[YuechenLi]

The industry will realize that while getting LLMs to write code is easy, getting LLMs to write good, production ready code is a skill all on its own, which simply must be done by a human and is not automatable to an LLM in any sense effectively. That will be the differentiating factor software engineering in the future, I think.

If I'm being blunt, if you are in the game industry, you probably have nothing to worry about in terms of LLM coding replacing you, because the tooling used in the gaming industry is as unfriendly to LLM coding as it gets: Heavily visual scripting based, extremely reflection heavy, and the code, Unreal C++ and Unity C#, looks like regular C++/C#, but doesn't behave like normal C++/C#. LLMs simply cannot reason about hidden implicit states effectively, so if the code looks right but doesn't act right, LLMs will simply get confused and start hallucinating.

[unknownfuture]

> The industry will realize that while getting LLMs to write code is easy, getting LLMs to write good, production ready code is a skill all on its own, which simply must be done by a human and is not automatable to an LLM in any sense effectively.

I don't agree.

Here's the thing about poorly written code: it can work for a surprisingly long time.

And by the time it stops working, the people who built it or the leaders who drove it or the execs who insisted on it have probably moved on.

So no. I would in fact argue that, by and large, as long as the software appears to work, most business don't care about code quality, and slinging high quality, AI written code slower than another guy who spitting out garbage will lose in this new normal.

[h4kunamata]

>The industry will realize that while getting LLMs to write code is easy, getting LLMs to write good, production ready code is a skill all on its own, which simply must be done by a human and is not automatable to an LLM in any sense effectively. That will be the differentiating factor software engineering in the future, I think.

Not many people understand that, including some reply to your comment.

AI loves to do enshitification, it adds code that is not required at all, broken logic, sure it might work but it might not be best practice.

People forget that AI as it exists atm isn't Artifical Inteligence but machine learning, it is as good as the model it was trained on. If the model is good, that agentic will be good, if the model is bad, the agentic will be so so.

Companies are making that same mistake.

I wrote a skill for Claude to talk with a MCP server using API, it uses far less token, ~700 instead of ~2k tokens to perform the same task so cheaper and a lot faster too, seconds instead of minutes.

Which again, goes back to what I said, an agentic AI is only as good as the model it was trained on, vibe coding without adding vulnerabilities is a whole another level.

[yallpendantools]

I've spoken about my troubles getting as much mileage out of LLMs as before while being vague about my industry and, well, this hits the nail in the head.

> because the tooling used in the gaming industry is as unfriendly to LLM coding as it gets: Heavily visual scripting based

At the start of the LLM craze, we (as a team) put ChatGPT to test with Godot. It wasn't very successful in that, IIRC, GDScript 2 was just released and ChatGPT's training corpus was so obviously based on GDScript 1.

We could make ChatGPT outline steps of how to accomplish things in Godot, sort of like getting a customized tutorial. When code isn't involved, ChatGPT was okay and Gemini seemed to fare better. Based on vibes, I think Gemini had a marginally better handle on GDScript 2 for some reason.

I've been trying it lately with Claude still with mixed results. I had to install a few skills/extensions for it (can't tell you which as I basically just blindly followed what our AI advocate recommended). Sometimes it works but when it doesn't it's harder to put a finger on why. Overall I prefer the DX of generating customized tutorials with ChatGPT.

> extremely reflection heavy

Big time. And IME we don't even have to deal with textbook reflection here. Game entities are so convoluted (remember the Fallout 3 Train NPC, the stories of how Skyrim works, etc.) that it is really pushing inheritance and OO to contortions it shouldn't be doing.

Dirty confession: in our game we have this GIANT switch-statement dealing with game objects. It happens in a handful of places, for different game object types. LLMs (Copilot and Codex) could generate the monkey code of adding a switch case and even writing the body but sooner than later, when the new objects have to interact with others, LLMs just can't reason around it. Not to mention the hundred edge cases you have to consider!

And before some smart-ass comments: in my almost-decade of dealing with this code base there have been a handful of attempts to "refactor" these switch-statements, always a newcomer's enthusiastic effort. I'm proud to say, I've managed to slay one of the giants, the only successful effort to my knowledge, and this only happened last year. But I did so by basically delegating to another of the giants; they turned out to be twins and we could do without one. The dirty way is the clean way because the alternative contains Lovecraftian geometries.

Claude has been great for finding edge-case bugs but that's only once the code has been written properly. Generally if QA reports a bug on a pre-release feature, it's at most 50/50 if Claude can debug it. But if it's a player report/live incident, I'd say Claude's chances goes up to around 80%.

All that said,

> if you are in the game industry, you probably have nothing to worry about in terms of LLM coding replacing you

Hah-hah. Look, I agree with you but please get in touch with upper management. As an engineer I'm confident on the value I bring to the table but I'm not sure management "gets" that. Like, no matter how I tell them what features I shipped, what infra I built, etc., it doesn't come across to them that LLMs would not have been able to automate that output!