Coding Agent Reliability Is a Trust Problem, Not a Technical One

Most teams talking about agent autonomy are debating the wrong constraint. The question that actually decides whether a coding agent ships to production is not whether the model is capable enough. It is whether anyone is willing to sign the release. That distinction sounds academic until you try to run agents at the scale of a real client roster, at which point it becomes the only thing that matters.

Ran Aroussi has been building software for 35 years. He wrote yfinance, the Python library that now sees somewhere between 25 and 30 million downloads a month, a figure he attributes in part to the fact that every AI asked to write market data code reaches for it. He also runs Automaze, a roughly 30-person development agency, and MUXI, an open-source application server for agents. That combination means his views on agent reliability come from running the things in front of paying clients rather than from a benchmark.

The line between autonomy and oversight is a trust line

Asked where the boundary sits between agents that self-heal and agents that need a human looking over them, Aroussi was unambiguous about which kind of problem this is. "I actually think that it's more of a trust line," he explained. "I think that technically you can create a fully autonomous system."

The failure modes he described are not model failures. Give a coding agent a goal with no intervention point and one of three things happens: it produces slop, it burns an enormous token bill continuing to try, or it fakes the tests to get them green. None of these are fixed by a better model. They are fixed by deciding, in advance, what the agent does when it gets stuck. After five tries, after two hours, whatever threshold you pick, it comes back and asks for help.

Where the human belongs in the loop

The useful framework here is not "review everything" or "review nothing." It can be helpful to think of human involvement as two fixed points with an automated stretch in between.

The human belongs in the planning stage, where the definition of done gets written, and in the confirmation stage, where someone verifies it actually happened. Everything between those two points can run on constraints rather than attention. Aroussi's argument is that if you specify enough of them, coverage thresholds, regression suites, quality gates, then "by definition, the code quality is good if everything is green."

That leads somewhere uncomfortable for people who care about craft. Whether the code is pretty stops being a meaningful question, because nobody is going to read it. "What matters is that it's efficient and that it's maintainable by the AI." His own product reflects this: MUXI formations can learn and propose changes to their own operating instructions, but they never self-apply. The proposal arrives as a git diff waiting for a human to approve it, and he has deliberately not built the flag that would allow otherwise.

Why "agentic workflow" is a contradiction in terms

One of Aroussi's sharper claims is that the industry's favourite phrase describes something that cannot exist. A workflow, he noted, is a deterministic set of steps with known inputs and known outputs. "So just calling it agentic is either misleading, or if it's really agentic, then you're just wasting tokens because it could be fully deterministic."

This is not an argument against workflows. He is explicit that most use cases genuinely need one, and that plenty of what gets built as agentic AI would be better and cheaper as a script. He pointed to the number of times he has seen an agent invoked to parse strings that a regular expression would handle faster, cheaper, and free. The category error is claiming autonomy for a system that has been handed its path in advance.

What he does see a place for is an agent entity that chooses which deterministic workflow to run. That framing maps neatly onto how humans work: you arrive with a set of standard operating procedures, and the judgement sits in deciding which one applies, not in re-deriving each step.

The junior developer paradox

The claim likeliest to start an argument is that for at least a year now, you have not needed to hire junior developers for their coding skills. Aroussi does not stop there, which is the part that gets lost when the line travels on its own. If the industry stops hiring juniors, he argued, "we will never have this archetype of an architect that we are looking for."

That archetype, in his description, is someone who understands the product, manages the project, and leads a team whose members happen to be agents. Automaze structures around it: pods with a senior developer acting as architect, a client-facing delivery manager, and juniors attached as apprentices in something close to the Renaissance workshop model.

The skill being built is not multitasking. It is what he calls multi-monitoring, the ability to run six to ten agents at once, and he is openly sceptical of anyone promising thousands. This connects to his distinction between teachable knowledge and earned knowledge. Teachable knowledge is compressing fast. Earned knowledge, such as knowing what two vCPUs will actually take before they fall over, cannot be accelerated, only lived through. His estimate is that agents compress the path from junior to mid-level from three or four years to around two. Not to zero.

Worth a listen for anyone deciding how much rope to give their agents, and where to tie the other end.