Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

andrewmurphy.io

Post reply on HN
Print view View original

61–70 of 231 posts

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

#61

Post by tcmart14 »

petcat wrote: post #20

As human developers, I think we're struggling with "letting go" of the code. The code we write (or agents write) is really just an intermediate representation (IR) of the solution. 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…

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.

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

#62

Post by jmulho »

john_strinlai wrote: post #30
furyofantares wrote: post #6

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

> Why not? Why can't faster typing help us understand the problem faster? do you have a example (even a toy one) where typing faster would help you understand a problem faster?

I often understand problems by discussing them with AI (by typing prompts and reading the response). Typing or reading faster would make this faster.

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

#63

Post by [deleted] »

furyofantares wrote: post #17
bob1029 wrote: post #11

Earlier quoted context omitted.

> Why can't we figure out the right thing faster by building the wrong thing faster? 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.

That's fair. I'm usually my own customer.

[deleted]

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

#64

Post by Bukhmanizer »

furyofantares wrote: post #17
bob1029 wrote: post #11

Earlier quoted context omitted.

> Why can't we figure out the right thing faster by building the wrong thing faster? 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.

That's fair. I'm usually my own customer.

I think a lot of the discourse around LLMs fails because of organizational differences.

I work in science, and I’ve recently worked with a couple projects where they generated >20,000 LOC before even understanding what the project was supposed to be doing. All the scientists hated it and it didn’t do anything that it was supposed to. But I still felt like I was being “anti-ai” when criticizing it.

I understand that it’s way better when you deeply understand the problem and field though.

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

#66

Post by observationist »

john_strinlai wrote: post #30
furyofantares wrote: post #6

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

> Why not? Why can't faster typing help us understand the problem faster? do you have a example (even a toy one) where typing faster would help you understand a problem faster?

Sometimes articulating the problem is all you need to see what the solution is. Trying many things quickly can prime you to see what the viable path is going to be. Iterating fast can get you to a higher level of understanding than methodical, deliberative construction.

Nevertheless, it's a tool that should be used when it's useful, just like slower consideration can be used. Frontier LLMs can help significantly in either case.

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

#67

Post by petcat »

tcmart14 wrote: post #61
petcat wrote: post #20

As human developers, I think we're struggling with "letting go" of the code. The code we write (or agents write) is really just an intermediate representation (IR) of the solution. 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…

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

#68

Post by mooreds »

everdrive wrote: post #9

Companies genuinely don't want good code. Individual teams just get measured by how many things they push around. An employee warning that something might not work very well is going to get reprimanded as "down in the weeds" or "too detail oriented," etc. I didn't understand this for a while, but internal actors inside of companies really just want to claim success.

> Companies genuinely don't want good code.

I might be more charitable. I'd say something like "Companies genuinely want good code but weigh the benefits of good code (future flexibility, lower maintenance costs) against the costs (delayed deployment, fewer features)."

Each company gets to make the tradeoffs they feel are appropriate. It's on technical people to explain why and risks, just like lawyers do for their area of expertise.

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

#69

Post by nyeah »

lgessler wrote: post #49
john_strinlai wrote: post #30

Earlier quoted context omitted.

> Why not? Why can't faster typing help us understand the problem faster? do you have a example (even a toy one) where typing faster would help you understand a problem faster?

Has everyone always nailed their implementation of every program on the first try? Of course not. Probably what happens most times is you first complete something that sorta works and then iterate from there by modifying code, executing, observing, and looping back to the beginning. You can wonder about ultimately how much of your time/energy is consumed by the "typing code" part, and there's surely a wide range of v…

That kind of thinking pops up very prominently in the article.

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

#70

Post by tcmart14 »

petcat wrote: post #52
exceptione wrote: post #40

Earlier quoted context omitted.

None of the comparisons make any sense. In short, these concepts are essential to understand: - determinism vs non-determinism - conceptual integrity vs "it works somewhat, don't touch it"

> determinism vs non-determinism 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.

Deterministic doesn't mean correct. Compilers can have bugs. What deterministic means, given the same input you get the same output every time. So long as given the same code it generates the same wrong thing every time, its still deterministic.
Post reply on HN