When AI writes the code, we have to teach the thinking
For the past two years, I've helped teach a product development course at a university in Prague. This year, our team had to ask an uncomfortable question: when AI writes most of the code, does it still make sense to teach software engineering the way we always have?
For about ten years, Jan Černý, the CEO of Applifting, has led 4IT580, a product development course at the Prague University of Economics and Business (VŠE). Every year he brings practitioners into his teaching team, and that is how, last year, I got the chance to join and help with the seminars. It looked cool, it came with a lot of responsibility, and it was a big challenge, all at once.
The first year
That first semester, I was one of several people sharing the work. I prepared one seminar and spent much of my time doing code reviews for the student teams. VŠE is an economics university, so the room ranged from students who already work as developers to people building their first real app. A few of them were genuinely talented. By the end of the semester they had shipped real products, and I walked away with the quiet satisfaction of having been useful.
But I also walked away with a nagging feeling. The course setup lagged behind how we build software at Applifting, and behind what I believe a good project foundation looks like. The starter template was overcomplicated. Its frontend followed atomic design, a pattern that has not aged well, and the students said so. They spent their energy navigating the structure instead of building their product.
Parts of the codebase were outdated even by everyday industry standards, and honestly, that made it a little painful to teach in.
So when the conversation about next year started, I volunteered again. This time I knew the course from the inside, and I offered to rework the seminar plan and rebuild the codebase it stood on.
The bigger question
When we started preparing the new semester, we asked ourselves something harder: does it still make sense to teach this course the way we always have? The course was designed for a world in which learning React and Node syntax was a large part of the job. That world is disappearing, because AI now writes most of the syntax, and it writes it fast.
This doesn't mean students no longer need to understand code. As I argued in my previous post, AI multiplies judgment, and juniors don't yet have much judgment to multiply. But syntax is no longer the bottleneck. What students need to learn is how to think about building a product: how to break it down, how to structure it, and how to draw boundaries clear enough that AI can work inside them and produce clean, correct code that is ready to be extended.
We had been teaching the part that machines are taking over, and undertraining the part they can't. So we decided to redesign the course completely.
Learning from those who started earlier
I didn't want to design it on intuition alone. Other universities face the same questions, and many have far more resources to think about them early. So I studied how they teach similar courses: MIT's Software Design Studio and Software Construction, Harvard's software engineering capstone, Stanford's CS194, and Austin Henley's analysis of more than 50 software engineering courses.
What I found was reassuring and humbling at once. Nobody teaches exactly our course, but several came close, with roughly 80% overlap. From MIT I took the idea that every student first goes through the whole development cycle alone, so nobody can hide behind the strongest teammate. Harvard gives every team a weekly meeting with an advisor. Our teams already meet the product teachers in weekly standups, but a weekly technical review of every team's code is more than a small group of practitioners teaching next to full-time jobs can run. We settled for two deep code reviews instead.
The result was a new curriculum built on vertical slices. In the old course, the backend didn't appear until the fifth class, so for weeks students couldn't build anything that touched data. Now they ship a feature from database to screen in their second seminar. And instead of a tool, they learn a loop: say what you want, let the agent write it, review it, steer it, and capture what you learned so the agent does better next time.
I brought it to the teaching team, we discussed it, and they agreed to go with this plan. That agreement mattered more than the document itself. A curriculum is only as good as the people willing to teach it.
The rebuild
A new curriculum needed a new codebase. As the person who carried the idea, I was best placed to build it, and in practice that meant a complete rewrite. Feature-sliced design replaced atomic design, shadcn/ui replaced Chakra UI, and students now build on top of a small but fully working social media app. Then came the design. Students are merciless critics of small things, and I wanted to give them nothing to call crap.
I couldn't have done it without AI tools. Next to my day job, I would never have found the hours. Somewhere along the way I noticed I was working exactly the way I wanted students to learn: I made the decisions about structure and boundaries, and AI did most of the typing.
Once the foundation was ready, I presented it to the team so everyone could prepare their seminars from the same baseline. I prepared the first three seminars myself to set the pace and rhythm of the new course. Meanwhile my colleague, Tomáš Klíma, rebuilt how student projects are hosted. Every student and team now gets an automatically created repository, and a push to main deploys automatically. It is how software ships in the real world, and students experience it from the first week.
Halfway through
We are about halfway through the semester. It is too early to call this a success. But a few things are already clear.
Our biggest bet was that students would want to work with an agentic workflow from day one. That bet is holding. Had we kept the old course, I believe many of them would have been disappointed. So far, every student has delivered every homework assignment.
The people behind it
None of this is a one-person story, and it would be wrong to tell it as one.
Jan Černý has carried this course for ten years, always alongside a demanding leadership role. What strikes me most is that he has never treated it as finished. He is always open to change and always asking how to teach it better. He also leads the product side of the course, where his team made a leap just as big as ours in how they guide student projects.
The seminar team, Jiří Hájek, Tereza Šimková and Tomáš Klíma, agreed to teach in a way none of us had tried before, which meant designing new seminars without an old version to fall back on. That is a lot of work to sign up for next to full-time jobs.
And the product team, Veronika Charvátová, Markéta Dlouhá and Tomáš Kříž, meets every student team in weekly standups. Their job has changed too. When building a feature gets much faster, product work grows: deciding what to build, and what not to, matters more than ever. They steer the students through that new world week by week.
I said yes to teaching because it looked like a cool challenge. If I'm honest, I stayed partly because I find it hard to say no. But mostly I stayed because I saw a chance to make a real difference. I still remember courses from my own university years that were already outdated when I sat in them, and how little I took away from them. This was my way to make sure these students won't say the same about ours.