> 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.
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.
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.)
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.
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.
The case study of the LLM getting the basic Mono framework usage wrong seems outdated.
They're pretty flawless at any framework now, React, SwiftUI, Unity - literal skill issue if you can't get good code out of an LLM.
If an LLM can write a nuanced paragraph about any topic, it can certainly write a simple [insert popular framework] component which has considerably less potential variation.
Consider that there are 100k+ words in English, 90k+ in Spanish, and 77 in C# (38 in JavaScript!).
The LLM can write code.
Can it make software? No. Because software is a lot more than code.
But the LLM can write code.
Any anti-AI takes moving forward are going to have to acknowledge that I think
> In a past life I had to argue every year to renew a license for a profiling tool that cost about 20 EUR a month. I’ve heard since that everyone at the company is now getting a Claude subscription, even non-programmers.
Underrated quote. I also found this frustrating. At one company I was at (a very old company which was trying to pivot to software engineering), we had hellish bureaucratic fights with the IT department to get access to Pycharm, Obsidian, and even GitHub. But then the AI craze dropped and management just gave us all GitHub Copilot access without us even asking.
Cory Doctorow's book The Reverse Centaur's Guide to Life After AI talks more about this. It's just a modern symptom of an age-old power struggle. The workers want more control over their craft, including quality standards and tools, but their bosses want more control over the workers.
What's happening now is bosses are feeling pressure from investors to show productivity gains from using AI, so bosses panic-push AI within their companies. Which leads to misaligned incentives like tokenmaxxing.
Article was flagged from the front page after criticism of Meta. You know, if free speech isn't allowed maybe we should contact Zuckerberg directly if that is what you want.
> It's interesting how AI is constantly providing false information and incorrect statements about my area of expertise. Fortunately, it's very useful and always right about topics I know very little about.— pikuma.com (@pikuma) June 19, 2026
Also true for TV commentators, bloviating C-suiters, frequent posters on social media, politicians, etc.
> While I have found LLMs useful for researching and planning code changes, my attempts at actually making them write code have been quite lackluster. I found them to be slow and expensive to generate, for a mediocre result.
I think this observation is generally true for the kind of problems the author is working on.
But I would not make the leap to avoid using LLMs for any kind of code writing. LLMs do fantastically well in the 95%+ of the code that engineers spend time on. And for those we should leverage the technology.
It is upto us as engineers to figure out when to stop using LLMs. We are smarter than just dumping logs and half dozen specialized markdown files to a LLM and have it figure out solutions.
This is likely a completely honest and plausible experience of the author, while at the same time still feeling like someone trying to use a pottery wheel and then concluding that pottery wheels are not suitable for producing very good art due to the clay often not centering. It says more about the author than about the topic.
18 comments
[ 0.25 ms ] story [ 35.9 ms ] thread> 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.
> 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.
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.
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.)
(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.
They're pretty flawless at any framework now, React, SwiftUI, Unity - literal skill issue if you can't get good code out of an LLM.
If an LLM can write a nuanced paragraph about any topic, it can certainly write a simple [insert popular framework] component which has considerably less potential variation.
Consider that there are 100k+ words in English, 90k+ in Spanish, and 77 in C# (38 in JavaScript!).
The LLM can write code.
Can it make software? No. Because software is a lot more than code.
But the LLM can write code.
Any anti-AI takes moving forward are going to have to acknowledge that I think
Underrated quote. I also found this frustrating. At one company I was at (a very old company which was trying to pivot to software engineering), we had hellish bureaucratic fights with the IT department to get access to Pycharm, Obsidian, and even GitHub. But then the AI craze dropped and management just gave us all GitHub Copilot access without us even asking.
Cory Doctorow's book The Reverse Centaur's Guide to Life After AI talks more about this. It's just a modern symptom of an age-old power struggle. The workers want more control over their craft, including quality standards and tools, but their bosses want more control over the workers.
What's happening now is bosses are feeling pressure from investors to show productivity gains from using AI, so bosses panic-push AI within their companies. Which leads to misaligned incentives like tokenmaxxing.
Also true for TV commentators, bloviating C-suiters, frequent posters on social media, politicians, etc.
I think this observation is generally true for the kind of problems the author is working on.
But I would not make the leap to avoid using LLMs for any kind of code writing. LLMs do fantastically well in the 95%+ of the code that engineers spend time on. And for those we should leverage the technology.
It is upto us as engineers to figure out when to stop using LLMs. We are smarter than just dumping logs and half dozen specialized markdown files to a LLM and have it figure out solutions.