Game Development

Visual scripting tools like Unity and Unreal Engine were supposed to speed up development and let designers think more about their game and less about blocks of code. Why would we go back to a world where everyone's building their own game engines?

A number of reasons I can think of.
One: debloat and performance. Unreal and Unity are extremely bloated. As much as I enjoy Godot, the bare minimum executable that it produces is over 20MB. Less bloat means less code being shipped which typically translates into better performance.
Two: better control of what's going on. Sure, UE's source is open for you to peek in and see what's going on, but it has literal decades of baggage. Unity has its way of doing things and, other than plugins, you're stuck with it. The point that Dean Hall makes of these engines all working based on scenes^["If you take Unity or Unreal, you have this editor scene and push play, it becomes a game scene and everything in it is relative to 0-0-0 of that scene," said Hall. "That's how you draw things, and it's so ingrained that people have a hard time imagining something that's different." (...) The thinking wasn't "Unity can't do this, I need a tool that can do this." It was "our game needs floating origin to work this way, how do we do it?"] and not every game needing that is spot on.
Three: Visual scripting isn't new and it leaves you stuck with the tool. There are several engines that offer visual scripting, some decades old (Clickteam Fusion, GameMaker, RPG Maker, Construct), being widely used for simpler games, but never for stuff that "thinks outside the box", so to speak.

Hall made a rather bold prediction: frameworks like Brutal, not game engines, will be the future of the game development.

I wouldn't go that far. A lot of big budget games will still use ready-made engines like UE and Unity simply due to cost and time, others will do things on their own "hard" way. CDProjekt ditched their own custom engine that powered Witcher 3 and Cyberpunk 2077 to work with UE going forward.

The only thing the LLM does for Brutal developers is speed up access to information, letting them research without watching a 40 minute YouTube video. (...) You can boil down Hall's theory about what he calls "the death of big engines" to this: if LLMs make language-based coding more accessible, than visual-based scripting loses its edge.

Not going to be the "death" of big engines because he's putting waaaay too much faith in people bothering to even search "how to do X using Y framework".

Hall's vision of the future game industry is almost the polar opposite of the one pitched by UGC platforms and AI boosters. Instead of a world where game development becomes easier through simplified tools, it becomes more accessible through easier understanding of language-based programming through LLMs.

In other words, it's a StackOverflow that won't berate you for "a stupid, repeated question" which should, in theory, help out with new stuff so long as it is properly documented, which seems to be the case with the Vulkan API