On November 17th, 2025, I led an hour of a professional development workshop for NJ K-12 teachers at the College of New Jersey. I was nineteen and the least experienced educator in the room, but I was there to teach a group of veteran teachers how to vibe code.
Demonstrating SplashGPT to the room
This side quest found me through Mark Snow, a mad-scientist-esque Central Jersey teacher who has taught computer science for nearly two decades; we met in New York City at EdTech Week 2025 that October. Most of Mark’s work has very little to do with teacher PD: he spends his energy building out hardware to spin up local AI models for his students and trying to keep NJ schools from adopting AI-powered surveillance technology.
I grabbed his email and called him within a week. He mentioned that he needed somebody to cover a session on Google AI Studio, a platform that had only just come out and that he had no time to explore himself. I told him I was interested, and instead of briefing me on his workshop in any conventional way, he handed me a NotebookLM assembled out of the material for every session in the series and told me to ask it questions. I had never thought to use NotebookLM in this way—this would be one of many creative AI use cases Mark would introduce me to.
My plan for my hour was to build an FDR chatbot in Google AI Studio. I was going to feed fireside chat transcripts to an AI and build a little interactive history applet where a student could talk with Roosevelt, pull direct quotes out of him, and get some feel for how he actually addressed the country. I was fairly sure this app would code up easily, and I assumed this use case was the fastest way to wow a room of teachers.
I built a rudimentary version, and on our next call I showed it to Mark alongside another app I had built on the side—SplashGPT, an internal tool for Yale Splash, which I’ll cover in a different blog post. Surprisingly, Mark told me to drop FDR entirely. The chatbot was a toy I had made because I knew the model would handle it well, whereas SplashGPT was something I had made because a problem was irritating me; he strongly believed my authentic application of vibe coding would resonate with the audience far more than the toy.
Mark asked me to get in front of a room and nerd out about a student organization none of them had heard of, and that’s exactly what I did. I stood in front of somewhere between fifteen and twenty-five educators sitting at circular tables with their laptops open, explained what Splash is and what about running it had been driving me crazy, and showed off the tool and the prompts it took to build it. What seemed to energize the audience was how few prompts it took to get a functioning app and how little technical vocabulary any of my prompts contained.
The teachers were then given thirty minutes to build something of their own, and I spent that half hour walking between the tables, helping people when they got stuck. Here are my takeaways:
All teachers are software developers
Everybody in that room had used a chatbot, and most of them had concluded from that experience that AI was a text box that talks back to you. Google AI Studio was, at that moment, the first free interface where a teacher could describe an app they wanted and watch it run in the same tab. They didn’t need to download anything, set up an environment, or, worst of all, open a terminal. Watching AI build them a decent, working app in front of their eyes, for free, broadened their sense of what AI could do for them.
Mark and I were originally worried that thirty minutes would be too little time to build anything. That was not the case—nobody sat there wondering what to make for even a second. Every single teacher already had a problem identified, a use case scoped to their exact classroom, and a precise sense of what would land with their particular students. Within ten minutes, people were playing games they had been imagining for years.
Teachers, at heart, are software developers. They have the ideas, the design instincts, and the learning science. They were primarily bottlenecked by their inability to code, and now the barrier to entry is far lower. One of the teachers I talked to had spent her entire career dreaming of making educational games, and had been seriously weighing whether it was worth going back to school to reskill into computer science in order to do it. She told me that afternoon she felt closer than ever to her dream of making something fun and meaningful for her students.
… but not all teachers are technical
At the end of the thirty minutes, Mark and I were bombarded by the same question: How do I show this to my students? How do I get this to my class? Unfortunately, AI Studio required, at the time, a premium subscription to deploy an app on the internet. There were audible groans. People had just made something they were proud of, for free, and the last step was fenced.
Mark and I went around telling everyone they could deploy it for cheap—you could take the code the model wrote, put it on GitHub, deploy it on Vercel, generate your own API key if necessary, and pay cents for a custom chatbot instead of a monthly fee. Unfortunately, that path required a technical background these teachers did not have, and we had no way of compressing that setup into a one-hour session. I would guess that most of those prototypes never made it in front of a single student.
So the deal, as it stands, is that either somebody charges a teacher for the service of putting their work on the internet, or the knowledge required to do it themselves sits slightly out of reach. The beginning is finally accessible but the end is still gatekept, by money or by knowledge. It is not impossible to teach a non-technical person what an environment variable is; a tool that helps somebody build for free should help them ship for free. We need friendlier products (or a bit more PD) before every teacher is truly able to ship software.
Big EdTech is fooling teachers
Almost everyone in that room identified as a MagicSchoolAI user. I think that is why they were so startled by what they could make for themselves with direct access to a frontier model in half an hour. They had been going back and forth with a wrapper for a year or two and had quietly concluded that AI was going to improve the efficiency of their work, but never change what they could do. A large part of educational technology sells teachers the premise that the underlying technology is “beyond” them, that AI models are “too complicated” and “FERPA too dangerous” to handle without an intermediary. That premise collects a service fee and student data while keeping very capable teachers permanently one or two years behind the frontier. Learning management systems have been running a longer, slower version of the same play for decades. I talked to a lot of people that day who were fed up with Canvas—these teachers had a clear, detailed picture of what they wished their course looked like online, but they had accepted as a fact of life that every student must sign into the same drab, lifeless platform.
The alternative, the reality where teachers challenge Big EdTech and make their own apps, has been explored before—Edupunk is the word. Jim Groom coined it on his blog in May of 2008, in a post called “The Glass Bees”, and it describes a do-it-yourself posture toward educational technology in which teachers build and run their own tools rather than accepting whatever was procured on their behalf. I found it through Justin Reich’s Failure to Disrupt (which I promised to read last summer and finally finished last week, so a blog post on that is incoming).
For most of its life, Edupunk has been available only to instructors who were already unusually technical, which is a small club, but I do not believe it will stay a small club forever. I can see a future where schools start asking harder questions about what big educational technology is actually worth, where their students’ data goes, and who is collecting the check. The answer may turn out to be running things locally and letting teachers build the platforms they want, which is cheaper, safer with student data, and vastly more customizable.
That future is not here yet, but the barrier to being technical has come down so far, so fast, that the movement Groom named eighteen years ago has a real shot at a second life. Edupunk has a complex and fascinating history I have barely scratched the surface of—hopefully, upon further investigation, my gut feeling still holds up!
The room working
Conclusion
I loved this side quest. I crashed on friends’ couches at Princeton and Rutgers on either side of the workshop, got very little sleep, and drove four and a half hours back to New Haven to make it to class on Monday morning. Leaving campus for a weekend during term is one of my favorite things in the world and I am always hunting for an excuse.
This fun weekend also turned out to be very meaningful. I got to share a personal project I was excited about, and I spent half an hour walking around a room watching people build things they had been imagining for years. Teachers approached me for selfies and asked for my email to follow up with more questions. If AI ends up doing something good for classrooms, it will be because teachers like the ones in that room got to build what they actually wanted, and I left believing that it will.