“Can you build me an app?”
“What should it help someone do?”
“Let us not overcomplicate it. Just make something simple.”
That exchange used to end with a project brief, a budget conversation, or a polite retreat. Now it can end with a working interface before anyone has agreed on the problem.
AI made software development more accessible. It did not make software thinking optional.
Most people believe AI changed software because it writes code. I think the more important change is that it exposed where the value always was: judgment.
When the cost of producing code falls, the decisions around the code become more visible. What should exist? Who is it for? What should happen first? What could go wrong? Is software even the right answer?
Those questions were always part of building good products. They were simply easier to hide when implementation was the obvious constraint.
Working software and good software are different achievements
Software is not a chain of code. It is a chain of decisions.
Business decisions become product decisions. Product decisions become experience decisions. Those become system and engineering decisions. Code is where the decisions finally become executable.
If the earlier decisions are weak, faster code only helps the team arrive at the wrong destination sooner.
Consider a simple appointment-booking product. The code may work perfectly, but the product can still fail because it assumes every service takes the same amount of time, ignores cancellations, hides the information people need before committing, or asks someone to create an account before they understand the value.
None of those are primarily coding problems. They are decisions about the business, the user, and the system.
Working software completes an intended function. Good software earns a place inside somebody's life or work. It handles the awkward cases, makes the right action understandable, fits the surrounding process, protects people when something goes wrong, and remains operable after the demo.
Good software is judgment made visible through a working system.
Access moved. Standards did not
Website builders and no-code platforms had already widened access to software creation. AI accelerated that shift. A person can now describe an interface, generate a working version, connect services, and iterate without following the traditional route into engineering.
That is genuinely important. More people can test an idea that previously stayed in a notebook or waited for a budget.
There is also evidence that AI can improve bounded development work. In a controlled GitHub study of 202 experienced developers, participants using Copilot were more likely to pass all the unit tests in a specific API exercise, and blind reviewers rated their code slightly higher on readability, reliability, maintainability, and concision. The task was narrow and the research came from the product's maker, so it should not be treated as proof that every team or codebase will see the same result. It does show that the production advantage can be real.
But access to a kitchen does not make every meal good. Access to a camera does not make every photograph meaningful. A tool can remove part of the production barrier without supplying the context, taste, or judgment that gives the work value.
The same is true here. A product can look complete while its assumptions remain untested. It can have polished screens and no clear reason to exist. It can technically perform a task while creating more work around it.
AI moves the bottleneck
For a long time, teams could blame the difficulty of development for slow progress. Sometimes that was true. Sometimes the real problem was that nobody had agreed on the problem, the priority, or what success meant.
AI does not remove that ambiguity. It moves it downstream.
Give a model a vague instruction and it will often return something plausible. Plausible is dangerous because it can feel finished before anyone has examined the choices underneath it. The interface works, the buttons respond, and the meeting briefly acquires the dangerous confidence of a demo.
The wider evidence reflects this tension. Google's 2025 DORA research, drawing on survey responses from nearly 5,000 technology professionals and more than 100 hours of qualitative data, found positive relationships between AI adoption, software delivery throughput, and product performance. It also found a continuing negative relationship with delivery stability. DORA's interpretation is useful: AI tends to amplify the system in which it operates. Strong feedback loops, testing, version control, user focus, and clear workflows help teams convert speed into value. Weak foundations allow faster output to expose more weaknesses downstream.
This is why specification matters more as execution becomes easier. A useful specification is not bureaucracy. It is a way of making decisions explicit: the user, their situation, the outcome, the boundaries, the evidence of success, and the cases that should not be treated as normal.
The value is not in writing a longer document. It is in reducing the number of important assumptions that remain invisible.
The interface is only the visible layer
Think about familiar products. Duolingo is not memorable because it can store language exercises. Its streaks, reminders, progression, and feedback shape a particular relationship with practice. Airbnb is not simply a database of places to stay. Trust, identity, reviews, payments, expectations, and support are part of the experience. Shopify is not only a collection of commerce functions. It helps a merchant move from an idea towards operating a business.
The engineering matters enormously. But the value people recognise comes from how many disciplines have been joined around a useful outcome.
That is why copying a visible interface rarely creates the same product. The screen is the surface of a much larger decision system: policies, data, incentives, operations, exceptions, support, trust, and feedback.
AI can reproduce more of the surface in less time. It cannot decide whether the system underneath deserves to exist.
Five tests before calling software good
The shift from prototype to product becomes clearer when we stop asking whether the software works and run five harder tests.
| Test | Question | What failure looks like |
|---|---|---|
| Worth | Does this solve a meaningful problem for a specific person? | A polished feature searching for a reason to exist |
| Behaviour | Does it fit how people actually decide and work? | Users create workarounds, hesitate, or abandon the flow |
| System | Are data, handoffs, permissions, dependencies, and exceptions designed? | The interface succeeds while the surrounding process fails |
| Operation | Can someone support, maintain, govern, and improve it? | The demo works, but ownership and recovery are unclear |
| Evidence | Can we tell whether it created the intended outcome? | Activity is measured because value was never defined |
These tests are deliberately wider than code quality. Code can be elegant while the product fails the worth test. The experience can be attractive while the operation test remains unanswered. A prototype can pass a happy-path demonstration while the system test is quietly waiting outside the meeting room.
The tests also give non-technical builders a more useful role. You do not need to write every line of code to ask whether the problem is real, the behaviour is understood, the exceptions are covered, the product can be operated, and the result can be measured.
Knowing what not to build
AI encourages a particular kind of optimism: if we can build something quickly, perhaps we should.
But one of the strongest product decisions is still to avoid creating software where a clearer process, a better policy, or a simpler tool would solve the problem. A bespoke dashboard may be less useful than one well-designed weekly review. An AI assistant may add friction where a sensible default would remove the decision entirely.
I have argued elsewhere that teams should understand the opportunity before choosing the technology. That principle becomes more important, not less, when technology is easier to produce.
The question is not “Can AI build this?” It is “Is this worth building, and what would make it genuinely good?”
Restraint is not a lack of ambition. It is the discipline of refusing to turn every inconvenience into another product somebody must learn, maintain, secure, and eventually replace.
The builder's role is moving up the stack
As execution accelerates, builders need to become more deliberate about the work around it:
- Understand the business constraint, not only the requested feature.
- Observe how people behave, not only what they say they want.
- Map the system around the interface, including handoffs and exceptions.
- Write specifications that expose choices and uncertainty.
- Test the smallest useful version before expanding it.
- Verify what AI produces rather than treating generation as completion.
This is a version of the broader shift I described in redesigning how we work because of AI. The advantage does not come from adding a faster tool to an unchanged process. It comes from rethinking where human attention creates the most value.
The work is moving up the stack from producing components to directing a system: deciding what deserves to exist, giving AI enough context to help, evaluating what it produces, and accepting responsibility for the outcome.
That does not make engineering less important. It makes the relationship between engineering and every other discipline harder to ignore.
Building became easier. Building well did not
I am excited that more people can create software. Someone with direct experience of a problem can now explore an answer without waiting for permission from a technical gatekeeper. That will produce new businesses, internal tools, community services, and strange experiments that would otherwise never exist.
It will also produce a great deal of unnecessary software.
The difference will come from the disciplines surrounding the code: product thinking, systems thinking, human behaviour, business judgment, positioning, and the ability to direct and verify AI.
Those are not supporting skills for modern builders. Increasingly, they are the work.
The barrier to creating software has fallen. The standard for deciding whether it is good should rise.
In the next article, I explore the six disciplines every AI product builder should deliberately develop. The connected AI product operating system shows how those disciplines can become a controlled way of working rather than a collection of good intentions.