# FOMO-Driven Development > Source: > Published: 2026-07-07 18:14:28+00:00 Back in 2022, GitHub ran a controlled [experiment](https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/) and found that developers using Copilot finished a scoped JavaScript task 55% faster than a control group. Three years later, METR ran a randomized [trial](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) with sixteen experienced open-source maintainers, working across 246 real tasks in their own repositories, and found that AI tools made them 19% slower. The maintainers predicted a speedup going in. After it ended, they still estimated the tools had sped them up. Neither study is broken. They measured different situations, and the distance between those situations is where a lot of engineering organizations are quietly losing money right now. I work in data infrastructure, close enough to both the vendor pitches and the postmortems to have watched the same adoption pattern repeat for the past two years: - A team sees a genuinely impressive demo. - Leadership feels the market moving underneath them. - Seats get bought, an agent gets wired into the repo, and the rollout ships before anyone decides how the output will be tested, reviewed, traced, or paid for. I've started calling this FOMO-driven development. Its defining feature is that the adoption decision comes from fear of being left behind rather than from a constraint anyone can name. The demos are definitely real; the extrapolation from them is where the damage happens. ## The gap between 55% faster and 19% slower GitHub's number came from a bounded, well-specified task: build an HTTP server in JavaScript, greenfield, clear finish line. Their later enterprise [study](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-in-the-enterprise-with-accenture/) with Accenture pointed the same direction inside large organizations, with more pull requests, higher merge rates, and greener builds. METR's developers were doing the opposite kind of work: maintenance in mature codebases they knew intimately, against quality bars they personally enforce. In that setting they accepted fewer than 44% of AI generations and spent roughly 9% of their working time reviewing and cleaning model output. The tools produced plenty of code, but the developers paid for it in verification. That's the variable separating the studies: who absorbs the cost of checking. On a greenfield task with a spec, checking is cheap, so generation speed dominates. In a fifteen-year-old codebase full of implicit invariants, checking is most of the job, and a tool that produces plausible-but-wrong diffs is a tax dressed up as an intern. ## The bottleneck moved and the budget didn't Conversely, DORA's 2025 [research](https://dora.dev/research/2025/dora-report/) describes AI as an amplifier: teams with strong platforms and practices get faster, while teams without them ship more change and more instability at the same time. GitLab's survey data puts numbers on the mechanism: 85% of organizations say their constraint has shifted from writing code to reviewing and validating it, and 82% treat AI-generated code as a new category of technical debt. Read together, the pattern stops looking mysterious. Generation got cheap, so volume went up. Review capacity stayed flat, so the queue moved from the IDE to the pull request column. If review was already your constraint, speeding up generation made the whole system slower. That's really just ordinary queuing theory, and it has nothing to do with how good the model is. FOMO-driven adoption funds the visible half of the system and defers the invisible half. Seats, agents, and IDE plugins are line items with logos attached. Test coverage, eval harnesses, review headcount, provenance tracking, and token budgets are chores, so they get a promise instead of a budget. Most of the failure stories I hear trace back to that deferral, not to the model writing a bad function. ## Benchmarks age like demos Cognition launched Devin in March 2024 with 13.86% on a random quarter of SWE-bench, and for a few weeks that number was everywhere, including in budget meetings(!). Then the benchmark's authors and OpenAI shipped SWE-bench Verified, because a chunk of the original tasks turned out to be broken or underspecified. Then the academic group behind SWE-agent retired their own elaborate scaffold in favor of mini-SWE-agent, about a hundred lines of Python, which clears 74% on Verified. SWE-Bench Pro exists because everyone eventually worried about contamination, and newer evaluation work argues that resolving tickets was never the right unit of measurement for real development anyway. If you couldn't follow that, don't worry. This is a young evaluation ecosystem correcting itself in public, which is healthy, but pegging procurement to it is the mistake. A leaderboard position has a shelf life measured in months or even weeks, and a hundred-line agent outscoring last year's most famous product should permanently lower everyone's confidence that scaffold complexity or launch-day numbers predict anything durable. ## The debt came back with new names The costs that FOMO defers do eventually send an invoice, and 2024 through 2026 has read like one long itemized receipt. **Provenance debt**: GitHub built code referencing specifically to flag Copilot suggestions that match public code, because "where did this function come from" turned out to be a question legal departments ask. **Security debt**: OWASP now maintains a [Top 10](https://owasp.org/www-project-top-10-for-large-language-model-applications/) just for LLM applications, and NIST extended its secure development framework for generative AI. The concrete version: one study measured average package-hallucination rates around 5.2% for commercial models and 21.7% for open source ones. Attackers noticed that models invent plausible package names, registered those names on public registries, and gave the industry slopsquatting, a supply-chain attack class that did not exist before autocomplete got ambitious. **Verification debt at ecosystem scale**: Stack Overflow banned AI-generated answers back in 2022 for a reason that generalizes to every codebase. The tools made producing answers cheap while verifying them stayed expensive, and the platform's economics run on verification. When the deferral happens inside a product instead of a process, it happens in public. Microsoft announced [Recall](https://en.wikipedia.org/wiki/Windows_Recall), pulled it after the security community dismantled the threat model, and spent ten months rebuilding it around encryption, enclaves, and opt-in defaults before general availability. Builder.ai rode the AI label to a multibillion-dollar valuation, restated its revenue, and entered insolvency last year. ## The invisible half None of this is new territory. The [hidden-technical-debt paper](https://proceedings.neurips.cc/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html) warned back in 2015 that the model is the smallest box in the diagram of a production ML system, and the data-centric AI crowd has spent years arguing that improving your data and your evaluations beats chasing the model of the month. FOMO-driven development is what happens when an organization hears "AI coding tools" and buys the box instead of the diagram. The economics are starting to enforce the lesson on their own. GitHub moved Copilot to usage-based billing in June, which attaches a per-token cost curve to your SDLC, and Gartner projects that AI coding spend can exceed an average developer's salary within a couple of years if consumption keeps compounding. The durable lock-in turns out to be the metered workflow, the telemetry, and the org-shaped dependency you build around a vendor's agent loop, none of which appears in the demo. ## Adoption without the FOMO Nothing here argues for sitting out. The Copilot gains are real, METR's authors themselves caution against generalizing beyond experienced maintainers on mature repos, and I use these tools daily with results I wouldn't give back. The argument is about sequencing. The non-FOMO version is unglamorous: name the constraint first, and if it's review latency or change failure rate, check whether generation speed even touches it. Measure at the system level, lead time and failure rate and review queue depth, instead of trusting IDE acceptance stats. Build a small eval set from your own repositories before the pilot, because public benchmarks measure SWE-bench and your codebase is not SWE-bench, then rerun it after every model or prompt change. Treat generated code as untrusted input in CI, the way you already treat user input in production, with provenance recorded at commit time. Give review capacity actual headcount. Put alerts on token spend the way you put them on cloud spend. And keep a rollback path, because the vendor's pricing, models, and agent architecture will all change underneath you within a year, and every case above suggests the switching moment arrives earlier than planned. Stated so it can be wrong: a team that adopts AI code generation without expanding review and evaluation capacity will see its change failure rate climb within two quarters, regardless of what happens to generation velocity. If your team scaled agents without hitting that trade, I want the specifics: repo age, review process, eval setup, and what the failure rate actually did. Counterexamples are worth more than the thesis. ## About the author Dani is a data professional with a rich background in data engineering and real-time data platforms. At Estuary, Daniel focuses on promoting cutting-edge streaming solutions, helping to bridge the gap between technical innovation and developer adoption. With deep expertise in cloud-native and streaming technologies, Dani has successfully supported startups and enterprises in building robust data solutions.