> 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.
Fabien, care to share your whole file? I'll plug it into my NixOS machine.
Which you likely failed to review thoroughly, so may be subtly wrong.
> 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.
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.
I left in the late 2010s, Lots of competition meant that wages were kept down, and hours fucking long. It was fun, I loved being at the intersection of Art, infrastructure and programming.
I fear for the future.
I hope that I am ok, because I have experience of high scale that is not really in the training corpus. I've also been in ML for a reasonably long time, so have more experience of getting the dipshit machine to do useful things.
But thats pretty thin gruel.
I am rapidly approaching middle age, which means that no fucker is going to employ me as an apprentice if I want to re-train. My techincal and artistic skills are basically replaced. They are the equivalent of Linotype expert. Technically impressive but utterly fucking pointless for a world where newspapers are dead and so is analog printing. In 40 years I could possibly make a thin living as an artisan. But I plan on being dead by then.
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.
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.
But on the positive side, no dependencies.
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.
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.)
How can you go the opposite direction? Instead of using LLMs to produce more code, can you produce less, maybe higher abstraction code?
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.
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.
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.
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.
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.
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.
Because it’s literally not going to happen. The existence of LLMs is a function of how much capital you have. Frontier models require so many resources to train and run that they are functionally inaccessible to the average person.
That’s why capital loves them! It’s a resources play.
You’re also conveniently leaving out all of the other negative aspects of LLMs/GenAI with regards to the arts, open communication, etc..
My hobby AI projects feature wise match existing company offerings in about a week of turn around. But this alone is valueless. The new thing that didn't exist before 2026 will remain the hard moat. But these moats will dissolve as fast as OpenAI can scrape your public marketing. It's going to be like releasing Meccha Chameleon as a break out hit but a month later the clones on Roblox having greater player numbers. This is the turn around times we're going to have to live with in general for business pivots to the "next" business logic that makes sense in the market.
Closer to the AI world it's going to be as fast as the transition from prompt engineering and MCPs to loop engineering and harnesses. I'm pretty confident popular commentators will see "loops" as old hat by December by raw function of what speed of evolution we're dealing with here now.
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.
Or at the very least: "It was never about the actual coding" and "coding more separates you from those who will fall behind" is classic kettel logic.
That's not very hard with many of the teams I've seen, with or without LLMs. Though the old adage of "If you want to go fast, go alone. If you want to go far, go together" still applies.
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.
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.
I only snark at those who try to mislabel that thing as something useful. Which it is not.
I'm doing this at LLM speed now.
I feel like I'm doing the work of two whole teams and designing rock-solid software.
Rust, strong types, enums, fantastic interfaces, brevity.
This isn't to say that LLMs aren't impactful, but that there's an argument for viewing them less as being a fundamental shift in how our profession works and more as another tool we can use to pursue essentially the same goals more efficiently than before. Like any other tool that's worth having, they can do things our existing tools couldn't do as well, or else we wouldn't have added it to our toolbox, but you still need to be able to recognize when to use it and when not to (and potentially how to use it when you do).
I think that part of why these tools are so polarizing is that there was already some assymetry in how much longer it takes to clean up things than to create things that need to be cleaned up, so a new tool that makes everyone more productive has a lot of potential to exacerbate the existing imbalance. To make up some numbers for illustrative purposes, if someone introduced four new flaky tests in the time it took to fully diagnose and clean up one, and then LLMs came and made everybody twice as productive, now in the same amount of time someone might introduce eight flaky tests while you fixed two, so you're falling behind twice as fast. Unless the productivity gain disproportionately speeds up the people working on making things more robust and polished (which I find dubious; if anything I think the opposite seems more likely) or LLMs suddenly make everyone who didn't care about quality when rushing things out take it more seriously (which seems even more dubious), then LLMs don't improve the situation for people who already felt that the balance was slanted too heavily towards speed over quality.
That's why they call us "hackers," and they call you something else.
Jul 10, 2026
Don't you mean extinct?
In 1993, Jurassic Park came out and revolutionized the use of CGI in films[1]. To the public the experience was magic. But for some of the people in the movie industry, it was a rude awakening.
Director Steven Spielberg had hired stop-motion master[2] Phil Tippett[3] to bring the film's full-body dinosaurs to life using his go-motion technique. Spielberg was highly skeptical that computer-generated imagery (CGI) could realistically depict a dinosaur[4]. But Dennis Muren and the digital artists at Industrial Light & Magic (ILM) worked on a proof-of-concept using CGI. They rendered a fully textured, photorealistic T. rex chasing a herd of Gallimimus in full sunlight.
I went down with [visual effects supervisor] Dennis Muren when he presented the T-Rex test to Steven and Steven went, ‘Wow, that’s what we’re going to do,’ and he asked me how I would feel and I said, ‘I feel extinct’[5].
I did seem like everything that I had built up until that time was like, "We are not going to do that anymore"[6].
Phil Tippett
Tippett, who had already selected a crew of thirty and was gearing up for the massive go-motion assignment, was understandably devastated by the turn of events. The Making of Jurassic Park
I have been thinking of this anecdote a lot lately. I see a lot of pessimism[7] around programmers. The anxiety of becoming obsolete is particularly palpable online[8][9].
Evolve
The best way to avoid becoming extinct is to evolve. I liked zkmon's take from Hacker News.
Ride the wave. You rode it when websites/webapps were the wave. I came into software industry before internet, kept changing my horse. You are never too old to learn new tricks. The new wave create new kind of work and workers. Be one of them. Ride the beast, master the tools. It's the same game again.
While the current episode reminds zkmon of the mid-90s web, it makes me think of the field of Computer Graphics in the early 2000s and the rise of "Mobile First" in early 2010s. Every generation of programmers will likely have seen a form of r-evolution. This is indeed the same game again. Life is flux[10]. LLMs are yet another tool. To evolve is to invest the time to learn how it works and how to best use it.
Learn how LLMs work
The best resource I found to learn how LLMs work is Andrej Karpathy's channel. The man obviously cares deeply about LLMs and really wants you to get them. His series of videos so far is 25 hours of pure gold.
A nice follow-up is the book Build a Large Language Model (From Scratch) by Sebastian Raschka. There are many drawings in full-color with rare Now Draw the Owl moments. This is a really good book.
Learn how to write code with LLMs
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 - and I know several developers who refuse to use agents. John Carmack recently had an interesting take about coding.
“Coding” was never the source of value, and people shouldn't get overly attached to it. Problem solving is the core skill. The discipline and precision demanded by traditional programming will remain valuable transferable attributes, but they won't be a barrier to entry.
Many times over the years I have thought about a great programmer I knew that loved assembly language to the point of not wanting to move to C. I have to fight some similar feelings of my own around using existing massive codebases and inefficient languages, but I push through.
Even though I am not writing code, I am still indirectly producing code. And there is considerable discretion about what one can generate. If I go "full-vibe-code" and let an LLM run, I can produce 1000x what I used to and find myself with an indecipherable mess. Is that a bad thing? If I work on a prototype or a small personal project, it does not matter. But for everything else, code quality still matters tremendously. LLMs may claim they still understand the project and suggest solutions, but I have seen them fail spectacularly and hallucinate.
It remains important to be able to read the code and understand the architecture. It may sound like a given, but I have seen many developers fail to do so. 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". Every time I notice something I don't like, I add it to my ~/.gemini/GEMINI.md/~/.claude/CLAUDE.md so the agent can emulate my style. Over the past months, I have added quite a few lines like the following.
- Don't use magic numbers or strings. Use a const or even better, an enum when appropriate.
The greatest difficulty I have encountered is "context switching". Working on multiple projects / independent features allows me to drive multiple agents simultaneously. It is quite a mental gymnastics to keep up. I have seen reports of "mental burnout" and I have also personally experienced increased mental fatigue. This is definitely something to monitor.
Code Review in the age of LLMs
Given how much better the tools are, I have much higher expectations during code reviews.
There is little excuse for poor commit messages now. There are many guides about how to write a good commit message. Here is the best one I ever came across. It takes 1 minute to ask an LLM to summarize it and transform it into directives that one can add to their GEMINI.md/CLAUDE.md.
When you write a commit message, follow these 7 rules: Rule 1: Separate the subject line from the body with a single blank line. Rule 2: Limit the subject line to 50 characters (72 is the absolute hard limit). Rule 3: Capitalize the first letter of the subject line. Rule 4: Do not end the subject line with a period. Rule 5: Use the imperative mood in the subject line (e.g., "Fix bug," "Add feature," not "Fixed" or "Adds"). Test formula: It must complete the sentence: "If applied, this commit will [your subject line here]". Rule 6: Wrap the body text manually at 72 characters to prevent Git formatting issues. Rule 7: Use the body to explain what and why vs. how. Assume the code explains the how; the message must explain the context and reasoning.
Since authoring code is much less of an effort, I expect SWEs to take much more care into designing elegant solutions. I have little scruples in asking for improved code clarity/code simplicity if the PR is a mess.
The same goes for PR code size. It used to be tedious to break a PR into smaller, easier-to-review, parts. This is no longer the case and I have no problems asking an author to break down their PRs unless they have a good reason for it.
Many code review tools now have integrated LLMs. You can create your own preferred prompt to automatically perform a first pass. For codebases I own, I have added the content of my GEMINI.md/CLAUDE.md which I can trigger with one click. Before sending a PR for review, the first thing I do is ask for the LLM to criticize/look for mistakes. This avoids wasting the reviewer's time on the other end.
Writing tests used to be a pain. This is no longer the case. It is ok to request unit tests/CI tests for each PR. These have never been more important since large refactors are becoming increasingly common. Human and LLM review may miss stuff but good tests should catch breakages.
It is more ok to refuse to take dependencies now. It used to be the go-to solution to avoid writing anything moderately complex. As recently as this morning, I asked an LLM to write a Levenshtein distance function instead of adding a dependency to my project.
Smaller teams
We can accomplish more with smaller teams. We may not be far from the '90s model, when a team of four could produce professional software. I was able to revive projects I had abandoned because I deemed them too time-consuming or complex. Last month I completed the reverse engineering of the Silpheed video format and I am making good process on Ikaruga for Dreamcast and Zelda: A Link to the Past on SNES.
If you can't beat them, join them
The LLM scene is fascinating. And amusingly the very subject to study is also a great tool to help keep up. An LLM will help to dive into any codebase and give pointers about the overall architecture. I have been enjoying reading how llama-cpp, OpenCode, ollama, and vLLM work. There are also many hardware solutions, like Tenstorrent, Etched, MatX, d-Matrix, or Cerebras Systems that are super interesting to follow.
Reading research papers was difficult at first since I have always had a difficult relationship with mathematics notation. LLMs helped to catch up with shortcomings. Having a buddy offer their opinion, and double checking it, helps a lot to ramp up.
Find the motivation
Most importantly, there is the problem of finding the motivation to learn. There are many good reasons to avoid making the effort, among them stories of people finding success by moving on.
To keep on going or not is a decision that belongs to each of us. It is the result of a process involving conviction and inspiration. While the former comes from within, I sometimes find the latter in success stories. This takes me back to the anecdote at the beginning of the article. I did not pick Phil Tippett's story randomly. While many know the misquoted "Don't you meant extinct?" part, what happened next is less notorious.
Despite the initial shock, Tippett, at 41 years old, was far from being "extinct". Spielberg kept him on as the film's "Dinosaur Supervisor." Because the computer animators at ILM were programmers and tech artists rather than traditional performance animators, they had no idea how to make a creature move with weight, timing, and biological intent.
Tippett co-developed the Dinosaur Input Device (DID)[11], a highly articulated physical armature connected to sensors, with ILM. Then his team physically manipulated the DID just like stop-motion, and the computer translated those movements into the digital space.
Phil Tippett (along with Dennis Muren, Stan Winston, and Michael Lantieri) won the Academy Award for Best Visual Effects for Jurassic Park in 1994[12]. His company, Tippett Studio, lived on to take part in movies such as StarShip Troopers, Dragonheart, and seventy-five other titles[13].
References
*
