Neel Shah, VP of Software Development
May 7, 2026
The Old Economics of Software
Uncle Bob has often made a simple but powerful point about software: software is not like manufacturing.
In manufacturing, there is a clear difference between design and production. Someone designs the product first. Then a factory produces copies of it. The production cost matters because each physical item requires materials, labor, logistics, and distribution.
Software does not work that way. Once software is written, the cost of producing another copy is almost zero. You do not need a new factory line to ship another copy of an application. You do not need raw materials to deploy another instance of a service. You can build, copy, deploy, and distribute software at extremely low marginal cost.
So the real cost of software is not production. The real cost is design.
That is the part Uncle Bob was getting at. Programmers are not factory workers producing units. Programmers are designers. The code itself is the design artifact. The source code is not merely a blueprint for the real product. In software, the source code is the most precise expression of the product’s design.
This matters because the expensive part of software is not writing the first version. The expensive part is changing it. A system that is well designed can absorb change. A poorly designed system resists change. Every new feature becomes harder. Every bug fix becomes riskier. Every small requirement creates side effects in unexpected places. Eventually, the team slows down, not because people are lazy, but because the design has become too expensive to work with.
| Feature | Manufacturing | Software |
|---|---|---|
| Process | Design happens first | Design is continuously expressed through code |
| Production Cost | Expensive | Copying and deployment are relatively cheap |
| Marginal Cost | Units require material and labor | Additional copies have very low marginal cost |
| Key Focus | Factory efficiency matters | Changeability matters |
| Failure Impact | Bad production increases unit cost | Bad design increases future change cost |
Production is cheap.
Design is expensive.
Bad design makes future change even more expensive.
What AI Has Changed
Now AI enters the picture. Tools like GitHub Copilot, Cursor, ChatGPT, Claude, and other coding assistants can generate code quickly. They can create endpoints, write unit tests, and suggest refactorings.
So it is tempting to say: “Uncle Bob was right before, but now AI has made design cheap too.” I do not think that is quite right.
AI has absolutely made code production cheaper. In many cases, dramatically cheaper. Boilerplate that used to take hours can be generated in minutes. AI has also made design exploration cheaper. A developer can ask AI to compare three architecture options or identify tradeoffs between event-driven design and direct API calls. That is valuable, but design exploration is not the same as design responsibility.
What became cheaper vs. what did not
| Area | Has AI made it cheaper? | Why? |
|---|---|---|
| Boilerplate code | Yes | AI can generate repetitive code quickly |
| First-draft implementation | Yes | AI can turn intent into working code faster |
| Unit test drafts | Yes | AI can generate common test cases and scaffolding |
| Local refactoring | Somewhat | AI can suggest and apply mechanical changes |
| Design exploration | Yes | AI can compare options and surface tradeoffs quickly |
| Domain modeling | Partially | AI can help, but humans must validate business meaning |
| Architecture judgment | No | AI does not own tradeoffs, risk, or long-term consequences |
| Operational responsibility | No | Humans still own supportability, security, and failure modes |
A Real-World Example: Repeated Compression
Imagine an assessment platform where a candidate’s testlet response includes both the current state and the full set of test items. The item payload can be very large because it includes exhibits, images, and tables. On paper, the implementation looks reasonable: The API returns the answer, the response is compressed, and the client receives it. AI could easily generate this code.
But the system has a design problem. If the server repeatedly compresses the same large item payload for every candidate, the CPU becomes the bottleneck. In a real case, CPU usage hit 80%. Once static content was separated from the response, CPU dropped to 15–20%.
The Real Issue
| Surface-level interpretation | Deeper design issue |
|---|---|
| The endpoint is slow | Static and dynamic data are bundled together |
| Compression is expensive | The same large content is repeatedly compressed |
| CPU is high | The server is doing avoidable repeated work |
| We need cleaner endpoint code | We need better content boundaries |
| We should optimize the controller | We should separate candidate state from static item content |
AI can help brainstorm these solutions, but AI does not automatically know the correct boundaries or security requirements of an exam platform. That is design judgment.
Why AI May Make Design More Important
When code was slower to produce, implementation friction created a natural space for thinking. Now that friction is gone. It is easier to say, “Generate this,” or “Build another service.” The danger is that the system grows quickly without becoming more coherent.
The scarce resource is no longer typing ability. It is judgment. Great developers will use AI to think better, asking it to explore alternatives and challenge assumptions rather than just writing code.
Weak AI Use vs. Strong AI Use
| Weak AI workflow | Strong AI workflow |
|---|---|
| “Generate a faster version of this endpoint.” | “What design alternatives would separate static and dynamic data to reduce repeated compression while preserving authorization?” |
| Treats AI as a coding machine | Treats AI as a design assistant |
| Optimizes locally | Questions the boundary |
| Focuses on implementation speed | Focuses on long-term system cost |
Conclusion
AI makes code cheaper; it does not make consequences cheaper. As senior engineers and architects, our value is no longer just production volume—it is directing the work. We must ensure the code belongs in the system. Software production was already cheap; AI made it almost free. But design judgment is still expensive.
Sources
Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall, 2017.
Robert C. Martin, “Software on the Cheap,” Uncle Bob Consulting LLC.
Eirini Kalliamvakou, “Research: Quantifying GitHub Copilot’s Impact on Developer Productivity and Happiness,” GitHub Blog, September 7, 2022.
DORA, 2025 State of AI-Assisted Software Development Report, Google Cloud / DORA, 2025.
Martin Fowler, “The Role of Developer Skills in Agentic Coding,” martinfowler.com, March 2026. Page 5