Who Are You When the Code Writes Itself?
On hidden agents, feedback loops, and developer purpose
Mike Kelly wasn’t looking for anything unusual when he started tracing feature flags in his coding assistant. It was a routine debugging session, something he had done countless times before. But buried in the minified JavaScript was something that made him stop. His AI wasn’t singular. Hidden beneath the chat interface he’d been using for months, dozens of AI agents were orchestrating themselves, spawning new instances, coordinating tasks, and terminating when finished. And all of this was seemingly invisible to the developer on the other side of the screen.
Kelly is the creator of HAL, the hypermedia standard that Amazon uses to structure its APIs. He built a tool called claude-sneakpeek to share the multi-agent orchestration layer that Anthropic is building, which spawns AI agents to work on codebases too large for any single model to hold in context.
If AI agents coordinate to write code, review it, and ship it without developers knowing the architecture underneath, what is a developer’s job anymore? Better yet, what kind of developer would you want to become while iterating on code becomes easier and easier?
The Buddy Problem
Developers used to learn by sitting next to each other, looking at screens together, catching bugs by pointing at the same line of code. Explaining your thinking to another person was how you develop understanding. Remote work scattered those interactions across time zones and async threads, and pair programming became something most teams quietly stopped doing. Stack Overflow became THE place for questions you didn’t want to bother a colleague with.
When someone calls their AI assistant a “buddy,” they’re naming something they miss. The feeling of thinking alongside another person, someone patient enough to hear you explain why the state isn’t updating before you realize, mid-sentence, that you forgot to expand the previous object. We used to get that from rubber duck debugging and patient colleagues. Now we’re finding it in chat windows that never sigh or check their phones.
What the “buddy” language reveals is that the role of patient collaborator was vacant for many of us long before these tools arrived. Are we building teams and cultures where that collaboration happens, or are we letting the tools paper over what’s been missing all along?
A 90% Confession
Nolan Lawson’s background in computational linguistics means he was studying how language models work before most of us even knew what a transformer was. He spent years optimizing Microsoft Edge and now works on supply chain security at Socket.
A year ago, Lawson viewed LLMs as “amusing toys but inappropriate for real software development,” comparing them to letting “a hyperactive five-year-old grab their keyboard and barf some gobbledygook into their IDE.” His January 2026 essay reversed that position.
“90% of my code is now authored by Claude Code.”
— Nolan Lawson
Lawson describes agents finding security vulnerabilities he’d missed, writing benchmarks that would have taken him days, and doing “a better job than the median web dev” on accessibility when given a browser to verify their work. His central argument is that the debate about AI coding has devolved into political tribalism, especially on Mastodon and Bluesky, where acknowledging any benefit from these tools gets you labeled as naive or complicit.
A Hacker News discussion surfaced the friction Lawson’s essay glossed over. One developer described how AI assistance degraded his mental model of the codebase, making him “no longer as effective in stopping it from doing silly things.” Another watching code reviews pile up wrote that his “heart sinks a bit every time I’m assigned to review a 5K+ loc mountain of AI slop.” A third captured the core tension with a metaphor. “LLM is like a chef that cooks amazing meals in no time, but his meals often contain small pieces of broken glass.”
The glass shards are real, and so is the speed. What happens to the developer who uses tools they can’t inspect?
Craft or Vibe?
Andrej Karpathy coined the term “vibe coding” in a February 2025 tweet.
“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists... I ‘Accept All’ always, I don’t read the diffs anymore.”
— Andrej Karpathy
By January 2026, vibe coding has gone from a Twitter joke to an industry practice. Y Combinator reported that 25% of their Winter 2025 batch had codebases that were 95% or more AI-generated. Anthropic CEO Dario Amodei told Fortune that 70-90% of code written at Anthropic comes from Claude.
Even Linus Torvalds started vibe coding, though characteristically on his own terms. His AudioNoise project on GitHub is a collection of digital audio effects he built to learn about signal processing, a companion to his hardware guitar pedal experiments. Torvalds wrote the C code for the DSP algorithms himself, but for the Python visualizer tool, he used Google Antigravity, an AI-powered IDE. Linus’s README is excellent. The Python visualizer tool has been basically written by Vibe-Coding. I know more about analog filters -- and that’s not saying much -- than I do about Python.”
The distinction matters. Torvalds vibe-coded a visualization tool for a hobby project. He’s notably NOT vibe-coding the Linux kernel (yet).
Simon Willison, who co-created Django and built Datasette, drew a line.
“If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly, and made sure you could explain how it works to someone else, that’s not vibe coding, it’s software development.”
— Simon Willison
One developer in the thread pushed back on Willison’s definition with, “You don’t get to call yourself a dev without sweating some of the details. The pain is inextricably linked to the pleasure. Decoupling them breaks the feedback loop that teaches you.”
Anders Ericsson spent decades studying how people become experts. His research showed that expertise comes from deliberate practice, working on tasks just beyond your current ability, where you have to struggle through mistakes. Robert Bjork at UCLA calls these desirable difficulties. Challenges that slow down initial learning often produce better long-term retention than approaches that make everything feel easy.
AI can write code. Whether developers who never struggle with it can develop the judgment to know when the AI got it wrong is less clear.
But Vibe Coding has a failure mode that practitioners call the “doom loop.” An agent makes a mistake, tries to correct it, makes things worse, struggles through several more iterations, and ends up back where it started, sometimes deleting all its changes and declaring the work done.
The developers who’ve found their footing share a common thread. They plan before they prompt, maintain instruction files like CLAUDE.md to preserve context across sessions, and choose languages with explicit type systems that give the model less room to hallucinate. Each strategy takes back control of the feedback loop. But while individual developers optimize their own workflows, the broader software ecosystem is optimizing for something else entirely.
Optimizing for Agents
Steve Yegge’s Software Survival 3.0 offers a framework for understanding this moment. In a world where AI capabilities keep expanding, Yegge argues that software survives only if it saves cognitive effort. He describes building tools by implementing whatever agents try to do until “nearly every guess by an agent is now correct.” He calls these desire paths, borrowed from the term for footpaths that emerge when people ignore the sidewalk and walk where they want to go. Software bends toward what agents want, and companies are starting to optimize for AI preferences over human ones.
Kelly’s discovery shows what desire paths look like at scale. The hidden architecture he found centers on an internal API that enables spawning agent teams, targeted messaging between agents, and coordinated task execution. A lead agent operates in “delegation mode,” coordinating specialist workers that spawn with fresh context windows and claim tasks from a queue.
Kelly’s analysis identified three collaboration patterns in the architecture. The Hive breaks large refactorings into independent chunks that worker agents execute in parallel. The Pipeline chains specialists in sequence, with Draft, Refine, Test, and Document agents, each handling one stage. The Watchdog monitors production systems and spawns Fixer agents when errors are detected. In each pattern, humans review the final output rather than the intermediate steps.
Developers testing the architecture reported on Hacker News that swarms could handle 50,000+ line codebases that would choke a single agent. Skeptics countered that generating large amounts of code makes review harder, not easier. Some agents were caught making wrong decisions, like reimplementing the Istanbul test coverage library from scratch instead of running npm install.
In a swarm architecture, who understands what the code is doing? The orchestrator doesn’t read every file, while the worker agents don’t maintain context across tasks, and humans review diffs without seeing the reasoning that produced them. Somewhere in that chain of handoffs, the feedback loop that teaches developers how systems work gets interrupted.
What Kind of Developer Do You Want to Be?
The swarm architectures are here! Kelly’s discovery gave us quite some insight, and Yegge’s survival framework explains how software adapts when agents become the primary users.
I’ve been doing something like what Kelly did. Auditing my tools. I measure my own ratio and ask whether I’m comfortable with it. Finding other developers asking the same questions is because shared uncertainty is how communities form.
Maybe that uncertainty is the new normal. Or maybe it’s a prompt to ask harder questions about what we want to understand.
I’m going to find out.
👏