Building with AI, answered in full.

The method's delivered evidence is greenfield: the two-week build started from a blank repository. The steps are designed to carry across to a running system, with three changes. The corpus grows: the existing system's behaviour becomes part of the requirement set, converted to structured markdown the same way, so the model reasons over what must be preserved as well as what must change. Verification hardens: characterisation and regression tests are written against current behaviour before anything is modified, and they join the pipeline's quality gates as hard checks. And the increments shrink: changes land behind existing interfaces in smaller steps, inside your branch protection and review process, rather than as a rebuild. What does not change is the control set: static analysis, dependency and secrets scanning, the model-led security review roughly every fifth prompt, and human review before merge. When the full method has run against a brownfield estate we will publish the write-up, dated, like the greenfield one.

It means treating the requirements as the source code and the model as the compiler. Every requirement is converted into structured markdown, stored where both humans and AI can read it, mapped for relationships, and interrogated for gaps and contradictions before any code is written. Only then does the model build against the full requirement set. It is the opposite of writing software conventionally and using AI as a faster autocomplete.

On a live engagement in specialty insurance, a product representing roughly twelve months of prior work was rebuilt as a working proof of concept in two weeks. The typical iteration curve is two to three days to reach roughly 80% correct, and a further three to five days to reach roughly 95%. Turning a proof of concept into a production system is a separate phase, and on that engagement it is scoped at four to six weeks with a dedicated team.

Because a model cannot reason across a corpus of PDFs, diagrams and slide decks that it has to re-read as attachments each time. Markdown makes the whole requirement set addressable, diffable and version-controlled, so the model can hold all of it at once, humans can review changes, and the canonical requirements stay synchronised with the code as things change.

Asking the model to read every requirement file and flag gaps and contradictions before writing any code. It is the step almost everyone skips. A contradiction found at that point costs a conversation with the business; the same contradiction found after the build costs the build.

With layered controls rather than a single review. Static analysis with quality gates, through SonarQube or Semgrep, runs on every commit, alongside dependency and vulnerability scanning through Snyk or Dependabot and secrets scanning with push protection. Branches are protected, so no merge lands without human code review. On top of that pipeline, roughly every fifth prompt the model runs a security review of the whole system, which catches the drift that per-commit checks cannot see. At productionisation, an independent penetration test assesses the AI-built system in its production shape. On the engagement this method came from, the external pen test in month one covered the pre-existing product, and the test of what the method built is scoped into the productionisation phase, against the finished system and to the receiving organisation's standards.

Pair-program the entire build with an engineer from the receiving organisation, rather than building it separately and handing it over. On the engagement this method came from, the whole two-week build was paired with one of the client's own engineers, who at the end put themselves at 70% confident they could follow the process and deliver the next outcome without us. Seventy per cent after a fortnight is not full independence, but it is the difference between a client who has bought a proof of concept and one who has started to acquire a capability.

No. It moves where their time goes. The research, drafting, scaffolding and first-pass review compress dramatically; the judgement calls concentrate: resolving requirement contradictions with the business, deciding what to proceed without, and the last few percent of correctness where the model stops being reliable. Someone still has to know what good looks like, which is why an enforceable engineering standard matters more in this model, not less.

By agreeing an enforceable engineering standard up front, so the model is generating against explicit rules rather than its own defaults. Tenhaw publishes the standard it uses as an open-source engineering handbook of 72 rules with stable identifiers, RFC 2119 severities and full rationale, designed to be enforced by an AI agent rather than remembered by a human.