"Write as Little Code as Possible"

TL;DR: Write As Little Code As Possible and Agentic Coding

Agentic coding tools have collapsed the friction of producing plausible software; output is no longer an issue. However, they have not collapsed the friction of knowing what is worth building, whether it fits the system, or whether users will change their behavior because of it, the much-desired outcome. When generating plausible code becomes cheap, every hour spent building the wrong thing becomes waste that can now be produced at scale. Discovery, validation, product judgment, and verification are what stand between your team and creating expensive waste at high-speed.

Thesis: AI made generating code cheap enough that weak product judgment can now scale. That is the problem this article addresses.

🎓 🇬🇧 The Claude Cowork Online Course — Available June 8-15 for $129

You have been prompting AI for months. The results are inconsistent, every conversation starts from zero, and the model forgets who you are. That is the ceiling of prompting.

The Claude Cowork Online Course teaches you to break through it: build Skills that encode your expertise, connect them to your tools, and assemble Agents who handle recurring work the way you would handle it yourself. No coding required.

What You Will Get:

✅ 8+ hours of self-paced video modules: Skills, Agents, delegation frameworks — ✅ Tested with a live BootCamp cohort (April 2026) — ✅ The A3 Framework: decide what to delegate and what to keep — ✅ Starter kit with folder structure, CLAUDE.md, and Skill templates — ✅ All texts, slides, prompts, graphics; you name it — ✅ Designed for the $20/month Pro plan — ✅ Lifetime access to the version you purchase — ✅ Claude Cowork Foundational Certificate.

👉 Please note: The course will be available for $129 from June 8 to 15, 2026! (After that, $199.) 👈

🎓 Join the Waitlist of the Course Now: Claude Cowork: Stop Prompting. Start Delegating. No Coding Required!

🇩🇪 Zur deutschsprachigen Version des Artikels: ‘Schreiben Sie so wenig Code wie möglich’ war schon immer der Punkt. KI hat ihn nur dringend gemacht.

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers.

🎓 Join Stefan in one of his upcoming Professional Scrum training classes!

The Bottleneck Was Never Typing Speed

Years ago, serving as an agile coach on an ambitious project of a large utility company, I shared with the engineers something they did not want to hear: I did not want them to write as much code as possible. I wanted them to write as little code as possible, just enough to solve the customer’s problem.

That required knowing what the problem actually was. So I asked them to join product discovery, sit in user interviews, and watch real people struggle with real workflows. Some of them resisted: they were more interested in solving puzzles, and writing code felt productive. In comparison, sitting in interviews felt like a waste of their time. But the engineers who showed up learned what “enough” meant. They stopped guessing what users needed, started watching what users actually did, and shipped useful features. The ones who stayed at their desks shipped “tickets.”

Recently, someone on LinkedIn called “write as little code as possible” a wonderful aphorism. I consider it less an aphorism than a critical engineering discipline. And in 2026, it has become the single most urgent discipline in software development.

AI Collapsed Generation Cost, Not Product Risk

Codex, Cursor, Claude Code, GitHub Copilot, Devin: the tools keep multiplying. They generate working code in minutes. Autonomous loops run AI coding agents for hours without human intervention. Changes accumulate while the team sleeps.

The output is impressive. The danger is that it now looks like progress before anyone has asked whether progress is happening.

The marginal cost of generating another plausible implementation is collapsing. The cost of understanding, validating, securing, and maintaining it is not. This distinction matters more than any benchmarking debate about which tool is fastest.

For decades, the cost of building software imposed a natural discipline on product teams. Engineers were expensive. In many Western software organizations, a small development team can easily represent a high six-figure annual investment once salaries, benefits, management, tooling, and overhead are included. That expense forced decisions. You could not afford to build everything, so you had to choose. Product people had to prioritize. Stakeholders had to make tradeoffs. The cost was a gate. In many organizations, that gate was mistaken for product discipline.

Agentic coding weakens that gate. The implementation cost that once forced at least some teams to ask “should we build this?” no longer exerts the same pressure. And organizations are discovering what happens when the gate no longer holds: they build everything, validate nothing, and wonder why the product becomes a collection of features that nobody asked for. It is Word on steroids, compressed from decades into weeks.

The Old Brake Before “Little Code”: Cost Masqueraded as Discipline

The expense of building software was doing double duty. The cost did not just limit what got built. It also created natural review points. When a feature took weeks to implement, the team had time to reconsider. Someone would ask a question in standup. A designer would notice a mismatch. A stakeholder would change priorities. The slowness was a brake, and the brake was doing useful work.

But the cost of engineering was never good product discipline. It merely disguised the absence of product discipline. Plenty of organizations burned through expensive engineering time building the wrong things for years. The cost gate slowed waste; it did not reliably prevent it.

Agentic coding does not remove every constraint, but it weakens the one many organizations unconsciously relied on.

The wrong feature can now reach a polished demo, a convincing prototype, or even production before anyone has had a serious conversation about whether it should exist. Speed used to protect organizations by creating pauses where judgment could intervene. That protection is gone.

We are now facing an inversion: building the wrong thing used to be survivable, because the cost of building gave teams time to course-correct. With agentic coding, building the wrong thing compounds faster. You do not discover you built the wrong thing during a code review or a backlog refinement session. You discover it after launch, when usage data flatlines.

Cannot see the form? Please click here.

The Evidence Points in the Same Direction

The pattern is no longer hypothetical: Richard Ewing, a product executive, described exactly this dynamic in a January 2026 post-mortem on Built In. His team built a technically impressive AI-powered search tool. The engineering team used vector databases, the latest LLMs, and a RAG pipeline. Their accuracy scores were near-perfect: 0.92 nDCG compared to the legacy system’s 0.65. The demo looked like magic. They shipped it, waited for adoption to climb, and watched it flatline.

When Ewing’s team finally ran user research after launch, they discovered they had given users homework instead of removing labor. The tool required users to stop their workflow, open a sidebar, write a prompt, wait for a response, and paste the result back into their work. Nobody wanted that. The AI feature went down for maintenance one afternoon, and nobody called support because no one cared. That silence was the feedback.

The technical execution was excellent, but that did not make up for the wrong product decision. AI made the perceived “solution” easier to build; it did not make the user’s workflow easier to understand.

Addy Osmani, a director at Google Cloud, identified a related failure mode using a term coined by Jeremy Twei: “comprehension debt.” In a January 2026 analysis, Osmani described what happens when developers accept AI-generated code that passes tests without truly understanding what it does. He caught himself doing it: Claude implemented a feature, the tests passed, he skimmed the code, merged it, and three days later could not explain how the feature worked. The codebase grows. Understanding shrinks.

Osmani cites research showing that teams with high AI adoption merged 98% more pull requests, while review time rose 91% and pull request size increased 154%. He draws on Faros AI telemetry and Google’s 2025 DORA report, which both warn that AI adoption amplifies existing organizational strengths and weaknesses rather than fixing broken delivery systems. Code review became the new bottleneck: While we got faster at producing change, we did not get equally fast at understanding its consequences.

On the security side, Veracode’s 2025 GenAI Code Security Report found that AI-generated code introduced security vulnerabilities in 45% of tests across more than 100 large language models and 80 coding tasks. The models produced functional, syntactically correct code that failed security requirements nearly half the time.

Documented production failures tell the same story from the other end. The Lovable platform vulnerability (CVE-2025-48757) exposed applications built on the platform to unauthorized database access due to insufficient row-level security, with a CVSS severity score of 9.3 (Critical). The systemic nature of the flaw sparked debates over the shared responsibility model, as Lovable argued that customers must actively secure the business logic of applications they generate.

In a separate, widely reported incident in July 2025, Replit’s AI coding agent deleted a live production database during a vibe-coding session. Despite explicit natural language instructions enforcing a strict code freeze, the agent bypassed safeguards and erased critical records for 1,206 executives and 1,196 companies. Replit CEO Amjad Masad publicly apologized and announced immediate infrastructure fixes, including mandatory segregation of dev/prod environments.

In both cases, the surrounding verification and responsibility model failed to keep pace with software that could be produced or changed very quickly. The speed of delivery compressed the window where someone could have intervened.

What the Evidence Shows

Product failure without product learning: Ewing’s AI search tool scored 0.92 nDCG accuracy but flatlined on adoption because the team never observed how users actually work. The tool added workflow steps instead of removing them. Technical excellence did not compensate for a missing product decision.

Comprehension debt without code understanding: Osmani’s analysis shows developers merging AI-generated code they cannot explain days later. Teams with high AI adoption merged 98% more pull requests while review time rose 91%. Code production scaled. Code understanding did not.

Security failures without verification infrastructure: Veracode found AI-generated code introduced security vulnerabilities in 45% of tests. Production incidents at Lovable and Replit showed that functional code without adequate verification reaches users before anyone catches the flaw.

What “Write As Little Code As Possible” Actually Means in 2026

The original discipline was about restraint. Know the problem before you write the solution. Validate assumptions before you commit resources. Ship the smallest thing that tests whether you are right. Agentic coding does not change any of that. It makes all of it more urgent.

“Write as little code as possible” now means: do not l

[truncated for AI cost control]