AI makes implementation cheaper; it makes evidence and judgment more valuable. AI has changed the cost of producing software, but the cost of being wrong remains just as high. Cheap software means that many teams are responding to AI by making the unit of implementation larger: write a substantial specification, run an intensive coding session, generate an entire milestone, and test the result afterward. When this works, it feels extraordinary. A large amount of code appears in a short time. But faster code generation is not the same as faster product development. The central question is rarely only, “Can we build this?” It is also, “Should we build this, does it work in the real workflow, and what do we need to learn next?” AI accelerates the first question, but the others. This article explains how to build faster with AI without going in the wrong direction, using the methodology that helped me ship more features in a few months at an applied AI startup than I did in a year in big tech. The Decision Rule The first step is to use the size of the batch to match the uncertainty in the work. A broad, AI-assisted implementation batch is appropriate when the desired result is stable and easy to verify. For instance, when doing a bounded migration, or a disposable prototype. In this type of work, there is little product uncertainty left to resolve, so AI is able to handle this autonomously. Use small, end-to-end slices when uncertainty is material, whether that be within a product, workflow, or integration. The purpose of the slice is to make the cost of being wrong small. It should produce a meaningful user outcome and evidence about the next decision. The Two Models The one-shot milestone model is a large-batch process: specification, implementation, then validation. Its advantage is throughput. Its weakness is that it batches uncertainty along with code. If the specification is incomplete, the workflow does not match reality, or an integration behaves differently in production, the team discovers the problem after creating the largest possible amount of work. Testing at the end may prove that the system conforms to the specification. It cannot prove that the specification was the right answer. Implementation also creates new information. Constraints, edge cases, integration behavior, and real workflow details often reveal that part of the proposed solution is wrong or incomplete. In a large-batch model, that learning arrives after the team has committed to the specification and built around it. The team then faces an unfavourable choice: follow a specification it now knows is weak, change the code without updating the decision, or reopen a large milestone late. When that difference is left unresolved, the specification becomes decision debt: a growing gap between what was approved, what was built, and what the team now knows to be true. The alternative is progressive end-to-end delivery. It follows Henrik Kniberg’s skateboard model: rather than deliver the components of an eventual product one by one, deliver the smallest complete version of the underlying user outcome, then improve it through real feedback. Kniberg’s model is more precise than “build an MVP”: the first release may be an earliest testable product, later becoming usable and eventually lovable. Reference: Henrik Kniberg, Making Sense of MVP In software, each increment should be a vertical slice: a narrow path through the interface, system logic, data, integrations, and operations that produces a real result for a user. Each slice gives the team a small, cheap opportunity to update the proposed solution and its acceptance checks before the next commitment. The intended user outcome and non-negotiable constraints should change only through an explicit product decision. The aim is not to ship less code. It is to learn early enough to change course before a large milestone turns incorrect assumptions into expensive rework. What AI Changes The core argument is not new. Small batches, vertical slices, and rapid feedback were valuable before AI. What AI changes is the cost of implementation. AI creates an opportunity: it lowers the cost of building a complete slice. One person can more readily work across the interface, backend, integrations, tests, documentation, and operations. This makes genuine end-to-end delivery more practical and weakens the old organizational reason to divide work into horizontal specialist tickets. AI also creates a danger: it lowers the cost of building a large batch before anyone has learned from it. A team can now spread a flawed assumption across an entire milestone in days rather than weeks. Unless it creates explicit feedback points, it can complete far more unvalidated work before discovering whether the product, workflow, or system design is right. Vertical slicing captures the opportunity while limiting the danger. Each slice is small enough to put a real workflow in front of users, operators, and integration te