The Fork in the Toolchain: How Agents Are Splitting Developer Tooling in Two

Nobody decided to stop reviewing compiler output. It happened because the surrounding infrastructure made review unnecessary. Whether you code in Rust or Go, the toolchain produces a binary, and nobody opens that binary to check the assembly before shipping because the confidence has been baked into the process. Trust now lives in type systems that constrain what the output can do, in test suites that verify observable behavior, in production monitoring built to catch failures before they spread. The process became the guarantee. That is the exact structure that's missing for coding agents, and its absence is what's driving the anxiety about AI-generated code. Volume output is getting the most attention because it's the most immediate problem, as no team can manually review everything agents produce. But the real friction is that agent-generated code is being treated the way we once treated junior developer output, as something that needs sign-off from a higher authority before it becomes real. The tools were always designed for the human author. As agents take on more of the authorship, that design assumption is starting to crack, and the engineering community is not yet sure what to replace it with. The assumption baked into every tool we use If agents are becoming a primary author of code, should the tools and languages those agents use still be optimized for humans? Every significant decision in programming language design over the past fifty years has been a decision about legibility. Assembly gave way to C because humans could reason about C. Abstraction layers accumulated because they made programs easier to hold in a person's head. Python's indentation rules exist not because whitespace is technically necessary but because enforcing it as syntax keeps code readable to humans by default. The TIOBE index, the most cited measure of language popularity, doesn't track technical performance. It tracks what engineers find intuitive and pleasant to work with. For the entire history of the field, writing code and reading code were performed by the same person. The tools built around those languages made the same assumptions about authorship. Error messages were written for the person staring at a terminal, CLI outputs formatted for quick scanning, and type systems kept loose so authors could move fast without being slowed down by the language itself. The reader was always assumed to be human, and everything was shaped accordingly. That held true for as long as humans were the only ones writing the code. What agents actually need from their tools The past fifty years of programming tool design share a common thread, one we might call the readability era. Every tool decision in that era was built around the assumption that the author was human. Yet the forgiving type semantics, terse errors, and prose-like syntax that made tools feel natural to human authors are solutions to a problem agents don't have. Agents aren't reading for comprehension and aren't getting frustrated with verbosity. Optimization for agents runs in the opposite direction. While a strict type system slows things down for humans, for agents it is the most helpful tool available because it is the most descriptive. This logic extends to every other design decision too. Long, unambiguous outputs that leave nothing to interpretation are easier for an agent to parse than short, clever ones designed for a developer who can fill in gaps from context. The design features that were pushed aside for a better developer experience are exactly what agent-native tooling should be optimizing for. The problem is that shifting to those features requires asking engineers to give up tools that feel good to use, and that is never a straightforward task. When scale makes comfortable tools the wrong tools Julien Verlaguet, who later founded SkipLabs, led the team at Facebook that built Hack to replace PHP. The engineering problem was straightforward: PHP's type-unsafety had become an active liability at scale. Confident refactoring was impossible. Whole categories of bugs couldn't be caught statically. The language had been built for speed of authorship by individual developers and had no answer for the discipline that hundreds of millions of lines across thousands of engineers required. What they built in response was deliberately worse to write in. Hack demanded precision where PHP had been forgiving, verbosity where PHP had been terse, explicit type annotations where PHP had let things slide. The individual developer experience got harder in exchange for properties that prioritized system scale. Eventually the org required the switch and made staying on PHP progressively harder until compliance became the path of least resistance. The resistance made sense. Hack was worse to write by every measure that had ever been used to evaluate writing code. That was not a flaw in the design. It was the design. The pedantry that felt like friction at the individual level was what made the system work. It was not a comfortable transition, but comfort was exactly what had been dragging the codebase down. The same pressure is building around agent-native tooling, and the tools the industry defaults to because humans find them comfortable are becoming the wrong ones. That’s why we are building Skipper —to apply that same infrastructure-first discipline to AI-generated software, shifting the focus from human-readable code reviews to automated, closed-loop execution environments. The same pressure is building around agent-native tooling, and the tools the industry defaults to because humans find them comfortable are becoming the wrong ones. Scale always wins Scale won at Facebook and it will win here too. The divergence between human-native and agent-native tooling is real and probably permanent, and the gap between where tools are today and where they need to be is already costing teams capability. The first movers are already building in this direction, treating agent-native tooling as a distinct engineering discipline rather than an extension of what already exists. The readability era didn't fail. It finished, and the tools that come next will be written for the authors who are doing most of the work. \