Autonomous coding agents are no longer a lab experiment. At some engineering teams they already open, review, and merge a majority of pull requests without anyone reading the diff. That shift raises an uncomfortable question for anyone building with AI: if nobody is reading the code, what keeps it trustworthy? On a recent episode of The AI Native Dev, Rob Willoughby, who leads AI engineering at Tessl, walked through the internal system his team built to answer that question, and the answer he landed on has less to do with which model you choose than with context engineering.

Willoughby runs the team behind what Tessl internally calls its Dark Factory, an autonomous pipeline that picks up Linear tickets, hands them to coding agents running in isolated sandboxes, and pushes the resulting pull requests through review and merge with minimal human involvement. Around 65 to 70 percent of his team's own pull requests now move through it, and roughly 40 percent of production changes across the company do too. The rest of the conversation was less about that number and more about how a team earns the right to trust it.

What context engineering actually means here

Context engineering, in Willoughby's practical framing, is the deliberate work of shaping what an agent sees before it writes a line of code: the repository structure, the standards documents, prior decisions, and the constraints that would otherwise live only in a senior engineer's head. It differs from prompt engineering, which shapes a single request, because it aims to make an entire codebase legible to any agent that touches it, not just the one being prompted in the moment.

Willoughby was direct about where he thinks the leverage actually sits. “The context that you give will change model results more than swapping a model will,” he explained, encouraging teams to treat that as a starting point rather than a footnote. Before adopting any orchestration layer, his advice is to simply get more intentional about what lives in the repo, because that is what ultimately goes into the agent. Teams chasing the newest model release before doing that work, in his view, are optimizing the wrong variable.

Verifiers: encoding taste in a form agents can check

The mechanism Tessl built to operationalize context engineering is what the team calls verifiers: short natural-language statements that resolve to a yes or no judgment about a specific piece of code, evaluated by a single LLM call scoped to just that question. Willoughby described the philosophy behind them as a kind of triage. Anything that can be made fully deterministic, like a lint rule, should be. Anything too fuzzy for a human reviewer to reliably catch inside a busy pull request queue becomes a candidate for a verifier instead. Agentic code review, he noted, should be the catch-all for what a team has not yet identified, not the primary mechanism for judgment it already understands.

The framing is a genuinely useful mental model for anyone worried that scaling agent-driven engineering means giving up on quality. Previously, Willoughby observed, a staff engineer would enforce standards through PR reviews, presentations, or a style guide nobody quite reads. Now that judgment gets encoded once into a verifier, and every agent working in that part of the codebase inherits it automatically. The engineer's impact scales without that engineer needing to personally review more code, which is a different kind of leverage than simply working faster.

Where coding agent reliability still breaks

The most candid part of the conversation was about failure. Willoughby described a period where a queue bug caused PR comments to be double-counted, occasionally producing race conditions where two sandboxes generated conflicting commits for the same ticket. The team patched it, watched it regress, and patched it again, accumulating roughly sixty affected pull requests over a few days of what he called constant churn and frustration. The fix that finally held was building a small formal model of the queue's behavior and verifying every PR against it. He put the result plainly: “we've had absolutely zero recurrences of that after the fact.”

He also described a deliberate stress test that did not go entirely to plan. During a team offsite, the group handed their verification layer, and nothing else, to a coding agent and asked it to rebuild the entire orchestrator from scratch in Elixir, a language chosen partly for its actor model. The rebuild worked, and by Willoughby's account was idiomatic Elixir, but the exercise also surfaced blind spots: routing logic tied to Linear labels and some GitHub batching behavior had only ever been covered by unit tests, not the end-to-end suite, so it broke quietly in the new implementation. Rather than treat that as a failed experiment, Willoughby framed it as the clearest way to find gaps in a verification layer before they cost a team in production.

That comfort with visible failure seems to be doing real cultural work at Tessl. Willoughby argued that the engineer's role is shifting to look more like a mechanic's than a builder's: not writing every line personally, but understanding the system well enough to debug why it broke and improve the environment the agents operate in. For teams earlier in that journey, his suggested starting point is unglamorous but concrete: tighten the context in your repo first, layer in end-to-end and behavioral tests, and only then start experimenting with verifiers and deeper autonomy.

None of this suggests coding agents are a finished technology. It suggests the interesting engineering problem has moved up a layer, from writing code to describing, in a form both humans and agents can check, what good code is supposed to do. Whether context engineering becomes the standard term for that work or gets renamed again in six months, the underlying practice Willoughby described will likely look familiar to any team that has started letting agents merge on its behalf. What would your own verification layer catch, and where would it break first if you stress-tested it the way Tessl did?