The Agent Writes the Code. Everything Around It Decides Whether You Can Trust It.

Most writing about AI-assisted development is about speed. Speed is real. It is also the least interesting part, and it is not what decides whether the result is any good. After nine months of building software almost exclusively through an AI coding agent in the terminal, my conclusion is this:

The agent writes the code. What makes the code trustworthy is everything around the agent: the structure it works in, the order of the steps, the checks it cannot talk its way past, and the knowledge that survives the end of a session.

This is the first of nine posts on agentic software development, about that “everything around”. The agent in both settings is Claude Code; the setup would carry over to any coding agent that reads an instruction file and runs commands. A note on roles, because it matters for reading what follows: the agent writes nearly all of the code. I design, decide, review, contradict, and, most importantly, decide which of the agent’s claims I believe.

Two settings, one core

The material comes from two settings that look very different. Both were measured on 17 September 2026; the numbers will drift, the date stays.

Setting A is a multi-product SaaS platform: five products on shared modules: association management, software for trades businesses, property management, an e-invoicing API and a PDF API. Backends and frontends are plugin-based; most functionality lives in shared packages that several products import. This is open product work: nobody hands you the requirements; you develop them.

Each repository is released on its own and published as an npm package. A change to a shared package often travels through ten or more repositories before a user sees it.

Setting B is an event-driven service inside a client project: it consumes messages from Kafka, keeps state in Postgres, publishes decisions back to Kafka, and serves a web UI over REST. The requirements came from outside, and the interfaces already existed. That is the opposite situation: the specification is the oracle, and tests can be derived from it before a line of code exists.

The process differs where the settings differ: the first phase of a client project is analysis of a specification; the first phase of product work is developing the requirements at all. But the core is the same in both: a structure the agent works in, a fixed order of steps, gates it cannot argue with, and knowledge that outlives the session. That is why they belong in one series.

What this series will and will not tell you

It will not tell you that an agent is fast; you know that. It is not a tool review either, and it will not compare models. It describes the setup (tools, instruction files, directories), the process (analysis, design, plan, implementation), the testing approach (tables first, tests second, code third), the automation (a pipeline that works through plans on its own), and, at length, the failure modes.

The failures are the most useful part. Every rule in the setup exists because something went wrong at least once, usually more than once: an agent that rewrote expectations until the tests passed, a request counter that reported zero while the page fired about 150 request batches a second, five bypassed test hooks despite an explicit prohibition in every brief. Each of those gets its own part, with the incident, the mechanism behind it, and the rule that followed.

The short version, in ten sentences

If you take only a few sentences from the whole series, take these. The part in brackets is where each one is worked out.

1. The agent writes the code; the structure around it makes the code trustworthy. Directories, order of steps, gates, and retained knowledge. (Parts 2 and 3)
2. A table cannot stay silent. Prose is quiet at the unclear places; a table demands a row there. Translating requirements into decision tables finds contradictions before code exists. (Part 5)
3. Design services so their function is testable without infrastructure. An agent that can check its own work after every step is excellent. One that has to guess is mediocre. (Part 6)
4. Write all tests first and prove they are red for the right reason. Then “implement the plans and use the tests” is an instruction an agent can execute well. (Parts 6 and 7)
5. Change an expectation only via its source, with a reason. Otherwise the suite becomes accommodating, with an agent exactly as with a human under pressure. (Part 8)
6. Absences are the most expensive defects. No tool reports what is missing. Test the rendered output, and ask what a user still needs to see it. (Part 8)
7. Prove the measuring instrument before believing its zero. (Part 8)
8. Precise-looking evidence gets checked least. Verify line references, timestamps, and paraphrases against the source. (Part 8)
9. What must hold needs an exit code. A rule in prose is not a control; a hook is. (Part 9)
10. Built correctly is not the same as useful. Every plan names a user job, and done means it was played through. (Part 9)

Part 4, what the next session knows, is the one without a sentence of its own: it is the mechanism behind sentence 1, the knowledge that survives.

The series

One part a week, from 29 September to 17 November 2026. The whole report is also on the site as one page: Agentic Software Development, about 9,000 words.

The tables in both settings are Nanook decision tables. If you want to see what they look like at scale before the series gets there, the field report How We Test a SaaS Application with Nanook covers the test suite of two of the platform’s products, and Testing E-Invoices for 40 Country/Format Combinations the e-invoicing rules. To build one yourself, start with the Quickstart.