> 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.

Working with AI development really shows you how important it is to explicitly specify which direction you're aiming for.

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.)