Why not? Why can't faster typing help us understand the problem faster?
> When you speed up code output in this environment, you are speeding up the rate at which you build the wrong thing.
Why can't we figure out the right thing faster by building the wrong thing faster? Presumably we were gonna build the wrong thing either way in this example, weren't we?
I often build something to figure out what I want, and that's only become more true the cheaper it is to build a prototype version of a thing.
> You will build the wrong feature faster, ship it, watch it fail, and then do a retro where someone says "we need to talk to users more" and everyone nods solemnly and then absolutely nothing changes.
I guess because we're just cynical.
Why can't standing on your head?
Because usually the customer can only tolerate so many failed attempts per unit of time. Running your fitness function is often very expensive in terms of other people's time.
This is easily the biggest bottleneck in B2B/SaaS stuff for banking. You can iterate maybe once a week if you have a really, really good client.
The article talks about process flows and finding the bottleneck. That might be coding, but probably is not.
Because typing is not the same as understanding.
do you have a example (even a toy one) where typing faster would help you understand a problem faster?
I don't understand why GP's comment is so controversial. GP is not denying that you should maybe think a little before a key hits the keyboard as many commenters seem to suppose. Both can be true.
Build a toy car with square wheels and one with triangular wheels and one with round wheels and see which one rolls better.
The issue isn't "typing faster" it's "building faster".
It's funny, because you could actually take that story and use it to market AI.
> I once watched a team spend six weeks building a feature based on a Slack message from a sales rep who paraphrased what a prospect maybe said on a call. Six weeks.
Except now with AI it takes one engineer 6 hours, people realize it's the wrong thing and move on. If anything, I would say it helps prove the point that typing faster _does_ help.
In the long term, some of the most expensive wrong-things are the ones where the prototype gets a "looks good to me" from users, and it turns out what they were asking for was not what they needed or what could work, for reasons that aren't visually apparent.
Why can't you understand the problem faster by talking faster?
I think we can, in some cases.
For instance, I prototyped a feature recently and tested an integration it enabled. It took me a few hours. There's no way I would have tried this, let alone succeeded, without opencode. Because I was testing functionality, I didn't care about other aspects: performance, maintainability, simplicity.
I was able to write a better description of the problem and assure the person working on it that the integration would work. This was valuable.
I immediately threw away that prototype code, though. See above aspects I just didn't need to think about.
Why do you need to type at all to understand the problem?
I write my best code when I'm driving my car. When I stop and park up, it's just a case of typing it all in at my leisure.
1. you want something that's literally been done tons of times before, and it can literally just find it inside its compressed dataset
2. you want something and don't care that much how it actually functions
It turns out, this is not the majority of software people are paying engineers to write.
And it turns out that actually writing the code is only part of what you're paying for - much smaller than most people think.
You are not paying your surgeon only to cut things.
You are not paying your engineer only to write code.
This only works in large companies. In startups this is how you run out of money.
Speed doesn’t fix misunderstanding, but it does change how quickly you can iterate toward understanding.
In practice, building something (even if it’s wrong) creates feedback loops you can’t get from thinking alone. Especially in systems like ML/LLMs, where behavior emerges from the pipeline rather than just the idea.
The real bottleneck isn’t typing speed — it’s how fast you can validate assumptions.
Faster iteration without reflection leads to chaos. Pure thinking without building leads to stagnation.
The balance is tight feedback loops with deliberate evaluation.
Expedience is the enemy of quality.
Want proof? Everyone as a result of “move fast and break things” from 5-10 years ago is a pile of malfunctioning trash. This is not up for debate.
This is simply an observation. I do not make the rules. See my last submission for some CONSTRUCTIVE reading.
Bye for now.
For instance, GCC will inline functions, unroll loops, and myriad other optimizations that we don't care about. But when we review the ASM that GCC generates (we don't) we are not concerned with the "spaghetti" and the "high coupling" and "low cohesion". We care that it works, and is correct for what it is supposed to do. And that it is a faithful representation of the solution that we are trying to achieve.
Source code in a higher-level language is not really different anymore. Agents write the code, maybe we guide them on patterns and correct them when they are obviously wrong, but the code is merely the work-item artifact that comes out of extensive specification, discussion, proposal review, and more review of the reviews.
A well-guided, iterative process and problem/solution description should be able to generate an equivalent implementation whether a human is writing the code or an agent.
Source code is a formal language, in a way that natural language isn't.
Maybe a dialect of legalese will emerge for software engineering?
- determinism vs non-determinism
- conceptual integrity vs "it works somewhat, don't touch it"
Here are the reported miscompilation bugs in GCC so far in 2026. The ones labeled "wrong-code".
https://gcc.gnu.org/bugzilla/buglist.cgi?chfield=%5BBug%20cr...
I count 121 of them. It appears that code-generation is not as deterministic as you seem to think it is.
I have very much upset a CEO before by bursting his bubble with the fact that how fast you work is so much less important than what you are working on.
Doing the wrong thing quickly has no value. Doing the right thing slowly makes you a 99th percentile contributor.
The real problem is that most AI coding workflows have the agent figure out the decision logic as it goes. That works until it doesn't, and when it doesn't you're debugging an opaque reasoning chain instead of a clear decision path. Been building tooling around making those decisions explicit before generation. The productivity gains aren't in generation speed. They're in eliminating the back-and-forth rounds that end up eating all your productivity.
Proper approach to speeding things up would be to ask "What are the limiting factors which stops us from X, Y, Z".
--
This situation of management expecting things to become fast because of AI is "vibe management". Why to think, why to understand, why to talk to your people if you saw an excited presentation of the magic tool and the only thing you need to do is to adopt it?..
gammalost•36m ago
hathawsh•32m ago
dmitrygr•27m ago
Many a disaster started this way
hathawsh•25m ago
zer00eyz•15m ago
Do you think the leet code, brain teaser show me how smart you are and how much you can memorize is optimized to hire the people who can read code at speed and hold architecture (not code but systems) in their head? How many of your co-workers are set up and use a debugger to step through a change when looking at it?
Most code review was bike shedding before we upped the volume. And from what I have seen it hasn't gotten better.