If you thought code writing speed was your problem you have bigger problems
181–190 of 231 posts
Re: If you thought code writing speed was your problem you have bigger problems
#182Earlier 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.
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
#183Then 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
#184How 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…
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
#185I'm here just for the comments...
“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
#186Earlier 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…
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
#187Earlier 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...
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
#188The 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
#189Take 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.