Two Completely Different Curves
The difficulty curve of traditional software development is roughly a gentle start followed by a steady climb: setting up the environment, learning the framework, writing the scaffolding—one step at a time. Later, as the codebase grows, the difficulty does increase, but you know exactly where every bit of that difficulty is coming from.
AI-assisted development follows an entirely different curve. The early phase is terrifyingly steep—a demo in a day, a prototype in three days, and within a week you can ship a product that looks pretty convincing. But that speed is not free. The bill has merely been deferred: once the codebase grows beyond the AI’s context window, development difficulty does not rise linearly—it explodes.
The inflection point arrives the moment the AI can no longer fit the entire project into its context. Before that, it is an all-knowing, all-capable partner. After that, it becomes an outsourced contractor that can only see a local slice of the system—you ask it to change A, and it has no idea that B depends on A’s old behavior; you ask it to add a feature, and it does not know that three months ago, in some forgotten corner, an implicit contract was written into the code.
The Later You Get, the Harder the Bug-Fixing Math Stops Working
The experience at this stage can be summed up in one sentence:
You fix one bug, and at the same time create 1–3 explicit bugs, plus n hidden ones.
Explicit bugs are still manageable—an error is thrown, the page goes blank, and if you can see it, you can fix it. The truly terrifying part is the n hidden bugs: no error, no crash, just some edge case quietly going wrong, or some piece of data slowly becoming corrupted. They ferment in the dark, and a few weeks later, they come back to you as “mysterious production issues.”
In traditional development, an engineer’s mental model of their codebase is continuous: they know where the landmines are, because they planted them with their own hands. In AI-driven development, the landmines are planted by the AI. No one knows when they are planted, and when it comes time to fix them, the AI itself cannot see the whole picture either. The parts that no longer fit into the context window are exactly where hidden bugs breed.
Complexity Has Seven Faces, and AI Can Only Hold Down a Few of Them
To understand why things explode later on, you first have to admit one thing: the “difficulty” in software engineering is not one kind of difficulty, but a set of independent complexities:
- Size Complexity: the cognitive burden created by the sheer number of lines and files. A hundred thousand lines of spaghetti code and a hundred thousand lines of carefully designed code are two completely different worlds to read.
- Cyclomatic Complexity: how many execution paths exist inside a function. if inside if inside if, and the number of paths grows exponentially—tests cannot cover them all.
- Algorithmic Complexity (Big-O): when the amount of data grows tenfold, does the program become ten times slower, or a hundred times slower?
- Architectural Complexity: how modules are divided, where the boundaries are, and who depends on whom. Cut it wrong, and every change affects the whole body.
- Dependency Complexity: every third-party library and every external service you introduce is another variable you do not control.
- State Complexity: how much mutable state exists in the system, when it changes, who changes it, and in what order. This is the richest breeding ground for hidden bugs.
- Data Complexity: the structure, flow, and consistency of data. Dirty data does not throw errors, but it contaminates everything downstream.
AI can help you keep the first three under control: generating code in bulk, flattening nested logic, and writing a decent algorithm are all well within its capabilities. But the latter four—architecture, dependencies, state, and data—require a global view to manage, and that is precisely the first capability AI loses once the context explodes.
That is the internal reason the curve explodes in the later phase: AI suppresses the simple forms of complexity, while letting the hard ones escape—and the hard ones grow exponentially with the size of the codebase.
AI Native Does Not Mean You Get to Skip Software Engineering
Our generation of developers is, of course, AI native. I have no doubt about that—AI is the primary author of all my own projects. But recently I have become increasingly convinced of something else: software engineering really is something you have to study systematically.
The logic is simple: AI drives the cost of “writing code” close to zero, so the bottleneck shifts backward. The problem used to be “can you write it?” Now the problem is “can you hold it together?”—hold the architecture together, hold the state together, hold the dependencies together. And these are exactly the core concerns that software engineering has accumulated over decades: modularity, information hiding, state management, and complexity control.
This is especially true for someone like me, who did not come from a formal CS background and got started entirely with AI. Every foundational lesson I skipped will eventually come due, collected by each hidden bug in the later stages.
AI eliminates typists, not engineers. It raises the bar for engineering ability, rather than lowering it.
Respect Knowledge, Respect Computers
Finally, a note of emotion—also the real point of this essay.
There is an idea becoming more and more popular: now that AI is here, why learn software engineering at all? Or even—why learn computer science?
Honestly, I think this is a very foolish way to think.
Computer science is what some of the smartest people over several decades accumulated while battling their natural enemy: complexity. It has not become obsolete because of AI. On the contrary, it has become the driver’s license for wielding AI: if you do not understand complexity, you cannot even judge where the things AI writes are likely to break.
Respect knowledge, and respect computers. The stronger the tool, the more skilled the hand holding it needs to be.