[Chris_Newton]

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.

[gopalv]

> 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.

[Ezra]

This is the article you referred to:

https://newsletter.posthog.com/p/the-hidden-danger-of-shippi...

[chrisweekly]

Thanks! Great link.

[js8]

Don't wait for feedback from "real users", become a user!

This tayloristic idea (which has now reincarnated in "design thinking") that you can observe someone doing a job and then decide better than them what they need is ridiculous and should die.

Good products are built by the people who use the thing themselves. Doesn't mean though that choosing good features (product design and engineering) isn't a skill in itself.

[bluGill]

Too often that isn't possible. There is a lot of domain knowledge in making a widget there is a lot of domain knowledge in doing a job. when e complex job needs a complex widget often there isn't enough overlap to be experts in both.

sure 'everyone' drives so you can be a domain expert in cars. However not everyone can be an astronaught - rockets are complex enough to need more people than astronaughts and so most people designing spaceships will never have the opportunity to use one.

[baxtr]

I find that this argument is used too often to refrain from using your own product.

Yes you're right not anyone can be a domain expert. But anyone in the company needs to at least try to use the product as much as possible.

I worked in companies where even the CEO had never used the product but was telling us what to implement.

[js8]

I am not asking anybody to be an expert in both (although I am sure such people exist, however rare); I am saying people should ideally have some skill in both. Also, people can collaborate, and learn new skills.

If you're bottle-necked by waiting for the users of your product to give a feedback, you clearly need to spend more time learning how to be a user yourself. Or hire people with some domain skill who can also code.

[ozim]

Have been there, we got pushback from users and we had to back off with releases. Users hunted product owner with pitchforks and torches.

As dev team we were able to crank the speed even more and silly product people thought they are doing something good by demanding even more from us. But that was one of the instances where users were helpful :).

People use dozens of apps every day to do their work. Just think about how are you going to make time to give feedback to each of each.

[johnnyanmac]

> Just think about how are you going to make time to give feedback to each of each.

That's pretty much solved by the size of the audiences. You won't give feedback on 12 apps, but 11 other people will probably do so on 11 different apps.

Of course, the issue with my domain is that there's plenty of feedback, and product owners just dismiss it. Burn down your entire portfolio to get that boosted shareholder value for the next earnings report.

[ozim]

And how do you solve that when you are one of those 11 apps when no one wants to talk to you because they have their work to do? Where you don’t have power to say that kind of thing.

Well by asking repeatedly of course but you just piss people off.

Have you ever given feedback to Atlassian, Google, Microsoft?

[nabbed]

>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.

[msteffen]

I think “iterating more quickly” is good for the company doing the building. But if you’re the customer, having a new piece of shit foisted on you twice a day so that some garbage PM can “build user empathy” gets old really fast.

Before AI, I worked at a B2B open source startup, and our users were perpetually annoyed by how often we asked them to upgrade and were never on the latest version.

[ffsm8]

> Before AI, I worked at a B2B open source startup, and our users were perpetually annoyed by how often we asked them to upgrade and were never on the latest version.

And frankly, they were in point.

Especially in the B2B context stability is massively underrated by the product.

There is very little I hate more then starting my work week on a Monday morning and find out someone changed the tools I'm using for daily business again

Even if it's objectively minor like apples last pivot to the windows vista design... It just annoys me.

But I'm not the person paying the bills for the tools I'm using at work, and the person that is almost never actually uses the tools themselves and hence shiny redesigns and pointless features galore

[roughly]

It's still faster and cheaper to just build the right thing to begin with. As the old saying goes, spend your time sharpening your ax.

[mgfist]

Yes, but only if you have an ax to sharpen. With a lot of things it takes trial and error to make progress. You can take this pretty up high too - sometimes it takes building multiple products or companies to get it right

[Jare]

> With a lot of things it takes trial and error to make progress

Way too often that is used as an excuse for various forms of laziness; to not think about the things you can already know. And that lack of thinking repeats in an endless cycle when, after your trial and error, you don't use what you learned because "let's look forward not backward", "let's fail fast and often" and similar platitudes.

Catchy slogans and heartfelt desires are great but you gotta put the brains in it too.

[diatone]

Without commenting about the frequency of negligence myself, I suspect at least that you and GP are in agreement.

I doubt GP is suggesting ‘go ahead and be negligent to feedback and guardrails that let you course correct early.’

Plugging the Cynefin framework as a useful technique for practitioners here. It doesn’t have to be hard to choose whether or not rigorous planning is appropriate for the task at hand, versus probe-test-backtrack with tight iteration loops.

[mgfist]

I see indecision and analysis paralysis far more. And yes, you do need to thing about things, but far too often I see people not do something because they're worried it's not optimal. But not doing something is far worse than doing something sub-optimally!

[uoaei]

If you start a business without a concrete idea of the timber you need to achieve the idea you have, an axe will be all but useless.

[overfeed]

> 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,

A lot of people are so enamored by speed, they are not even taking the time to carefully consider the full picture of what they are building. Take the HN frontpage story on OpenCode: IIRC, a maintainer admitted they keep adding many shallow features that are brittle.

Speed cannot replace product vision and discipline.

[johnnyanmac]

Tech very quickly shifted to a industry of marketers instead of hackers. And with salesmen, you want to advertise as many features as possible, not talk about how quality one good crucial feature is.

This won't really stop until investors start judging on quality and not quantity. But a lot of those are thinking in finances, and the thought of removing their biggest cost center is too tempting to not go all in on. So they want to hear "we made this super fast with 2-3 people!" instead of "we optimized and scaled this up to handle 400% more workload with double the performance".

[fc417fc802]

The outcome of that approach depends entirely on the broader process. Imagine golf but you refuse to swing with anything less than maximum strength to avoid wasting time.

Discovery is great and all but if what you discover is that you didn't aim well to begin with that's not all that useful.

[andai]

> If we’re far enough off course, increasing speed becomes counterproductive and it ends up taking longer to get where we want to be.

This reminded me of the idea that civilization is already a misaligned superintelligence, and that technology (incl. AI) just moves it faster in the wrong direction.

That's basically the problem of supermorality. If you're an actually benevolent AI, do you do what civilization tells you? Or do you do what is good? What happens if you disagree?

[abustamam]

I think it depends on what is good, and who it's good for.

Thus far, AI has been good... For venture capitalists. Jury's out if it's good for humanity and civilization at large. There have been a lot of benevolent usages of AI thus far, but also a lot of bad.

As for those who disagree with the "benevolent AI," I think they just get sent to the gallows (either metaphorically or literally)

[_doctor_love]

> velocity is a vector

Exactly this. Velocity is a vector. It has magnitude (aka speed) and direction.

Our industry has chased magnitude over all else for so long. Now we can put nitro in everyone's car and we get to where we wish to go very fast. Suddenly bad direction-setting is getting feedback where there used to be friction and natural time to steer.

My greatest hope is that a ton of bad leaders and middle managers end up finally getting exposed due to the advent of AI. (Will I be disappointed? Almost certainly yes.)

[siddboots]

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.

[TheJord]

10 years of thinking before shipping is actually the move. The AI just becomes a power tool — useless if you don't know what you're building, unstoppable if you do

[layla5alive]

Are you being cute impersonating an LLM, or are you an LLM posting?

[xyzzy123]

You're missing out on 10 years of real world feedback if you do this.

[ozim]

There are projects where „real world feedback” will be actively harmful.

[skydhash]

> 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).

[tombert]

I've definitely gotten it into contexts where it will never stop going into the wrong direction, even when I tell it to forget everything it did before, and told it a correct path forward. Usually restarting the entire session fixes it, but not always.

[FrankRay78]

Shrewd context management is the go here.

[nprateem]

The biggest problem is the fact they DON'T clarify their stupid assumptions.

The number of times I've seen them get the wrong end of the stick in their COT is ridiculous.

Even when I tell them to only implement after my explicit approval they ignore this after 2 or 3 followups and then it's back to them going down blind alleys.

[theshrike79]

Imagine you're lost in a jungle, you know within 180 degrees where you should go to get to the nearest civilization.

If you need to spend actual humans searching every 10 degrees (or more if they need to go far), the cost might not be worth it. What if they don't come back? Every human scouting is not foraging for the group or protecting them from whatever is in the jungle,

Now if you have a near infinite capacity of autonomous drones you can send one every degree from your position and get an approximate estimate whether that direction is safe or not.

It's the same with programming, you can do a TON of exploratory crap with near zero extra cost. Just to see if that's the right direction or not. Basically lean in to the "fast but inaccurate" aspect of AI.

Like I had a hare-brained idea of a local web-based file manager / media browser that would use YOLOv8 and CLIP to tag and classify images and videos as you browse. Took me about 30 minutes of active time over a few evenings while doing other stuff to conclude that, yes, it IS doable. Now I can focus my actual brain on it.

[throwaway27448]

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

A proper capitalist system will tend toward the right direction as directed by the market yea? All of this neuroticism about AI doesn't matter.

[johnnyanmac]

Yes, the true market; shareholders.

[jstummbillig]

Ah, metaphors. Abstract concepts are not moving objects. You don't actually need to "turn it around" or "sail past it". You can break the laws of physics (because they don't apply). You can teleport around.

Speed actually just wins, because we are usually constrained by time.

[3121aksj8p]

Yes, AI can emit BS at a faster rate than ever. We can also produce more blog posts than ever.

Working or useful software? AI hasn't produced any at all since 2023.

[jstummbillig]

Wow, an account, just for that? I feel honored and slightly suspicious.

[nprateem]

Altman didn't want to post from his own account

[Chris_Newton]

Speed actually just wins, because we are usually constrained by time.

Sorry, but I don’t understand what you mean here. What do we win by being faster at producing the wrong things?

[jstummbillig]

You learn more quickly that you are producing the wrong thing.

[sifar]

Do you ? It takes a some introspection. People can be in denial despite the feedback from reality.

[johnnyanmac]

This implies that

1) a lot of shallow, orthogonal directions is better than 1 deep, careful approach

2) There's no social aspect to churning out a bunch of slop that will affect the perception of potential "right things" later. My domain can be particularly grudgeful in this regard.

[jstummbillig]

1) If there is uncertainty, that seems to be correct, yes. (If there is no uncertainty, then the question and the essay become moot: You already know what to do. Things take as long as they must. Worst case, you are wrong.)

2) I read that part twice and could not figure out what it is you are trying to say.