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 let the tool run until the problem has earned the right to consume code. Earning that right requires the same things it always required: talking to users, testing assumptions, watching people work, and having the discipline to say “we should not build this” even when building it would take five minutes.
The same split I saw with engineers years ago is happening now, except the stakes are higher. A developer with an agentic coding tool who skips discovery can produce a month’s worth of wrong features in a week. A developer with the same tool who starts with a validated problem statement can produce a month’s worth of right features in a week. Same tool, same speed, but opposite results: one produces output, the other creates outcome.
Varun Dubey, a founder writing about his experience with agentic coding in WordPress plugin development, identified the core dynamic in May 2026: once AI handles execution, the constraint moves to judgment:
- Who decides what gets built?
- Who checks whether the implementation fits the existing architecture?
- Who catches that “functional” and “right for this codebase” are different standards?
When the answer is “the agent handles it,” architectural debt accumulates at the agent’s working speed.
Where the Saved Engineering Time Should Go
The hours AI saves in implementation should not disappear into a larger backlog. They should be reinvested upstream into discovery and downstream into verification.
Discovery before generation: Spend more time observing user workflows before asking the agent to build. The person who can describe the user’s problem in three precise sentences has reduced more risk than the person who built a polished answer to a question nobody confirmed.
Assumption testing before backlog expansion: Treat every feature idea as a hypothesis, not as another task for the agent. The question “what would have to be true for this feature to matter?” costs nothing to ask and prevents expensive answers.
Telemetry before stakeholder applause: Define usage signals before shipping. If you do not know what success looks like in data before launch, you will not recognize failure until it is too late to course-correct.
Verification before autonomous loops: Tests, security checks, review gates, and sandboxing are now product infrastructure. Veracode’s finding that 45% of AI-generated code introduces security vulnerabilities is not an argument against AI coding. It is an argument for verification as a first-class investment.
Deletion as a core capability: If AI makes code cheap to create, teams need an explicit practice for removing code that did not earn its place. Most teams are bad at deletion. In the AI coding era, that weakness becomes expensive fast. The discipline of “write as little code as possible” includes removing code that should not exist.
The default organizational response will be to convert AI gains into backlog throughput, from more tickets closed to more prototypes shown to more features shipped. That is the trap. Unless leadership explicitly reallocates capacity to discovery, telemetry, verification, and deletion, AI does not create learning. It creates a larger surface area of untested assumptions.
The Sprint Review Becomes the New Brake
For Scrum teams, one existing mechanism is already designed for exactly this problem: the Sprint Review.
In the AI coding era, a Sprint Review without evidence from real use is not a review. It is a release celebration.
Consider two Sprint Reviews. In the first, the team demos three new features. Stakeholders applaud, and the Product Owner queues up three more. Nobody asks whether anyone used the features from the last Sprint. In the second, the team shows usage data from the previous Sprint’s release: one feature is getting traction, one is being ignored, and one is being used in a way nobody anticipated. The conversation shifts to what the data means for next Sprint’s priorities.
The first Sprint Review is a performance, a good example of agile theater. The second is a decision-making session.
If your Sprint Review looks like the first, it is not doing its job. It is one of the few built-in moments where judgment can slow output down long enough to turn evidence into decisions.
This cannot become the Product Owner’s private burden. If AI lets one developer generate five times more change, the whole team owns the consequences: engineers need to challenge vague prompts, designers need to test workflow fit before interface polish, Product Owners need to kill unvalidated backlog items (actually, those should not make it into the backlog in the first place), and stakeholders need to stop treating AI speed as permission to skip judgment. The brake is a system with a collective responsibility.
The pressure is also coming from above. Management and stakeholders are factoring in faster delivery times. Prototypes that took weeks now appear in hours. The expectation becomes: if AI can build it faster, why are we not shipping more? That pressure makes disciplined product thinking harder precisely when it matters most.
Conclusion: Generation Is Cheap, Judgment Is Scarce
“Generate” is not the same as “understand.” Speed is not the same as progress. Output is not the same as value. AI made generating code cheap enough that weak product judgment can now scale. That is the problem.
Instead, write as little code as possible. Just enough to solve the customer’s problem. To know how little that could be, you first need to understand the problem. The tool that writes the code has changed. The question of whether the code was worth writing has not been answered.
Are you using AI to increase your learning rate, or merely your output rate? I am curious.
Key Questions This Article on “Little Code” Answers
Why does AI-assisted coding make product discovery more important?
Agentic coding tools have collapsed the cost of generating plausible implementations. They have not collapsed the cost of knowing what is worth building. When implementation is cheap, building the wrong thing no longer carries the natural braking effect that expensive engineering once provided. Organizations that skip discovery now produce waste at the speed their AI tools can generate code. Discovery is what separates teams that create outcome from teams that create output.
What happens when teams use agentic coding without validating what they build?
The evidence shows three failure modes:
- Product failure: teams ship technically impressive features that users ignore because the product decision was wrong.
- Comprehension debt: developers merge AI-generated code they cannot explain, and the codebase grows faster than understanding.
- Security exposure: AI-generated code introduces vulnerabilities in nearly half of tests, and production incidents follow when verification infrastructure is absent.
In all three cases, the code worked. The judgment around it did not.
Where should teams invest the engineering time that AI coding tools save?
The saved hours should not become a larger product backlog. They should be reinvested upstream into discovery (observing user workflows before asking the agent to build), assumption testing (treating every feature idea as a hypothesis), and telemetry (defining usage signals before launch). Downstream, teams should invest in verification (tests, security checks, review gates) and deletion (an explicit practice for removing code that did not earn its place). The team that uses AI to produce more backlog items has missed the point.
How should Scrum teams adapt Sprint Reviews for AI-assisted development?
When a team can produce working software faster than ever, the need for the Sprint Review to shift from “look what we built” to “based on what we learned from actual users, what should we build next” becomes essential. (As it should have been before, too.) A Sprint Review without evidence from real use is a release celebration, not a decision-making session. Teams should show usage data from the previous Sprint’s release and use the conversation to decide priorities, not to applaud demos. The Sprint Review becomes one of the few built-in moments where judgment can slow output down long enough to turn evidence into decisions.
What is comprehension debt in AI-generated code?
Comprehension debt is a term coined by Jeremy Twei and discussed by Addy Osmani, a director at Google Cloud. It describes what happens when developers accept AI-generated code that passes tests without truly understanding how it works. The codebase grows while 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%. Code production scaled faster than the team’s ability to understand the consequences of each change.
“Little Code” — Related Articles
Ralph Wiggum Ships Code While You Sleep. Agile Asks: Should It?
Dear Micromanager: Your Distrust Has a Job; It’s Just Not the One You’re Doing
The AI Spending Trap: Why Adoption Outpaces Outcomes
Assist, Automate, Avoid: How Agile Practitioners Stay Irreplaceable with the A3 Framework
Stop Telling Professionals How to Do Their Job — Commander’s Intent at Work
Three AI Skills to Sharpen Judgment
No More Cheap Claude: Four First Principles of Token Economics in 2026
👆 Stefan Wolpers: The Scrum Anti-Patterns Guide (Amazon advertisement.)
📅 Training Classes, Workshops, and Events
Learn more about the micromanager with our AI and Scrum training classes, workshops, and events. You can secure your seat directly by following the corresponding link in the table below:
| Date | Class and Language | City | Price |
|---|---|---|---|
| 💯 🇬🇧 May 28 to June 25, 2026 | GUARANTEED: AI4Agile BootCamp #7 (English; Live Virtual Cohort) | Live Virtual Cohort | €499 incl. 19% VAT (If applicable.) |
| 🖥 💯 🇬🇧 June 8, 2026 | GUARANTEED: Claude Cowork: Stop Prompting. Start Delegating. (English; Self-paced Online Course) | Self-paced Online Course | $129 incl. 19% VAT (If applicable.) |
| 🖥 💯 🇬🇧 June 9, 2026 | GUARANTEED: HoA 74: “CLAUDE.md” — The One File That Makes AI Remember How You Work. (English) | Meetup | FREE |
| 💯 🇬🇧 June 10-July 2, 2026 | GUARANTEED: Claude Cowork BootCamp #2 (English; Live Virtual Cohort) | Live Virtual Cohort | $249 incl. 19% VAT (If applicable.) |
| 🖥 💯 🇬🇧 June 11, 2026 | GUARANTEED: HoA 75: Token Economics. (English) | Meetup | FREE |
| 🇩🇪 June 30 to July 1, 2026 | Professional Scrum Product Owner Training (PSPO I; German; Live Virtual Class) | Live Virtual Class | €1.299 incl. 19% VAT (If applicable.) |
| 🖥 💯 🇬🇧 July 15, 2026 | GUARANTEED: AI 4 Agile Course v3 — Master AI for Agile Practitioners (English; Self-paced Online Course) | Self-paced Online Course | $149 incl. 19% VAT (If applicable.) (Before: $249, incl. Update to v3.) |
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If your organization’s procurement process requires a different purchasing approach, please contact Berlin Product People GmbH directly.
✋ Do Not Miss Out and Learn More about Little Code — Join the 20,000-plus Strong ‘Hands-on Agile’ Slack Community
I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you would like to join all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
