This is the third post in a series about the agentic engineering pipeline for the SDLC. The opening post described the approach as a whole and named its six principles, and the post before this one went into business analysis and its interplay with UX. Now we turn to the place where most people suspect the actual act of software development happens: the writing of the code.
In this pipeline, development no longer writes the code. This claim is uncomfortable, and I still hold it to be correct. There is no IDE anymore in the old sense, no integrated development environment in which a person opens file after file and types line after line. The developer no longer sees the individual source code as it comes into being, because the agent writes it. This sounds like a loss of control. The work just moves to a level at which the hard decisions have always been made anyway. Whoever types code line by line spends a large part of their time below that level.
Why this role in particular puts the thesis to the test
Business analysis and UX have long worked with language as their main material. An analyst who labels a source inventory, or a designer who describes an error state in business language, has never seen a compiler error message. For these roles, the agent speeds up an activity that consists essentially of reading, comparing, and formulating. Development is different. It has a craft that has built up its own world of tools over decades: editors with syntax highlighting, debuggers, refactoring keys, autocompletion. This world of tools was the pride of the profession. When I claim that it largely disappears in an agentic pipeline, I touch the self-image of many colleagues. That calls for a justification that goes beyond a slogan.
Developer and architect have become one role
Behind this role stands an organizational decision. In the classic setup, architecture and development are separate. There is someone, often with the title software or solution architect, who decides in advance how a system is built, which components talk to each other, which patterns apply. Alongside that is development, which translates these specifications into code. This separation had an economic reason. Architecture decisions are expensive if you correct them late, and typing code was slow enough that an upstream planning phase paid off.
The agent shifts this balance. When a first runnable implementation appears in minutes instead of days, the sharp separation between the person who designs the architecture and the person who implements it becomes artificial. The architect has to check against the grown legacy system anyway, the brownfield, to see whether her idea holds there. That check now runs through the same agent that later builds. It no longer makes sense to outsource the architecture knowledge into a separate upstream phase and a separate person when the feedback between design and reality becomes this tight. In the pipeline, developer and architect are therefore one connected role. The architecture review is its own station within the same role that also builds.
This station has its fixed place in the chain. Roughly, it runs like this: from the principles of the project, a kind of technical constitution, and the functional specification, open points are clarified first. After that follows the architecture review, in which it is decided how the change fits into the grown system. Only then follow the plan, the tasks, and the actual implementation, before the quality gate takes hold. The architecture thus sits before the code, but in the same hand that is responsible for the code.
The capability a model does not have
What the developer still contributes when the agent writes the code is the architectural judgment and the feel for the concrete brownfield. That is not a vague talent one invokes when the arguments run out.
An experienced architect recognizes that a change in one place triggers something three places further on. It is not in the code. She recognizes it because she has seen a comparable system fail at exactly this spot before. A storage logic, say, touches the same record in three places and at one of them assumes something the other two do not know. In the source code, that is not marked as a danger. It is a danger because a human knows the history of the system and knows where it once hurt. No repository holds this experiential knowledge. It lives in the heads of the people who have maintained the system.
The agent has something else. It has training patterns, that is, an average across very many systems that it saw during training. This makes it strong at everything common. At what is particular to this one system it grows uncertain, and in the brownfield what is particular almost always counts. Examples are column names that preserve an old business vocabulary, or process logic that implements some requirement from ten years ago whose reason is no longer documented. Add to that tacit conventions the code obeys without anyone recording why. A model cannot derive such peculiarities from the average of the world. Someone who knows the system from their own work has to know them.
That makes reviewing behavior, diff, and tests the new central work of development, and I consider this shift the core of the role. Diff means the difference between the code before and after a change, that is, exactly what the agent touched. This review demands more judgment than typing. Whoever types a function themselves thinks about syntax, about the right loop and the variable name. Whoever reviews a diff that an agent produced has to answer instead whether this change does the right thing in the grown system. Does it take effect in the three places it has to affect, and in none that it must not affect? That is the harder question, and it used to be buried beneath the typing.
The agent is good at what is common, because it has learned the average of many systems. In the brownfield, what counts are the peculiarities of this one system, and only someone who knows the system from their own observation knows them. The main work of development has therefore become reviewing the diff and the behavior. That review demands the same architectural judgment that used to be folded into the typing work.
How the agent takes over the work: the feasibility check
Development’s first concrete task in the pipeline is the feasibility check. It is a reading task. In this phase the agent changes not a single line of code. Instead it reads the grown system. To do so it searches the source code, reads the version history via git log and git blame, and evaluates Architecture Decision Records, that is, documented architecture decisions. It also reads runbooks, the operating instructions for live operation, and examines the database schemas. One of the important principles of the pipeline is that the agent may read freely but needs a release for every change. This way, exploring the system stays possible at any time, while an intervention in the code requires a conscious decision.
What this phase actually produces is a statement about whether the change is feasible, not feasible, or feasible only under certain conditions. With this statement comes a list of the affected components. The check also records which assumptions of the functional ticket have been confirmed against the brownfield and which have been disproven. An example: the ticket from business analysis assumes that a certain field is always filled. The feasibility check, however, finds against the real data that in many legacy records it is not filled at all. That is a disproven assumption, and it belongs documented before anyone writes code. Added to this are questions back to the business side and a short solution sketch. The sketch indicates a direction and does not yet contain an implementation.
The questions do not go into the chat. They go back into the functional ticket, to where business analysis sees them and can answer them. They are also classified. A question is either blocking, in which case implementation cannot begin without an answer. Or it concerns something that could, if need be, be cut out of the scope, in which case it does not hold up the ticket. Or it is purely a matter of implementation, in which case development can decide it itself without bothering the business side. This classification prevents every technical detail question from being blown up into a question back to the business side. Conversely, it also prevents a blocking gap from being swept under the table.
From ticket to task: the technical slice
When feasibility is clarified, development slices technical tickets. Here a rule applies that demands a lot of discipline in practice: a ticket comprises exactly one change with its own acceptance test.
The order of the tickets follows the natural buildup of a change, which grows from the bottom up through the layers of a system. First the data model, because everything else builds on it. On top of it the business logic that works with this data. Then the API, that is, the interface through which other systems or the user interface access it, and finally the user interface itself. After that come the tests, insofar as they do not arise per ticket anyway, and last the documentation. This order ensures that every ticket builds on a foundation that already stands.
Every technical ticket contains a back-reference. It names the acceptance criteria of the functional ticket that it implements, and the UX states that it serves. In practice I write these references as short tags, such as a reference to a particular acceptance criterion or a particular UX state. The point behind this is traceability. When someone later asks why this one code change exists, the reference leads from the technical ticket to the functional criterion and from there to the original requirement. This chain is valuable in the brownfield, because legacy code notoriously loses its justification. After three years no one knows anymore why a certain check exists, and the version history alone is often not enough if the commit message back then was thin.
As a rough heuristic for the size of a technical ticket I take one to three hours of work. What is meant is the slicing of a task. The number is not a billable time budget. A ticket that can be implemented and tested in one to three hours has a size that a human can still keep in their head when reviewing the diff. A ticket that comprises a whole day produces a diff that is too large to review responsibly. So the small slice has a solid reason: without it, a clean review is hardly possible anymore at the end.
The cascade of plan, epic, and tickets
Above the individual tickets lies a cascade that leads from the first research to the autonomous implementation loop.
At the beginning stands the research, and it is a reading task. Here the same thing happens as in the feasibility check: the agent reads the legacy code without changing anything. On this builds the epic. It describes the goal of the entire change, the scope, and the overarching acceptance conditions, and forms the bracket under which the individual tickets hang. From the epic the tickets are then sliced, small and testable, according to the rules I just described. The plan subsequently sets the order of the work, plus the quality gates that have to be passed along the way. It also contains the Definition of Done, that is, the condition under which the work counts as finished. Last runs the loop in which the agent actually works through the plan.
I steer this loop with a single instruction, which I reproduce here verbatim, because its exact wording is important:
Continue with the next step according to the implementation plan. Stop only when the plan is finished. Implement the task in a structured and careful manner. Be precise. Adhere to the quality requirements (lint, tests) absolutely. Commit often and early. Document your progress in the implementation plan, the epic, and the tickets.
This one instruction allows long autonomous work without constant micromanagement, because its guardrails lie outside the agent. It refers to a plan that a human reviewed beforehand and to quality requirements that are enforced by machine. Those are lint and tests that fail hard when something is wrong. Its stop criterion is clear, namely the end of the plan. Without the reviewed plan and without the hard gates, the same instruction would be dangerous. It could send the agent twenty steps in the wrong direction before anyone notices that the direction was wrong. With plan and gates it becomes a tool for the autonomous work that makes the speed gain pay off in the first place.
Committing often and early connects the loop with the principle that I consider the most important of the whole pipeline: that state lives in artifacts and not in the chat.
Git as the source of truth
An agent has no memory beyond the session, and even within a session a long chat history loses its effect. What is in the repository, on the other hand, endures. In this role, version control does not just store finished code. It is the actual source of truth about the state of the work.
Three useful traces arise here at no extra cost. The commit message records the why of a change, provided one takes it seriously and does not fob it off with one word. Via git blame the origin of every line can be traced: when it came into being, by whom, and with what justification. The git diff command shows the exact difference between two points in the history. Unlike a separately maintained notes file that lies around in every project and goes stale at the next code change, this trace hangs on the code itself and stays current. Whoever reads the history of the affected file before a change guesses less.
What the role produces
At the end of its work, development leaves behind a series of artifacts. I name them individually, because the quality gate later attaches to exactly these artifacts.
The first is the feasibility statement, recorded in its own block for development notes within the functional ticket, where business analysis finds it. Then come the epic and the technical tickets, each of which contains a test strategy. This test strategy names which tests arise at which level: unit tests for individual functions, integration tests for the interplay of several parts, end-to-end tests for the continuous flow from the user’s perspective. It also names something that is often missing and that I consider especially important: the anti-test. By this I mean that the strategy sets out what is intentionally not tested and why. A test strategy that only says what is tested leaves open whether a gap was intended or forgotten. When the strategy names its gaps explicitly, a reviewer can retrace the decision behind it and come back to it during testing.
Added to this are the implementation plan and the pull requests. A pull request is the unit in which a completed change is submitted for review. For it, a condition applies that I care about: the pull request must be understandable on its own, from the diff, the tests, and the plan. No one should have to know the chat history with the agent. If a reviewer can only understand the pull request by retracing what was discussed in the chat between human and agent, then the handover has failed. That chat is ephemeral, and no one archives it. The last artifact is the progress log. It records which step was completed when and with what result.
The quality gate of this role
Development has two check points in the pipeline, and they lie at different places in the work.
The plan review stands before the first code. It checks the order of the work, the test strategy, the risks, and the affected files. This review is the most effective point of the whole role, because an error is cheapest here. As long as it is in the plan, a correction in the text suffices. Once the agent has built it into the code over twenty steps, the code correction is joined by the search for the spot at which the direction tipped. Reviewing the plan beforehand costs little and spares this expensive rework.
The code review on the pull request comes after that. Here a human reviews the behavior, the diff, and the tests. The mandatory artifact of this role consists of two parts: the reviewed plan and the pull request with green checks. Green checks means that all automatic checks have passed. Without these two artifacts there is no handover to the next role.
Beneath the human check points lies a machine layer that no one has to go through by hand. Deterministic checks run before the expensive model stations even start up. The static security analysis examines the code for known vulnerability patterns. Alongside it, the license and IP check verifies whether the produced code pulls in foreign components under an incompatible license. Detection of prompt injection catches smuggled-in instructions that could manipulate a model out of a file it has read. These checks run as scripts with a traceable result, and they run first on purpose, so that no model spends computing time on plainly faulty material. They handle what can be determined unambiguously and so relieve the human gates, which deal with questions of judgment.
The economic reversal: quality that is suddenly affordable
About this role, one point occupies me most: it reverses a calculation that ran against quality for decades.
Code quality always had a price in developer hours. One hundred percent coverage by unit tests was a theoretical ideal in most projects: every line of the code executed at least once by an automatic test. That cost so much time that under deadline pressure it was the first thing to be cut. Lint in strict mode checks the code against all style rules and suspect patterns without any rule being waved through as an exception. That was just as expensive, because every rule that triggers costs a human who fixes it. The same goes for consistent formatting and gap-free static checking. These disciplines were the first to fall victim to deadline pressure, because their benefit lay in the future and their cost in the present.
The agent shifts this calculation, because adhering to these disciplines costs it almost nothing. It no longer costs an additional developer hour to cover one hundred percent of the lines with tests when an agent writes the tests. Satisfying every lint rule, too, costs no human effort anymore when the agent adjusts the code until no rule triggers. Formatting and static checking are no longer up for debate, because the agent keeps to them in the loop without a human having to spend time on it. With that, the calculation reverses: disciplines that used to fall victim to deadline pressure because they were expensive are now the standard case, because they have become cheap. An ideal that one had to afford has turned into the path of least resistance.
One hundred percent test coverage, however, is not the same as correctness. Coverage only measures whether a test executed a line. It says nothing about whether the test checks the right thing. An agent can write tests that touch every line and still assert nothing meaningful. They then only confirm what the code does anyway and do not check whether it does the right thing. A suite of such tests yields a green checkmark that is worthless. Full coverage, then, only shifts the problem. It ensures that the cheap errors surface by machine, and leaves the expensive errors, which lie in the understanding of the requirement, open. That is why the Test role is needed after development, and why it has to bring a different perspective from the one that produced the code and its tests.
The economic reversal is still valuable, because it shifts the floor. Previously the question was whether a project could even afford decent test coverage and strict static checking. This question no longer arises, because the answer is yes and it costs nothing. The energy that used to be needed to reach this floor is now free for the harder work. That includes reviewing whether the tests check the right thing, and judging whether the change does the right thing in the brownfield. The agent handles the base level, which leaves the humans time for these questions.
How the compliance rules take effect in this role
A series of compliance requirements runs through all roles of the pipeline. In development, some of them become especially concrete, because here, for the first time, code arises that can have real effect.
The static security analysis and the license and IP check attach directly to the produced code. They belong to the machine layer beneath the code review and do not run only later. The security test catches known vulnerability patterns before they get into a pull request. The license check prevents foreign code with a license incompatible with the project from slipping in unnoticed. That is a form of IP contamination that is a real risk in agentic work, because a model can reproduce code from its training whose origin no one knows.
Every AI-produced change gets a marking. In development this marking sits in the commit comment. It names the operation that was carried out, the responsible person, and the version of the model or the skill definition that produced the code. A skill definition here is the reusable instruction with which a certain task is given to the agent. This marking is the transparency requirement of the EU AI Act, Regulation (EU) 2024/1689, in daily practice. This way, the version history later shows whether a line of code was written by hand or proposed by a model and only confirmed.
The agent works in an isolated sandbox, that is, a sealed-off environment, and not on the developer’s laptop. It has access neither to the file system of the human who steers it nor to production environments. Its effect is limited to development, test, and integration. An operation on a production environment is not only forbidden by convention but actively blocked by a technical lock. This separation is what makes long autonomous work responsible at all. An agent that can do nothing to production may have more freedom in the development environment.
At the pull request stands the human gate. A named, responsible person releases the change or improves it, and the AI support does not diminish this responsibility. Added to this is the second and third opinion from the fifth principle of the series. In the code review a second model checks the patch, one that did not write it itself. A model that checks its own code clings to its own logic and overlooks the same errors it made while writing. A second model with different training data and different blind spots brings an independent perspective. When both agree, the finding is more reliable, and where they diverge, a human has to look more closely. The same separation also hardens against prompt injection, because a smuggled-in attack would have to outwit two different models in two different ways.
A word to those who would rather not hear it
I began this post with a thesis that touches the self-image of many developers, and I do not want to soften it at the end. The profession, as many learned it, ran largely from the mind through the keyboard into the editor. Competencies one was allowed to be proud of are now losing their value: mastery of the editor, speed at writing, formalized and conceptual thinking, knowing a programming language by heart down to its corners. That is a real loss for those who invested a lot in these skills, and I think nothing of selling it as a pure gain.
What takes its place demands more experience than typing. It means designing a plan that holds, slicing the tickets so that the review works, and judging whether a diff does the right thing in the grown system. The newcomer to the profession, who used to grow into the subject by writing code, faces a harder path. The entry through the craft falls away, and the entry through judgment presupposes an experience that she cannot yet have. What this path will look like, I do not know. The study by Christopher Potts and Moritz Sudhof of Stanford University, “A paradox of AI fluency” (arXiv:2604.25905), gives a hint that practice makes a difference. Practiced users spot errors in the dialogue much more often than unpracticed ones. How one acquires this practice when the traditional path of practice disappears is an open question, though, and I have no ready answer to it.
Outlook
In this pipeline, development delivers a pull request with green checks and full test coverage. That does not end the work. Coverage does not guarantee correctness: an agent can write tests that touch everything and check nothing meaningful. The hard judgment about the rightness of a change stays with the human. This is where the next role picks up. The following post in the series covers the Test role. It looks at the same feature from a different perspective than the role that built it. Its work starts where a green checkmark from development is not yet a guarantee of correct behavior.