The AI development paradox: why greenfield coding speeds up 55% while mature codebases slow down 19%

• Slowdown in mature code (METR, 246 tasks): +19% time per task for developers with an average of 5 years' experience working in the repository
• Self-assessment error (calibration blindness): a gap of nearly 40 percentage points between the felt acceleration (-20%) and the actual slowdown (+19%)
• Acceleration on a clean slate (Microsoft/GitHub): -55.8% time (71.2 vs. 160.9 min) on a typical HTTP server built from scratch
• Hidden growth of the dependency tree and hallucinations: 14 direct dependencies expand into 492 packages (and up to 1,442 on a web project)

At some conferences you'll see slides touting a twofold increase in speed with AI assistants, while at others you'll hear reports that neural networks slow down senior engineers. The paradox is that both claims rest on rigorous randomized controlled trials (RCTs) with second-by-second timing, and both are true.

In the experiment by Peng and colleagues from Microsoft Research, GitHub, and MIT Sloan (`arXiv:2302.06590`), 95 developers were given the task of writing an HTTP server in JavaScript from scratch against prepared automated tests. With AI autocomplete, participants finished in **71.

2 minutes versus 160.9 minutes for the control group — 55.8% faster**.

Then, in July 2025, a team from METR (`arXiv:2507.09089`) ran a mirror-image RCT with 16 experienced maintainers and 246 real production tasks in their own mature repositories (averaging 1.1 million lines of code, 10 years of project history, and 5 years of personal experience per participant — roughly 1,500 commits).

With AI tools, developers spent 19% more time on each task, and 75% of participants ended up worse off.

Why did experienced developers misjudge their own speed by almost 40

percentage points?

The most alarming figure in the METR report isn't the +19% time increase itself — it's the collapse of human calibration. Before the study began, outside experts (34 economists and 54 ML researchers) predicted a speedup of 38–39%, and the developers themselves predicted 24%. But after finishing all 246 tasks and logging their timings, participants were genuinely convinced that AI had saved them about 20% of their time.

Perception and the stopwatch diverged by 39 percentage points (even though task-duration forecasting calibration was normal, at 0.64 and 0.59). AI distorts the perception of effort: sitting back as a reviewer and watching text scroll by feels psychologically easier than personally fighting through legacy code. The management takeaway: any report on the "effect of AI adoption" built on employee surveys is measuring dopamine, not productivity.

Where does the "jagged frontier" of model capability fall between

novices and experts?

Combining the METR and Microsoft data with Harvard's research on 758 BCG consultants (`Navigating the Jagged Technological Frontier`, 2026) and Brynjolfsson's QJE study of 5,172 support agents produces a coherent picture:

1. The novelty-of-context effect: in customer support, AI delivered an average gain of +15%, but novices saw gains of +30–36%, while veterans saw essentially zero improvement. On a clean slate, every one of us is a novice, which is why we get a -55% time reduction there. In a five-year-old repository, the main challenge is preserving the unwritten architectural invariants that never made it into the model's weights. 2. The persuasiveness trap: inside the model's capability frontier, consultants using AI completed 12.2% more tasks and did so 25.1% faster. But beyond that frontier, the share of correct solutions fell from 84.5% to 60–70.6%, even as outside judges rated the persuasiveness of these flawed outputs 17.9–25.1% higher.

To avoid falling into that +19% trap, I follow four rules: never delegate understanding (specify the exact file, line, reason, and acceptance criteria in the task), use `PreToolUse` hooks to block only 25 irreversible commands out of 424 allowed ones (unwrapping `ssh`, `python -c`, and `base64` wrappers in the process), keep 93 KB of modular architecture rules on disk, and separate delegation into `Level 0–3` tiers.

How do 14 declared packages turn into 492, and what makes

slopsquatting dangerous?

According to USENIX Security 2025 (`arXiv:2406.10279`), based on 576,000 code snippets, models invent nonexistent library names in 5.2% of cases for commercial LLMs and 21.7% for open-source ones (205,474 unique phantom names), which attackers exploit through slopsquatting. You can check your project's actual dependency tree in a second:

```python import json, sys

lock = json.load(open(sys.argv[1], encoding="utf-8")) root = lock["packages"][""] direct = len(root.get("dependencies", {})) + len(root.get("devDependencies", {})) total = len([k for k in lock["packages"] if k]) print(f"Manually declared: {direct} | Actually in the tree: {total}") ```

In my bot, 14 declared libraries expanded into 492 packages, and on a web project — into 1,442 packages. The bare minimum of hygiene is committing lock files and running `trufflehog`, `trivy fs --scanners vuln,secret`, and `syft`.

Security hooks, delegation tiers, and dependency controls are already built into the [Nomad AI](https://nomadnet.ai) stack and on the [agent.nomadnet.ai](https://agent.nomadnet.ai) platform. You can learn engineering-grade vibe coding without losing control over architecture at [Hamidun Academy](https://academy.hamidun.com) (72-hour free trial), and battle-tested rules and guardrails are available in the [Vibe Club](https://hamidun.com/club).