Speed Traps in the LLM-Era
The Speed Trap of Literalism
Henry Ford was only half-right about a faster horse. Ditto with Steve Jobs and dictating to users.
Customers are the undisputed experts on their pain. They point to their wounds. But lack the vocabulary to articulate a robust solution. They do not know our internal thoughts, technical constraints, or skill sets. Customers aren't wrong. They are mistaken about what an elegant solution looks like.
Programming with large language models has increased our implementation speed tenfold. But this speed birthed a new problem: Literalism.
§The High Cost of "Ghost Work"
Shipping exactly what a customer asks for is the sin of Literalism. A customer requests "Feature XYZ." We hobble together a solution in thirty minutes. This is what productivity feels like.
In reality, we generated "ghost work." These features ignore our core goals. Create brittle code. Bloat the user interface.
Take a recent sin of mine. An art gallery wished to require artists submit their address. The "fast," AI-assisted blunder took 30 minutes end-to-end. I wrote code which created a conditional requirement for artists to add their full address for only this specific call.
It was a graceless implementation:
- Bolted-on: I moved before I thought.
- Jagged: I broke the logic of our design system.
- Dead weight: I forced a new code path to monitor.
§Interrogating Pain
We must interrogate feature requests. "Why do you want this? What task are you attempting to accomplish?"
Listening is difficult. Especially so when a customer is in pain, their project launches tomorrow, and they want a fix today. Pain is disorienting. A user knows they hurt, cannot explain the anatomy of the friction.
This is where "taste" comes in. Speed gives us more time to develop opinions.
Wait. Look. Sit still. Ingest the data. Feel friction alongside the user. Taste requires deep attention to the underlying context.
Contrast this with dumping context into an LLM and expecting the Magic Sandbox to fix everything.
Great implementations treat features and bugs as symptoms of a single gap. Take multiple messy requests and build one elegant solution. Solve the present issues, and prevent the future ones. In my gallery example, the elegant solution wasn't a "required toggle." It was Custom Questions. I built a system for custom fields. It solved the user's immediate crisis and fixed five future problems I haven't even thought of yet.
We must build what our users actually need. Stop reacting to every request. Buy yourself time. Develop taste. Think.