Something important is happening in software development. For the first time, it's possible for a person who isn't a developer to describe what they need and get working, production-grade software back — in hours, not months.
This changes who can build software. It changes what's worth building. It changes the economics of operational capability for every organisation that has lived with spreadsheets and manual processes because the alternative was a six-month project and a seven-figure budget.
But it only works if the output can be trusted. And that's where the industry has a gap.
The trust gap
The technology to generate code autonomously has arrived. What hasn't arrived — not yet, not at scale — is the confidence that the output is safe to deploy.
The industry has moved fast — and rightly so. But the quality of AI-generated code — its security, maintainability, architectural soundness — hasn't always kept pace. That's not a criticism of the tools. It's the natural consequence of optimising for speed before the verification layer existed. Anyone who has reviewed AI-generated code in production has seen the pattern: it compiles, it runs, and somewhere underneath there's a security assumption that wasn't checked or an architectural shortcut that will cost weeks to unwind later.
The generation capability is already very, very good — and will only get better. The verification hasn't kept pace.
We believe this gap closes — not by slowing down, but by building intent-based oversight into the process itself.
What we mean by governance
Governance, in our context, is not bureaucracy. It's not committees or approval chains. It's three structural properties of how software gets built.
Deliberation before building
Before code is written, the system examines the proposed build from multiple perspectives. Security, cost, domain expertise, architectural risk. Each perspective scores its confidence. Risks are surfaced that the original description didn't anticipate. This takes 3-5 minutes.
The value isn't in the deliberation itself — it's in preventing the architectural mistakes that, in traditional development, surface at week four and cost months to fix. Three minutes of deliberation saves weeks of rework.
Transparent quality signals
Twelve mechanical checkpoints run after every build: type safety, contract verification, spec compliance, completeness checking, code review, intent matching. Each produces a signal. The signals compose into a grade.
The grade is transparent. If nothing was verified, the grade reflects that — not with an A, but with a B at best. An A requires assertions that actually pass, not just code that compiles. This matters because the grade is what the operator reads to decide whether to ship. If the grade inflates, the operator ships broken software and trust erodes. Everything downstream depends on honest signals.
Learning from every build
Every build produces two outputs: the software, and the lessons. Recurring failure patterns are tracked — not "test failed" but "builds on this type of codebase consistently break when this component is modified." Learned patterns are extracted: "when the project involves sensitive data, always include a tokenization layer." These patterns are scored by confidence and activation count. They compound.
After fifty builds, the platform has accumulated 174 learned patterns and 20 tracked failure modes. The fifty-first build starts not from zero, but from everything the platform has ever learned. The cost decreases. The quality increases. The institutional knowledge deepens with every project.
Who this is for
We built this for people who need software but don't think of themselves as software people. Or those who know they need something but the cost (or alternative cost for their attention) is prohibitive at a three month project with five-to-six-figure budgets.
A company with 200 employees that needs a commercial dashboard but has never had a development team. They've lived with spreadsheets because the alternatives were too expensive and took too long.
A founder who needs to ship a product this month but wants something that works under real use — not just in a demo.
An operator — a CFO, a commercial director, a portfolio manager — who knows exactly what needs to be built but has always had to translate that knowledge into a developer's language, then wait months to see if the translation was right.
For these people, the value isn't faster coding. It's access to capability that was previously out of reach. Software they actually need, built in a timeframe they can act on, at a cost that makes sense.
Intent, not just specification
There's a reasonable argument that if AI writes the code, humans should focus on writing better specifications. We agree with the instinct. But we think it doesn't go far enough.
A specification — with file paths, acceptance criteria, dependency graphs — is still developer thinking, moved upstream. Most of the people we serve don't think in those terms. And they shouldn't have to.
We've been exploring what happens when the input is pure intent. A 300-word description of a health intelligence concept — no technical spec, no design brief, no wireframes — produced 4,161 lines of working code in 41 minutes. The platform chose the architecture, designed the analytical engine, generated realistic data, and produced a user interface that nobody specified. It drew on biomedical domain knowledge to make clinically sensible decisions — correlating medication timing with vital sign changes, evaluating supplement efficacy against actual lab markers.
Nobody told the platform about HDL-to-triglyceride ratios. It knew — because that knowledge is embedded in the model the platform builds with.
At the other end of the spectrum, a detailed 992-line specification produced a 26,669-line production application in two overnight builds. Fully typed. Row-level security on every table. Hash-chained audit trail. One page of spec, one working application.
The point is that both work — because the governance layer operates regardless of input detail. Quality gates, failure registry, learned patterns, transparent grading. Whether you describe your intent in three sentences or three hundred tickets, the build is governed the same way. That's what makes intent-driven development safe. Without governance, a three-sentence input would be reckless. With it, it's efficient.
The compounding thesis
Most software tools improve when their team ships an update. A platform that learns from its own builds improves every time it runs. The improvement isn't just in the code — it's in the accumulated knowledge: patterns, failure modes, domain-specific insights from real projects across industries.
That knowledge exists in the data corpus, not in the codebase. It's the thing that makes the difference between a tool that generates code and a platform that builds production software. And it compounds — which means the gap between where the platform is today and where it will be in twelve months is not linear.
This compounding happens at two levels.
At the platform level, every build across every client makes the system smarter. Patterns learned from a healthcare build inform a supply chain build. Failure modes discovered in one domain prevent mistakes in another. The platform's institutional knowledge grows with every project.
But the more important compounding happens at the client level. Every build a client commissions produces not just software, but a proprietary data corpus: reasoning history, architectural decisions, domain-specific patterns, learned failure modes. That corpus belongs to the client. It accumulates. It makes their next build faster, cheaper, and more architecturally coherent than the last.
This is where the strategic argument lives. In an era where AI-native operations are becoming a competitive differentiator, the organisations that start building their proprietary corpus today — their owned software, their owned data, their owned institutional knowledge — are creating an advantage that compounds with time. The gap between an organisation with a 12-month corpus and one starting from zero is not 12 months of calendar time. It's 12 months of accumulated intelligence that the latecomer cannot shortcut.
The cost of waiting isn't just delayed capability. It's a compounding disadvantage.
What we're working on
We're at the beginning. The platform exists — hundreds of builds across healthcare, supply chain, financial analysis, project management, and scientific computing, all produced autonomously with zero human-written code. And, of course, it builds itself.
But "works" is the starting point, not the destination.
What comes next: industry-specific compliance (healthcare, financial services — the domains where the governance layer has the most value). Self-serve access for founders and small teams. Remote onboarding for enterprises. And the continued accumulation of institutional knowledge that makes every build better than the last.
The question we're answering isn't "can AI build software?" — it can. The question is: can it build software you'd trust with your clients' data, your company's reputation, and your own professional credibility?
We believe it can. When the build is governed.
Oscar is the founder of orch.build, a governed autonomous development platform.
Contact: oscar@interstice-advisory.com