← Field Notes // Field Notes / 04

The Bottleneck Was Never Typing Speed

Jeff Hay, Portable Knowledge, LLC

It would be nice if the hard part of software development was writing the code. For a long time, a lot of tooling investment acted like it was: better autocomplete, faster builds, more powerful frameworks, all chasing the same assumption, "if we can just type the solution faster, we'll ship faster." AI coding assistants are the natural endpoint of that assumption, and they're genuinely good at it. Point one at a clear, specific description of what you want, and it will produce working code faster than any of us could type it.

Point one at a vague description, though, and it will produce something plausible-looking, confidently, that probably isn't what you actually needed. That's not a flaw in the tool. It's doing exactly what was asked, which is the problem: most of the time, what was asked wasn't actually specified.

Requirements gathering has always been the unglamorous part of the job, the discipline everyone agrees is important and that gets compressed first when a deadline is tight. It's tempting to skip it precisely because a person with enough context could often fill the gaps themselves, inferring intent from a hallway conversation or institutional memory. An AI coding assistant doesn't have that context to fall back on. A vague prompt to an AI just produces a vague, confident-looking result, faster than a person would have, which makes the underlying ambiguity easier to miss until it's already shipped.

What actually changed

The bottleneck moved. It used to be, informally, "how fast can someone type this." Now it's "how precisely can someone describe what this needs to do, including the edge cases, the constraints, the things that go without saying to a person who's been on the team for years (and that go without saying to an AI tool too, in the wrong sense)." Writing that down clearly was always valuable. It's now the actual leverage point, the thing that determines whether AI-assisted development produces something useful or something that merely looks useful until someone runs it against reality.

I spent most of a career in FDA-regulated medical imaging, where "we didn't write the requirement down clearly enough" isn't a minor process gap, it's a verification and validation failure. That discipline, systems requirements written precisely enough to trace forward into test cases and backward into design decisions, is exactly the muscle most teams let atrophy once they're moving fast. It's worth building back, not because regulation demands it, but because it's the actual difference between AI tooling that accelerates good work and AI tooling that accelerates confident-looking mistakes.