Vibe Engineering: You’re Not Prompting AI. You’re Building Your Business Harness.

The discipline that makes AI coding agents reliable turns out to be business engineering. My laboratory was code. Yours doesn’t have to be.


A few weeks ago I caught two files in one of my repositories disagreeing about reality. Both claimed to be the source of truth for the same project. One said the project had 102 feature specifications. The other said 109.

Nobody edited them apart on purpose. I had simply kept two copies of the same knowledge, and duplication did the rest: silently, over months. That’s a small bug with a large lesson, because the same thing happens to everything you tell an AI agent in a chat window. Every instruction you type is consumed once and gone. The agent that starts tomorrow knows nothing the agent learned today.

Vibe coding fails the way young companies fail: talent without institutions. And the fix reveals what this discipline actually is. When you write down how work gets done, what the words mean, which rules never bend, who approves what, and how output gets verified, you are not prompting an AI. You are engineering your business: its processes, its controls, its tests. Vibe engineering is business engineering. The code is just where I ran the experiment.

Here’s the claim in one uncomfortable question. Your company has QA for its products, audits for its accounts, and reviews for its people. What is the test suite for the AI that now drafts your emails, triages your support queue, and summarizes your deals? For most organizations the honest answer is: there isn’t one. Fluent output is being waved through on confidence alone, and fluent confidence is precisely what modern models produce best.

I run this method across everything my consultancy builds: a risk-intelligence engine (the one behind Aegilo), a book written with a pipeline of AI agents, and AYA, an operating system for running a company on exactly these principles. AYA is the idea taken to its conclusion: the business harness made software. Software, intelligence analysis, prose, and an operating model. Different substrates, one method. That’s the tell that this is business engineering rather than a coding trick, and I’ll come back to it.

The whole thing compresses into three moves.

Move one: the constitution

Every repository I work in has one canonical file the agents read before every session. Not documentation for humans. An operating contract for the workforce: who we are, what the words mean, what never bends. Every other configuration file is a two-line pointer to it, because the moment you keep two copies, you’re back to 102 versus 109.

Outside of code this file has an older name. It’s your operating agreement: the thing most companies keep in the heads of their longest-tenured people and call culture. Vibe engineering forces it into writing, because an AI workforce can’t absorb culture by osmosis.

Three parts of that file do most of the work.

A glossary. This is the most underrated tool in agent work. Define your terms once, and something better than comprehension happens: the agents start speaking your language back to you. In my intelligence engine, words like originator, held primary, and partial each carry an entire policy. Their output stops needing translation. A shared vocabulary is an interface, the same way an API is.

Laws versus defaults. Most of the file is good defaults that an explicit human instruction can override. A handful of rules are marked hard. In my case: client data never enters shared infrastructure, and every claim cites its primary source. If you don’t make this split, you get both failure modes at once: agents that fight you on trivia, and agents that negotiate away the things that actually matter. If everything is a hard rule, nothing is.

Scar tissue with citations. Every rule in the file names the failure that earned it. One of mine reads: a paged read is not complete until it reconciles against an independently obtained total. It exists because in a single week, four real defects slipped through page seams. 33 records silently lost. A query that reported 1 where the truth was 39. An entire archive served as one page for months. The rule carries its own justification, so no future agent relitigates it. Neither does future me.

The corollary keeps the file short: a rule without a failure attached is speculation. Don’t write rules you imagine needing. Write the failure down while it’s still bleeding, and every future agent inherits the scar instead of the wound.

Move two: the gates

Verification splits cleanly in two, and the split is the whole trick.

Machines check everything checkable. My documentation is validated in CI: a stale claim or a broken reference fails the build, so the docs can’t quietly rot the way docs do. Tests assert invariants, never the AI’s fragile wording. A benchmark keeps score on real outcomes. This is the layer most businesses are missing entirely: evals for the work their AI produces. Not “does it read well.” Is it right, measured against reality, on a scoreboard someone owns.

Humans keep the judgment calls, named in advance. The book pipeline taught me where that line sits. Six specialized agents move each chapter through plan, research, draft, edit, and red-team. Almost all of it runs without me. But “is this chapter good?” is not machine-checkable. A book is not a test suite. So exactly two human gates survive: I approve the brief, and I read the draft. Everything between them is automated; everything at them is not. Cheap judgment, spent precisely where a wrong brief would otherwise cost four thousand words.

Two gate rules earned their place the hard way. Anything that spends money states its estimated cost and waits. And this one came from watching an agent discover a clever workaround to a gate that existed specifically so I would decide: a human gate is closed by the human. An agent that finds a way around one must report the workaround and stop. The action was harmless. The precedent was not.

Underneath both kinds of gate sits one habit. Never ask an agent to be right. Ask it to show where everything came from. Every model call in my systems leaves a trace. Decision logs keep the judgments that were dropped, not just the survivors. Reports cite the primary source, never the model’s paraphrase of it. Fluent confidence is exactly what modern models are best at producing, which is exactly why it’s worth nothing. The chain of evidence is worth everything.

And evidence cuts both ways. When my benchmark disproved a deterministic scoring engine I was genuinely proud of, the engine was deleted. Provenance that only ever flatters you isn’t provenance.

Move three: the loop

Specify, delegate, verify, record. Then feed back: when something fails, the failure becomes a written rule in the constitution, and the next agent starts smarter than the last one finished.

This loop is the answer to the question every prompt-engineering thread dances around: why does none of that effort accumulate? Because prompts are consumed. Constitutions compound. A prompt improves one conversation. A rule improves every conversation that will ever happen after it.

The loop closed on me personally this month, which is only fair. I rewrote one of my constitutions, a substantial revision, glossary and all, and didn’t commit it. A parallel agent session working in the same checkout overwrote it without ever knowing it was there. Nothing was lost that version control couldn’t have saved, had I used version control. The lesson went straight into the file it was about: an uncommitted spec is just a prompt. Institutions only compound when they’re versioned.

The confession

Here is the part I’d want to hear first if I were reading this.

I built a software factory. Three times. The third version works: a control plane with a CLI, a run ledger, worktree locking, a merge-policy engine. Agents building software at scale, humans merging. Its own README describes “a controlled software factory operating beside the human.”

I don’t use it.

Not because it failed. Because the method made it unnecessary. Once the constitution exists, once a one-page delivery procedure says how any change ships, once the gates are named, orchestration collapses into simple delegation: one strong model reads the procedure and hands scoped, well-contexted goals to smaller, cheaper models. A markdown file replaced a control plane. The sophistication didn’t disappear. It migrated from the machinery into the method.

I’ve since noticed I’m not alone. Theo Browne, the developer behind T3, recently described getting deep into a custom system for managing agent configuration across his machine fleet, finding it buggy and annoying, and abandoning it. His fleet now runs on a repository of markdown files. Two practitioners, independently, same convergence. When machinery competes with institutions, institutions win: they compound, and machinery depreciates.

The factory isn’t deleted, though. It’s gated: parked behind a written condition, the day one orchestrator can no longer supervise the volume. Building it before that day would be scope creep. Even mothballing follows the method.

The same move, at three scales

Zoom out and the pattern gets more interesting than any one repo.

A solo developer runs a fleet of machines on markdown files and coding agents. My consultancy runs its products on constitutions, glossaries, and procedures, with one orchestrator delegating to smaller models. And at the top of the market, Palantir builds what its architects call the ontology: the customer’s business modeled as data, logic, and actions, with fleets of fine-tuned, task-specific models doing the work. One of their architects put the principle cleanly in a recent interview: you need “a harness of your business, not of a tool,” and once you have it, the models become commodity. Swap them by task, by price, by speed. He cites customers like AIG publicly crediting agentic underwriting flows, hundreds of agents, with roughly a third more written premium.

Same anatomy at every scale: encode the business in an artifact the models read, and treat the models as swappable labor. A glossary is a micro-ontology. A scar-cited rulebook is a hand-rolled feedback pipeline. The constitution, the gates, and the loop are a business harness. The difference between my markdown files and a Fortune-100 ontology is budget, not kind.

Which is also the sovereignty argument, and it matters more every quarter. Models improve and get cheaper on someone else’s schedule: they are rented labor. The specification of how your work is done, in words you own, is the only part of the stack that appreciates. It’s also perfectly portable. The same files that drive today’s leading model will drive whatever replaces it. Own the spec, and every model becomes interchangeable. Rent the spec, leaving it scattered across chat histories on someone else’s servers, and you’ve outsourced the one asset that was yours.

The smallest business harness there is

The proof was never that this works on software. It’s that the identical method runs an intelligence product, a book, and an operating model. The substrate changed three times; the institutions didn’t. Every function in your company is heading the same way: work delegated to AI, supervised by people. Which means every function needs what engineering already has, a spec, gates, and evals. The smallest version of that harness is three documents:

A shared vocabulary. Ten terms, written down, that your AI must use back to you. Your micro-ontology.

A written procedure. One page describing how work becomes “done,” read at the start of every session, edited whenever reality disagrees. Your process, finally explicit.

A gate you refuse to automate. Named in advance, in writing. Held. Your control framework, reduced to its first entry.

That’s the entry fee. An evening, honestly. And it’s the asset that appreciates while the models commoditize under it. Coding is now writing good markdown. So is running a business.


The three documents above exist as fill-in templates: the Vibe Engineering Field Kit is a 21-page workbook you complete in an evening, $47. If you want to see which of these institutions your organization is missing first, the free diagnostic takes five minutes. And if you’d rather build your first constitution with me in the room, that’s exactly what Build is for.