A note added September 2026: I wrote this piece in February 2025 after running a workshop for teachers on having students design educational games with AI tools. I have rewritten it as a reconsideration. The original argued that AI removes the technical barrier so students can focus on design. I no longer think that is true, for reasons I lay out below, and I want to be clear that I did not follow the classrooms afterward, so what follows is an argument rather than a report. The slides and one-pager at the bottom are the originals.
In early 2025 I ran a one-session workshop for teachers called Level Up Learning. The premise was appealing and I believed it: students who design educational games have to understand the content deeply enough to teach it, they build for a real audience of peers rather than for a grade, and they take ownership of something they made. Those benefits are real, and I would still defend them. The new part in 2025 was the claim that AI tools would handle the technical work, so that a student with no coding background could get from an idea to a playable game without the build becoming the whole project. The workshop pointed teachers toward Rosebud AI, a platform where you describe a game in plain language and it generates the code, and sent them off to try it.
What I never checked
The honest place to start is with what I do not know. The workshop was for teachers. I did not sit in on the classrooms where they tried it, and I did not go back and ask how it went. So I cannot tell you that students spent their time fighting the tool instead of designing, though I suspect they did, and I cannot tell you the games were worse or better than what they would have made on paper. A pitch that ends with “and then I never found out” is not a great look for someone who spends his working life telling districts to evaluate before they scale, and I would rather say that plainly than dress it up.
What I can do is explain why, a year and a half later, I would not make the same pitch, and the reasons do not depend on a classroom anecdote I do not have.
The barrier moves, it does not disappear
Describing a game in plain language is not easier than building one. It is a different hard problem. A prompt is a specification, and writing a good specification requires knowing what you want precisely enough to say it, which is exactly the understanding a design project is supposed to develop. So a generator asks students for the output of the learning as the input to the tool. When a student does not have that understanding yet, which is the whole point of the exercise, the tool fills the gap with its own choices, and the student’s time goes to reacting to those choices rather than making their own. I have watched adults do this with AI-assisted coding, and I have written about what those tools cannot do and about keeping human judgment at the decision points. I have no reason to think a seventh grader with a game idea is better positioned than a professional with a spreadsheet problem.
The original piece also treated “no coding required” as a benefit in itself. I am less sure. Code, or a block-based stand-in for it, is a form of friction that does useful work in a design project: it makes a student commit to a decision before they can see it run. Removing that friction does not free up time for design. It removes one of the places where design was forced to happen.
The parts that were never about the tool
Rereading the original, the advice I still stand behind is the least technological. Paper prototyping before touching any tool forces the design conversation to happen when nobody can outsource it. Playing a range of game types first, text adventures, strategy games, simulations, pet games, gives students a vocabulary for what they want, and I would expect the students with that vocabulary to have a much easier time with any tool than those without it. And the classroom culture questions I listed as secondary in 2025, comfort with iteration and the willingness to take a creative risk in front of peers, are the ones I would now put first. No tool creates those conditions, and I doubt any tool compensates for their absence.
Two questions the workshop did not ask
The first is dependency. Rosebud is a hosted commercial platform, and a student’s game lives there. The workshop did not ask what happens when the pricing changes, the free tier closes, or the company pivots, which is a question I now ask of every tool I put in front of a district. A game a student made in a notebook is theirs. A game generated on someone’s server is on loan, and I have written enough about paywalls and lock-in since then to be embarrassed that I did not raise it.
The second is cost. I have argued that generative AI has a plastic waste problem, and a class of students re-prompting a code generator to get a sprite to move is a fairly pure example of expensive compute spent on friction rather than on learning. That does not make the activity wrong. It makes it something to be deliberate about, and the 2025 version of the workshop was not.
What I would do now
I would still have students design educational games. I would not lead with the tool. The design work belongs on paper and in conversation, with classmates playtesting paper prototypes, until a student can say clearly what the game is and why it teaches what it teaches. If a class then wants to build a digital version, the choice of tool should be a choice, made with students, with the trade-offs on the table: a block-based environment where they build the logic themselves, a text-adventure tool where the writing is the game, or an AI generator with the understanding that prompting is a skill of its own and will take time to learn. And I would tell teachers what I now believe, which is that the AI version does not save time. It spends it differently.
I would also do the thing I did not do, which is follow up. If you ran something like this with students, in any form, I would like to hear what actually happened, because I have a suspicion and no evidence, and I would rather have the evidence. You can reach me at licht.education@gmail.com. The workshop was a reasonable thing to try in early 2025, and the slides and one-pager are here because the design reasoning in them is still sound and because the record of what I thought then is part of what makes second thoughts worth having.
