AI can write the code, but the design is still on you

Contents
AI has changed pretty much everything about how software gets made. The models we have today write code really well. They can design things too, technically. Ask for an architecture or a whole game and you’ll get one. They just don’t bring the intent behind it, the experience or that human feel for what’s actually right, so that part is still on you.
I’ve been building a couple of games with these tools, and that’s the thing I kept running into.
It writes code really well
If you’ve spent an afternoon with a decent model, you know what I’m talking about. It writes code fast, in whatever style you ask for, and it can build things a lot faster than you (or a whole team of devs) ever could.
There are still bugs, of course, but it can find and fix them on its own as long as you give it a way to check its own work. It writes the code, runs the tests, reads what failed and fixes it.
Giving it that way to check is key. A model with a good test harness is a completely different animal from a model with nothing but your prompt. That can be tests, a build it can run or even just logs, anything that lets it see what it just made. Without that, it’s guessing and you’re the one who finds out (usually in production).
Ask it for the big picture
Ask a model for an overarching plan for a piece of software, the whole high-level design. You’ll get one, and at first glance it’ll look great.
Look a little closer, though, and you’ll usually find it made an assumption early on that isn’t ideal for what you’re building. It doesn’t stop to question it either. It just goes along that route and builds everything else on top of it.
It can’t judge things the way a person does. You can look at a plan and get a bad feeling about one part of it before you can even explain why. Models don’t seem to have that (at least not yet). They’ll happily pick the not-so-ideal option and keep going.
At the time of writing (November 2026), I’m using Fable 5.2 and I still run into this. The plan looks great when you first read it, and then pretty soon the design flaws start showing up. Maybe this gets better in the future, but for now it’s still the case.
Was code ever not a black (ok, maybe gray) box?
Yes, coding is turning into a bit of a black box. You ask for a feature and it shows up, but you don’t always know exactly what’s inside. On large projects, though, that was kind of already the case.
Think about how many memes there are about this, like coming back to your own code from a few days ago, wondering who the heck wrote it and having zero memory of writing it at all.

What idiot wrote this code!? by CommitStrip
Or the comment that says // don't touch anything below this, the app stops working and nobody knows why. There are whole memes about load bearing comments and even load bearing whitespace (yes, really). If something works, you leave it alone.

If it’s not broken by CommitStrip
So not knowing 100% of what your code is doing isn’t new. There’s just a lot more of it now, and it shows up a lot faster.
Now, though, you can just ask. Point the AI at the code and it’ll walk you through what a function does and why it’s there. That wasn’t an option before. You read it line by line, stepped through it in a debugger or scribbled the algorithm on a napkin to figure out what some variable was at some point. Granted, there was a lot less code back then. But you get my point. There’s more code now, and there are also much better tools to understand it.
It’s even more true in companies. Internal tools aren’t always well written, and a lot of different people end up touching the same code over the years. In some of those cases, I actually think AI does a better job. At least it’s consistent (and it won’t leave you a comment like the one above).
You can’t be lazy about the decisions
Humans still need to drive this thing. If you get lazy and offload the decision making, the policies and the overall design to the model, it’ll work for a while. It might even look great in the demo. Then it comes back to bite you later, when the thing has real users and a decision from day one is now load bearing.
It’ll build pretty much anything you describe. Deciding what to build, and how it should all fit together, is the part you still have to own. This is especially true for complex software, and even more so for games.
Games are where it really shows
I’ve had a few game ideas floating around in my head for years. Some notes scribbled down somewhere, a vague idea of the UI, certain events and situations I really wanted to see in the game. Nothing close to a full design, but I knew roughly what I wanted.
So I gave it a shot. I did a full brain dump of everything to the AI (Opus 5.5 and Fable 5.2, the best models available at the time) and asked it to come up with a plan and gameplay based on actual industry best practices. I also asked it to interview me so we could build the game together, and over a bunch of questions I gave it all my ideas and direction.
Then it built a prototype, and it fell flat. Sure, it’s a prototype, so you expect some rough edges, but everything about it was bland even though it did everything I asked for. I’d even had it write bots that played the game over and over to tweak the numbers and weights, so a game lasted about as long as I wanted without ending too quickly or dragging on, and the player had a chance to go through all the available systems. All of that worked, and it still didn’t feel right.
I tried a few rewrites. At one point I let the agent loose on it and told it to go crazy, throw everything out if it wanted to and revamp the whole thing. The game changed quite a bit after that, but it still felt exactly the same.
This wasn’t a one-off either. I did this with two completely different types of games and ran into the same problem both times.
It took me a lot of thinking to figure out what was going on. The AI took my instructions as a checklist of things to build. It did every item on the list and did it correctly, but it never had the intent behind the list. It doesn’t inherently know what makes a game fun. If you ask it to make the game fun, it’ll add things that are supposed to make a game fun, but there’s still something missing that I can’t quite name. “Soul” sounds a bit weird, but it’s the closest word I’ve got. Maybe it’s intent, or maybe it’s just good design.
If you’ve played a procedurally generated game that felt a bit off, you might know what I mean. There’s a ton of content and lots of possibilities, but something about it feels hollow. The phrase “mile wide, inch deep” kept coming to mind. It’s not exactly the same thing, but that’s what it reminded me of. There’s something different about stuff that’s handcrafted, and I honestly don’t know what it is.
So for one of the games, I started over the old fashioned way. Pen and paper, but no AI. I asked myself what I actually wanted out of this game, imagined myself playing it at every step and spent hours planning out the systems and how they work together. Then I asked the AI to build exactly what I’d written down and stick to it.
The prototype it built this time was much, much better. It was actually engaging, and every part of it had a reason to be there because I’d put it there.
The bottom line
At the end of the day, AI is a really good, very fast pair of hands. The overall logic, the vibe and the goal of the thing still have to come from you, especially for complex software and games.
So go ahead and let it write the code, and give it a way to test its own work. Just do the design yourself first.
Header photo by Rudi Endresen (via Unsplash)