A quarter of your commits. Duplication up 81%. Refactoring down 70%.
Those are not opinions. They come from an analysis of 623 million real code changes made between 2023 and 2026, and read together they describe one thing: code is accumulating faster than anyone is consolidating it.
Nothing in that list is about code that does not work. All of it is about code that cannot be changed - and that is a different problem, one that arrives four months late and attached to nobody.
The generator cannot make this decision for you
Not because it is bad at architecture. Because deciding where a piece of code belongs requires knowing things about your system, your team, and your next six months that are simply not in the file it was shown.
Supplying those things is the job. It has a name, and the name is architecture.
The S.H.A.P.E. Method
- S - SURVEY. Read the system before you add to it. Thirty minutes per area, one page, once.
- H - HOLD. Decide the boundaries and what may cross. Three to seven boxes. Every arrow says what crosses, in what shape, in which direction.
- A - ARTICULATE. Write the decision down, including the alternatives you rejected. Five boxes, one page, never edited after acceptance.
- P - PROMPT. Hand the generator your structure instead of asking it for one. Never ask what the best architecture is - a question with no context returns the architecture of a company much larger than yours.
- E - EVALUATE. Measure drift with four numbers, monthly, in fifteen minutes. The slope is the signal, not the value.
Then six chapters on the decisions you actually face
Where does this code go? What talks to what? Where does the data live? What happens when it fails? How does it change? Who can touch it?
Each with twenty-four ready-to-use prompts, a worked example of how it goes wrong in a real codebase, and what good looks like when it is going right. 200 prompts in total, numbered and indexed.
What this book will not do
It will not give you a stack. There is no recommendation here about which database, which framework, or which cloud - those answers expire and the questions do not.
It will also not tell you that AI-assisted development is a mistake. A quarter of commits already involve it and that share is rising. The position here is narrower and more useful: the generator is extraordinary at producing code and structurally unable to decide where it belongs.
Written for you if
- You can build features but freeze when someone asks where something should live
- You are self-taught, or came through a bootcamp, and the architecture part was never covered
- You are shipping fast with AI and quietly suspect the codebase is getting away from you
- You have to survive an architecture review and do not know what you will be asked
Also included
Five fill-in instruments: a thirty-minute survey, a boundary map, a five-box architecture decision record with a worked example, a reusable prompt frame, and a four-number drift dashboard. A twenty-minute architecture review reconstructed minute by minute. And a thirty-day plan that starts on Monday.
If you have three hours rather than three weeks: read Chapter 3, then Chapter 6, then Appendix B, and draw the boundary map for whatever you are working on. That is most of the practical benefit of this book, and it fits in an afternoon.
George Chu holds a Master of Engineering in Software Engineering from Peking University and is a Senior Member of the IEEE.
