[flagged]
Ai generated comments are against the rules of HN.
@dang this bot is spamming
If you thought code writing speed was your problem you have bigger problems
131–140 of 231 posts
Re: If you thought code writing speed was your problem you have bigger problems
#132As 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…
This. The comparison between compilers and LLMs is so utterly incorrect, and yet I've heard it multiple times already in the span of a few weeks. The people suggesting this are probably unaware of the fact that Turing complete languages follow mathematical properties not just vibes. You can trust the output of your compiler because it was thoroughly tested to ensure it acts as a Turing machine that converts one Turing complete language (C, C++, whatever) into another Turing complete language (ASM) and there's a theorem that guarantees you that such a conversion is always possible. LLMs are probabilistic machines and it's grossly inappropriate to put them in the same category as compilers - it would be like saying that car tires and pizzas are similar because they're both round and have edges.
Re: If you thought code writing speed was your problem you have bigger problems
#133I'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 is the way.
Re: If you thought code writing speed was your problem you have bigger problems
#134Earlier 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…
> 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.
As it turns out - "just make this button green" - is not the majority of what people at FAANG are doing...
As it turns out - 4 years before LLMs - at least one of the FAANGs already had auto-complete so good it could do most of what LLMs can practically do in a gigantic context.
But, sure...
Re: If you thought code writing speed was your problem you have bigger problems
#135Companies 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.
They don't care about good code, but they do pay people a lot of money to care about good code. If the people you hired didn't care, our software quality would be worse than it is. And since people are caring less in the face of AI, it is getting worse.
Re: If you thought code writing speed was your problem you have bigger problems
#136> 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.
attempt != release to customer
when you're building a feature and have different ideas how to go about it, it's incredibly valuable to build them all, compare, and then build another, clean implementation based on all the insights
I used to do it before, but pretty rarely, only for the most important stuff. now I do it for basically everything. and while 2-4 agents are working on building these options, I have time to work on something else.
Re: If you thought code writing speed was your problem you have bigger problems
#137> That's the part most people get. Here's the part they don't, and it's the part that should scare you:
> When you optimise a step that is not the bottleneck, you don't get a faster system. You get a more broken one.
if you ever played factorio this is pretty clear.
Re: If you thought code writing speed was your problem you have bigger problems
#138Earlier 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…
> 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.
Everyone has its own set of novel problems. And they use libraries and framework for things that are outside it. The average SaaS provider will not write its own OS, database, network protocols,... But it will have its own features and while it may be similar to others, they're evolving in different environments and encounter different issues that need different solutions.
Re: If you thought code writing speed was your problem you have bigger problems
#139These “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 hat…
What makes you think they haven't? I agree with them and I've been heavily using Claude / Codex for a while now. And I'm slowly trying to use AI more selectively because of these concerns.
Re: If you thought code writing speed was your problem you have bigger problems
#140As 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…
> The process of compiling higher order language to assembly is deterministic and well-tested.
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.
I've posted this 3 times now. Code-generation by compilers written by experts is not deterministic in the way that you think it is.