Insight: the real value of AI for engineers is eliminating wait states and uncertainty, not raw speed
The Speed Trap: Why AI’s Real Value Has Nothing to Do With Typing Faster
Most engineers I know are chasing the wrong metric right now. They’re asking how to use AI tools faster, how to generate more code per hour, how to shorten the time between prompt and output. That framing is wrong, and I think it’s costing people the actual benefit sitting right in front of them.
I’ve been paying loose attention to where my time actually goes for a few months. The honest answer surprised me. The slow parts of my work were never the typing. They were the waiting.
What “Wait States” Actually Look Like
Wait states in engineering work are not always obvious. They don’t show up cleanly in a time tracker. They look like this: you’re mid-implementation on something and you stop because you’re not sure how a downstream system behaves under a specific edge condition. So you go read old code, grep through logs, maybe ping someone on Slack. Twenty minutes later you have your answer and you go back to what you were doing.
Or you have two reasonable architectural approaches and you’re not confident enough in your own read to commit, so you wait for a second opinion from someone you trust. Except they’re in meetings until 3pm.
Or you just don’t have enough context on a subsystem you didn’t build to make a call you’re comfortable making. So you sit in partial paralysis, doing smaller tasks while the real work waits.
None of that is a typing problem. It’s an information latency problem. It’s an uncertainty problem.
Why the Framing Matters
JetBrains put it plainly when promoting a developer productivity talk earlier this month: “Developer productivity shouldn’t be measured in speed.” That’s the right instinct, and it mirrors what I’ve been working through myself.
When you optimize for speed, you reach for autocomplete. You want tokens generated fast, boilerplate filled in, repetitive code handled. Fine. There’s value there. But it’s shallow value.
When you optimize for reducing wait states, you reach for something more like a thinking partner. You’re not asking it to type for you. You’re asking it to give you enough context, confidence, or analysis to make a decision you’d otherwise have to wait hours or days for.
The output can look similar from the outside. Internally, the experience is completely different.
The Second Opinion Problem
Andrej Karpathy talked about this in a recent No Priors episode. He described what mastery of coding agents actually looks like, and part of it is this shift away from AI as a code generator toward AI as a collaborator on reasoning. That matches my experience.
The most valuable thing I’ve gotten from AI tools in the last year is not faster code. It’s faster confidence. I can pressure-test an approach at 11pm without waiting for a colleague to be available. I can ask “what are the failure modes here” and get a substantive answer I can then verify. I can reconstruct context on a system I haven’t touched in eight months without a two-hour archaeology session through git history.
That’s not speed. That’s elimination of idle time, of blocked time, of the dead air between deciding to do something and actually doing it.
What This Means for How You Use These Tools
If you’re using AI primarily to write code faster, you’re probably getting real value but leaving most of it on the table. The better use pattern, in my experience, is to reach for it specifically when you feel stuck, uncertain, or blocked. Not when you know exactly what you want to type.
Ask it about the thing you’d normally have to wait to find out. Ask it to poke holes in the thing you’re almost confident about. Use it to compress the gap between “I need to understand this” and “I understand this enough to move.”
The engineers who are going to get the most out of these tools are not the fastest prompt writers. They’re the ones who have the self-awareness to notice when they’re in a wait state and the discipline to actually use the tool to get out of it rather than just doing the comfortable thing and waiting.
The real shift is not about velocity. It’s about removing the friction between knowing what you need to do and being unblocked enough to do it. That’s a different problem than autocomplete solves. It’s also a much more valuable one.
Sources & Further Reading
#AIEngineering #DeveloperProductivity #SoftwareEngineering #MachineLearning #BuildingWithAI
