Charity Majors, CTO of Honeycomb, argues that AI adoption forces teams to finally implement foundational engineering practices—instrumentation, tracing, and deterministic processes—rather than bypassing them.
She emphasizes that non-determinism requires more discipline, not less, and that organizations expecting AI to automate away maintenance or legacy problems without this groundwork will not succeed.
While AI has solved some categories of software (personal productivity apps), hard problems remain wherever software failure affects physical systems or user trust demands stability.
What happened
In a conversation with RedMonk analyst James Governor, Honeycomb co-founder Charity Majors argues that AI adoption requires teams to first complete foundational engineering work—instrumentation, documentation, and deterministic processes—rather than enabling shortcuts. Majors contends that non-determinism demands more discipline, not less, and that agents in production are finally forcing teams to do the instrumentation work (particularly traces as a product decision) they should have done years ago.
Why it matters
Organizations expecting AI to solve software maintenance or legacy code problems without this groundwork will fail to capture its benefits. Majors frames this as an enforcement mechanism: every CEO wanting AI capabilities must first "eat their broccoli"—implement proper engineering discipline and bring observability to the level required for AI systems to operate safely. For teams building systems where failures affect the physical world (medical, infrastructure, finance), the stakes are especially high; user trust is built through stable, predictable systems, not generated code that moves goalpost automatically.
What to watch
Majors identifies persistent hard problems AI has not solved: database migrations, systems with strict user expectations (e.g., Slack, where UI stability matters), and any software where the digital realm directly affects atoms or molecules. She notes that code is now cheap, which should enable new artifacts and architecture-first thinking—but only if teams have first invested in the discipline (what she references via Dora and space industry standards) that makes such leverage safe.
James Governor and Charity Majors discuss how AI is reshaping engineering practices, with Majors emphasizing that organizations cannot extract value from AI without first implementing foundational engineering rigor. Majors observes that change budgets are so constrained by AI initiatives that most organizations have essentially given up on improving observability, resigning themselves to the traditional three-pillar approach (metrics, logs, traces) even when they know their implementations are weak.
Majors argues that the next frontier is "knitting together determinism and non-determinism"—and that AI, paradoxically, is finally forcing teams to invest in instrumentation and tracing work they should have prioritized years ago. She frames this as a positive: agents in production are a forcing function that compels proper observability. However, she cautions that non-determinism requires more engineering discipline, not less. Drawing on references to Dora metrics and aerospace industry standards, she insists that "every CEO wants their shiny, fancy AI cookies. Well, discipline comes first, then you get cookies."
Governor and Majors reference Chad Fowler's recent writing on "Phoenix architectures"—building on Fowler's earlier coining of the term "immutable infrastructure" in 2013. Majors explains that Fowler's key insight is that code is not the source of truth; the system is. This has been miserable to work with historically because teams have had to discover system contracts and edge cases by breaking them. But with the economics of code reversed—code is now cheap to produce—organizations should be able to generate code from architecture and specifications, provided they have first invested in documenting those specs and understanding system behavior through observability.
Majors acknowledges caveats: database migrations and other gnarly technical problems are still genuinely hard, and generating code from specs is not a solved problem. She also distinguishes where AI has genuinely succeeded from where it hasn't. Personal productivity apps and toy projects are solved. But for systems with high expectations—anything a billion users depend on, or anything where digital failure affects atoms (medical devices, infrastructure, financial transactions)—hard problems remain. User trust is built through stable friction, not through constantly changing AI-generated interfaces. The last year of AI hype, she argues, has been almost entirely aimed at individual productivity, when the hard useful work is always about software development as a team sport—and that requires organizational discipline and shared commitment to engineering values, not clever shortcuts.
Majors's argument inverts the common narrative about AI as a labor-saving shortcut. Rather than automating away engineering rigor, she sees AI adoption as a constraint that _enforces_ rigor. Teams with poor documentation, knowledge locked in people's heads, and weak observability will not be able to extract value from AI systems—and worse, deploying AI without that foundation creates new risks. The framing of non-determinism as requiring _more_ discipline, not less, directly contradicts the year's dominant hype, which has emphasized ease and speed over reliability.
Majors also references Chad Fowler's Phoenix architectures and the idea that the system—not the code—holds the truth about how software behaves. This reframes the economics of code generation: if code is now cheap to produce, the real leverage comes from architecture and specification, which in turn require the instrumentation and observability discipline that AI can now help enforce. The analogy to the shift from handcrafted servers to cattle in the cloud era is apt: both shifts feel disruptive until organizations internalize new practices.
The key reservation Majors voices is about scope. AI has genuinely solved narrow categories of software—personal productivity apps, toy projects—but the edges where stakes are high (user trust, physical safety, system persistence) remain hard. This distinction matters for business leaders evaluating AI ROI: the hype has been aimed almost entirely at individual productivity, while the durable work is always about software development as a team sport, requiring organizational alignment and shared discipline.
AI-summarized, only the topics you pick — one digest a day via Email, Slack, or Discord.
Free · takes 30 seconds · unsubscribe anytime
Ask AI anything about this article. Q&As are published on this page for other readers too.
The AI news that matters, in one minute each morning.
Sign up free