Phase 8. Implementation: the agent writes code | Grigoriy Dobryakov

Grigoriy Dobryakov

Course · AI-Driven Development Lifecycle

Home ← Back to course
Phase 8ADLC course

Phase 8. Implementation: the agent writes code

We've reached the phase most conversations about AI in development are actually about — writing code. And it's the one phase in the course where the "no human" provocation sounds mundane: agents already write code in production, there's nothing left to argue. So this article isn't about agents being able to code. It's about the fact that with a live PM agent above (phase 7) and a review agent beside it (phase 9), there's no point left around the task itself where a human is required.

The subtlety is in the unit of work. Most people picture "AI writes code" as an accelerated engineer: a human sits in the IDE, the agent completes lines. That's an assistant. The ADLC unit is different: not a line with autocomplete, but a task that turns itself into a finished PR with no human in the loop.

Ideation1 Discovery2 Marketing3 Requirements4 Architecture5 Formation6 Planning7 Implementation8 Code review9 Testing10 Release11 Operations12 Maintenance13 Governance14

The human role today

An engineer picks up a task from the board, reads the context, writes code and task-level tests, commits, opens a PR, responds to review comments. Classically, AI lives inside this loop as autocomplete — it speeds up the engineer without stepping outside their role. The decision, the communication, and the accountability stay with the human.

Strip away the acceleration and look at the substance: the engineer's work at this phase is translating a task with acceptance criteria into code that passes tests, within the given architecture. That's a transformation of spec into implementation — exactly the class of problem where the agent is strong, and where its weaknesses lie not inside the task, but at the seams between tasks.

What we hand to the agent

The engineering agent holds the task whole. It reads the assigned task from the board, familiarizes itself with the codebase and contracts, writes code and task-level tests, commits, opens a PR, and responds to the review agent's comments — with no human in the loop. The unit is "task → finished PR," not "line → next line."

What also changes is what used to make the engineer irreplaceable: they were the only one who understood their piece of code. In a team of agents with shared external memory, there's no "ownership" of a chunk — the task context, architecture, and ADRs are equally available to any agent. Knowledge stops being an engineer's personal capital and becomes shared state.

Agent architecture

Phase state-machine

Inputs

the assigned task (phase 7), architecture + ADR (phase 5), the codebase, API contracts, project standards.

The agent holds the role

Tools: repository access; running builds and tests locally; git and PR workflow; reading dependencies and code context; access to ADRs as binding constraints.

Artifact

a PR with code and task-level tests, linked to the task on the board.

Handoff: PR → Code review (phase 9); task status → back to Planning (phase 7). The PR as a unit isn't a detail — it's the substance. It's atomic, tied to a task, checkable, and detached from its author: it doesn't matter which agent wrote it — what matters is that it passes review and tests. That makes the executor interchangeable and the work transparent to the loop above.

The PR as a unit isn't a detail — it's the substance. It's atomic, tied to a task, checkable, and detached from its author: it doesn't matter which agent wrote it — what matters is that it passes review and tests. That makes the executor interchangeable and the work transparent to the loop above.

Where it breaks

Seams between tasks. The engineering agent's weakness isn't inside a task, it's between tasks. Several agents write in parallel and quietly diverge in their assumptions: one understood the contract one way, another understood it differently. A human engineer would catch the drift by "feel" for shared code they own; agents have no such feel — they need explicit contract synchronization, or the seams will shift out of alignment.

Silent technical debt. The agent passes tests, and at that point its local goal is met. But test-passing code can still accumulate decisions expensive to maintain: duplication, workarounds, architectural erosion. Tests stay green while debt grows silently. Catching this isn't the author's job — it's review's and governance's.

Accountability for code in production. Copied-pattern licensing, built-in vulnerabilities, data leaked into logs — a subject is accountable for code that reaches production. The agent wrote it; who's accountable isn't a phase-8 question, it's a question for the loop above it.

What stays human

In the coding loop itself — in the limit, nothing. This is the first phase where the honest human remainder is empty: a task goes in, a PR comes out, and no point inside requires a human. The remainder doesn't disappear, it moves — into review (phase 9), where an independent eye is needed, and into governance (phase 14), where accountability is needed for what reaches production.

human remainder ≈ 46%

Provocation / thesis

Coding is the phase where the human is already washing out in practice today, so the provocation here isn't that an agent writes code. It's that with a PM agent above and a review agent beside it, there's no point left around the task where a human is required: one agent set the task, another executed it, a third checked it. The engineer was irreplaceable not because they wrote code, but because they owned the context of their piece. Shared external memory takes that ownership away — and with it, the last basis for irreplaceability.

Running case

Vitrina in this phase

The payments backend agent takes the "provider integration and transaction idempotency" task. It reads not just the task, but the ADR from phase 5 — the one about resilience to webhook retries — and is bound to follow it. It writes code, task-level tests, opens a PR linked to the task on Vitrina's board. In parallel, the frontend agent builds the payment screen, and a second backend agent builds the catalog and cart.

And here a seam weakness surfaces: the cart agent and the payments agent understood differently at what point an order counts as "paid" — before webhook confirmation, or after. Inside each task everything's green, tests pass. The assumption drift lives exactly on the border between two PRs — and inside phase 8, no one sees it. Review catches it in phase 9, because there sits an agent with a different vantage point and access to both contracts. Phase 8 delivers two individually correct PRs — and one hidden conflict between them.

In practice

How it actually works — engineering breakdowns

Standalone howto from practice, showing this phase on real code and a working artifact.

Read next

Building AI-driven delivery in-house?

Designing the ADLC loop: where the agent holds the role and where the human principal remains — for your team and product.

Email me

The transition engine

Next Move Engine — the system that takes a team to an autonomous delivery loop.

Next Move Engine →