Here's a guy who does more than make simple, bloated end-user apps. He tries to dig into the code and make novel performance optimizations etc. He sees that AI can't code everything.
I liked the two original experiments in the article, which in a microcosm gels with my 1+ year of deep agentic development. But I would like a whole article about his experience, and with which model (Opus? Fable? erg, Sonnet?) and effort he used.
I've progressed in using latest Claude-kins and the GPTs as usually competent teammate/buddies, and generally know to sort out the fluff confidence with the realz (shoot, that was how I was when I was but a wee little coder lad: overconfident because of an error-free compile and one non-segfault run.)
You have to put in the time, the skill creation, the system prompt/personalization, the (sometimes adversarial) automation, the testing, verification, kicking down the loop castles (as usually caused by being cheeky with highest effort levels.)
The author is a real C++ programmer. Not like the PyTorch guys who use std::shrared_ptr for cyclical graphs and then go on to overpromise on threaded Python only to find out that the slowdown is much larger and everything is brittle as expected years ago.
The times that Meta people can browbeat honest engineers are over.
If the author can’t put in the effort to think of something original to say that hasn’t been said 1000x, why should I put the effort into rebutting cliches that were last relevant in 2024?
> Hallucinations are an inherent property of how LLMs work.
While technically true the hallucination rates on modern models is low and other checks can ensure that by the time a human sees it it is most likely solid.
For research there is more danger as there is less feedback loop other than other LLM scrutinising the first. For research I get it to come to a conclusion but provide me with links so I can judge. More like advanced search.
Hence the advice to read the tests? Interesting how people make the argument that AI code is garbage and can't be trusted (it's inelegant and poorly structured, sure, but that's a different matter), and how the only option isn't to just spot check the work, but to laboriously write it by hand.
I'm not disappointed in the article, there are many of them out there. I'm disappointed that this is near the top of HN. I lazily outsource my information hunter and gathering to HN.
It'd be nice if blog authors categorized their posts into "old man shaking fist at clouds" vs "something I searched for on the internet, legitimately never found it, and decided to write it myself"
At the risk of sharing an unpopular take, this reads a lot like someone who decided how they feel about LLM-driven engineering ~5 months ago and doesn’t seem to reflect the current reality.
(Or they’re working in an organization with lower budgets and not cranking the frontier models of today)
I fully agree about the cost/sustainability parts, but to suggest you can’t build a high quality coding/verifying/iterating loop for _most_ problems is disingenuous.
> this reads a lot like someone who decided how they feel about LLM-driven engineering ~5 months ago and doesn’t seem to reflect the current reality.
I've been reading this for 2 years straight. "oh you have a criticism of AI? Well they fixed that in Aeternos v Y-point-Z, which after doing all of my work also gave my wife an orgasm for the first time this year, obviously OP is using the old model".
His experience is completely plausible. He’s in a niche that requires highly performant code and most complex, highly performant games do nit have source available for models to train on. It’s a very common observation that the farther you stray from mainstream, the less effective the LLM models become.
5 months ago people said the exact same things, you know. That this stuff was how it was 5 months before that, and doesn't reflect the current reality.
> I do admit that this approach immediately triggered my contrarian side and made me very defiant of any AI tool.
Makes sense.
> While this could be partially remedied by always asking for a primary source or citation, I dislike the idea that one has to add magical incantations to their queries to get the right results. It’s a good laugh to make fun of “make no mistake” memes, until you start having to consider similar things seriously.
Man I am genuinely stumped at the obvious lack of desire to use something in a way it's supposed to be used. LLMs are tools and like with any tool it's on us to use it properly, not hitting a screw with a hammer and saying that hammers are a very stupid tool.
It just seems silly to need to beg in English for things like that. What's the entire space of things you need to think about? Can you be sure the specific way you asked would be correct, or do you also have to add "don't lie about following this instruction:"? Why not have an interface `ai --make-no-mistakes --dont-make-things-up`? I don't want to have to talk to the computer like it's people.
But English is literally the interface. It's the *same* as `--make-no-mistakes`, it's just your preference compared to directly telling it to the AI which is ok. That doesn't change the fact the using the tool correctly != using the tool.
> You shouldn't be required to tell an information retrieval tool to actually retrieve information rather than making it up!
And therein lies the problem: perception. LLMs are treated like information retrieval tools but in reality are probability machines that return plausible/mostly accurate information.
They're not searching, they're inferring and then guessing. That the guesses are often quite good means that we can easily fool ourselves with whatever it spits out. We call it hallucination but it's a feature, not a bug.
We're not talking about "the public". The person writing the article is a very experienced software engineer. There shouldn't be a gap in understanding.
To be fair, hammers are bad screwdrivers. They are faster at driving screws and require less finesse to do so, but are really bad at taking them out, often break the screw, and often result in a fastening that superficially looks correct but fails to perform well under stress.
Two new types of screw, the ring-shank nonhelical fastener and the rivet, however, are changing everything. Soon, using screwdrivers will be rare except in special circumstances.
I don't really see your point. You're still using the screwdriver and it's up to you to use it when it makes sense, see if it's doing it's job properly, fix issues it creates etc... If it's not doing a good job for your particular screw don't use it. But don't say it's a horrible tool since you choose to not use it properly.
There is a middle ground between CEOisms "LLMs are literally Jesus" and people similar to this blog's author "LLMs are mostly trash."
Part of the entire premise of the article is that many people aren’t being given a choice, so this is a really weird deflection. I disagree about the author not recognizing a middle ground.
Not providing a source is how Llms get caught in sycophancy and hallucinations. The “tool” needs improvement, especially one that claims it’s intelligence. How would you react if you found out after schooling everything you learned has half-hallucinated because your teacher made it up and there is no text book or historical log of facts? You had assumed this whole time you were learning facts…now what?
I read through a bit of it, and it seems like the author assumes training was done only on open source data, but I doubt that's actually the case. There are plenty of paid, proprietary source codes being sold out there, hacked code, that is.
Aside from that, I don't agree with the author's view on agentic workflows. Modern AI native development runs like a massive state machine, starting from MCP, local file systems, and what's usually called a harness.
I also noticed what might be a mistake in the author's domain, games. Putting aside the fact that inheritance based OOP is an outdated pattern, the suggestion to remove update() and put it into a manager class's List, then iterate with a for loop, is meant to eliminate overhead like P/Invoke costs in C#. But if Foo is still a class, a reference type, then List<Foo> is just an array of pointers scattered across heap memory. Pointer chasing can still happen. So I think that's actually bad advice.(Of course, the same issue exists in Mr. Claude's code as well.)
If the author truly wanted Data Oriented Programming(or DOD), they would have specified struct arrays or NativeArray.
This is a tricky area. The author's goal was likely to remove the per MonoBehaviour Update call cost in Unity, which is why they suggested using List<Foo>. But the instruction seems ambiguous, and I think that's part of the difficulty with AI development.
The objective function is the same, but the implementation varies and subtly differs from what I actually want.
From a design perspective, for team maintenance, the GameUpdateable abstraction might actually be better. But it's difficult. In terms of extensibility, an update manager that handles registration and expansion of multiple update targets might be over abstracting.
Writing this down makes me realize how many things I actually consider when putting code into a program. Sometimes I model how my next teammate might read it, and sometimes my words might be interpreted differently. It's really difficult.
Here's a guy who does more than make simple, bloated end-user apps. He tries to dig into the code and make novel performance optimizations etc. He sees that AI can't code everything.
It reads like something written by a time traveler from the past.
We are all time travelers from the past.
I liked the two original experiments in the article, which in a microcosm gels with my 1+ year of deep agentic development. But I would like a whole article about his experience, and with which model (Opus? Fable? erg, Sonnet?) and effort he used.
I've progressed in using latest Claude-kins and the GPTs as usually competent teammate/buddies, and generally know to sort out the fluff confidence with the realz (shoot, that was how I was when I was but a wee little coder lad: overconfident because of an error-free compile and one non-segfault run.)
You have to put in the time, the skill creation, the system prompt/personalization, the (sometimes adversarial) automation, the testing, verification, kicking down the loop castles (as usually caused by being cheeky with highest effort levels.)
> “Agentic workflow” (or whatever they’re calling it at the time you’re reading this article)
> Unlike the silver bullets of the past (like microservices or NoSQL)
> Hallucinations are an inherent property of how LLMs work.
> It’s all marketing and buzzwords
Not a serious article or thinker. I can get this stuff on Reddit if I want to read thrice-regurgitated cliches about AI.
The author is a real C++ programmer. Not like the PyTorch guys who use std::shrared_ptr for cyclical graphs and then go on to overpromise on threaded Python only to find out that the slowdown is much larger and everything is brittle as expected years ago.
The times that Meta people can browbeat honest engineers are over.
Nice corporate take.
I'd like to hear actual rebuttals to those quotes.
If the author can’t put in the effort to think of something original to say that hasn’t been said 1000x, why should I put the effort into rebutting cliches that were last relevant in 2024?
So you basically agree but complain there are no new arguments against AI programming in the article?
No, I’m not sure where you are getting the idea that I agree with what I am referring to as cliches last relevant in 2024.
> Hallucinations are an inherent property of how LLMs work.
While technically true the hallucination rates on modern models is low and other checks can ensure that by the time a human sees it it is most likely solid.
For research there is more danger as there is less feedback loop other than other LLM scrutinising the first. For research I get it to come to a conclusion but provide me with links so I can judge. More like advanced search.
> it it is most likely solid.
Most likely? That’s not reassuring at all. So you’re saying the other checks can result in hallucinations?
If you're using an LLM and not an agentic workflow then you're doing things wrong in 2026.
My agents have to pass tests meaning that if their LLM hallucinates, the agent tools capture it and not me.
Some people have the agent hallucinating its own meaningless tests
Hence the advice to read the tests? Interesting how people make the argument that AI code is garbage and can't be trusted (it's inelegant and poorly structured, sure, but that's a different matter), and how the only option isn't to just spot check the work, but to laboriously write it by hand.
3,300 words but nothing new to say.
Dislikes AI so much and ironically wrote a whole article without doing any of their own thinking.
I'm not disappointed in the article, there are many of them out there. I'm disappointed that this is near the top of HN. I lazily outsource my information hunter and gathering to HN.
Maybe you guys just shouldn't read blogs.
It'd be nice if blog authors categorized their posts into "old man shaking fist at clouds" vs "something I searched for on the internet, legitimately never found it, and decided to write it myself"
At the risk of sharing an unpopular take, this reads a lot like someone who decided how they feel about LLM-driven engineering ~5 months ago and doesn’t seem to reflect the current reality.
(Or they’re working in an organization with lower budgets and not cranking the frontier models of today)
I fully agree about the cost/sustainability parts, but to suggest you can’t build a high quality coding/verifying/iterating loop for _most_ problems is disingenuous.
> this reads a lot like someone who decided how they feel about LLM-driven engineering ~5 months ago and doesn’t seem to reflect the current reality.
I've been reading this for 2 years straight. "oh you have a criticism of AI? Well they fixed that in Aeternos v Y-point-Z, which after doing all of my work also gave my wife an orgasm for the first time this year, obviously OP is using the old model".
His experience is completely plausible. He’s in a niche that requires highly performant code and most complex, highly performant games do nit have source available for models to train on. It’s a very common observation that the farther you stray from mainstream, the less effective the LLM models become.
5 months ago people said the exact same things, you know. That this stuff was how it was 5 months before that, and doesn't reflect the current reality.
> An Honest Review
> I do admit that this approach immediately triggered my contrarian side and made me very defiant of any AI tool.
Makes sense.
> While this could be partially remedied by always asking for a primary source or citation, I dislike the idea that one has to add magical incantations to their queries to get the right results. It’s a good laugh to make fun of “make no mistake” memes, until you start having to consider similar things seriously.
Man I am genuinely stumped at the obvious lack of desire to use something in a way it's supposed to be used. LLMs are tools and like with any tool it's on us to use it properly, not hitting a screw with a hammer and saying that hammers are a very stupid tool.
How are they supposed to be used? The providers promised us we could just say what we wanted and get it.
It just seems silly to need to beg in English for things like that. What's the entire space of things you need to think about? Can you be sure the specific way you asked would be correct, or do you also have to add "don't lie about following this instruction:"? Why not have an interface `ai --make-no-mistakes --dont-make-things-up`? I don't want to have to talk to the computer like it's people.
But English is literally the interface. It's the *same* as `--make-no-mistakes`, it's just your preference compared to directly telling it to the AI which is ok. That doesn't change the fact the using the tool correctly != using the tool.
It's more like a hammer that never drives nails straight unless you hold it in a specific uncomfortable manner.
You shouldn't be required to tell an information retrieval tool to actually retrieve information rather than making it up!
> You shouldn't be required to tell an information retrieval tool to actually retrieve information rather than making it up!
And therein lies the problem: perception. LLMs are treated like information retrieval tools but in reality are probability machines that return plausible/mostly accurate information.
They're not searching, they're inferring and then guessing. That the guesses are often quite good means that we can easily fool ourselves with whatever it spits out. We call it hallucination but it's a feature, not a bug.
> It's more like a hammer that never drives nails straight unless you hold it in a specific uncomfortable manner.
I mean sure, pick any analogy, still doesn't change the fact that there are right uses and wrong uses; right ways to use it and wrong ways to use it.
> information retrieval tool
How is an LLM this? It's a non-deterministic word generator.
An LLM is not what the public was “sold”, they were “sold” a personified agent. That is the gap.
We're not talking about "the public". The person writing the article is a very experienced software engineer. There shouldn't be a gap in understanding.
To be fair, hammers are bad screwdrivers. They are faster at driving screws and require less finesse to do so, but are really bad at taking them out, often break the screw, and often result in a fastening that superficially looks correct but fails to perform well under stress.
Two new types of screw, the ring-shank nonhelical fastener and the rivet, however, are changing everything. Soon, using screwdrivers will be rare except in special circumstances.
I don't really see your point. You're still using the screwdriver and it's up to you to use it when it makes sense, see if it's doing it's job properly, fix issues it creates etc... If it's not doing a good job for your particular screw don't use it. But don't say it's a horrible tool since you choose to not use it properly.
There is a middle ground between CEOisms "LLMs are literally Jesus" and people similar to this blog's author "LLMs are mostly trash."
Part of the entire premise of the article is that many people aren’t being given a choice, so this is a really weird deflection. I disagree about the author not recognizing a middle ground.
> Part of the entire premise of the article is that many people aren’t being given a choice
Yeah, "part", but that's not the part I wrote about?
Not providing a source is how Llms get caught in sycophancy and hallucinations. The “tool” needs improvement, especially one that claims it’s intelligence. How would you react if you found out after schooling everything you learned has half-hallucinated because your teacher made it up and there is no text book or historical log of facts? You had assumed this whole time you were learning facts…now what?
I read through a bit of it, and it seems like the author assumes training was done only on open source data, but I doubt that's actually the case. There are plenty of paid, proprietary source codes being sold out there, hacked code, that is.
Aside from that, I don't agree with the author's view on agentic workflows. Modern AI native development runs like a massive state machine, starting from MCP, local file systems, and what's usually called a harness.
I also noticed what might be a mistake in the author's domain, games. Putting aside the fact that inheritance based OOP is an outdated pattern, the suggestion to remove update() and put it into a manager class's List, then iterate with a for loop, is meant to eliminate overhead like P/Invoke costs in C#. But if Foo is still a class, a reference type, then List<Foo> is just an array of pointers scattered across heap memory. Pointer chasing can still happen. So I think that's actually bad advice.(Of course, the same issue exists in Mr. Claude's code as well.)
If the author truly wanted Data Oriented Programming(or DOD), they would have specified struct arrays or NativeArray.
This is a tricky area. The author's goal was likely to remove the per MonoBehaviour Update call cost in Unity, which is why they suggested using List<Foo>. But the instruction seems ambiguous, and I think that's part of the difficulty with AI development.
The objective function is the same, but the implementation varies and subtly differs from what I actually want.
From a design perspective, for team maintenance, the GameUpdateable abstraction might actually be better. But it's difficult. In terms of extensibility, an update manager that handles registration and expansion of multiple update targets might be over abstracting.
Writing this down makes me realize how many things I actually consider when putting code into a program. Sometimes I model how my next teammate might read it, and sometimes my words might be interpreted differently. It's really difficult.