How we build with AI

MO_AI is the wrapper around everything we do to work agent-natively: a shared set of standards, guardrails and processes that keep quality and reliability high while the tools underneath keep shifting.

It exists because the pace of change in this field is difficult to absorb as an individual and impossible to absorb as an organisation without a system. MO_AI standardises best practice, cuts through the weekly noise, and reduces the cognitive load of keeping up.

Judgement, speed, quality

Three things have to be true at once for this to work, and they are in this order for a reason.

Judgement decides whether the thing is worth building at all. It is the part that did not get cheaper, and the part we systematised hardest. See how we decide what to build.

Speed is what AI actually changed, and we measured it rather than claiming it. 2.6× more delivered work per engineering hour against our own baseline. The evidence is below.

Quality is what speed costs you if the system around it is weak. Ours is scored, audited and has been running for years. See the 10 Fundamentals.

Not vibe-coding. Engineering.

Let us be direct about what this is not. We do not build products on vibes. Accepting whatever an AI produces because it looks plausible and runs is not what we do. We bring engineering expertise and product judgement to every build, and we call what we do engineering, deliberately.

The guiding principle: AI without control is worse than no AI at all. AI is like a Formula 1 car. You can get in and drive very fast, but unless you know how to control it you will spin off at the first corner. MO_AI is how we keep control of the speed.

A single connected journey

Three workstreams. The order matters, because AI accelerating execution makes it more important than ever that we are building the right thing.

Define and design. Everything anchors to business value and user need. A high-level PRD per project, feature-level PRDs per feature, with design and requirements working as an interplay rather than a rigid sequence. Design settles behaviour, not just interface. See how we decide what to build.

Augmented engineering. Human-driven, with the engineer as architect. Brainstorm, plan, build, review. Brainstorming turns the PRD into a technical spec through real architectural trade-offs. Planning produces a blueprint the engineer reviews before anything is implemented. Build is where agents execute, and an agent might run for an hour or more on a single task. Review is where much of our value now lives.

Autonomous engineering. System-driven rather than human-driven. Small, repetitive work offloaded to agents so people work higher up: automated review, dependency upkeep, and turning production errors into actionable fixes.

GitHub is the single source of truth throughout. Issues are generated from a signed-off PRD via the MO_AI plugin and always reviewed by an engineer, giving traceability from planning to delivery.

Guardrails

• Plan before you build. Because execution is compressed, setting the work off in the right direction is the single highest-leverage step. Reviewed plans are non-negotiable.
• The human is the architect. We no longer write every line by hand. We make the trade-offs, own the architecture, and direct the agents. Accountability stays with a person.
• Review, always. Automated review gives a fast first pass. Engineers still read the code, comment, and direct changes. Automation removes the bottleneck of waiting for review. It does not remove the reviewer.
• Friction is feedback. When AI output falls short, that is a signal to improve a skill, a rule or the codebase, not a thing to fix by hand and move past.
• Guard the dangerous edges. Tool access is scoped deliberately, read rather than write on a production database for example, and risky changes such as large diffs or migrations are flagged for human eyes.

The MO_AI plugin

An in-house Claude Code plugin that augments native capability with MOHARA practice. It builds on proven open-source foundations with a layer tailored to how we work, and it is deliberately hackable: when a skill misbehaves, anyone can adjust the guidance, add a rule or hook, or write a new skill, validate it, and contribute it back.

The evidence in full

The headline numbers already appear in the stat wall at the top of the page, so this is the working rather than a reveal.

We measured two client builds from our own portfolio, one delivered before we adopted agentic engineering and one after. Both are web application builds on the same stack, from the same organisation, with client names withheld. Timesheet hours are the denominator, so this is output per hour rather than a headcount effect.

2.6× more delivered work per engineering hour, on the most conservative measure we could construct.

It holds across every measure of delivered work: 2.60× pull requests per engineering hour, 2.74× per all-role hour, 3.60× production code changed per hour. We exclude commit count deliberately, because agentic work produces fewer, larger commits and tracks habits rather than output. The later build's pull requests were larger, not smaller, which is why 2.6× is the conservative read.

What we do not claim. Two different products of comparable scale on the same stack, not identical scope. The later build was still in progress when measured, so it reflects one phase of delivery. One baseline role category was excluded because it could not confidently be classed as engineering; including it lifts the figure to 2.83×. The later build also shipped substantial automated test coverage that the headline does not count at all.

The 2.6× figure never travels without its method and its limitations, which is why they are set out in full above rather than reduced to a headline. The rigour is the differentiator, not the multiplier. A bare "2.6× faster" is a marketing claim and would be challenged as one.

Common questions

Does MOHARA use AI to write client code?

Yes, under direction and inside a reviewed process. Agents execute substantial units of work against a plan an engineer has reviewed first, and every change is reviewed before it ships.

Is AI ever the decision-maker?

No. All code is reviewed, tested and approved by human engineers before it is used in any product. AI suggestions are treated as input from a tool, never as a replacement for expertise and judgement.

Do AI providers train on our source code?

No. We do not allow AI providers to train their models on client source code.

How much faster is it, really?

2.6× more delivered work per engineering hour on our own measured comparison, stated conservatively. The full method and its limitations are published.