Agents Made Code Free. Maintaining It Didn't Get Cheaper. - Dmitry Buykin, Maersk

Dmitry Buykin’s first attempt to get an AI-coded project under control earned the Thanos analogy. He deleted tests and unused boilerplate and rewrote the whole project. Some useful pieces went with it. Then the agents kept writing, and the mess grew back.

The practical limit was how much change people could check. Once the project crossed that line, even a cleanup required someone to work out, in one pass, everything that deserved to survive. Buykin’s next attempt spread that judgment over time. Small weekly sweeps would handle deletions, and people using the system would have a way to correct it while they could still inspect the task that went wrong.

Someone wants to change the amount on an order that already has approval. A coding agent helped write the instructions for handling the request. A second agent follows them in production. The system runs in 110 countries with about 10,000 scenarios described in prose. The unit of change is a slice, one process in one country. By default, a correction to the order process stays in the slice where the problem occurred.

Buykin estimated that prose made up about three quarters of the system. To find out how well the tests protected it, the team borrowed a technique from mutation testing. They deliberately broke a sentence and watched for a failing test. Almost none turned red. A coding agent could rewrite those instructions easily, but the passing tests gave little guidance about which meaning the rewrite had to preserve. Even when the wrapper around a model consists entirely of code, its agent instructions and tests still express what people intend the system to do.

Consider an instruction to check with the team. A business expert knows what decision the team makes. A developer can inspect traces and logs with a coding agent to work out how much of that step the connected systems can perform. For the order change, the team lead kept the decision. The developers could connect the data for the limit, and they had their coding agents record those connections so the runtime could check them.

One document serves both readers. Agents read precisely specified blocks. Experts read the surrounding explanation, including a plain description of what the code does, and sign off. Keeping one copy avoids having to reconcile two accounts of the same rule. When a task goes wrong, an expert reviews it with the information the production agent saw. The expert’s note gives the coding agent a change to make, and the original task gives it a case to run again. A group of experts participates from the start because no one person knows all the rules.

The team records whether each production outcome was accepted or rejected and uses that history to direct expert attention. How could the same order be acceptable in one place and too large in another? The prose set the limit at 1,500. The code applied a different limit. Each could apply its own rule successfully, so the disagreement raised no error.

Wording can change behavior in subtler ways, too. An instruction forbidding a particular tool call tells the model that the tool exists. The team built a linter for prose and had authors lint each changed file and record the result in a ledger. Two copies of a rule could still drift apart, so the team also watched what Buykin calls a walk, the path an agent actually takes through the instructions.

When agents kept taking the same path, the team packaged its steps into one workflow tool. The first tools made things worse. The prose still named the steps inside the tool, so agents ran those steps again after the workflow had performed them. Removing the step-by-step prose and leaving the decisions fixed the duplication. The team now moves a walk into code when it repeats and agrees across countries. A path that still varies stays in prose.

Who makes the decision inside a workflow? Code prepares the facts. Experts own a decision table describing the allowed choices. The model picks a matching row, and code carries out the decision. If no row fits, a person takes over. That handoff gives the team a way to handle a new case without asking the model to invent a rule. Connecting many small model decisions through workflows was a proposed next step.

Some rules moved the other way. The team took hundreds of lines of expressions out of code and put them into prose because the experts responsible for the decisions couldn’t read their implementation. A regular expression could still spot a critical signal, and a growing collection of such patterns could live in configuration. Where the answer varied, the person who understood the rule needed to be able to read and correct it.

Given a choice of what to load, the model loaded everything. It saw prices and invented a pricing check. Nobody had asked for one. The team moved context selection into the runtime. For the order change, the runtime supplied three facts from the order and kept the full record itself. With fewer irrelevant facts to act on, the model made fewer wrong moves.

For a larger set of data, the model passes a handle, a short name for data the runtime already holds. The model can refer to the set without carrying the whole set in its context. The runtime checks the context for consistency and validates the handle before a write. Giving the model enough information to choose a row and allowing it to change an order are separate engineering decisions.

What happens if a write succeeds but looks like a failure to the agent? The team checks changes during development, and only code can open the write path at runtime. Buykin counts five checks before the write and a sixth to establish whether it landed. An apparent failure can prompt the agent to retry. A journal ensures the action takes effect only once. Keeping that protection in code lets the team revise the prose many times a day.

Buykin initially read every change. That was how the system picked up his habits, and how he became the person every change waited on. Eventually the volume outgrew what he could read. He was burning out. His earliest warning came when he was tired and couldn’t explain what had changed. The dashboard could stay green through all of that. He took the loss of his ability to explain a change as reason to stop and fix the review process.

One way to direct scarce attention was to estimate the reach of a change before making it. Before building a proposed check, the team replayed its rule over several thousand past sessions. It would have fired on less than 1% of them. That figure measured how much past traffic the check would have touched. Judging whether it was right for the affected sessions still took case review. Buykin watched for jumps in the numbers to tell him where to read.

The team waits for an isolated signal to recur, even when an expert raised it. A cluster across slices warrants investigating the rule they share. Otherwise a coding agent can keep adding conditions until today’s examples pass. Removing those conditions can lower the eval score. The failures that reappear give the team a list of cases its rules still need to handle.

An expert’s note about a failing task becomes an eval, a case that checks for that failure. An agent then searches sibling slices for the same behavior. The search can be broad because it gathers evidence. The edit stays narrow because markets and local laws differ on purpose. Only siblings where the failure is confirmed receive the fix.

With 10 to 20 feedback loops open at a time, Buykin had become the message bus between users and agents. Giving each user a screen to evaluate a task removed a handoff. Each loop writes to a ledger, so an investigation can continue without waiting for the architect to relay a comment or remember an unfinished case.

Agent sessions end, too. The team keeps two kinds of memory in files.

• What happened. The history preserves events such as an issue being reported and investigated.
• What is true now. The current account gives the next session its starting point, including what the investigation established.

Each issue needs evidence connecting it to its root cause. Without that link, the next agent can act on a mistaken explanation, and a check has nothing concrete to count when it looks for the problem again.

Checking took almost nine tenths of the agent’s time on a change and a growing share of Buykin’s own week. The team ranked replay on real tasks as its strongest evidence. Before seeing the results, they wrote down what would prove their expectation wrong. They also made each new check fail once on purpose, to establish that it could detect the failure it was meant to catch.

What became of the team lead’s approval after a refactor? Every condition and every decision-table row represents a branch. The team wanted to account for each old branch exactly once in the new implementation. The branch for amounts over the limit had disappeared. The order would have gone through without the team lead.

To compare behavior, the team freezes a set of real tasks and runs the old and new versions against the same inputs. For an over-limit order, the outcome to compare is whether the request still reaches the team lead. If none of the frozen tasks takes a particular branch, the team records that branch as having no evidence. Agreement on the rest of the set cannot establish what happens there.

A second agent reviews the change with a checklist. It works without the authoring agent’s reasoning, so the author’s explanation cannot steer it toward agreement. Over six months this independent review grew to cover most of Buykin’s checking. Batch completion still needed its own accounting. Agents sometimes finished most of a batch and quietly skipped the remainder, especially when their context was full. In one backlog, most items looked covered. The ledger showed that only about a quarter had enough evidence to close.

What became of the variants of one process over a year? Some branches merged back together. Others continued to diverge, and some dead branches still looked alive. The history of a split or a merger could explain how a variant got there. Deciding whether to keep it took evidence from actual tasks.

The team introduced gauges for regrowth. A ratchet puts a ceiling on a tracked count. Once the team lowers the count, it cannot rise again. Two gauges were running at the time of the talk, with six more planned. Each week the team identifies behavior that no real task reaches and records the name and evidence for each candidate before removing it. That record is what Buykin lacked during the original rewrite.

A test could keep a dead variant alive. As long as a test mentioned an option, coding agents treated it as behavior they had to preserve. Now the test goes with the variant when the team retires it. With these small weekly removals, Buykin had yet to need another wholesale rewrite.

After the system went into production, Buykin recognized his own engineering principles in its design. Its skills and memory carried his biases along with his habits. He put a personal twist on Conway’s observation about systems reflecting the organizations that build them. This system reflected whoever corrected it. Involving other experts changed whose judgment the next session would inherit.

Which question would your repository struggle to answer? Buykin closes with three for each of his six Thanos stones. Time asks how much change people can check. Space asks where a change may spread. Reality asks what evidence establishes that a rule or change is correct. Mind asks what the model sees. Power asks what can actually change the system. Soul asks who supplies judgment and what it costs them. 18 repository-audit questions

Buykin was already burning out when he learned to work this way. His advice to the person a team’s changes are waiting on is to pick one question the repository can’t answer yet and start there, while you can still read every change.