DEV Community: akash singh

I Built an AI System for 80+ Microservices. Six Months Later, My Whole Team Uses It.

akash singh — Fri, 02 Oct 2026 15:21:28 +0000

In April I wrote about a system I built on Claude Code that takes an epic to PR-ready code across 80+ microservices. If you read that post, I sounded like someone who had finished something.

I hadn't. This is the follow-up I didn't plan to write. It covers what went wrong, what I got wrong, and how a tool I built for myself ended up being used by the whole tech team, every new joiner, and people who don't write code at all.

I had written "DO NOT" eight times in one file

A couple of months in, I stopped trusting my own rules.

The one that stung most was commits. My prompts said, in capitals, that the system must never run git commit. It is the rule I care about most, because I want to read every diff before it becomes history. One day I went looking for why that rule felt shaky, and I found two things. My own settings file was explicitly allowing git commands. And one of my own reference documents contained a ready-made git add && git commit snippet. I was telling the model NEVER in eighteen places while handing it permission, and an example, in two others.

Until then, my fix for anything that went wrong had been the same every time. I opened a prompt file and added another line in capital letters. MANDATORY. NEVER. A warning emoji, to be safe.

So one weekend I sat down and audited everything I had built. The same set of rules (don't commit, don't lint, don't skip a phase) was pasted into 18 different files. One of those files said "DO NOT run" eight times. The main orchestrator prompt was 1,464 lines long, and all of it was loaded at once.

I felt a bit silly. This is exactly what I flag in other people's pull requests: duplicated logic and no single source of truth. I would never have approved it. And I had written it myself, one frustrated line at a time.

The damage was what you would predict from any codebase with copy-pasted rules:

Drift. I changed a rule in one file and 17 others quietly disagreed with it. The model had to guess which copy was the real one.
Dilution. When everything is MANDATORY, nothing is. The model could not tell a rule that protects a loan calculation from a rule about where the braces go.
Cost. Every turn, it re-read the same prohibitions when it should have been reading my code.

Asking is not the same as preventing

The fix had two parts.

The first was boring: one rulebook. A single file where every rule has a short ID, like GIT-1 for "never commit" and ISO-1 for "only write inside the isolated workspace". Every other file now says "obey GIT-1 and ISO-1" and nothing more. My main instruction file went from 370 lines to about 145.

The second part changed how I think about these tools.

I split the rules into two kinds. Some are judgment calls, like matching the code style already in a service. The model applies those with discretion, and that is fine. Others are invariants. Never commit. Never write outside the workspace. Those have to hold every single time.

For the invariants, I stopped asking. Claude Code has a permission system, and I moved those rules into it. The command is now denied before it runs. The model's opinion about it no longer matters.

A prompt is a request. A deny rule is a wall. I had spent months making the same request in a louder and louder voice, when what I needed was a wall.

It is not a perfect wall. A command wrapped inside another command can still slip past the matcher, so I kept the written rule as well and I check the permission file from time to time. But the difference in day-to-day behaviour was immediate.

It learned to debug, which I never planned

The April version did one thing: turn an epic into code.

But new features are not most of my week. A large part of it is support. Something failed in production, a number is wrong, and somebody needs to know why before the end of the day.

So I gave the system read-only agents. One searches the logs. One queries MongoDB. One runs SQL. One reads metrics. None of them can write anything.

The first version of the log agent taught me something. I would describe a problem, and it would search for what it imagined the log message looked like. It found nothing, and it reported that nothing with complete confidence.

The fix is embarrassing in its simplicity: before searching the logs, search the code for the actual log string. That is what I do myself when I debug. I had just never written it down, because it never occurred to me that it was a step.

Every incident we solve now becomes a runbook. There are 29 of them. The next time the same thing breaks, the system starts from the runbook instead of from zero, and so does whoever is on support that week.

The day a teammate opened a pull request

In May, a colleague opened a pull request against the framework. It was a skill that spins up a local cluster of our services for debugging. I had not asked for it.

A few weeks later someone else added the database and log agents I just described. Three teammates have contributed so far.

This mattered more to me than any token number. In April I wrote that this was "just something the team needed". If I am honest, at the time it was something I needed, and I was hoping the team would too. A pull request from someone else was the first real evidence.

I remember reading that diff twice. It was not complicated. I read it twice because someone had gone through my prompt files closely enough to extend them, and had decided the thing was worth their own evening. Until then I had been the only person who knew where anything was.

Then people I never built it for started using it

Today the whole tech team works out of this repo. I did not announce that or push for it. It spread one person at a time, usually after someone watched a colleague get an answer in two minutes that would have taken them an afternoon.

New joiners start here now. Anyone who has joined a company with 80+ services knows the first month: you don't know which service owns what, and you feel like you are interrupting a senior engineer every time you ask. Now a new joiner asks the system first. It answers from the service map and from the code itself, and it never sighs.

For any new joining, the first question used to be some version of "where do I even start reading?". I never had a good answer. Ninety-odd services is not something you read. Now I tell them to open the repo and ask it how a loan moves from application to disbursal, then follow whatever it points at. They come back with better questions, and they come back sooner.

The part that surprised me most is the product team. They do not write code, and I never imagined them opening this repo. But they use it to ask plain questions, like which third-party vendors we depend on and which flows each one sits behind. That used to be a message to an engineer and a wait for whoever had time. Now they ask directly and get an answer grounded in the actual code.

I built a pipeline for delivering code. The thing people reach for most is simpler: a way to ask the system how it works and get a straight answer.

Smaller changes that added up

Reviewers. There are now review agents that read a plan or a diff before I do, including one that checks specifically for fintech risk and can block the work. That block used to be a sentence in a prompt. Now it is a piece of state the workflow checks, so it cannot be talked around. One rule I settled on: the reviewer must be at least as capable a model as the author.

The right model for the job. Fetching logs does not need the most expensive model. Deep code analysis and test-driven implementation do. Each agent now runs on the model that fits its work.

A second codebase. The system now works across two separate sets of repositories, where before it knew only one.

What I would tell myself in April

If you are writing the same rule for the third time, you have a structure problem. The model is not the issue.
Decide which of your rules are invariants, and enforce those outside the prompt.
Build for the work you actually do. For me that was debugging, even though code generation makes the better demo.
Share it before it feels ready. The best parts of this system were not written by me.
Watch who actually uses it. I built this for engineers shipping epics. New joiners and the product team get as much out of it, and they use it for something I treated as a side feature.

The numbers

I do not have a tidy before-and-after benchmark, and I would rather not invent one. Here is what I can count:

92 services are mapped today, up from the 80+ I wrote about in April.
31 features have their own workspace in the framework.
29 runbooks have come out of real production incidents.
3 teammates have contributed code to it, and the whole tech team uses it.
The token figure from the first post still holds: roughly 75,000 down to 15,000 per epic, because the heavy reading happens in separate agents.

How it all fits together

If you skipped everything above, this is the whole system in one picture. Three kinds of request go in: a question, an epic, or an incident. All three read from the same shared knowledge and run inside the same guardrails, and what each one produces goes back in for the next person.

Some things have not changed. I still approve every phase. I still read every diff. I still raise every pull request myself. I do not expect that to change, and I do not want it to.

The interesting part was never removing the engineer from the loop. It was reducing how much context the engineer has to hold in their head.

If you are building something similar, I would like to know one thing: which of your rules turned out to be walls, and which were only ever requests?

I Built an AI System That Delivers PR-Ready Code Across 80+ Microservices

akash singh — Sat, 18 Apr 2026 12:08:17 +0000

I'm a software engineer at a fintech company with 80+ microservices. I built a structured AI system around Claude Code that takes an epic from description to PR-ready code — while I stay in control of every decision.

Here's how it works, why I built it, and what it actually changed.

--- The Problem With Microservices at Scale A single product epic at Propelld can touch 5 to 10 services simultaneously. Before I built this system, the pain was predictable:

Dependencies got missed mid-sprint
Architecture decisions lived in Slack and died there
Code review surfaced patterns that should have been caught in design
The same mistakes repeated across epics because nobody remembered what was decided three months ago Standard tools don't solve this. Copilot suggests the next line. ChatGPT gives you a plan. Neither knows your codebase, your service boundaries, or your team's conventions.

I needed something that could reason about my system — not a generic one.

What I Built

An AI-assisted delivery system built on top of Claude Code (Anthropic's CLI for Claude). Not a side project. Not open source. Just something the team needed.

The system takes an epic from description → code analysis → architecture decision → implementation → PR-ready code.

My role: make decisions, review diffs, raise the PR.

The system's role: everything else.

--- The 6-Phase Pipeline

Every phase has a hard human gate. The AI cannot proceed until I explicitly approve.

Phase 1 — Service Identification

The system reads a service-index.json — a curated map of what each of the 80+ services does — and identifies which services the epic touches. No source code read yet. Just topology. Then it stops and asks clarifying questions.

Phase 2 — Deep Code Analysis

A sub-agent dives into actual source code. It finds patterns, import conventions, error handling styles, and inter-service dependencies. Everything gets saved as checkpoint files — JSON and Markdown artifacts that carry context forward without re-running the analysis. Then it stops and surfaces a summary.

Phase 3 — Architecture Options

The system presents two or three architecture approaches with trade-offs. Pros, cons, complexity, risk. I choose. The AI never picks for me — this is a hard rule in the system prompt.

Phase 3.5 — Decision Records

My choice gets saved as an Architecture Decision Record (ADR). Future epics reference past decisions automatically. This is how institutional knowledge stops dying in Slack.
Phase 4 — Implementation Guide

A second agent generates a full implementation guide: BEFORE/AFTER code diffs, file paths, service mapping, story points per task. This happens before a single line of production code is written.
Phase 5 — Handoff Options

I choose how to proceed:

AI-guided execution with me driving
TDD mode (AI writes tests first, then code)
Take the guide and go fully manual Phase 6 — Code Generation (TDD) If I pick TDD mode, the AI writes code in an isolated workspace — never directly in the microservices directory. I review the diff. I raise the PR. No autonomous commits. No auto-formatting. No surprises.

The Architecture That Made It Work: Agents and Skills
The heavy lifting doesn't happen in the main conversation thread. That was the key insight.
I built custom agents and skills that run in parallel — like a lead engineer delegating to specialists:

One agent explores the service graph
Another analyzes source patterns
Another generates the implementation guide

Each runs in its own context. Only the summary returns to the main thread.

Result: token usage dropped from ~75,000 to ~15,000 per epic. The main conversation stays clean enough to reason about.

--- The Part People Underestimate: Pattern Matching
This isn't vibe coding.

Before generating any code, the system reads the existing codebase and extracts:

Brace style (Allman — braces on new lines, mandatory at Propelld)
Import patterns (import { logger } from "../config/logger" — not CommonJS requires)
Error handling conventions (formatException(error) — not console.error)
Service client usage (@propelld/service-clients — never raw HTTP calls)

Code that comes out matches what's already there. It doesn't invent new conventions. It follows what exists.

--- What Actually Changed After a Month

Dependencies caught before a single line of code is written
Architecture decisions documented and automatically referenced in future epics
One engineer delivering PR-ready code across multiple services per sprint
End-to-end implementation flow for all major feature types
No need to download each service manually, I have created start.sh which download all the service into a folder and letter Agents can refer those services for analysis. --- What I'd Tell Anyone Thinking About This The system is only as good as the structure you impose on it. Unconstrained AI in a complex codebase is noise. Constrained AI with explicit phase gates, checkpoint artifacts, and pattern-matching is leverage.

The AI isn't replacing judgment. It's handling the grunt work — so judgment is the only thing I'm spending time on.

That's the trade worth making.

Have you built structured AI workflows into your engineering process? I'm curious what's working and what isn't — drop it in the comments.