A year ago, doubting artificial intelligence in software engineering was a defensible position. Now, according to Charity Majors, CTO and co-founder of Honeycomb, that skepticism has become a liability rather than a badge of rigor. Her shift in view did not happen overnight, and it says something broader about how fast the tooling around AI-assisted coding has matured.
From Grumbling to Grudging Acceptance
Majors recalls telling an audience at SREcon in March 2025 to try "vibe coding" - writing software with heavy AI assistance rather than typing every line by hand. The reaction, by her account, was grumbling. Her argument then was practical rather than evangelical: engineers who dislike a technology should still learn to use it, because informed criticism carries more weight than reflexive dismissal. At that stage, she compared AI's likely impact to a new programming language - significant, but not necessarily generational.
Her thinking changed by November 2025. She points less to the underlying model, Opus 4.5, and more to the surrounding infrastructure - specifically Claude Code, the coding harness built around it. In her assessment, harnesses evolved from something resembling a shell script into serious infrastructure in their own right. That shift in tooling, not just model capability, is what moved her from cautious observer to someone comparing the moment to the arrival of cloud computing around 2010, when it became obvious the infrastructure layer of the industry was being permanently rewritten.
Why the Old Doubts Made Sense
Engineers who stayed wary of AI through 2025 were not being irrational. The software industry has a long memory of technologies pitched as transformative that ultimately underdelivered - COBOL was once sold as a tool that would make professional programmers unnecessary, neural networks cycled through hype and disappointment for decades, and no-code and low-code platforms promised to flatten the need for engineering expertise without fully doing so. Given that track record, treating each new claim with caution was a reasonable default, not a failure of imagination.
What Majors argues has changed is the economics underneath the code itself. Historically, writing software from scratch cost more than editing what already existed, which is why codebases accumulated patches rather than rewrites. Generating many variants of a function can now be faster than writing one version by hand. She draws a direct parallel to what happened in infrastructure during the 2010s, when servers stopped being individually repaired - treated as "pets" - and became disposable, recreated instances managed through tools like Terraform and Kubernetes - "cattle." She suggests code may be heading toward the same pattern: when something breaks, regenerate and verify, rather than debug by hand.
Verification Becomes the New Bottleneck
If AI is writing more of the code, trust shifts elsewhere in the pipeline. Majors is blunt about where she thinks that trust needs to move: toward testing, evaluation, and conformance checking, rather than toward manual code review, which she considers the least valuable part of what humans contribute to engineering. Her reasoning is that people are better suited to deciding what should be built than to scanning lines of code for syntax errors and logic bugs.
This reframes two decades of DevOps culture, which she considers only half successful. The push to get operations teams writing code worked. The parallel goal - getting software engineers to genuinely understand how their code behaves once it reaches production - has not, in her view, been achieved. Non-deterministic, AI-generated systems raise the stakes on that gap, because reduced certainty about how code was written has to be offset by stronger verification elsewhere.
Career Pressure and the Cost of Standing Still
For engineering leaders and individual contributors alike, Majors frames this as a moment demanding action rather than caution. She distinguishes anxiety from excitement by pointing to agency: people with more control over a situation tend to experience change as opportunity rather than threat. Her advice to anxious managers is to consider stepping back into hands-on technical work, where that agency is more immediate.
She is equally direct about the job market implication - that AI experience is fast becoming a filter in hiring decisions. At the same time, she resists a one-sided narrative. Neither uncritical enthusiasm nor blanket rejection captures what is actually happening: real productivity gains exist alongside real costs, including fatigue from reviewing AI-generated output and exhaustion from constant hype cycles. Her own team addresses this with a simple structural fix - no AI tools on Wednesdays - a small, deliberate way of retaining control rather than a solution to the underlying tension.