# AI Productivity Is Burning Out Your Best Engineers > [!question] Lingering Questions > - The evidence base is one manager's team plus a single paraphrased GitLab survey stat — "40% faster," "three engineers," "zero points" are anecdotal and unquantified against a baseline. This is an experience report, not a study; treat the mechanism as plausible, not established. > - Does the burden actually concentrate at L4/L5 specifically, or is that an artifact of who this particular author surveyed and manages? > - If prevention work is converted into artifacts wholesale (tests, lint rules, filed bugs) to make it visible, does the artifact count become a new target and reintroduce the same measurement problem one level up? > [!tip] Article Ideas > - Does the "invisible validator" dynamic map onto WordPress.org plugin/theme review queues, where a small number of reviewers catch everything and their prevention work is measured, if at all, by volume rather than by what they stopped? > - "Lag effect" (faster review queues preceding rising incidents a few weeks later) as a metric worth watching in any team after enabling AI-assisted workflows. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Prevented Work Is Invisible to Velocity Metrics]] — already promoted from this exact source in a prior pass > - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — invisible validation labor as a structural AI-adoption cost > [!quote] Vocabulary > - **Invisible validator** — an engineer whose primary contribution is catching and correcting AI-generated defects, work that leaves no trace in velocity metrics > - **Lag effect** — the delay between a faster (but shallower) code-review process and the downstream production incidents it fails to prevent > - **AI Quality Gate** — the article's proposed fix: a named, sprint-tracked oversight role for validating AI-assisted output ## Bibliographic capsule A lead software engineer at AT&T describes the "invisible validator" problem: AI coding assistants raise juniors' floor and seniors' ceiling, but the burden of catching AI's mistakes — security gaps, compliance risks, architectural conflicts — concentrates on mid-level (L4/L5) engineers, whose corrective work never appears on a dashboard; after his team hit "40% faster" delivery, three of his best mid-level engineers quit within six to eight weeks. ## Author's thesis AI coding assistants didn't remove human judgment from software delivery, they relocated it — onto engineers experienced enough to spot what's wrong but not senior enough to delegate the cleanup — and because that validation work is invisible to velocity metrics by construction, the team loses exactly the people holding undocumented institutional context while leadership reads the dashboard as healthy. ## Key arguments (≤3) 1. **The load lands on mid-level engineers structurally, not by accident.** Juniors "feel productive from day one" (AI raises their floor); seniors go from sketch to prototype fast and have authority to delegate cleanup; mid-level engineers absorb validation quietly because they're positioned exactly where they can spot the problem but can't push the work elsewhere. 2. **Velocity metrics are blind to prevention by construction, not by miscalibration.** They count output; they structurally cannot count "the production incident that did not happen" — this is the article's sharpest single point. 3. **The fix is making invisible work visible, not slowing AI adoption.** Four concrete moves: a named "AI Quality Gate" role each sprint, a defect-prevention-rate metric, written-rationale requirements on AI-assisted review approvals, and deliberate rotation of the validation role. ## Claim atoms ### AI relocates validation work onto mid-level engineers > [!quote] ID:rw_leaddev_iv1 > They are experienced enough to spot what is wrong, but not senior enough to push the work elsewhere. So they absorb it quietly. Where/why: "Why this burden lands on mid-level engineers" section. Names the structural mechanism — the load lands on L4/L5 because of their position in the org ladder, not by chance. Anchor claim for the whole piece. ### Velocity metrics cannot count prevented incidents > [!quote] ID:rw_leaddev_iv2 > Velocity metrics count output. They do not count the production incident that did not happen. Where/why: "Measure what engineers prevent, not just what they ship" section. The measurement system is blind to prevention by construction — the core reason invisible validation stays invisible. ### Faster review queues precede rising incidents (lag effect) > [!quote] ID:rw_leaddev_iv3 > Code review queues move faster, but production incidents start creeping up a few weeks later. This is the lag effect. Where/why: "The warning signs hiding in plain sight" section. An observable, falsifiable signal a manager can watch for. ## Permanent candidates - **[P1] Optimizing one metric hides the work that metric can't see** — already promoted from this exact source in a prior pass as [[3. Resources/Permanent Notes/Prevented Work Is Invisible to Velocity Metrics]]. Do not recreate; this Literature Note fills the missing bibliographic/atom record for a source that was already mined. ## Processing checklist - [x] Confirmed this doc's `notes` field already contained a full deep-read (Refactor Appendix present) — ported directly - [x] Checked existing Permanents before creating new ones — found the exact claim already promoted; linked instead of duplicating - [x] Connect into the relevant MOC — [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] ## Links - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — invisible validation labor as a structural cost of AI-assisted development - [[3. Resources/Readwise/Articles/AI Productivity Is Burning Out Your Best Engineers]] — source document