Author: Dominic Böttger
Date: 2026-04-06
Source: https://dominic-boettger.com/blog/ai-writes-faster-than-your-shadow/
Journalistic Quality: 4/5
Influence: 3/5
This article examines how AI-assisted code generation is fundamentally transforming software development practices, creating a productivity paradox where developers feel faster but measured outcomes show they are slower. The author presents data showing that while AI generates 22% of merged code industry-wide (up to 80% in some cases), this code contains 1.7x more issues than human-written code, leading to 30% higher change failure rates and 91% longer review times. The core argument is that traditional code review processes cannot keep pace with AI's output volume, creating a "Nyquist-Shannon sampling problem" where defects systematically slip through. The article documents several production incidents (Kiro's 13-hour outage, Moltbook's 1.5 million leaked API keys, database deletions) attributed to inadequate guardrails around AI agents. The author advocates for a fundamental shift in software development: moving from manual code review to automated pipeline-based quality gates, from complex abstraction-heavy architectures to flat convention-based structures, and from developers as code producers to requirements engineers and quality gatekeepers. Proposed solutions include multi-layer automated testing (unit, integration, E2E, mutation, property-based, contract testing), static analysis with custom rules, multi-agent code review systems, infrastructure security boundaries, and spec-driven development. The article positions DevOps principles as more critical than ever, arguing that the ability to design robust pipelines and deployment processes has become developers' most important competency in the AI era.
The headline "AI Writes Faster Than Your Shadow — Now What?" accurately captures the article's central theme and does not misrepresent the content. The phrase references the Lucky Luke character who "shoots faster than his shadow," serving as a metaphor for AI's unprecedented code generation speed. The "Now What?" portion signals the article's prescriptive focus on adapting development processes to this new reality. The content delivers precisely what the headline promises: it establishes that AI writes code at extraordinary speed (the "faster than your shadow" claim is supported with concrete metrics showing 22% AI-generated code industry-wide, up to 80% in individual projects), then systematically addresses the "now what" question through detailed analysis of problems and solutions. The article's structure follows a logical progression: it opens with the speed observation, quantifies the productivity paradox with data, explains why traditional processes fail (the Nyquist-Shannon sampling theorem analogy), documents real-world failures, and concludes with actionable recommendations across multiple dimensions (testing, architecture, review processes, infrastructure). There is no sensationalism or clickbait element in the headline. The Lucky Luke metaphor, while playful, is substantiated throughout the text and serves as a recurring motif (the article concludes with "Lucky Luke shoots faster than his shadow. But without a target, he only hits the desert"). The headline does not promise controversy, secrets, or shocking revelations that the content fails to deliver. The tone established by the headline—acknowledging a dramatic shift while focusing on practical response—matches the article's analytical yet pragmatic approach. The author does not minimize the challenges (documenting production incidents and quality degradation) but frames them as solvable through process adaptation rather than AI rejection. One minor consideration: readers unfamiliar with the Lucky Luke reference might not immediately grasp the "faster than your shadow" metaphor, but the article's opening paragraphs quickly establish the speed context, making the headline comprehensible even without cultural background knowledge. Overall assessment: The headline accurately represents the content's scope, tone, and argument. It neither overpromises nor mischaracterizes what follows.
Text type: Essay (not labeled)
The article is written predominantly in the **indicative mood**, presenting assertions as verified facts rather than allegations or conditional claims. The author employs declarative statements throughout, particularly when citing data and research findings. Key indicators of indicative mood: **Quantitative assertions presented as fact**: "22% of all merged code lines are now AI-generated," "AI-authored code has 1.7x more issues," "Pull requests per author increased by 20%," "Change failure rate increased by 30%." These statements are presented without hedging language ("appears to," "may be," "allegedly") and are attributed to named sources (GitClear, CodeRabbit, SmartBear). **Categorical statements about causation**: "AI did not remove the safety net. The safety net was usually another person who did not fully understand the code." "The answer is not 'more people' — it is automation." These are presented as definitive conclusions, not hypotheses. **Incident documentation**: The production failures (Kiro, Moltbook, Grigorev, npm, Anthropic) are described in indicative mood as events that occurred, not as alleged or unverified claims. "An AI agent received overly broad permissions and deleted a production environment. 13 hours of outage." **Technical explanations**: The Nyquist-Shannon sampling theorem section presents the analogy as an established framework for understanding the problem, not as a speculative comparison. However, there are **limited subjunctive/conditional elements**: **Prescriptive recommendations**: "The role changes fundamentally: from code producer to requirements engineer and quality gatekeeper." This is a normative claim about what should happen, though presented with indicative certainty. **Predictive statements**: "The teams that adapt their process now will be the ones who make the difference in 12 months." This future-oriented claim uses conditional logic but is stated with confidence rather than uncertainty. **Hypothetical scenarios**: "Imagine you are standing at a conveyor belt inspecting every 10th part for defects." These are illustrative devices rather than factual claims requiring verification. The article's **source attribution pattern** reinforces the indicative mode: nearly every major quantitative claim is linked to a named source (GitClear, CodeRabbit, LogRocket, SmartBear/Cisco, paddo.dev, Bryan Finster, Dave Farley). The author presents these as established findings rather than contested allegations. The **absence of hedging language** is notable. The author rarely uses qualifiers like "appears to," "suggests," "may indicate," or "allegedly." Instead, statements are direct: "The data is clear," "The numbers don't lie," "These are not failure statistics. These are the measurements of a system under a load it was never designed for." The article does contain **normative/evaluative claims** ("What is expensive: understanding, maintaining, and correctly deploying that code"), but these are presented as factual assessments of the current state rather than subjective opinions requiring conditional framing. **Overall assessment**: The article operates primarily in indicative mood, presenting a fact-based argument supported by quantitative data and named sources. The author writes with the confidence of someone reporting verified findings rather than advancing unproven allegations. The prescriptive sections (recommendations) shift toward normative claims but maintain the same declarative tone. The linguistic mode suggests the author expects readers to accept the presented data as established fact rather than contested claims requiring verification.
This essay demonstrates good journalistic quality overall, with particular strengths in transparency, verifiability, and respect for personality rights. The author provides clear attribution, extensive source citations with accessible references, and maintains appropriate professional boundaries when discussing individuals and organizations. The factual foundation is substantially accurate for verified claims, though some statistical assertions remain unverified and warrant follow-up fact-checking. The primary weakness lies in objectivity, where the presentation employs emotionally colored language, dramatizing formulations, and rhetorical devices that move beyond purely sober analysis. The separation between factual reporting and analytical interpretation is generally clear given the essay format, though some declarative assertions could benefit from more explicit framing as interpretative judgments. For an essay addressing technical and organizational challenges in software development, the piece meets professional standards while acknowledging room for improvement in maintaining consistent neutrality of tone.
Good
The article provides clear authorship attribution (Dominic Böttger) with publication date and source identification. The author's professional background is evident through the content (working with software development teams and companies) and the blog context provides organizational structure. However, detailed information about potential conflicts of interest, funding sources, or the author's specific institutional affiliations beyond being a blog author is not explicitly disclosed. The transparency is substantially present with only minor gaps in comprehensive disclosure of all relevant interests.
Usable
The article presents numerous statistics and claims about AI coding productivity. Web research confirms several key claims: the 22% AI-generated code statistic is verified (DX reports 22-27.4% in Q4 2025-Q1 2026), Addy Osmani's 80% statement is confirmed (though his title differs from the article's description), Rakuten's 12.5-million-line codebase task is verified with 99.9% accuracy, and CodeRabbit's 1.7x issue rate is confirmed. However, several specific claims could not be verified through research: the Salesforce 90% engineer migration claim, the specific 23.5% incidents-per-PR increase, the 91% PR review time increase from GitConnected, and the 4.3 vs 1.2 minutes review time comparison from LogRocket. The core factual foundation is accurate for verified claims, but the unverified statistics (some of which are post-cutoff) create uncertainty about completeness. A subsequent fact verification is recommended for the unverified statistical claims.
Questionable
The presentation contains significant emotional coloring and evaluative language that undermines objectivity. The author uses dramatizing formulations such as "AI writes faster than your shadow," "wildly coding Lucky Luke," "catastrophe examples," and "media execution." The text employs strong value judgments like "the uncomfortable truth," "heroic acts," and characterizes certain practices as "hope" rather than pipelines. While the core argument about AI development challenges is substantive, the delivery frequently relies on rhetorical devices, metaphors, and charged language that goes beyond sober presentation. The tone shifts between analytical and advocacy, with clear prescriptive positions presented through emotionally weighted framing rather than purely neutral description.
Good
The article provides extensive source citations with accessible references throughout. Primary sources are clearly preferred, with direct links to industry reports (GitClear, CodeRabbit, DX), academic frameworks (DORA metrics from "Accelerate"), technical tools (Stryker, Pact, Semgrep), and specific blog posts (paddo.dev, Bryan Finster). The author cites specific incidents (Kiro, Moltbook, Grigorev) and industry examples (Rakuten, Salesforce) with enough detail to be traceable. Cross-verification is evident through multiple independent sources supporting similar claims. The main weakness is that some statistical claims lack complete source attribution (e.g., the 19% slowdown figure is attributed to METR but without a direct link), and a few secondary claims rely on the author's professional observations without external verification. Overall, the verifiability infrastructure is strong with most essential claims being independently checkable.
Good
The text is clearly identifiable as an essay/opinion piece through its blog context, authorial voice, and prescriptive recommendations. The author's perspective and analytical framework are transparent throughout, with clear attribution to Dominic Böttger. The piece appropriately mixes factual reporting (statistics, case studies) with analytical interpretation and prescriptive advice, which is suitable for the essay format. The genre conventions are respected—readers can distinguish between the factual foundation (industry data, research findings) and the author's interpretative framework and recommendations. The only minor limitation is that some analytical assertions are presented with declarative confidence that could benefit from more explicit framing as interpretative judgments rather than established facts, but this does not fundamentally undermine the separation principle given the clear essay format.
Very Good
The article maintains complete respect for personality rights throughout. Named individuals (Addy Osmani, Dave Farley, Nicole Forsgren, Jez Humble, Gene Kim) are referenced only in professional contexts with appropriate attribution and without any inappropriate personal details or defamatory content. The case studies (Kiro, Moltbook, Grigorev, Anthropic) focus on organizational and technical failures rather than personal blame. No private information is disclosed, and all references to individuals serve legitimate informational purposes within the professional discourse. The treatment is consistently dignified and appropriate, with no boundary transgressions in either textual or contextual representation.
Not Applicable
The article does not report on investigative proceedings, criminal proceedings, or formal accusations against identifiable individuals. The text discusses technical failures and organizational challenges in software development but does not center on allegations of wrongdoing by specific persons. The case studies mentioned (Kiro, Moltbook, etc.) describe system failures rather than attributing guilt to individuals. Since no persons are subject to allegations or proceedings that would engage the presumption of innocence principle, this criterion is not applicable to the content.
Not Applicable
The article does not center on identifiable persons or groups in a way that would engage discrimination concerns. The text discusses software development practices, AI tools, and organizational processes without targeting any protected characteristics or groups. References to "developers," "teams," and "senior engineers" are purely professional role descriptions without any stereotyping or stigmatization based on age, gender, ethnicity, disability, or other protected characteristics. Since no persons or groups are the subject of reporting in a manner that could involve discriminatory treatment, this principle is not applicable to the content.
Context: Opinion Journalism / Editorial
This article employs active persuasion through a combination of data-driven analysis, professional authority, and strategic framing to advocate for specific software development practices. The factual foundation is strong, with well-sourced industry statistics and case studies supporting the core thesis. The argumentation is logical and structured, moving systematically from problem identification through solutions. However, the presentation is clearly positioned rather than neutral — the author uses moderate emotional appeals (catastrophe examples), evaluative language, and conceptual framing (Nyquist-Shannon theorem, conveyor belt metaphor) to guide readers toward predetermined conclusions. The intent is transparent: this is professional advocacy for DevOps principles and quality-first AI integration. The recommendations are advisory rather than coercive, respecting reader autonomy while making strong cases for specific practices. The piece functions as expert commentary that persuades through reasoned argument rather than manipulation, though it clearly aims to change reader behavior and beliefs about AI coding practices.
Accurate
The article presents predominantly verifiable facts with proper sourcing. Key statistics (22% AI-generated code, 1.7x more issues in AI code, 20% increase in PRs) are confirmed by external research from DX, CodeRabbit, and industry sources. The Addy Osmani reference is partially accurate (he wrote about the 80% problem, though his title differs slightly). The Rakuten case study is fully confirmed. One claim about Salesforce moving 90% of engineers could not be verified. The article properly cites sources (GitClear, CodeRabbit, paddo.dev, Dave Farley) and distinguishes between measured data and anecdotal examples. The technical analysis of AI coding challenges aligns with documented industry trends. Minor unverified claims do not undermine the overall factual foundation.
Representative
The article presents a focused but representative view of AI coding challenges. It acknowledges both benefits (speed gains, productivity improvements) and problems (quality issues, review bottlenecks), avoiding pure one-sidedness. Multiple perspectives are included through various industry sources and case studies. However, the presentation emphasizes problems over solutions and focuses heavily on the risks without equally exploring successful AI integration strategies. Alternative explanations for productivity gaps (learning curves, tool maturity) are mentioned but not fully developed. The article provides substantial context about DevOps history and testing frameworks, though some counterarguments from AI tool vendors or success stories receive less attention. The framing is clearly pro-quality-assurance rather than neutral reporting.
Supplementary
The article uses moderate emotional elements to supplement its technical arguments. Phrases like "AI writes faster than your shadow" and "Lucky Luke shoots faster than his shadow" create urgency and memorability. The catastrophe examples (Kiro's 13-hour outage, Moltbook's leaked API keys) are presented with some dramatic emphasis to illustrate consequences. However, these emotional elements serve primarily to reinforce factual points rather than manipulate readers. The tone remains largely analytical and professional, with technical depth dominating over fear-mongering. The author's frustration with teams ignoring DevOps principles is evident but expressed through reasoned argument rather than inflammatory rhetoric. The emotional appeals are present but clearly secondary to the data-driven analysis.
Positioned
The language is professional and technical but clearly positioned. The author uses evaluative terms like "radical change," "fundamental misjudgment," and "uncomfortable truth" to signal strong convictions. Rhetorical devices include the recurring Lucky Luke metaphor, the Nyquist-Shannon theorem analogy, and strategic repetition of key concepts ("guardrails," "sampling rate," "conveyor belt"). The text employs some absolute expressions ("no exceptions," "must under no circumstances") when discussing security boundaries, though these are justified by technical necessity rather than rhetorical manipulation. The author's position as an experienced practitioner is evident in phrases like "I observe this in my daily work" and "I have had to experience." No dehumanizing language or enemy images are present. The tone is assertive and prescriptive but maintains professional standards and avoids polarizing rhetoric.
Moderate
The article employs clear but moderate framing through multiple techniques. The title "AI Writes Faster Than Your Shadow — Now What?" immediately frames AI speed as a challenge requiring response. The Nyquist-Shannon sampling theorem provides a conceptual metaphor that frames code review as a signal processing problem, making the technical issue more comprehensible. The "conveyor belt" metaphor frames AI output as overwhelming human capacity. The text follows a problem-solution narrative arc (data → problems → catastrophes → solutions), which guides interpretation but remains transparent. The framing emphasizes systemic process failures over individual blame. Some dualistic patterns appear ("heroic acts" vs. "systems," "ceremony" vs. "constraint") but serve analytical clarity rather than manipulation. The author's perspective is evident but not totalizing — alternative approaches are acknowledged even when critiqued. No significant recontextualization or stigma-label framing is present.
Sound
The argumentation is predominantly logical and well-structured. The thesis is clear: AI code generation requires fundamental process changes, not just tool adoption. Claims are systematically supported with data (industry statistics), analogies (Nyquist-Shannon theorem), case studies (Kiro, Moltbook, Rakuten), and expert sources (Dave Farley, paddo.dev). The logical progression moves from problem identification → quantification → explanation → solutions. Causal claims are generally well-supported (e.g., review time increases linked to AI code characteristics). Minor logical gaps exist: the correlation between AI adoption and quality metrics could have alternative explanations (team maturity, implementation approach) that receive limited exploration. The article occasionally presents strong recommendations ("must," "no exceptions") based on case studies rather than comprehensive evidence, but these are clearly marked as the author's professional judgment. No major logical fallacies are present. The argumentation is sound and evidence-based with transparent reasoning.
Open
The author's intent is clearly recognizable and honestly communicated. The article is explicitly positioned as professional commentary from a practitioner ("I observe this in my daily work with teams and companies"). The author's advocacy for DevOps principles and quality-first approaches is transparent throughout. The piece is clearly labeled as a blog post with the author's name prominently displayed. The author discloses their professional perspective and experience base. Potential conflicts of interest are not explicitly addressed (e.g., whether the author consults on the tools/frameworks mentioned), which prevents a perfect transparency score. The persuasive intent — to convince readers to adopt specific development practices — is evident and not disguised as neutral reporting. The recommendations clearly reflect the author's professional philosophy, which is presented openly rather than hidden behind false objectivity.
Advisory
The article contains clear recommendations with advisory rather than coercive tone. The "What You Can Do Tomorrow" section provides specific, actionable steps (enable code reviews, write tests, check hooks, write CLAUDE.md files) with reasoning for each. These are framed as professional advice rather than ultimatums. The language uses "should" and "must" in technical contexts (security requirements) but maintains reader autonomy in implementation decisions. No time pressure, social pressure, or threats are employed. The consequences of inaction are presented through case studies (catastrophes) but without manipulative fear-mongering. The recommendations respect that readers will make their own decisions based on their context. The calls to action are direct and prescriptive but remain within professional advisory norms. The author advocates strongly for specific practices but does not undermine reader autonomy or present false dichotomies about consequences.
The author's intent is to persuade software development teams and leaders to fundamentally restructure their development processes in response to AI code generation. This is professional advocacy grounded in the author's consulting experience and observations. The intended effect is behavioral change: readers should adopt automated testing, implement CI/CD guardrails, restructure code review processes, and embrace DevOps principles. The article aims to create urgency around quality issues while providing actionable solutions. The persuasive strategy combines authority ("I observe this in my daily work"), data (industry statistics), analogies (Nyquist-Shannon theorem), and case studies (catastrophes) to build a compelling case. The effect on readers is likely to be consciousness-raising about AI coding risks and motivation to implement recommended practices, particularly among those already concerned about code quality. The article may also reinforce existing beliefs among DevOps advocates while challenging teams that have adopted AI tools without process changes.
Several factors mitigate the persuasive influence. The article is clearly labeled as a blog post with the author's name and publication date visible, establishing it as personal commentary rather than objective reporting. The genre conventions of technical blogging allow for stronger advocacy and prescriptive recommendations than would be appropriate in news journalism. The author's professional expertise and consulting background are disclosed, providing context for the perspective. The factual foundation is strong and well-sourced, meaning the persuasion rests on verifiable data rather than manipulation. The technical depth and specificity (mutation testing, contract testing, specific tools) indicate genuine expertise rather than superficial advocacy. The intended audience appears to be professional software developers and technical leaders who can critically evaluate the recommendations based on their own experience. The transparency of intent — this is clearly advocacy for specific practices — allows readers to engage with the arguments on their merits rather than being deceived about the author's purpose.
The author's professional authority and consulting role create an asymmetric credibility dynamic — readers may defer to expertise rather than critically evaluating claims. The catastrophe examples (13-hour outages, leaked API keys, destroyed databases) create emotional pressure that may override rational cost-benefit analysis of AI adoption. The framing of AI coding as a "conveyor belt" problem and the Nyquist-Shannon analogy, while illuminating, also constrain how readers conceptualize the issue — alternative framings (learning curve, tool maturity, organizational adaptation) receive less attention. The article's length and technical density may create cognitive load that reduces critical engagement, particularly in the solutions section where specific tools and practices are recommended. The "What You Can Do Tomorrow" section, while helpful, may create implementation pressure without adequate consideration of organizational context or resource constraints. The strong language around security ("no exceptions," "under no circumstances") may extend beyond technical necessity into rhetorical emphasis. The article's positioning within the broader AI hype cycle may amplify its influence — readers concerned about AI risks may find confirmation bias, while AI enthusiasts may dismiss valid concerns.
Author information not available
Analysis created with decipher – Open interactive version