The author argues that developers using AI fall into two distinct camps—those who read and understand generated code ("accelerators") and those who delegate implementation entirely to AI ("vibecoders")—and that these aren't points on a spectrum but fundamentally different commitments with different long-term costs.

• Reading code matters because programming is ultimately about building a mental model of the domain, not just producing working software; without understanding the implementation, you lose the ability to explain decisions, anticipate consequences, and adapt to change.
• Vibecoders risk accumulating "intent debt" as context drifts between sessions and requirements get lost, while accelerators risk drifting into vibecoding if they stop reading diffs—there's no safe middle ground.
• The choice between these approaches isn't about how much the AI writes, but about your relationship to the output and whether you're committed to maintaining ownership of the reasoning behind the code.

AI has made producing code, tests, policies, and organizational structures nearly free, but maintaining and understanding them hasn't gotten cheaper. This creates a trap where systems accumulate layers of infrastructure faster than they provide value, turning the factory into its own largest customer.

• Steve Yegge's AI agent system (Wheelhouse) grew to 600,000 lines of supporting code—nearly matching the 1.2M lines of the actual product itself—complete with constitutional governance, legal rulings, and a "Head of Wheelhouse Law" role, all created in under ten weeks.
• AI removes the friction that historically forced teams to justify new policies, tests, and documentation. What's cheap to generate becomes expensive to maintain: every new rule creates potential contradictions, every test needs monitoring, every document is a possible source of confusion.
• The real failure mode isn't obvious incompetence—each individual addition looks sensible. The problem is capacity-seeking-utilization: once you have agents producing work constantly, the system needs more coordination infrastructure to manage that work, which creates more things to maintain.
• Engineering telemetry shows the gap between activity and value: teams with high AI adoption completed 21% more tasks and merged 98% more PRs, but review time jumped 91%, PR size ballooned 154%, and bugs per developer rose 9%.

This article breaks down the “agent harness” as the orchestration layer—prompts, tool interfaces, loops, memory, guardrails—around foundation models. It argues that teams accumulate hidden technical debt when they treat harnesses as permanent and shows why training and production harnesses must differ to avoid failures as models evolve.

• Harness code (prompts, tool wrappers, loops, guardrails) becomes obsolete as models improve, so teams treating it as permanent architecture waste months later ripping it out
• Research harnesses need broad, open tool access so optimizers can learn new capabilities, while production harnesses need strict allowlists, scoped credentials, and deny-by-default controls—using one harness for both either stifles learning or creates security risk
• "Inner" harnesses (built by the model/agent developer) and "outer" harnesses (built by end users via skills, MCP servers, custom agents) evolve on different timelines and accumulate separate technical debt

This article lays out seven hard-learned rules every engineer breaks at least once—like “rollback first, debug later,” testing backups by restoring them, and always having a tested rollback plan. It also covers handling external failures, using four-eyes checks for risky changes, logging trade-offs, and avoiding “temporary” fixes that stick around forever.

• When production breaks after a deploy, roll back immediately and debug afterward rather than wasting time proving your change is innocent
• Backups are worthless untested—actually run restore drills, since restore times can balloon as data grows and permissions/procedures may be unclear
• Every third-party API will eventually fail, so know rate limits, SLAs, and whether you can queue requests or serve stale data before it happens
• Risky changes (migrations, infra tweaks, dangerous scripts) need a second reviewer, and "temporary" fixes should be built clean since they often become permanent

The article compares human “rockstar” developers—who produce clever but inscrutable code—with AI tools that can churn out massive, disjointed codebases. It shows how both create unmaintainable systems and recommends guiding AI to generate small, understandable snippets, slowing down to match architecture to problem complexity, and keeping craftsmanship in human hands.

• AI coding tools act like "rockstar" developers of old: producing huge volumes of code fast, but leaving behind unmaintainable messes once the task is "done"
• Unchecked AI output leads to tangled codebases so complex that only another AI can parse them, creating technical debt that's effectively unpayable
• The fix is treating AI as a guided tool rather than an autonomous contributor: small prompts, human-understandable code, and matching architecture complexity to the actual problem
• Sometimes writing a few lines by hand beats wrestling with AI-generated noise—craftsmanship can't be outsourced

The author revisits Fred Brooks’s classic software lessons in the era of AI coding agents, arguing that while agents wipe out accidental complexity, they amplify essential design challenges and generate unprecedented technical debt. He warns of new “agentic” tar pits, scope creep, and coordination overhead as AI swarms bloat codebases and shift the real work back to human judgment and taste.

• AI agents eliminate accidental complexity (boilerplate, tests, refactoring) but can't handle essential design work, which still requires human judgment
• Past ~100,000 lines of code, agents start "chasing their own tails," generating defensive boilerplate that clogs codebases—seen in McKinney's own projects and Posit's million-line Positron fork
• Coordination overhead doesn't disappear with AI, it just changes form: parallel agent sessions produce contradictory plans that force humans back into the loop
• Going from agent-generated prototype to production-ready code (testing, documentation, edge-case hardening) remains fundamentally human work

This article discusses the dangers of accumulating technical debt, especially in the context of rapid AI advancements. While it may seem beneficial to defer debt repayment for future improvements, this approach can lead to an overwhelming complexity that even AI tools can't manage. Developers must balance short-term gains with long-term sustainability.

• AI-assisted coding tempts developers to defer technical debt indefinitely, betting that future model improvements will make it cheap to fix later, with some codebases growing past 40,000 lines/day.
• This bet assumes AI capability growth continues indefinitely, but once it plateaus, accumulated debt becomes unfixable by any human or AI.
• The result is "subprime" technical debt—debt whose risk was mispriced on the assumption of endless future gains, setting up an eventual reckoning.