The Waiting Game

Here’s what a typical day used to look like:

• Write a feature
• Open a PR
• Wait for review
• Get feedback
• Make changes
• Wait for re-review
• Wait for the backend team to finish their part
• Wait for QA
• Wait for deployment window

Now multiply that by every feature, every bug fix, every small improvement.

I think this workflow is dead. Not dying—dead. Once you’ve experienced building without it, going back feels like moving through mud.

What Changed

AI coding tools didn’t just make writing code faster. They collapsed the entire feedback loop.

When you can:

• Prototype a feature in an hour instead of a day
• Generate tests alongside the code
• Catch issues before they leave your machine
• Iterate through multiple approaches in a single session

…waiting two days for a PR review becomes psychologically unbearable.

The problem isn’t that reviews take time. The problem is the ratio. When writing code took 80% of the time and waiting took 20%, the waiting was tolerable. When writing takes 20% and waiting takes 80%, the process breaks.

The Dependency Trap

The waiting isn’t just for reviews. It’s structural.

Frontend waiting for backend. Mobile waiting for API. Feature teams waiting for platform teams. Everyone waiting for everyone else, synchronized through sprint ceremonies that exist to manage the waiting.

This made sense when building was slow. Coordination overhead was worth it because individual productivity was low. Better to coordinate carefully than to waste expensive engineering time.

But when a single engineer with AI tools can build the frontend, the backend, and the API in less time than the coordination meeting takes—the math changes.

The Boredom Problem

I’ll say what people are thinking but not saying: this is boring now.

Not the building. Building is more interesting than ever. The tools are incredible. The possibilities are expanding daily.

The process is boring. The waiting is boring. The ceremonies are boring. The overhead that used to feel like necessary friction now feels like theater.

When you spend a morning shipping three features solo, then spend an afternoon in meetings about why the team can’t ship one feature this sprint, something breaks in your motivation.

What Actually Gets Blocked

Let’s be specific about what the traditional workflow blocks:

Experimentation — Want to try a different approach? That’s another PR, another review cycle. By the time you get feedback, you’ve lost the thread.

Rapid iteration — User reports a bug. You fix it in 10 minutes. It ships in 3 days after the review and deployment process completes.

Learning — The fastest way to learn is to try things. Corporate workflow adds days of latency to every try.

Momentum — Context switching kills productivity. When you’re constantly stopping to wait, you never build momentum.

Joy — Building things is fun. Waiting for permission to build things is not.

The Solo Builder Advantage

Here’s what solo builders with AI tools experience:

• Have an idea at 9am
• Ship it to production by lunch
• Get user feedback by afternoon
• Iterate based on feedback before end of day

No reviews. No dependencies. No waiting.

This isn’t theoretical. This is what’s happening right now in startups, side projects, and any environment where the process hasn’t calcified.

The gap between this experience and corporate workflow isn’t incremental. It’s categorical.

Why Companies Keep the Process

To be fair, the corporate workflow exists for reasons:

Risk management — Reviews catch bugs before production. Multiple eyes reduce mistakes. Approval chains create accountability.

Knowledge sharing — Reviews spread context across the team. No single person becomes a bottleneck because others have seen the code.

Quality standards — Process enforces consistency. Without it, codebases diverge and technical debt accumulates faster.

Compliance — Regulated industries require audit trails, separation of duties, and documented approvals.

These reasons are real. The question is whether the cost is still worth it when the productivity delta has grown so large.

The Uncomfortable Middle

Most engineers are stuck in an uncomfortable middle:

• They’ve tasted what’s possible with AI tools
• They can’t fully use those capabilities at work
• The gap creates daily frustration
• They’re not ready to quit over it

This is where most of the industry sits right now. Aware that something is broken, unable to fix it, trying to find workarounds.

What Replaces It

The honest answer: we don’t know yet.

Some possibilities:

Async review with AI assistance — AI handles the mechanical review (style, bugs, security), humans review architecture and design. Faster for routine changes, thoughtful for important ones.

Trust-based deployment — Engineers who’ve demonstrated judgment get direct deploy access. Review happens after shipping, not before.

Smaller teams, less coordination — Instead of 10 engineers waiting on each other, 2 engineers who can each build the full stack independently.

Outcome-based accountability — Measure what shipped and whether it worked, not whether the process was followed. Hold people accountable for results, not ceremony compliance.

None of these are fully formed. The industry is figuring it out. But the current state—where process designed for 2015 productivity levels governs 2026 capabilities—can’t hold.

The Generational Split

Something worth noticing: this frustration isn’t evenly distributed.

Engineers who grew up with corporate process see it as normal friction. Annoying but expected. The water they swim in.

Engineers who started with AI tools—or who’ve gone deep with them recently—experience corporate workflow as actively painful. They know what’s possible. The gap is visceral.

This split is going to create pressure. Teams with mixed composition will have constant tension between “this is how we’ve always done it” and “this is unbearable now.”

FAQ

Key Takeaways