I'm a solo dev. In fact I'm hardly a dev; it's just a helpful skill. Code writing speed IS a problem, because it takes valuable time away from other tasks. A bit like doing the dishes. I just set up Claude Code tonight. I still read and understand every line, but I don't need to Google things, move things around and write tests myself. I state my low-level intent and it does the grunt work. I'm not going to 10x my pr…
If you thought code writing speed was your problem you have bigger problems
121–130 of 231 posts
Re: If you thought code writing speed was your problem you have bigger problems
#122So 'writing helper' + 'research helper' + 'task helper' alone is amazing and we are def beyond that.
Even side features like 'do this experiment' where you can burn a ton of tokens to figure things out ... so valuable.
These are cars in the age of horses, it's just a matter of properly characterizing the cars.
Re: If you thought code writing speed was your problem you have bigger problems
#123Re: If you thought code writing speed was your problem you have bigger problems
#124> The bottleneck is understanding the problem. No amount of faster typing fixes that. 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…
Re: If you thought code writing speed was your problem you have bigger problems
#125Earlier quoted context omitted.
I really hate the trying to make LLM coding sound like it's just moving up the stack and is no different from a compiler. A compiler is deterministic and has a set of rules that can be understood. I can look at the output and see patterns and know exactly what the compiler is doing and why it does and where it does it. And it will be deterministic in doing it.
> compiler is deterministic and has a set of rules that can be understood. 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.
Re: If you thought code writing speed was your problem you have bigger problems
#126Btw: https://playcode.io
Re: If you thought code writing speed was your problem you have bigger problems
#127So far there's no obvious change one way or the other, but it hasn't been very long and everyone is in various states of figuring out their new workflows, so I don't think we have enough data for things to average out yet.
We're finding cases where fast coding really does seem to be super helpful though:
* Experimenting with ideas/refactors to see how they'll play out (often the agent can just tell you how it's going to play out)
* Complex tedious replacements (the kind of stuff you can't find/replace because it's contextual)
* Times where the path forward is simple but also a lot of work (tedious stuff)
* Dealing with edge cases after building the happy path
* EDIT: One more huge one I would add: anywhere where the thing you're adding is a complete analogy of another branch/PR the agent seems to do great at (which is like a "simple but tedious" case)
The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced.
I would say we've gone from being extremely skeptical to cautiously excited. I think it's far fetched that we'll see any order of magnitude differences, we're hoping for 2x (which would be huge!).
Re: If you thought code writing speed was your problem you have bigger problems
#128Re: If you thought code writing speed was your problem you have bigger problems
#129Earlier quoted context omitted.
Here's a literal toy one. 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".
No need to build three, you just have to quickly write a proof for which shapes can roll. You'll then spend x+y units of time, where y<<x, instead of 3*x units. We have stories that highlight the importance of thinking instead of blindly doing (sharpening the axe, $1 for pressing a button and $9999 for knowing which button to press).
Writing the 3 are the proofs.
Re: If you thought code writing speed was your problem you have bigger problems
#130Earlier quoted context omitted.
AI is really good when: 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 as long as it roughly is what you wanted, it's fine 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…
Actually the surgeon analogy is really good. Saying AI will replace programming is like saying an electric saw will replace surgeons because the hospital director can use it to cut into flesh.