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 is written for two readers: a Barnacle engineer who needs to know the process, the artefacts, and the gates, and 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.
Most of the method comes down to two things. The spec is how we turn intent into code we can verify and audit. The context graph is 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 are used in every phase.
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 we deliberately use its vocabulary. GitHub's open-source Spec Kit follows the same sequence — a project constitution, then specify, clarify, plan, tasks, and implement — and our Build loop maps onto it stage for stage. But those frameworks only cover the development loop, and a client project is longer than that. So we add the rest of the lifecycle around it: 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 the system healthy after deploy, and provenance throughout.
How prescriptive is this? The phases, the gates, the artefacts, and the provenance that connects them are fixed on every project — they are what a client buys when they buy the method. Everything else 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 — just record the reason in the constitution. And if a step makes no sense for your project, question it rather than following it blindly.
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.