Four modes of developing with AI: A / B / B+ / C

The front door to the harness series: four development modes — Classic (A), AI-Assisted (B), Agent-Driven (B+), Agent-First (C). It's not a ladder but four distinct bets: one mode is optimal for one team and catastrophic for another on the same project. This recipe helps you pick a mode and answers the meta-question of how much AI a project even needs. For B+/C a harness is mandatory (it leads on to the Harness Engineering recipe); for A/B it's barely needed.

IntermediateAI DevOps15 minCursor, Claude Code, Copilot, ExecPlan, ADR

Not a ladder — four bets

The core thesis: modes A / B / B+ / C are not steps a team 'advances' through. They are four distinct bets — four ways to win and four ways to break. The same mode can be optimal for one team and catastrophic for another, on the same project. The modes differ along three axes: who writes the code, what the engineer attends to (the object of attention), and the throughput the team produces. In A a human writes every line and owns it deeply. In B the human leads and AI speeds up typing (Cursor tab, Copilot) — a 30–50% gain, but the bottleneck is unchanged: one person's cognitive bandwidth. In B+ the agent writes the code, the human frames the task and reviews the solution, and the code stays human-readable. In C the object of attention is the environment the agent runs in; the engineer's main product is the harness.

Mode	Who writes the code	Object of attention	Throughput
A — Classic	Human	Lines of code	Linear in headcount
B — AI-Assisted	Human, AI speeds it up	Lines + AI suggestions	1.5–2× over linear
B+ — Agent-Driven	Agent	Task and solution	2–3× · 2–3 threads
C — Agent-First	Agent	Agent's environment	Non-linear · 5–10 tasks

Mode B is a transitional state, not a 'third way'. Either a step toward B+/C, or a slow slide back into A under the weight of its own AI slop. You can't stay in B for long without picking a side.

Play with the modes: win / lose / break and the matrix

Below is the interactive. Open each mode's tab and compare three blocks: what it wins, what it loses, and where it can break. Then switch to the comparison matrix — it lines up all four modes side by side across people, speed, cost, risk, and fit, with a category filter. I won't recap the matrix in prose — its whole point is to be explored live: see how A has zero entry cost but falling competitiveness; how C buys non-linear throughput at the price of capability collapse and deep vendor lock-in; and how B+ keeps code human-readable while growing 2–3×. Play with the tabs and filters before reading on — the next step builds on what you find there.

Four modes of developing with AI — A / B / B+ / C

It is not a ladder a team "moves forward" along. It is four different bets: four ways to win and four ways to break. One mode can be optimal for one team and catastrophic for another — on the very same project. Pick a mode, compare win / lose / break, then play with the summary matrix.

A transitional spot between B and C, but distinct enough to call its own mode. The agent writes the code; the human steers: unpacks the task, frames it, runs another task in another worktree in parallel, reviews at the MR level — not line by line, but not "checks passed → I merge" either.

Mode philosophy

"I don’t write code. I direct the agent." — it’s not about tools. It’s about shifting the object of attention: from lines of code to framing the task and checking the solution.

—

Three theses for the team

01
Your value isn’t lines of code, it’s a well-framed task
The more effective person isn’t the faster typist but the one who frames more precisely and spots "that’s not it" faster. Those are different skills, and they’re trainable.
02
The reflex "I’ll write it myself, it’s faster" is a trap
This particular function you’ll write in 5 minutes, the agent in 8. But while the agent works, you move a second task. By end of day the gap is 2–3×, not 1.5×. Each action is slower; total output is higher.
03
Review is "was the task solved", not "does the code run"
The main mistake is reading the diff line by line and thinking "looks fine." The right question is "was what I asked done, at the right scale." Often the agent solves 1.5× more than needed, or 0.7×.

+ Wins

What it wins

Non-linear growth while keeping legibility

Parallel worktrees give throughput unreachable in B. Yet the code is still legible — a newcomer reads it without a special agent-onboarding procedure.

Lower cognitive load

In B a developer decides every 2 minutes. In B+ — once every 30–60 minutes, weightier ones. Less brain fatigue by end of day.

Boundary linters + strict types absorb AI slop

The critical difference from B: structural drift is caught mechanically by your stack’s barriers — import boundaries (dependency-cruiser / import-linter), strict types (strict TS / mypy), architecture rules (eslint-plugin-boundaries, FSD and analogues). The machine holds the architecture, not discipline.

Per-project segmentation is natural

Because the code stays human-readable, you can run B+ with any client — even NDA-strict, even regulated. No "90% of the code was written by AI" conversations with the client.

The team keeps its skills

The capability collapse that threatens Mode C doesn’t happen in B+. Developers keep reading code, reviewing, understanding.

Less vendor lock-in

Skills written as a project description are portable. Swap the agent — most of the infrastructure keeps working.

— Losses

What it loses

Throughput falls short of C

One person runs 2–3 parallel threads, not 7–10. The bottleneck is review bandwidth. The B+ vs C difference: "review every MR" vs "review at the ExecPlan level."

A cognitive ceiling on review

3.5 MRs a day from the agent — you can review properly. 10 a day — you can’t. Then you either decay to "glance-and-merge" or hit the ceiling.

Long-horizon tasks get fragmented

A 7–25 hour autonomous ExecPlan is impossible in B+ — you can’t review intermediate steps at that volume.

Tests for humans, not as an agent signal

In C, tests are written as a system-health signal, and a test-integrity barrier stops the agent from weakening or deleting them just to get a green run. In B+ tests are still written for a human to read; high coverage is a side effect, not a target (chasing the number is Goodhart).

Skills as "descriptions" aren’t optimal

A skill written for a human describes ideas. A skill for an agent describes operations. 70% of the potential value.

The quality document is semi-formal

With 10+ client projects, the lack of a systematic health signal is a blind spot that keeps growing.

⚠ Risks

Where it can break

01
Invisible drift to Mode C under load
As volume grows you’re naturally pulled to simplify review. "Linters green → merge without looking." That’s Mode C, but without the harness that makes Mode C safe. The most dangerous trajectory.
02
One person’s ceiling
B+ works in the hands of a strong architect with repo-first discipline. That’s a personal skill, not a team mode. Rolling it out to other leads runs into the absence of their taste.
03
The team stratifies
Those who master the agent-driven flow at your level grow. Those stuck in Mode B fall behind. Over 6–12 months a big gap opens inside the team.
04
Mid-level capability rot
Mid-levels in B+ don’t write code — they also direct the agent, but never built the intuition for what well-structured code looks like. In 2 years they can direct and can’t write a function unaided.
05
MRs get bigger
As agents get smarter their MRs grow. Soon you’ll look at an 800-line MR written in 2 hours and realize 5 minutes of review is a fiction.

Where B+ sits

Mode B+ is an underrated market position. Most teams are in B, or in a badly-built early C. B+ as a deliberate mode is rare. You can sell it to clients: AI-driven speed + human-readable code + architectural discipline.

Summary matrix: filter by category

	AClassic	BAI-Assisted	B+Agent-Driven	CAgent-First
People & focus
Who writes the code	A human	A human, AI speeds it up	The agent	The agent
Engineer’s object of attention	Lines of code	Lines + AI	Task and solution	The agent’s environment
Who makes architectural decisions	A human	A human	A human	Via ExecPlans, partly delegated
What counts as "good work"	Clean code	Fast delivery of clean code	Precise task framing, review	Designing the environment, long tasks
Speed & scale
Team throughput	linear	1.5–2×	2–3×	non-linear
Parallel tasks per engineer	1	1	2–3	5–10
PRs/day per engineer	0.5–1	1–2	2–3	3–5+
Long-horizon tasks (>7h autonomous)	no	no	fragmented	yes
Replication across projects	no	no	partial	full
Cost
Entry cost	zero	low	medium	high
Maintenance cost	high	medium	medium	medium on people, high on infra
Token spend per unit of work	0×	~0.5×	3–5×	8–15×
Vendor lock-in	none	medium	medium	deep
Quality & risk
Code legibility for humans	maximal	high	high	medium/low
Guard against architectural drift	on discipline	on discipline	mechanical	mechanical + janitors
Role of tests	a human check	a human check	written for humans to read	health signal, never weakened (test-integrity)
Main risk	Seniors leave, falling behind	AI slop accumulates	Drift to C, capability rot	Vendor outage, capability collapse
Fit
New-hire onboarding speed	Weeks–months	Weeks	Weeks	Days (if a harness exists)
NDA-strict clients	ideal	good	good	hard
Competitiveness 2026–2027	falling	stable	rising	rising faster
Competitiveness 2030+	low	in question	if it holds as a mode	depends on the LLM market
Typical team size	Any	Any	5–20, the lead’s role matters	3–50+ given a harness
Who it fits	NDA, regulated industries, small teams with no speed pressure	Teams early in the AI transition, projects with unpredictable architecture	Mature teams with a strong lead, outsourcing with diverse clients	Teams ready to restructure, with high volume of similar tasks

Key takeaways

It is not a ladder

You don’t "move from A to B to B+ to C." Each mode is a standalone strategy with its own bets and failure modes. One mode can be optimal for one team and catastrophic for another.

Per-project segmentation is realistic

Different projects in one company can run different modes at once. Internal pet projects — C. New open clients — B+. NDA-strict — A or B on local models. The point: segmentation is an explicit decision, not drift.

iii

Mode B+ is underrated

Most teams are in B (simple) or a badly-built early C (fast). B+ as a deliberate mode is rare. It sells better to NDA-strict and regulated clients than "90% of our code is AI."

Mode B is transitional

You can’t live there long: either a step toward B+/C, or a soft decay into A under the weight of its own AI slop. You can’t stay in B without picking a side.

B+’s main trap: drift to C without a harness

As the team grows, it’s naturally pulled to simplify review and trust the linters. That is Mode C, but without the infrastructure that makes Mode C safe. The most dangerous trajectory.

Capability rot is an unsolved market problem

Not just you — everyone in B+ and C. There’s no universal answer. The point is to name the problem explicitly and have a deliberate program: reading-first, by-hand sandbox tasks, new roles, pair-programming with the agent and a senior.

vii

Semi-automation is the sweet spot

Between "fully manual B+" and "fully automatic C" lies a working space where scripts gather data and drafts, and a human decides. It yields 80% of C’s benefits at 5% of the cost.

When comparing modes, don't count pluses — look at the failure mode: A's main risk is losing seniors; B's is quietly accumulating AI slop; B+'s is drifting to C without a harness; C's is capability collapse and an LLM-vendor outage. Choosing a mode is choosing the risk you're willing to carry.

How much AI a project needs: the decision rule

The meta-decision isn't 'how do I roll out agents faster' but 'how much AI does this project even need'. The rule is simple and keyed to the mode. B+ and C — a harness is mandatory. The moment the agent writes the code, 'written in the rules' stops meaning 'actually followed': you need mechanical barriers (boundary linters, strict types, structural tests, pre-commit + CI), or there is nothing to catch architectural drift with. Without a harness, B+ quietly slides into a bad C. A and B — a harness is barely needed. The light parts are enough: ADRs for key decisions, a Definition of Done (one checklist for what 'done' means), and ordinary linters. A team in mode B (human leads, AI speeds up typing) will waste time building infrastructure for an agent it doesn't need. The main mistake here is building full agent-first where good autocomplete would do.

Mode	Harness needed?	What to set up
A — Classic	Barely	ADRs, ordinary linters
B — AI-Assisted	Barely	ADRs, Definition of Done, linters
B+ — Agent-Driven	Mandatory	Boundary barriers, strict types, pre-commit + CI
C — Agent-First	Mandatory (full)	Full harness: structural tests, skills, janitors

There's one decisive question: who writes the code? If the agent does, a harness is mandatory. If a human does, the harness is optional and reduces to ADRs + a DoD + linters. Everything else in the choice is secondary.

B+ deeper: how not to fall into a bad C

Where B+ sits on the market: it's an undervalued position. Most teams are either in B (simple) or in a badly built early C (fast). B+ as a deliberate mode is rare, and it sells better to NDA-strict and regulated clients than 'we're 90% AI-code': AI-driven speed + human-readable code + architectural discipline. The main threat to B+ is invisible drift to C without a harness, plus capability rot of the mid-level. Mids and juniors in B+ don't write code — they too steer the agent, but never build intuition for what well-structured code looks like. In two years they can steer and can't write a function unaided. Nobody has a universal fix; there is a deliberate program of four working models (see the checklist). And keep the mode's three theses in mind: your value isn't lines of code but a precisely framed task; the reflex 'I'll just write it myself — faster' is a trap (the agent is slower on a single function, but you're driving a second task in parallel); review means 'was the task I framed solved, at the right scope', not a line-by-line 'looks fine'.

Program against capability rot

Reading-first: the junior reads more code than they write (open-source, others' PRs, 'explain to me' on their own MRs)

Hand-coded sandbox tasks every 1–2 weeks — an algorithm/refactor without the agent, reviewed by a senior

New roles instead of grades: task framers, reviewers, harness engineers, domain experts

Pair-programming with the agent and a senior 1–2× a week — calibrating taste for task framing

Glance-and-merge under load: linters green → merge without looking — that's already a bad C

Assuming B+ reproduces itself: it's a lead's personal skill, not a default team mode

Capability rot of juniors and mids is an unsolved problem for the whole market, not just your team. There's no universal answer; the one avoidable mistake is to not acknowledge it and have no program at all.

'B+ Enhanced': what to take from C piecemeal

You don't have to rebuild the whole process to capture part of C's benefits. Four targeted elements give roughly 30% of C's upside at ~10% of the cost — and each is useful on its own. ExecPlan — only for tasks bigger than a working day and/or touching >5 files. It lives in docs/plans/YYYY-MM-DD-name.md: Context, Goal (one sentence), Out of scope, Approach (5–10 bullets) are written by the human; Progress, Decisions, Surprises are filled by the agent as it goes; Done is the human at the end. A diagnostic: if you can't write the first four sections in 30 minutes, the task isn't ready to launch. A semi-automated quality.md — a script gathers coverage, lint/dep-cruiser/knip violations, outdated deps and generates a draft; the lead fills in the interpretation by eye, 15 minutes a week. Full LLM automation is premature — without project context it writes generic filler. Skills as operations, not descriptions — a step-by-step action list + DoD + anti-patterns + a link to an example in the code, not 'we use FSD and Vitest'. ADR structure — the cheapest adoption of all: one markdown = one decision, 5–15 ADRs per project at 15–20 minutes each.

B+ Enhanced: ~30% of C at ~10% of cost

ExecPlan for big tasks (>1 day / >5 files): human writes Context/Goal/Approach, agent fills Progress/Decisions

Semi-automated quality.md: the script gathers numbers, the human adds interpretation 15 min/week

Skills as operations: actions + DoD + anti-patterns + a code example link, one skill at a time

ADR: one markdown = one decision, retroactively document the ones already made (FSD, test framework)

Full LLM automation of quality.md now — it writes generic filler without project context

Semi-automation is the sweet spot: between fully manual B+ and fully automatic C there's a space where scripts gather data and drafts while the human decides. That's 80% of the benefit for 5% of the effort.

Per-project segmentation + where to go next

The closing thesis: different projects in the same company can run different modes at once — and that's an explicit decision, not drift. Internal pet projects → C (you can take risks; capability collapse isn't scary there). New open clients → B+ (speed + human-readable code you're not embarrassed to show). NDA-strict and regulated → A or B on local models (the client's code never leaves for a third-party LLM). The point is to pick the mode per project deliberately, not to slide into it under deadline pressure. Where to go next. If the rule from step 3 lands you in B+ or C, you need a harness, and this door opens onto the 'Harness Engineering' recipe: there the five-layer environment unfolds into a four-phase task route, barriers vs conventions, and the lessons-ledger, plus a map of the per-phase rollout series. If you're in A or B, you don't need a full harness — take only the light parts (ADRs, a Definition of Done, the linters from step 3) and come back here when you're ready to move into B+.

Project type	Mode	Why
Internal pet projects	C — Agent-First	Risk is fine, capability collapse not critical
New open clients	B+ — Agent-Driven	Speed + human-readable code for the client
NDA-strict / regulated	A or B (local models)	Code never leaves for a third-party LLM

Landed in B+/C — read 'Harness Engineering' next: there the mode choice unfolds into concrete infrastructure and a phased rollout. Stayed in A/B — you don't need a full harness; ADRs + a DoD + linters are enough.

Result

You understand that A / B / B+ / C is not a ladder but four bets with different failure modes, and you can pick a mode for your team and project. The key rule: who writes the code decides everything — for B+/C a harness is mandatory, for A/B ADRs + a Definition of Done + linters suffice. B+ is an undervalued position held together by a program against capability rot and the targeted 'B+ Enhanced' elements. Per-project segmentation is an explicit decision, not drift. If you're in B+/C, the next step is the 'Harness Engineering' recipe, where the mode choice unfolds into a concrete environment and a phased rollout.

Next Steps

Harness Engineering: build the environment for modes B+/C