4 Writing Lean code

This chapter argues that lean coding is not about writing the fewest possible lines, but about preventing waste before it enters the system. The central idea is to make intent explicit early, constrain solutions so they do not expand beyond the need, and judge code by how easy it is to understand, change, or delete. In an AI-heavy workflow, that discipline matters even more because vague requests can quickly produce plausible but excessive solutions. The chapter frames coding as a judgment practice: define what is needed, set boundaries, and reject anything that cannot justify its place.

A major theme is the evolution of the “source of truth” in software. Early waterfall-style work treated code as the truth, which delayed feedback and encouraged overproduction. TDD improved that by letting tests define correctness first, BDD expanded the idea so business stakeholders could read the behavior, and interface-first and design-driven approaches tried to reduce coupling and ambiguity. The chapter then extends this logic to spec-driven development, where explicit specifications become the authority before code is written. A good spec acts like a pull signal: it clarifies what must happen, what must never happen, and what constraints matter, while preventing AI from inventing unnecessary architecture.

The other big lesson is to design for deletion and manage dependencies deliberately. Code is treated as inventory with carrying costs, so the right question is not how to make something permanent, but how to make it easy to remove when it stops adding value. That same mindset applies to external libraries and AI-generated code, both of which increase surface area, maintenance burden, and hidden risk. Standard work is presented as the safeguard: document team patterns for errors, logging, validation, structure, and reviews so that both humans and AI generate consistent code. Code review then becomes a Lean quality gate, focused on spec compliance, waste elimination, and reversibility rather than taste or personal preference.

A classic, sequential, waterfall way where authority ultimately resides in the code, often revealing defects and overproduction only after significant investment.

A TDD loop where tests become the source of truth and code is written to satisfy those predefined expectations.

AI-driven development expands the technical implementation surface area to produce reasonable looking solutions.

Comparison of how deletion can be approached as a design decision.

Importing an entire library with multiple capabilities to service one business need.

Without defined standards, each AI-generated feature adopts different patterns, creating a maintenance burden and technical debt.

Using our standard work as a guide for PR reviews.

• Flow protection starts before code is written: Specs stop building the wrong thing. Standard work stops pattern fragmentation. Reviews stop non-compliance. Each is an Andon cord that catches defects before they compound.
• Specs constrain AI from plausibility to necessity: Write what must be true before generating what makes it true. Include "Never" statements. A 30-second spec prevents overproduction. Specs improve through iteration.
• Code and dependencies are inventory: Every line costs maintenance and creates security exposure. Design for deletion: isolated, explicit dependencies, easy to disable. Dependencies multiply surface area. You wanted one function, you got 50 validators and transitive CVEs. Inline if under 20 lines.
• Dependencies are surface areas you own forever: You wanted one function, you got 50 validators and 3 transitive packages. You don't choose transitive dependencies, but you own their CVEs. Evaluate through value lenses: does the user notice? Does business value erode from maintenance? What's the hidden technical cost? Inline if under 20 lines. Use specs to force AI justification: "Dependencies: NONE unless justified.
• AI is a dependency with a cognitive attack surface: Non-deterministic outputs fragment patterns. One casual suggestion created all 8 TIMWOODS waste types. Constrain with specs and standards.
• Standard work creates determinism: Document the current best way. Code review is Gemba, observe reality. Improve standards when patterns emerge. Standards aren't rules; they're an ongoing conversation.
• Reviews protect flow at the gate:** Review against standards, waste, and value. Spec compliance blocks merges. Standards violations block merges. Overproduction blocks merges. Style preferences suggest only. Objective criteria, not debates. Stopping a PR is cheap. Fixing it in production is expensive.
• Knowing what NOT to build matters more than knowing how: AI makes adding code trivial. Your job: prevent unnecessary code from ever being written.

FAQ