Drop a Spec. Ship a Feature.

A front door for change

Every company already has a place where feature ideas go to wait. It is called the backlog, and it is where good ideas go to be forgotten. The self-build wizard is a different kind of front door — one that takes the idea seriously the moment it arrives.

You bring whatever you have. Most people bring a Markdown file: a paragraph of intent, a few bullet points of behavior, maybe an acceptance criterion or two. Some bring more — a design export, a rough HTML mockup, a screenshot of a competitor’s screen, a spreadsheet of the fields they want. The wizard accepts all of it, and reads the supporting files as carefully as the prose. They are not decoration; they are evidence of intent.

What makes this more than an upload box is that the system on the other side is not a blank model. It is connected to the running product — it has read the schema, the API contracts, the component library, the audit rules, the naming conventions. When your spec says “add a status field to the customer record,” it already knows what a customer record is, where it is stored, which screens render it, and which of them are access-scoped. The spec lands in a system that understands the ground it is standing on.

Review before build

The first thing the system does with your spec is refuse to build it. Not out of stubbornness — out of the same instinct a good engineer has when handed a one-paragraph ticket. It reads the spec the way a reviewer reads a pull request: looking for what is unstated, contradictory, or quietly impossible.

A spec review turns up the things specs always hide. The happy path is described; the empty state is not. The new field is defined; whether it is required, who can edit it, and what happens to the ten thousand records that already exist without it are not. The mockup shows a button; the spec never says what it does when the user lacks permission to use it. These are not edge cases. They are the actual work — the reason “just add a field” becomes a two-week discussion three days in.

The system produces a written review before it touches anything: here is what I understood, here is what I can build directly, here is what contradicts something already in the product, and here is what I cannot proceed on until you decide. That review is the artifact that used to require a grooming meeting and never quite happened.

The interview

This is the part that feels genuinely new. Instead of guessing at the gaps, or building the wrong interpretation and waiting for someone to complain, the system asks. It turns its review into a short, specific interview and puts the questions to the person who submitted the spec — the person who actually knows the answers.

The questions are not generic. They come from the collision between what you asked for and what the system already knows about itself. Three questions, three answers, and a spec that was 60% complete becomes executable. No meeting was scheduled. No requirements document was written and then ignored.

And because the interview is recorded alongside the spec, the decisions have a home. When someone asks in six months why Support can’t edit renewal risk, the answer is not folklore. It is on the record, dated, attributed.

Build, in isolation

Only now does the system write code, and it does so somewhere it cannot break anything. Each build happens in an isolated working copy of the codebase — its own branch, its own sandbox — never in the live tree that real users are touching. This is the boring architectural decision that makes the whole thing safe: a build in progress is invisible to production by construction, not by luck.

Inside that sandbox the system does what an engineer would do. It changes the schema, writes the migration for the existing records, adds the field to the API contract, updates the screens, wires the permission checks the interview settled, and connects the alert to the digest that already exists. It runs the type checker and the tests in its own copy and reads the output. If the build is red, it does not surface it to you; it reads its own failure and tries again.

New behavior arrives behind a feature flag, dark by default. The feature can exist in the codebase — merged, tested, deployed to staging — while being switched off for everyone. That separation, between “the code is present” and “the feature is on,” is what lets the system move quickly without asking you to trust it blindly.

QA is a gate, not a phase

The word “done” is where most automation quietly fails. A system that marks work finished the moment the code compiles will happily ship a feature that compiles and does the wrong thing. So the wizard does not get to declare its own work complete. It has to pass a gate it does not control.

The gate is made of checks that describe the feature’s actual job, not its syntax. Does the new field save and reload? Does the empty state read the way the interview said it should? Does a Support-role session see the field but fail to edit it? Does a “High” risk change actually land in the digest? A failure does not lower a score — it reopens the work, with the failing check folded back in as the next thing to fix.

Only when the gate is green does the system do the last thing it is allowed to do on its own: post the working feature to staging and notify the people who need to see it — a link to a running feature and a plain-English report of what it built, the spec it came from, and how it knows each requirement works.

Why this, why now: three curves crossed

None of this was buildable eighteen months ago, and it is worth being precise about what changed, because “AI got better” is not an answer.

First, models learned to hold a whole codebase in their head. The bottleneck was never generating a function; it was understanding the fifty files that function has to be consistent with. The context to reason across an entire system — its contracts, its conventions, its history — is now something a model can actually carry.

Second, systems learned to describe themselves. A build agent is only as safe as its map of the thing it is changing. When the product exposes a live, machine-readable account of its own schema, permissions, and contracts, the agent stops guessing and starts referencing. Self-knowledge is what turns “generate plausible code” into “make this specific system do this specific thing.”

Third, deploys became reversible. Feature flags, isolated build copies, health-gated promotion, and one-command rollback are not new — but together they change the risk math. When any change can be turned off instantly and no build can touch the live tree while it is being built, you can let a system move fast, because the cost of it being wrong is a switch, not an outage.

The spec that gets built is almost never the spec that was written. The gap between them is where every “that’s not what I meant” lives.

This piece is honest about the line

It would be easy to describe this as software that builds itself, and that description would be a lie of omission. There is a person in this loop, on purpose, and the line they hold is the most important part of the design.

The developer is not surprised by any of this. Nothing runs in the dark. The self-build wizard operates in full view of the engineering team — every spec, interview, build, and check is visible as it happens, and the same guardrails that apply to a human contributor apply to the system. It works in isolated copies, it cannot merge anything that is not green, and there is a hard boundary of protected areas — the parts that govern safety, access, and the approval machinery itself — that the automated build simply cannot modify. A change that reaches for that boundary is stopped and handed to a human, every time.

And production is never automatic. Staging is where the system’s authority ends. Promotion to production requires a human signature — and where a change touches something that needs more than one set of eyes, it requires everyone whose approval is needed, not a majority and not a default. The system’s job is to make that signature an easy, well-informed yes. The decision itself stays where it belongs.

What you get is not a company without engineers. It is a company where the distance between “I have an idea” and “there is a working version to look at” collapses from weeks to a day — and where human judgment is spent on the only two questions that were ever worth a person’s time: is this the right thing to build, and is this version good enough to ship?