With all the emphasis on the speed of modern AI tools, we often seem to forget that velocity is a vector quantity. Increased speed only gets us where we want to be sooner if we are also heading in the right direction. If we’re far enough off course, increasing speed becomes counterproductive and it ends up taking longer to get where we want to be.

I’ve been noticing that this simple reality explains almost all of both the good and the bad that I hear about LLM-based coding tools. Using AI for research or to spin up a quick demo or prototype is using it to help plot a course. A lot of the multi-stage agentic workflows also come down to creating guard rails before doing the main implementation so the AI can’t get too far off track. Most of the success stories I hear seem to be in these areas so far. Meanwhile, probably the most common criticism I see is that an AI that is simply given a prompt to implement some new feature or bug fix for an existing system often misunderstands or makes bad assumptions and ends up repeatedly running into dead ends. It moves fast but without knowing which direction to move in.

> Increased speed only gets us where we want to be sooner if we are also heading in the right direction.

This is a real problem when the "direction" == "good feedback" from a customer standpoint.

Before we had a product person for every ~20 people generating code and now we're all product people, the machines are writing the code (not all of it, but enough of it that I will -1 a ~4000 line PR and ask someone to start over, instead of digging out of the hole in the same PR).

Feedback takes time on the system by real users to come back to the product team.

You need a PID like smoothing curve over your feature changes.

Like you said, Speed isn't velocity.

Specifically if you have a decent experiment framework to keep this disclosure progressive in the customer base, going the wrong direction isn't a huge penalty as it used to be.

I liked the PostHog newsletter about the "Hidden dangers of shipping fast", I can't find a good direct link to it.

I've been working on a side project for ~10 years (very intermittently) that involves a tricky combination of mathematics, classical AI algorithms, and programming language design, and I've gone though this very slow but rewarding journey to work out how all of the pieces should fit together properly.

In the last year or so I've been able to prototype it and accelerate the development quite significantly using Claude and pals, and now it is very close to a finished product. One one hand there's no doubt in my mind that the LLM tools can make this sort of thing faster and let you churn through ideas until you find the right ones, but on the other hand, if I hadn't had that slow burn of mostly just thinking about it conceptually for 10 years, I would have ended up vibe coding a much worse product.

>Increased speed only gets us where we want to be sooner if we are also heading in the right direction.

I suppose there is an argument that if you are building the wrong thing, build it fast so that you can find out more quickly that you built the wrong thing, allowing you to iterate more quickly.

> It moves fast but without knowing which direction to move in.

It also moves fast with a tendency to pick the wrong direction (according to the goal of the prompter) at every decision point (known or unknown).