AI Demands More Engineering Discipline, Not Less

If you were around for the transition from treating servers like handcrafted "pets" to adopting immutable infrastructure, the current atmosphere probably feels strangely familiar.

Addressing the Noise

Recently, I published a piece discussing the divergent paths of AI enthusiasts (racing against time) and AI skeptics (racing against entropy). I have a massive backlog of AI topics I intend to explore:

However, the feedback on my last post was so voluminous that I need to clear the air before moving forward. The responses generally fell into two camps: technical merits and ethical concerns.

Some readers misinterpreted my arguments, thinking I was suggesting that developers should ~~abandon code review~~ and simply blast their lowest-quality code directly into production. I was not.

The Evolution of "Slop"

I chose that specific example for a reason. Let's look at the timeline of AI code quality:

Era	Perception of AI Code	Technical Reality
Early 2025	"AI code is just slop."	This was the mainstream, reasonable default.
Post-Opus 4.5	"Wait, this is actually usable."	AI reached the quality of the median software engineer for common patterns.
Mid-to-Late 2025	"It's an agentic tool."	The rise of `agentic harnesses` (LLMs in loops with tools), MCPs, and function calling.
End of 2025	"General purpose usability."	The wave crested; the tools became truly functional.

The enthusiasts were shouting that this was coming faster than we realized. As it turns out, they were correct.

The Reliability Perspective

Coming from a reliability background, my colleagues and I are generally quick to adapt. We have a certain unwholesome zest for diving into disgusting technical disasters—mostly because they make for great campfire stories later.

However, we sometimes struggle to admit that progress is real. We tend to focus on the remaining bugs and edge cases, forgetting that huge portions of the problem space have been effectively solved.

The Exponential Curve

The jump from "total garbage" to "surprisingly competent" happened with startling speed. While "I'll believe it when I see it" is a fair stance the first time, it becomes a liability the second time.

I want to avoid the typical, sweeping clichés like ~~"it was never X"~~ or ~~"the future belongs to xyzzy"~~ 🤮. My claims are specific and contextual.

The Economic Inversion of Code

In 2025, the fundamental economics of software production were flipped. We can represent this shift as:

$\text{Cost of Code Generation} \to 0$ $\text{Speed of Production} \to \infty$

Code shifted from being a treasured, curated asset to being disposable and regenerable almost overnight.

The "Meat Brain" Problem

Historically, we understood software by writing it. We relied on a "shared understanding" among the team.

"The real product of a software team is shared understanding."

This understanding is stored as a form of cache in our fragile little meat brains. Because our interdependence is so high, software engineering became a deeply collectivist effort, sensitive to emotional dynamics and fairness.

But humans are flawed containers:

We miss tiny details.
We get bored by repetition.
Our mental models diverge from the actual reality of what the user experiences in production.

The Engineering Solution

Ultimately, the gap between our mental model and production is an engineering problem.

At Honeycomb, we issued our AI mandate last August. As a devtools company, we are expected to operate at the bleeding edge of technology. I had seen enough evidence to know that the shift was inevitable, and the responsible move was to lean in.

Charity Majors