A question that comes up in almost every conversation about AI-built software: "But it's not production-ready after one prompt, is it?"
It is a fair question. And the answer is no, it isn't. But there is a more useful way to think about what is actually happening.
The expectation gap
When people see AI build software, they compare the output to a finished product. A system that has been in production for three years, refined through thousands of bug reports, shaped by real user feedback, hardened by security audits. They look at what the AI produced in two hours and say: this isn't that.
Of course it isn't. Nothing is that on day one. Not when a team of developers builds it. Not when a consultancy builds it. Not when AI builds it.
The comparison they should be making is not to the finished product. It is to the starting point of the traditional process.
The same phases, compressed
Software has always been built in phases. This has not changed. What has changed is how long each phase takes.
Traditional
Requirements gathering. Architecture. Sprint planning. Development. Code review. Testing. Bug fixes. Documentation. Deployment. Iteration.
With Orch
Describe intent. Council deliberates. Architect plans. Builder executes in parallel. Quality gates verify. Grade the result. Iterate. Document. Deploy.
Count the phases. They are the same. Requirements become intent. Architecture still happens. Execution still happens. Testing still happens. Documentation still happens. The sequence is identical.
What is different is the timeline. The first 15,000 lines of code — the foundation that a traditional team produces in three to six months — now exist in two hours. They are not perfect. They were never going to be perfect on the first pass, regardless of who built them. But they are there. Compiling. Type-safe. Documented. Ready to iterate on.
The iteration is where the product lives
No software is finished after the first build. Not traditionally. Not with AI. The difference is where you start iterating from.
Traditional day one
A project plan. A Jira board. Maybe a design mockup. No code. No database. No API. The team starts from an empty repository.
Orch day one
Working code. Database schema with security policies. API routes. Frontend components. Auto-generated documentation. Quality grade. A list of builder-suggested improvements for the next iteration.
The team that starts from zero will iterate for months before they have what the AI produced on day one. The team that starts from 15,000 lines iterates from a position of substance, not a position of nothing.
And here is the subtle but important point: the iteration cycle itself is also compressed. A change that takes a developer a day takes Orch seventeen minutes. We know this because the platform recently built 7,700 lines of its own SaaS infrastructure — brownfield, on top of a 60,000-line existing application — in exactly seventeen minutes. Zero type errors. Zero regressions.
The quality question
"But is the code any good?"
This is the right question. And the answer matters more than the speed.
Most AI coding tools cannot answer this question honestly. They produce code and say done. They do not tell you when the code is incomplete, when the architecture is fragile, or when a security assumption is wrong. They optimise for the appearance of completion.
Orch answers the question structurally. Every build passes through twelve quality gates. The platform grades itself — honestly. An A means it is clean. A B means it works but has gaps. The platform tells you what those gaps are. It suggests what to fix next. It learns from its own failures and applies those lessons to the next build.
That honesty — "here is what I built, here is what grade I give it, and here is what I would improve" — is more than most human teams provide on day one of a project.
The real objection
When someone says "it's not production-ready from one prompt," it is worth understanding why that expectation exists. It is a natural one.
The demos are extraordinary. You type a sentence and watch software appear. It is easy to conclude that the finished product should also appear in one step. The gap between the demo and production feels like a failure of the technology when it is actually the normal distance between a first draft and a final product — a distance that exists regardless of how the first draft was created.
Once you see AI-built software as the same process you already know — requirements, architecture, build, test, iterate — just running at a fundamentally different speed, the value becomes intuitive. You are not skipping steps. You are compressing them. And you start from a foundation, not from nothing.
What changes
When the first phase of a project takes hours instead of months, something shifts in how organisations think about software.
Projects that were too small to justify a development team become viable. A custom tool for a twenty-person department. A dashboard for a specific workflow. An internal portal that replaces a shared spreadsheet. These were never worth a six-month investment. They are worth a six-hour one.
Projects that were too risky to attempt become testable. "What if we built X?" is no longer a quarter-long commitment. It is an afternoon. Build it. Test the idea. If it works, iterate. If it does not, you lost hours, not months.
And projects that traditionally required a full team become achievable by a single operator. Not because the AI replaces the team. Because the AI compresses the timeline to the point where one person — directing the platform, setting the quality bar, governing the output — can do what previously required coordination across five or ten people.
The process has not changed. The economics have.
Oscar is the founder of orch.build, a governed autonomous development platform.
Contact: oscar@interstice-advisory.com