Cowboy Coder Is Back. This Time, They Scale
I should start by admitting I’m part of the problem.
I can still draw the architecture of code I wrote three years ago from memory. The data flow, the edge cases, the reasoning behind every choice that looks strange at first glance. Ask me to do the same for a feature I shipped last month with help from an agent, and I can tell you what it does and why we built it. The deeper model, the one that lives at the level of individual functions, isn’t there.
That’s not laziness, and it’s not a lapse in review. I read every diff. An agent does a closer pass alongside me. I can speak to the intent and shape of what I’m approving. But the deep mental model, the one you actually need at 2am when something breaks and the agent isn’t helping you debug, isn’t forming the way it used to.
I’m a CISO who still writes code, and this worries me. It should worry anyone managing engineers right now, because it isn’t just me. Across the industry, AI coding agents are quietly reviving the single worst antipattern in software engineering history. We just don’t recognize it yet, because it’s wearing different clothes.
Remember the cowboy?
If you’ve managed engineers long enough, you know the cowboy. The one who disappears for a weekend and comes back Monday with a full rewrite nobody asked for. The one who, somehow, is the only person who understands the gnarly billing module, the auth flow, the deployment pipeline. The one whose decisions land in production faster than the team can review them.
Cowboys aren’t heroes, by the way. The hero is the engineer who pulls the 2am save when production breaks. The cowboy is the one who created the conditions that made the 2am save necessary in the first place. Heroes clean up. Cowboys cause.
For twenty years, our industry has been quietly learning how to build engineering organizations that don’t depend on this person. Code review. Pair programming. Design docs and RFCs. Collective code ownership. Postmortems that look at process, not blame. The whole inheritance from XP, agile, and DevOps was, in large part, a response to the lesson that cowboy culture feels productive and is actually corrosive.
It worked. Not perfectly, but the average engineering team today is far more resilient than the average team in 2005.
Then the agents arrived.
Watch what happens on teams that have adopted Claude, Cursor, Copilot, Codex, and the rest without changing how they work. An engineer prompts an agent. The agent emits eight hundred lines of code. The engineer skims it, sees the tests pass, and merges. Repeat, ten times a day, across the team.
The output is enormous. The velocity charts look incredible. And underneath, something is going wrong that nobody is naming yet.
Nobody on the team has reasoned through that code. The “author” couldn’t walk you through it under questioning. They didn’t write it, they prompted it. The reviewer couldn’t either; they had thirty other PRs in the queue, and half the time the reviewer is another agent. Six months from now, when something breaks at 2am, the engineer who gets paged will be debugging code that has, in any meaningful sense, no human author at all.
This is the cowboy pattern. The weekend rewrite, the opaque module, the knowledge silo, the tech debt nobody quite remembers creating. Same antipattern, new substrate.
Why it’s actually worse
The cowboy archetype, for all its damage, had one redeeming feature: somewhere, in one human brain, the model of the system existed. Bus factor of one.
Development driven by agents, without comprehension, produces bus factor zero. The code enters the repository with nobody understanding it. There is no expert to consult, because the “expert” was a probability distribution that has since moved on to the next prompt.
The social brakes that used to slow cowboys down are also gone. Cowboys had egos, reputations, and peers who could push back in code review. Agents have none of these. They don’t sulk when overruled, don’t take credit, don’t feel shame when prod breaks. The friction that used to make cowboy culture limit itself in healthy teams, the simple fact that other humans were watching, is absent.
And there’s a new accountability sink. When the cowboy shipped a bad rewrite, you knew whose desk to visit. When an agent ships a bad rewrite, the conversation goes “well, the AI wrote it” and everyone shrugs. The blame diffuses into the tooling.
What managers should do now
The good news: the playbook for fixing this already exists. We wrote it the last time. It needs updating, not reinventing.
Require comprehension, not just approval. Before any meaningful PR written with an agent gets merged, the author should be able to walk through it without asking the agent again. If they can’t explain why a function exists, the PR isn’t ready. This is the most impactful change you can make, and the one I’d benefit from most personally.
Cap PR size, hard. Code review evolved assuming limited human throughput on both sides. Agents broke that assumption. A PR of 50 lines can be meaningfully reviewed; a PR of 800 lines gets approved without thought. Set a limit, enforce it in tooling, and force large changes to be decomposed.
Tag agent involvement and track it. Make AI authorship a first class piece of metadata on commits and PRs. Watch incident rates, time to debug, and refactor cost on modules where agents wrote most of the code, and compare against the rest. You can’t manage what you can’t see, and right now most engineering orgs are flying blind on this.
Protect the loop of deliberate practice. Junior engineers who never struggle through a hard bug don’t become senior engineers who can debug under pressure. Build in rotations without agents, pair on hard problems, and make “can debug from scratch” part of your leveling criteria. The seniors riding herd on agents today learned their craft the hard way. The next cohort needs a path to the same skill, or you’ll wake up in five years with a team that can prompt fluently and reason about nothing.
Reframe tech debt as unread code. The most dangerous code in your repository is no longer the bad code. It’s the unread code, modules that work today and that nobody on the team has actually internalized. Schedule comprehension audits. Assign engineers to read and document modules written by agents that they didn’t author themselves. Treat unread code as a liability on the books.
This is not an argument against AI
The agents are useful. The productivity gains are real. I use them every day, and I’m not giving them up.
The point is that the technical productivity of these tools is arriving faster than the organizational practices needed to absorb them. The teams that already had healthy engineering culture, the kind with code review that actually reviews, sustainable pace, and collective ownership, will adapt and thrive. The teams that quietly tolerated cowboys are about to have a much worse problem, at much greater scale, with no single person to point at.
And the rest of us, the ones who can still picture the flow of code we wrote three years ago but no longer build that same depth of model with the new stuff, need to be honest that the muscle is atrophying. Mine is. Yours probably is too.
The cowboy didn’t go away. The cowboy scaled, with a million tokens of context. The work of engineering management is to recognize the pattern in its new form and apply the lessons we already learned the last time.




The best article on AI coding agents I have seen in a while. AI coding agents write code. They even review code. But it is still the responsibility of software engineers to review and, critically, understand that code.