i.Premise
AI is in a hype cycle. In complex industries, a convincing demonstration or an isolated productivity gain says very little about whole-system benefit once integration, operating risk, governance, cost, and organisational change are counted.
There is no universal case for adoption. Some organisations should proceed; some should narrow the scope, wait, or stop. Scepticism is not resistance to progress. It is the appropriate starting point for a consequential claim that has not yet earned confidence.
We are a principal-led, structurally independent advisory, strategy, and remediation practice for owners of established businesses, boards, executive teams, and technical leaders.
We test whether the claimed benefit survives contact with the whole system: cost trajectory, architectural durability, maintainability, governance, ethical practice, and safeguards. When it does not, we remediate what is already in flight.
ii.Humility
What we don’t claim to know.
We don’t know exactly how the next thirty-six months play out. What we bring is rigour, frameworks, hands-on operational experience from the firms our principals have led and built before this one, first-hand experience navigating earlier technology cycles, and the discipline to update our thinking when reality says we should.
The pressure on consequential AI decisions today is the pace the hype cycle sets. The pace is real, but it does not prove the benefit. What the moment calls for is a rational voice in the room: independent, technically credible, plainly communicated, and willing to recommend no, not yet, or much less.
iii.Position
What we’ll say out loud.
A lot is being asserted about AI right now with more confidence than the evidence supports. We try to hold the assertions to the evidence. Things we think the evidence does support:
Today’s AI prices aren’t tomorrow’s, and rushed adoption can build lock-in by accident.
Vendors have signalled price rises. And without rigour at adoption, agentic codebases may need the most expensive models to maintain. We help clients model the trajectories, best case to worst, and keep their codebase maintainable without AI.
AI has to earn its place in a complex system.
A faster isolated task is not the same as a better operating system. The claimed benefit has to survive integration, review, exception handling, regulation, security, cost, and the work transferred to everyone around the tool. In highly complex environments, the defensible answer may be a narrow use, a delayed decision, or no adoption at all.
Whether the bottleneck is the code or the organisation around it is the diagnosis.
Sometimes the code is the bottleneck: accumulated technical debt, untenable architecture, security exposures. Sometimes it’s the organisational work around the code: alignment between the people building and the people accountable, a coherent plan, a product vision that survives contact with delivery. Often both, and telling them apart is part of the work.
AI writing the code does not remove the need for human review; without it, comprehension debt accumulates.
Reading and reviewing each other’s code is how a team builds the shared mental model of the system. That mental model is what guards against incidents and contains them when they happen. Without review, what accumulates is comprehension debt: code in production nobody on the team fully understands. The claim that AI removes the need for human review of its own code is premature, and likely borrows tomorrow’s product stability and coherence for today’s velocity.
Vibe coding ships features faster than the architecture that holds them together.
In the demo it’s impressive: a working flow, a useful button, a prototype to show the room. What can follow less reliably is the rest of a coherent system: a specification the next feature can be reasoned against, an architecture the team can extend without breaking, a product whose shape follows from a clear purpose. Built this way long enough, the result is more tacked-together features than coherent product, and the architecture becomes work that needs naming and unwinding later.
iv.Principals
