CASE STUDY · AGENTIC SOFTWARE ENGINEERING, IN THE OPEN

One engineer.
1,132 test scenarios.
57 working days.

Marketlum is an enterprise-grade platform — double-entry ledger, multi-currency, hierarchical permissions, invoicing, plugin architecture, MCP server. It has one human contributor. 95% of its commits were written with an AI agent. This page is the honest account of how, including what didn’t work.

95%

AI co-authored

1,132

BDD scenarios

specs before code

domain modules

Why we’re showing you our own codebase

Most agentic-engineering advice is written by people who have never shipped a serious system that way. We wanted a case that couldn’t be faked, so we used our own product.

Marketlum is a framework for self-organising markets — where teams (human and AI) run as micro-enterprises with their own P&L, agreements and ledger. It is a genuinely hard domain: money, permissions, auditability, multi-currency, invoicing. The kind of code where a subtle bug is expensive and invisible.

It is built almost entirely by agents, under a system we designed. That system is what we sell.

Full disclosure up front: Marketlum is pre-revenue and in pilot conversations, not general availability. The numbers below are about how it was built, not about customer outcomes. When we have those, we’ll publish them here too.

The four rules that make it work

Specification before code — always

24 numbered specs live in specs/ in the repo. Each one starts as an append-only brainstorming file: the agent asks 4–7 questions per round, each with 3–5 mutually exclusive options and one pre-selected recommendation. The human moves an [x] or writes a sentence. Silence means agreement. Only when the rounds close does the agent write the implementation-ready spec — domain model, endpoints, migrations, permissions, UI, test coverage, out-of-scope.

This is the whole trick. The scarce resource in agentic engineering is not code, it's decisions. The pre-selected-option format compresses a human's architectural judgment into minutes of reading instead of hours of writing, and leaves a permanent decision trail explaining why the system looks the way it does.

Strict BDD as the correctness contract

The repo rule is absolute: no endpoint or UI behaviour is implemented before its .feature file and step definitions exist. Today that's 220 feature files and 1,132 Gherkin scenarios against 76 step-definition files. Written in plain business language, they are readable by the person who owns the domain — so a human can review behaviour instead of diffing 173,000 lines of TypeScript.

This is the answer to “how do you trust agent-written code?” You don't. You trust an executable specification the agent had to satisfy, and which you can read.

The guardrails live in the repo, not in the prompt

CLAUDE.md fixes the agent's identity and its non-negotiables. CI runs on every push and PR: build all six packages, lint, then the full end-to-end BDD suite against a real Postgres. CONTRIBUTING.md carries a hard pre-PR checklist — suite green, build green, BDD scenarios updated, schema changes revert cleanly, app changes mirrored into the scaffolding template. Written conventions replace supervision; the pipeline, not the human, is the gate.

Architecture that agents can actually navigate

40 bounded domain modules, Zod schemas in one shared package as the single source of truth for types and validation, a plugin system for anything optional, 69 reversible migrations. Agents work well in small, explicit, strongly-typed contexts and badly in sprawling implicit ones — so the modular boundaries aren't just good engineering, they're throughput.

What actually came out

AI co-authored

95% of all commits

Codebase

~173k tracked lines, TypeScript; NestJS + Next.js, 6 packages

Executable spec

220 feature files, 1,132 scenarios, 76 step-definition files

Design record

24 brainstorming + specification documents, committed

Scope delivered

Double-entry ledger, multi-currency + NBP FX, invoicing, orders, offerings, hierarchical RBAC, API keys, taxonomies, agreements (RenDanHeYi/VAM), dashboards, search, plugin system, MCP server, docs site, project scaffolder

Human contributors

For calibration: a scope like this is normally a small team for a year or more. That is the delta agentic engineering buys — and the reason we think engineering orgs are about to change shape rather than just get faster.

What we got wrong

Skipping the spec is a false economy

Every feature we let an agent start from a chat message instead of a spec came back as rework. The spec ritual feels slow and is the fastest part of the process.

Model changes are a real variable

Five different frontier model versions appear in this repo's commit trail. Capability moved underneath us mid-project — which is exactly why the guardrails belong in the repository, not in a prompt tuned to one model.

Renames are the honest cost of speed

Spec 024 renamed the core “Agent” concept to “Actor” across the schema, backend, UI, tests and docs. Fast building means more concept churn, not less — and it's survivable only because migrations and BDD coverage make a sweeping rename mechanical instead of terrifying.

Permissions and access will bite you

Our own agents were blocked from opening pull requests by read-only tokens. Agent access design is a first-class part of adoption, not an afterthought.

What this means for your team

If you’re a CTO or VP Engineering being asked what agents can really do: this isn’t a demo, a toy, or a greenfield CRUD app. It’s a money-handling system built by one person and a set of agents inside a defined operating system — spec-first decisions, executable behaviour contracts, repo-level guardrails, modular architecture.

That operating system is what we install. We built it on our own product first, with our own money, on the hardest domain we had.

Get an Agentic Engineering Audit — 2 weeks, fixed fee →← Back to case studies