Website of Peter Westerman

Traditional software development is slow by design — not because code takes long to write, but because the coordination of multiple humans toward a shared technical goal is inherently expensive in time. Standups, backlog grooming, sprint planning, code review cycles, merge conflicts, QA handoffs, staging deployments, deployment approvals. Each step adds calendar time. Most of that time is not code-writing time; it is waiting time, coordination time, and context-switching time.

In a vibe coding practice with one human directing one AI, most of that coordination overhead disappears. The result is calendar compression that is more dramatic than almost any other change you can make to a software development process. Understanding why this compression happens, what its real limits are, and what it enables that would not otherwise be possible is the foundation for using vibe coding strategically rather than just tactically.

Why the Cycle Time Is Different

In traditional development, the bottleneck for any given feature is rarely the time to write the code. It is the time between code-writing steps: waiting for a developer to pick up the task, clarifying requirements that were not specified completely, waiting for a senior developer to review the implementation, resolving conflicts with work happening in parallel, getting a QA engineer to test it, fixing issues found in QA, waiting for deployment approval. Each of these is a coordination problem between humans with different schedules and competing priorities.

Remove the coordination overhead, and the natural pace of software production is much faster than traditional project timelines suggest. The AI starts immediately, builds without context-switching away to other tasks, does not require code review from someone who is also reviewing three other things, does not need deployment approval, and has no competing priorities. The bottleneck shifts entirely to human judgment — the quality of direction, the speed of evaluation, and the clarity of corrections.

This bottleneck shift has a practical implication: the fastest path to better output is not a faster AI. It is better human judgment applied at the direction stage. An AI given better direction produces better output than the same AI given worse direction. The AI’s raw capability is fixed at the moment of the session; the quality of the session is determined by the quality of the human inputs.

What a Productive Day Looks Like

A productive day with a complex product might include three or four distinct build sessions. Morning: one objective identified, a brief written, session opened, build completed in 30–45 minutes, tested against the specific scenarios the feature is supposed to support, issues described specifically, corrections made in the same session. Midday: a second objective, same approach. Afternoon: a third feature or a focused debugging session on issues found during afternoon testing. Evening: end-to-end walkthrough of everything built that day testing the full user scenarios, notes for the next day’s sessions.

At the end of a day structured this way, two to four working features have been built and tested. In a traditional development process, equivalent output would represent one to two weeks of sprint progress. The compression is real and it is that dramatic — not occasionally but consistently, as long as the session quality is maintained.

What determines session quality: the specificity of the objective, the accuracy of the context file, the completeness of constraints stated in the brief, and the thoroughness of testing between sessions. Any one of these failing degrades the cycle. All four working well produces the kind of output rate described above.

Testing as a Velocity Investment, Not a Constraint

The most counterintuitive lesson about vibe coding velocity: testing between sessions is not a constraint on speed. It is what enables sustained speed. The professionals who skip testing in the rush to build the next feature are optimizing for the next two hours at the cost of the next two days.

When you test immediately after building, bugs are caught at the point of maximum context — you know exactly what was just built, what it was supposed to do, and how it connects to adjacent components. Fixes at this point are fast and targeted. When you skip testing across several sessions and then encounter a bug, you are working with cold context: which session introduced it, which components might be affected, what the intended behavior was. The reconstruction overhead often exceeds what the skipped testing would have taken.

The compounding effect is even more important: bugs not caught in session N are often still present in sessions N+1, N+2, N+3. Features built in those sessions may depend on the broken behavior in session N. By the time the bug is discovered, fixing it may require revising not just the broken component but the features built on top of it. Catching a bug at session N costs one fix. Catching the same bug at session N+5 costs one fix plus up to five corrections to dependent work.

The rule that held across the full portfolio: nothing new gets built until the last thing built has been tested against the primary user scenarios it is supposed to support. Twenty minutes per session, non-negotiable. This single discipline, applied consistently from the beginning of a practice, produces a codebase with substantially less accumulated technical debt than the same practice without it.

The Documentation Session as Velocity Infrastructure

One discipline that took too long to establish: ending every build session with a context file update. Five minutes to capture what was built, what architectural decisions were made, what constraints were added or modified. This is not documentation for its own sake. It is the input that makes the next session start productively rather than from a reconstruction.

Sessions that start from a current, accurate context file produce better first-pass output than sessions that start from a stale one. The AI working from accurate context about the system’s current state makes correct assumptions rather than plausible-but-wrong ones. The difference is most visible in complex products where multiple components interact — the AI that understands the current state of those interactions produces implementations that fit together; the AI working from outdated context produces implementations that have to be corrected for incompatibilities that would not have existed if the context had been current.

Five minutes at the end of each session. Fifteen to twenty minutes saved at the start of the next. Net recovery per session: ten to fifteen minutes, plus the quality improvement from better context accuracy. Over a hundred sessions on a given product, that compounds into a substantial difference in both time and output quality.

The Learning Rate Benefit

The most important consequence of compressed iteration is not that more gets built in the same time. It is that learning happens faster. Every iteration cycle is an opportunity to observe, evaluate, and improve the methodology. More cycles mean more learning opportunities. The methodology that produced the first product was significantly weaker than the methodology that produced the twentieth — not because the AI improved dramatically between those products, but because the human direction improved substantially through the practice of iteration across nineteen previous products.

By the end of twelve months, requirements documents were more complete, architecture conversations were more productive, testing was more thorough, context files were more accurate, and the feedback loop between what was built and what was needed was tighter. That methodology improvement, not AI capability improvement, is the primary driver of the trajectory from three to five weeks per product to three to five days per product over the year.

The same learning-rate benefit applies to any knowledge work domain where AI collaboration is used systematically. Each session is an opportunity to improve the context file, the template, the specialist profile. Each project produces learning about what works and what doesn’t in your specific domain. The professionals who apply this systematically — treating each session as an iteration not just on the task but on the methodology — will have a compounding advantage over those who treat each session as independent.

The Parallel Track Approach

A pattern that emerged around the sixth product: running parallel development tracks. While one product was in testing — which requires real-time use rather than active direction — the requirements document for the next product can be written. While the AI is building a complex back-end component, the requirements for the front-end component that will follow can be developed. While waiting for a deployment to complete, context files can be updated.

This works well when the parallel tracks are genuinely independent. A requirements document for a new product does not depend on what is currently being built in the current product. Updating the Coding Playbook does not conflict with active building. The parallel tracks create useful overlap that keeps the human’s time fully utilized without creating the coordination complexity of dependent parallel work.

The failure mode to avoid: running parallel implementation tracks where the tracks are architecturally dependent. If Feature A’s design depends on a decision still being made in Feature B’s implementation, building both in parallel creates a risk that A will need to be rebuilt when B’s decision is resolved differently than assumed. The rule: parallel tracks are safe for work that is genuinely independent. Any dependency between parallel tracks needs to be resolved explicitly before the dependent track starts building.

What Realistic Speed Expectations Look Like

To calibrate expectations appropriately: the speeds described in this post — multiple features per day, complex products in days rather than weeks — represent the mature practice after twelve months of methodology development, with full context infrastructure in place, using the Shared Library for standard components. They are not the speeds of a new vibe coding practice in its first month.

In the first month, expect two to three times slower than the mature practice for equivalent work. Context files are sparse, requiring more re-establishment overhead. Architectural patterns are not yet established, requiring more design conversations. Testing discipline is developing, requiring more correction cycles for bugs that would be caught earlier in a mature practice. The first month is the slowest month. The trajectory from that starting point to the mature pace is measured in months, not years — but the investment in reaching it has to be made.

The practical implication for setting client and stakeholder expectations: add appropriate buffer to timeline commitments made early in a vibe coding practice. The buffer should decrease as the practice matures and the trajectory of improvement becomes predictable. Within six months of consistent practice, the velocity improvements should be substantial enough to justify the kind of aggressive timelines described in this post. Before that point, conservatism in commitments is appropriate.

How Recent AI Innovations Change This Picture

The iteration engine described in this post — multiple complete build-test-evaluate cycles per day — was the core productivity mechanism of the methodology. Recent AI innovations affect both the speed of each cycle and the quality of output at each stage.

Background tasks in the Claude Agent SDK address the waiting problem directly. In the methodology described here, human time during build cycles was frequently idle: waiting for the AI to complete a complex multi-file change, waiting for a test environment to start, waiting for a dependency installation to finish. Background tasks allow these operations to run without blocking the session. The practical effect is a higher density of productive iteration within the same calendar time — fewer gaps, more cycles.

Checkpoints change the risk profile of ambitious iterations. The methodology already included a discipline of keeping builds small and testing frequently to minimize the cost of discovering that a direction was wrong. Checkpoints formalize this: a checkpoint before a risky architectural change means the recovery cost of a wrong direction is known and bounded. This changes how aggressively you can iterate on uncertain design decisions, because the downside of being wrong is bounded by the checkpoint rather than by how much code you have to manually undo.

Extended thinking changes the quality of first-draft output on complex features, which changes the iteration count required to reach production quality. In the methodology described here, complex features typically required more iterations to converge than simpler ones — not because the AI made more mistakes, but because the reasoning required to produce the right architecture was more extensive. Extended thinking applies that reasoning before generating code. Fewer course corrections needed on the first draft means fewer iteration cycles to production quality, which means the engine runs faster on hard problems as well as easy ones.