✓ Human-authored analysis; AI used for formatting and proofreading.
In 1980, Manny Lehman published his laws of software evolution. The second law is violated at industrial scale by AI-assisted development:
Lehman's Second Law (Increasing Complexity): As an evolving program is continually changed, its complexity increases unless work is done to maintain or reduce it.
The key phrase: "unless work is done." Complexity doesn't stay constant. It doesn't decrease on its own. It increases with every change. UNLESS someone actively works to reduce it. Refactoring. Consolidation. Deletion. Simplification. These are the forces that counteract entropy. Without them, every change adds complexity, and the system moves toward calcification. The state where any change breaks ten other things.
AI is the most powerful additive force ever applied to a codebase. And it has no instinct to subtract.
The additive bias
Ask an AI to fix a bug: it adds code. A new condition. A guard clause. A wrapper function. The bug is fixed. The codebase grew by 15 lines.
Ask an AI to add a feature: it adds code. A new module. A new handler. A new test file. The feature works. The codebase grew by 200 lines.
Ask an AI to handle an edge case: it adds code. A special-case branch. An exception handler. A fallback path. The edge case is handled. The codebase grew by 30 lines.
AI never says: "To do this properly, I should first refactor these three modules to simplify the dependency graph, then add the feature in 50 lines instead of 200." The AI doesn't refactor unprompted because refactoring isn't in the prompt. The prompt says "add a feature." The AI adds a feature. The structural simplification that would make the feature smaller and the codebase healthier isn't requested, so it doesn't happen.
Over weeks and months, this compounds:
Week 1: Codebase: 5,000 lines. AI adds 2,000 lines. 7,000 total.
Week 2: Codebase: 7,000 lines. AI adds 2,500 lines. 9,500 total.
Week 4: Codebase: 9,500 lines. AI adds 3,000 lines. 12,500 total.
Week 8: Codebase: 12,500 lines. AI adds 3,500 lines. 16,000 total.
Week 12: Codebase: 16,000 lines. AI adds 4,000 lines. 20,000 total.
Refactoring done: 0 lines deleted.
Consolidation done: 0 duplicate functions merged.
Simplification done: 0 abstractions removed.
Lehman's Second Law: complexity increased on every change.
Nobody did the work to maintain or reduce it.
The five symptoms of AI-accelerated entropy
1. Duplicate implementations
Five developers prompt AI for date formatting over a month. Five implementations exist. Each is correct and slightly different. A bug found in one leaves the other four vulnerable. Nobody knows the duplicates exist because nobody searched. The AI generated, the developer merged, and the codebase grew.
In a human-written codebase, the third developer would have noticed the existing function during code review. With AI-generated code at high velocity, code review is overwhelmed and the duplication slips through.
2. Divergent patterns
The AI generates a retry function using exponential backoff in module A. A week later, a different prompt generates a retry function using linear backoff in module B. Both are correct for their context or both are correct for NO particular reason, just different training data patterns activated by different prompts.
The codebase now has two retry strategies. Nobody chose or documented the rationale. A future developer encountering both doesn't know which is the standard. They generate a third.
3. Layer violation creep
The architecture has three layers: handler, service, repository. The AI generates code that calls the repository directly from the handler bypassing the service layer. The code works. The architectural boundary is violated. The violation isn't caught because the linter isn't configured for architectural boundaries, and the code reviewer is scanning for bugs, not for layer violations.
Over weeks, more handler-to-repository calls appear. The service layer becomes optional. The architecture degrades from three layers to a tangle. Lehman's law in action: the structure deteriorated because nobody did the work to maintain it.
4. Dead code accumulation
The AI generates a utility function for feature A. Feature A is later replaced by feature B, which uses a different utility. The original utility remains in the codebase. Nobody deleted it because nobody knows it's unused. The AI didn't flag it when generating the replacement. The developer didn't search for references.
After months, 10-20% of the codebase is dead code. Functions that are never called, modules that are never imported, constants that are never read. Each adds to the cognitive load of anyone navigating the codebase.
5. Configuration sprawl
The AI generates a new config value for each feature: a timeout here, a retry count there, a batch size over there. Each is reasonable. None are documented. None are constrained. After months, the application has 200 configuration values, half of which interact in undocumented ways. Changing one timeout cascades to a retry count cascades to a batch size cascades to a memory limit. The configuration is its own complex system, ungoverned and unverified.
Why human-era maintenance doesn't scale
In the pre-AI era, a team that generated 1,000 lines per week could allocate 20% of their time to refactoring 200 lines of maintenance work per week. The ratio was sustainable. The codebase grew slowly. The maintenance kept up.
In the AI era, the same team generates 5,000 lines per week. Twenty percent of their time is still the same number of hours but the maintenance needed is 5x larger. The ratio inverts:
Pre-AI: 1,000 lines added / week. 200 lines maintained / week. Ratio: 5:1
AI-era: 5,000 lines added / week. 200 lines maintained / week. Ratio: 25:1
The maintenance capacity didn't scale.
The generation capacity scaled 5x.
The gap widens every week.
Lehman's law says complexity increases UNLESS work is done to reduce it. The amount of work needed scales with the rate of change. The rate of change increased 5x. The maintenance capacity didn't. The inevitable result: complexity accumulates faster than it can be reduced.
The resolution: mechanical maintenance
If human maintenance doesn't scale to AI-speed generation, the maintenance must also happen at machine speed. Three mechanisms:
Composition over generation
The AI that searches for existing implementations before generating new ones is a force for reduction, not addition. "Found existing retry function in utils/retry.go. Using it instead of generating a new one." One import instead of 150 lines. The codebase shrinks instead of grows.
This requires the AI to search FIRST and generate SECOND. The Compose-First skill from the Superpowers framework. Without it, the default is generation. With it, the default is reuse.
Architectural enforcement
The layer violation that creeps in silently is caught instantly by a linter rule. depguard for Go, eslint-plugin-import for JavaScript, ArchUnit for Java. The linter enforces the architectural boundaries on every commit. The AI can generate code that violates the boundary but the CI gate rejects it.
This is Lehman's "work done to maintain structure" automated. The human doesn't review every line for architectural compliance. The linter does. The maintenance scales with the generation because it's mechanical.
Deletion metrics
Track the ratio of additions to deletions on every PR. A healthy codebase has a ratio below 3:1. For every 3 lines added, 1 line is deleted. AI-generated PRs often have ratios of 50:1 or higher with all additions without deletions.
Making the ratio visible changes behavior. The developer who sees "this PR added 200 lines and deleted 0" asks: "is there dead code I should remove?" The metric doesn't do the deletion. But it prompts the human to do the work Lehman said was necessary.
Maintainence with velociy
AI doesn't cause entropy. Entropy is Lehman's law. It's a property of evolving software. AI ACCELERATES entropy because it increases the rate of change without increasing the rate of maintenance.
The acceleration isn't inevitable. Teams that pair AI generation with mechanical maintenance such as composition over generation, architectural enforcement, deletion tracking can maintain the structure while capturing the velocity. The key is recognizing that the maintenance must be automated, not manual, because manual maintenance scales with human hours and AI generation doesn't.
Lehman said complexity increases UNLESS work is done. With AI, the unless must be enforced mechanically because the work needed exceeds what humans can do at the rate AI generates change.
Lehman's law applies to security control catalogs too. A catalog that grows without structure degrades with overlapping controls, inconsistent naming, conflicting predicates. Stave manages this through structural conventions: per-domain directories, per-pack YAML manifests, a thin index with derived control references, golden test infrastructure, and mechanical validation that every control's observation fields match the JSON Schema. The catalog grows (2,668 controls) without degrading because the structure is enforced mechanically on every change. Lehman's "unless" is automated.
Top comments (0)