Vibe coding and accidental architecture
Because AI writes code instantly from simple prompts, developers skip intentional design. Business logic leaks into infrastructure, creating accidental architecture and context amnesia.
AI + Engineering
Your engineers got faster. Your best engineers became reviewers.
You rolled out AI coding tools and output went up: more PRs, more features, more activity on every dashboard. Then the pipeline got slower. Review queues ballooned, and the people you hired to design architecture are spending their week validating code they didn't write. The bottleneck didn't disappear. It moved to your scarcest resource: human judgment.
You're Not Imagining It
AI made building nearly free. Everything after building didn't get any cheaper.
This isn't a discipline problem on your team, and you aren't the only one seeing it. LinearB looked at 8.1 million pull requests across roughly 4,800 engineering teams and found that AI-generated code waits about 4.6 times longer for review than code a person wrote by hand. DORA's 2025 State of AI-assisted Software Development report shows the same tension from a different angle: AI adoption is now correlated with higher delivery throughput, but it pushes delivery instability up at the same time, because AI amplifies whatever was already true of a team's engineering discipline, the strong parts and the fragile parts alike. Agoda's own engineers reached the same conclusion by living it: coding was never the bottleneck. It was just slow enough before that nobody noticed it wasn't.
AI didn't create new value. It created new speed. And speed pointed at the wrong constraint just produces more theater, faster.
Where Most Teams Go Next
More review tooling doesn't fix this. It adds another layer at the wrong altitude.
Here's where most teams go next: they buy more tooling for the review stage, an AI reviewer, another quality gate, another dashboard. It feels like the obvious move. It doesn't work, because you're stacking a new probabilistic layer onto a pipeline that was never gated properly to begin with, at exactly the altitude where the constraint doesn't sit.
The real constraint is human judgment and decision capacity, and that doesn't scale by adding tools. It scales by changing what your scarce judgment gets spent on, and what you actually inspect before it ships, often by shifting review upstream to the specification instead of the generated diff. That's not an engineering-process tweak. It's an operating-model decision, and until someone makes it on purpose, the default answer is whatever queue happens to be loudest that week.
Is This For You?
When your best people are reviewing more than they're designing.
This tends to fit VPs of Engineering, CTOs, and product leaders who have deployed tools like GitHub Copilot or Cursor and are noticing that local speed gains have not changed delivery.
The time is right for this reset when:
- Faster coding has not changed delivery: Engineering reports that coding is faster, but time-to-market, launch readiness, or deployment flow has not changed.
- Code review queues are backing up: Pull requests sit open for days, code review latency is rising, and developers are rubber-stamping approvals just to keep things moving.
- Product managers cannot keep pace: Upstream discovery is starved. Product managers are rushed to feed the developers, producing vague requirements that lead to rework.
It Doesn't Stop At The PR Queue
The PR queue is where you feel it first. It isn't where it ends.
The review backlog is just where this shows up first, because it's visible and it's yours. One altitude up, the identical pattern is already forming as the question your sponsor is quietly asking: "We shipped a ton. What actually improved?" More initiatives in flight, more releases, and less clarity about which ones moved the number that matters. That's acceleration whiplash again, this time measured at the portfolio level instead of the pull-request level: activity outrunning the organization's capacity to decide what any of it was worth.
If you only unclog the review queue, you've built a faster factory. The harder, more valuable work is turning that speed into value end to end, connecting the code your engineers ship to the outcome your sponsor can actually see.
The Resistance Risk
You can mandate tool usage. You cannot mandate adoption.
The biggest risk in AI tool adoption often is not the model. It is whether the people doing the work see a reason to use it. When leadership mandates tool rollouts from the top down, teams push back. They check the compliance box, use the tool to generate some noise, but their daily work stays the same.
I help you start with the work developers actually experience. If teams are resisting a new AI tool or workflow, it is often because the change has not solved their daily friction.
We start with people close to the problem, find where the work is stuck, and invite them to shape the AI changes. Their friction becomes useful information, not resistance to overcome.
What I Actually Do
Build the operating system that turns AI speed into value you can point to.
- 01
Find where your speed is actually going
Not developer activity metrics. Where the AI-driven speed you already paid for is piling up as risk, rework, and review debt instead of shipped value.
- 02
Decide what your judgment should govern
Choose what your scarce human judgment actually needs to inspect, and build that governance into the flow of the work itself, not into a deck nobody opens again.
- 03
Connect velocity to the outcome your sponsor can see
Link engineering throughput to the result leadership cares about, so "we shipped a lot" turns into "here is what it was worth."
What to Expect
A scoped diagnostic first, not a blind commitment.
- 01
Start with a scoped diagnostic
Two to four weeks. We look at the signals you already have: lead time, review wait, escaped defects, deployment patterns, and developer feedback, and build a clear map of where your AI-driven speed is actually going.
- 02
Map how work really moves
We work with product, tech leads, and QA to map how work moves from idea to production, then find the place that is now doing the waiting.
- 03
Change a few working rules
We change a few working rules with the team: smaller reviews, clearer readiness for specs, and automated checks before human review.
- 04
Set the 90-to-180-day path
You leave with a concrete plan to turn that speed into throughput and value your leadership can see, scoped to 90-180 days, not a blind multi-year transformation.
Sound Familiar?
Friction points that stall AI value.
PR queues back up
Teams write code faster, but the review queue is stuck. Reviewing massive AI-generated code diffs is exhausting, leading to rubber-stamping or stalled releases.
The 90-day wall of technical debt
AI speed creates a massive payday loan of cognitive and technical debt. Demos look impressive in week two, but the codebase decays and hits an unmaintainable wall around day ninety.
Developers do not trust the rollout
You bought expensive copilot licenses, but adoption is patchy. Developers use it as an autocomplete but resist changes to their core workflows because they feel top-down mandates ignore their actual day-to-day pain.
In Practice
The moves that make this stick once the diagnostic is done
AI value shows up when delivery changes, not just coding speed
They are managing the work around coding differently. After 20 years working with organizations on product, portfolio, and developer-flow problems, these are the moves I would look for.
- 01
They look at the whole path to production
They do not stare at developer activity metrics. They look at how long work takes from request to production and where it waits.
- 02
They shift reviews upstream
Instead of reviewing massive, thousand-line AI-generated code diffs, engineering leads review the Markdown specification (intent) before code is generated.
- 03
They keep reviews small
They replace large, multi-day pull requests with smaller reviews. Review speed becomes a team concern, not an individual favor.
- 04
They manage design intent hollowing
They establish explicit architectural guardrails and lints so AI agents cannot bypass standard system design, keeping code maintainable.
- 05
They slow down code generation when another queue is full
If testing, release, review, or product discovery is full, generating more code only creates inventory and rework.
- 06
They improve the workflow with developers
Instead of pushing tools, they involve developers in finding what slows the work down. Adoption is easier when the change removes daily frustration.
Questions I Get
Questions leaders ask when developer speed doesn't produce delivery flow
Why is faster coding not making delivery faster? +
Because coding is only one step. If AI makes coding faster, but product discovery is slow or code reviews are stuck, delivery does not change much. You've just moved the bottleneck. To understand how to fix this, read If AI Coding Made Engineering Faster, Why Isn't The Business Faster?.
What is a diagnostic, and how is it different from committing to a transformation? +
You do not need to sign up for a multi-quarter transformation to find out where your bottleneck actually is. A diagnostic is two to four weeks: I map where your AI-driven speed is going and where it is turning into risk, rework, or review debt, and we leave with a 90-180 day path to turn it into throughput and value your leadership can see. Whether we keep working together after that is a separate decision.
Does this only fix the code review bottleneck? +
No. The review queue is usually where the bottleneck becomes visible first, but the same pattern tends to show up one level up as "we shipped a lot, so what actually improved?" Unclogging the review queue on its own just builds a faster factory. The harder, more valuable work is connecting engineering speed to the outcome your sponsor can see, end to end.
How do we fix the code review / PR queue bottleneck? +
Treat reviews as team work, not an interruption. Make pull requests smaller, automate the checks a machine can handle, and agree on how quickly reviews should happen.
What is Spec-Driven Development (SDD) and how does it help? +
Spec-Driven Development (SDD) is a governance framework for AI-assisted coding. Instead of writing code directly via natural language prompts (vibe coding), developers write and review detailed Markdown specifications first. The AI is then restricted to generating code that complies with that spec. This shifts reviews upstream and prevents "accidental architecture" and "design intent hollowing" (where AI-generated code lacks human design rationale).
What is the "90-day wall" of vibe coding? +
Vibe coding is great for building rapid prototypes. However, because LLMs generate code locally without understanding global architecture, they introduce severe context amnesia and duplicated logic. Around the 90-day mark, this technical and cognitive debt accumulates to a point where the codebase becomes unmaintainable, slowing future development to a crawl.
How do we address developer resistance to new AI tools? +
Do not start with a mandate. If developers resist the tool, ask what it is making harder or failing to help with. Slow CI, noisy PR notifications, review delays, and vague specs may matter more than another AI feature.
Is this about replacing developers or reducing team size? +
No. This is about flow, not headcount. If your team is stuck in acceleration whiplash, people may be working harder and writing more code while shipping less value. The useful move is to remove the bottlenecks that make good work wait, churn, or come back as rework.
How is this different from traditional Agile or DevOps consulting? +
Traditional consulting often focuses on team rituals or CI/CD tooling. Those still matter, but AI-assisted development changes the pressure points. Code generation gets cheaper, so the slow spot often moves to discovery, review, testing, release, or adoption.
What does working together actually look like? +
It starts with a two-to-four-week diagnostic, then 6-10 weeks of looking at the work, mapping the waiting points, and changing a few working rules with product and engineering leads. From there, support can continue while the team tests the changes and decides what to keep.
Start With The Diagnostic
Find out where your bottleneck actually is
You don't need to sign up for a transformation to find out what's actually stuck. Bring your current engineering situation: what tools you've deployed, where your queues are backing up, and what still feels stuck. I'll help you build a clear map of where your AI-driven speed is going and a 90-180 day path to turn it into throughput and value your leadership can see.