Live data from Hacker News

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

andrewmurphy.io

181–190 of 231 posts

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

#182
post #140

Earlier quoted context omitted.

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

In the 12+ years I've been a professional developer, I can only remember two bugs that were caused by the compiler / interpreter, everything else were logic bugs, oversights, 3rd-party libraries, misunderstanding of the requirements, internal contradictions in the requirements etc.

So that's maybe 0.1% of all the bugs I've touched.

In that sense, code generation isn't really an interesting source of bugs for the discussion at hand.

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

#183
I think one of the biggest gains of AI is the second order effects. And maybe a bit in the third order as well. When coding with Claude, I can focus on the architecture, the big picture of the implementation, while Claude takes care of the details. Every function for which I don't have to remember the order of the arguments anymore, is a little bit extra brain power I can dedicate to thinking about the solution. I can focus on what matters, and I can focus for longer. I find that remembering argument order is much more tiresome than thinking through complex interactions(because the latter is fun, while the former is boring)

Then there's the speedup. A smaller team can now achieve what a larger team was needed for before. This means less communication overhead, in theory fewer and/or shorter meetings. Which all translates to me spending more time and more energy on thinking about the solution. Which is what matters.

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

#184

How do people ensure that AI don't produce subtle and stupid mistakes that humans usually don't make, like the one in Amazon that deleted the entire production deployment? When a person writes code, the person reasons out the code multiple times, step by step, so that they don't make at least stupid or obvious mistakes. This level of close examination is not covered in code review. And arguably this is why we can tru…

> How do people ensure that AI don't produce subtle and stupid mistakes that humans usually don't make, like the one in Amazon that deleted the entire production deployment?

Right... Because Humans have never ever accidentally rm -rf'd a production system in the wrong spot?

GitLab has entered the chat.

Or that time an S3 developer purged more than intended, causing internet outages.

All the above are from 2017.

Then there was a deployment goof by Knight Capital Group, they lost 440 million in 45 minutes. The company went poof back in 2012 as a result.

MySpace back in 2019 deleted a ton of prod data from users during a botched migration (oops).

Humans make mistakes. Anyone arrogant enough to think they only write perfect code is delusional.

We are holding AI to higher standards than we hold humans, who are just as fallible if not worse.

QA your software, stop letting developers test changes.

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

#185

I'm here just for the comments...

These discussions remind me of two quotes:

“This is just a moment in time. Step aside and let it happen.” - Inara Serra, Firefly.

"Your effort to remain what you are is what limits you." Puppet Master, Ghost in the Shell.

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

#186
post #172
post #147

Earlier quoted context omitted.

The intention of the title is to say your main problem. The problem separating you from $PROFIT$: 1. Idea 2. ??? 3. Profit Coding effectively is definitely one problem. And you're right that AI helps with that problem. But for startups, side-hustles, VC-pitches and the inner-workings of companies (HN crowd) coding was never the problem. edit to add: So for people working on professional software teams, the discussion…

> But for startups, side-hustles, VC-pitches and the inner-workings of companies and so on (HN crowd) coding was never the problem. I'd say you're 180° wrong. Getting to an MVP fast is the most immediate problem when you've started a startup. Iterating on ideas fast is the most immediate problem once you've released your MVP. You need an MVP to get users, and you need to to iterate to find product-market fit. Perfect…

This isn't in defense of perfectly crafted code. It's about NO CODE. Do not write (ai-moar) code! It's not the code that is the problem.

I understand the need for MVP to bring an idea into reality. It's the feedback that's valuable not the code. This is not about the code. So why is the argument "write more code"?

In any case, I have yet to create a product on my own that has done well financially. So what the hell do I know. If you have, then I should probably listen to you. But I have worked on teams for successful companies and in my career, the best advice I can give to an engineer is that your code matters, do a good job and care about what you make; also it's not about the code.

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

#187

Earlier quoted context omitted.

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

>at least one of the FAANGs already had auto-complete so good it could do most of what LLMs can practically do

Could you clarify what you're referring to? I'm interested.

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

#188
I read this book last year and this application is spot on. There is a point in the narrative when the company automates a step in their manufacturing using an expensive machine and it has the effect developed here: the next step in the process is backed up further.

The points specific to software where it might not even be producing in-spec is also very good.

Comments that cite the solo dev/prototype case are of course not what this is getting at, but it's one good use of quick generation.

I would extend this article by saying what The Goal says, namely that the goal of every firm is to make money, and everything is intermediate to that. So whether or not software architecture is grade-A or grade-C, it's only ever in this subservient role to the firm's goal.

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

#189
Code-writing speed is not a bottleneck when the stakes are high. Sometimes, it's better to slow down, plan ahead, and consider the consequences because the cost of a failed iteration is too great.

Take the way AI is being developed as an example. People rush to build giant agents in giant datacenters that are aligned to giant corporations and governments. They're building the agentic organism equivalent of machiavellian organizations, even though they'd be better off building digital humans that are aligned to individual humans that run on people's gaming PCs at home. They will find out that the former is the wrong architecture, but the cost of that failed iteration is the future of human civilization, and nobody gets a second try.

Of course, this is an extreme example on one end of the scale. On the other end, it wouldn't matter at all if you're building a small game for yourself as a weekend project with no users to please or societal impacts to consider.

Post reply on HN