How to build with AI, engineering-first

The method's delivered evidence is greenfield. The two-week build started from a blank repository, and the steps are designed to carry across to a running system with three changes. The corpus grows to take in the existing system's behaviour, converted to structured markdown the same way, so the model reasons over what must be preserved as well as what must change. Verification hardens, because 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.

Requirement changes go into the markdown first, never straight to the model. You amend the requirement files, then ask the model to re-evaluate the project against the amended set and build the new requirement. It works because the canonical set sits where both sides read from, a Git repository or a knowledge base like Obsidian, version-controlled and diffable, so a change is reviewed rather than remembered. Prompting the model directly feels quicker, but the code then drifts from the canonical requirements and the next full re-evaluation silently undoes it. Testing feedback comes back the same way, as it did on a live engagement where a user-testing transcript was converted to markdown and handed to the model to improve the product against.

A Claude Code enterprise implementation, in our hands, is this build method run inside your environment rather than ours. The tool matters less than the corpus it is pointed at, where every requirement has been converted into structured markdown and interrogated for gaps and contradictions before a model at its highest reasoning setting builds against all of it. Claude Code is the default, with OpenAI and Gemini models used where they suit the problem better. The work sits in your repositories, so static analysis, dependency and secrets scanning run on every commit in your pipeline, protected branches hold a human review before any merge, and roughly every fifth prompt the model runs a security review of the whole system.

Because the relationships between requirements are where the design decisions actually live, and they are almost never written down anywhere. Once every source is structured markdown, you ask the model to link the requirements to each other: dependencies, shared entities, conflicting assumptions, ordering constraints. The map is a working artefact for the decisions that follow, not a diagram for a deck. It is also what makes the gap pass worth running, because a model that can see how requirement 14 relates to requirement 61 will tell you they contradict each other in a conversation, rather than leaving you to find out once the thing has been built twice.

No, and we would rather you did not. The first step is to collect every source of requirement in whatever state it is in: PDFs, slide decks, architecture diagrams, screenshots, email threads, spreadsheets. Nothing is excluded for being messy or out of date, because completeness matters more than quality at that point, and the requirements you leave out are the ones that surface in week three as a rebuild. Structuring is the model's job, not yours. What we do ask for is somewhere both people and models can read from, a Git repository or a knowledge base like Obsidian, and an agreed engineering standard so the model builds to your rules rather than its own defaults.

All at once, which is what the preparation buys you. With a frontier model on its highest thinking setting and the whole requirement set in front of it, the opening prompt can be genuinely high-level, asking it to review all requirements and build a production-ready product, with high coverage of automation and integration tests, and be confident every requirement is met. You are not hand-holding it file by file. Doing that reimposes the exact bottleneck the corpus just removed, because the model's advantage is holding the entire system at once, and it is the habit most teams carry over from an assistant that could only ever see the file that was open.

A model transcribes them and describes what they show in prose, as part of converting every source into markdown. People underestimate that part, because an architecture diagram or a screenshot often carries a constraint that appears nowhere in the written requirements, and once described it becomes text the gap-and-contradiction pass can interrogate like anything else. The output is structured markdown with one concern per file, readable by a human and parseable by a model, so your own people can check a description is faithful before it becomes canonical. Anything still ambiguous in the picture then surfaces as a flagged gap rather than a guess in the build.

Then you decide what to proceed without, explicitly, and write the decision down. The method takes the model's flagged list of gaps, contradictions and ambiguities to the people who own the answers, and in practice some answers will not arrive in time and some do not exist yet. The call is a trade between risk tolerance and how long the answer would take to get, made by someone with the authority to make it. Not every question is worth blocking on. What matters is that proceeding was a decision somebody made and recorded, rather than an omission nobody noticed until the build was finished.

Because scaffolding chosen before the requirements are understood bakes in architectural choices the requirement set may not support, and unpicking that later costs more than the template ever saved. So the build starts from a blank repository: nothing scaffolded, no starter template, no opinionated framework chosen in advance. That is not an argument against your standards. The engineering standard, static analysis, dependency and secrets scanning and branch protection all apply from the first commit, in your pipeline. The only decision that waits is the framework, until the model has read the whole corpus and the design decisions buried in the relationships between requirements are visible.

By making the requirement set complete and machine-readable first, so meeting every requirement is a checkable instruction rather than an aspiration, then testing three ways. High coverage of automation and integration tests is written into the opening build prompt. Automated, manual and user testing run together after it, and the feedback is documented back into the markdown corpus instead of a spreadsheet where it gets triaged and forgotten. Human review is the backstop, because protected branches mean no change merges without someone reading it. The corpus is what makes that check possible, since it runs against the whole requirement set, not a traceability matrix somebody maintains by hand.

Yes, and it is the closest fit to how we work anyway. Claude Code is what our own toolchain reaches for first, and we drive it the way this method needs, with one high-level prompt against the whole requirement set at maximum reasoning rather than a file at a time. Where you already have an approved enterprise tenancy, we work inside yours rather than bringing our own, and nothing goes into a tool you have not named and approved in writing. What we add sits around it: every requirement as structured markdown, the gap-and-contradiction pass before a line of code exists, and our 72 published rules with RFC 2119 severities enforced by an agent from the first prompt.

Yes, and that is where our delivered evidence actually sits. Everything Tenhaw has shipped runs on Microsoft Azure including Azure OpenAI, with delivery through GitHub, and the two-week proof of concept behind this method extracted information from PDFs into business intelligence on Azure. Codex is already in how we work, since a build opens by pasting an outcome-driven epic into Claude or Codex in the editor, and OpenAI models sit in the default toolchain, picked for what each does best and run inside your infrastructure under your policies. None of the thirteen steps changes when the models behind them are yours rather than the ones we reach for first.

Gemini yes, Vertex AI with one honest edge. Gemini is already in the default toolchain alongside Claude Code and OpenAI models, chosen case by case for what each does best, and because the requirement corpus is markdown in a Git repository, changing which model reads it is a configuration decision rather than a rewrite. We have shipped nothing on Vertex itself, so there we would work alongside your own platform engineers rather than lead the platform work, and price it that way rather than learn your stack on your budget. Tenhaw does not resell or mark up models, platforms or licences, so nothing you specify becomes revenue for us.

Yes. The method is Git, markdown and a model at maximum reasoning rather than a framework, so which model reads the requirement corpus is a configuration decision, and the operating model outlasts the tooling. Delivered work sits on Microsoft Azure with delivery through GitHub, and that is where the two-week London specialty insurance proof of concept took PDFs to business intelligence. Claude Code, OpenAI and Gemini models sit in the default toolchain. On a model you host, your platform team owns the hosting and inference side with us beside them rather than in front, scoped and priced as that supporting role. Test first whether your hosted model can hold the entire requirement set at once on its highest reasoning setting.

Velocity84 is Tenhaw's build lab, a separate venture that builds agentic-first products and supports founders through cohorts of AI-native builders. Three cohorts so far have produced more than twenty prototypes and businesses spanning agentic voice, video analysis, document and information reading, mobile applications and go-to-market. It is where the agentic patterns used on Tenhaw's client engagements are developed and tested.

Both, and the build lab is the evidence for the first part. More than twenty agentic products across five modalities have been built through Velocity84, and on client engagements Tenhaw has rebuilt a product representing roughly twelve months of prior work as a working proof of concept in two weeks. The build method used is published in full rather than described.

No. They are startup-scale products without the regulatory, integration and scale constraints of a large organisation. They evidence build capability and breadth across agentic modalities. For enterprise evidence, the client case studies are the relevant material.