Brooks named it in 1975. The lesson keeps getting relearned, and AI-assisted development is making the second-system trap easier to fall into, not harder.
Fred Brooks named the second-system effect in 1975. The first version of a system tends to be cautious, because the team is still learning the problem. The second version tends to be overdesigned, because they finally understand it and want to fix everything they couldn't fix the first time. Most teams never get to a third version. The second one collapses under its own ambition.
We have spent a lot of the last year auditing AI-assisted rewrites, and the same pattern keeps showing up. The system that earns the money is being quietly replaced by a parallel implementation that compiles, looks cleaner, and is missing something important.
Why AI makes this trap easier to fall into
AI coding assistants lower the cost of writing new code. That is true, and mostly good. The catch is that they lower it uniformly. The friction that used to keep a team from scaffolding a parallel implementation — the work of typing it all out — is gone. So the parallel implementation gets built.
On its own that isn't a problem. The problem is what those implementations tend to miss. A few of the rewrites we have looked at recently were built in a single sprint, pass a thin test suite, and replicate roughly 80 percent of the original behavior. The remaining 20 percent is what the old system was doing on purpose.
The behaviors that aren't written down
Every long-running system encodes behaviors that exist only in the code. The retry that quietly recovered from a partner outage in 2022. The off-by-one that rounded in the customer's favor and ended up referenced in a contract. The performance trick nobody documented because the engineer who wrote it left two years ago. None of these are in the requirements doc. None of them are in the tests. They are still load-bearing.
A rewrite, AI-assisted or otherwise, tends to treat these behaviors as absences and confidently write the new code without them. The new code looks correct. Production tells a different story, usually about three weeks after launch, when a customer notices that something that used to work doesn't.
What we suggest instead
When the second-system urge hits a team we work with, we ask them to do something unglamorous first. Spend a week, before any new code is written, documenting what the existing system actually does. Not what it was meant to do. Not what the docs say. What it does, including the parts that look like bugs but pay rent.
The list is always longer than expected. By the end of the week the rewrite plan looks different, and usually smaller. That is the point. The behaviors that survived the audit become the contract for the new system. The ones that didn't survive can be removed on purpose, which is very different from removing them by accident.