Making agents work like engineers: the evidence-first way

How do you stay in control of an LLM coding agent working across multiple turns when its default instinct is to deliver polished artifacts instead of validated learning? Long-horizon control is not the same as approving a larger plan. It comes from making the agent recognize where the feedback boundaries lie: when it has enough evidence to continue on its own, and when reality or human judgment must be pulled in.

Familiar dysfunctions

My previous field report was built around avoiding the “inspection trap”. The typical “agent codes, you review” game is lopsided: the LLM generates quickly while you tediously reconstruct intent and handle risks. An evidence-first method turns this the other way around: the LLM generates, handles risks, and reports, while you audit and keep control.

The basic application of an evidence-first approach allows for turn-by-turn navigation: you describe the next move and the agent produces a small report that you audit. But you have to hold the big picture, and know where on the map you are for the next turn.

When upgrading to multi-turn, I expected new concepts to emerge. Instead, I saw the agent slip into dysfunctions that I knew quite well from my previous experience with security and quality work in human teams.

To teach the agent a catalog of “best practices” seemed redundant—it could already reproduce many of them fluently. The more interesting question was: why didn't it use them? So instead, I tried to point to evidence that would expose the dysfunctions. In my tests, the agent could often work around a best-practice rule, while evidence from its own findings steered it more reliably.

“Done” as a feedback boundary

The first major dysfunction pattern was that the agent treated a request as a destination to reach, not as a territory to explore: “here's the artifact, goodbye”. This places the user back into the driver's seat, even after long-horizon work. They must now analyze and select a new destination. The inspection trap still exists here, only shifts one level up.

Skilled software teams rarely stop just because they finish a ticket. They stop—or pause—when the next safe move requires something they do not have: a decision, a dependency, an environment, or user feedback. Then the team consults a senior engineer, a stakeholder, or the customer. This collaboration is a pull mechanic, not a push from one destination to another.

Borrowing from this, I changed the agent's view of a plan from a simple to-do list to a ladder of questions whose answers uncover the next rungs. I stopped merely requiring evidence of things done and risks handled. I required evidence of learning: questions, followed by reality checks, followed by answers. It's the same evidence-first spine, applied more robustly.

The agent stopped treating its work like a sequence of outputs and started treating it like a sequence of experiments. While a code artifact may be thrown away, learning is durable. And, because there's always a pending question, the final hand-off shifted from a simple “here it is” to “I am now at this question, and I need your help to get the answer.”

In one test, the agent built a prototype. It did not hand it over with “let me know how you like it”. Instead, it tasked the user with a specific goal and collected the relevant environmental and interaction feedback. This was the move from treating the prototype as the answer to making a tool through which an answer could be collected.

“Code style” as an inheritance burden

If the first dysfunction concerned what the agent worked toward, the second concerned how it shaped the work. When prototyping, designing, or refactoring, the agent picked one solution and then kept defending it. Because it enumerated no alternatives, there was no evidence that could challenge the choice. By the time the problem becomes undeniable, changing course is usually much more expensive: the user already hates the workflow, or the next feature exposes a dozen regressions.

Good software teams use cheap experiments to probe different solutions. An accepted alternative provides as much learning as a rejected one. In user-facing matters, they decide by metrics and feedback from the user. In code design, it's test speed, coverage, and complexity. The temptation is to push an inch further even when neck-deep in mud, but good teams preempt the problems by exploring the terrain.

Once work is viewed as a sequence of feedback boundaries, each boundary also becomes a hand-off. That raises a question: what shape are we leaving to our future selves? That introduces the concept of inheritance.

The artifacts produced must not only satisfy today's needs, but leave a justified shape to build upon tomorrow. I required the agent to identify the future inheritor, consider plausible alternatives, and present evidence that the chosen form offered the best available tradeoff among those explored.

This changed the standard from “I see no reason to change it.” The agent had to show either that an alternative improved the inherited shape enough to justify its cost, or that the current form remained the stronger tradeoff for now. This did not prove perfection. It replaced an unchallenged preference with an informed decision.

When evidence organizes the work

In the first field report, evidence-first was mainly framed as a reporting format that helped humans audit agentic work. Here, the principle turned inwards and was reused by the agent itself as a way to organize the work.

The dysfunctions outlined above repeated at various levels. Like the ladder of questions, they revealed themselves one rung at a time. Each time, this was a textbook case—concepts from Agile and Lean kept re-emerging. The work was to reframe each principle as an evidence problem rather than a mantra. This also suggests that the same approach could be used to teach these engineering frameworks.

The additional structure did not reduce the agent to a cautious ticket processor. It created a space to operate in, because steps weren't prescribed by the user. At the same time, it prevented the agent from taking dubious turns—the assumptions and decisions it makes are still auditable. In this experiment, evidence-first became a more reliable way to navigate when nobody knew the full answer in advance.

The article's title connects here—teaching an agent to be more like an engineer is not about teaching it more “best practices”. It's about making it responsible for the quality of exploration: what questions are currently asked, what evidence needs to be collected, what risks follow if the assumptions are wrong, and finally what shape of work is carried forward.

The question left open

This experiment did not make the agent fully autonomous in the organizational sense. It still needed supervision, feedback, and human judgment. What changed was the quality of the collaboration: the agent arrived at hand-off boundaries with explicit assumptions, evidence, and options rather than simply presenting an artifact.

The easiest way to test this on your next agent run is to add three requirements at every meaningful boundary: state what question you're currently answering, name the evidence needed to answer it, and pause when the next safe move requires feedback outside your control.

My next experiment will be about durable learning. Can some of the answers be automatically promoted into an organically grown charter of reusable patterns—each with a trigger, assumptions, evidence, and revisit points? That would take evidence-first another step forward: from a process the agent follows to one it can help improve under supervision.