What happens when building software stops being expensive
AI makes writing code dramatically cheaper. The bottleneck moves to deciding what to build, designing the architecture, integrating, validating and maintaining.
For decades, writing code was the expensive part of a project. Every screen, every integration and every report cost hours from someone who knew how to program. That’s why companies thought twice before building anything of their own, and why standard tools almost always won.
That’s changing fast. Coding agents already write functions, screens, tests and migrations at a speed that wasn’t realistic a few years ago. I work this way every day: AI extends what one person can build.
But cheap code doesn’t mean a cheap system. It means the cost moves somewhere else.
What gets cheaper and what doesn’t
Everything that consists of producing gets cheaper: writing a function from a clear specification, laying out a screen, generating tests, repeating a pattern in a hundred places, translating one data schema into another.
Everything that consists of deciding doesn’t get cheaper, or not at the same pace:
- Understanding how a company really works and where it gets stuck.
- Choosing what to build and, above all, what not to build.
- Designing the data model everything else will depend on.
- Integrating the new with what already works.
- Checking that what the system says is true.
- Keeping it running as the company changes.
When one part of the work becomes almost free, the other becomes the bottleneck.
Where the bottleneck is now
Deciding what to build
If building costs little, the temptation is to build everything. But every piece you add has to be integrated, understood and maintained. The most valuable decision in a project is still the decision not to build something.
Architecture
AI amplifies design, good or bad. A wrong data model now gets replicated faster than ever, across more screens, more reports and more integrations. At Rocio.com the first step was to normalise an archive that lived in 320,093 rows of text metadata. Building on top without doing that would have inherited the problem in every new feature. That’s why modernizing a legacy system starts by understanding and preserving, not by rewriting.
Integration
Systems rarely fail inside a piece; they fail at the seams: between the process and the data, between the data and the tool, between the tool and the AI. Producing pieces faster doesn’t fix the seams. It multiplies them.
Validation
Generating a dashboard takes minutes. Knowing whether its figures are true doesn’t. In AtalayaIQ findings are reconciled independently with hand-written SQL, and each day is compared with the previous day of the same type at the same logging delay. Without that, the system would have announced drops that didn’t exist, with complete confidence. Reliable Business Intelligence starts with definitions, not charts.
Maintenance
A system in production stays alive: providers, models, data and the company itself all change. That’s why designing for change matters. At Rocio.com the AI index is disposable and rebuilt from the database: changing provider doesn’t touch the content.
What this means for the professions
There’s no need for absolute predictions. Programming won’t disappear, just as it didn’t when compilers, frameworks or open-source libraries arrived. What changes is the weight of each task within the work.
More code will probably be written than ever, and so there will be more systems to design, integrate, verify and maintain. Value shifts towards whoever knows what to build, how it fits together and how to check that it works.
The role gaining weight: the Digital Architect
A Digital Architect designs and builds complete digital systems: understands the company’s process, puts its data in order, builds the tools and integrates AI where it helps. And answers for the whole, not for one piece.
It isn’t a new role in essence. What’s new is that, with coding agents, one person can cover both the design and the building of systems that used to need a team, as long as the judgement is clear. Fewer handovers between roles means less context lost along the way.
What changes when you work like this
In practice, the way I work starts from the problem, not the code. How I work comes down to four inputs (the problem, the data, the constraints and the objective) and one output: the system. AI speeds up execution; decisions, verification and accountability aren’t delegated.
If you want to see how this translates into real systems, the case studies are documented with no invented figures.
When building is fast, the bottleneck is judgement.