There is a specific feeling you get the first time Claude Code ships something for you in twenty minutes that would have taken a full afternoon. You feel like you cheated. You feel like the rules of software engineering quietly rewrote themselves while you were not looking. Then you open a second terminal, point another agent at another feature, and tell yourself you are just going to multiply that feeling.

I have done this. Most engineers I respect have done this. And nearly all of us have lived through what comes next.

What comes next is a codebase that nobody has actually read in full. A pull request the size of a small novel, merged by a human who skimmed the diff and let the green checkmarks do the rest of the thinking. A config file with three sources of truth. A migration that ran in dev, looked fine in staging, and corrupted production. A feature flag that was never actually wired up. A logger that swallows the error you are now spending six hours trying to find.

The lesson is not that Claude Code is bad. I use it every day, both for AlgoCademy and for the routing engine I am building at Rheon, and I would not give it up. The lesson is older than the tool. It is older than AI. It is the lesson that software has been trying to teach the industry for fifty years, and the lesson that AI tooling makes very easy to forget: writing the code is not the hard part. Knowing what to write, when to write it, and how to fit it into the thing that already exists, that is the hard part. Speed at the keyboard solves the easy problem. It often makes the hard problem worse.

The Mythical Man-Month, Now With Robots

Fred Brooks wrote The Mythical Man-Month in 1975 and the central observation has aged better than almost any other claim in our field. Adding more developers to a late project makes it later. Communication overhead grows quadratically. Coordination eats whatever capacity the new hires were supposed to add. The hard parts of software are not parallelizable.

We accepted this for human teams. Then we plugged in agents and quietly decided the rule no longer applied.

It still applies. An AI agent is, for the purposes of this argument, an extra developer. A fast one, a tireless one, a developer who works for pennies, but a developer all the same. Run three of them in parallel on the same product and you get the same problems Brooks described, just compressed into a single afternoon. Two agents reach for the same abstraction and produce two slightly different versions of it. One adds a utility function that already exists somewhere else in the repo, named something you would never have searched for. Another quietly chooses a different date library because that is what its training data prefers. Now you have inconsistencies that no human ever decided to introduce, and no human is fully aware of.

The fact that the agents are cheap and fast does not change the math. It just makes it cheaper and faster to dig the hole.

Code Is a Liability

The instinct to measure productivity in lines of code, features shipped, or pull requests merged is one of the oldest mistakes in the industry. It feels measurable. It looks like progress. And it is one of the most reliable ways to drive a product into the ground.

Code is a liability. Every line you write is something you have to maintain, debug, secure, document, and eventually delete. Every feature you ship is a surface that future you, or someone you hire, will have to keep alive while the rest of the world moves on around it. Every dependency you add is a future CVE. Every clever abstraction is a future onboarding tax.

When the bottleneck on producing code was a human typing, this liability accumulated slowly enough that most teams could absorb it. The bottleneck enforced a kind of natural editing. You did not write the feature unless you really needed it, because writing it was expensive. Claude Code removes that bottleneck. The liabilities still accumulate. The editing function does not.

This is why teams that adopt AI tooling without changing their process end up with bigger codebases, more features, more bugs, and somehow less product. They are confusing the cost of typing with the cost of software. Typing was never the expensive part.

The Planning You Skipped

The most insidious thing about a fast tool is that it makes the planning step feel optional. Why sketch the data model when you can ask Claude to scaffold it and iterate? Why argue about the API shape when generating three versions takes less time than the meeting would? Why think about edge cases when the agent will probably handle most of them?

The answer is that the agent will handle most of them, in the sense of producing code that compiles and looks plausible, and it will silently get the rest wrong in ways you will not notice until a customer does. AI tooling is extremely good at giving you a shape that resembles the right answer. It is not, on its own, good at telling you what the right answer is. That part is still on you.

When you skip the planning phase, you are not saving time. You are moving the cost. Instead of an hour at a whiteboard you get six hours of debugging a system whose original intent nobody, including you, ever fully articulated. Instead of a hard conversation about which feature actually belongs in the next release, you get all of them, half-built, fighting each other for surface area in your UI.

The teams I have seen do well with Claude Code are the ones who treat the planning step as more important, not less. They know that the agent will execute fast, so the cost of executing the wrong thing is now higher relative to the cost of figuring out what to execute. Slowness in thinking is the dual of speed in implementation. If you only get fast at one of those, you have not gotten faster at building software. You have just gotten faster at making mistakes.

The Pull Request Nobody Read

There is a quiet pact in code review. The reviewer will read the diff seriously. The author will keep the diff small enough that this is possible. Both sides have skin in the game.

Claude Code breaks the pact from one direction. The diff is suddenly a thousand lines long, generated in an hour, touching twelve files the reviewer has never seen. The reviewer is now expected to evaluate work product at a rate that the human eye cannot actually evaluate. So they do what humans do when overwhelmed. They pattern-match. They look at the test file, see green, and approve. They glance at the function signatures, see plausibility, and move on. They trust the green checkmarks because trusting the green checkmarks is the only way to clear the queue.

This is how AI hallucinations end up in production. Not because anyone is reckless, but because the volume of code being produced has outrun the volume of attention available to review it. The hallucination rate of a frontier model on coding tasks is low, but it is not zero. Run that small percentage across thousands of lines a day, and the math is not in your favor.

The fix is not to demand more careful reviewers. It is to keep the diffs small enough that careful review is still possible. Which means writing less code. Which means doing fewer things at once.

What Actually Breaks

The failure mode of moving too fast with AI is not that your codebase becomes ugly. Ugly codebases can ship. The failure mode is instability that compounds. You ship a feature. It introduces a regression. You ship a fix. The fix introduces a different regression because the original feature was not understood by anyone, including the agent that wrote it. You ship another fix. Now you have three layers of patches over a foundation that nobody on your team can fully describe.

Eventually something serious goes. A migration deletes data it was not supposed to. A rate limiter forgets to apply itself to a new endpoint. A subscription webhook double-charges a customer because the idempotency key was generated with the wrong scope. The post-mortem is always the same shape. We moved too fast, we did not review carefully, the agent produced something that looked right, nobody had the full picture, and now we are explaining ourselves to a customer who is no longer a customer.

For most products this is recoverable. For some, it is not. Leaking customer data is not a setback you patch and move on from, it is an event that defines the rest of the company. The question is not whether the speed was worth it on the average day. The question is whether it was worth it on the worst day.

Depth Beats Breadth

What I have come to believe, after a year of using Claude Code seriously and watching what happens when I use it well versus when I use it badly, is that the right unit of work is one feature at a time, taken seriously, finished completely.

Finished, in this context, has a specific meaning. It means designed before it was written. It means small enough that the diff fits in a single human’s head. It means tested in a way that exercises the edge cases, not just the happy path. It means documented well enough that someone joining the team next month could read the code and understand the intent. It means deployed behind a flag, observed in production with real traffic, and gradually rolled out. It means the bugs that were going to surface in the first week have surfaced and been fixed. It means you have stopped touching it because there is nothing left to touch.

A feature in this state is a real asset. It will run for years and ask very little of you. Five features that are seventy percent finished are not an asset. They are five sources of paged-at-3am incidents waiting for the right input.

The temptation Claude Code creates is to convert your engineering capacity into half-finished features at a rate your old self would have envied. The discipline Claude Code rewards is to convert that same capacity into completely finished ones at a rate your old self could not have managed. The first feels faster. The second actually is.

How to Actually Slow Down

The practical version of this argument, the part you can apply on Monday, looks something like this.

Write the design before you start the agent. Even one paragraph, even on a napkin. Decide what this feature is and, more importantly, what it is not. The agent will happily expand the scope without asking. You have to be the one who refuses.

Run one agent at a time, on one task at a time. The fantasy of three agents running in parallel and merging into a coherent codebase is exactly that. If you find yourself wanting parallelism, that is a signal that your tasks are too big and need to be cut down, not a signal that you need more agents.

Read the diff. All of it. If the diff is too big to read, the task was too big. Send it back, break it apart, try again. Do not approve code you have not understood, no matter how green the tests are. The tests are also written by the agent.

Ship behind a flag. Watch it in production for longer than you think you need to. The bugs that matter are the ones that show up under real traffic, with real data, with real users doing things you did not predict. No staging environment will surface those.

Delete more than you add. The cleanest signal that a team is using AI tooling well is that the codebase is not growing as fast as the feature list suggests it should. That means abstractions are being consolidated, dead code is being removed, and complexity is being managed instead of accumulated.

Treat your roadmap with at least as much seriousness as you treat your code. Saying no to a feature is now the most valuable thing a product person can do, because the cost of saying yes has collapsed and the cost of maintaining what you said yes to has not.

The Part That Did Not Get Faster

The thing nobody wants to say out loud about AI coding tools is that they made the easy part of the job easier and left the hard part exactly where it was. Generating plausible code is easy now. Knowing which code to generate, in what order, fitting into what architecture, is the same problem it was in 2015. It still requires taste. It still requires patience. It still requires the willingness to throw away work that does not fit, even when throwing it away feels like waste.

Speed at the keyboard was never the constraint on good software. It is not the constraint now. The engineers who get the most out of Claude Code over the next few years will not be the ones who learn to type the fastest prompts. They will be the ones who learned, somewhere along the way, to think slowly about what is worth building, and to build it once, properly, before moving on.

That has always been the job. The tool got faster. The job did not.