AI Makes Coding Easier. That's Exactly Why You Need More Discipline
There’s a comforting story making the rounds in developer circles: AI writes the code now, so engineering just got easier. Charity Majors — co-founder of Honeycomb and one of the loudest voices in observability — thinks that story is backwards. Her counter is blunt: AI doesn’t demand less engineering discipline. It demands more. Here’s why that counterintuitive take holds up.
A quick note on sourcing: this topic didn’t generate enough fresh community discussion over the past 30 days to lean on real-time reactions. So this piece is built on the arguments Majors has made consistently and where the industry is broadly heading, rather than this week’s hot thread.
Writing Code Was Always the Smallest Part of the Job
Here’s the core confusion: people treat software engineering as if it were the same thing as typing code. It never was. The hours spent actually writing code are a sliver of what the work involves.
So where does the rest go? Understanding what’s actually being asked for. Predicting how a system will break. Tracing the cause when it does. Confirming how the code behaves in production, not in your head. As Majors likes to put it, the real cost of software is maintenance, not authorship.
AI automates the easy slice — generating the code. The trap is that faster generation doesn’t shrink the work of verifying, understanding, and operating that code. It expands it.
More Code Means More to Answer For
The logic is simple once you sit with it. There used to be a natural ceiling on how much code one developer could ship in a day. AI coding tools blow straight through that ceiling. A few hours, and you’ve got a thousand-line feature.
Then comes the question that matters: did your speed at understanding that code go up too? No. The human pace of reading code and grasping why it works the way it does is roughly where it always was.
The result is that we keep pushing more and more code into production that nobody wrote by hand and nobody fully understands. And when something breaks at 3 a.m., “sorry, the AI wrote that part” is not a sentence anyone can use. Users don’t care who typed it. The engineer still owns it.
The Bottleneck Moved From Writing to Trusting
This is the sharpest part of Majors’ read. By dissolving the bottleneck of writing code, AI shifted the real constraint to your ability to understand and trust the code in front of you.
Which means a pile of practices that used to be filed under “nice to have” just got promoted to “non-negotiable.” Things like:
- Observability — actually seeing how code behaves in production
- Shipping in small increments, with the ability to roll back fast when something goes wrong
- Code review and automated tests as a safety net under your confidence
- Designing for failure, anticipating the ways a system breaks before it does
Before AI, you could limp along without much of this. A human wrote the code, so at least someone had a mental model of it. In an era of code nobody understands pouring in by the thousand-line, lose the safety net and you’re in free fall.
Senior Engineers Just Got More Valuable, Not Less
There’s a second irony worth sitting with. The dominant narrative is “AI replaces junior developers.” Follow Majors’ logic and you land somewhere close to the opposite.
The ability to look at AI-generated code and say “this is dangerous,” “this breaks here under load,” “this becomes an incident in production” — that comes from hard-won intuition. The more trivial it becomes to produce plausible-looking code, the more valuable the person who can doubt it and verify it becomes.
But there’s a real worry tucked in here. If juniors just crank out AI-generated code, they may skip the messy, fumbling experience that turns a junior into a senior. Judgment comes from people who’ve actually written and broken things. If AI lets the next generation skip that struggle, where do tomorrow’s seniors come from? That’s a problem the industry has to solve together, not wave away.
The Takeaway
Strip it down to one line: AI made writing code easy. It did nothing to make owning that code easy. If anything, as the volume of code nobody understands climbs, observability, testing, fast deploys, and clean rollbacks matter more than they ever did. The more powerful the tool, the higher the bar for the person wielding it.
So ask your own team the honest question. Are you just optimizing for cranking out code faster — or are you thickening the safety net that all that extra code now demands? The faster you go, the more worthwhile it is to stop and ask.
Comments
Loading comments...