In this series, we have discussed a range of engineering practices: frontend-backend separation, DDD (Domain-Driven Design), layered architecture, DI (Dependency Injection), RESTful (Representational State Transfer), async & concurrency, SSE (Server-Sent Events), plugin architecture, and Project Rules.
It may look like a lot of technology, but they all ultimately point to the same question:
Now that AI can generate large amounts of code, what is still the most important capability for a programmer?
The answer is shifting from:
“How to write the code”
to:
“How to design a system in which AI can write code correctly.”
1. Code Is Getting Cheaper, Design Is Getting More Expensive
The traditional software development flow roughly looked like:
Understand requirements
↓
Design the solution
↓
Write code
↓
Test and debug
Coding took up a large share of the time. Now, AI can quickly complete:
CRUD
API
SQL
Data models
Unit tests
Business modules
The better AI gets at writing code, the more important one question becomes:
What should be written, and where should that code live?
2. Establishing Boundaries
Looking back at the previous articles, there is a common theme behind all of them:
Frontend-backend separation
→ System boundary
DDD
→ Business boundary
Layered architecture
→ Responsibility boundary
Repository
→ Data access boundary
DI
→ Dependency boundary
RESTful + contract-first
→ Interface boundary
Async & concurrency
→ Execution model boundary
SSE / WebSocket
→ Real-time communication boundary
Plugin / Extension Point
→ Feature extension boundary
Project Rules
→ Telling AI about all these boundaries
So the purpose of architecture is not to add complexity.
Quite the opposite:
Architecture prescribes where complexity should be contained, before the complexity even appears.
3. AI Is Changing Where Programmers Focus
The traditional development model is closer to:
Requirements
↓
Programmer designs
↓
Programmer codes
↓
Programmer debugs
AI-assisted programming is increasingly closer to:
Requirements
↓
Architecture design
↓
Define boundaries and contracts
↓
AI implements
↓
Automated validation
↓
Human acceptance
Programmers aren’t disappearing from the development flow — they are moving further upstream.
In the past, we were more like:
Construction workers.
In the future, increasingly like:
Architect + Project Manager + Acceptance Engineer.
You may not lay every brick yourself, but you must know:
How the house should be designed
Where the load-bearing walls are
How different modules connect
What standards the construction crew must follow
What criteria to accept against at the end
AI is responsible for speeding up construction.
Humans are responsible for ensuring:
The construction is heading in the right direction.
4. Upgrading from “Writing Code” to “Designing Systems”
Developer capability can be roughly understood as several levels:
Level 1
Can write code
↓
Level 2
Can implement features
↓
Level 3
Can design modules
↓
Level 4
Can design systems
↓
Level 5
Can design the rules that let AI continuously build the system
AI is strongest at replacing low-level coding work.
But the higher you go, the more different the problems to solve become:
How should the domain be divided?
Where are the module boundaries?
Which capabilities should be abstracted?
Which parts should be plugin-ized?
Who is responsible for the data?
How should modules depend on each other?
Can it still be maintained if the feature set grows tenfold?
These are not “code generation” problems.
They are:
Architecture problems.
So AI has not diminished the value of architecture skills.
Quite the opposite:
AI has turned architecture skills into an even bigger lever of productivity.
5. The Future’s More Efficient Model: Humans Design, AI Implements
The future software development flow is likely to converge on:
The focus of human work is gradually shifting from:
Implementation
to:
Design + Constrain + Validate.
This is also why the whole series has kept emphasizing Project Rules.
In the past, architecture specifications might have been just documents. Now they can become:
Architecture
↓
Project Rules
↓
AI Context
↓
Generated Code
In other words:
For the first time, architecture specifications can participate directly in code production.
6. Good Architecture Paves the Track for AI
AI’s advantage is speed; architecture’s role is direction.
Without architecture:
Requirements
↓
AI improvises freely
↓
More and more code
↓
Structure gets messier and messier
With architecture:
Requirements
↓
Architecture
↓
Rules / Contracts
↓
AI
↓
Implementation that fits the boundaries
So good architecture doesn’t restrict AI’s capabilities — it:
Keeps AI’s high-speed execution on the right track.
Just as a high-speed train doesn’t really need more freedom to roam, but a clear, stable track system.
7. miniagent Is Also Such a Practice
This series has consistently used miniagent as a case study, not to present some so-called “standard architecture.”
It’s more like an experiment:
Can we first establish clear architectural boundaries, then let AI keep developing within those boundaries?
For example, miniagent organizes core components — database, Repository, Service, Registry, Factory — through ServiceContainer, and initializes the relevant capabilities at application startup.
What’s truly worth paying attention to is not the specific class names, but the development approach behind them:
Design first
↓
Constrain
↓
Let AI implement
↓
Test and review
↓
Keep evolving
This loop is the engineering capability genuinely worth building for AI programming.
8. From “Coder” to “System Orchestrator”
In the AI era, competing with AI on:
Who writes code faster?
matters less and less.
What developers should more worthily improve is:
Understanding the business
↓
Abstracting the domain
↓
Designing the architecture
↓
Defining boundaries
↓
Setting the rules
↓
Breaking down tasks
↓
Directing AI
↓
Validating the results
And so the role shifts from:
Coder
gradually to:
System Orchestrator.
The outstanding developer of the future may not be the one who writes the most code on the team.
More likely, it’s the one who can:
Turn complex business into a clear system, turn the system into explicit rules, and keep AI working according to those rules.
Conclusion
If the entire series were compressed into one sentence, it would be:
Don’t just learn how to make AI write code for you — learn how to design a system worth having AI write.
When the focus shifts from:
“How should this function be written?”
gradually to:
“Should this module exist? Where are its boundaries? What is the interface? Who depends on whom? Where is extension allowed? What rules should AI follow?”
the role has already begun to change:
Coder
↓
Architect
↓
AI Orchestrator
From a producer of code,
toward the commander of the system.
Open Source Code
🪐 Wishing you good luck 🪐