Project Based Learning in the LLM Age

May 2026

I made this collage! Plato's Academy mosaic from Wikipedia and laptop image from Openverse

Background

I started my career as a computer science teacher in 2022, which was a pretty incredible year for computer science as a discipline - ChatGPT was released in November 2022, and I remember the exact day in March 2023 when a lot of my students learned about it from a South Park episode. Learning about this new type of tool alongside my students was thrilling, and a lot of memorable experiences came out of it ^[1].

Every year since then, I've started class with a conversation about what Large Language Models (LLMs)^[2] are, how they relate to our study of computing, and the rules for assignments in my class. This conversation starts with theory because many of my students are missing important context. I encourage students to think of LLMs as "spicy auto-complete,"^[3] that work the same way our phones do when they try to guess the next word to help you type a text message. (This image from Reddit)

We also discuss our learning goals for the course, which include being able to independently read, write, and reason about computer programming languages.

I admit that I use generative AI tools in my work and personal life. In class, I like to call DeepSeek "my favorite tutor" and will frequently model intentional use in the classroom by asking it to help me come up with examples that I can use to explain tricky concepts to students. But we discuss that "my favorite tutor" doesn't just give me answers - and that my learning could easily be harmed if I just asked it to answer questions for me.

Once we're all on the same page about what these tools are, we can turn to policies. My first discussion question goes something like this:

"imagine I make a rule that says you aren't allowed to use these tools in my class and you do anyway - do you think I'll be able to tell?"

Teens are used to getting this sort of question from adults and the answer is always "yes". They have teachers who claim to be able to tell, so they assume I'll have the same answer - but my answer is "no." While there are lots of "AI detector" tools available to teachers, they're notoriously inaccurate. These AI detectors accuse human-written text of being machine-generated, and fail to flag submissions that actually are machine-generated. These false-positive and false-negative rates are so bad that I'd be better off using a magic 8 ball to accuse students of cheating. And unlike the AI generators provided by my school district, the magic 8 ball wouldn't have a racist bias in its errors.

This problem also isn't new - before LLM-generated code, I occasionally had students submit projects that they couldn't explain because a friend or relative did the work for them, or they downloaded it from somewhere online.

So, I want to support my students' use of LLM tools as a complement to their education, and need to make sure that they aren't misusing them. But any attempt to police their use would probably cause more harm than good. What should I do?

Elements of an AI-Proof Assessment Strategy

I'm really proud of the assessment strategy that I've come up with. Before going into the details, it's worth establishing what exactly I'm trying to assess.

Process, not Product

I had the opportunity to present about our program at this year's peer group meeting for technology faculty hosted by the Virginia Community College System. At that presentation, I met Vishal Basani, who teaches at the GMU Data Science and Computing Lab School in Frederick, VA, which sounds like it has a lot of the same goals and culture as my school. Vishal gave a thoughtful presentation about strategies to combat AI use in their program, and had clearly thought about this topic a lot. There were a lot of good ideas in the presentation, and the one that stuck with me the most was that teachers should emphasize "process over product," and that emphasis should be reflected in the grading strategy. Vishal's grading scheme emphasizes students documenting their process. Students are required to download and submit their entire terminal history for each assignment, which shows every attempt they made to run their code, and the errors or output they received. They annotate this output with reflections on the bugs they encountered and the process they used to solve them. I really liked this idea!

At its most fundamental level, computer science is a problem-solving discipline. The real reason I think it's so important for high school students to study computing is not that I think they'll all grow up to be programmers. Regardless of the life/career choices that my students choose after my class, I'm certain that they'll encounter tricky problems that they'll need to break down and solve. The problem solving process (and the growth mindset it requires) is the transferrable skill that I want my students to take away from my class, so I love an assessment strategy that places problem solving first.

Explainable and Defensible Code

I also tell students that writing code is the easy part. The hard part of a software engineering job is convincing people that your code is worth running - engineers regularly participate in code reviews where they need to defend their code to other engineers, and need to advocate for time and resources from non-technical leadership. A lot of my assessment strategy involves requiring that students can explain their code - how it works and why others should care about it.

Project-Based Learning

My school heavily emphasizes project based learning (PBL) where students chart their own learning journeys as motivated by projects. For example, my students start their HTML course by developing a family recipe website - they choose what that website looks like, starting with sketches. As they turn their sketches into reality, they need to learn how to layout a page, embed photos, and format different types of text, instructions, and measurements. By the end of the year, students are building detailed games that run in a web browser using JavaScript (and they turn out great! You can play this year's games here).

These projects necessarily include a lot of work outside of class time, where I can't directly supervise the work that students do. But I love this part of my classes. I could certainly satisfy my course curriculum with only problem sets and multiple-choice tests, but that's not what motivates me, and not the experience I want for my students. I love watching my students get excited about their ideas and take pride in their work. I also like how these projects allow me to connect with my students. Talking with my students about their family recipes at the beginning of the year is a great way to build the relationship that will help us get through the harder content later in the year together.

Implementation

My goals are to create a system where my students can design their own project-based learning paths, can focus on the process of developing code more than the final product, and can confidently present their final results. My solution has a few parts:

Version Control

My colleague Jeff Elkner bases his entire computer science class around student-owned public git repositories. This works fantastically, and I've adopted it for my classes as well. This strategy has tons of benefits for day-to-day classroom organization, and it's the centerpiece of my LLM-aware grading strategy.

On the first day of school, my students create an account on Codeberg^[4], which they use to publish their work. Codeberg works with git, an industry-standard version control software. In git, students frequently "commit", save the state of their code as they are working. Each commit includes a short note about what they are working on.

This "commit history" is easy to read and does a great job of documenting the process alongside the product. When I look through a student's code, I can see how much time they spent on their code, the mistakes that they made along the way, and how their code evolved over time. This log is a great way to keep students accountable - these projects are too big to write in one sitting, so if their entire project appears in a single commit, it's likely that it wasn't written organically.

This is a skill that we build on throughout our program. By the end of our program, students are skilled at using git for collaboration - they use issues to track work in shared repos and review each others' pull requests.

Live Code Defense

The second part of the assessment requires students to defend their code on the spot. This varies based on conditions in each of my classes:

• In my freshman-level web design class, I give students print-outs of their code and have them annotate it as an in-class assessment. I highlight specific lines to explain, and have a few short answer questions that they must answer.
• In my advanced classes, students collaborate on their shared projects. They use a "pull request" model which requires that they present their code to their peers before it is accepted and "merged" into the group project.
• I often ask my students to present their code to the class.
• As the final exam in some of my classes, I conduct one-on-one mock interviews, where students must answer questions about the projects they worked on over the course of the semester. These projects are often big and include lots of small files. We start with some functionality in their finished project, then they need to navigate to the code that defines that functionality and explains how it works.

Grade Helper

Reviewing student code on Codeberg and printing out excerpts gets tedious for some of my larger classes. With the help of a capstone student, Sean, this year we developed the "Grade Helper" to make this process easier. The Grade Helper is a website that maintains links to each student's Codeberg account. For each assignment, I tell students where in their account to save their file. When the assignment is done, the grade helper can do two things:

• Make summary report that lists each student, shows me their final product, and gives me summary statistics about their commit history. It can also run custom validation to make sure that their work meets my requirements.
• Compile everyone's code into a single PDF document that I can print and hand out in class. To minimize variables on test day, this code strips out all comments from the code and uses predictable formatting that students can preview ahead of time.

The grade helper is hosted on our class website, so students can check it any time to confirm that I can see their files and to preview what I'll see when I grade.

I'm really happy with how the grade helper has improved my workflow this year, and we have tons of ideas for improvement. The biggest pain point so far is when student code gets too long. Printing out student code is reasonable when it's short, but by the end of the year the code gets way too long to print. For now, I'm solving this by prescribing how students break up their code so that I can easily identify excerpts to print. I will be very excited to bake this logic into the PDF generator sometime soon!

Results

None of these ideas are original, but I'm really happy with the workflow that they have created in my classroom. The effect is an engaging project-based learning class where students are accountable for the code that they submit, regardless of where the code comes from. Instead of wasting my effort trying to catch "cheaters", we can all have nuanced conversations about the evolving industry and can try to understand it together.

This strategy does effectively catch students who abuse LLMs - I had a student last year who submitted a very detailed physics simulation. When I asked them to explain a math formula in their code, they had never heard of the trig functions in the formula and admitted that they didn't write it.

But those cases are rare - students understand my process and know that they won't get away with submitting code they don't understand. The more common case is that these tools expand our learning. I often have students who come to me with LLM-generated code that they want help understanding - we review the code together, they end up explaining it to their peers, and we all grow from the experience.

I've also found that peer pressure is an effective regulator in this system. Students regularly check the previews on the grade helper to check on their friends' and encourage them to finish their assignments on time. For my advanced classes that use the pull request model, the decision to accept a teammate's contribution into the shared project is a team discussion. So I tell teams that everyone on the team is responsible for understanding and explaining the shared code. When a student asks their teammates to accept code that they can't explain, their teammates are very good at intervening!

I hope that sharing about this system helps other educators who are grappling with these same questions. I would be excited to talk more with anyone who wants to hear more details about any of this. Here is a quote from my last round of course evaluations that helped me believe it's going well:

"I like that this course has a lot of PBL and application. It helps me better understand the material instead of written exams."