S&box Looks Great, But AI Can't Write Code for It Yet
I just found out about s&box, and I have to say — this is the most genuinely exciting game engine announcement I've seen in a long time. A spiritual successor to Garry's Mod, built on Valve's Source 2 engine, fully open-sourced under MIT, with C# scripting and a modern scene system that borrows the best ideas from Unity and Godot. It launches in April 2026. That's next month.
I'm excited. I'm also pretty sure I won't be using it.
What Makes S&box Impressive
Let me give s&box its flowers first, because it deserves them.
Facepunch has been working on this since 2015. They bounced between Unreal Engine 4 and Source 2 before landing on a heavily modified Source 2 build — the same engine that powers Half-Life: Alyx. The result is a platform that feels modern despite its Source lineage:
- C# scripting with hotloading — change your code and see it instantly, no compile-restart cycle
- A scene system modeled after Unity and Godot, with GameObjects and Components
- Built-in multiplayer, a terrain system, visual scripting via ActionGraph, and a shader graph
- Cloud-based asset system with drag-and-drop
- VR support out of the box
- No royalties, no licensing fees — publish standalone games on Steam or anywhere else
And as of November 2025, the C# layer is fully open source on GitHub under the MIT license. That's a huge deal. You can read the engine code, contribute to it, fork it. The underlying Source 2 binaries remain proprietary, but the entire scripting and editor layer is yours.
This is a serious engine. Not a toy, not a prototype — a real platform from a studio that shipped one of the most enduring sandbox games ever made.
The Problem: AI Doesn't Know S&box Exists
Here's where my enthusiasm collides with my workflow.
I build games with agentic coding tools. That's my thing — I use Claude, GPT, and other models as collaborative partners in my development process. And when I evaluate a new engine, the first question I ask isn't "is the editor nice?" It's "can my AI actually write code for this?"
For s&box, the honest answer is: not yet, and probably not for a while.
Training Data Cutoffs Are the First Wall
The leading AI models have knowledge cutoffs that predate s&box's maturity:
- Most models were trained on data through mid-to-late 2025 at best
- S&box's open-source release happened in November 2025
- The scene system overhaul — the one that made s&box actually resemble a modern engine — landed in August 2023, but the API has been a moving target since
So when you ask an AI to write a s&box Component, you're asking it to work with an API it has barely seen. It might know that s&box exists. It almost certainly can't write idiomatic s&box code.
C# Familiarity Is a Trap
"But it's C#!" I hear you say. "AI is great at C#!"
True. AI models are excellent at C# — when it's Unity C#, or ASP.NET, or vanilla .NET Console apps. They've trained on millions of lines of that code.
But s&box C# isn't Unity C#. The API surface is completely different. The component lifecycle, the networking model, the scene system, the asset pipeline — none of it maps to Unity's MonoBehaviour pattern or Godot's node tree. An AI that confidently writes void Start() or _Ready() is going to produce code that doesn't compile in s&box.
Worse, s&box runs a restricted .NET subset. You can't use System.IO.File. You can't access the filesystem directly. Certain namespaces are sandboxed. An AI model trained on general C# will cheerfully suggest APIs that are explicitly blocked.
The Corpus Problem
This is the deeper issue. AI models are, at their core, pattern-matching engines trained on existing code. Their effectiveness with any platform is roughly proportional to how much code exists for that platform in their training data.
For Unity, that corpus is enormous — millions of tutorials, Stack Overflow answers, GitHub repos, YouTube transcripts. For Godot, it's growing fast. For Unreal, it's deep in C++ land but well-represented.
For s&box? The community is passionate but small. The documentation at sbox.game/dev is still filling out. There's an unofficial wiki, a community-driven superdocs site, and some Steam community guides. But the total volume of s&box-specific code and documentation available on the open internet is a fraction of what exists for established engines.
This matters. When an AI model hallucinates an API call, it's because it doesn't have enough examples to know the real one. With s&box, hallucination risk is high.
ActionGraph Can't Be Automated
S&box includes ActionGraph, a visual scripting system. This is great for designers and beginners — but AI coding agents work with text. They can't drag nodes around in a visual editor. If part of your game's logic lives in ActionGraph, your AI assistant literally cannot see or modify it.
What Would Need to Change
I don't think s&box is permanently AI-unfriendly. Here's what would move the needle:
-
Time. As s&box launches and the community grows, more code will appear online. Future model training runs will include s&box examples. This is the biggest factor and it's just a matter of waiting.
-
Documentation depth. The more comprehensive and example-rich the official docs become, the better AI models will learn the platform. Facepunch has a track record of good developer relations — I'm optimistic here.
-
Community growth. Every tutorial, every open-source s&box game on GitHub, every Steam workshop upload with source code — it all feeds the training pipeline eventually.
-
RAG and context injection. You can partially work around the training gap today by feeding s&box documentation directly into your AI's context window. It's clunky, but it works for targeted questions. The open-source codebase helps here — you can literally point an AI at the engine source. A well-crafted CLAUDE.md file loaded with s&box conventions could go a long way.
My Verdict
S&box looks like it could become one of the most important game engines of the next decade. It combines the modding DNA of Garry's Mod with a modern architecture, open source ethos, and the raw power of Source 2. I'll be watching the April launch closely.
But for my workflow — where AI agents are core collaborators, not optional helpers — s&box isn't ready. The training data gap is real. The restricted API surface creates traps. The niche corpus means constant hallucination risk. I'd rather use an engine where my AI partner can write correct code on the first try than fight an uphill battle teaching it a platform it's never seen.
If you're an experienced C# developer who doesn't lean on AI assistance, s&box could be perfect for you. If you're part of the agentic game development movement — building games with AI, not just about AI — you'll want to stick with Unity or Godot for now and revisit s&box in a year or two when the models catch up.
I'm genuinely rooting for this engine. I just can't use it yet.
Interested in how AI is changing game development? Read more about building a programming language designed for AI to write, or explore indie-friendly tools at Gamestruction.