MG12 design
← All work Platform · AI engineering · Governance

Codamor

A coding pipeline generates code and stops. Codamor turns it into a service-delivery loop that doesn't — security, architecture, UX, testing and operations applied as AI perspectives, models from different vendors checking each other's work, and a continuous-improvement cycle that watches the running service and feeds the gaps back through the same governed pipeline. Code generation gets you a build; Codamor is built to deliver a service that measures itself, improves itself, and that you can stand behind.

Role
Founder · product & platform architecture
Domain
AI engineering · governance · DevEx
Stack
.NET headless core · local API · multi-vendor LLM orchestration
Status
In development

The idea

Every AI tool on the market is a coding pipeline: it generates code and stops. But shipping the code is the start of the work, not the end of it — what follows is running a service, measuring whether it’s actually working, and improving it. A coding pipeline has nothing to say about any of that, and its one-shot output routinely lacks the things a service needs anyway: security thinking, deliberate architecture, UX consistency, real test discipline, operational KPIs, and a record of why anything was decided.

Codamor turns the coding pipeline into a service-delivery loop. It does what world-class engineering organisations do — it designs by walking around: the perspectives a serious build needs are applied as AI personas that contribute to shared, versioned artifacts (the requirements, the architecture, the threat model, the test plan, the KPI spec), and those artifacts become enforced gates on every future change. Then it keeps going — watching the running service and feeding what it learns back through the same governed pipeline. The walk-around is the process, the documentation is its by-product, and the loop never closes.

One pipeline, many perspectives

A single requirement walks one governed pipeline — requirements, security, architecture, UX, build, test, operations — with the right perspective applied at each stage rather than left to a single model’s mood. Each perspective’s output has to terminate in something real: a machine-checkable gate, or a decision the human has signed. Output that is neither is rejected. No theatre, no advice that goes nowhere.

  • Artifacts, not vibes — every contribution lands in a durable, versioned document that future changes are checked against, not re-litigated from scratch each run.
  • Real gates — the generated test harness is actually executed; the honest exit code and counts decide whether a change passes, not a model’s say-so.
  • The repo is the record — artifacts, decisions and attributions live as git-friendly files in the user’s own repository, greenfield or legacy, always reconciled against the code that was really written.

Models marking each other’s homework

No single model’s blind spots get to ship. Codamor assigns which engine writes and which engines review, per role, across vendors — so the perspective that proposes a change is never the only one that signs it off. Cross-model, cross-vendor review catches the correlated errors a single-model pipeline can’t see in itself.

The loop that doesn’t stop at release

The pipeline doesn’t end at go-live. The systems Codamor builds are designed to emit the KPIs and voice-of-customer signal they’ll be judged by — and the operations and management perspectives watch that signal, turn the gaps into prioritised improvements, and feed them back through the same governed pipeline. It’s a continuous-improvement loop wired into the codebase: the platform measures itself, and improves itself, under governance.

Compliance born in, not bolted on

Because every requirement, design decision, review verdict and sign-off is recorded the moment it happens, a Codamor-built system arrives with its audit trail already written. For AI decision points, that evidence is produced through Plenio — per-event, named-human oversight records of the kind the EU AI Act actually demands. The governance isn’t a later project; it’s a property of how the system was made.

The architecture

Codamor is a headless .NET core behind a local API, with thin clients — a desktop shell, a CLI and a CI runner — that have no privileged path of their own. Everything that produces an artifact also feeds a gate; nothing in the core assumes the system it’s building shares its own technology. A context manager assembles the smallest sufficient context for each step and holds runs to hard token budgets, and every step is journalled so a crashed run resumes exactly where it stopped.

  • Headless core + local REST API
  • Multi-persona pipeline orchestration
  • Cross-vendor model adapters
  • Versioned artifact store (repo-native)
  • Machine-checkable gates
  • Real test execution
  • Context manager + token budgets
  • Journalled, resumable runs
  • KPI & voice-of-customer loop

Why it’s here

Codamor is where end-to-end product leadership, applied ML and platform architecture meet in one build: a real product thesis, a multi-vendor AI system engineered around it, and the governance designed in from the first commit. It’s the working argument behind everything else on this site — that AI is worth deploying only when it’s measurable, governable, and something you can stand behind.

Want work like this in your business?

Start a conversation