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.
https://newsletter.posthog.com/p/the-hidden-danger-of-shippi...
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.
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.
Well by asking repeatedly of course but you just piss people off.
Have you ever given feedback to Atlassian, Google, Microsoft?
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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
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).
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.
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?
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.
2) I read that part twice and could not figure out what it is you are trying to say.
Working or useful software? AI hasn't produced any at all since 2023.
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.
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?
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)
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.)
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.
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.
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.