Charity Majors, co-founder and CEO of Honeycomb, discusses how AI is reshaping software engineering, drawing on her background building Parse, working at Facebook, and creating Honeycomb’s observability platform. She argues the industry must stop debating whether AI will write production code and start defining what it takes to ship code no human has read — a shift comparable to when infrastructure moved from pets to cattle.
The limits of individual productivity metrics
Measuring individual engineer output misses what matters: team output. Goodhart’s Law applies — any metric becomes a target and loses signal.
Managers need data to back their judgment, but data alone is insufficient; context and bias awareness are essential.
AI is forcing the industry to ask earlier and more often: what does “good” look like? Speed is the easiest thing to measure, but it’s an immature proxy for quality, functionality, or user value.
How Charity’s perspective on AI has evolved
In March 2025, she and Fred Hebert keynoted SREcon urging engineers to try “vibe coding” — partly so they could complain more credibly. She saw AI as a major shift like cloud, but not yet generational.
By November 2025 (Opus 4.5 release), the tooling harnesses around models — not the models themselves — made the leap visible. People who had dismissed AI were trying again and changing their minds.
Skepticism was warranted: history is littered with “AI writes code” claims (neural nets, no-code, low-code). But the direction is now clear — the question is not if but when we’ll ship unread code, and what guardrails that requires.
Rewriting code vs. editing code
Chad Fowler’s “code is cash” thesis: immutable infrastructure replaced in-place server mutation; AI makes rewriting application code cheaper than editing it. Mutation accumulates entropy; replacement resets it.
Generating 10,000 function variants can be faster than writing one. This forces investment in evals and tests, shifting cost from maintenance to validation.
Hard rewrites (e.g., Parse’s 2-year Ruby-to-Go migration) reveal how poorly we capture contracts. Architecture diagrams that generate code to spec — an old dream (UML, Rational) — may finally be feasible because generation is cheap.
Production as a stage of development
Ops and QA have always focused on “what is” (validation, correctness in production); software engineering focuses on “what should be.” Engineering has been snobbish about both disciplines.
Production is not post-development — it is a stage of development. Code in the repo is partial information; behavior in production is the truth.
Deploying anytime without fear requires closing the feedback loop: merge → production → observe. UAT environments are a crutch; the goal is to make the train not stop.
Code reviews
Code review is hugely overloaded: product decisions, API design, mentoring, syntax/bug checking, compliance. Some parts are valuable human conversations; others (nitpicking, pattern enforcement) are better automated.
Intercom (now Fin) exemplifies high-discipline AI-native PRs: senior-engineer wisdom encoded in automated checks frees humans to discuss direction and coherence.
Reading unreviewed AI-generated diffs is disrespectful of reviewers’ time. If you haven’t read it, don’t send it.
Non-deterministic systems
Non-determinism demands more engineering discipline, not less: conformance testing, performance bounds, fuzz testing, behavioral suites. Trust debited at creation must be repaid in validation.
The goal: make AI boring. Corral non-deterministic agents into carved pathways where they’re a superpower, not a foundation-eroder.
Deterministic systems aren’t going away; the challenge is making the two play nicely together.
Sensible uses of AI at Honeycomb
Baseline norms: you own the loop — no “Claude said so.” You cannot send what you haven’t read. If it takes the recipient longer to read than you to generate, it’s slop.
Self-awareness: don’t ask questions AI could answer; don’t offload thinking that is your core job. Use AI to think more rigorously, not as a shortcut to avoid thinking.
Exceptions exist (non-native English speakers, neurodivergence) — the norm is respect, not absolutism.
The two AI camps
Two camps talk past each other: enthusiasts see speed wins and fear falling behind; on-call engineers see melting mental models, slop, and reliability regressions. Neither is making it up.
The disconnect often maps to who carries the pager. Meta’s Sev-0 spike (Instagram, WhatsApp) coincided with reliability-team cuts — a pattern echoed across companies.
Intercom’s data: 18 months of declining reliability before recovery began. Wins must be coupled with costs; otherwise each side assumes the other is irrational.
Why AI works so well for building software
Software and AI share the same substrate: logic and language. This enables baked-in guardrails, structured validation, and rich training data (code that compiles).
AI is far better at code than prose. Writing is thinking on paper — no shortcut exists. Code is a simplified, purpose-driven language where correctness is verifiable.
DevOps
DevOps emerged to heal the dev/ops wall (split brain: half write, half operate). It succeeded in making ops write code; it failed to make engineers truly own their code in production.
20 years of DevOps aimed for one feedback loop: code → production → insight. That loop remains broken — platform teams and feature teams operate in separate domains, which is a healthy separation of concerns, but engineers still lack fast feedback.
Modern observability: metrics/logs are system exhaust (cheap, high-volume, low-context). Your code’s telemetry should be a product decision — wide events with connective tissue, stored once, queried combinatorially.
Modern observability
Auto-instrumentation (OpenTelemetry) has made instrumenting faster than not instrumenting. Models are trained on common patterns; instrumentation becomes part of developer intent, declared and checked in production.
Spans (structured log subsets forming traces) are the new primitive. Transaction-based models break with AI: a single conversation may span hours, spawning agents that call APIs and storage. Honeycomb’s “Timeline” visualizes these meta-traces (traces of traces).
Agents need rich, relational telemetry — not raw logs/metrics that flood context windows. Successful AI SRE agents bypass observability stores and go upstream to intact telemetry.
Handling context overload
Traditional telemetry fills agent context with noise. The signal is in relationships between data points.
Pattern: give agents access to upstream, high-context telemetry (source of truth) rather than downstream aggregates.
What’s new in Observability Engineering 2nd edition
Full rewrite (600 pages vs. 250), six parts:
Running deterministic + non-deterministic systems
2-3. Instrumentation and understanding (with/without AI tracks)
4-5. Guest deep dives: frontend/mobile (Hanson Ho), CI/CD, ClickHouse columnar storage, Fin’s iterative observability
Leadership/governance (200 pages): open letter to CTOs on AI goals blocked by observability gaps, systems-theory delivery, quantifying observability as investment vs. cost center, staff+ driving change without authority (Rick Claus), build vs. buy vs. open source, vendor partnerships as durable skills.
What effective leadership looks like
Most effective: kind, caring humans who are skilled business operators.
Second: terrible humans who are skilled business operators.
Everyone else: good people who are sloppy operators. Being good at business is hard; if you don’t hold yourself to high standards, someone will impose them on you (Twitter/X case study: 60 engineers vs. 1,700, still running).
To set culture and ethics, you must first win at the business.
Engineering management: what is changing
Every leader must be hands-on: generate code, ship diffs, feel the PR process. No excuse not to — tooling makes it easier than ever.
Teams are shrinking; owning more surface area should be good, but not if driven by CEO fiat or layoffs.
Middle management is essential: sense-making, context-giving, helping teams understand what and why. AI can execute tasks; humans must frame the problem.
Understanding is fragile and hard to build — that’s the manager’s job.
Career advice for middle managers and directors
If you’re a middle manager: go back to being an IC for a while. Get AI on your resume — it’s a career risk not to. The longer you wait, the harder the catch-up.
Directors: anxiety and excitement are physiologically similar; the difference is agency. Run toward the wave. Own the transition: “I’m excited to be an IC again.” Talk about what you learn.
The job market for 2-3 year AI engineers is exceptional; those without face steep filtering.
Junior engineers
Hard to quantify junior value because we can’t quantify any engineer’s value — it’s vibes.
Kids are cooking: high schoolers building impressive things without knowing SDLC. They’ll invent workflows we haven’t imagined.
Hire them. Internships are low-risk, high-signal. Even if it doesn’t work out, the internship changes their trajectory.
AI fatigue
Multiple varieties: receiving slop, hype/doom-trolling (Cal Newport’s term for AGI fear-mongering by lab CEOs), family fear, social media overload.
Universal frustration = opportunity to reclaim agency. Propose bottom-up experiments: “No AI Wednesdays,” “no AI PR descriptions,” “one week off.” Report what worked.
Leaders don’t know what permission to give until teams show what works.
Book recommendations
Catastrophe Ethics (Travis Rieder): modern life implicates us in harm whatever we choose; no ethical framework avoids absurdity. Ethical integrity = educate yourself, listen inward, decide what suffering speaks to you — not performative rage.
More Everything Forever (Adam Becker): demolishes AI religion (singularity, effective altruism, accelerationism). Exponential growth must end (S-curve or crash). Life-extension obsession = oldest human fear of death. Dry humor, sharp critique.
