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; 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 hold it to be correct nonetheless. 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, but it is not. The work shifts 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 acts as an accelerator of an activity that at its core consists 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, then I touch the self-image of many colleagues, and that demands a justification that goes beyond a slogan.
Developer and architect have become one role
Before I talk about the mechanics, I have to explain an organizational decision that stands behind this role. 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 comes into being in minutes instead of days, then the sharp separation between the one who designs the architecture and the one who implements it becomes artificial. The architect has to check against the grown legacy system anyway, the brownfield, whether her idea holds there, and this 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. In essence it runs like this: from the principles of the project, a kind of technical constitution, and the functional specification, a clarification of open points emerges 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
When the agent writes the code, the question arises what the developer even contributes anymore. The answer is the architectural judgment and the feel for the concrete brownfield, and that is not a vague talent that 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 that touches the same record in three places and at one of them makes an assumption that the other two do not know is not marked as a danger in the source code. 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: column names that preserve an old business vocabulary; process logic that implements some requirement from ten years ago whose reason is no longer documented; 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.
From this follows a shift that I consider the core of this role. The review of behavior, diff, and tests is the new central work of development. 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, about the variable name. Whoever reviews a diff that an agent produced has to answer the question whether this change does the right thing in the grown system, whether it takes 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 matters 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
The first concrete task of development in the pipeline is the feasibility check. It is reading. In this phase the agent changes not a single line of code. Instead it reads the grown system. It searches the source code, reads the version history via git log and git blame, evaluates Architecture Decision Records, that is, documented architecture decisions, reads runbooks, which are the operating instructions for live operation, and examines the database schemas. That the agent may read freely but needs a release for every change is one of the important principles of the pipeline. This way, exploring the system stays possible at any time, while an intervention in the code demands a deliberate decision.
The actual result of this phase 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. It is also recorded which assumptions of the functional ticket have been confirmed against the brownfield and which have been disproven. If the ticket from business analysis assumes that a certain field is always filled, and the feasibility check determines against the real data that it is not filled at all in many legacy records, then 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 one could, if need 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, and it prevents, conversely, that a truly blocking gap gets 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 interface through which other systems or the surface access it, the API, and finally the surface itself. The tests follow, insofar as they do not arise per ticket anyway, then the documentation last. 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, for example as a reference to a particular acceptance criterion or a particular UX state. The point behind this is traceability. When later someone asks why this one code change exists, then 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 often does not suffice 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 is implementable and testable in one to three hours has a size that a human can still keep in their head when they review the diff. A ticket that comprises a whole day produces a diff that is too large to review responsibly. The small slice therefore has a solid reason. Without it the review can hardly be done cleanly in 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 reading. 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, and 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 wording matters:
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 was reviewed by a human beforehand and to quality requirements that are enforced by machine, that is, to 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, because 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, 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, by contrast, endures. In this role, version control is the actual source of truth about the state of the work, far more than just the storage place for finished code.
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, and git diff 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 beginning is made by the feasibility statement, recorded in its own block for development notes within the functional ticket, there where business analysis finds it. There follow 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 the explicit determination of what is deliberately 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 the test.
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. Here a condition applies that I consider decisive: the pull request must be understandable on its own, from the diff, the tests, and the plan, without anyone knowing 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, because this chat is ephemeral and no one archives it. And finally the progress log, which 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. What is reviewed are 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. The license and IP check verifies whether the produced code pulls in foreign components under an incompatible license. The 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 obviously 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, that is, the state in which every line of the code is executed at least once by an automatic test, was a theoretical ideal in most projects. It cost so much time that under deadline pressure it was the first thing to be cut. Lint in strict mode, that is, a tool that checks the code against all style rules and suspect patterns without any rule being waved through as an exception, was similarly 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 things that first fell 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. It costs no human effort to satisfy every lint rule when the agent adjusts the code until no rule triggers anymore. Formatting and static checking are no longer negotiable, because adhering to them happens 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. What was previously an ideal that one had to afford is now the path of least resistance.
But one hundred percent test coverage is not the same as correctness. Coverage measures whether a line was executed by a test, not whether the test checks the right thing. An agent can write tests that touch every line and still assert nothing meaningful, because they only confirm what the code does anyway, instead of checking whether it does the right thing. A suite of such tests gives a green light that is worthless. Full coverage therefore 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 further. That is why the Test role is needed after development, and that is why this role has to bring a different perspective than the one that produced the code and its tests.
What makes the economic reversal valuable anyway is the shift in the floor. Previously the question was whether a project could even afford a decent test coverage and strict static checking. This question no longer arises, because the answer is free and is yes. The energy that previously flowed into reaching this floor is now available for the harder work. That includes the review of whether the tests check the right thing, and the judgment of whether the change does the right thing in the brownfield. The base level is handled by the agent, which frees the humans up for these questions.
How the compliance rules take effect in this role
The pipeline contains a series of compliance requirements that run through all roles. 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 under a license that is 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, and 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. Whether a line of code was written by hand or proposed by a model and merely confirmed can be read later in the version history.
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 actively blocked by a technical lock, not merely forbidden by a convention. This separation is the precondition for long autonomous work to be responsible at all, because 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 this responsibility is not diminished by the AI support. 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; when 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 to a large extent from the mind through the keyboard into the editor. Mastery of the editor, speed at writing, formalized and conceptual thinking, knowing a programming language by heart down to its corners were competencies one was allowed to be proud of and that are now losing their value. 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 is more demanding than typing: designing a plan that holds, slicing the tickets so 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 through writing code, faces a harder path, because the entry through the craft falls away and the entry through judgment presupposes an experience that she cannot yet have. What this path looks like in the future, 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 see errors in the dialogue considerably more often than unpracticed ones. But how one acquires this practice when the traditional path of practice disappears is an open question, and I have no ready answer to it.
Outlook
Development delivers in this pipeline a pull request with green checks and full test coverage. With that the work is not yet over. Coverage is not correctness, an agent can write tests that touch everything and check nothing meaningful, and the hard judgment about the rightness of a change stays with the human. Here the next role attaches. The following post in the series treats the Test role, which looks at the same feature with a different perspective than the one that built it, and which attaches where a green checkmark from development is not yet a guarantee of correct behavior.