Episode Summary
Executive Summary: Charity Majors argues AI is already reshaping software engineering, but not in a simplistic “faster coding” way: the real shift is toward shipping code you haven’t read, backed by stronger testing, telemetry, and operational discipline. She says the industry is splitting into AI enthusiasts and skeptics, both with real concerns, and that the path forward is to couple wins with costs, own the loop, and optimize for better outcomes—not just speed.
Main Topics: AI is changing software from deterministic to non-deterministic work: Charity frames AI as a fundamentally different kind of tool because it produces variable outputs and requires new trust mechanisms. The key shift is not whether AI will be used, but when engineers will be comfortable shipping code they did not personally read. Reliability, ops, and QA become more central: She argues software engineers have historically overvalued code in the repo and undervalued production reality. AI makes ops-style validation, QA practices, telemetry, and conformance testing more important because trust must be rebuilt after generation. AI camps are both partially right: Charity describes two groups: AI-pilled enthusiasts seeing real productivity gains, and skeptical operators seeing reliability regressions, slop, and more on-call pain. She stresses that neither side is making it up, and they need to talk to each other more. Code review is overloaded and may need to be decomposed: She separates useful review activities—architecture, product intent, API design—from lower-value syntax nitpicking and bug-hunting that could be replaced by tests, tooling, or AI validation. The goal is better human use of attention, not elimination of collaboration. Observability must evolve for AI systems: Honeycomb’s approach emphasizes richer telemetry, spans, traces of traces, and Timeline for multi-agent workflows. Charity says agents need relationship-rich data, not noisy exhaust, and that instrumentation should be built into the development loop. Career advice: stay close to AI, and for leaders, go back to hands-on work: Middle managers should consider returning to IC work if needed, and anyone without AI experience should get it onto their resume quickly. Juniors remain valuable and will be okay if companies hire them; leaders must stay hands-on and understand production. Human judgment, communication, and respect still matter: Charity argues AI should not be used to shift cognitive or communication burden onto other people. Slop is disrespectful when it costs the recipient more time than it saved the sender, so teams should set norms and experiment intentionally.
Key Arguments: The central question is not whether engineers will ship code they haven’t read, but when—and the industry should prepare for that reality now. AI increases the need for discipline: better tests, evals, conformance testing, telemetry, and production feedback loops, not less. Software engineers have over-identified the source of truth as the repo; production is part of development, not a postscript. Code review is too overloaded to remain a single catch-all practice; product decisions, API design, and teaching should be separated from rote diff checking. AI-generated output often transfers work from the sender to the recipient; if a human wouldn’t read it first, it is probably slop. Both AI enthusiasm and AI skepticism are grounded in real experiences—productivity gains on one side, reliability degradation on the other. Observability should be treated as a product and governance concern, especially as agentic systems require richer context than logs and metrics alone. Middle managers need to remain technically current; leaders who lose touch with delivery and production will be less effective in an AI-shaped org. Junior engineers will still matter because talent and learning capacity are visible in practice, and organizations that hire and mentor them will benefit. The best response to AI fatigue is local agency: teams should define experiments, norms, and guardrails instead of waiting for top-down permission.
Data Points: Parse rewrite duration: 2 years - Charity describes a painful rewrite of Parse’s API from Ruby on Rails to Go. Original API build time: 6 months - Time spent writing the original Ruby on Rails API at Parse before the rewrite. Honeycomb/Parse scale: over 1 million mobile apps - She cites the scale of apps hosted on Parse by the time she left. Reliability decline window at Intercom/Finn: 18 months - She references a published post showing reliability and code quality went down for 18 months before beginning to recover. Twitter/X staffing comparison: ~60 engineers vs. 1700 before - Used to illustrate how much smaller the core engineering team became under current leadership. Meta severity events: many Sev Zeros over about 2 months - She says Meta experienced a flurry of highest-severity incidents recently. AI review volume at Spotify/Anthropic example: 4,500 changes per day per week - Mentioned as a reported shipping-speed metric in an Anthropic/Spotify engineering discussion. Resume scoring variance: 66 to 90 points - A local model-based ATS/resume scorer was said to return very different scores for the same resume across repeated runs. Hiring threshold for ATS example: 85 points - She notes companies often set 85 as the pass bar, making the variance operationally meaningful. Old observability book length: 250 pages - The first edition of Observability Engineering. New observability book length: 600 pages - She says the second edition is a major rewrite, nearly 2.5x longer. Book structure: 6 parts - The second edition is organized into six parts spanning AI, instrumentation, use cases, and governance. Buildkite scale: 1.4 billion job minutes a week - Used in sponsor copy to describe CI scale and reliability needs under AI-driven commit volume.
Pivotal Quotes: "the question is not if we will stop reading code written by AI, but when" — Charity Majors: Her thesis on the inevitability of AI-generated code entering mainstream engineering workflows. "there is no human in the loop. You own the loop." — Charity Majors: Her point that engineers remain accountable for AI-assisted work and cannot outsource responsibility to the model. "Production is not what happens after development, it is a stage of development." — Charity Majors: Her argument that software quality must be validated in production reality, not only in the repo.
Implications: Teams should invest in tests, evals, observability, and production feedback loops now, while leaders stay hands-on and set clearer norms. AI will raise the bar on engineering discipline and make reliability, not raw speed, the differentiator.