AI coding tools reveal that the real engineering skill was always judgment, not typing speed
The Best Engineers I Know Are Getting Slower
And I mean that as a compliment.
Not slower because the tools are failing them. Slower because, for the first time, they have enough leverage to actually feel the weight of what they’re building. When you can produce in one hour what used to take two days, something unexpected happens. The bottleneck shifts. And it doesn’t shift to the AI. It shifts to you.
🧠 The Typing Bottleneck Was Hiding a Judgment Problem
Here’s something I’ve been sitting with for months. When engineers are constrained by how fast they can physically write code, they make a lot of fast, small decisions almost by default. You skip the design doc because there’s no time. You hardcode the config because the alternative means another hour of work. You ship the quick fix and file a mental note to revisit it, a note you both know will never get revisited.
The speed constraint was forcing a kind of false productivity. You were always moving, which felt like progress. But a lot of that motion was debt accumulation dressed up as shipping.
AI coding tools remove the typing bottleneck entirely. GPT-5.4, which OpenAI rolled out this week with up to 1M tokens of context in Codex and what they’re calling “best-in-class agentic coding for complex tasks,” means the raw production ceiling just got raised again. The instinct for most engineers is to use that headroom to produce more. More features, more PRs, more throughput.
The engineers I respect most are doing the opposite.
The Real Skill Was Never Typing
They’re using the reclaimed time to think longer before they start. To question whether the feature should even exist. To push back on the ticket instead of just closing it. To write the architecture doc that nobody asked for but everyone needed.
This is judgment. And it turns out judgment was always the scarce resource. Typing speed was just loud enough to drown out that fact.
I’ve watched engineers with average coding chops become genuinely dangerous with these tools, because they already had the judgment. They knew which abstractions were wrong. They could smell a data model that would cause pain in six months. They asked the uncomfortable questions before writing line one. The AI handles the translation from intention to implementation. But the intention still has to come from somewhere, and that somewhere is human.
⚙️ Structure Is the New Leverage
One practical thing I’ve noticed: the engineers extracting the most value from AI coding tools aren’t better prompters. They’re better architects of context. Shraddha Bharuka’s breakdown of Claude Code project structure is a good example of this thinking in action. The insight is that prompting is temporary but structure is permanent. When you give an AI tool a well-organized repo with clear rules, reusable workflow definitions, and local context files near the dangerous modules like auth and billing, you stop fighting the tool and start multiplying yourself.
That’s a judgment call. Deciding what the AI needs to know, what it should never touch, and where the sharp edges live in your specific system. No model figures that out for you.
What Changes From Here
I don’t think the future belongs to the engineers who can prompt fastest. It belongs to the ones who’ve always been good at the hard, slow parts: system design, questioning requirements, understanding consequences, knowing when not to build something.
The AI handles a growing share of the translation work. That’s genuinely useful. But the engineers who treat that as an invitation to think less are going to build faster toward the wrong destination.
The best thing these tools have done is make judgment visible. It was always the job. Now there’s nowhere left to hide behind the typing.
Sources & Further Reading
#AIEngineering #SoftwareDevelopment #AITools #EngineeringLeadership #CodingWithAI
