Live data from Hacker News

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

andrewmurphy.io

91–100 of 231 posts

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

#91
post #52

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.

99.9% vs about 20%. Pretty weak argument.

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

#92
post #16

> 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 can't faster typing help us understand the problem faster?" Because typing is not the same as understanding.

The typing referred to here is not "the typing part of coding" (fingers touching the keyboard), it's the whole coding (LLM is not a typing aid, it's a coding aid).

And coding faster CAN help us understand the problem faster. Coding faster means iterating, refactoring, trying different designs - and seeing what does and doesn't work, faster.

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

#93
Correct, but I'd frame it to confused leaders a bit differently. Because we made this part easier, we've increased how critical, how limiting, other steps/functions are. Data's more valuable now. QA is more valuable now. More teams need to shift more resources, faster.

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

#94
post #67

Earlier quoted context omitted.

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

I commented elsewhere, but that doesn't mean it's not deterministic. Deterministic means given the same input it gives the same output. Compilers can still have bugs and generate the wrong code. But so long as given the same input it generates the same wrong output, it is still deterministic.

Compilers can generate wrong output in many different ways. And they're all analogous to the same ways that a sophisticated LLM can generate wrong outputs.

The compiler relies on:

* Careful use of the ENV vars and CLI options

* The host system, or the compilation of the target executable (for cross-compiling)

* It relies on the source code specifically

How is this really different from careful prompt engineering, and an extensive proposal/review/refine process?

They are both narrowing the scopes and establishing the guardrails for what the solution and final artifact will be.

> proposal/review/refine process

This is essentially what a sophisticated compiler, or query optimizer (Postgres) does anyway. We're just doing it manually via prompts.

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

#95

Earlier quoted context omitted.

For me it's also in generating output that I know is right when I see it, but don't necessarily know every intricate detail of up front.

You’re engaging with an LLM.

Yes?

Edit: you mean op?

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

#96

Earlier quoted context omitted.

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

so, what i am gathering is that some people in this comment section read "typing faster" literally, while other people are reading it and translating it to "iterating faster".

"Code writing speed" is just a superficial dismissal of AI without consideration as to whether AI is being used well or poorly for the task at hand. Saying that AI is the same as making people type faster, or that AI only produces slop, etc, is a very self limiting mindset.

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

#97
post #10

> 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 can't faster typing help us understand the problem faster? Why can't standing on your head?

Everyone has their own process.

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

#99

Earlier quoted context omitted.

You’re engaging with an LLM.

Yes? Edit: you mean op?

No I mean you. The person to whom you are responding is a bot. No judgment, just pointing this out in case you don’t want to waste human brain cycles.
Post reply on HN