mahd.dev / process

INSIDE THE HARNESSthe loop that builds.

How mahd.dev actually ships software: an autonomous engineering loop — spec-driven, gated by adversarial review, and directed by senior architects. This is the process, told plainly.

Most of what an engineering team does is not invention. It is the disciplined, repeatable work of turning a decided requirement into tested, shipped code.

For most of software's history that work was done by hand. What changed — and what this page is about — is that the repeatable part can now run as a loop.

We run it as a sequence of roles, each starting with fresh context, each handing the next a checked artifact — until a change is built, verified, and ready to commit.

The loop is real software. An orchestrator runs it role by role behind quality gates; it is not a metaphor for one long prompt.

The loop

Nine roles, one change at a time.

  1. Inquisitor

    Asks one sharpening question at a time until the requirements are unambiguous.

    Hardened requirements

  2. Architect

    Answers the open questions and synthesises a design, diagrams included.

    A drafted design

  3. Design Critic

    Reviews the design adversarially — the job is to find holes, not to rubber-stamp.

    An approved or rejected design

  4. Explorer

    Researches the codebase — existing patterns, integration points, and broken windows.

    A grounded context

  5. Planner

    Turns the design into a test-first, incremental plan.

    A step-by-step plan

  6. Task Writer

    Writes each step as a task with Given-When-Then acceptance criteria.

    Tasks with clear criteria

  7. Builder

    Implements one task at a time, tests first, with no batching.

    A finished increment

  8. Validator

    Runs the quality gates and the end-to-end check itself before anything is accepted.

    A passed or failed verification

  9. Committer

    Writes one conventional commit per step — and never pushes; that call stays with a person.

    A committed, documented change

Gates that bite.

Every change runs the same path: it is built and self-checked, then handed to an adversarial review whose only job is to find holes. Pass, and it is committed. Reject, and it loops straight back to be reworked — nothing advances on trust.

There are two such gates. One reads the design before any code is written; the other reviews the finished change against its written acceptance criteria. Both can send work back, and on real runs both have.

The reject path is the point. A gate that never rejects is decoration — these reject genuine work, with a concrete reproduced fault, and the loop reruns until the change earns its way through.

Gates that bite.Every change runs the same path: it is built and self-checked, then handed to an adversarial review whose only job is to find holes. Pass, and it is committed. Reject, and it loops straight back to be reworked — nothing advances on trust.

Spec-driven and auditable.

Nothing is built from a vague instruction. Each change begins as a written specification, and the loop works one spec at a time until the code matches it.

Every role leaves a durable artifact behind, so the path from idea to commit stays legible after the fact — not locked inside one long conversation.

That trail is the difference between speed you take on faith and speed you can audit: requirement, design, decision, and commit, each recorded as it happens.

  1. A honed requirements record — one decided question at a time
  2. A design document with diagrams, reviewed before any code
  3. Research notes, each grounded in a real source
  4. A test-first implementation plan
  5. Task files carrying Given-When-Then acceptance criteria
  6. A decision journal, each call scored by confidence
  7. An append-only event log and one conventional commit per step

Architect-led, harness-driven.

The harness carries the repeatable work. The decisions that shape a system stay with senior people.

What people own

  • The architecture — how a system is shaped and where its seams fall.
  • The judgment to decide what is worth building, and what to leave out.
  • Adversarial review of the design, before a line of code is written.
  • The decision to ship — the loop never pushes to remote on its own.

What the harness carries

  • Writing the implementation, one specified task at a time.
  • Building and verifying every change behind quality gates.
  • Keeping the boilerplate, the regressions, and the rework moving.
  • Recording every decision, event, and commit as it goes.

Where we stay honest

  • The harness runs under senior judgment — it does not replace it.
  • Agents resolve a meaningful share of well-specified work — not all of it, and well short of the saturated benchmark scores often quoted as proof that engineering is solved.
  • It absorbs the commodity layer of the work; it has not made engineers obsolete. A person still reads the diff and decides to ship.
Why this matters to you

What the loop buys you.

The same discipline reads differently depending on where you stand — but it serves both.

IF YOU'RE BUILDINGfrom zero.

The loop is how a small team ships like a larger one without cutting corners.

  • Legible spend: you can see exactly what was specified, decided, built, and verified.
  • No vague instructions — the spec is the contract, so you fund work, not guesswork.
  • Speed that doesn't mortgage the architecture: the gates hold even under a deadline.
  • An honest account of what the harness carried and what a person decided.

IF YOU RUN ITat scale.

The loop is auditable by construction — built for teams that have to answer for every change.

  • An audit trail by default: requirement, design, decision, review, and commit, each recorded.
  • Adversarial gates that reject real work, with a concrete reproduced fault — not rubber stamps.
  • A human signs off on every change; the loop never pushes to production on its own.
  • Guardrails named up front, so the way of working fits inside your governance.
Work with mahd.dev

BUILD WITHan architect-led loop.

Tell us what you're building. You get senior architecture, the engineering harness, and a small team that ships — not a staffing contract.

Start a conversationSee the services