> Those who refuse to use an LLM will fall behind because they won't be able to produce as much
Seems like a silly and needlessly aggressive take.
Fall behind what? Able to produce "as much" what? I've never been evaluated on volume in my life. Nor have co workers who were severely "behind" ever feared for their jobs.
Krssst [3 hidden]5 mins ago
Yes, I dislike this kind of take so much. It keeps being repeated as a truthism and a way of putting down people that don't do what the speaker wants. It's fine to disagree, but there's no need to get such a threatening tone.
A lot of tech jobs seem to be only about sheer output volume, with quality (maintenability, availability, security, generally understanding what the thing is doing) not mattering much. In that case sure, LLM all the way and whatever happens happens. But not all jobs are like that.
inglor_cz [3 hidden]5 mins ago
My experience with regard to quality is quite the opposite.
With LLM at my disposal, I had the time- and effort-budget to expand test suites considerably, I was even able to attack a somewhat thorny question of reproducible builds on MSVC, which is not exactly friendly towards determinism.
These tasks would take me personally so much time that I would have to set them aside, at the cost of output quality.
zdragnar [3 hidden]5 mins ago
This is very much an N=1 anecdote from a friend, but his manager has basically doubled velocity expectations for the team at his company over the last year. Everyone has to use Claude code because that's the only model they're allowed to use, and not using it means not hitting the arbitrary expectations.
Conversely, the company I am at has no such expectations, and we've got a legacy code base that LLMs aren't very handy in anyway.
CamperBob2 [3 hidden]5 mins ago
we've got a legacy code base that LLMs aren't very handy in anyway
So do I. What I'm finding is that they are now.
I've spent the last week tracking down bugs using Fable that have gone undiagnosed for several years. And this is a damned obscure legacy code base that runs on a proprietary 8051 variant. Guaranteed to be nothing like it in-distribution.
bryanlarsen [3 hidden]5 mins ago
> I asked an LLM to write a Levenshtein distance function instead of adding a dependency to my project.
Which you likely failed to review thoroughly, so may be subtly wrong.
lnrd [3 hidden]5 mins ago
> Writing every line by hand is no longer the norm. Those who refuse to use an LLM will fall behind because they won't be able to produce as much
> It remains important to be able to read the code and understand the architecture. As a result, I reduce my velocity by iterating over my PR until it reaches the same level of quality I would have produced "by hand"
I do that too and when I do it I'm not sure anymore if I'm "producing as much more" than if I was doing it by hand. I need to spend time to read the code, break down the flow so that it clicks in my head and so that I'm 100% sure that I understand what is going on and what every line does. And then I still test it (executing it), because that's where you notice the edge cases anyways.
Once I understand it and test it, the part where I iterate or fix small quirks and hallucinations is the smallest part of the job and is irrelevant if i do it by myself or ask the LLM to make the change.
I'm still not convinced that I'm faster with an LLM at all, since I add this new bottleneck (the time spent understanding every line). If I do it by hand it already clicks in my head, so it's faster for me to test it, find unaddressed edge cases and then confidently ship it. Maybe the LLMs gains are not in this at all and writing every line by hand will still be the norm for a long time.
Still, LLMs make me insanely faster in: finding something in the codebase, recostructing a flow and understanding the architecture, triaging a bug (sometimes it just solves it with a prompt), writing and updating tests, reviewing changes for potential issues. These days I have almost always 2/3 agents running doing something of the above.
That saves me hours and you can pry an LLM from my dead hands, but I'm still not sold that it makes me faster at producing production grade code that I fully understand and follows my company architecture and standards.
Then sure, if I need to make a prototype or a small tool for myself or some novelty thing, an LLM can do it without me ever touching or reading the code. But I think that's not what the majority of software engineers are employed to do.
pocksuppet [3 hidden]5 mins ago
It's probably best to learn about LLMs, and then don't use them most of the time. It's much harder to justify not even knowing how the new thing works, than to justify not using it because the old thing is better.
01284a7e [3 hidden]5 mins ago
"Ride the wave."
Or don't.
Most LLMs people are using to code are paywalled, and controlled by private, for-profit entities.
This is fundamentally different than the past, and diametrically opposed to the hacker.
If you're a hacker, which most of you are not (things have changed here over time), you will reject this.
CamperBob2 [3 hidden]5 mins ago
If you're a hacker, which most of you are not (things have changed here over time), you will reject this.
You'll also recognize that the problem is not AI or LLMs, but the proprietary entities that control the best models. That's the part HN'ers seem to have the most trouble with. They fight AI, when they should be fighting for universal access to it
HN.zip
> Those who refuse to use an LLM will fall behind because they won't be able to produce as much
Seems like a silly and needlessly aggressive take.
Fall behind what? Able to produce "as much" what? I've never been evaluated on volume in my life. Nor have co workers who were severely "behind" ever feared for their jobs.
A lot of tech jobs seem to be only about sheer output volume, with quality (maintenability, availability, security, generally understanding what the thing is doing) not mattering much. In that case sure, LLM all the way and whatever happens happens. But not all jobs are like that.
With LLM at my disposal, I had the time- and effort-budget to expand test suites considerably, I was even able to attack a somewhat thorny question of reproducible builds on MSVC, which is not exactly friendly towards determinism.
These tasks would take me personally so much time that I would have to set them aside, at the cost of output quality.
Conversely, the company I am at has no such expectations, and we've got a legacy code base that LLMs aren't very handy in anyway.
So do I. What I'm finding is that they are now.
I've spent the last week tracking down bugs using Fable that have gone undiagnosed for several years. And this is a damned obscure legacy code base that runs on a proprietary 8051 variant. Guaranteed to be nothing like it in-distribution.
Which you likely failed to review thoroughly, so may be subtly wrong.
> It remains important to be able to read the code and understand the architecture. As a result, I reduce my velocity by iterating over my PR until it reaches the same level of quality I would have produced "by hand"
I do that too and when I do it I'm not sure anymore if I'm "producing as much more" than if I was doing it by hand. I need to spend time to read the code, break down the flow so that it clicks in my head and so that I'm 100% sure that I understand what is going on and what every line does. And then I still test it (executing it), because that's where you notice the edge cases anyways. Once I understand it and test it, the part where I iterate or fix small quirks and hallucinations is the smallest part of the job and is irrelevant if i do it by myself or ask the LLM to make the change.
I'm still not convinced that I'm faster with an LLM at all, since I add this new bottleneck (the time spent understanding every line). If I do it by hand it already clicks in my head, so it's faster for me to test it, find unaddressed edge cases and then confidently ship it. Maybe the LLMs gains are not in this at all and writing every line by hand will still be the norm for a long time.
Still, LLMs make me insanely faster in: finding something in the codebase, recostructing a flow and understanding the architecture, triaging a bug (sometimes it just solves it with a prompt), writing and updating tests, reviewing changes for potential issues. These days I have almost always 2/3 agents running doing something of the above. That saves me hours and you can pry an LLM from my dead hands, but I'm still not sold that it makes me faster at producing production grade code that I fully understand and follows my company architecture and standards.
Then sure, if I need to make a prototype or a small tool for myself or some novelty thing, an LLM can do it without me ever touching or reading the code. But I think that's not what the majority of software engineers are employed to do.
Or don't.
Most LLMs people are using to code are paywalled, and controlled by private, for-profit entities.
This is fundamentally different than the past, and diametrically opposed to the hacker.
If you're a hacker, which most of you are not (things have changed here over time), you will reject this.
You'll also recognize that the problem is not AI or LLMs, but the proprietary entities that control the best models. That's the part HN'ers seem to have the most trouble with. They fight AI, when they should be fighting for universal access to it