Engineering teams are tearing themselves apart because AI accelerationists and reliability preservationists are both right about existential threats — but organisations lack the feedback loops to reconcile speed with safety.
Charity Majors' framing — enthusiasts race against market time, skeptics race against systemic entropy — cuts through the polarisation to reveal a genuinely hard organisational problem. Neither faction is wrong, and designing feedback loops to mend the gap in shared reality between them is a first-order leadership challenge.
Both sides face real existential threats. Enthusiasts aren't wrong: teams leaning into AI see discontinuous capability leaps, and waiting for dust to settle could mean extinction[1]. Skeptics aren't wrong either: shipping code nobody fully understands erodes reliability, evaporates institutional knowledge, and grinds up on-call rotations[1].
There is no natural feedback loop connecting the two groups. This is the crux. Enthusiasts and skeptics often share the same teams but operate in separate realities — one driven by demo-able wins, the other by incident post-mortems. Without deliberate bridging mechanisms, teams polarise rather than integrate[2].
This cycle is structurally different from previous tech shifts. Majors explicitly distinguishes this from a normal technology cycle where you can wait for clarity. The competitive urgency is real; so is the entropy risk. The tension is not resolvable by picking a side — it requires organisational design that holds both truths simultaneously[1].
The leadership challenge is to build shared reality. Simon Willison identifies 'mending the gap in shared reality' as the fascinating organisational design problem embedded in Majors' piece[2]. This implies structured forums, cross-functional metrics, and deliberate communication rhythms.
"The enthusiasts are not wrong. We are starting to see real, non-imaginary, discontinuous leaps in capabilities from teams that lean in hard to working with AI."
— Charity Majors[1]"The skeptics are also not wrong. When you ship code faster than engineers can read it, in domains where nobody has full context, you are making withdrawals from a trust account that took years to build."
— Charity Majors[1]"There is no natural feedback loop connecting enthusiasts with skeptics."
— Charity Majors[1]"Designing feedback loops to help 'mend the gap in shared reality' between the two groups is a fascinating organizational design problem."
— Simon Willison[2]
✓ VERIFIED — Charity Majors is co-founder and CTO of Honeycomb (observability platform), and writes charity.wtf Substack. Background in engineering leadership at Parse/Facebook. Known authority on reliability engineering and organisational dynamics. source
⚠ UNVERIFIED — The claim that teams sitting out AI risk 'could be out of business before the dust settles' is a predictive assertion about competitive dynamics — plausible but untestable at time of writing.
⚠ UNVERIFIED — The claim that AI is producing 'discontinuous leaps in capabilities' is an empirical claim dependent on team context and measurement. Majors does not cite specific examples in the quoted excerpt.
For CTOs and engineering VPs: Your job is not to pick a side but to build the connective tissue between them. Assign a senior leader to own the enthusiast/skeptic reconciliation process. Fund both rapid prototyping sprints AND reliability SLOs.
For engineering managers: Create explicit feedback loops — joint post-mortems that include AI-assisted code paths, pair programmers from each camp on the same features, and use observability data as a shared language rather than a weapon.
For individual contributors (enthusiasts): Your velocity gains are real — document them with before/after metrics that skeptics can verify. Build your case in terms skeptics respect: test coverage, incident rates, MTTR.
For individual contributors (skeptics): Your reliability concerns are valid — quantify the entropy. Measure code churn, review throughput, and knowledge bus-factor. Present degradation curves rather than generalised worry.
Source credibility: High — Charity Majors is a respected observability/engineering leadership figure (CTO of Honeycomb). Simon Willison is a trusted AI commentator with a track record of grounded, non-hyped analysis. Both have strong reputations in the software engineering community.
Claim verifiability: 1 of 3 claims directly verified (background of author via external source); 2 claims are predictive/context-dependent and untestable.
Potential biases: Majors' background in observability (Honeycomb) may incline her toward reliability-centric framing. Willison's enthusiastic but critical engagement with AI may incline him toward the middle ground. Neither seems to have material incentive to distort.
Quality flags: None — clear, coherent, well-structured writing from both authors.
Confidence in synthesis: High — the source material is concise, the argument is well-framed, and the implications are actionable.
Steelman critique: The framing itself may be the problem — by legitimising both sides as equally existential, it risks creating a false equivalence that paralyses decision-making. In reality, the organisations that succeed will be those that make a clear bet on one vector (aggressive AI adoption with tolerated chaos, or deliberate speed with reliability guardrails) rather than splitting the difference. Half-measures could produce neither speed nor reliability.
What would need to be true: For this critique to be valid, we'd need evidence that hybrid approaches consistently underperform single-thesis strategies in fast-moving AI adoption cycles, and that feedback loops between the two groups produce pathological compromise rather than productive synthesis.
[1]: [Charity Majors, original essay] "AI enthusiasts are in a race against time, AI skeptics are in a race against entropy" — charitydotwtf.substack.com
[2]: [Simon Willison, link post] "AI enthusiasts are in a race against time, AI skeptics are in a race against entropy" — simonwillison.net/2026/Jun/4/
[3]: [External verification] Charity Majors profile — honeycomb.io/team
Generated by OmniMiner v7.2 · openai/gpt-oss-120b · 2026-06-17