Accidental and Essential Complexity in the Age of LLMs

Writing code is almost free now. LLMs generate functions, tests, and modules in seconds. What took days now takes an afternoon.

But cheaper code does not mean simpler systems. The complexity is still there. It just moved.

Two Kinds of Complexity

Every system carries two kinds of complexity.

Essential complexity is the domain problem. Business rules, edge cases, data relationships. A booking system needs cancellation policies, payment flows, and availability logic. That complexity exists because the business exists. No tool removes it.

Accidental complexity is what we add on top. Inconsistent patterns between modules. Boilerplate no one standardized. Architecture choices that add friction without solving a business need.

The ratio between the two decides how a team spends its time.

A new project is mostly essential work — the team ships features and models the domain. An old, large codebase flips. Most effort goes to fighting accidental friction. When accidental complexity exceeds essential complexity, the team stops solving business problems and starts fighting the machine.

AI Made Code Cheaper. Teams Produce More of It.

When something becomes cheaper, people use more of it. The same is happening with code.

AI makes writing code almost free. But the result is not smaller systems. The result is more code. More files, more abstractions, more modules. Teams generate code faster than they can understand it.

I call this shadow accidental complexity. The AI wrote it for free. It looks clean. It passes the linter. But someone still needs to maintain it and understand it six months later.

The cost of creation dropped to zero. The cost of comprehension did not.

If an AI generates 1,000 lines for a problem that needs 50, the system grew by 950 lines of surface area a human must carry. The code works. The tests pass. But more code is not more progress. It is more liability.

The Real Risk: Skipping the Thinking

AI makes the accidental side so easy that teams skip the essential side.

Why spend a week modeling the domain when the AI generates the implementation in an hour? Because generating code before understanding the domain creates systems that are well-written but wrong.

The functions are clean. The patterns are consistent. But the boundaries are in the wrong place. The data model reflects the AI’s guess, not the actual requirements.

The hard work was never typing. The hard work was deciding what to build.

Rules Fix the Accidental Side

Accidental complexity is a consistency problem. The patterns are known. The conventions can be defined. The rules can be written down.

Define architecture conventions in files LLMs can read — project instructions, rules files, custom skills. The LLM stops guessing and follows your design language.

Without rules, every generation drifts. The same problem gets solved three different ways across three files.

With rules, LLMs reduce accidental complexity at scale. The difference is not the LLM. The difference is the constraints you give it.

But rules only fix the accidental side. Where to draw module boundaries, which tradeoff fits your business — that requires understanding the domain. LLMs help here as a thinking partner: explain your design problem, explore tradeoffs, challenge your assumptions. But the judgment stays with you. Once the decision is made, the LLM generates the implementation. The essential part was the decision. The code is accidental.

From Producer to Curator

The engineering role is shifting. The old bottleneck was writing code. The new bottleneck is understanding it.

The best practice I have found is a clear split. Invest in rules for the accidental side. Let LLMs handle consistency and pattern enforcement. Spend your time on the essential side: domain modeling, architecture decisions, boundary design.

Engineers become architect-reviewers. Define the essential boundaries. Let the LLM handle the accidental work. Verify the output stays within constraints.

The complexity bill always comes due. The question is whether you spent your time on the part that matters.