gonzo_ML author: In his team, only models write code; people review it

Stories about “switching to agents” usually end with a polished presentation. This one includes a timeline, numbers, and an honest account of what did not work. The author of the gonzo_ML channel explains how, from 2024 to 2026, he went from “models occasionally complete some code” to “nobody on the team codes by hand.”

The threshold models crossed

The author’s first completed projects arrived around the turn of 2024 and 2025. He believes the models crossed a threshold—not that he suddenly became bolder. In January 2025, Gemini and Claude assembled the transformer, intervention, and activation-visualization code for his interpretability course project. In the spring, he built an MCP server for translations without, as a matter of principle, typing a single line by hand. By December, he had converted it to Streamable HTTP and brought it to production. As usual, the production work proved larger than the feature itself: logging, monitoring, security, load handling, error handling, and deployment added more code than the new transport.

The working approach became: specifications with task decomposition, tests before implementation, and ADRs for accepted decisions. It all began with speckit; the team now lives by these practices in Claude Code, no longer as a solo effort.

Why brownfield failed—and then worked

In 2025, the author tried giving models a decade-old platform codebase. Bug fixes and small features came out “wrong.” He blamed brownfield development. It later became clear that the real issue was elsewhere: the context lived in people’s heads, not where an agent could retrieve it.

The team therefore focused on foundations. Models were given access to documentation in repositories and, through MCP, to Confluence; standards and ADRs; tasks—first in Jira, then in Linear; production logs through MCP; and, when necessary, Slack conversations. In other words, everything a new person joining the project would need. People now assign tasks and review, while agents also handle the initial review, documentation, release documents, and tests. A person enters the process at approval-based quality gates.

The bottleneck moved. Writing code no longer takes long, but the final human reading stage is under strain. Everyone keeps several agent sessions running: while one agent writes, another session can be used to read the latest sprawling diffs.

Language shopping and Rust

An unexpected effect is that the language can be chosen for the task rather than around the team’s existing expertise. The first candidate was a service that emulated real APIs, complete with all their problems, and had become the limiting factor in performance tests. It was rewritten in Rust and, for comparison, in Go and Node, with parity tests covering all four implementations.

In the same 100 MB pod, Rust maintains about 8,900 open connections, versus roughly 3,400 for the Python original. At idle, it uses 1 MiB instead of 33. Go with fasthttp performed only 11% better than Python, while the standard net/http version was twice as bad. The author adds a caveat: these figures come from a local test bench, and under a manual-development model, nobody would have allocated even a week to such a rewrite of an auxiliary service.

More than code

A separate example is an accounting report. The author previously rechecked the accountants’ work every year and found mistakes. This year, Claude did it in one evening. It found errors the author had not thought to challenge, citing laws and interpretations; the author verified the references, and everything checked out. It also found an incorrect calculation from the previous year that had increased the tax bill, as well as a missed refund for the current year. The quality gate moved: the model now checks both the accountants and the author himself.

Limitations and conclusion

This is one person’s experience, without independent measurements. The Rust benchmark is local, and the tax case is a single example, although the author manually verified the references. The circumstances are also unusual: the company is deliberately reorganizing around an AI-first model.

The practical takeaway for teams: if an agent produces the “wrong” result, first check where the context lives. Put documentation, ADRs, tasks, and logs into repositories and MCP; write specifications and tests before implementation. And prepare the review process in advance, because that is precisely where the bottleneck will emerge.