Live data from Hacker News

If you thought code writing speed was your problem you have bigger problems

andrewmurphy.io

121–130 of 231 posts

Re: If you thought code writing speed was your problem you have bigger problems

#121
post #114

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…

This I think is pretty spot on. I still have to review the code ideally line by line. It is like templates, generators, etc. they help and do make things faster but 10x isnt gonna happen unless requirement gathering also 10x which so far, ai has had no impact on.

Re: If you thought code writing speed was your problem you have bigger problems

#122
It's unfair to characterize AI as 'code writing / completion' - it's at minimum 1/4 layer of abstraction above that - and even just 'at that' - it's useful.

So '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

#123
My problem when writing code is mainly executive dysfunction; I constantly succumb to the temptation to take the easy way and do it properly later, and later never comes. For some reason, using a coding agent seems to alleviate this. Things get done the way I think they should be done, not just in a way that's "good enough for now."

Re: 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…

I'm reminded of the original Agile joke, "software you don't want in 30days or less." today it's "software you don't want in 5days or less."

Re: If you thought code writing speed was your problem you have bigger problems

#125
post #67

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

It is deterministic, unless GCC is now including a random statistical process inside its compiler to generate machine code. You've copied this same comment repeatedly, it doesn't become more correct the more you spam it.

Re: If you thought code writing speed was your problem you have bigger problems

#127
When we (the engineering team I work on) started using agents more seriously we were worried about this: that we'd speed up coding time but slow down review time and just end up increasing cycle time.

So 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

#129

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

> quickly write a proof for which shapes can roll.

Writing the 3 are the proofs.

Re: If you thought code writing speed was your problem you have bigger problems

#130

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

It's so much faster too! How many meters of flesh have you cut this month, and how are you working toward increasing that number?
Post reply on HN