If you thought code writing speed was your problem you have bigger problems • Hacker News Board

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

#101

Post by avereveard » Tue, Mar 17, 2026, 7:40 PM UTC

Eh code doesn't have a lot of value. Especially filling methods between signatures and figuring out the dependencies exact incantation is mechanistic and definitely time better spent doing other things.

A lot of these blog start from a false premise or a lack of imagination.

In this case both the premise that coding isn't a bulk time waste (and yes llm can do debugging, so the other common remark still doesnt apply) is faulty and unsubstantiated (just measure the ratio of architects to developers) but also the fact that time saving on secondary activities dont translate in productivity is false, or at least it's reductive because you gain more time to spend on doing the bottlenecked activity.

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

#102

Post by closewith » Tue, Mar 17, 2026, 7:40 PM UTC

onlyrealcuzzo wrote: post #56

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…

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…

> It turns out, this is not the majority of software people are paying engineers to write.

The above are definitely the majority of software people are paying developers to write. By an order of magnitude.

The novel problems for customers who specifically care about code quality is probably under 1% of software written.

If you don't recognise this, you simple don't understand the industry you work in.

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

#103

Post by hrmtst93837 » Tue, Mar 17, 2026, 7:40 PM UTC

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…

[flagged]

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

#104

Post by Rapzid » Tue, Mar 17, 2026, 7:41 PM UTC

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…

The semantics described in the high-level language are absolutely maintained deterministically.

With agentic coding the semantics are not deterministically maintained. They are expanded, compressed, changed, and even just lost; non-deterministically..

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

#105

Post by Kilenaitor » Tue, Mar 17, 2026, 7:41 PM UTC

petcat wrote: post #67

tcmart14 wrote: post #61

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.

Having bugs is not the same as being non-deterministic.

I get the point that the compiler is not some pure, perfect transformation of the high-level code to the low level code, but it is a deterministic one, no?

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

#106

Post by doctorpangloss » Tue, Mar 17, 2026, 7:41 PM UTC

bob1029 wrote: post #11

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

You have it completely backwards.

Most Enterprise IT projects fail. Including at banks. They are extremely saleable though. They don't see things that are failures as failures. The metrics are not real. Contract renewals do not focus on objective metrics.

This is why you make "$1" with all your banking relationships and actually valuable tacit knowledge, until Accenture notices and makes bajillions, and now Anthropic makes bajillions. Look, I agree that you know a lot. That's not what I'm saying. I'm saying the thing you are describing as a bottleneck is actually the foundation of the business of the IT industry.

Another POV is, yeah, listen, the code speed matters a fucking lot. Everyone says it does, and it does. Jesus Christ.

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

#107

Post by pbasista » Tue, Mar 17, 2026, 7:42 PM UTC

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…

> review the ASM that GCC generates (we don't)

Of course we do not. Because there is no need. The process of compiling higher order language to assembly is deterministic and well-tested. There is no need to continue reviewing something that always yields the same result.

> We care that it works, and is correct for what it is supposed to do.

Exactly. Which is something we do not have with an output of an LLM. Because it can misunderstand or hallucinate.

Therefore, we always have to review it.

That is the difference between the output of compilers and the output of LLMs.

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

#108

Post by skydhash » Tue, Mar 17, 2026, 7:42 PM UTC

senko wrote: post #73

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.

> 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. Heh, depends on what you do. Many times the stakeholders can't explain what they want but can clearly articulate what they don't want when they see it. Gener…

> Generate a few alternatives, have them pick, is a tried and true method in design. It was way too expensive when coding was manual, so often you need multiple rounds of meetings and emails to align.

Why do you need coding for those. You can doodle on a whiteboard for a lot of those discussions. I use Balsamiq[0] and I can produce a wireframe for a whole screen in minutes. Even faster than prompting.

> If you don't think coding was the bottleneck, you're not thinking creatively about what's only now possible.

If you think coding was a bottleneck, that means you spent too much time doing when you should have been thinking.

[0]: https://balsamiq.com/product/desktop/

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

#109

Post by andrewstuart » Tue, Mar 17, 2026, 7:43 PM UTC

These “LLM programming ain’t nothing special” posts are becoming embarrassing for the authors who - due to their anti AI dogmatism - have no idea how truly incredibly fast and powerful it’s become.

Please stop making fools of yourselves and go use Claude for a month before writing that “AI coding ain’t nothing special” post.

Ignorance of what Claude can actually do means your arguments have no standing at all.

“I hate it so much I’ll never use it, but I sure am expert enough on it to tell you what it can’t do, and that humans are faster and better.”

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

#110

Post by cess11 » Tue, Mar 17, 2026, 7:43 PM UTC

One of the main reasons I like vim is that it enables me to navigate code very fast, that the edits are also quick when I've decided on them is a nice convenience but not particularly important.

Same goes for the terminal, I like that it allows me to use a large directory tree with many assorted file types as if it was a database. I.e. ad hoc, immediate access to search, filter, bulk edits and so on. This is why one of the first things I try to learn in a new language is how to shell out, so I can program against the OS environment through terminal tooling.

Deciding what and how to edit is typically an important bottleneck, as are the feedback loops. It doesn't matter that I can generate a million lines of code, unless I can also with confidence say that they are good ones, i.e. they will make or save money if it is in a commercial organisation. Then the organisation also needs to be informed of what I do, it needs to give me feedback and have a sound basis to make decisions.

Decision making is hard. This is why many bosses suck. They're bad at identifying what they need to make a good decision, and just can't help their underlings figure out how to supply it. I think most developers who have spent time in "BI" would recognise this, and a lot of the rest of us have been in worthless estimation meetings, retrospectives and whatnot where we ruminate a lot of useless information and watch other people do guesswork.

A neat visualisation of what a system actually contains and how it works is likely of much bigger business value than code generated fast. It's not like big SaaS ERP consultancy shops have historically worried much about how quickly the application code is generated, they worry about the interfaces and correctness so that customers or their consultants can make adequate unambiguous decisions with as little friction as possible.