Should Bevy editor be an agent native editor?

[lazytiger]

Currently, neither the Unity nor Unreal engines and editors are designed to be agent-native. However, Bevy’s ECS architecture places the engine itself and game logic under the same architectural model, which makes it much easier for Bevy to become agent-native.
The next generation of software should likely be designed around agent-native architectures. The era in which users must memorize large numbers of complex operations is coming to an end. Under this assumption, shouldn’t the Bevy editor avoid inheriting the cumbersome human-oriented UI patterns of traditional editors, and instead move directly toward an agent-native design?

[IceSentry]

https://bevy.org/learn/contribute/policies/ai/

[lazytiger]

This is not about vibe coding. This is an editor design issue.

[KABoissonneault]

There's a lot that can be better for everyone, up to modern tool standards, and be more accessible to non-standard "mouse and keyboard" setups, while also being helpful to agents by accident. The default for classic tools is to hide features exclusively behind a GUI that needs to be navigated through and clicked on by a mouse cursor, which is inaccessible even to many humans.

Making sure everything can be accessed at least by hotkeys, or even better, a command terminal, can benefit power users, users that cannot use a mouse, scripts, and other traditional software, in addition to allowing agents to communicate. These commands should also come with proper documentation, again, to the benefit of everyone.

Then, a GUI can be added to invoke some of these common commands, with dedicated editors for complex ones, to be used by people. The scripts, software, and agents can manage complex commands on their own.

It doesn't really have to be hostile to any approach. If the argument is "why make a GUI at all, everyone should use agents", then I am against that. But "agents can use it, and we don't support vibe gamedev" is also not an argument against accessible design.

[viniciusmorgado]

What do you mean by "agent-native editor"? An agent driving the GUI, or the editor exposing an API, or structured, queryable, programmatic affordances the agent can call? The first is pointless (the agent has direct control over the code, and an editorless engine like Bevy doesn't need the GUI to work properly), and the second already exists below the editor (that's literally BRP, or just the rust code). Either way, it's not a reason to drop the human-oriented UI.

Bevy's ECS architecture places the engine itself and game logic under the same architectural model, which makes it much easier for Bevy to become agent-native.

Sure, agreed, ECS makes Bevy unusually agent-friendly. But notice that it cuts against where you're going, not toward it. The reason ECS is agent-friendly is that everything is just data and code an agent can touch directly. Which is exactly why the agent's home is the code, not a GUI. The same property you're leaning on to argue for an agent-native editor is the property that makes the editor unnecessary for agents. Bevy is an editorless engine that is less reliant on the editor (right now, none at all) when compared with engines like Unreal or Unity.

The next generation of software should likely be designed around agent-native architectures. The era in which users must memorize large numbers of complex operations is coming to an end.

Ok, but this is just speculation, a guess with no real evidence behind it. How many systems actually work this way today, at any real scale? And why would this be the direction everything goes, instead of one approach among several? "Should likely be designed" is basically turning a guess about the future into a recommendation, without backing up either half. Maybe there's something here, but right now it's an assertion, not an reasonable argument.

shouldn't the Bevy editor avoid inheriting the cumbersome human-oriented UI patterns of traditional editors, and instead move directly toward an agent-native design?

There is nothing cumbersome about good human-oriented patterns, they are what assures accessibility. They're the whole reason a GUI is usable for the people who'd reach for a GUI in the first place. You're disregarding this completely, and of course disregarding that maybe people don't want to use AI in their projects. You're treating human-oriented as the outdated thing and agent-native as the inclusive future, but it's backwards.

Think about who the editor is even for:

• If you want an agent to do the work, you're better off letting it write Bevy code directly, and that's true even if you're non-technical and can't read a line of it. An agent writing Rust runs circles around an agent poking at a GUI. Rust is a rigorous language with a lot of compiler guarantees. The GUI at this point is just a lossy middleman.

• If you want to grab things with your mouse and move them around yourself, then you're a human, and what you actually want is good human-oriented design. Which is exactly the opposite of what an agentic workflow needs to be efficient.

An agent-native GUI lands in between and helps neither.

For me, "make the editor agent-native" is almost a category mistake If it's what I think it is, with maybe one exception: if you had said to build it "good for humans and agents" that would likely be a better path to follow. I point this out because you said to avoid human-oriented patterns and go directly to agent-native, which I disagree with. But then, even with the "hybrid" path, there's a question of effort and resources: unless it's an accident, a byproduct of the human-friendly design, or the effort to implement it is low, I don't think it's worth it. If the effort and resources necessary to implement and maintain it are too high, I think it's a gigantic waste of time and resources that should be focused on an editor for humans instead of for agents, since LLMs and agentic workflows can operate directly on your game's codebase.

I think that you can improve the discussion by better defining what a agent-native editor means exactly.

[Mikopet]

As a general rule (in my eyes ofc): less the AI in game development, the better...

I do somewhat understand, when people care about the quick results, early developer feedback, and other stuff what drives the game project forward faster. I really do.

However, game development is a creative territory, where real value lies in the uniqueness of ideas and solutions how the game is built. Sure, I also understand not everybody's goal is to create such values... yet, I really do believe AI must not be the driver how something is built. That only would make the game derivative and just a one-of-many.

"Agent native" suggest that would be the case, and (for me) it is very hard to bear this kind of approach.

---

Again, the problem is not using these tools but to impose it to other developers without even the ability to opt-out normally. (Forcing the industry to follow suit and creating generalized products is already a problem, let's not put more pressure on the people who trying to resist the slop...)