Das überraschendste Ergebnis der jüngsten KI-Produktivitätsforschung ist nicht, dass Coding-Assistenten Entwickler langsamer machen können. Es ist, dass die Entwickler es nicht bemerken.
In METRs randomisierter kontrollierter Studie wurde bei 16 erfahrenen Open-Source-Entwicklern, die an 246 realen Aufgaben in ihren eigenen Repositories arbeiteten, eine 19-prozentige Verlangsamung gemessen. Dies ist ein vorläufiges Zwischenergebnis einer laufenden Forschungsreihe mit kleiner Stichprobe und spezifischem Aufgabenkontext (vertraute Codebases). Die Teilnehmer hatten zuvor eine 24-prozentige Beschleunigung vorhergesagt und glaubten auch im Nachhinein noch, 20 Prozent schneller gewesen zu sein. Die Kluft zwischen Wahrnehmung und Messung: 39 bis 44 Prozentpunkte.
Das ist kein Zufall. Es hat eine Struktur. Die Kluft zwischen Selbsteinschätzung und Messung ist kein isoliertes Phänomen, sondern systematisch reproduzierbar und in bekannten kognitiven und methodischen Faktoren verwurzelt.
Die strukturelle Wahrnehmungslücke
Das Studiendesign verdient einen genaueren Blick. Ein echtes RCT, randomisierte Zuordnung, Bildschirmaufzeichnung, reale Aufgaben in vertrauten Codebases, keine synthetischen Benchmarks. Und dennoch aktualisierten die Entwickler ihre Überzeugungen nicht, selbst nachdem sie messbar langsamere Aufgaben abgeschlossen hatten. Die subjektive Produktivitätswahrnehmung hatte sich vollständig von der objektiven Leistung entkoppelt. Die Autoren von METR weisen darauf hin, dass ein Teil der Verlangsamung darauf zurückzuführen sein könnte, dass Entwickler Zeit mit dem Formulieren von Prompts, dem Bewerten von Vorschlägen und dem Debuggen von generiertem Code verbrachten. Dieser Overhead bleibt in der subjektiven Wahrnehmung unsichtbar, weil er sich wie aktive Arbeit anfühlt, nicht wie Leerlauf.
Dies ist kein isolierter Befund. Laut einer Umfrage von Panto, einem kommerziellen KI-Tool-Anbieter, dessen Daten aus seiner eigenen Nutzerbasis stammen, berichten 74 Prozent der Entwickler, sich mit KI-Tools produktiver zu fühlen. Kontrollierte Messungen bestätigen jedoch regelmäßig keine vergleichbaren Gewinne, insbesondere nicht für erfahrene Entwickler, die an komplexen Codebases arbeiten. Die Kluft zwischen Wahrnehmung und Messung ist kein methodisches Artefakt. Sie ist eine strukturelle Eigenschaft der menschlichen Bewertung KI-unterstützter Arbeit.
Automation Bias verstärkt das Problem. Eine Metaanalyse der California Management Review über 74 Studien ergab, dass automatisierte Systeme mit hoher, aber nicht perfekter Genauigkeit systematisch Übervertrauen erzeugen. Laut dieser Analyse steigen Begehungsfehler um 12 Prozent und die Anomalieerkennung verlangsamt sich. Auf KI-Coding-Tools übertragen: Entwickler übersehen wahrscheinlich mehr Fehler im generierten Output, gerade weil die Genauigkeitsrate hoch genug ist, um die Wachsamkeit zu untergraben.
Warum versagt die Selbsteinschätzung so konsistent? KI-Tools reduzieren den wahrgenommenen kognitiven Aufwand durch Boilerplate-Generierung und Autovervollständigung. Das erzeugt ein subjektives Flow-Erlebnis, das Entwickler als Geschwindigkeit interpretieren. Anthropics Studie zur Kompetenzentwicklung, deren detaillierte Ergebnisse im Abschnitt "Die unsichtbare Schuld" ausführlicher besprochen werden, enthüllt den Mechanismus: Entwickler, die stark an KI delegierten, schnitten bei Verständnistests unter 40 Prozent ab. Genau der Mechanismus, der sich produktiv anfühlt, nämlich reduziertes kognitives Engagement, verschlechtert die Fähigkeit, die eigene Leistung zu bewerten. Für jede Organisation bedeutet das: Eine KI-Produktivitätsbewertung auf Basis von Selbstberichten überschätzt systematisch den Nutzen.
Individuelle Gewinne, systemische Stagnation
Wenn die Selbsteinschätzung einzelner Entwickler schon unzuverlässig ist, was passiert dann auf Teamebene? Telemetriedaten von über 10.000 Entwickler-Workflows liefern eine ernüchternde Antwort.
Faros AIs Produktivitätsstudie zeichnet ein paradoxes Bild: Einzelne Entwickler mit KI-Unterstützung mergen 98 Prozent mehr Pull Requests und schließen 21 Prozent mehr Tasks ab. Doch die DORA-Metriken (Deployment Frequency, Lead Time for Changes, Change Failure Rate und Time to Restore Service), die vier Kernindikatoren der Software-Delivery-Performance, bleiben auf Organisationsebene flach. Flache DORA-Metriken bei steigendem individuellem Output sind das Zeichen eines Systemengpasses, nicht eines Produktivitätsgewinns. Mehr individueller Output übersetzt sich nicht in höheren organisatorischen Durchsatz.
Die Erklärung liegt in einer Engpassverschiebung. KI beschleunigt die Codegenerierung, erzeugt aber eine überwältigende Review-Last im nachgelagerten Prozess. Die PR-Review-Zeit steigt bei Teams mit hoher KI-Adoption um 91 Prozent laut Faros AI, getrieben durch einen 154-prozentigen Anstieg der durchschnittlichen PR-Größe. Größere PRs erhöhen die kognitive Belastung für Reviewer überproportional. Jede Einheit KI-generierter Leistung erfordert mehr menschliche Bewertungszeit, als sie einspart.
Die Fertigungsanalogie ist treffend: Ein schnellerer Produktionsschritt vor einem manuellen Qualitätsprüfungsschritt erhöht nicht den Gesamtdurchsatz. Er erzeugt einen Rückstau halbfertiger Produkte. Laut Faros AI bleibt die Deployment-Frequenz selbst bei 98 Prozent mehr Merges unverändert.
Ein erschwerender Faktor: GitClears Langzeitanalyse verzeichnet einen fast 30-prozentigen Rückgang der Peer-Review-Beteiligung parallel zur steigenden KI-Adoption, obwohl das Commit-Volumen um 55 Prozent gestiegen ist. Mehr Output bei weniger Review produziert unkontrollierte Qualitätserosion. Der individuelle ROI von 4:1 (laut Index.dev: 150 Dollar eingesparte Entwicklerzeit gegenüber 37,50 Dollar pro zusätzlichem PR) bricht zusammen, wenn man den Review-Overhead, eine 1,7-fache Fehlerrate laut Sonar und verdoppelten Code-Churn einrechnet.
Technische Schulden in beispiellosem Tempo
Das Problem flacher Systemmetriken wird durch die Qualität des generierten Codes selbst verschärft. Mehr Code bedeutet auch: mehr technische Schulden, in einem nie dagewesenen Tempo.
Sonars Developer Survey 2026 mit über 1.100 Entwicklern ergab: KI-generierter Code enthält 1,7-mal mehr Gesamtprobleme als menschlich geschriebener Code. Logikfehler sind 1,75-mal höher, Wartbarkeitsprobleme 1,64-mal, Sicherheitslücken 1,57-mal. Eine auf der IEEE ISSRE 2025 vorgestellte Studie mit 500.000 Code-Samples und Ox Securitys Analyse von 300 Open-Source-Projekten werden gemeinsam von InfoQ referenziert: KI- und menschlicher Code haben grundlegend verschiedene Defektprofile. Sie versagen auf kategorisch unterschiedliche Weise.
Ox Securitys Analyse identifizierte 10 wiederkehrende Anti-Patterns, die in 80 bis 100 Prozent des KI-generierten Codes auftreten:
- Exzessives Kommentieren (90-100 Prozent)
- Lehrbuchmuster ohne kontextuelle Anpassung (80-90 Prozent)
- Refactoring-Resistenz (80-90 Prozent)
- Überspezifikation für unwahrscheinliche Randfälle (80-90 Prozent)
- Duplizierte Bugs über Generierungssitzungen hinweg (80-90 Prozent)
Der Titel ihres Reports, "Army of Juniors", trifft den Punkt: KI produziert funktional kompetenten Code, dem die architektonische Weisheit erfahrener Ingenieure fehlt. Besonders deutlich wird dies in der Unfähigkeit, technische Entscheidungen im Kontext des Gesamtsystems zu treffen. KI-generierter Code löst das unmittelbare Problem, ignoriert aber Nebenwirkungen auf Nachbarsysteme, bestehende Abstraktionen und langfristige Wartungskosten.
GitClears Fünfjahresanalyse von 211 Millionen Zeilen zeigt die strukturelle Konsequenz: KI-intensive Repositories weisen ein 34 Prozent höheres kumulatives Refactoring-Defizit auf. "Moved Code", ein Proxy für gesundes Refactoring, ist auf nahezu null gefallen. Copy-Paste-Code hat zum ersten Mal 2024 refaktorierten Code übertroffen, ein Wendepunkt im Code-Evolutionsverhalten. Codebases wachsen durch Akkumulation statt durch Konsolidierung; jedes neue Feature fügt Schichten hinzu, anstatt bestehende Strukturen zu verbessern. Laut Addy Osmani haben bis 2026 bereits 75 Prozent der Technologie-Entscheidungsträger moderate bis schwerwiegende Konsequenzen aus diesen angehäuften Schulden.
Die unsichtbare Schuld: Kompetenzen und Urteilsvermögen
Jenseits der technischen Schulden akkumuliert sich eine weitere, weniger sichtbare Schuld bei den Entwicklern selbst. Ihre Fähigkeiten und ihr Urteilsvermögen verändern sich parallel zur Tool-Nutzung.
Der stärkste direkte Beleg stammt aus Anthropics 52-Personen-RCT, dokumentiert als Sekundärquelle bei InfoQ: Junior-Entwickler mit KI-Unterstützung schnitten bei Verständnistests 17 Prozent schlechter ab (50 vs. 67 Prozent). Nicht alle KI-Nutzung war gleich schädlich: Wer stark delegierte, fiel unter 40 Prozent. Wer KI strategisch für konzeptionelle Fragen nutzte, lag über 65 Prozent. Wie KI genutzt wird, bestimmt das Ergebnis weit mehr als ob sie genutzt wird.
Die Studie identifizierte eine gefährliche Rückkopplungsschleife: Mehr Delegation verschlechtert die Überwachungsfähigkeit, was wiederum die Abhängigkeit von KI für Aufgaben erhöht, die der Entwickler nicht mehr selbstständig bewältigen kann. Die Zeitersparnis war vernachlässigbar, etwa zwei Minuten pro Aufgabe. Ein schlechter Tausch für nachhaltigen Kompetenzverlust.
Die Parallele zur Automation Complacency in der Luftfahrt ist keine Metapher: Piloten, die sich jahrelang auf den Autopiloten verlassen, verlieren nachweislich manuelle Flugfähigkeiten. Die Softwareentwicklung folgt derselben Dynamik, nur ohne die regulatorischen Gegenmaßnahmen, die die Luftfahrt längst implementiert hat.
Junior-Entwickler tragen das höchste Risiko, da sie gleichzeitig die intensivsten KI-Nutzer und die am stärksten von kognitivem Offloading während formativer Lernphasen Betroffenen sind. Laut Addy Osmani erzielen Juniors Produktivitätsgewinne von 35 bis 39 Prozent gegenüber 8 bis 16 Prozent für Seniors. Diese Geschwindigkeitsgewinne gehen möglicherweise direkt auf Kosten des architektonischen Urteilsvermögens und der Debugging-Intuition, die Senior Engineering definieren. Organisationen, die auf Junior-Geschwindigkeit optimieren, schwächen möglicherweise ihre langfristige Engineering-Pipeline und werden den Schaden erst bemerken, wenn die aktuelle Generation in Rollen hineinwächst, die mehr verlangen, als sie mitbringen.
Was tatsächlich funktioniert
Keines dieser Ergebnisse bedeutet, dass KI-Tools nutzlos sind. Sie bedeuten, dass pauschale Produktivitätsversprechen der Realität nicht standhalten und dass es auf den Kontext ankommt.
Senoritätslinie und Aufgabeneignung
Produktivitätseffekte divergieren scharf entlang der Senoritätslinie. Kontrollierte Studien zeigen 35 bis 39 Prozent Gewinne für Juniors laut Addy Osmani, aber nur 8 bis 16 Prozent für erfahrene Entwickler. Im Extremfall: METRs RCT ergab eine 19-prozentige Verlangsamung für Experten, die in ihren eigenen Repositories arbeiteten, ein Ergebnis einer Stichprobe von 16 Entwicklern in einem spezifischen Kontext, das nicht ohne Weiteres verallgemeinert werden sollte. Seniors besitzen bereits die Mustererkennung und das Kontextwissen, das KI bereitstellt. Für Juniors füllt KI echte Wissenslücken. Für Experten übersteigt der Bewertungsaufwand den Generierungsvorteil.
Forschung zeigt klare Eignungsgrenzen. Laut Pantos eigener Umfrage unter seiner Nutzerbasis arbeiten Entwickler bei Routineaufgaben 51 Prozent schneller, mit bis zu 81 Prozent Zeitersparnis bei CRUD-Operationen und API-Integration. KI stößt an ihre Grenzen bei neuartiger Algorithmenentwicklung, komplexer Geschäftslogik, Architekturentscheidungen und sicherheitskritischen Implementierungen. Die Grenze verläuft nicht zwischen KI und Nicht-KI, sondern zwischen Aufgaben, bei denen Fehlerkosten niedrig sind, und solchen, bei denen sie katastrophal sein können.
Messen, nicht schätzen
Die 39-44-Prozentpunkte-Kluft zwischen Wahrnehmung und Realität disqualifiziert Selbsteinschätzung als Entscheidungsgrundlage. Wer wirklich wissen will, ob KI-Tools einen Unterschied machen, muss DORA-Metriken, Review-Zeiten und Fehlerraten verfolgen, nicht die Stimmung der Entwickler. Der folgende Code berechnet die durchschnittliche PR Cycle Time (Zeit von PR-Erstellung bis Merge) und PR-Größe, beides nützliche Proxies für Review-Engpässe, aber zu unterscheiden von der DORA Lead Time, die ab dem initialen Commit zählt:
# Calculate PR Cycle Time and PR size from GitHub data
# Prerequisites: GitHub CLI (gh) and jq installed
gh pr list \
--state merged \
--limit 100 \
--json number,createdAt,mergedAt,additions,deletions \
| jq '[.[] | {
pr: .number,
cycle_time_h: ((.mergedAt | fromdateiso8601) - (.createdAt | fromdateiso8601)) / 3600,
pr_size: (.additions + .deletions)
}] | {
avg_cycle_time_h: (map(.cycle_time_h) | add / length),
avg_pr_size: (map(.pr_size) | add / length)
}'
Das Ergebnis zeigt, wie lange PRs durchschnittlich offen bleiben und wie groß sie typischerweise sind. Wer einen Trend erkennt - wachsende PR-Größen bei stabiler oder sinkender Merge-Frequenz - steht vor dem Review-Engpass-Muster, das Faros AI über 10.000 Entwickler-Workflows dokumentierte.
Governance als Voraussetzung
Laut DevOps.com erzielen Unternehmen mit Governance-Investitionen deutlich bessere KI-Ergebnisse als Teams ohne strukturierte Frameworks. Governance bedeutet hier: proaktive Skalierung der Review-Kapazität, Einführung KI-spezifischer Qualitätsmetriken und bewusste Schaffung von Lernräumen für Junior-Entwickler ohne KI-Delegation. Teams, die KI als Pair-Programming-Partner nutzen, mit aktivem Code-Review und bewusster Auseinandersetzung mit dem generierten Output, berichten durchweg bessere Ergebnisse als solche, die KI-Output direkt und ungeprüft übernehmen. Die Art der Interaktion bestimmt das Ergebnis: KI als Denkpartner statt als Ghostwriter. Strukturierte agentenbasierte Entwicklungs-Workflows mit Multi-Agent-Pipelines und Quality Gates sind ein konkreter Ansatz, diese Art von Governance skalierbar umzusetzen.
Fazit für Entscheidungsträger
KI-Coding-Tools sind weder nutzlos noch das pauschale Produktivitätswunder, als das sie vermarktet werden. Ihr Wert hängt davon ab, wer sie nutzt, wofür und mit welcher organisatorischen Infrastruktur. Wer das ignoriert, akkumuliert technische und menschliche Schulden, die sich bereits heute in steigenden Wartungskosten, wachsenden Review-Rückständen und erodierenden Engineering-Kompetenzen manifestieren. Die entscheidende Frage ist nicht, ob diese Konsequenzen eintreten, sondern ob Ihre Organisation sie früh genug erkennt, um den Kurs zu korrigieren, bevor das Ausmaß des Problems eine sinnvolle Korrektur prohibitiv teuer macht.
The most surprising finding from recent AI productivity research isn't that coding assistants can make developers slower. It's that the developers don't notice.
METR's randomized controlled trial measured a 19 percent slowdown among 16 experienced open-source developers working on 246 real tasks in their own repositories. This is a preliminary interim result from an ongoing research series, with a small sample size and specific task context (familiar codebases). Participants had predicted a 24 percent speedup beforehand, and still believed they had been 20 percent faster afterward. The gap between perception and measurement: 39 to 44 percentage points.
This is not a coincidence. It has a structure. The gap between self-assessment and measurement is not an isolated phenomenon but systematically reproducible, rooted in well-known cognitive and methodological factors.
The Structural Perception Gap
The study design deserves a closer look. A genuine RCT, randomized assignment, screen recording, real tasks in familiar codebases, no synthetic benchmarks. And yet developers did not update their beliefs, even after completing measurably slower tasks. The subjective experience of productivity had completely decoupled from objective performance. METR's authors point out that part of the slowdown may be attributable to developers spending time formulating prompts, evaluating suggestions, and debugging generated code. That overhead remains invisible in subjective perception because it feels like active work, not idle time.
This is not an isolated finding. According to a survey by Panto, a commercial AI tool vendor whose data comes from its own user base, 74 percent of developers report feeling more productive with AI tools. However, controlled measurements regularly fail to confirm equivalent gains, especially not for experienced developers working on complex codebases. The gap between perception and measurement is not a methodological artifact. It is a structural property of how humans evaluate AI-assisted work.
Automation bias amplifies the problem. A meta-analysis by the California Management Review across 74 studies found that automated systems with high but imperfect accuracy systematically generate overreliance. According to this analysis, commission errors increase by 12 percent and anomaly detection slows down. Applied to AI coding tools: developers likely miss more errors in generated output precisely because the accuracy rate is high enough to erode vigilance.
Why does self-assessment fail so consistently? AI tools reduce perceived cognitive effort through boilerplate generation and autocompletion. This creates a subjective flow experience that developers interpret as speed. Anthropic's study on skill formation, whose detailed findings are discussed more extensively in the section "The Invisible Debt", reveals the mechanism: developers who heavily delegated to AI scored below 40 percent on comprehension tests. The very mechanism that feels productive, reduced cognitive engagement, degrades the ability to evaluate one's own output. For any organization, this means: an AI productivity assessment based on self-reporting systematically overestimates benefits.
Individual Gains, Systemic Stagnation
If individual developers' self-assessments are already unreliable, what happens at the team level? Telemetry data from over 10,000 developer workflows provides a sobering answer.
Faros AI's productivity study paints a paradoxical picture: individual developers with AI support merge 98 percent more pull requests and close 21 percent more tasks. Yet DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service), the four core indicators of software delivery performance, remain flat at the organizational level. Flat DORA metrics amid rising individual output are the sign of a system bottleneck, not a productivity gain. More individual output does not translate into higher organizational throughput.
The explanation lies in a bottleneck shift. AI accelerates code generation but creates an overwhelming review burden downstream. PR review time increases by 91 percent on teams with high AI adoption according to Faros AI, driven by a 154 percent increase in average PR size. Larger PRs disproportionately increase cognitive load for reviewers. Each unit of AI-generated output demands more human evaluation time than it saves.
The manufacturing analogy is apt: a faster production step before a manual quality inspection step does not increase overall throughput. It creates a backlog of semi-finished products. According to Faros AI, deployment frequency remains unchanged even with 98 percent more merges.
An aggravating factor: GitClear's longitudinal analysis records a nearly 30 percent decline in peer review participation alongside rising AI adoption, even though commit volume increased by 55 percent. More output with less review produces uncontrolled quality erosion. The individual ROI of 4:1 (according to Index.dev: $150 in saved developer time versus $37.50 per additional PR) collapses when you factor in review overhead, a 1.7x error rate according to Sonar, and doubled code churn.
Technical Debt at an Unprecedented Pace
The problem of flat system metrics is deepened by the quality of the generated code itself. More code also means: more technical debt, at a pace never seen before.
Sonar's Developer Survey 2026 of over 1,100 developers found: AI-generated code contains 1.7 times more total issues than human-written code. Logic errors are 1.75 times higher, maintainability issues 1.64 times, security vulnerabilities 1.57 times. A study presented at IEEE ISSRE 2025 with 500,000 code samples and Ox Security's analysis of 300 open-source projects are referenced together by InfoQ: AI and human code have fundamentally different defect profiles. They fail in categorically different ways.
Ox Security's analysis identified 10 recurring anti-patterns appearing in 80 to 100 percent of AI-generated code:
- Excessive commenting (90–100 percent)
- Textbook patterns without contextual adaptation (80–90 percent)
- Resistance to refactoring (80–90 percent)
- Over-specification for unlikely edge cases (80–90 percent)
- Duplicated bugs across generation sessions (80–90 percent)
The title of their report, "Army of Juniors", hits the mark: AI produces functionally competent code that lacks the architectural wisdom of experienced engineers. This is particularly evident in the inability to make technical decisions in the context of the overall system. AI-generated code solves the immediate problem but ignores side effects on neighboring systems, existing abstractions, and long-term maintenance costs.
GitClear's five-year analysis of 211 million lines shows the structural consequence: AI-intensive repositories exhibit 34 percent higher cumulative refactoring deficit. "Moved Code", a proxy for healthy refactoring, has dropped to near zero. Copy-paste code surpassed refactored code for the first time in 2024, a turning point in code evolution behavior. Codebases grow through accumulation rather than consolidation; each new feature adds layers instead of improving existing structures. According to Addy Osmani, by 2026, 75 percent of technology decision-makers already face moderate to severe consequences from this accumulated debt.
The Invisible Debt: Skills and Judgment
Beyond technical debt, another less visible debt accumulates among the developers themselves. Their skills and judgment change in parallel with tool usage.
The strongest direct evidence comes from Anthropic's 52-person RCT, documented as a secondary source at InfoQ: junior developers with AI support scored 17 percent worse on comprehension tests (50 vs. 67 percent). Not all AI usage was equally harmful: those who heavily delegated fell below 40 percent. Those who used AI strategically for conceptual questions scored above 65 percent. How AI is used determines the outcome far more than whether it is used.
The study identified a dangerous feedback loop: more delegation degrades monitoring ability, which in turn increases dependence on AI for tasks the developer can no longer handle independently. The time savings were negligible, roughly two minutes per task. A poor trade for sustained competence loss.
The parallel to automation complacency in aviation is not a metaphor: pilots who rely on autopilot for years demonstrably lose manual flying skills. Software development follows the same dynamic, only without the regulatory countermeasures that aviation implemented long ago.
Junior developers bear the highest risk because they are simultaneously the heaviest AI users and the most vulnerable to cognitive offloading during formative learning phases. According to Addy Osmani, juniors achieve productivity gains of 35 to 39 percent versus 8 to 16 percent for seniors. These speed gains may come directly at the cost of architectural judgment and debugging intuition that define senior engineering. Organizations that optimize for junior velocity may be weakening their long-term engineering pipeline, and won't notice the damage until the current generation grows into roles that demand more than they bring.
What Actually Works
None of these findings mean that AI tools are useless. They mean that blanket productivity promises don't hold up to reality, and that context is what matters.
Seniority Line and Task Suitability
Productivity effects diverge sharply along the seniority line. Controlled studies show 35 to 39 percent gains for juniors according to Addy Osmani, but only 8 to 16 percent for experienced developers. At the extreme: METR's RCT found a 19 percent slowdown for experts working in their own repositories, a result from a sample of 16 developers in a specific context that should not be readily generalized. Seniors already possess the pattern recognition and contextual knowledge that AI provides. For juniors, AI fills genuine knowledge gaps. For experts, evaluation overhead exceeds the generation advantage.
Research shows clear suitability boundaries. According to Panto's own survey of its user base, developers work 51 percent faster on routine tasks, with up to 81 percent time savings reported for CRUD operations and API integration. AI reaches its limits with novel algorithm development, complex business logic, architectural decisions, and security-critical implementations. The boundary runs not between AI and non-AI, but between tasks where error costs are low and those where they can be catastrophic.
Measure, Don't Estimate
The 39–44 percentage point gap between perception and reality disqualifies self-assessment as a decision-making basis. Anyone who truly wants to know whether AI tools make a difference must track DORA metrics, review times, and defect rates, not developer sentiment. The following code calculates the average PR Cycle Time (time from PR creation to merge) and PR size, both useful proxies for review bottlenecks, but to be distinguished from DORA Lead Time, which starts counting from the initial commit:
# Calculate PR Cycle Time and PR size from GitHub data
# Prerequisites: GitHub CLI (gh) and jq installed
gh pr list \
--state merged \
--limit 100 \
--json number,createdAt,mergedAt,additions,deletions \
| jq '[.[] | {
pr: .number,
cycle_time_h: ((.mergedAt | fromdateiso8601) - (.createdAt | fromdateiso8601)) / 3600,
pr_size: (.additions + .deletions)
}] | {
avg_cycle_time_h: (map(.cycle_time_h) | add / length),
avg_pr_size: (map(.pr_size) | add / length)
}'
The result shows how long PRs remain open on average and how large they typically are. Anyone who spots a trend, growing PR sizes with stable or declining merge frequency, is facing the review bottleneck pattern that Faros AI documented across over 10,000 developer workflows.
Governance as a Prerequisite
According to DevOps.com, companies with governance investments achieve significantly better AI outcomes than teams without structured frameworks. Governance here means: proactively scaling review capacity, introducing AI-specific quality metrics, and deliberately creating learning spaces for junior developers without AI delegation. Teams that use AI as a pair-programming partner, with active code review and conscious engagement with generated output, consistently report better results than those that accept AI output directly and unreviewed. The mode of interaction determines the outcome: AI as a thinking partner rather than a ghostwriter. Structured agent-based development workflows with multi-agent pipelines and quality gates are one concrete approach to implementing this kind of governance at scale.
Conclusion for Decision-Makers
AI coding tools are neither useless nor the blanket productivity miracle they are marketed as. Their value depends on who uses them, for what purpose, and with what organizational infrastructure. Those who ignore this accumulate technical and human debts that are already manifesting today in rising maintenance costs, growing review backlogs, and eroding engineering competencies. The critical question is not whether these consequences will occur, but whether your organization recognizes them early enough to course-correct before the scale of the problem makes any meaningful correction prohibitively expensive.
El hallazgo más sorprendente de la investigación reciente sobre productividad con IA no es que los asistentes de codificación puedan hacer más lentos a los desarrolladores. Es que los desarrolladores no lo notan.
El ensayo controlado aleatorizado de METR midió una desaceleración del 19 por ciento entre 16 desarrolladores experimentados de código abierto que trabajaban en 246 tareas reales en sus propios repositorios. Este es un resultado preliminar parcial de una serie de investigación en curso, con un tamaño de muestra pequeño y un contexto de tareas específico (bases de código familiares). Los participantes habían predicho una aceleración del 24 por ciento de antemano y aún creían que habían sido un 20 por ciento más rápidos después. La brecha entre percepción y medición: 39 a 44 puntos porcentuales.
Esto no es una coincidencia. Tiene una estructura. La brecha entre la autoevaluación y la medición no es un fenómeno aislado, sino sistemáticamente reproducible, enraizada en factores cognitivos y metodológicos bien conocidos.
La brecha estructural de percepción
El diseño del estudio merece un análisis más detallado. Un verdadero ECA, asignación aleatoria, grabación de pantalla, tareas reales en bases de código familiares, sin benchmarks sintéticos. Y aun así los desarrolladores no actualizaron sus creencias, incluso después de completar tareas mediblemente más lentas. La experiencia subjetiva de productividad se había desacoplado completamente del rendimiento objetivo. Los autores de METR señalan que parte de la desaceleración puede atribuirse a que los desarrolladores pasan tiempo formulando prompts, evaluando sugerencias y depurando código generado. Esa sobrecarga permanece invisible en la percepción subjetiva porque se siente como trabajo activo, no como tiempo muerto.
Este no es un hallazgo aislado. Según una encuesta de Panto, un proveedor comercial de herramientas de IA cuyos datos provienen de su propia base de usuarios, el 74 por ciento de los desarrolladores reporta sentirse más productivo con herramientas de IA. Sin embargo, las mediciones controladas regularmente no confirman ganancias equivalentes, especialmente no para desarrolladores experimentados que trabajan en bases de código complejas. La brecha entre percepción y medición no es un artefacto metodológico. Es una propiedad estructural de cómo los humanos evalúan el trabajo asistido por IA.
El sesgo de automatización amplifica el problema. Un metaanálisis de la California Management Review a través de 74 estudios encontró que los sistemas automatizados con alta pero imperfecta precisión generan sistemáticamente sobredependencia. Según este análisis, los errores de comisión aumentan un 12 por ciento y la detección de anomalías se ralentiza. Aplicado a las herramientas de codificación con IA: los desarrolladores probablemente pasan por alto más errores en la salida generada precisamente porque la tasa de precisión es lo suficientemente alta como para erosionar la vigilancia.
¿Por qué la autoevaluación falla de manera tan consistente? Las herramientas de IA reducen el esfuerzo cognitivo percibido a través de la generación de código repetitivo y el autocompletado. Esto crea una experiencia subjetiva de flujo que los desarrolladores interpretan como velocidad. El estudio de Anthropic sobre formación de habilidades, cuyos hallazgos detallados se discuten más extensamente en la sección "La deuda invisible", revela el mecanismo: los desarrolladores que delegaron mucho en la IA obtuvieron menos del 40 por ciento en pruebas de comprensión. El mismo mecanismo que se siente productivo, la reducción del compromiso cognitivo, degrada la capacidad de evaluar la propia producción. Para cualquier organización, esto significa: una evaluación de productividad con IA basada en autoinformes sobreestima sistemáticamente los beneficios.
Ganancias individuales, estancamiento sistémico
Si las autoevaluaciones de desarrolladores individuales ya no son fiables, ¿qué sucede a nivel de equipo? Los datos de telemetría de más de 10,000 flujos de trabajo de desarrolladores proporcionan una respuesta aleccionadora.
El estudio de productividad de Faros AI presenta una imagen paradójica: los desarrolladores individuales con soporte de IA fusionan un 98 por ciento más de pull requests y cierran un 21 por ciento más de tareas. Sin embargo, las métricas DORA (Deployment Frequency, Lead Time for Changes, Change Failure Rate y Time to Restore Service), los cuatro indicadores centrales del rendimiento de entrega de software, se mantienen planas a nivel organizacional. Métricas DORA planas en medio de un creciente rendimiento individual son la señal de un cuello de botella sistémico, no de una ganancia de productividad. Más producción individual no se traduce en mayor rendimiento organizacional.
La explicación reside en un desplazamiento del cuello de botella. La IA acelera la generación de código pero crea una carga abrumadora de revisión aguas abajo. El tiempo de revisión de PR aumenta un 91 por ciento en equipos con alta adopción de IA según Faros AI, impulsado por un aumento del 154 por ciento en el tamaño promedio de los PR. Los PR más grandes aumentan desproporcionadamente la carga cognitiva para los revisores. Cada unidad de producción generada por IA demanda más tiempo de evaluación humana del que ahorra.
La analogía con la manufactura es adecuada: un paso de producción más rápido antes de un paso manual de inspección de calidad no aumenta el rendimiento general. Crea un backlog de productos semiterminados. Según Faros AI, la frecuencia de despliegue permanece sin cambios incluso con un 98 por ciento más de merges.
Un factor agravante: el análisis longitudinal de GitClear registra una disminución de casi el 30 por ciento en la participación en peer review junto con una creciente adopción de IA, a pesar de que el volumen de commits aumentó un 55 por ciento. Más producción con menos revisión genera erosión de calidad descontrolada. El ROI individual de 4:1 (según Index.dev: $150 en tiempo de desarrollador ahorrado versus $37.50 por PR adicional) colapsa cuando se tiene en cuenta la sobrecarga de revisión, una tasa de error 1.7 veces mayor según Sonar y el doble de churn de código.
Deuda técnica a un ritmo sin precedentes
El problema de las métricas sistémicas planas se profundiza por la calidad del código generado en sí. Más código también significa: más deuda técnica, a un ritmo nunca antes visto.
La Encuesta de Desarrolladores 2026 de Sonar con más de 1,100 desarrolladores encontró: el código generado por IA contiene 1.7 veces más problemas totales que el código escrito por humanos. Los errores de lógica son 1.75 veces mayores, los problemas de mantenibilidad 1.64 veces, las vulnerabilidades de seguridad 1.57 veces. Un estudio presentado en IEEE ISSRE 2025 con 500,000 muestras de código y el análisis de Ox Security de 300 proyectos de código abierto son referenciados conjuntamente por InfoQ: el código de IA y el humano tienen perfiles de defectos fundamentalmente diferentes. Fallan de maneras categóricamente distintas.
El análisis de Ox Security identificó 10 antipatrones recurrentes que aparecen en el 80 al 100 por ciento del código generado por IA:
- Comentarios excesivos (90-100 por ciento)
- Patrones de libro de texto sin adaptación contextual (80-90 por ciento)
- Resistencia al refactoring (80-90 por ciento)
- Sobreespecificación para casos extremos improbables (80-90 por ciento)
- Bugs duplicados entre sesiones de generación (80-90 por ciento)
El título de su informe, "Army of Juniors", da en el clavo: la IA produce código funcionalmente competente al que le falta la sabiduría arquitectónica de ingenieros experimentados. Esto es particularmente evidente en la incapacidad de tomar decisiones técnicas en el contexto del sistema general. El código generado por IA resuelve el problema inmediato pero ignora los efectos secundarios en sistemas vecinos, abstracciones existentes y costos de mantenimiento a largo plazo.
El análisis de cinco años de GitClear de 211 millones de líneas muestra la consecuencia estructural: los repositorios intensivos en IA exhiben un déficit de refactoring acumulado un 34 por ciento mayor. "Moved Code", un proxy para un refactoring saludable, ha caído a casi cero. El código de copiar y pegar superó al código refactorizado por primera vez en 2024, un punto de inflexión en el comportamiento de evolución del código. Las bases de código crecen por acumulación en lugar de por consolidación; cada nueva funcionalidad añade capas en lugar de mejorar las estructuras existentes. Según Addy Osmani, para 2026, el 75 por ciento de los tomadores de decisiones tecnológicas ya enfrentan consecuencias moderadas a severas de esta deuda acumulada.
La deuda invisible: habilidades y criterio
Más allá de la deuda técnica, se acumula otra deuda menos visible entre los propios desarrolladores. Sus habilidades y criterio cambian en paralelo con el uso de herramientas.
La evidencia directa más fuerte proviene del ECA de 52 personas de Anthropic, documentado como fuente secundaria en InfoQ: los desarrolladores junior con soporte de IA obtuvieron un 17 por ciento peor en pruebas de comprensión (50 vs. 67 por ciento). No todo uso de IA fue igualmente dañino: quienes delegaron mucho cayeron por debajo del 40 por ciento. Quienes usaron la IA estratégicamente para preguntas conceptuales obtuvieron más del 65 por ciento. Cómo se usa la IA determina el resultado mucho más que si se usa.
El estudio identificó un bucle de retroalimentación peligroso: más delegación degrada la capacidad de monitoreo, lo que a su vez aumenta la dependencia de la IA para tareas que el desarrollador ya no puede manejar de forma independiente. El ahorro de tiempo fue insignificante, aproximadamente dos minutos por tarea. Un mal intercambio por una pérdida sostenida de competencia.
El paralelo con la complacencia de automatización en la aviación no es una metáfora: los pilotos que dependen del piloto automático durante años pierden demostrablemente sus habilidades de vuelo manual. El desarrollo de software sigue la misma dinámica, solo que sin las contramedidas regulatorias que la aviación implementó hace mucho tiempo.
Los desarrolladores junior cargan con el mayor riesgo porque son simultáneamente los usuarios más intensivos de IA y los más vulnerables a la descarga cognitiva durante las fases formativas de aprendizaje. Según Addy Osmani, los juniors logran ganancias de productividad del 35 al 39 por ciento versus el 8 al 16 por ciento para los seniors. Estas ganancias de velocidad pueden ir directamente a costa del criterio arquitectónico y la intuición de depuración que definen la ingeniería senior. Las organizaciones que optimizan para la velocidad de los juniors pueden estar debilitando su pipeline de ingeniería a largo plazo, y no notarán el daño hasta que la generación actual crezca hacia roles que demandan más de lo que aportan.
Qué funciona realmente
Ninguno de estos hallazgos significa que las herramientas de IA sean inútiles. Significan que las promesas generales de productividad no resisten la realidad y que el contexto es lo que importa.
Línea de senioridad e idoneidad de tareas
Los efectos de productividad divergen marcadamente a lo largo de la línea de senioridad. Los estudios controlados muestran ganancias del 35 al 39 por ciento para juniors según Addy Osmani, pero solo del 8 al 16 por ciento para desarrolladores experimentados. En el extremo: el ECA de METR encontró una desaceleración del 19 por ciento para expertos trabajando en sus propios repositorios, un resultado de una muestra de 16 desarrolladores en un contexto específico que no debería generalizarse fácilmente. Los seniors ya poseen el reconocimiento de patrones y el conocimiento contextual que la IA proporciona. Para los juniors, la IA llena verdaderas lagunas de conocimiento. Para los expertos, la sobrecarga de evaluación supera la ventaja de generación.
La investigación muestra límites claros de idoneidad. Según la propia encuesta de Panto entre su base de usuarios, los desarrolladores trabajan un 51 por ciento más rápido en tareas rutinarias, con hasta un 81 por ciento de ahorro de tiempo reportado para operaciones CRUD e integración de API. La IA alcanza sus límites con el desarrollo de algoritmos novedosos, la lógica de negocio compleja, las decisiones arquitectónicas y las implementaciones críticas de seguridad. El límite no está entre IA y no-IA, sino entre tareas donde los costos de error son bajos y aquellas donde pueden ser catastróficos.
Medir, no estimar
La brecha de 39-44 puntos porcentuales entre percepción y realidad descalifica la autoevaluación como base para la toma de decisiones. Quien realmente quiera saber si las herramientas de IA marcan una diferencia debe rastrear métricas DORA, tiempos de revisión y tasas de defectos, no el sentimiento de los desarrolladores. El siguiente código calcula el PR Cycle Time promedio (tiempo desde la creación del PR hasta el merge) y el tamaño del PR, ambos proxies útiles para cuellos de botella de revisión, pero a distinguir del DORA Lead Time, que comienza a contar desde el commit inicial:
# Calculate PR Cycle Time and PR size from GitHub data
# Prerequisites: GitHub CLI (gh) and jq installed
gh pr list \
--state merged \
--limit 100 \
--json number,createdAt,mergedAt,additions,deletions \
| jq '[.[] | {
pr: .number,
cycle_time_h: ((.mergedAt | fromdateiso8601) - (.createdAt | fromdateiso8601)) / 3600,
pr_size: (.additions + .deletions)
}] | {
avg_cycle_time_h: (map(.cycle_time_h) | add / length),
avg_pr_size: (map(.pr_size) | add / length)
}'
El resultado muestra cuánto tiempo permanecen abiertos los PR en promedio y cuán grandes son típicamente. Quien detecte una tendencia - tamaños de PR crecientes con frecuencia de merge estable o decreciente - está enfrentando el patrón de cuello de botella de revisión que Faros AI documentó a través de más de 10,000 flujos de trabajo de desarrolladores.
Gobernanza como requisito previo
Según DevOps.com, las empresas con inversiones en gobernanza logran resultados de IA significativamente mejores que los equipos sin marcos estructurados. Gobernanza aquí significa: escalar proactivamente la capacidad de revisión, introducir métricas de calidad específicas para IA y crear deliberadamente espacios de aprendizaje para desarrolladores junior sin delegación de IA. Los equipos que usan la IA como compañero de pair programming, con revisión activa de código y compromiso consciente con la salida generada, reportan consistentemente mejores resultados que aquellos que aceptan la salida de IA directamente y sin revisión. El modo de interacción determina el resultado: IA como compañero de pensamiento en lugar de escritor fantasma. Los workflows de desarrollo basados en agentes con pipelines Multi-Agent y Quality Gates son un enfoque concreto para implementar este tipo de gobernanza a escala.
Conclusión para los tomadores de decisiones
Las herramientas de codificación con IA no son inútiles ni el milagro de productividad generalizado que se comercializa. Su valor depende de quién las usa, para qué propósito y con qué infraestructura organizacional. Quienes ignoren esto acumulan deudas técnicas y humanas que ya se manifiestan hoy en costos de mantenimiento crecientes, backlogs de revisión en aumento y competencias de ingeniería en erosión. La pregunta crítica no es si estas consecuencias ocurrirán, sino si su organización las reconoce lo suficientemente temprano como para corregir el rumbo antes de que la escala del problema haga cualquier corrección significativa prohibitivamente costosa.