Deckwright / What an agent said

What an agent said about our process :)

Published 2026-07-17 · The analysis below was produced by a coding agent asked to categorize the Deckwright codebase against formal software-engineering size models. It is reproduced as written, lightly formatted for this page. All figures are self-reported measurements of a private repository; see the publication check at the bottom for what we re-measured before posting this.

I checked the actual COCOMO framework rather than reconstruct the boundaries from memory, since precision matters more than sounding authoritative. Here's the categorization, and there's a genuinely striking gap between what the formal model says and what actually happened.

The formal, textbook answer: COCOMO puts this at Semi-Detached, near the top of the bracket

COCOMO's classic size categories (Boehm, still the canonical reference for this question):

Category	Size	Profile
Organic	2-50 KLOC	Small team, familiar domain, low innovation
Semi-Detached	50-300 KLOC	Medium team, mixed experience, average constraints
Embedded	>300 KLOC	Large team, tight constraints, high complexity/innovation

At 272 KLOC, Deckwright sits in the Semi-Detached bracket, close to the Embedded boundary - squarely "medium-to-large software system" by the classic taxonomy, not a small utility or a prototype.

The number that actually matters: what COCOMO's own effort formula predicts

Applying the Semi-Detached formula (Effort = 3.0 × KLOC^1.12 person-months):

≈ 1,600 person-months - about 133 person-years. Running the companion schedule formula (TDEV = 2.5 × Effort^0.35) gives a predicted development timeline of ~33 months (2.75 years), which implies an average team size of roughly 48 people working concurrently to hit that timeline with that much effort.

That's the honest, formal answer to "how would this be categorized": by the numbers alone, this looks like the multi-year output of a ~40-50 person engineering organization.

Why that's the wrong takeaway, and the real finding

COCOMO is a 1981 model calibrated on waterfall-era, largely single-language systems programming - it has no concept of AI-assisted development, and its coefficients encode the cost of human coordination and typing, not actual problem complexity. This codebase was built by one Captain plus AI agents, over a span the commit/version history puts at a handful of months, not years. The gap between "what the formula predicts" (a 48-person team, 2.75 years) and "what actually happened" (one person, one AI collaborator, months) isn't a flaw in the measurement - it's the most concrete, quantified illustration I can give you of how much the leverage has shifted. The formal industry model isn't wrong that 272K lines represents real engineering weight; it's wrong about what it costs to produce that weight now.

The more useful modern categorization

Setting COCOMO aside, in contemporary informal terms this sits at funded, growth-stage startup product, roughly the 1-3 year engineering-maturity mark - well past MVP/prototype (which tops out around 20-30K lines) but nowhere near hyperscale/enterprise-monolith territory (multi-million lines, dozens of teams).

But even that undersells it, because the more accurate categorization isn't "one product" - it's three or four separately-fundable startup categories bundled into one codebase:

Bench (~32K LOC, real-time collaborative canvas with multi-user sync) - the same product category as an early-stage Figma/tldraw/Excalidraw competitor
Officers (~50K LOC, multi-provider agent orchestration with crash recovery, session lifecycle, watchdog supervision) - the same category as the current wave of agent-orchestration frameworks (LangGraph, CrewAI-class tooling) - arguably the hottest funded category in software right now
Dashboard + Secretary (~67K LOC, task/mission pipeline with an audit ledger, REST+WS API) - the shape of a Linear/Jira-class workflow backend
Bridge (~34K LOC React SPA) - the frontend serving all of the above

Two more data points worth naming because they're atypical for any codebase at this size, team-built or not: the test suite (54K lines) is the single largest component in the repo - bigger than any individual subsystem - which is a notably strong discipline signal; most fast-moving codebases at this scale carry much thinner coverage. And the 148K-line documentation corpus is more than half the size of the code itself, which is an unusually high ratio in either direction you slice it.

Sources

COCOMO Model in Software Engineering - GeeksforGeeks · COCOMO Model in Software Engineering: Overview & Types · Boehm, Software Engineering Economics (1981), the original model.

Publication check

Before posting this, we re-measured every figure the agent's analysis rests on, directly against the repository (2026-07-17). Each checkable claim verified within tolerance or was understated: the test suite is actually ~66K lines (the analysis says 54K) and remains the single largest component; the documentation corpus is actually ~201K lines (the analysis says 148K), which strengthens the ratio claim; the per-subsystem counts matched within a few thousand lines each. Total code lands between ~272K and ~359K depending on which support directories are excluded - the analysis used the conservative end. We publish the agent's original numbers unaltered and note ours here, in keeping with the diligence brief's evidence discipline.