> 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.
Just about every professional coding job I've ever had has had programmers eager to code more, complaining about how much rigmarole there is around making changes, complaining about constant meetings and endless bureaucracy around change management and requirements. Meanwhile business mostly saw programmer velocity and output as a problem and a business risk, as they struggled to keep up with the rate of change and kept stepping on the brakes.
Like realistically even without LLMs I output probably around 10x as much code working alone, self-employed with zero meetings or bureaucracy, than I've ever done as a professional programmer. My output sometimes rivals that of entire teams' I've been part of, mostly because I get to just code to my heart's content.
> My output sometimes rivals that of entire teams' I've been part of, mostly because I get to just code to my heart's content.
The fact is that often I code less than most of my peers. Because I prefer spending some time to design suitable data structures/algorithms for the problem at hand. I don't aim for perfection, just that it align with the business domain (and/or the interface) so that future works are proportional with the scope of change requests. This has reflected in small commits because the fundamental core of the business domain rarely changes (when they do, we have bigger problems than my writing speed).
So I've never seen the need to increase my writing speed, because there's never any need to do so. What I'd like to increase is the speed the Product team get back to me with answers to my questions. Because that's often the real bottleneck.
> Fall behind what? Able to produce "as much" what?
Customer meaningful features that move the needle on the business.
I think this is strictly true. And not because LLMs can write code faster. I think it's true even if you're still writing most of your code by hand and using the LLM as an assistant.
My anecdotal but decades-long observation is that most of the time=cost of a project comes not from writing code, but from dealing with "issues". Weird bugs, surprising behaviors, spec ambiguities, library defects, mysterious test failures, etc. Stuff that requires intense debugging and building out a mental map of code that might not even be yours. LLMs excel at this kind of thing, freeing you up to spend most of your time working on business logic.
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.
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.
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.
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.
We have general expectations on the velocity an engineer should be able to work at. If it took someone 5 weeks to deliver the exact same thing another engineer could deliver in 1 week, that would be considered "falling behind" at most places. Would you disagree?
And as technology improves, so do expectations. I remember when 10+ minute compile times after every change were completely normal (i.e. when this XKCD [1] still made sense). Now compile times are generally much better -- on many projects, you can even hot reload in under a second. I can implement things much faster now, and so can everyone else. The same sort of improvement happened with IntelliSense, CI, the explosion of open source libraries, etc.
The notion of falling behind because you refuse to adopt an advance in the field seems both uncontroversial and not aggressive at all to me.
No, he is correct. LLMs have much larger working memories for the kind of details you work with in programming tasks. You are at an objective cognitive deficit by not taking advantage of this. Everybody knows what he means by left behind. When you program, you do so with a goal in mind, and you will not be able to reach that goal as quickly without LLMs. You will be outcompeted by those who use them, and this means that opportunities to contribute professionally, in open source, etc. will be closed to you.
127. A technological advance that appears not to threaten freedom often turns out to threaten it very seriously later on. For example, consider motorized transport. A walking man formerly could go where he pleased, go at his own pace without observing any traffic regulations, and was independent of technological support-systems. When motor vehicles were introduced they appeared to increase man’s freedom. They took no freedom away from the walking man, no one had to have an automobile if he didn’t want one, and anyone who did choose to buy an automobile could travel much faster and farther than a walking man. But the introduction of motorized transport soon changed society in such a way as to restrict greatly man’s freedom of locomotion. When automobiles became numerous, it became necessary to regulate their use extensively. In a car, especially in densely populated areas, one cannot just go where one likes at one’s own pace one’s movement is governed by the flow of traffic and by various traffic laws. One is tied down by various obligations: license requirements, driver test, renewing registration, insurance, maintenance required for safety, monthly payments on purchase price. Moreover, the use of motorized transport is no longer optional. Since the introduction of motorized transport the arrangement of our cities has changed in such a way that the majority of people no longer live within walking distance of their place of employment, shopping areas and recreational opportunities, so that they HAVE TO depend on the automobile for transportation. Or else they must use public transportation, in which case they have even less control over their own movement than when driving a car. Even the walker’s freedom is now greatly restricted. In the city he continually has to stop to wait for traffic lights that are designed mainly to serve auto traffic. In the country, motor traffic makes it dangerous and unpleasant to walk along the highway. (Note this important point that we have just illustrated with the case of motorized transport: When a new item of technology is introduced as an option that an individual can accept or not as he chooses, it does not necessarily REMAIN optional. In many cases the new technology changes society in such a way that people eventually find themselves FORCED to use it.)
> 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.
Some of my colleagues say they don't want to be "AI proofreaders", that they'd prefer to do something else. I can't really argue, they are entitled to their own desires of course. But I do enjoy the chat sessions with agents. It's like pair programming with superman.
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.
I think this is a flawed analogy. In the past when we had a new way of doing something that obsoleted the old way, it replaced it because it was an obvious improvement. I mean, stop motion is cool, but obviously there are limitations.
The deal GenAI offers is: the result will be mediocre at best, on average it will be slop, but it will do it much faster. Ok, that's a fair value proposition in certain contexts. We've always had a need to prototype things fast, and the tradeoff with a prototype is always quality.
However, we're living in an age where we have WAY TOO MUCH in the way of information byproducts, even before AI. How many people do you meet that are like "God, I just wish I had more software in my life!" Most people don't want more software, they want less software that works better. They want more quality and less quantity. It's like this in almost everything digital now. I sign onto Netflix and I can't find anything to watch, even though there's more to watch than I could consume in a lifetime. I live in abundance but I don't want any of it.
GenAI offers us an abundance of stuff we don't want or need (lots of bad code, lots of bad writing, lots of bad illustrations, lots of bad videos) at a cost of stuff we do not have in abundance (energy, attention, natural resources, jobs). It strikes me as a bad trade: lets transform the stuff we need into stuff nobody wants, while decimating our culture in the process.
Anyway, FWIW I do agree with his point that the job has always been problem solving. I use LLMs to solve problems, I'm not extinct. But I'm not going to pretend that I think this is a net win.
You can accomplish quite a lot with smaller local models on reasonably priced pro tier hardware (not cheap hardware, but very attainable hardware for anyone making average software engineer money). Qwen 3.6 27B and 35BA3, Gemma 28B, and so on are incredibly beneficial even if Anthropic and OpenAI produce better options.
Failing that, GLM 5.2 is open weights, trades blows with current frontier models and widely available on commodity inference providers. And you could run it yourself if you do actually have the resources.
Even with locally runnable small "open" models you are relying on scraps of others. They are much worse at the LLM game and you don't know when they stop releasing the weights.
How can you go the opposite direction? Instead of using LLMs to produce more code, can you produce less, maybe higher abstraction code?
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 in general or LLMs in particular, but the proprietary entities that control the best models.
That's the part HN'ers seem to have the most trouble with. They protest AI qua AI, as if that's somehow going to help, when they should be fighting for independent development and universal access.
I mostly like this article but
> 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.
Just about every professional coding job I've ever had has had programmers eager to code more, complaining about how much rigmarole there is around making changes, complaining about constant meetings and endless bureaucracy around change management and requirements. Meanwhile business mostly saw programmer velocity and output as a problem and a business risk, as they struggled to keep up with the rate of change and kept stepping on the brakes.
Like realistically even without LLMs I output probably around 10x as much code working alone, self-employed with zero meetings or bureaucracy, than I've ever done as a professional programmer. My output sometimes rivals that of entire teams' I've been part of, mostly because I get to just code to my heart's content.
> My output sometimes rivals that of entire teams' I've been part of, mostly because I get to just code to my heart's content.
The fact is that often I code less than most of my peers. Because I prefer spending some time to design suitable data structures/algorithms for the problem at hand. I don't aim for perfection, just that it align with the business domain (and/or the interface) so that future works are proportional with the scope of change requests. This has reflected in small commits because the fundamental core of the business domain rarely changes (when they do, we have bigger problems than my writing speed).
So I've never seen the need to increase my writing speed, because there's never any need to do so. What I'd like to increase is the speed the Product team get back to me with answers to my questions. Because that's often the real bottleneck.
> Fall behind what? Able to produce "as much" what?
Customer meaningful features that move the needle on the business.
I think this is strictly true. And not because LLMs can write code faster. I think it's true even if you're still writing most of your code by hand and using the LLM as an assistant.
My anecdotal but decades-long observation is that most of the time=cost of a project comes not from writing code, but from dealing with "issues". Weird bugs, surprising behaviors, spec ambiguities, library defects, mysterious test failures, etc. Stuff that requires intense debugging and building out a mental map of code that might not even be yours. LLMs excel at this kind of thing, freeing you up to spend most of your time working on business logic.
This has certainly been my experience.
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.
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.
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.
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.
We have general expectations on the velocity an engineer should be able to work at. If it took someone 5 weeks to deliver the exact same thing another engineer could deliver in 1 week, that would be considered "falling behind" at most places. Would you disagree?
And as technology improves, so do expectations. I remember when 10+ minute compile times after every change were completely normal (i.e. when this XKCD [1] still made sense). Now compile times are generally much better -- on many projects, you can even hot reload in under a second. I can implement things much faster now, and so can everyone else. The same sort of improvement happened with IntelliSense, CI, the explosion of open source libraries, etc.
The notion of falling behind because you refuse to adopt an advance in the field seems both uncontroversial and not aggressive at all to me.
[1] https://xkcd.com/303/
Those who do not transform themselves into paperclip maximizers will become paperclips.
No, he is correct. LLMs have much larger working memories for the kind of details you work with in programming tasks. You are at an objective cognitive deficit by not taking advantage of this. Everybody knows what he means by left behind. When you program, you do so with a goal in mind, and you will not be able to reach that goal as quickly without LLMs. You will be outcompeted by those who use them, and this means that opportunities to contribute professionally, in open source, etc. will be closed to you.
This is the future. Adapt or die.
I use the 1M token opus claude for two days to build a dashboard and it forgets how to run the build script it wrote at the start of the project.
Man can it put together a react app lickety split, though
Those times are passing and you'll sooner or later meet with new reality.
> 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.
I don't want to curate my own AGENTS file. I'd rather just copy someone else's verbatim similar to code formatting style.
Fabien, care to share your whole file? I'll plug it into my NixOS machine.
Did Tippett enjoy working on the Dinosaur Input Device as much as he did with his go-motion technique?
I see employability being discussed far more often than joy.
If your motivation was selling as many clothes as possible, then the industrial textile revolution was miraculous.
If you enjoyed knitting threads together, it was the crushing victory of mediocrity.
Some of my colleagues say they don't want to be "AI proofreaders", that they'd prefer to do something else. I can't really argue, they are entitled to their own desires of course. But I do enjoy the chat sessions with agents. It's like pair programming with superman.
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.
> 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.
On the negative side, the code may not work.
But on the positive side, no dependencies.
I think this is a flawed analogy. In the past when we had a new way of doing something that obsoleted the old way, it replaced it because it was an obvious improvement. I mean, stop motion is cool, but obviously there are limitations.
The deal GenAI offers is: the result will be mediocre at best, on average it will be slop, but it will do it much faster. Ok, that's a fair value proposition in certain contexts. We've always had a need to prototype things fast, and the tradeoff with a prototype is always quality.
However, we're living in an age where we have WAY TOO MUCH in the way of information byproducts, even before AI. How many people do you meet that are like "God, I just wish I had more software in my life!" Most people don't want more software, they want less software that works better. They want more quality and less quantity. It's like this in almost everything digital now. I sign onto Netflix and I can't find anything to watch, even though there's more to watch than I could consume in a lifetime. I live in abundance but I don't want any of it.
GenAI offers us an abundance of stuff we don't want or need (lots of bad code, lots of bad writing, lots of bad illustrations, lots of bad videos) at a cost of stuff we do not have in abundance (energy, attention, natural resources, jobs). It strikes me as a bad trade: lets transform the stuff we need into stuff nobody wants, while decimating our culture in the process.
Anyway, FWIW I do agree with his point that the job has always been problem solving. I use LLMs to solve problems, I'm not extinct. But I'm not going to pretend that I think this is a net win.
"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.
You can accomplish quite a lot with smaller local models on reasonably priced pro tier hardware (not cheap hardware, but very attainable hardware for anyone making average software engineer money). Qwen 3.6 27B and 35BA3, Gemma 28B, and so on are incredibly beneficial even if Anthropic and OpenAI produce better options.
Failing that, GLM 5.2 is open weights, trades blows with current frontier models and widely available on commodity inference providers. And you could run it yourself if you do actually have the resources.
Even with locally runnable small "open" models you are relying on scraps of others. They are much worse at the LLM game and you don't know when they stop releasing the weights.
How can you go the opposite direction? Instead of using LLMs to produce more code, can you produce less, maybe higher abstraction code?
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 in general or LLMs in particular, but the proprietary entities that control the best models.
That's the part HN'ers seem to have the most trouble with. They protest AI qua AI, as if that's somehow going to help, when they should be fighting for independent development and universal access.
"they should be fighting for independent development and universal access". Well stated.