> 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.
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.
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.
That's not what suitable data structures/algorithms mean. What you stated are mere helpers and still pertains to the realms of coding, not design.
Coding isn't and never was the issue. It is a tool and not the intent. Think about what would stand universally true whether you use Go, C, JavaScript, Assembly,... The organization of data (information), and the process of transforming it (computation).
Those do not depends on code. We already have basic ones like the list, the map, the stack, the queue, the binary tree, the graphs,... But for any business domain, you can create more specific ones. And like the basic one, they do not depends on code. The code depends on them.
So writing code faster does not make the design better.
No but it lets you iterate faster. Who hasn't come up wit the most perfect elegant design, only to come up against three reality of implement and an "oh we forgot about that" aspect. Except by then, it's too late to change, so you march on. Writing code faster lets you find the things you didn't think of faster so then you get to design it again but better this time.
The waterfall method of software development is well studied and while agile is no panacea, there's a reason the industry has moved away from multi-year waterfall development practices.
It used to be, before LLMs. It was standard practice though.
If you have a bad design that's had contact with reality for a while, it's much easier to make it actually good, rather than figure stuff out up front (I've rarely made this work, even though I'd love to).
> Who hasn't come up wit the most perfect elegant design, only to come up against three reality of implement and an "oh we forgot about that" aspect
The mistake here is trying to come up with the most elegant design. You solve for what’s needed with the knowledge that you’ve most likely not captured the full situation, and make allowance for future changes.
I don’t want faster code. What I want is flexibility in evolving my design and there’s plenty of good tools and practices for that. From ensuring your code is testable to ensuring there are easy ways to experiment with parts of it.
I’ve never been in a situation that says “We’ve not think of that, we need to get back to the drawing board”, It’s been mostly “We need a new version of this module to support this feature”
Lol, I just don’t rush into coding when I could talk with the customer/user (or Product). And I shape my codebase into something I can easily experiment upon. Which means I try for it to be modular with suitable abstraction that I can easily tweak.
> My output sometimes rivals that of entire teams' I've been part of
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.
Unless you encounter circumstances where it's death by committee (or something similarly bad), but overall I agree! It's just that you don't have the bad environment risk/problem when it's just 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.)
Yup, that is called progress. One freedom to live in a cave with his 6 spouses and hunting animals all day was indeed taken away. In exchange you don't need to hunt all day, you can go to groceries, you don't need six spouses and 20 kids, as kids death rate is not 80% but 0.001%.
One can, obviously, romanticize the times of cave live, that's fine with me, but I doubt that would be a common choice.
I really believe in technological progress and would strongly defend and advocate for it. I'm also very distressed by the idea that we have an absolute ratchet of more surveillance (and registration, monitoring, and licensing of people and their daily activities) over time.
My intuition has always been that these things don't have to go together, but it's often sounded like a number of people who've thought about it a lot expect that they do! Can anyone reassure me about this? Is there a future in which people have greater capability, and there are also fewer institutions or mechanisms proactively monitoring us?
I'm aware of portions of the history of that conversation but would love to hear your take or the take of other HN members.
I think a lot of HN'ers are in denial. I was an LLM skeptic check my history if you like. At the beginning of 2026 LLMs shifted over the hump to as good or better than most devs and are continuing to get better. I don't think we've even begun to see how this is going to affect the industry. People in charge don't and never have cared about code quality, tech debt, maintainability. Now they will not only not care but cease to listen to devs that insist on it.
People on HN will drop what they think is their trump card. Ie The computer spitting out incorrect info. However, I've worked in banking finance where data was wrong and people in charge just shrugged when I showed them and said something like, accounting will catch it. And here's the worst thing. They were right.
I agree. Denial only takes you so far. At some point, the devs that insist on outdated working practices (at least ones the boss regards as such) will be replaced by younger people who either don't know about them, or like their boss, don't care.
They will just generate code that passes the tests also written by the AI, ask the AI to find any bugs, and so long as the code runs without obvious issues, that will get released.
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 wide availability of open source, 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.
> 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.
And I am gradually coming to the conclusion that "needle" isn't even features. In a world where everyone has AI access, moving the needle in an existing product space can readily be done by whoever. The real game changers will be those who redefine their market segment entirely rendering existing offering completely out of customer demand. And the only way to migrate the business to the new model from the ground up in say four to six months will only economically be able to be done by AI.
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.
Realistically, has the volume of code that can be produced ever been the bottleneck? In every job I’ve ever had, it was never that the devs couldn’t write enough code fast enough, it was everything else that slowed them down, mostly other people.
7 years ago my biggest bottle-neck was waiting for a tester to test my code. Fast forward to now, my biggest bottle-neck is waiting for a tester, and my team-mates using AI to generate mega-patches that they don't bother testing is just making it worse.
n=1 but every job i've ever been at was time to code was like 10 or 15% of available time; its all the useless meetings/busywork caused by corporate structure and bad specs etc
I think people are making a bad assumption that features = profit, and that we're going to be trapped in a red-queen race to move in place while shipping features at an astonishing rate. I don't think this is going to happen.
Before subscription services, you needed to add features because you had to justify to people why they should buy an upgrade. So yeah, it made sense to make as many features as possible to try to cast a wide net.
I think with software as a service, making features is not really the most important thing. Realistically, people buy software for what it does right now, not its future potential. Further, changing things out from underneath users tends to annoy them (pretty much EVERY time a service introduces a redesign, even if it's a good one, people initially hate it -- you're asking them to relearn a thing that was working perfectly fine).
Anyway, I think new software is going to win the same way it's always won, based on its utility, not based on shipping features at some sort of frantic rate.
> 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
And those issues often appears because no one had the "time" to properly design a solution before rushing to code. Saving one hour of planning by spending weeks on debugging.
> 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
I've noticed that too. And I think it's no surprise we see lots of "728 security exploits found by LLMs in project X" posts.
They excel at what you mention.
I also think that, as of 2026, they suck fat balls at writing code.
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.
The reality is that everyone will be replaced by a cheaper alternative someday, with LLMs or not. If you depend on LLMs more and more to do your work and the costs of keeping your tokens increases, your 'left behind' co-workers will still be fine.
Exactly, it's pretty obvious, and definitely as you sail, not aggressive (someone melts a little too easily) The comment was naive to the point of denial.
If it is the future, people will actually have plenty of time to wait and start using it only later. There is no hurry and no reason to be early adopter crash test dummy. They can wait and stary using it at own pace
The "or die" part betrays insecurity and weakness. You need to scare prople into using it rihht now, because of some perceived threat.
I'm curious about what adaptation you have in mind.
You use LLMs to write specific functions? The person who uses it in an agent loop will leave you behind to die.
You use LLMs in an agent loop? The person who uses LLMs to supervise loops will leave you behind to die.
You use LLMS to supervise agent loops? The person who uses LLMs to determine product offering and automatically start supervision on producing the product will leave you behind to die.
You use LLMs to determine product offering and kick off the supervision? The person who uses LLMs to clone your product without the initial product research will leave you behind to die.
You use LLMs to clone products gaining traction? The person who runs a cluster 100x the size of yours will leave you behind to die.
I am trying to understand where you think you fit in, in this Brave New World.
You obviously think that you're adapting, but if you're correct, anything you do now can be replaced by an LLM in the near future.
This one does not require any death threats. It's a statement of where the world is going. Maybe you disagree. Come back to this thread in 3 year and see which POV was more correct. The
* "LLMs suck, are stupid, I hate them, and I'm not using them"
or
* "LLMs are the future and if you don't adapt you'll left behind"
I'm confident it's this 2nd option. Care to wager?
People might be using hyperbole: "You'll be left behind" = "you'll be out of a job" or "you'll be unemployable" or "You'll die" but they all mean the same thing.
This whole you need to "adapt" to LLMs thing is bonkers to me, because there's practically no skill in using an LLM. It took me a weekend to learn how to use a coding harness, and the skill pretty much generalizes to all coding harnesses. The things that make me potentially good at using a coding harness are my preexisting engineering skills. I'm sorry, but I think if you believe that being on the cutting edge of knowing how to prompt is some sort of magical skill that's going to protect you from economic hardship, you're delusional.
Most of the "cutting edge" stuff I've seen is basically trying to scale the amount of parallel work that can be done, without any consideration to how much that costs, how much waste is generated, or if the output is even useful. Most of my coding time is spent thinking through problems. Which is exactly how I spent my time prior to LLMs.
> This whole you need to "adapt" to LLMs thing is bonkers to me, because there's practically no skill in using an LLM.
False. There was a person in this thread complaining about how the LLM forgot to run the build script it itself wrote. Yet people are effectively using LLMs to tackle highly complex, unusual work.
The existence of skill issues implies that skill is needed. This is THE skill that will separate the wheat from the chaff in a software engineering context. There's a reason why Steve Yegge said you're a bad engineer if you're writing code in an editor. It's because you've punted on developing the skillset that will make you vastly more effective.
It's marketing. The big AI companies know what they're doing and are trying to drive adoption with FOMO. Some people bought into the idea early on and feel self-important. Meanwhile, using AI is so easy that it's tantamount to pushing a button, because that's the whole point of it: to make things easy to do. You can pick it up in half an hour, so it's impossible to "fall behind," unless you're holding stock when the bubble inevitably crashes.
I worked for a company that measures developer's output in number of commits, PRs created and approved, and Jira tickets per sprint. Management doesn't even insist on that the tickets have any kind of an effort estimate.
It can be pretty depressing, until you learn how to game the system - create tickets for yourself that are tiny amounts of work. I hear that it's getting harder to do that, because management is looking more carefully at tickets generated and it looks like they'll start having developers assign points to their tickets before the tickets are added to the sprint
It reminds me of people that get upset when other people aren't drinking as much as them at a party. It's like they need other people to consume the thing because they suspect that maybe their consumption will look a little problematic if other people aren't doing it to the same degree.
I don't understand why LLMs are supposed to be able to do things more quickly anyway.
I've tried a couple of times to use Claude to help write stuff, and it sits there for a couple of minutes "thinking" before returning some grossly incorrect code.
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.
This is the path I'm on. I want to know enough about them to actually demonstrate their weaknesses when I choose to not use them for a given task. Upper management doesn't want to hear "because they suck" when they ask why. My company (and many others) just added a new "AI proficiency" metric to their hiring process, and I can take a hint.
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.
> when they should be fighting for independent development and universal access.
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..
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?
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.
Because I'm using my local working brain to work on other things. If I'm thinking about my family or making dinner I'm not thinking about the code I need to write. Or the email that needs to get sent, or setting up an eye doctors appointment. I'd pay for something to deal with that.
It stopped striking like that when you let agents write the code? You don’t think about what agents you can direct while taking a shower or making dinner?
I wish I could stop thinking when I wanted to. The problem is my working memory is very full and being able to hand some of that off, to a paper notebook or a todo app on my phone, or an agent, is valuable.
Was velocity of writing the code ever the limiting factor in this business? If it was/is, why pay for westerners to prompt agents when you can pay for 10 fold more southeast asians to prompt agents?
The expectation is that someone has already done that with a dependency. If the code has just been sharted out by an LLM, it has by definition been reviewed or even understood by no one.
What good would that do me? Levenshtein distance is one of those things that's trivial on the surface, but I have no idea if there are tricky edge conditions.
I do one better: I pull from a trusted creator or I review things like GitHub issues to ensure better people than me have reviewed 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.
I've been thinking of it as a "conservation of cognition". there is some fundamental about of cognition that needs to be spent in order to keep things moving. LLMs do not reduce that, they only change it.
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.
My biggest gripe with AI is that I struggle to come up with even one real problem that it has solved in my daily life, and that of my family and friends.
Yes it might have made me a bit faster at some things I do for work. But it seems to me that we face so many challenges as a civilization, and AI doesn’t actively help with any of them? Unless you buy into the narrative that it will somehow usher in a golden age of abundance where everyone is taken care of and nobody needs to work anymore (utter BS in my opinion). The amount of capital flowing into it, that is then not available for other causes, is completely mind-boggling to me.
> My biggest gripe with AI is that I struggle to come up with even one real problem that it has solved in my daily life, and that of my family and friends.
I wish I could upvote this a thousand times, because this is exactly my experience as well. It's made a few things slightly more convenient, but convenience is not exactly a problem in my life! And yet, it's actively damaging a lot of things I care about in a way that I think is going to be extremely bad for society.
Outside of coding, LLMs have helped me formulate thoughts and have conversations with people that I could never have had without AI. Thorny prickly people problems that previously would have required a therapist and a counselor and group sessions and many meetings can be worked through because I didn't have the volcabulary or expressiveness to say things before. That's not a convenience thing, oh Doordash for milk instead of having to go to the store, that's life changing.
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.
Nothing about AI will stop people doing the work that brings them joy, be it stop motion, or hand knitting a jumper from yarn you made yourself from shearing your own sheep.
You just won't be able to get a job doing it. It will be a hobby, not a way to make a living.
- Avoid using magic numbers and strings. There should be consts or even better enums.
- When working on a patch, you should other the test first. Watch the test fail. Then include the new code. And watch the test pass.
- Leverage early return and continue as much as possible to reduce code indentation.
- Only delete comments if they are obsolete. If you change code, make sure the comment above is still correct.
- Use enums instead of boolean for function parameters.
- Talk to me like an engineer. Don't be excessively verbose. Be down to the point.
- Don't use superlative. Stop praising me, give me the cold hard truth.
- Let the reader of the code breath. Add empty lines between logic block of code. Add a small to the point comment to explain what the block does.
- When you write unit tests, add a short comment at the beginning of the function and class to explain what they test and how they test it.
- Check commit message, if you proof read or write one, 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.
I joined VFX at the start of the 2000s, I rode the evolution of VFX from special effects, to fully digital, and back again (well not quite, "practical" effects are rarely practical, just really good VFX.)
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.
With the improvements that AI has made in just the last year, it should be obvious to anyone that code written by an AI will at some point stop being "AI slop" and be better than the majority of coders are able to put out. Reduced to its basics, all code is just characters put into a sequence. Similar to chess or Go, both of which, it was claimed at one point or another, would be impossible for a computer to beat a human, until they did (chess 1997, go 2016), so computers will eventually produce better quality code than even a team of humans is capable of.
A genuine question : If an AI can reliably write code better than most coders, do it quicker, and produce code that runs efficiently which has less, or at least no more, bugs than human written code, why on earth would a company not use an AI to write all their code for most purposes?
And if they did, why is it important for that code to be 'elegant' or even human readable if the bug checking is also done by AI? (as seems to be the direction we are moving in)
LLMs are statistical prediction machines, they're always going to produce the most "average" code because they reproduce what they're trained on. Average code is bad, and it's going to get a lot worse as people's skills degrade and the training set degrades.
If the code isn't readable to humans, there's no particular reason to think it's going to be magically readable by LLMs either.
Until this year, you would have been right, but in May, the Erdős unit-distance conjecture was disproven by an AI. This required novel thought and reasoning, not just recombining already known facts.
The view that they are only statistical prediction machines is becoming increasingly disconnected from their current abilities.
I probably should have put the word 'easily' before readable. After all, if it is valid code, it can be read.
None of that changes that it's a statistical prediction machine. This isn't me speculating, it's just literally what it is. You can buy a book on how to implement one (I have one!) The fact that it solved a math problem doesn't change that, it just means it was trained on enough math to be able to apply a known technique. These things aren't magic.
The problem was unsolved, it solved it when it was not possible for it to be trained on the solution, therefore your other claim that "they're always going to produce the most "average" code" does not hold up, they can come up with better code than they were trained on precisely because they can apply known techniques to write better code than existed in their training data. The book you have is out of date and does not apply to recent improvements in the field.
The unit distance problem had no known answer and no roadmap. The model identified the problem, chose its own approach, and produced the proof.
I am not convinced by either your logic or your argument from incredulity. Neither prove your position.
They predict the "most likely" token given the context. That's a huge caveat. Just putting "this is excellent code" in the context makes a vanilla LLM do better. Doesn't that make you pause for a moment before asserting hard limits on what they're capable of?
You might argue they're still capped at the "best" quality seen in the input. Not so. Take typos. Human text has a certain base rate of typographical errors. LLM output contains almost none. Why? Because there are many more ways to be wrong than right. LLMs are not just averaging machines, they also denoise. That should also give you pause.
I do find it rather curious that on a site where people value discussion, instead of answering my genuine question, people just downvoted the fact that it was asked in the first place.
I'm sceptical of the idea that the majority of programmers are already having LLMs write the code. It reminds me of the general idea some years back among the programmer chattering classes that everyone is surely doing some level of unit-testing, whereas in the real world there were tons and tons of teams that did zero unit-testing ever.
This analogy has layers that OP probably doesn't recognize.
The film industry loves cgi because none of the digital vfx houses are unionized and they can treat the artists like crap. It severely devalued a ton of skilled labor around miniature and set design.
Now, after 20 years of hard swing into cgi, people are starting to recognize just how much better movies from the practical era looked, and there is a push back towards it. Project Hail Mary was predominantly practical effects, for example. Stop motion animation is coming back, and theres a push back into hand cell animation.
While many of the things tou say are true, movies like PHM and other "predominantly practical" movies have so many effects that they put Marvel to shame.
> Project Hail Mary was predominantly practical effects
Don't drink the Kool Aid. The studios love to make this sort of claim — recent examples include F1: The Movie, Top Gun: Maverick, and Mission: Impossible – The Final Reckoning, and you'll see interviews where the main actors say it was all real — but it's just marketing.
Project Hail Mary leans heavily on CG. For example, while they did hire a puppeteer (he ended up voicing the alien!) to control a neat physical puppet on set, almost all of it was replaced with CG in post production, and only used for reference. Corridor Crew has a great breakdown [1]. They frequently provide a good counterpoint against fraudulent "no CG" claims.
You can have the most everyday-setting movie or TV show imaginable and still have it VFX'd to hell and back compared to something shot on film 30 years ago. Not even just like Ted Lasso faking the stadiums/fields they were on, but just retouching every single little thing.
Basically anything you see out of a window, anything in the street more than a few meters away from a camera, almost any overhead shot, any wide shot, any panorama or landscape, blood, liquids, glass, any semblance of stunt work, most signs, boats, any action on water, flight... is vfx
> 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.
The trap here is that LLMs love to YOLO out reinvented wheels and that leads to a lot of verbosity and untested complexity. Levenshtein distance is one thing, but I've seen an LLM try to hand roll an ORM which obviously will lead to buggier code and a context window bloated with irrelevant noise. Better, as always, to let the ORM maintainer leverage LLMs for the more local issue.
There have been a few movies that each revolutionised CGI in their own way. The Last Starfighter, flight of the navigator, tron, jurassic park, toy story, Terminator 2
Both were pretty influential. Roughly speaking I think a lot of people saw T2 and thought "wow, that looks really cool in a high-tech way" and a lot of people saw Jurassic Park and thought "wow, that looks really realistic". The silvery liquid terminator morphing into stuff was cool, but the natural-looking dinosaurs were cool in a complementary way.
So much of the Terminator stuff was live action and not CGI though, that I don't think that Terminator is the thing to look at for CGI. The floating head was CGI, but all those squibs were not.
> 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.
The default behavior is not necessarily good. You end up with tests that match the code, but you don’t necessarily end up with tests that test the behavior you care about. And then, if the LLM tries to decide whether the code is correct, it can conclude “it matches the test so it must be right” regardless of whether it’s actually right.
Designing good tests requires the most intelligence. Sometimes even more than writing the code itself. You have to fully understand the code, its uses, and its various edge cases.
As much as I would like to “evolve”, I don’t want to buy an RTX5090, I don’t want to run a model trained on stolen IP, and I don’t want to pay a monthly subscription to a tech bro. I suspect that I’ll never work in this industry ever again!
I don't get the part about having the AI write commit messages. Is it that hard writing them by hand? Plus saves potential embarrassment if the AI says something stupid.
The article conflates general use of LLMs with LLMs for programming and is a worse article for this reason.
As an example, I already heavily leverage LLMs to ask questions about unknown codebases and concepts, and even some debugging, for which it is immensely useful. However, given the AI messianism inherent in some companies, I fear that management’s impression is that millions of LOCs will get written in days, and I’m not ready just yet to abdicate my personal responsibilities in meeting business and performance requirements.
The argument that those who refuse to use an LLM will fall behind because they “won’t be able to produce as much” hinges on more LoC being an objective good and typing speed being a bottleneck, which always struck me as a suspicious line of reasoning. In a well-thought-through architecture, you don’t need to type that much; add to that the observation that more LoC usually means more opportunity for error and the net effect suddenly becomes less obviously positive (and this ignoring other negative effects LLM-driven development might have on OSS ecosystem, such as GPL-washing).
Furthermore, when it does come to typing speed, good old non-LLM-powered autocomplete does still exist, and offers less opportunity for subtle errors within otherwise plausibly looking blocks of code.
124 comments
[ 0.24 ms ] story [ 39.0 ms ] thread> 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.
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.
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.
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.
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.
That's not what suitable data structures/algorithms mean. What you stated are mere helpers and still pertains to the realms of coding, not design.
Coding isn't and never was the issue. It is a tool and not the intent. Think about what would stand universally true whether you use Go, C, JavaScript, Assembly,... The organization of data (information), and the process of transforming it (computation).
Those do not depends on code. We already have basic ones like the list, the map, the stack, the queue, the binary tree, the graphs,... But for any business domain, you can create more specific ones. And like the basic one, they do not depends on code. The code depends on them.
So writing code faster does not make the design better.
If you have a bad design that's had contact with reality for a while, it's much easier to make it actually good, rather than figure stuff out up front (I've rarely made this work, even though I'd love to).
The mistake here is trying to come up with the most elegant design. You solve for what’s needed with the knowledge that you’ve most likely not captured the full situation, and make allowance for future changes.
I don’t want faster code. What I want is flexibility in evolving my design and there’s plenty of good tools and practices for that. From ensuring your code is testable to ensuring there are easy ways to experiment with parts of it.
I’ve never been in a situation that says “We’ve not think of that, we need to get back to the drawing board”, It’s been mostly “We need a new version of this module to support this feature”
And you're somehow able to post on HN from within the time crystal?
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.
Unless you encounter circumstances where it's death by committee (or something similarly bad), but overall I agree! It's just that you don't have the bad environment risk/problem when it's just you.
One can, obviously, romanticize the times of cave live, that's fine with me, but I doubt that would be a common choice.
My intuition has always been that these things don't have to go together, but it's often sounded like a number of people who've thought about it a lot expect that they do! Can anyone reassure me about this? Is there a future in which people have greater capability, and there are also fewer institutions or mechanisms proactively monitoring us?
I'm aware of portions of the history of that conversation but would love to hear your take or the take of other HN members.
People on HN will drop what they think is their trump card. Ie The computer spitting out incorrect info. However, I've worked in banking finance where data was wrong and people in charge just shrugged when I showed them and said something like, accounting will catch it. And here's the worst thing. They were right.
They will just generate code that passes the tests also written by the AI, ask the AI to find any bugs, and so long as the code runs without obvious issues, that will get released.
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 wide availability of open source, 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/
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.
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.
Another thing that LLMs are particularly good at is instilling their users with a false sense of confidence.
llm's cant solve your organization issues...
Before subscription services, you needed to add features because you had to justify to people why they should buy an upgrade. So yeah, it made sense to make as many features as possible to try to cast a wide net.
I think with software as a service, making features is not really the most important thing. Realistically, people buy software for what it does right now, not its future potential. Further, changing things out from underneath users tends to annoy them (pretty much EVERY time a service introduces a redesign, even if it's a good one, people initially hate it -- you're asking them to relearn a thing that was working perfectly fine).
Anyway, I think new software is going to win the same way it's always won, based on its utility, not based on shipping features at some sort of frantic rate.
And those issues often appears because no one had the "time" to properly design a solution before rushing to code. Saving one hour of planning by spending weeks on debugging.
I've noticed that too. And I think it's no surprise we see lots of "728 security exploits found by LLMs in project X" posts.
They excel at what you mention.
I also think that, as of 2026, they suck fat balls at writing code.
This is the future. Adapt or die.
This is the future. Adapt or die.
The "or die" part betrays insecurity and weakness. You need to scare prople into using it rihht now, because of some perceived threat.
I'm curious about what adaptation you have in mind.
You use LLMs to write specific functions? The person who uses it in an agent loop will leave you behind to die.
You use LLMs in an agent loop? The person who uses LLMs to supervise loops will leave you behind to die.
You use LLMS to supervise agent loops? The person who uses LLMs to determine product offering and automatically start supervision on producing the product will leave you behind to die.
You use LLMs to determine product offering and kick off the supervision? The person who uses LLMs to clone your product without the initial product research will leave you behind to die.
You use LLMs to clone products gaining traction? The person who runs a cluster 100x the size of yours will leave you behind to die.
I am trying to understand where you think you fit in, in this Brave New World.
You obviously think that you're adapting, but if you're correct, anything you do now can be replaced by an LLM in the near future.
Just where were you going with "Adapt or die".
* "LLMs suck, are stupid, I hate them, and I'm not using them"
or
* "LLMs are the future and if you don't adapt you'll left behind"
I'm confident it's this 2nd option. Care to wager?
People might be using hyperbole: "You'll be left behind" = "you'll be out of a job" or "you'll be unemployable" or "You'll die" but they all mean the same thing.
Most of the "cutting edge" stuff I've seen is basically trying to scale the amount of parallel work that can be done, without any consideration to how much that costs, how much waste is generated, or if the output is even useful. Most of my coding time is spent thinking through problems. Which is exactly how I spent my time prior to LLMs.
False. There was a person in this thread complaining about how the LLM forgot to run the build script it itself wrote. Yet people are effectively using LLMs to tackle highly complex, unusual work.
The existence of skill issues implies that skill is needed. This is THE skill that will separate the wheat from the chaff in a software engineering context. There's a reason why Steve Yegge said you're a bad engineer if you're writing code in an editor. It's because you've punted on developing the skillset that will make you vastly more effective.
The Luddites were a small group; AI has the chance to turn a majority of society into loom-smashers, which will be very fun to watch.
It can be pretty depressing, until you learn how to game the system - create tickets for yourself that are tiny amounts of work. I hear that it's getting harder to do that, because management is looking more carefully at tickets generated and it looks like they'll start having developers assign points to their tickets before the tickets are added to the sprint
* Those who refuse to use a spreadsheet over calculator and paper will fall behind because they won't be able to produce as much
* Those who refuse to use a truck over horse drawn wagon will fall behind because they won't be able to carry as much
Seems pretty common sense to me, rathern than aggressive.
I've tried a couple of times to use Claude to help write stuff, and it sits there for a couple of minutes "thinking" before returning some grossly incorrect code.
What's the bit that's supposed to be faster?
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 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 only snark at those who try to mislabel that thing as something useful. Which it is not.
That's why they call us "hackers," and they call you something else.
Find curious uses for, exploit in inventive ways, reimplement even -- yes. Fighting -- get off our lawn.
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..
How can you go the opposite direction? Instead of using LLMs to produce more code, can you produce less, maybe higher abstraction code?
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.
Which you likely failed to review thoroughly, so may be subtly wrong.
But on the positive side, no dependencies.
I do one better: I pull from a trusted creator or I review things like GitHub issues to ensure better people than me have reviewed it.
> 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.
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.
Yes it might have made me a bit faster at some things I do for work. But it seems to me that we face so many challenges as a civilization, and AI doesn’t actively help with any of them? Unless you buy into the narrative that it will somehow usher in a golden age of abundance where everyone is taken care of and nobody needs to work anymore (utter BS in my opinion). The amount of capital flowing into it, that is then not available for other causes, is completely mind-boggling to me.
I wish I could upvote this a thousand times, because this is exactly my experience as well. It's made a few things slightly more convenient, but convenience is not exactly a problem in my life! And yet, it's actively damaging a lot of things I care about in a way that I think is going to be extremely bad for society.
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.
You just won't be able to get a job doing it. It will be a hobby, not a way to make a living.
Fabien, care to share your whole file? I'll plug it into my NixOS machine.
- Avoid using magic numbers and strings. There should be consts or even better enums.
- When working on a patch, you should other the test first. Watch the test fail. Then include the new code. And watch the test pass.
- Leverage early return and continue as much as possible to reduce code indentation.
- Only delete comments if they are obsolete. If you change code, make sure the comment above is still correct.
- Use enums instead of boolean for function parameters.
- Talk to me like an engineer. Don't be excessively verbose. Be down to the point.
- Don't use superlative. Stop praising me, give me the cold hard truth.
- Let the reader of the code breath. Add empty lines between logic block of code. Add a small to the point comment to explain what the block does.
- When you write unit tests, add a short comment at the beginning of the function and class to explain what they test and how they test it.
- Check commit message, if you proof read or write one, 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.
You know that metaphor is about death and replacement, rather than upgraded individuals, right?
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.
A genuine question : If an AI can reliably write code better than most coders, do it quicker, and produce code that runs efficiently which has less, or at least no more, bugs than human written code, why on earth would a company not use an AI to write all their code for most purposes?
And if they did, why is it important for that code to be 'elegant' or even human readable if the bug checking is also done by AI? (as seems to be the direction we are moving in)
If the code isn't readable to humans, there's no particular reason to think it's going to be magically readable by LLMs either.
The view that they are only statistical prediction machines is becoming increasingly disconnected from their current abilities.
I probably should have put the word 'easily' before readable. After all, if it is valid code, it can be read.
The problem was unsolved, it solved it when it was not possible for it to be trained on the solution, therefore your other claim that "they're always going to produce the most "average" code" does not hold up, they can come up with better code than they were trained on precisely because they can apply known techniques to write better code than existed in their training data. The book you have is out of date and does not apply to recent improvements in the field.
The unit distance problem had no known answer and no roadmap. The model identified the problem, chose its own approach, and produced the proof.
I am not convinced by either your logic or your argument from incredulity. Neither prove your position.
You might argue they're still capped at the "best" quality seen in the input. Not so. Take typos. Human text has a certain base rate of typographical errors. LLM output contains almost none. Why? Because there are many more ways to be wrong than right. LLMs are not just averaging machines, they also denoise. That should also give you pause.
The film industry loves cgi because none of the digital vfx houses are unionized and they can treat the artists like crap. It severely devalued a ton of skilled labor around miniature and set design.
Now, after 20 years of hard swing into cgi, people are starting to recognize just how much better movies from the practical era looked, and there is a push back towards it. Project Hail Mary was predominantly practical effects, for example. Stop motion animation is coming back, and theres a push back into hand cell animation.
I highly recommend the 4-part essay series "'No CGI' is just invisible CGI" https://youtube.com/playlist?list=PLgdTaHO8FLEve_XFiRBEcOSkR...
Don't drink the Kool Aid. The studios love to make this sort of claim — recent examples include F1: The Movie, Top Gun: Maverick, and Mission: Impossible – The Final Reckoning, and you'll see interviews where the main actors say it was all real — but it's just marketing.
Project Hail Mary leans heavily on CG. For example, while they did hire a puppeteer (he ended up voicing the alien!) to control a neat physical puppet on set, almost all of it was replaced with CG in post production, and only used for reference. Corridor Crew has a great breakdown [1]. They frequently provide a good counterpoint against fraudulent "no CG" claims.
[1] https://youtu.be/l9zqIo8KtjI?is=e7-3Wz_mnMdl2Yp8
They recreated one and had one of the stop motion guys from Jurassic park and another animator come visit and test it.
Their conclusion was that animating in blender with your mouse is still better, even though it was enjoyable to use the animatronic controller.
Their concept for the video was “look at this better way to animate that time forgot” and ended up concluding that “actually it isn’t better”
The trap here is that LLMs love to YOLO out reinvented wheels and that leads to a lot of verbosity and untested complexity. Levenshtein distance is one thing, but I've seen an LLM try to hand roll an ORM which obviously will lead to buggier code and a context window bloated with irrelevant noise. Better, as always, to let the ORM maintainer leverage LLMs for the more local issue.
I thought Terminator 2 did this. At least around where I lived everyone talked about T2 and questioned how they did this or that. JP? Not really.
The default behavior is not necessarily good. You end up with tests that match the code, but you don’t necessarily end up with tests that test the behavior you care about. And then, if the LLM tries to decide whether the code is correct, it can conclude “it matches the test so it must be right” regardless of whether it’s actually right.
TDD can help but is not a panacea.
Automating this away feels like massive folly.
Use AI to brainstorm, implement features, learn new things, improve your writing, or speed up repetitive work.
Just make sure you keep thinking while doing so!
As an example, I already heavily leverage LLMs to ask questions about unknown codebases and concepts, and even some debugging, for which it is immensely useful. However, given the AI messianism inherent in some companies, I fear that management’s impression is that millions of LOCs will get written in days, and I’m not ready just yet to abdicate my personal responsibilities in meeting business and performance requirements.
Furthermore, when it does come to typing speed, good old non-LLM-powered autocomplete does still exist, and offers less opportunity for subtle errors within otherwise plausibly looking blocks of code.