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.
Summaries like this, in your inbox every morning.
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.
For example, today's edition would include:
AI-summarized, only the topics you pick: one digest a day via Email, LINE, or Slack.
Free · 30 seconds with Google · unsubscribe anytimeWhat is AIToday? →
Ask AI anything about this article. The AI reads this article, earlier AIToday articles, and Wikipedia, and cites its sources. Q&As are published on this page for other readers too.
