About this method
This is the method we use on client work, and the first thing a new engineer reads to learn how we operate.
It has two readers. The first is a Barnacle engineer who needs to know the process, the artefacts, and the gates. The second is a client who wants to understand what they are buying and why our code holds up under audit. Most of the method serves both. Where a section is mainly for one reader, it says so.
Two things run through everything here. The first is the spec — how we turn intent into code we can verify and audit. The second is the context graph — how we ground the agent in the client’s own world, so it works from their reality rather than the model’s training data. Most AI builds need both, and we build the grounding on Alexandria, our context layer for enterprise AI agents.
The lifecycle at a glance:
Discovery is an optional two-week starting point: when the idea is still vague, it lands on one use case worth pursuing and builds a quick prototype to make it tangible. Shape takes a committed use case and removes the doubt — proving it can be built and producing the design to build it. Build turns the design into verified software, spec by spec. Tune & right-size makes it efficient enough to run at real volume on the smallest model that clears the bar. Deploy & handover puts it in production and hands it over. The spec and the context graph run the length of the lifecycle.
Codified delivery methods are an old idea, and a good one. Andersen Consulting had Method/1, Rational had the Unified Process, IBM Global Services ran GSMethod across every engagement — each captured the firm's way of working so a project's quality did not depend on which team turned up. Agile pushed the heavyweight versions out of fashion, but the idea was always sound, and AI has made it current again: when an agent writes the code in minutes, the discipline around the code is what determines the outcome. The Barnacle Method is our version — the same idea as those lifecycles, rebuilt for AI solutions delivered by engineers working with agents.
Spec-driven development is becoming an industry practice, and our vocabulary is deliberately shared with it. GitHub's open-source Spec Kit runs the same spine — a project constitution, then specify, clarify, plan, tasks, and implement — and our Build loop maps onto it stage for stage. But those frameworks cover the development loop, and a client project is longer than that. What we wrap around the shared spine is the rest of the lifecycle: a Shape phase that removes the feasibility risk before a line of spec is written, a context graph that grounds the agent in the client's world, a Tune & right-size phase that makes the result affordable and sovereign, an operate discipline — set up and handed to whoever runs it — that keeps it healthy after deploy, and an insistence on provenance throughout.
How prescriptive is this? The method fixes the frame: the phases, the gates, the artefacts, and the provenance that connects them. Those hold on every project, because they are what a client buys when they buy the method. Everything inside the frame is judgement. How you run a stage, how long it takes, how big a task is, which levers you pull in tuning — the method gives defaults and the reasoning behind them, and the engineer running the project decides the specifics. When a default does not fit, deviate and record the reason in the constitution; the record is the rule, not the default. And if a step makes no sense for your project, that is a signal to think, not to comply.
Darwin spent eight years cataloguing barnacles before the theory that made his name. The patient, unglamorous work came first, and the breakthrough followed from it. Our method rests on the same idea. Shape and the spec are the patient work. The working system is what they produce.