The Makers – Implementation Plan & Developer

In the previous post I introduced the Business Analyst and the Solution Architect – the planning phase of my agent team. They produce not a single line of production code, but they lay the foundation for everything that follows: a structured use case document and a technical solution design that serves as a blueprint.

In this post the third and fourth members of the team arrive: the Implementation Plan Agent and the Developer Agent. They are the doers – and precisely for this reason the real challenge lies not with them, but with the question of how to deploy them correctly.

The Problem After the Concept

You might think that with a finished solution design the hard work is done. The Developer Agent receives the document, reads it, and implements it. Simple.

In practice, that doesn't work.

A solution design is a blueprint. It describes the target state – class diagrams, schema changes, sequence diagrams, an action catalog with ten or twenty items. This is exactly the amount of information a human developer needs to plan a good implementation. But for a Coding Agent with a limited context window, that same amount of information is a problem.

The model reads the concept, begins the implementation – and loses track in the process. Not immediately. But by the third change in the fourth file, what the research calls "Context Rot" begins: the early part of the concept, the architecture decisions from the beginning, the cleanup notes from page two – they sink in the model's attention because the code it is currently writing dominates the context window. What remains is a Coding Agent that is broadly on the right track but improvises more and more in the details.

This is the focus problem from the post about the four systemic weaknesses – but one level deeper. No longer at the level of the individual prompt, but at the level of a multi-step implementation task.

The Implementation Plan Agent: The Atomic Battle Plan

The answer to this problem is not better prompting and not a longer concept. The answer is another step of decomposition.

The Implementation Plan Agent takes the solution design from the Solution Architect and transforms it into an atomic, step-by-step implementation plan. Its output lands as a Markdown file under docs/plan/. That sounds like even more documentation – and that is exactly where the decisive difference from the classic documentation overhead that nobody reads lies.

This plan is not a summary. It is an execution script.

Every step in the plan contains:

• Affected file(s) with the full path
• A checklist with concrete tasks the Developer Agent can tick off
• Before/after code examples when the change is complex
• A validation command – a concrete npm run build or type-check command that must be green after this step
• Manual verification – a table: which action does the user perform, what is the expected result
• Cleanup – which code, which imports, which temporary workarounds are made obsolete by this step
• A risk assessment – from "none" to "high"

And the most important property of this plan: after each completed step the application is in a runnable state. No step breaks the build. No step leaves half-finished dependencies. This is not a coincidence but an explicit requirement on the agent that it must adhere to when creating the plan.

That sounds like effort. It is also effort – but it is incurred once, in advance, in a phase where corrections are cheap. Not spread across a chaotic implementation where every error surfaces only through npm run build.

An Idea I Borrowed

This approach did not emerge from nowhere. I looked at various concepts that have emerged in the community around AI-assisted development – including the GitHub Spec-Kit, a framework that formalizes the idea of Spec-Driven Development (SDD).

The core idea of SDD is precise: before the Coding Agent writes a single line, a highly precise specification is created – a guardrail that prevents the model from guessing, improvising, or making assumptions that will need to be corrected later.

I tried the Spec-Kit and was immediately convinced by this fundamental principle. Not all of it was directly relevant to me. I therefore adopted the aspects that fit my situation and left the rest: specifically the idea that the Coding Agent receives a finished specification as a guardrail, not a vague task description.

The implementation plan is my version of this specification. It is tighter, more concrete, and tailored to my stack – but it follows the same basic principle: the AI should not guess. It should execute.

The Developer Agent: Precision Tool, Not Creative Free Spirit

With the finished plan, the Developer Agent does not receive the entire solution design as context. It receives exactly one step. The current step. And nothing else.

This is intentional.

A Developer Agent that knows the entire solution design starts to optimize. It sees that step 7 would actually pair well with step 3, and merges them. It notices that there would be a more elegant solution if the order were swapped – and changes it without asking. It improvises the architecture because it believes it sees the big picture.

That is exactly the behavior that has cost me hours. It is the Coding Agent as a creative free spirit – and creativity in the implementation phase is the last thing I need.

A Developer Agent with a single step as context cannot do that. It reads the task, executes it, ticks off the checklist, runs the validation command, and waits. It makes no architectural decisions because there are none to make. The decisions were already made in the concept and the plan.

What this agent is very good at instead: strict adherence to coding guidelines, TypeScript typing without shortcuts, cleanup after every change, follow-up questions when the task is ambiguous. All within a focused, small context – and that is precisely its strength.

Human-in-the-Loop: A New Pattern at the Implementation Level

In the post about the strategists I described how the Human-in-the-Loop checkpoint works at the concept level: I review a use case and a solution design – documents I can judge before a single line of code exists.

At the implementation level the pattern is similar, but with one decisive difference.

The implementation plan is no longer an abstract architecture sketch. It is concrete: this file. This function. These three lines that change. This command that must be green afterwards. I can read the plan and immediately judge whether it is plausible – without reading the code for it. I can see whether the order of steps makes sense, whether a dependency is missing, whether a risk was underestimated.

That is the checkpoint where I intervene: not at the code level, but at the plan level, before the Developer Agent writes the first line.

After that the Developer Agent works through the plan step by step. And after each step the application is runnable – which means I don't have to wait until everything is done to see whether the direction is right. I can interrupt after step 3, look at the changes, and decide: continue, or course correction?

That is a different pattern from the classic code review at the end. It is not rubber-stamping thousands of lines that are already written and can hardly be changed without redoing everything. It is iterative control at a pace I set myself.

Why This Is Not a Control Problem, But a Steering Problem

Here is the point I couldn't formulate clearly enough for a long time: I don't review to find errors. I review to hold the course.

A Developer Agent that works strictly according to plan rarely makes technical errors in the narrow sense. It doesn't write broken code. What it does is interpret on a very small scale: when the task says "extract this logic into a composable" and there are two ways to do it, it chooses one. Not the wrong one – but perhaps not mine.

The Human-in-the-Loop checkpoint allows me to see these small interpretive decisions before they accumulate over ten steps into a divergence I can no longer trace. It is less error correction than course-holding.

And that is a fundamental difference from what I used to do: giving the agent everything at once, looking at what came out at the end, and then spending hours in a diff of 800 changed lines searching for where things went wrong.

Yes, It Is Also a Workaround

As already discussed in the previous post, this step too is a response to the limited context windows of today's models. The Implementation Plan Agent does not solve this through better prompts, but through decomposition: instead of forcing the model to process a complex concept as a whole, it receives the smallest meaningful unit – one step, one validation command, one defined end state.

That is a workaround, but one that works. And "it works" is the decisive criterion in engineering. Whether future models will make this decomposition unnecessary, I don't know. Today it is the most reliable method I have found.

What This Means in Practice

I want to walk through the pattern concretely once so the flow becomes tangible.

Starting point: The solution design from the Solution Architect is stored under docs/loesungskonzept/. It describes a new feature implementation in twelve measures, spread across three layers – database, backend, and frontend.

Step 1: The Implementation Plan Agent reads the concept and analyzes the existing codebase. It creates a plan under docs/plan/ with eighteen concrete steps, grouped in three phases. Each phase leaves a runnable build.

Step 2: I read the plan. Not the code – the plan. This takes ten minutes. I notice that step 9 assumes a dependency that was not described that way in the concept. I add a note, the Implementation Plan Agent corrects the step.

Step 3: The Developer Agent receives step 1 of the plan as context. It executes the tasks, ticks off the checklist, runs npm run build – green. It waits.

Step 4: I look at the changes. One file, three functions, one new type. Everything as planned. I release the next step.

This is not a fast-track procedure. For a small, isolated feature it is clearly overkill. But for a medium to large implementation that affects multiple layers and must be integrated into a grown codebase, it is the method that costs less time in the end – because architecture breaks, duplications, and rule violations never arise in the first place.

Conclusion

The Business Analyst and the Solution Architect ensure that the right thing is planned. The Implementation Plan Agent ensures that the plan is implementable. The Developer Agent ensures that the plan is actually implemented – step by step, validated, without improvisation.

Each of these agents does exactly one thing. No agent needs to know everything. No agent needs to keep the big picture in view – that's my job.

That is the core of the Human-in-the-Loop principle as I understand it: not as a vote of no confidence in the AI, but as a conscious decision to deploy the cognitive strengths of human and model at the right places. The model is good at executing focused tasks. The human is good at judging direction, context, and intention. Both together are stronger than either alone.

In the next post I'll show how this four-agent team is rounded out by some specialized additions – and where the limits of the whole approach lie.