Stop being skeptical about AI for development with Charity Majors

Gergely Orosz (interviewing Charity Majors, CTO/co-founder of Honeycomb) · article · 2026-08-12 Reader 🖥️

Agent Harness AI Backlash Emotional Impact of AI Work Agency Non-Deterministic Software Pull Requests & Async Code Review They Build It, You Run It Trust

AI skepticism about software development, though rational as recently as 2025 given the industry's track record of over-promised transformative technologies, has become irrational in 2026 because the model-plus-harness combination (Opus 4.5 running inside Claude Code) crossed a genuine, cloud-computing-in-2010-scale capability threshold — so the live question for engineers is no longer whether to adopt AI but how to build the validation discipline (tests, evals, conformance checking, observability) that makes shipping AI-written, unread code safe.

practical · mixed — A practical, action-directing piece (stop being skeptical; build validation systems; take small acts of control) delivered as Orosz's numbered-takeaways synthesis of a podcast conversation. It mixes personal narrative (Majors's own three-stage change of mind), analogical argument (cloud in 2010, pets-to-cattle), and flat assertion (contrarian one-liners on code review and DevOps) without much direct evidentiary support for any single claim. Note on source fidelity: the fetched content is Orosz's written takeaways article about the episode, not the full spoken transcript — several timestamped segments (e.g. 'Junior engineers' at 1:16:31, 'What effective leadership looks like' at 1:07:45) are listed but not summarized in the 13 takeaways, so this extraction reflects only the curated subset Orosz chose to write up.

Structure

Part	Role
Charity's own three-stage journey: March 2025 skepticism about generational impact, November 2025 turning point (Opus 4.5 + Claude Code), 2026 verdict that skepticism is no longer rational	evidence
The 2025-cloud-in-2010 analogy and the concession that pre-2026 skepticism was rational (citing COBOL, neural nets, no-code/low-code as prior failed promises)	context / concession that strengthens the claim by conceding its opposite was once reasonable
The 'pets to cattle' infrastructure analogy applied to code generation vs. editing	evidence / mechanism
Contrarian claims about code review and the 20-year failure of DevOps	reframing of what human engineering work is actually for, once AI writes the code
Non-deterministic systems need more discipline, not less (tests, evals, conformance testing)	conclusion / prescriptive core
Career advice to anxious engineering directors (agency, return to IC work, AI on your resume)	practical application to a specific audience
Both camps ('AI-pilled' and 'anti-AI') getting things right, AI fatigue, small acts of control, and the rule about not sending unread AI writing	qualification / call for honesty and restraint that tempers the piece's own pro-adoption thrust

Key terms

harness Agent Harness
The engineering layer wrapped around a model (Claude Code, specifically) that turns raw model capability into usable, serious infrastructure — Majors treats the harness, not the underlying model, as the variable that actually flipped her assessment of AI's generational significance.
pets to cattle
Borrowed from cloud infrastructure's 2010s shift (individually repaired servers vs. Terraform/Kubernetes-style disposable, regenerable instances), reapplied to code: instead of hand-editing broken code, generate new, verifiably-correct code to replace it.
non-deterministic systems
Software whose behavior/production process (AI-authored code, AI-run agents) is not fully predictable or human-verified line-by-line, requiring compensating discipline elsewhere in the pipeline.
AI-pilled / anti-AI
Majors's shorthand for the two camps in the adoption debate — not meant as an insult to either side; she explicitly says both camps are 'getting important things right.'
agency (in the anxiety/excitement pairing) Agency
The presence or absence of felt control over one's own situation, which Majors claims is the physiological differentiator between anxiety and excitement in the face of the same disruptive change.

Propositions

explicitIn 2025, it was rational to be skeptical about AI for software development; in 2026, it is not.conf: high
explicitBeing skeptical of AI doesn't require refusing to use it — skeptics should still learn AI tools because you can complain about them more credibly once you've used them.conf: high
explicitCharity's own turning point toward seeing AI as generational change came in November 2025, driven more by the coding harness (Claude Code) becoming serious infrastructure than by the underlying model (Opus 4.5) itself.conf: high
explicitAI's 2025 impact on the software industry is comparable in kind and scale to cloud computing's 2010 mainstreaming of the infrastructure layer.conf: high
explicitSkepticism about AI through 2025 was rational because prior technologies promising to transform software (COBOL, neural nets, no-code/low-code) had made similar promises and fallen short.conf: high
explicitcontestedIt is a matter of 'when,' not 'if,' that professional engineers will ship code to production that they have never read and do not understand, and engineering's job is to build the systems that validate that code so this can be done with confidence.conf: high
contradicts ←Generative AI Is Not Going To Build Your Engineering Team For You · p1 — Same author, ~2 years apart: here (2024) Majors argues AI-generated code 'cannot be trusted' and must be read line-by-line before committing; by 2026 she argues it's 'when, not if' engineers ship AI-written code to production that they've never read and don't understand — an explicit, self-acknowledged reversal of her own position as the harness/validation layer matured, worth tracking as her view evolving rather than a one-off inconsistency.
explicitSoftware may be undergoing the same 'pets to cattle' shift that infrastructure underwent in the 2010s: because AI can generate hundreds of variants of a function faster than a human can hand-write one, generating new verified code to replace broken code may become cheaper than repairing it.conf: high
explicitCode review is overrated and the least valuable part of what humans contribute to software engineering, because humans are good at conversation and deciding what to build, not at reading code to check correctness, syntax, and bugs.conf: high
supportsThe Pulse: Interesting AI coding stats from Cursor · p7 — Corroborates, with a normative argument for why the shift is appropriate, the same author's (Orosz's) own empirical finding that unreviewed-AI-commit share jumped from ~10% to ~40% in one month.
explicitTwenty years of DevOps failed: it succeeded at getting ops people to learn to code, but failed at getting software engineers to understand their own code running in production.conf: high
explicitBecause AI-written code reduces trust that would previously have been placed in the code (since a human no longer wrote or fully understands it), engineering discipline must increase elsewhere in the development process — specifically in validation, via tests, evals, and conformance testing — meaning non-deterministic systems require more discipline, not less.conf: high
supportsAI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy · p10 — Same practitioner's claim that AI raises rather than lowers the required discipline bar, restated here specifically for non-deterministic/AI-written systems.
explicitAnxiety and excitement are physiologically almost identical; the difference is agency, so anxious engineering directors should consider moves that restore their agency (e.g., returning to IC work) rather than staying in a position where they feel disruption is happening to them.conf: high
explicitAI experience is about to become a baseline hiring filter for engineers ('you'll be filtered out if you don't have AI experience'), and the window to move into a more agentic role (e.g., back to IC work) while this is still easy is closing.conf: high
explicitBoth the 'AI-pilled' and the 'anti-AI' camps are getting important things right; the fix for their mutual distrust is for both sides to tell the whole story, pairing every celebrated AI win with an honest account of its costs, since failing to do so makes skeptical coworkers look merely self-interestedly afraid of automation rather than legitimately concerned.conf: high
extendsAI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy · p1 — Reprises, nine months later and in a different venue (interview vs. essay), Majors's own earlier two-camps-both-right thesis from her essay already in the corpus.
extendsAI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy · p8 — Same 'tell the whole story, pair wins with costs' prescription, restated as a direct appeal to both camps in interview form.
explicitAI fatigue (reviewing AI slop, hype exhaustion, being worn down by 'doom trolling' from AI CEOs) is real, and small deliberate acts of withheld participation — e.g. Honeycomb's team-wide no-AI Wednesdays — are a workable way to take back a sense of control.conf: high
explicitNo AI-drafted message or email should be sent to a human without the sender first reading it in full, because if it would take the recipient longer to read than it took the sender to produce, it is probably slop.conf: high
implicitThe legitimacy of updating from 'skeptical' to 'not skeptical' rests on tracking the harness/tooling layer around a model, not just the model's raw capability — implying that AI-skepticism assessments should be re-run whenever the harness materially changes, not only when a new model ships.conf: medium
implicitTrust that was previously placed in the artifact (hand-written, human-understood code) is being relocated to the process that validates the artifact (evals, tests, observability) — an implicit shift from trusting authorship to trusting verification.conf: medium

Arguments

Continued blanket AI skepticism about software development was defensible through 2025 but is no longer defensible in 2026. strength: medium

Explicit premises:

Skepticism through 2025 was grounded in a real track record of over-promised, under-delivered transformative technologies (COBOL, neural nets, no-code/low-code).
Since November 2025, the model-plus-harness combination (Opus 4.5 in Claude Code) represents a genuine, generational capability jump, comparable in scale to cloud computing's 2010 mainstreaming.

Implicit premises:

A prior track record of failed transformative-technology promises justifies skepticism only until qualitatively new evidence appears, at which point the skeptic should update.
Charity Majors's own personal experience and professional judgment (a credentialed practitioner and industry voice) is sufficient evidence that the industry-wide threshold has, in fact, been crossed — not merely that it has been crossed for her personally.

Inferences:

If harness quality rather than raw model capability is the load-bearing variable, then evaluations of 'is AI ready for production software engineering' should be re-run whenever the harness materially changes, not just when a new model ships — meaning static skepticism ('AI isn't there yet') is itself methodologically suspect regardless of which direction it points.

Code review is overrated as a human contribution to software quality. strength: low

Explicit premises:

Humans are good at conversation and deciding what to build.
Humans are not good at reading code to check for correctness, syntax, and bugs (implied by contrast).

Implicit premises:

Automated or AI-assisted verification (tests, evals, conformance checking) can perform the correctness-checking job as well as or better than human review.
The primary value humans add to engineering is upstream (deciding what to build), not downstream (checking that it was built correctly).

Inferences:

If code review is deprioritized, the verification burden it informally carried must be absorbed by evals/tests/conformance checking — teams that cut review without building that replacement capacity are taking on pure risk, not making an even trade.
Junior engineers, who have historically learned to read and critique code partly through the review process, would need a different mechanism for that skill formation if review is deprioritized — a mechanism this document does not name.

Non-deterministic (AI-authored) software systems require more engineering discipline, not less. strength: high

Explicit premises:

AI-written code reduces the trust historically placed in code, because a human did not write it and may not fully understand it.
Discipline must therefore increase elsewhere in the pipeline — specifically in validation (tests, evals, conformance testing) — to compensate.

Implicit premises:

Overall system trustworthiness is roughly conserved: reducing trust in one component (human authorship) requires proportionally increasing trust-generating investment in another (verification) to hold reliability constant.

Inferences:

Teams that adopt AI coding without proportionally investing in verification infrastructure are running an undisclosed trust deficit, even if short-term code output looks acceptable.

Narratives

Charity's own three-stage change of mind: March 2025 (SREcon audience grumbles at her 'try vibe coding' advice; she's skeptical of generational impact), November 2025 (turning point via Opus 4.5 + Claude Code), 2026 (declares blanket skepticism no longer rational).
→ Implicitly supports the unity by modeling, in a credible practitioner's own dated timeline, the very update the article calls on the reader to make — used as personal evidence for the claimed industry-wide threshold, not merely as illustration.
The 'pets to cattle' infrastructure analogy: pre-2010s manual server repair versus the Terraform/Kubernetes-era practice of re-creating rather than fixing individual instances.
→ Supports the code-generation-over-editing claim by giving it a precedent that already succeeded at the infrastructure layer, implicitly arguing code is on the same maturation path infrastructure already completed.
Honeycomb's team-wide practice of not using AI on Wednesdays.
→ Supports the AI-fatigue-countermeasure claim by supplying a small, concrete, replicable practice as evidence that agency-reclaiming acts are actually implementable, not just a slogan.

Questions addressed

✅ Was AI skepticism about software development rational through 2025?
Yes — because prior transformative-technology promises (COBOL, neural nets, no-code/low-code) had repeatedly fallen short.
✅ Is AI skepticism about software development still rational in 2026?
No — because the harness/model combination crossed a genuine capability threshold in November 2025, comparable to cloud computing's 2010 mainstreaming.
⭕ What would it take for an engineer to be fully comfortable shipping code they have not read?
Named as the question engineers 'need to answer' and pointed at in general terms ('engineering is building the systems that validate this code'), but the article never specifies what those validating systems must actually guarantee — coverage thresholds, what evals catch versus miss, what 'comfortable' would look like in practice.
⭕ What is the right human role in an AI-heavy development workflow, if not code review?
Partially: humans should focus on conversation and deciding what to build, while verification shifts to automated systems — but the article doesn't address who validates the validators, or how junior engineers acquire the skills review used to teach them, despite the episode itself apparently covering 'Junior engineers' as a separate segment not summarized here.
✅ Why did 20 years of DevOps fail to connect engineers to their code's behavior in production?
Ops people learned to code (that half worked); software engineers never learned to understand their code running in production (that half failed).
✅ How should anxious engineering leaders respond to AI-driven disruption?
Increase personal agency — e.g., consider returning to IC work — while the window to do so easily is still open, partly because AI experience is about to become a baseline hiring filter.

Gaps

incompleteThe central prescriptive claim — engineers 'will' ship unread code to production, and this becomes safe once 'engineering builds the systems that validate this code' — never specifies what those validating systems must actually guarantee (coverage thresholds, formal verification, what evals reliably catch versus miss) to make unread code trustworthy. 'Comfortable shipping without reading' is asserted as an achievable target state without describing what achieving it looks like or how a team would know it had arrived.
Read next: Majors's own linked essay 'AI demands more engineering discipline. Not less' (charity.wtf) may operationalize the validation bar this interview leaves abstract; also relevant is this corpus's DORA AI Capabilities Model material on quality-platform capabilities.
incompleteThe 'code review is overrated' claim is offered as a contrarian one-liner with no supporting evidence (defect rates, incident postmortems, comparative studies of eval-only versus human-reviewed pipelines), and does not address what happens to junior engineers' skill formation if review — historically a primary mechanism by which junior engineers learn to read and critique code — is deprioritized. This gap is made sharper by the episode's own timestamps listing a 'Junior engineers' segment (1:16:31) that this takeaways article does not summarize at all.
Read next: The podcast's own 'Junior engineers' segment (unsummarized here); this corpus's systemic-apprenticeship material on skill transmission mechanisms.
incompleteThe call for both camps to 'tell the whole story' and pair wins with costs is asserted as the fix for AI-camp division, but no mechanism is given for why camps currently incentivized to trumpet wins publicly and bury costs privately would start doing so absent a structural change — the identical gap already identified in Majors's own earlier essay in this corpus (extract-ai-enthusiasts-time-skeptics-entropy#g2) recurs here, restated but still unaddressed nine months and one interview later.
Read next: extract-ai-enthusiasts-time-skeptics-entropy (same author, same unresolved gap).
illogicalThe 'pets to cattle' analogy assumes code can be treated like infrastructure — interchangeable, statelessly regenerable, verifiable via automated health checks — but code, unlike a server, typically encodes unique business logic and meaning. 'Verifiably correct' for a server means 'responds to health checks'; 'verifiably correct' for a business function is a much harder, domain-specific correctness problem that the piece never distinguishes from the infrastructure case it borrows its confidence from.
Read next: This corpus's changeability/optionality material on what AI-generated code systematically underdelivers on.
incompleteThe headline 'AI's 2025 was cloud's 2010' analogy is asserted on Majors's own authority ('comfortable saying this') without engaging any disanalogies — cloud's 2010 mainstreaming was driven by quantifiable cost/reliability economics (published SLAs, TCO comparisons), whereas this piece's claim that AI coding reached a comparable threshold rests on anecdote and personal conviction, not the kind of adoption data Orosz himself has published elsewhere in this corpus (e.g., Cursor's two years of usage statistics).
Read next: extract-pragmatic-engineer-cursor-ai-coding-stats (same author, quantitative data that could have grounded this analogy but isn't cited here).

Stop being skeptical about AI for development with Charity Majors

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents