Fowler, Böckeler, Osmani Map the Coding-Agent Methodology

In Brief

Fowler’s Bliki now carries the canonical vibe-coding definition with its caveats attached, and by that definition most of what production teams call vibe coding is agentic programming with a sloppy review step.
Böckeler’s sensor evidence runs against intuition: cheap computational sensors (linters, complexity rules, dependency-cruiser layering rules) impressed her most at the file and function level, raw coupling metrics fed to an LLM returned lackluster output on a prompt she flags as insufficiently specific, and she was very impressed by inferential modularity review once it had a strong prompt behind it. Mutation testing is the exception on cost — resource-intensive enough that she ran it manually.
Osmani’s orchestration tax names the ceiling the harness does not lift: every piece of agent work that needs real architectural understanding serializes through one human, so the right number of parallel agents is however many you can review properly.
The studies measure the failure modes one narrow slice at a time, and none validates the methodology as a whole: agents tangle refactorings into 21.43% of cases versus 36.72% for the human golden patches they were paired against, stripping consent declarations lifted the overeager rate from 0.0% to 17.1% in paired Claude Code scenarios, and receiving at least one review is the strongest correlate of an agent PR merging.
The accountability floor stays human: agents implement, engineers design, and a team that wants to stop reading agent code at all must, on Olano’s argument, make that an organizational decision and move its rigor to specs and tests.

Why This Matters

Over the first half of 2026, and crystallizing in the last two weeks of May, four independent threads assembled into something closer to a syllabus than to commentary. Martin Fowler’s Bliki stabilized the canonical definition of “vibe coding” with explicit maintainability, correctness, and security caveats — moving the term from Karpathy’s offhand February-2025 coinage into the standard architectural reference. Birgitta Böckeler’s sensors series gave the constructive answer: instrument the harness with computational and inferential sensors so it catches maintainability regressions before a human ever sees the diff. Addy Osmani’s “Orchestration Tax is You” named the bottleneck the harness layer doesn’t remove — human attention is a single-threaded resource that all your parallel agents must serialize against. And a cluster of senior-practitioner critiques (Charlie Holland’s “Claude is not your architect,” Olano’s “--dangerously-skip-reading-code,” Jacob Harris’s “Why I don’t vibe code”) set the rhetorical floor: agents implement, engineers design, and the accountability for what ships stays human.

Academic work published across the same half-year ratifies each leg empirically: refactoring-runaway and overeager-action measurement papers quantify the failure modes, an 11,000-PR study shows how badly merge and rejection labels misread agent capability while a larger PR corpus quantifies what actually gets agent code merged, and CentaurEval quantifies where human-in-the-loop actually adds value. The methodology is catching up to the capability, and the pieces compose into a curriculum a team can adopt deliberately rather than discover by incident.

Key Findings

Fowler’s Bliki fixes the vocabulary, and the caveats travel with it

The definitional move comes first. Fowler’s Bliki, his long-form glossary where vocabulary stabilizes for architectural conversation, now carries “vibe coding” as: “building a software application by prompting an LLM, telling it what to build, trying it out, prompting for changes — but without looking at any of the code that the LLM generates” [1]. The essential characteristic Fowler isolates is the willingness to “forget that the code even exists”: no diff review, no structural inspection.

The caveats travel with the term in the canonical reference, which is the part practitioners should use. Fowler is explicit that vibe-coded software carries maintainability problems (low-quality, voluminous code), correctness risks (hallucination, non-determinism), and security exposure (leaked secrets and credentials) [1].

His scoping is sharp: vibe coding is “best used for disposable software that’s only used by its author or a close group of collaborators who understand and accept the risks involved,” while “code that is more complex, more widely-used, and with more consequences to its risks should not be forgotten about” [1].

The distinction teams most often blur is the one Fowler draws between vibe coding and what he calls agentic programming, where the developer does review the LLM’s output even though they didn’t type it themselves. That line, do you read the code?, is the actual fault line in the methodology debate.

Most of what production teams call “vibe coding” is, by Fowler’s definition, agentic programming with a sloppy review step. Naming the two separately is the first move in the curriculum: the sensors and attention patterns that follow are the apparatus that keeps a team on the agentic-programming side of the line.

Böckeler’s sensors catch what the human can’t read fast enough

If Fowler names the failure mode, Böckeler builds the detector. Her framing treats the harness as “a system of guides and sensors that increase the probability of good agent outputs and enable self-correction before issues reach human eyes” [2].

The vocabulary split is the practitioner takeaway. Guides (Thoughtworks also calls them feed-forward: skills, conventions, guardrails, reference docs) shape generation. Sensors are feedback — “tools that observe what the agent actually produced” and “provide a loop for the agent to self-correct before a human even looks at the code” [11].

Within sensors, the consequential distinction is computational versus inferential [2][11]:

Computational sensors run deterministically on code structure: type checkers, linters (ESLint, Semgrep), dependency analyzers (dependency-cruiser), coverage and mutation-testing tools. Objective and fast, and cheap apart from mutation testing, which Böckeler calls “quite resource intensive” [2].
Inferential sensors use an LLM to interpret code semantically — modularity reviews, coupling analysis — producing contextual judgments a linter can’t.

Her empirical findings cut against the intuition that the LLM sensors are the valuable ones:

Computational sensors dominate at the file/function level. Basic linting on argument counts, file length, function length, and cyclomatic complexity is the concrete case; her verdict is on the class — computational sensors “impressed me most at the file and function level” [2]. She wrote custom ESLint formatters that hand the agent self-correction guidance inline, and raised the question of whether warning management is “now more feasible” — the agent can make a judgment call on suppressing a warning or nudging a threshold, which keeps the exceptions visible and reviewable.
Dependency rules are a high-leverage cheap win. dependency-cruiser enforcing layered architecture (e.g., API clients forbidden from importing orchestration services) let the agent self-correct against folder-concept violations. Her note: “Without AI, I would not have gotten these rules in place quickly” [2].
Raw coupling data is a trap. Feeding an LLM raw incoming/outgoing import metrics produced “quite lackluster” output that misread intentional patterns as problems — because “the raw data itself was very noisy and not that useful without semantic interpretation” [2]. Dependency structure matrices for humans were “tedious to interpret.”
Inferential modularity review is where the LLM earns its place — but only with strong prompts. Driving the review with Vlad Khononov’s Balanced-Coupling “Modularity” skills [12] proved “very fruitful,” surfacing duplicate route code, inconsistent backend-calling patterns, and parameter-handling inefficiencies that computational sensors missed. Without human review and coupling expertise, and without these extra AI reviews, she found the agent “definitely compounding inadvertent technical debt” [2].
Mutation testing beats coverage as a regression sensor. Her worked example: a file at 100% statement coverage and 75% branch coverage, with no unit tests at all, surfaced 13 surviving mutants, the gaps living in missing assertions that coverage alone hid. She notes the sensor is “quite resource intensive” and ran it as manual incremental passes rather than continuously [2].

Two cautions she raises belong in the curriculum. First, the sensors create tension: aggressive max-lines-per-function rules pushed complexity out of functions and into component-property chains rather than removing it [2]. Second, and more important, sensors “are not a magical solution to take the human totally out of the loop” — she explicitly worries they can produce “a false sense of security and an illusion of quality” [2]. The sensor layer raises the floor; it does not remove the ceiling the next finding is about.

Osmani’s orchestration tax: the human is the global interpreter lock

The cleanest naming of the ceiling comes from Osmani. The orchestration tax is “the price you pay for forgetting” that human attention is the serial bottleneck, and “the only real fix is to start architecting your own attention like you architect any concurrent system” [3].

The concurrency metaphor is exact, and the rest of his argument rests on it. It comes from Python’s global interpreter lock (GIL): a program can start as many threads as it likes, but only one runs Python code at a time, because each must first acquire the lock. Osmani’s version: “You are the GIL of your AI agents. They all can run at once. But when any of their work needs genuine understanding of the architecture or resolving merge conflicts, that work has to acquire the lock” [3].

Spawning agents therefore multiplies generation, not judgment. Twenty running agents produce a dashboard that feels like massive productivity while being “decoupled from actually shipping good code to main” [3]. His sharpest warning is about the failure’s invisibility: “You can be maximally busy and barely produce anything. From the inside it feels identical” [3]. The unpaid tax compounds into technical and cognitive debt simultaneously — you merge code you didn’t read well.

The patterns he prescribes are the attention-architecture layer of the curriculum [3][4][5]:

Backpressure as the governing constraint. The right number of parallel agents is how many you “can actually code review properly.” The throughput of the system equals the throughput of the review step — Amdahl’s law applied to a human reviewer.
A two-mode workflow. Local high-touch sessions for architecture and judgment; asynchronous background sessions for bounded mechanical work — mirroring how a manager allocates work across a team [4].
WIP limits, kill criteria, one-agent-per-PR. Cap concurrent streams, define abandonment criteria before building to prevent feature sprawl, and never let a single PR span multiple agents [4].
Git worktrees for isolation, shared interfaces handled human-first before agents build atop them [4].
“Write a brief, not a vibe.” Scope each delegation with outcomes, constraints, non-goals, acceptance criteria, and a verification plan; treat agents “like reports” with predictable async check-ins (what changed, what’s next, what’s blocked) [4].

Osmani’s reframing of the bottleneck closes the loop with Fowler and Böckeler: “the bottleneck is no longer ‘can the agent write code?’ It’s ‘should we build this?’” [4] and “the bottleneck is no longer generation. It’s verification” [5]. The harness raises generation throughput; the human is the verification throughput; the orchestration tax is the gap between the two.

The anti-vibe cluster sets the floor: agents implement, engineers design

The critique cluster supplies the rhetorical and accountability floor the rest of the curriculum stands on. Three pieces, one thesis.

Charlie Holland — “Claude is not your architect.” The argument is that agents are “pathologically agreeable” and structurally “incapable of the thing that makes a real architect valuable: saying ‘no.’” When the agent hands over a polished proposal it “short-circuits the discussion,” replacing the productive disagreement between engineers with deference to the system that has the least context [6].

Its designs are “a generic best practice for a generic problem at a generic company. Which is to say, it was designed for nobody” — no awareness of team expertise, VPC lockdowns, legacy integrations, or compliance. The accountability line is the keeper: “Claude doesn’t have a bag. Claude doesn’t get paged at 3am,” and “if a human’s name isn’t on the architectural decision, nobody owns it.” The prescription compresses to “Engineers design. Agents implement” [6].

Olano — “--dangerously-skip-reading-code.” The title riffs on Claude Code’s permission-bypass flag to make a serious organizational point: a team could rationally choose to stop reading LLM-generated code, treating it like compiled assembly or transpiled JavaScript, but only if it restructures the entire process around that choice [7].

The argument is an Amdahl’s-law point: “LLMs produce non-deterministic output and generate code much faster than we can read it,” so you cannot have some developers generating 20,000 lines a day while others review it. And the choice is not local: “this is not an individual’s or team’s call: it has to be an organizational decision.” [7]

Rigor doesn’t disappear in that model; it migrates from code review to specifications and tests, with standardized specs becoming the “new unit of knowledge” and automated verification confirming conformance rather than humans reading implementation [7]. That is the spec-driven escape hatch from the orchestration tax, and it is an organizational commitment, not a tooling toggle.

Jacob Harris — “Why I don’t vibe code.” The most personal of the three, anchored in Brooks’s No Silver Bullet: LLMs attack accidental complexity but not the essential complexity that “takes skill and experience and wisdom hard-won from system failures past.” Harris values friction as a design signal (“I learn by failing, and if the LLM takes that work away from me, I won’t really understand what I’m doing”) and warns that velocity without that friction produces “a thicket of weird abstractions” documented only by obsolete prompts [8].

The accountability theme recurs: “an LLM can’t care,” and the failure dynamic where “when the LLM does well, it’s a genius” but when it deletes your infrastructure you blame your own prompting [8].

The through-line across the cluster — design ownership stays human, accountability stays human, and the spec/test layer absorbs the rigor that code review used to carry — is not anti-agent. It is the boundary condition that makes the sensors and attention patterns safe to push hard.

The academic layer measures each leg, one narrow slice at a time

The failure modes are now measured rather than only asserted, which separates this wave from the prior year’s enthusiasm/skepticism cycle. Each study lights up one narrow slice (refactoring behavior, authorization, merge dynamics, collaboration value), and none of them validates the methodology as a whole.

Study	What it measured	Headline figures
Refactoring Runaway [9]	Tangled refactorings in 3,691 valid agent patches on Multi-SWE-bench, paired against the benchmark’s 128 human golden patches	Agents 21.43% of 3,691 vs 36.72% of the 128 golden patches; refactoring-aware refinement lifted compilability from 19.34% to 38.33%
Overeager Coding Agents [10]	Out-of-scope actions across ~7,500 runs on four agent frameworks	Stripping consent declarations: 0.0% to 17.1% on paired Claude Code scenarios; permissive frameworks 5.4–27.7% vs ask-to-continue 0.2–4.5%
Agentic PRs merged or rejected [13]	11,048 closed agentic PRs, 717 manually inspected	Only 35.7% of rejections reflected genuine agentic failure
AI teammates meet code review [14]	Collaboration signals on 33,596 agent-authored PRs across 5 coding agents	Merge rate around 71.5%; receiving at least one review is the strongest correlate of integration
CentaurEval [15]	Collaboration-necessary tasks, 45 human participants, 5 LLMs	LLMs alone 0.67%, humans alone 18.89%, together 31.11%

Refactoring runaway is real but smaller than the benchmark’s human baseline. The “Refactoring Runaway” study analyzed 3,691 valid patches across Multi-SWE-bench using three agent frameworks and 12 LLMs, every combination attempting the same set of Java issues. Agents introduce tangled refactorings — refactoring smuggled in alongside the actual fix — in 21.43% of those 3,691 agent patches versus 36.72% of the benchmark’s 128 human-written golden patches for the same issues, at lower intensity (0.66 vs 1.75) but broader type diversity. The comparison is paired issue-by-issue, but its denominators are not: one human patch per issue against roughly 29 agent attempts.

Tangled refactorings are strongly associated with reduced compilability; the study’s aggregate presence variable showed no significant association with its test-based correctness measure. That is a null result, not a clean bill of health — at finer granularity, method-level tangled refactorings were significantly negatively associated with issue resolution too. The study’s refactoring-aware refinement approach lifted compilability from 19.34% to 38.33% and resolved an additional 2.79% of issues [9]. For practitioners, scope creep from agents shows up first and most reliably as a build-breakage signal, and it is detectable.

Overeager actions are a consent problem. “Overeager Coding Agents” built OverEager-Bench (500 validated scenarios, ~7,500 runs across Claude Code, OpenHands, Codex CLI, Gemini CLI and six base models). The headline result reframes scope expansion as an authorization problem distinct from capability failure or prompt injection: stripping explicit consent declarations raised the overeager rate from 0.0% to 17.1% on paired Claude Code scenarios, and framework design dominated — the permissive cluster showed 5.4–27.7% overeager rates versus the single ask-to-continue framework at 0.2–4.5% [10].

The lesson for harness engineering is direct: framework design dominates the effect size, though base-model choice still moves the rate by up to 15.9 percentage points within a framework.

Reviewer engagement is the strongest correlate of an agent PR merging — with an inverted signal. The “Why Are Agentic Pull Requests Merged or Rejected?” study examined 11,048 closed agentic PRs (9,799 human-reviewed, 717 manually inspected) and found that PR outcomes alone are misleading: only 35.7% of rejections reflected genuine agentic failure, while 31.2% were workflow constraints and 33.1% had no observable rationale [13].

A companion empirical line reports an overall agentic-PR merge rate around 71.5%, ranging from roughly 43% (Copilot) to 83% (Codex), with Devin near 54% [14]. Once everything else is controlled for, receiving at least one review is the strongest correlate of integration. Read that as association only: the study is observational, disclaims causal inference, and offers the reverse reading itself — reviewers may be selectively investing effort in changes they already judge viable. In a 60-PR hand-coded follow-up, the dominant success pattern is an actionable review loop that converges toward reviewer expectations.

Raw iteration intensity is not significantly associated with merge once reviewer engagement and coordination stability are accounted for, while larger change sizes and coordination-disrupting actions like force-pushes lower merge odds [14]. What tracks with an agent PR reaching merge is a review it can actually act on, not back-and-forth volume. The study explicitly leaves the agentic-vs-human comparison to future work, so resist importing human-PR review intuitions wholesale.

Human-in-the-loop value is bidirectional and large where it exists. CentaurEval built “Collaboration-Necessary” templates — tasks intractable for standalone LLMs or humans but solvable together (45 templates → 450 tasks, 45 human participants, 5 LLMs, 4 intervention levels). The pass rates: LLMs alone 0.67%, humans alone 18.89%, human-AI collaboration 31.11% — a ~65% lift over human-only [15].

The qualitative finding matters for the “agents implement, engineers design” framing: strategic breakthroughs can originate from either side, an “emerging co-reasoning partnership” rather than a strict human-directs-tool hierarchy. The curriculum tension to hold: the anti-vibe cluster is right that accountability and final design ownership are human, but CentaurEval is evidence that the idea generation can flow both ways. The discipline is about ownership of the decision, not monopoly on the insight.

The supply side explains why this is urgent now

The methodology pressure isn’t accidental timing. The model vendors have collectively repositioned around the harness. Latent Space’s AINews roundup collects the thesis from two X posts it quotes: @gdb’s “the model alone is no longer the product,” and @dzhng’s argument that top-tier products need “model <> harness <> product symbiosis” — alongside AI21 shutting its model team to pivot to agents, DeepSeek standing up a harness team for the first time, OpenAI iterating Codex toward remote computer use and richer agent features [16].

To the degree labs move toward harnesses co-trained with their models — a door the same roundup flags as opening, where a model post-trained to work well only inside its vendor’s agent funnels usage there — the generation-throughput side accelerates by vendor roadmap. The verification-throughput side (the human, the sensors, the attention architecture) does not. The orchestration tax is, structurally, the gap that vendor competition keeps widening, even as those same vendors also invest in verification, review, and test-generation tooling. That is much of why the methodology layer is arriving now: the supply side is making the bottleneck increasingly hard to ignore.

Practical Implications

1. Adopt the Fowler line as a team policy, not a vibe. Write down, per workstream, whether you are doing vibe coding (no code review, disposable or internal only) or agentic programming (review required). The two are different risk regimes, and Fowler’s caveats only attach to the first. Most production vibe coding is mislabeled agentic programming with a degraded review step; name it correctly and the rest of the curriculum has somewhere to attach.

2. Build the sensor stack from the cheap end, and don’t over-invest in LLM sensors early. Reading Böckeler’s results, a sensible build order is: linters and complexity rules → dependency-cruiser layering rules → mutation testing, the one computational sensor she flags for cost → then inferential modularity review with a strong skill behind it. She publishes no ranking and no cost measurement, so the ordering is a reading of her results rather than a finding of hers; on that reading, custom ESLint formatters that feed the agent self-correction guidance inline are the highest-leverage place to start. Don’t expect much from raw coupling data fed to an LLM without a structured prompt — her own first hypothesis for the lackluster result is that her prompt wasn’t specific enough, and she still finds the data useful for change-impact triage. Reserve the inferential sensor for modularity and coupling judgments where you can point it at a structured framework like the Balanced-Coupling modularity skill.

3. Don’t trust coverage alone as the regression sensor. Coverage at 100% with surviving mutants is the exact false-confidence failure Böckeler warns about. Keep coverage as the cheap, continuous signal, and run mutation testing in periodic passes, treating surviving mutants as the gaps coverage hides; a harness that answers only to coverage is instrumenting the illusion of quality. That matches how Böckeler used them: together, not one instead of the other, on a single file in one TypeScript codebase, with mutation testing run as manual incremental passes.

4. Set your parallel-agent count to your review throughput, then defend it. Osmani’s backpressure rule is the single most important operational number: the right number of concurrent agents is how many PRs you can actually review properly. Pick that number, set WIP limits, define kill criteria before building, and enforce one-agent-per-PR. The dashboard-full feeling is not throughput; merged, reviewed code is.

5. Optimize agent PRs for an actionable review loop, not iteration volume. The agentic-PR evidence associates merge with getting a review the agent can converge against, not with raw back-and-forth, which is not a significant predictor once reviewer engagement and coordination stability are controlled. That evidence is observational, so treat the review loop as the signal to work with rather than a lever proven to cause merges. Keep diffs small, avoid force-push churn, and make sure each agent PR draws a real review rather than accumulating un-actioned iteration.

6. Default the harness to ask-to-continue for anything touching files outside the stated scope. The overeager-actions data puts the dominant effect on framework design: permissive products ran 5.4–27.7% out-of-scope action rates against the ask-to-continue framework’s 0.2–4.5%. That comparison is observational across four products differing in more than permission gating, and base-model choice still moves the rate by up to 15.9 percentage points within a framework — so ask-to-continue is a config posture worth taking first, not a substitute for model choice.

7. Skipping code review is an organizational decision that moves the rigor to specs and tests. Olano’s is the disciplined version of the vibe-coding dream: unread code is survivable only if specs and automated verification carry the rigor, and only if the whole org commits; partial adoption fails to Amdahl’s law. This connects to the harness-as-spec-machine pattern from prior production reporting: owning the spec makes model upgrades cheap; owning the code makes them refactors. Most teams should not take this step yet; those that do should take it deliberately and completely.

8. Keep design ownership and accountability human regardless of how good the harness gets. The anti-vibe cluster’s accountability argument is not a productivity tax; it is the boundary condition that makes pushing the sensors and parallelism hard safe. Require a human name on every architectural decision. Use agents for speed on things people designed, and treat the agent’s enthusiastic proposals with the skepticism you would apply to a confident junior with no production context. CentaurEval shows insight can come from either side; ownership of the decision cannot.

Open Questions

Does the sensor stack generalize past TypeScript/web? Böckeler’s findings come from a TypeScript dashboard with a mature linter/dependency-rule ecosystem. The cheapest, highest-leverage sensors (custom ESLint formatters, dependency-cruiser) are JS-ecosystem-specific. How much of the order-of-return survives in Python, Go, or polyglot repos where the deterministic-sensor tooling is thinner?
What’s the right inferential-sensor cost ceiling? Running an LLM modularity review on every change is a token cost that scales with change volume. Böckeler’s results show it is valuable with strong prompts, but nobody has published the economics of running it continuously versus on a sampling cadence. Where is the break-even between sensor cost and the technical debt it prevents?
Can backpressure be automated, or is it irreducibly human judgment? Osmani’s “set agents to your review throughput” is a manual discipline today. Is there a measurable proxy for “reviewing properly” that a harness could enforce automatically (e.g., gating new agent spawns on review-queue depth), or does the GIL stay manual because “reviewing properly” resists quantification?
Do agentic-PR review dynamics actually differ from human-PR dynamics? The merge-prediction work on agent PRs explicitly defers the comparison with human-authored PRs to future work. So it remains unestablished whether what predicts integration for agent PRs (reviewer engagement, coordination stability, small diffs) diverges from the human baseline, or whether teams can safely reuse their existing review intuitions. If the dynamics differ materially, agent-PR triage needs its own playbook rather than an inherited one.
Where does the spec-as-rigor-layer break first at scale? Olano’s “move rigor to specs and tests” and the broader spec-driven escape hatch assume specifications can carry the verification load that code review used to. At what organizational size or system complexity does the spec itself become the unread artifact, the thing nobody reads carefully because the agent generates it too, recreating the original problem one level up?

Scout: The Coding-Agent Methodology Curriculum — Failure Modes, Sensors, Attention Architecture, and the Harness Moves That Connect Them