Inside Termondt Tech
Built isn't done: what happens to the sprint when an AI agent writes the code
When I first brought Agile to a development team I was leading, it shipped three big releases a year. The business put in every request it had for a release, and then it waited. Nobody could tell them where an individual item stood. Often it was days before the release that they found out something they really needed hadn't made it.
So we sat down with the business and broke the work into smaller units, and we prioritized them again every sprint. They could see what had been built, what was left, and what was rolling to the next sprint, and they had a place at the table to tune the backlog to what customers needed. They became the method's most vocal advocates.
This year I ran a project where the engineer writing the code forgot the whole project every night. I directed Claude Code to build Argus, a platform for fully automated trading strategies, and wrote none of the code myself. Part one of this series tells how it was built, and part two how its research was kept honest. This one is about the process. After fourteen weeks I think AI coding agents can bring back exactly the problem that business had, in a place most teams aren't watching yet.
What Agile bought us
Earlier in my career, my development team agreed to run Scrum when no other team at the company formally did. We thought it beat the way we'd been building software, and we thought that doing it well, where other teams could see our output, would make the case better than any presentation. QA and the business analysts asked to be brought into our process. I followed the same pattern at every company after that: one team adopts the method, its output shows the value, and the people around it ask to join.
What they were asking for was three things. Predictability: everyone knew which units were in the sprint, which were done and which were rolling to the next one, instead of finding out at the end of a release. Transparency: the business sat in sprint planning and backlog grooming, and at one company they came to standups too. Quality: QA tested and signed off inside the sprint, so done meant tested, not handed over.
The ceremonies were never the point. Each one existed to keep those three things true for a team of people, and every one of them rested on two assumptions nobody had to say out loud.
Two assumptions the agent breaks
The first is that the people building the software remember the project. In 2012 I wrote a post on development process that included a rule for requirements: when an open question gets resolved, keep a written record of the answer. "Verbal resolution is usually not good enough. You want proof that this was the resolution as it could be forgotten. I've seen this happen hours before a production release."
With people, forgetting is a risk you manage. With an agent it's certain. Every session starts new, and whatever we agreed yesterday is gone unless a file says it. On Argus the documentation became the control system: a rules file read at the start of every session, 741 lines by October, and 87 decision records that every future session was told to read before touching the component each one covers. Standups, grooming and the conversation at someone's desk all assume a memory the agent doesn't have.
The second assumption is that building is the expensive part. Story points measure it, and sprint planning is sized by it. With an agent, building is the cheap part. I spent about 420 hours on Argus over fourteen weeks, and most of them went to prompts, reviews and operating, not to waiting for code.
Two more things change with an agent. It does the next step early. The notes that govern its sessions say it plainly: "the most common way for a session to go wrong is to do the next step early." Ask for a design and, unless something stops it, you get the code as well. And the agent and I each held half of what we needed to know, and neither of us offered our half. We wrote a retrospective in September on a requirement I had missed, and one of its root causes reads: "The human held the environmental context (what's in the real account) that would have flagged it; the model held the architectural view (this assumption is load-bearing in five places) that would have made it worth raising. Neither surfaced it to the other."
Built isn't done
Put those together and a familiar problem shows up in a new place. An agent builds a unit of work in hours, so the board fills up fast. But built isn't done. Done still means reviewed, signed off and tested, and those are human steps. If a team plans its sprint the old way, by how much it can build, unreviewed agent output piles up in a column the business can't read. The business is back to learning late what will actually ship. It's the end-of-release surprise from waterfall, with the hidden phase moved from development to review.
Slowing the agent down doesn't fix it. Translating the three things Agile bought does.
- Predictability means making review and sign-off the planned, visible part of the board, and planning against the people who review and sign rather than against what the agent can build.
- Transparency means giving the business and QA their seat where the decisions are now made: in the decisions a design asks someone to sign, and in what the build has to prove, both settled before the agent writes a line.
- Quality means done still means tested, against checks written before the build rather than added after it.
How Argus ran without a sprint
Argus had no sprints, no tickets and no tracker. It had one person deciding, one agent building, and 51 tagged releases in fourteen weeks. What it did have was a written process, and in late September the agent turned that process into twelve prompt templates, one for each kind of work: an investigation, a business spec, a design, a build, a code review, a release, and a few more. They're public on GitHub, along with the task prompts, the designs, the decision records and that retrospective.
The lifecycle they describe is the development process I ran with teams for years, rewritten for an engineer who forgets.
Something happens, or something is wanted, or a question needs data, and a session writes it up without touching the code. A design session writes a design and is forbidden to change code, tests or configuration. I sign off on its numbered decisions, amend them, or send it back. A build session implements "exactly what was approved," and if the code shows the design was wrong, it stops and proposes an amendment instead of improvising. A code review runs in a fresh session, a reviewer that didn't write the code, against a checklist of thirteen kinds of defect the codebase had already paid for. A release session writes the notes, including what the release does not do and what to check after deploying it. Then I tag and deploy, by hand.
Two rules in the templates' README do most of the work. One is "One template per session. A design session that also builds loses the review gap between them, and that gap is what catches the defects." The other is that every prompt states what its session is allowed to change, because of the next-step-early problem. The README is also plain about where I come in: "The templates stop at the points that are yours: sign-off on a design's decisions, approval of config values, the tag and the deploy."
The sign-offs weren't a formality. One design was approved with three amendments, each of which changed its shape rather than a number. Another went through four revisions, and the design records why the second one died: "Richard's review rejected it, and the review was right."
The agent decides and reviews, too
It's easy to describe AI coding as the agent building while the human decides and reviews. That isn't what happened on Argus, and the difference matters for a team.
The agent did most of the work of deciding. Its designs named the alternatives it rejected and why, laid out the evidence, made a recommendation and ended with numbered decisions. When it drafted the plan for the research program in part two, I could answer "yes to all" to eight items, because the work behind each one was already on the page. It did most of the work of reviewing as well. Code reviews ran as agent sessions with the checklist, and one proactive pass, hunting for new instances of defects we'd already paid for, produced a release of eleven fixes.
In part one I wrote that none of the serious defects surfaced because the agent noticed on its own while building. That's still true. But the same model found them when it was given the reviewer's job, in a separate session, with a checklist. For a manager that changes the arithmetic. Review capacity stops being a fixed number of senior engineers. You create more of it by separating the job.
What stays human is the judgment. The context the agent can't see, like what was really in the brokerage account. The policy calls. The order of the question: on October 2 I had a research plan rewritten so the goal, profit after costs, came before the forecast, and two things of substance in the test changed with it. Choosing what gets reviewed. And the name on the sign-off.
Faster deciding and reviewing also open three new ways to fail, and with a team I'd guard each one.
- Test the reviewer before you trust it. Plant defects from the checklist and see whether the review session catches them. The research engine in part two had to reproduce a known answer before it was trusted with a new question, and a reviewer should pass the same kind of gate.
- Watch the amend rate. I amended designs and rejected one outright. A signer who accepts every recommendation for a month is either reading perfect briefs or rubber-stamping, and the number tells you which one to look into.
- Argue the other side when it matters. A recommendation anchors whoever reads it. For anything that can cost money, have a fresh session make the best case for the strongest alternative the design rejected, before anyone signs.
The sprint, rebuilt
Here's how I'd translate the ceremonies for a team. None of this has been run with a team yet. It's where I'd start.
| Ceremony | What it was for | With an agent |
|---|---|---|
| Backlog grooming | A shared understanding of the why, in small units | A work prompt that the business and a signer have edited, naming the records the session must read and what it may change. Plus ten minutes on assumptions: the agent lists what its design leans on, and the business says what's actually true |
| Sprint planning | Commit to what the team can build | Plan against what the team can review and sign. Size the work by the decisions it needs, not the code it takes |
| Daily standup | Share state and blockers | The agent writes the status from the board. The people spend the fifteen minutes on what has to be decided today to keep the work moving |
| The sprint | Build what was committed | Design, build and review in separate sessions, each with what it may change stated |
| Sprint review | Show working software | Evidence from the running system, and a release note that says what the release doesn't do |
| Retrospective | Improve how the team works | Changes to the rules file and templates, reviewed like code, and where money is at stake, a test or a lock |
On cadence, my first instinct was a one-week sprint. I think that's right for the people and wrong for the work, and with an agent the two can finally be separated. The sprint used to bundle six jobs: a commitment horizon, the business's seat for reprioritizing, QA's sign-off window, the demo, the retro and the release. An agent pulls them apart.
I'd keep a fixed weekly heartbeat for the people: priorities with the business, the week's sign-offs, and a retro on the rule changes. Fixed, because predictability for the business includes knowing when their seat comes up. Design decisions would flow as the agent's briefs arrive, which is how I signed them on Argus. And the amount of unfinished work would govern the flow in between, with two triggers. When unreviewed output passes a limit, or the oldest item gets too old, new agent work stops starting, while reviews and fixes carry on. That's the Argus kill switch applied to the process: it stops new entries and leaves the exits working. When the queue of signed, ready work runs low, an extra decision session gets called before the agents sit idle.
The process is a system someone has to be able to stop
Termondt Tech builds automated systems that a human can monitor and stop. An agent-driven development process is one of those systems, and I'd hold it to the same rails I held Argus to.
| Argus rail | In the development process |
|---|---|
| A kill switch that stops new entries and leaves exits working | The first trigger above: stop starting new work, keep reviewing and fixing |
| Reconcile against the broker before anything resumes | Before each cycle, a fresh session checks the decision records against the code and production, and a mismatch stops the cycle until a person resolves it |
| One place in the code that can send an order | One path to production, pinned by a test |
| A hash-chained audit log | A tamper-evident record of prompts, sign-offs and deploys |
| A daily loss breaker, latched per trading date | A breaker on defects that reach production, latched per cycle, so starting a new sprint doesn't reset it |
| Shadow, then sandbox, then live at minimum size | Agent-built logic runs beside the old path before it replaces it |
There's one more test I'd add, and it puts the agent's worst habit to work. In that 2012 post I described building every release twice, the second time from a clean checkout of the label, so nothing in the release could be living only on a developer's machine. The agent's forgetting makes the same check possible for knowledge. Delete a module on a branch, have a fresh session rebuild it from the rules, designs and decision records alone, and run the tests that pin its invariants. Wherever the rebuild goes wrong, something the team knows was never written down.
How I'd bring it to a team
Not as a framework. With every company and team I brought Agile to, I looked for the right mix for them rather than arriving with "this is how we do it." A process that worked somewhere else, imposed on a team that had no say in it, doesn't take. A team that helps shape its process owns it. What gave teams that ownership more than anything else was the retrospective in the early weeks, held consistently, with everyone in it, in the open, and followed up.
That still holds with agents, with one line drawn clearly. Some rules aren't the team's to vote on: the hard lines around money, safety and regulation, set by whoever is accountable for the system. On Argus they were in the spec on the first day, before anything had broken. Everything around them belongs to the team: the cadence, the templates, the checklist, the shape of the board. The Argus templates say it about themselves: "These are meant to evolve."
I'd start where I always have, with one team. It runs the process, its output makes the case, and the people around it ask to join. I'd expect the first to ask to be the same people who asked before, the business and QA, because the decisions are where they get their seat now. In a trading firm I'd add risk and compliance. FINRA's 2026 oversight report already lists formal review and approval of generative AI uses, "including both business and technology experts," among the practices it looks for, along with keeping prompt and output logs.
The honest limit is the size of the evidence. Argus was one person and one agent, for fourteen weeks, on a new system. My years with teams are long, but they ended before coding agents arrived. The team version in this piece is what I'd start with, not something I've proven. The way to find out is the way part two found out whether a strategy paid: a team runs it, with what success and failure look like written down before the first week, and the result gets reported either way.
What I would tell a team lead
If your team is about to let an AI agent write most of its code, these are the changes I'd start with.
- Plan against review, not against build. The agent will build more than your people can check. A sprint sized by what can be built turns into a pile of work nobody can call done.
- Keep the business at the table, where the decisions are now. They used to get their seat in grooming and planning. Now it's in the decisions a design asks someone to sign and in what the build has to prove.
- One kind of work per session, and say what it may change. A design session that also builds skips the review it was supposed to get.
- Review in a session that didn't write the code, against the defects you've already paid for. Keep that list, and add to it every time you pay for a new one.
- Test your reviewer and watch your signers. Plant known defects for the first. Watch the amend rate for the second.
- Let unfinished work set the pace. Keep the weekly heartbeat for people. When unreviewed work passes its limit, stop starting new work.
- Draw the hard lines yourself, and give the team the rest. The rules about money, safety and regulation are yours. The rituals around them are theirs, and the early retrospectives are where they make them their own.
What is next
If your team is putting AI-written code into production, I run a two-week Rails Review. I read your agents' prompts, their output and your tests, and hand back the written rules and the tests that pin your invariants. Use the contact form.
Rich Termondt has been building software since 1998, including fourteen years of trading infrastructure: an exchange's order-entry and market-maker gateways, then market-connectivity, FPGA and DevOps teams at a trading firm. At Termondt Tech he now guides AI agents to build fully automated systems that a human can monitor and stop; Argus was written by Claude Code under his direction and review.