A couple of weeks ago, I had the pleasure of attending the AI Engineer World’s Fair. I stepped off the subway and made my way up the stairs toward Moscone West, nervous and excited. Finally — a few days to devote my full attention to sorting the real innovation from the hype. And I came with homework. As a daily AI user I had real problems I wanted answers to. Problems like not knowing my codebase as well as I would like. Pair programming no longer fits the workflow. Wondering how I keep building my engineering intuition when I’m writing less of the code by hand.
I talked with others, and they agreed with me. Commiserated, even. Some were skeptical that these problems have a solve at all. Others waved a hand — they’ll get fixed eventually, don’t worry about it. By the end of the conference, nobody had given me an answer. Speakers were presenting my exact pain points from the stage as open problems.
And honestly? That was the most useful thing I brought home. Not a breakthrough. A validation. The people supposedly at the frontier are asking the same questions I am. There isn’t some room full of engineers who’ve figured this all out while the rest of us fall behind. Turns out we’re probably not six months from AGI. We may even still need good software engineers — heck, maybe more of them.
I can feel the pressure; it’s getting closer now.
I felt behind, maybe you do too.
It’s coming from two places. The first is your feed. Social media is structurally incentivized to convince you that innovation is happening right under your nose and you’ll miss it if you don’t keep scrolling. Keeping up with the hype cycle has become its own part-time job — threads, launch videos, hot takes on benchmarks.
The second is tech leadership. We’ve all seen the memos by now. Shopify’s CEO declared “reflexive AI usage is now a baseline expectation” — AI usage goes in your performance review, and before you ask for headcount, you have to justify why AI can’t do the job. Anthropic’s CEO predicted AI would be writing 90% of all code within three to six months. That was March 2025. I think it’s safe to say that was hype.
Look at the shape of what happened. The claim — AI makes developers faster — came first, from the people selling it. Then it got laundered through the feed into mandates and even layoffs. And now generating the evidence is somehow our job. We’ve been handed a conclusion and asked to go prove it. As lifelong learners, we already have this undertone of needing to constantly learn and improve, and this hype cycle is hijacking this need for profit.
Here’s the math nobody’s doing.
I’m not convinced AI makes me faster overall. Sure, it generates code quickly, but that’s only part of the job. I still need to understand, review, and debug it, and debugging code I didn’t mentally model is costly.
And that’s all assuming the tooling is even up. It’s getting better, but take a peek at Claude Code’s status page sometime. We are a long, long way from nine 9’s.
In a METR study, experienced open-source developers using AI tools were 19% slower on real tasks. The kicker: afterward, they estimated AI had made them 20% faster.
Now, people have countered that study by saying the subjects didn’t have enough AI experience. To which I counter — do you? No, seriously. I’m no expert, but I have built a document generation agent, daily-driven Claude Code and Codex, written multiple model wrappers, consumed hours (days? 😭) of AI content, and earned two Microsoft AI Engineer certs.
Most of that knowledge has a shelf life measured in months, and the rules of the tooling from six months ago are unraveling. A new model drops and invalidates your entire workflow, so you rebuild from the ground up. The vim-config crowd could always argue their six hours of tinkering paid off over years in a stable environment. But what happens when you pay those six hours again and again, because the environment never stops shifting? And, by the way, your tooling is non-deterministic?
There are harder-to-quantify costs. If I skip translating the business logic into a data structure myself, did I actually internalize it? Did following the diff with my finger and muttering, “Oh so this function calls this one here… yep, makes sense,” really get me there? Are junior devs getting the reps that build intuition. Am I still getting the reps? Is my code-reading muscle only strong right now because we’re barely a year into this? Those hard-to-spot costs are real, and it’s my responsibility to pay them.
So whose job is to prove that AI makes you a 10x engineer?
Not mine. And I’d argue it’s not yours either.
The trillion-dollar productivity claims came from vendors with something to sell. If a study of experienced developers can find the opposite of what everyone feels, and the practitioners on stage at the industry’s flagship conference are still listing the core problems as unsolved, then you — an individual dev under deadline pressure — are not going to settle the question between standups. Who knows maybe you will. But if you’re feeling pressure just remember the burden of proof belongs to the people who made the claim.
AI has genuinely changed how I work. It’s a tool I reach for every day, and I’m not putting it down. But my job was never to prove AI makes me faster. My job is to remain a trusted engineer. It’ll be a while before we figure all of this out.
So right now I find myself slowing down. I use AI to quiz me on the code I’m merging. I have it explain code back to me and I check it against my own understanding. I’m sure better techniques for this will arise and I’m on the lookout. Comment below how you keep yourself honest. I’ll keep paying attention to the codebase — someone has to be able to fix it.
Until next time 👋