Phronesis and AI Coding Agents: The Skill the Model Cannot Give You

AI coding agents have collapsed the cost of writing code to roughly zero. The cost of knowing when and how much code to write has not moved. Most of the current “AI productivity” debate is people talking past each other because they are mixing those two skills together. One frame, borrowed from Aristotle, separates them cleanly; read Mario Zechner, Addy Osmani, Kent Beck, Simon Willison, METR, and Steve Yegge through it and the apparent contradictions dissolve into a single disagreement. On that disagreement, Zechner is closer to right than Yegge is, but Yegge’s foil sharpens the point rather than blunting it.

The Two Skills the Debate Keeps Confusing#

A car that can suddenly do 300 km/h does not oblige you to drive it there. At 300 km/h you cannot make fine maneuvers. On narrow, winding roads you lose the line. Knowing when to be fast and when to be slow is itself a skill, and it is not in the car.

AI coding agents are a car that lost its speed limit. Producing the artifact, the function, the working implementation, is now near-free. Knowing whether to produce it at all, in this codebase, with these on-call rotations, for this customer profile, is a different and unchanged skill, and it is the one worth arguing about now that the speed question is settled.

Aristotle had a clean name for it. In Book VI of the Nicomachean Ethics he distinguishes three intellectual virtues: episteme (unchanging knowledge, like mathematics), techne (the craft of making things, what a potter or a React developer has), and phronesis (practical wisdom; deliberation about what to do in this situation, with these constraints, for this end). Phronesis is the one that requires lived experience of particular cases. Aristotle states this plainly: a young person can be a brilliant geometer or a skilled craftsman, but cannot have phronesis, because phronesis is built from accumulated judgment about cases that actually went somewhere.

This is the frame. Agents drive down the marginal cost of techne, and none of what phronesis requires lives in the model weights or can be fully encoded into a CLAUDE.md file or a “skill.” If you use Claude Code or Cursor every day, have shipped real features with them, and have been bitten at least once by something the agent confidently got wrong, the claim that matters is this: “use AI more” and “slow down with AI” are not contradictory. They are answers to two different questions, and the frame above is how you tell which question you are looking at.

Why the Experts Look Like They Disagree#

Read the loudest voices in this space side by side and they sound contradictory. They are not. They are all talking about the same single split, just from different sides of it.

• Addy Osmani’s 70/30 split. Osmani’s claim is that AI agents will do the first 70 percent of a task (techne, now cheap) brilliantly and the last 30 percent (security, edge cases, maintainability, fit; phronesis, still expensive) badly.
• Kent Beck’s TDD-with-agents. Beck calls TDD a “superpower” when paired with agents and warns that agents will happily delete a test to make it pass. The test is phronesis externalized: the agent grinds techne against a phronetic spec.
• Willison “ships from his phone” because his repos have fast tests, strict lints, type checks, preview environments, and protected branches. He is not running faster; his scaffolding holds phronesis for him, so he can hand techne to the agent. That speed was bought up front.
• METR’s 19 percent slowdown. METR’s 2025 randomized trial measured experienced developers on familiar repos using AI agents. Participants predicted they would be ~24 percent faster. They were ~19 percent slower; and even after the trial, still felt ~20 percent faster. METR’s February 2026 follow-up acknowledges the sampling caveats (experienced devs, familiar code, the worst case for AI assistance). The perception gap is what happens when you mistake the feeling of fluent techne for the result of phronesis.
• Zechner argues that agents compound mistakes faster than humans can catch them; the discipline is scoping tasks tightly and reading the diff every day.
• Yegge’s “code is a liquid” position, in shorthand, holds that the orchestration layer will absorb the judgment, the bottleneck is organizational ability to absorb agent output, and you should stop looking at the code. He is betting that phronesis can be moved into the orchestrator; everyone else above is betting it cannot. That is the real disagreement.

So the six positions reduce to one axis with two ends. On one end: phronesis stays human. On the other end: phronesis migrates into the tooling layer. Zechner, Osmani, Beck, Willison, and METR cluster on the first end (with different operationalizations). Yegge sits on the second end.

The Debate Synthesis#

Closer to Zechner than to Yegge, with respect for what Yegge is actually arguing. Here is why.

Phronesis is consequence-shaped. The judgment about whether to ship this code, in this state, into this system, is judgment about what happens next, in places the orchestrator cannot see. A model can see the diff. A model cannot see the on-call rotation, the customer who has just been migrated, the regulator who is asking new questions this quarter, the half-finished refactor in the next sprint, the junior teammate who is going to maintain this in six months without context. The consequences of code change live downstream of the orchestrator’s visibility, and they live downstream in places that change faster than the model’s training data.

Yegge’s argument has a real version and a weak version. The real version is that the spec-to-execution loop is now extraordinarily cheap, and treating “looking at code” as the central act of engineering will become as anachronistic as treating “feeding the punch-card reader” as central. He is right about that loop. The weak version is that this generalizes to “you do not need to look at the code.” It does not, because the spec-to-execution loop is not the only loop. There is also the consequence-to-spec loop, and that loop runs through human judgment about a future the orchestrator has no information about.

So: Yegge is right about the speed of one loop and wrong about which loop is load-bearing. Zechner is right about the loop that is load-bearing and slightly understating how cheap the other loop has become. The synthesis is Osmani’s 70/30, Beck’s TDD rhythm, and Willison’s scaffolding, all of which institutionalize phronesis in different places so techne can run free where it is safe.

The Perception Gap#

A short note from working with agents on this codebase. There was a refactor that felt fast. The agent produced a working diff in maybe twenty minutes, the tests passed, the preview deploy looked correct, and the satisfying click of “merge” arrived shortly after. Two days later, a small piece of phronesis that was not in the spec (a build-time behavior on a specific Astro content collection edge case) surfaced as a broken sitemap entry that no test was watching. The fix took longer than the original “fast” change. The original change felt fast because the techne part was fast. The full operation, including the part where someone notices the gap, was not fast. The METR finding generalizes: the feeling of producing fluent code is not the same signal as the result of producing the right code.

The incident is not unusual; it is what the METR data describes when it happens to one person. The dashboard reads “fast” because techne is fast, but production runs on a different time scale.

A Decision Framework Rooted in Phronesis#

The questions worth asking before any agent task are phronetic. Speed falls out of the answers.

The root of the tree is two phronetic questions. Can you scope the task? Who pays if it breaks? Speed only enters after both are answered. You do not pick a speed and then check if the task is safe at that speed. You read the situation, and the situation determines the speed.

The branches map roughly to a consequence ladder:

Context	Suggested speed	Why
Throwaway prototype, no users	Full agent autonomy	Crash radius is you
Internal tool, small blast radius	Agent-drafted, human-reviewed	Failure is annoyance, not loss
Customer-facing, reversible	Agent-assisted, paired review	Failure is rollback
Customer-facing, irreversible (payments, data migration, auth)	Hand-written or heavily supervised	Failure is the kind that makes the news
Public API, library, infrastructure	Phronesis-first; agent for boilerplate only	Other people pay the cost of mistakes

The asymmetry to notice: the cost of being too cautious in row one is small (you spent more attention than necessary). The cost of being too fast in row five is borne by people who never consented to your speed. That asymmetry is why the safe default is to slow down at the bottom of the table.

Phronesis Encoded Into Scaffolding#

Willison’s “ships from his phone” is the most useful operational claim in this space, because it shows that the choice is not actually “human or agent.” The choice is “where does the phronesis live.” If it lives only in your head, you must be present for every merge. If it lives in the scaffolding (tests, types, lints, CI gates, build-time checks, protected branches, preview deploys), the agent can move quickly inside the rails the scaffolding draws.

A concrete example from this site’s build pipeline. Mermaid diagrams in blog posts are rendered to SVG at build time, cached by content hash, and shipped as static markup. The build fails loudly if a diagram cannot parse. This is not a sophisticated piece of engineering; it is one rehype plugin and a cache directory. What it does is move a piece of phronesis (the judgment “this diagram should actually render in production, on the production runtime, without surprises”) out of the reviewer’s head and into the build. An agent can now propose a Mermaid diagram, the build either accepts it or rejects it, and the human time saved is real.

The same principle applies one tier up. Astro Content Collections enforce frontmatter schemas at build time, so an agent that hallucinates a category field or a malformed date cannot land it. The phronesis (the rule “posts must have valid frontmatter or the build fails”) is in the schema, not the reviewer. The pattern generalizes:

• Schema validation at build. Move “the agent forgot a field” from a human catch to a machine catch.
• Test count regression as a CI gate. Beck’s warning. If the test count drops between commits and the diff did not delete a feature, fail the build.
• Type checks on the strictest setting. TypeScript’s strict is phronesis encoded. Use it.
• Protected branches with required reviews. The agent cannot self-merge. The reviewer is the smallest possible piece of in-the-loop phronesis, and it should not be optional.
• Preview environments per PR. Lets the reviewer apply phronesis to a running artifact.
• A pre-commit hook on token-budget creep. The CLAUDE.md and skill set that an agent loads also takes phronesis: choose a tight set, not an “awesome list.” (More on this in Why Copying Others’ Claude Code Skills Doesn’t Work.)

Each of these is one piece of phronesis lifted out of the reviewer’s head and frozen into a check. The compound effect: the human reviews what the machine cannot check, instead of re-checking what it should have caught already.

Practices That Operationalize the Frame#

Each habit below ties to one of the experts above. Pick the ones that fit your team; the point is to make phronesis explicit somewhere in your loop.

Scope first, then unleash (Zechner). Before running the agent, write down the bounded task, the acceptance test, and the rollback plan. If you cannot fit the task in three sentences, the task is too big to delegate.

# Agent task scope
- What: add idempotency key handling to POST /orders
- Done when: 100 duplicate requests in the test produce 1 order, returns same response
- Rollback: revert single commit; no schema migration in this scope

Beck’s practice: externalize judgment into a failing test, written by hand, before the agent touches the code. Let the agent implement against that test, then add a CI gate that fails if the test count drops between commits. The agent brings the power; the test is the rail.

Invest in scaffolding before autonomy (Willison). Before you raise the agent’s permissions, raise the build’s strictness. Add the lint, the type check, the schema validation, the preview deploy. The agent’s safe speed is bounded by the scaffolding’s ability to catch its mistakes. If you cannot articulate what the build catches, you cannot articulate why an agent at that speed is safe.

Zechner’s other habit is reading the day’s diff yourself, every day, thirty minutes at a time. The summary is the techne report; the diff is the artifact the future maintainer will read. It catches the small confidently-wrong choices the tests did not cover, and it surfaces the perception gap before it accumulates.

Match speed to consequence. Read the situation; choose the speed. The mistake is letting yesterday’s speed carry into today’s task without checking whether the consequence profile changed.

Where Phronesis Gets Skipped#

A few failure modes that recur, ranked by how often they show up in conversations with other teams using these tools.

• Mistaking the feeling of speed for actual speed. The METR finding is the canonical case, but it generalizes. If your only signal is “this felt fast,” you are measuring techne and calling it productivity. Track at least one outcome metric per workflow.
• Encoding phronesis into CLAUDE.md and assuming it will be followed. The file is a hint to the model. The actual constraint is the test, the type check, the CI gate; that is where the judgment lives.
• Letting agents delete tests to make them pass. Beck flagged this directly. Add a pre-commit hook or a CI gate that fails on test count regression. The agent will, under pressure, take the path of least resistance, and removing the failing test is the path of least resistance.
• Outsourcing the diff review to another agent. Agents reviewing agents compounds the same blind spot in both directions. At least one human eye per merged change, even if cursory, even if it only catches one mistake a month.
• Conflating “I can do this with an agent” with “I should do this with an agent.”
• Building a 12-MCP-server, 50-skill setup because someone else does. This is cargo culting, and it is itself an absence of phronesis: choosing what an agent loads is a judgment about what your work actually needs. See Why Copying Others’ Claude Code Skills Doesn’t Work for the token-budget math.
• Tracking only techne metrics. Lines of code, PR throughput, “AI acceptance rate” are all techne metrics. Add at least one phronesis-flavored signal: time-to-first-incident on agent-authored PRs, rework rate within thirty days, on-call pages per shipped feature. The numbers do not have to be precise; they have to be in the conversation.

Trade-offs Worth Naming#

The position above carries real costs.

Slowing down is unevenly distributed. A solo founder shipping an MVP and an engineer at a regulated bank should not be operating at the same agent speed. The decision framework above is contextual by design.

Phronesis costs time. End-of-day diff review is thirty minutes a day you were not spending before. The defense is that this is cheaper than the incident, the rework, and the maintainer’s resentment, but it is a real cost all the same. If your team adopts the practice, name the cost out loud, do not pretend it is zero.

The advice is not cleanly measurable in the short term. You cannot A/B test “did slowing down prevent the incident that would have happened anyway.” The argument has to be made on first principles plus accumulated patterns, not on a single benchmark. That is uncomfortable in a culture that wants every recommendation backed by a chart. The METR study is the closest thing the field has to a load-bearing data point, and even METR has updated its caveats since publication.

Default Scope and Exceptions#

The default holds for the working engineer on a team shipping software that real users depend on: encode as much phronesis as you can into the build and the review loop, and slow down at the bottom of the consequence ladder where other people pay for your mistakes.

Where the default does not hold: throwaway code, personal scripts, prototypes whose only user is you. In that context Yegge’s framing is closer to right, the orchestrator can absorb most of the judgment, and the “spray code through hoses” mode is fine because the consequences of mistakes are bounded to you. The mistake is letting the agent speed that works in that mode carry over into the contexts where it does not.

If there is one next action: pick the single piece of phronesis that lives only in your head today and move it into the build, whether that means a CI gate, a schema, or a pre-commit hook.

References#

• Thoughts on slowing the fuck down (Mario Zechner) (opens in new tab) - The seed essay; argues agents compound mistakes faster than humans can catch, recommends scoped tasks and daily diff review.
• The 70% Problem: Hard Truths About AI-Assisted Coding (Addy Osmani) (opens in new tab) - The techne/phronesis split rephrased for engineers; coined “house of cards code.”
• The 80% Problem in Agentic Coding (Addy Osmani) (opens in new tab) - Osmani’s 2026 follow-up tightening the diagnosis as agents have become more capable.
• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (METR) (opens in new tab) - The 19% slowdown randomized trial; the perception gap is the load-bearing finding.
• We Are Changing Our Developer Productivity Experiment Design (METR, February 2026) (opens in new tab) - METR’s own acknowledgement of sampling caveats in the original study.
• Agentic Engineering Patterns (Simon Willison) (opens in new tab) - The “ships from phone” counterpoint; credits scaffolding and CI, not the model.
• Highlights from My Conversation About Agentic Engineering on Lenny’s Podcast (Simon Willison) (opens in new tab) - Source for the “merging PRs from his phone” detail referenced above.
• TDD, AI Agents and Coding with Kent Beck (The Pragmatic Engineer) (opens in new tab) - Agent-as-unpredictable-genie metaphor; TDD as the externalized phronesis loop.
• Steve Yegge on AI Agents and the Future of Software Engineering (The Pragmatic Engineer) (opens in new tab) - The 8-levels framework and the orchestration-absorbs-everything argument; the post’s primary foil.
• Steve Yegge Wants You to Stop Looking at Your Code (O’Reilly Radar) (opens in new tab) - Primary source for the “Formula One” framing and the “code is a liquid” line paraphrased above.
• The End of the curl Bug-Bounty (Daniel Stenberg) (opens in new tab) - Primary source from the maintainer on AI-generated noise costs.
• Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding (arXiv 2602.23905) (opens in new tab) - Empirical study of 22,953 PRs across 1,719 vibe coders; 4.52x review comments and 31% lower acceptance.
• Phronesis (Wikipedia) (opens in new tab) - Accessible summary of the episteme/techne/phronesis distinction from Nicomachean Ethics Book VI.
• Why Copying Others’ Claude Code Skills Doesn’t Work (SPH) - Internal cross-link; the cargo-cult-config problem is itself an absence of phronesis.
• The AI Assistance Spectrum (SPH) - Internal cross-link; the assistance-level framework is the techne axis; phronesis is the axis that selects across its levels.