AI, Code, and Design: Why the Most Important Thing Hasn’t Changed

AI tools can write code. But why the core of software design remains a human mental model—and what that really implies.

I. Introduction  

AI-powered coding assistants are now capable of producing:

• syntactically valid code,
• working code,
• and even a certain form of reasoning about code structure.

Faced with this, a legitimate question arises:
do we still need to learn how to code, or is it enough to learn design and leave the rest to AI?

This question lies at the heart of a video titled “The Skill That Separates Good Developers from GREAT Ones” by Emily Bache, which offers a nuanced answer deeply rooted in the fundamentals of software engineering.

II. In Software, Code Is the Design  

A central point emphasized in the video is that, unlike other engineering disciplines, software does not clearly separate:

• the design phase,
• from the production phase.

The source code is the software’s design.

Once written:

• it is interpreted deterministically,
• it can be reproduced without ambiguity,
• it requires no further intervention from the designer to be “manufactured.”

The compiler and the build pipeline play the role of the factory.
The design itself resides in the code.

III. Writing Code, Testing, and Debugging Are Part of Design  

From this perspective, coding is not a mechanical activity.
It is a design activity.

Testing and debugging are not secondary steps:

• they evaluate the design,
• reveal its weaknesses,
• and refine and correct it.

It therefore makes little sense to oppose learning to code and learning design:
learning to code is learning to design.

IV. Programming Is Theory Building  

Emily Bache builds on the work of Peter Naur, who described programming as an activity of theory building.

This theory corresponds to:

• a coherent understanding of the system,
• the ability to explain why each part exists,
• the ability to answer questions about the code,
• and above all, the ability to modify it correctly.

Design is therefore not limited to what is stored in a Git repository.
It also includes what exists in the minds of the people working on the software.

V. The Cost of Software Is the Cost of Change  

Another fundamental point addressed in the video is Constantine’s equivalence, popularized by Kent Beck:

The cost of software is essentially equal to the cost of changing it.

This cost depends heavily on:

• the level of coupling,
• the clarity of the design,
• the cognitive load required to understand the system.

The harder a system is to hold in one’s head, the more expensive it is to change.

VI. Where AI Actually Fits in This Process  

AI tools can produce code from:

• natural language instructions,
• constraints,
• tests,
• design rules.

They can generate a working solution.
They therefore participate, to some extent, in the design of the code.

But one essential point remains:
the theory of the system does not automatically end up in the developer’s head.

What the developer truly has is:

• the content of the prompts,
• not necessarily a deep understanding of the generated code.

VII. Modifying AI-Generated Code Raises the Same Fundamental Question  

When it comes time to evolve a system generated by AI, two options exist:

• continue modifying only the prompts,
• or read, analyze, and understand the produced code.

In the second case, the developer must reconstruct the same mental model as with code written by another human:

• understand how the system works,
• identify its abstractions,
• judge its quality,
• and imagine how it could evolve.

As Martin Fowler famously put it:

“Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.”

This observation remains valid, even in the age of AI.

VIII. Raising the Level of Abstraction: A Possibility, Not a Universal Solution  

The video mentions cases where teams use AI as a kind of “advanced compiler,” programming primarily through prompts and textual descriptions.

In such situations:

• the level of abstraction is high,
• the system’s theory is expressed in natural language,
• the implementation language becomes secondary.

This approach can work in certain contexts, but it raises important questions about scalability, consistency, and long-term maintainability.

IX. The Required Skills Have Not Changed  

A central takeaway from the video is that the skills required to get good results with AI are the same as those required without it:

• domain understanding,
• clarity of reasoning,
• design sensibility,
• the ability to reduce coupling.

AI does not eliminate the need for design.
It makes this skill even more visible.

X. Do We Still Need to Learn How to Code?  

Emily Bache’s conclusion is clear.

Since:

• all code is design,
• and an essential part of design lives not in the code but in the mental model,

learning to code remains fundamental—especially early in one’s career.
It is through the experience of writing code that we learn how to design.

Prompting techniques will evolve rapidly.
Design skills, however, will always be needed.

XII. Conclusion  

AI changes how we write code,
but it does not change what gives a software engineer their value.

Design remains a human activity,
because it relies on understanding, judgment,
and the ability to evolve a system over time.

Code can be generated.
The system’s theory must still be built.

Useful Links  

• The Skill That Separates Good Developers from GREAT Ones
  The video that inspired this article, exploring the link between code, design, mental models, and the use of AI tools.

• Tidy First? and work on the cost of change
  A recent book by Kent Beck. Reflections on Constantine’s equivalence and the importance of design in reducing the cost of software evolution.