What Changes When Software Becomes Cheap to Build?

Last week, I built a website as a hobby project for the son of some friends, who wants to promote himself as a DJ. Generating a website with AI is hardly news, and the fact that my last serious software development efforts were way more than a decade ago doesn’t make it particularly remarkable either. I was less interested in whether AI could build a website than in what the experience might tell me about how we think about architecture.

What surprised me was what happened once I took an approach that went beyond generating a few pages.

Before building anything, I used ChatGPT to think through and specify what I actually wanted: the goals, requirements, architecture, constraints and future features I wanted to anticipate. I then used these specifications as context for working with Claude Code. What emerged was a non-trivial, although relatively small, software project. The solution consisted of a website (Astro framework), with responsive design and image optimisation, source control repository (GitHub), continuous deployment on a cloud hosting platform (Vercel) and, in one of the later iterations, integration with a content management system (Sanity). A simple diagram of the solution can be found below in Figure 1.

The CMS is a useful example of what surprised me. I had considered needing one in the future, but built the first version of the solution without it. When I decided to add it in a later iteration, with AI doing much of the implementation, it turned out to be incredibly easy.

This didn’t tell me whether the original implementation was well designed for change. Something being easy to modify is not necessarily proof of good architecture. But it did give me another insight: the distance between thinking of a change and seeing it working had become remarkably short.

When producing becomes easier than reviewing

During this process, my own role changed. I spent almost no time writing code and much more time deciding what I wanted. I refined requirements, considered alternatives, made choices, set constraints, reviewed results and iterated through this process multiple times.

At first, I tried to follow much of what the AI produced. My background in software engineering helped, but as the project progressed, I increasingly reviewed outcomes instead of every implementation detail. AI produced and modified software faster than I was willing to spend time thoroughly understanding each change.

For a DJ website, this seemed like a reasonable trade-off, but for business-critical enterprise software it clearly isn’t enough. That initially led me towards a question about software quality assurance. If humans inspect less of what is being produced, perhaps requirements, architecture, automated testing, policies and other controls need to carry more of the burden.

But much of that isn’t new. We already depend on software that nobody fully understands. Modern systems contain layers of frameworks, cloud services, libraries and third-party products. Testing, security controls, architecture constraints and automated verification already help us deal with that complexity.

AI may intensify the problem, but it doesn’t create it.

When building becomes part of thinking

AI-assisted development is changing the economics of producing code and documentation. None of this is a new economic insight. What interested me was experiencing what that change in economics does to the way you make decisions.

In my case, the marginal cost of another experiment was almost invisible. I was already paying for ChatGPT and Claude subscriptions, and adding the CMS did not require additional development capacity or noticeable additional usage costs. I could decide to try it, see the result and then decide whether to continue or adapt. Looking from this perspective, building itself became part of the exploration. Instead of analysing a possibility, making a decision and then implementing it, I could use implementation to learn:

explore → build → observe → learn → adapt

This kind of feedback loop doesn’t introduce anything new. Concepts such as prototyping and agile development, and ideas such as build–measure–learn from The Lean Startup, have been around for a long time. Using working software as a way to learn isn’t new either. What may be changing is how often building becomes an economically sensible way of exploring a decision.

At enterprise scale, cheaper code production doesn’t remove costs elsewhere. AI usage, platforms, maintenance, security, governance and managing a potentially more complex technology landscape still have to be accounted for. But that does not change the basic observation: the cost of trying something in software may fall substantially. That could change some of the conditions under which architecture operates.

Software alone isn’t the enterprise

There is also an important limit to this observation. Almost all the complexity of my project was in the technology itself, while enterprise change is very different.

Imagine using AI to create the software for a new customer onboarding process in days rather than months. Customers still have to adopt the change. The organisation may still need to change responsibilities and employee behaviour. Processes, data and controls may still need to change as well.

AI can make creating and changing software faster without making all the other required changes equally fast. As software production becomes less of a constraint, those other dimensions may become relatively more important constraints on change. And that is where a potentially interesting Enterprise Architecture question emerges.

Enterprise Architecture exists to connect strategic intent to coherent change across capabilities, organisation, processes, information and technology. Nothing in my experiment convinces me that AI creates a fundamentally new purpose for it. It may, however, change the relative cost of some of the actions and choices involved.

Beyond the cost of building

My experiment started with a fairly technical surprise: I could build much more software than I expected without doing much of the programming myself.

The economics behind that are not new. What I had not appreciated until experiencing it was how a lower cost of building can change the relationship between thinking and doing. Some questions that previously required substantial analysis before implementation may increasingly be explored through implementation itself.

In an enterprise, that possibility runs into a much broader reality. Software is only one part of change, and making it cheaper does not make organisational change, data, processes, controls or strategic coherence equally cheap.

The question it left me with is broader:

If software becomes dramatically easier to create and change, what does that mean for the decisions we make in architecture, and how we arrive at them?

I don’t yet know the answer. But it seems like a question worth exploring.