AI coding is not software engineering

The distinction that matters

Large language models are good at coding. They are bad at software engineering.

This is not a semantic quibble. Coding is the act of writing instructions that a machine can execute. Software engineering is the discipline of choosing abstractions, decomposing systems, designing architectures, managing state, handling failure, and building artifacts that can be maintained, extended, and understood over time.

LLMs excel at the first and show no empirical competence at the second.

The distinction matters because organizations that treat AI coding as a substitute for software engineering are building future maintenance liabilities that nobody fully understands.

The deskilling risk

The near-term risk is not that AI will replace engineers. It is that offloading more and more code to models will gradually deskill the humans who need to understand the system.

After months of AI-assisted development, a codebase can reach a state where 60% or more of the code is AI-written and nobody fully understands it. The humans who could have maintained it have been gradually losing deep system knowledge, not because they are lazy, but because the interaction model of prompt-and-accept does not build the same cognitive models that reading, writing, and debugging by hand does.

This is a governance problem, not a tooling problem. The tools work. The governance question is whether the organization is building maintainable systems or accumulating technical debt at machine speed.

The UX problem

The standard AI coding workflow (prompt, receive code, review, accept) is adequate for small, stateless tasks. It is inadequate for the kind of interactive, stateful, exploratory development that produces deep understanding.

The lineage from Smalltalk, Lisp, APL, and Mathematica through to modern notebooks demonstrates that humans think best when they can interact with live objects, refine mental models, and grow understanding incrementally. The "dead code" model (file-based, stateless, CI-first) cuts humans off from the living system they are building.

This is not merely a preference. It is a cognitive requirement. If the workflow makes it easy to generate code and hard to understand it, the organization is training its engineers to accept answers they cannot fully explain.

What teams should do

Distinguish coding from engineering in your metrics. Do not measure AI coding success by lines of code, pull request volume, or token consumption. Measure by system comprehensibility, defect density over time, and the ability of multiple engineers to explain how critical paths work. If only one person understands a subsystem, you have a bus factor of one.

Require understanding, not just review. A code review that consists of skimming AI-generated code and clicking approve is not a governance gate. Require that engineers can explain what the code does, why the approach was chosen, and what failure modes exist. If they cannot explain it, the code is not ready.

Design workflows that build understanding. Use interactive, stateful, exploratory environments where engineers and AI can jointly inspect, refactor, and test in small, observable steps. The goal is not to maximize AI usage. It is to maximize the engineer's understanding of the system they own. Jeremy Howard put this well recently: if the workflow makes deep understanding hard, that is a tool design failure, not an AI literacy issue.

Watch for the deskilling gradient. If your senior engineers are spending more time reviewing AI output than writing and reasoning about architecture, you are on the deskilling gradient. The correction is not to use less AI. It is to use AI in ways that deepen understanding rather than replacing it.

The bottom line

AI coding tools are genuine productivity accelerants. But productivity without comprehension is just technical debt accumulation at higher velocity. The governance question is whether your AI coding practices are building systems your team can maintain, or systems that will have to be rewritten when the humans who half-understood them move on.