The New Computing
Watch
AbstractAbstract
AI is transforming computing, education, and society. As computing educators, we have a particular responsibility in this moment—to work through the uncertainty and prepare graduates who can shape the AI era. That requires rethinking not just how we teach, but what we teach: the very content of our assignments, courses, and degree programs. This ~25-minute talk opens Day 0 of the GitHub Education Educator Summit and walks through three redesigns already underway at Illinois—an assignment, a course, and a degree—organized around a single hypothesis: that AI collaboration is a distinct skill, independent of but related to classical programming.
SummarySummary
The opening talk for the GitHub Education Educator Summit’s Day 0 Changing Curriculum workshop, in person at GitHub HQ. It argues that AI’s emergence forces computing educators to redesign what we teach, and walks through concrete steps at three scales: a Spring 2026 redesign of CS 124 around independent, AI-collaborative student projects graded on time-on-AI; Using and Understanding AI, a new course for non-technical students built entirely through conversational programming and anchored by multi-agent conversational assessment; and a draft Applied Computing degree inspired by architectural pedagogy. The throughline is a hypothesis—that AI collaboration is a skill of its own—and the open question it raises for the rest of the summit: what is the right balance between classical fundamentals and agentic development, and what specifically makes someone a good AI collaborator?
History rhymesHistory rhymes
The opening reads five quotes from computing pioneers without attribution. They sound like they could have been said yesterday. They weren’t. Grace Hopper on programming in plain language. Joseph Weizenbaum on what we don’t know how to give machines. J.C.R. Licklider on translating natural-language goals into procedures. Edsger Dijkstra on a high-level language mutilating the minds of students learning to program. John Kemeny on millions of people writing their own software. 1958 to 1976.
The hope-and-fear cycle is older than the technology. We have been here before, every time computing has moved closer to ordinary people—compilers, BASIC, the personal computer, the web. Every time, we worked through the uncertain middle. We will this time too. The rest of the talk is a few first steps I’ve taken—not predictions about how it ends, but moves I can show you.
Assessments: CS 124 in Spring 2026Assessments: CS 124 in Spring 2026
The traditional model of a programming assignment: write a specification, hand it to students, they translate it into code, I grade the code against the spec. In July 2025, with Claude Code, I sat down with the multi-week Android assignment we give CS 124 students and watched—with only the test suites in hand, not even the prose specification—as Claude completed the entire thing in an hour. The shape of assignment we had used for decades broke that afternoon.
We tried a partial fix in Fall 2025: blur the spec, give students less to hand to AI. It failed. The information students need to fairly complete an assignment is enough information for AI to complete it too. So this spring, we went back to the drawing board.
In Spring 2026, every one of ~400 CS 124 students designed and built their own Android app with Claude Code. The hard part of working with a coding agent isn’t generating code—it’s getting the idea out of your head into a specification the agent can follow. The course scaffolds that work: the first half is design, ideation, peer feedback, and brainstorming feasibility with Claude; the second half is structured building sessions. Because no two projects are the same, we grade for time on AI—instrumented from session logs, with AI itself distinguishing substantive engagement from off-task chatter. Classical programming fundamentals stay rigorous in parallel: 15 hours of proctored testing per semester in the Illinois computer-based testing facility, mastery learning, and frequent small assessment with rolling retakes. The pre-AI pedagogy that worked still works.
Courses: Using and Understanding AICourses: Using and Understanding AI
This semester I launched a new course on generative AI for non-technical students, designed as a general-education entry point into AI literacy—no prerequisites, no code. The experiment isn’t only what to teach; it’s how many places in the course’s content, infrastructure, and operations I could let AI in.
The course infrastructure was built entirely through conversational programming. I did not manually read, write, or debug a single line of the code that powers the site—across 199 sessions, 4,038 turns, and 29,770 tool calls. Inductive sessions use interactive artifacts students play with before we name the mechanism; AI-supported preparation means human-to-human conversation in the room starts on common ground; and the piece I am most excited about pedagogically is conversational assessment—the chat-based equivalent of an oral exam, scaled. A multi-agent system: an interviewer agent talks with the student, an evaluator agent watches the rubric. We validated it against adversarial personas; the hardest to defeat was the confident bullshitter. The same recipe collapses any slow human feedback loop into many fast ones.
Several students kept building beyond the course. One built a full-stack replacement for the apps her sorority pays for; another, an aquascaper, built a tool for tracking tanks, livestock, plants, water chemistry, and maintenance—a domain I had never heard of before this semester. With Cory Gwin at GitHub I am planning a Fall 2026 pilot of Conversational Programming, a course for non-technical students with no code to read or debug.
My hypothesisMy hypothesis
The talk names its throughline explicitly: AI collaboration is a distinct skill—independent of, but related to, classical programming. The prevailing view treats them as stacked—learn to code first, then you can build with AI. I suspect they are independent. In both worked examples, most of the value came from decomposing the problem, directing the AI, and judging its output—not from reading or writing source code. If that’s right, we shouldn’t gate agentic work behind a year of programming; we should at least try teaching it first. The honest caveat: every result we have was measured on students taught code-first, so no one has actually run the other experiment yet. I argue this at length in Another Skill.
Degrees: Applied ComputingDegrees: Applied Computing
Through faculty discussions at Illinois about how our programs should change, two populations have come into focus. Some students want to understand computing—the theory, the internals, the depth. Some want to use computing to solve problems in the world. Not categories—dimensions; most students mix. CS degrees today serve the first population well, the second only obliquely.
Applied Computing is a draft proposal for an undergraduate degree built for the second population. The core leans on conversational programming first, classical programming later—six courses across the first two years, ordered deliberately: fluency first, then the move backward to reason about the systems underneath. Outside the core, three pillars: a domain concentration via any existing minor, formation through writing, literature, moral reasoning, and studio art, and a studio progression with a public capstone defense. Much of this is borrowed from architectural pedagogy—students build, critique, iterate, and validate, repeatedly, in front of peers and the public.
The section closes on Stewart Brand. In 1968, Whole Earth Catalog: “we are as gods, we might as well get good at it.” In 2009, he updated the verb: “have to get good at it.” We are handing students tools more powerful than anything Brand had in mind—and we have a particular responsibility for what they build.
What’s nextWhat’s next
The talk hands off to the afternoon’s Changing Curriculum workshop and to the Day 2 Curriculum Overhaul session—co-presented with Cory Gwin and Leo Porter—which take up the open question it leaves on the table: the right balance between classical fundamentals and agentic development, and what makes someone a good AI collaborator. Thanks to Cory and Morgan at GitHub Education for hosting, and to Leo Porter for facilitating.
Slides
The New Computing
Thank you to GitHub Education for hosting us. We are in such a moment in computing education. Generative AI and coding agents are opening up new opportunities for our entire field, and new questions about how we teach. In the next twenty-five minutes: three redesigns from this year at Illinois, an assignment, a course, and a whole degree. One argument at three growing scales, and then I hand off to Cory.
Let me start with a few things people are saying. Anyone, accountants, analysts, operations managers, can use this system with little training. Detailed computer coding is no longer necessary.
Since we don't know how to make AI wise, we ought not give AI systems tasks that demand wisdom.
Computers will soon devise their own procedures for achieving goals we specify in plain language.
It is practically impossible to teach good programming to students who have had prior exposure to AI tools: as potential programmers they are mentally mutilated beyond hope of regeneration.
We are about to see millions of people writing their own software.
History rhymes. One thing I have found helpful in this moment, to orient myself and find a path through the uncertainty, is to realize that we have been here before. The quotes I just presented as contemporary are not.
They are modified quotes from computing pioneers, from 1958 to 1976. Grace Hopper, who was tremendously excited about people communicating with computers in English, and who I bet would be thrilled by what is happening now. Licklider and Kemeny with the same hope. And Dijkstra, a sharp thinker, worrying that BASIC would mutilate students' minds. As someone who learned BASIC growing up, I hope I avoided that fate.
We have always had these threads of hope and fear accompanying every advance toward communicating with computers in our own language. When the first compilers came out, people worried that the knowledge of writing assembly by hand would be lost. Each time we charted a path through the hope, the fear, and the uncertainty, and kept democratizing computing. I don't know the future. I want to share a few first steps.
Assessments
So let's begin with assessments. Grace Hopper, in the FLOW-MATIC manual in 1958: familiarity with detailed computer coding is not necessary. This work on CS 124 is in collaboration with our head tutors, head graduate tutors, colleagues at Illinois, and the rest of a staff of more than fifty.
I have taught introductory computing at the University of Illinois since 2017, and for years I used an assessment model I think is pretty traditional.
I come up with an idea for an assignment.
I turn it into a specification and give it to the students.
They turn the specification into a working program and hand it back.
And I grade the program against the specification.
Last summer, after I began working with coding agents myself, I did what I suspect many educators have done: I wondered whether they could do my homework. In July 2025 I sat down with Claude Code and the multi-part, multi-week Android assignment we give CS 124 students. With only the test suites we provide, not even the full specification, Claude completed the entire assignment in about an hour. This is that hour, sped up thirty-two times.
So the pipeline looks like this now. The idea, the specification, the student, the same as before.
But the student hands the specification to AI.
And AI produces the program that comes back to me. The specification has to be clear for grading, and if it can be handed to AI and the result turned in with little or no prompting, very little learning is taking place.
I would argue there are really two kinds of assignments today.
There are assignments students do without AI, where they engage with the traditional learning goals: a description, a result, a grade.
And there are assignments done with AI, where the student and AI collaborate to get to the result. We need to teach students to use AI, and that takes assignments that engage them with it collaboratively. An assignment they can one-shot is not a good assignment to do with AI: they learn neither the original material nor how to work with AI.
In Fall 2025 we tried something. Could we give students a specification a human could understand but an AI agent couldn't? Start with a clear one: implement a linked list with insert, delete, reverse, and toString.
Then make it harder to read: the same assignment in emoji.
Then blur parts of it. The idea was to provide the specification in a way that slows AI down without stopping a student.
It did not work. The information we had to give students so they could all complete the same assignment, and so we could grade it fairly, was enough for AI to do the assignment. And students reported that they didn't learn very much. In their words: the project is too difficult to do by yourself, yet too easy to do with Claude. You can just ask Claude to do everything for you.
So this spring we went back to the drawing board. By then I had been using coding agents more, and I was starting to see what is still difficult. Generating code is not difficult. What is hard is getting the idea out of your mind and into a specification, through a conversation with a coding agent.
So rather than everyone doing the same project, each of about four hundred students in CS 124 came up with their own idea for an Android app.
Then, working with AI, they built it.
And the instructor sees their app, not one more copy of the same assignment. No two are the same, and that is the point.
We redesigned the course to scaffold this. Over the first half of the semester, weekly activities work on design and ideation: students interview each other, give feedback on each other's ideas, and brainstorm feasibility with Claude, ending with a plan. Over the second half, building sessions introduce productive and effective ways to collaborate with AI: plan mode, tests first, architecture, and learning a concept the app depends on.
Because students were all doing different things, they make different amounts of progress, and we set up the assignment to support that. First every student builds an MVP. Then they pick from a series of further tasks, in design, development, evaluation, and stretch goals like deploying the app, chosen with advice from their project mentor. About half the course finished their MVP and went on to these tasks.
With four hundred students all doing different things, how do we evaluate them? Rather than gauge how much progress a student made, we look at how much effort they put in.
We collect students' Claude sessions and measure time on task, both from the timestamps and by engaging AI in the grading workflow to distinguish legitimate from off-task interaction. A student talking to Claude about the weather does not count.
That produces a dashboard where students can see their progress. We ask for an average of four hours a week over the six weeks of the project, and up to eight in a week for students who want to work ahead.
I like this because one of the old features of the assignment model was never great. Give everyone the same thing to do and you get a wide spread of effort: some students get stuck on a nasty bug, others get a lot of help from staff. Same point A to point B, different routes, different frustration. Now everyone starts in a different place and makes an equal amount of progress through a big idea space, and the distribution of effort collapses.
I could spend ten minutes on what the students built. I was blown away, not just by what they accomplished individually but by the collective breadth of their interests. A simplified launcher for seniors, with medication reminders and a kiosk mode. A lab assistant that schedules and tracks multi-day materials-science experiments. A quote-sharing app with emotion tagging and an interactive 3D sphere.
We have always known this, but when you give students the ability to make their own choices, they find things they are interested in, and that engagement drives learning. That is one of the opportunities AI gives us: assignments that give students more agency, so the learning happens aligned with what they care about.
Now, I don't want to leave you with the impression that we are not teaching classical programming. We still are. Fundamentals still matter, for the people who will work at that layer; whether they are the prerequisite is a separate claim. We have a large bank of programming problems that students solve on learncs.online, and they do fifteen hours of assessment in our computer-based testing facility, solving programming challenges without the ability to use AI.
We also have debugging exercises: find and fix the problem in a small broken program. Reading and reasoning about code is the part you can't skip if you are working at that layer.
We have done a lot of development work on this, including papers published at SIGCSE. Solution-based autograding is how our problem bank grew to 771 problems between 2020 and 2024: the autograder is generated from a solution, so the student's code has to behave correctly, and we don't care how it got there.
And the problems cover the topics of the course, from declaring methods to lambda expressions.
We also use what I consider best practice at this point: frequent small assessment. Instead of four hours of proctored high-stakes exams, a midterm and a final, students take fifteen hours of short proctored quizzes across the semester.
It is a rolling retake strategy. Each week they see new material, and they also have the chance to go back and retake old material.
And the amount of assessment we do lets us drop low scores, the best twelve of fifteen, so we get a better picture of what students actually know.
I could spend ten minutes on frequent small assessment too. Students do better. They don't fall behind without knowing it. It allows student-friendly grading, it is probably less stressful, and preparation drives learning. The same pedagogical techniques we used before AI that are super effective are still going to be effective today. We should keep using them.
Institutional support: our computer-based testing facility at Illinois. It is tremendously valuable to my own classes, proctored assessment on a computer, and I think it is a tool we are going to want and need more and more in the era of AI. It holds the classical programming quizzes in CS 124, and the same facility holds a very different kind of assessment, the conversational one.
So this is the shape of CS 1 today: classical fundamentals measured in the testing facility, plus a real project students design, build, and get graded on for engagement. Two lanes, run in parallel. Which leaves an open question: what is the right balance, and does the agentic work really need the fundamentals to come first? I have a bet, and I will make it before the end. The cleanest test is students with no fundamentals at all.
Courses
The next step is slightly larger: new courses. Seymour Papert, in Alan Kay's 1972 paper: should the computer program the kid, or should the kid program the computer? This work is in collaboration with colleagues at Illinois, UBC, Replit, GitHub, and Optimizely.
This spring I launched a new class on exploring generative AI: Using and Understanding AI. It is a small pilot, designed for a non-technical audience, something that could be taken as a general education requirement. No prerequisites, no prior experience, no code. The goals are working mental models of how AI systems actually work, and the judgment to use them well. The syllabus is online.
For me, this was a very intentional experiment in how many ways I could integrate AI into every stage of developing and delivering a course. AI as co-instructor.
Content: AI helped me with the syllabus, the activities, and the assessments. It was a collaborator in that part of the course.
Infrastructure: I built the entire course infrastructure through conversational programming.
Operations: AI was very much present in the classroom, handling structural work so the humans could connect. This was a course about AI for students, and a course about AI for me: what can we do as educators with this technology?
The entire course website, the infrastructure, the backend, all the services, were built through conversational programming. I did not write, read, or debug a single line of the code that powers the site: 199 sessions over 68 days, 4,038 turns, 29,770 tool calls. Having spent a decade building the infrastructure for my CS 1 course, I was shocked by how much I accomplished in one semester. The whole log is online, so you are welcome to watch me get frustrated, and proud.
We meet twice a week, in a series of activities: exploratory sessions where students learn about AI, discussions where they talk to each other about AI's impact on their lives and on society, and labs where they use AI to do things.
The exploratory sessions are often centered on an interactive artifact. For a session on convolutional networks, there is a little digit-recognition network students can train right in the browser, watching the loss and accuracy, then draw digits and watch classification in real time. Students play with it, come up with questions, use AI to explore answers for the rest of the hour, and share with each other. No lecturing, a very inductive approach. This too was built through conversational programming.
For the discussions, I noticed early on that some students did the assigned readings and others didn't, and that affected the quality of the dialogue in class. So I brought AI into this part of the course as well.
Before class, students complete what I call conversational preparation: they chat with an AI agent about the reading that helps them highlight the key themes, so that when they pair up, they are talking to someone prepared to think through the ideas.
During class, we experimented with agents that join a group's conversation, figure out what they have talked about, check that they have hit the key themes, and if not, send them back to keep talking. The goal is always to support human connection and conversation.
The most exciting piece of this course pedagogically, for me, is what I call conversational assessment: the chat-based equivalent of an oral examination. Students talk to AI agents instructed to determine what they understand about a topic. And you can ask open-ended questions. Explain the Turing test. Then: do today's models pass it? Depending on the position the student takes, the AI offers counterexamples and looks at their ability to defend the argument or acknowledge its limits.
It is a multi-agent architecture. One agent, the assessor, interviews the student. Another, the evaluator, watches the transcript, guides the conversation, checks that the objectives are being met, and performs the assessment.
We tested it with a harness of AI personas, AI talking to AI, to tune the problems and to deal with adversarial students: we don't want anyone to pass by extracting the answers from the model. The hardest one to defeat? The confident bullshitter.
What excites me most about this style of assessment is that it opens up the space of autograding, which has always been so effective in our computing courses. The usual loop for open-ended work: submit, wait two weeks, get feedback from a human.
Autograding tightens the loop, so students can respond to feedback as part of their working process. One slow loop becomes many fast ones.
We know the value of feedback declines over time. We don't know exactly how fast, but it declines. So it is exciting to think, across the entire university, about the feedback AI models can provide. We don't have to use it for final grading, but we can bring it into students' learning in pedagogically appropriate ways.
Institutional support: our computer-based testing facility at Illinois. It is tremendously valuable to my own classes, proctored assessment on a computer, and I think it is a tool we are going to want and need more and more in the era of AI. It holds the classical programming quizzes in CS 124, and the same facility holds a very different kind of assessment, the conversational one.
There was a lab where students used Replit to build websites, and they got really excited. Several kept going as their final project. One student, in a sorority, said: my sorority spends all this money on apps to organize information, what if I can build a replacement? Another, into aquascaping, which I had never heard of, built a site to design tanks and track livestock, plants, water chemistry, and maintenance.
So here is my hypothesis, the thread through all of this.
The prevailing view treats programming and AI collaboration as stacked: learn to code first, and then you can build with AI.
I am betting they are independent, but related. AI collaboration is a distinct skill that is independent from, but related to, classical programming. In CS 124 and in Using and Understanding AI, most of the value came from decomposing the problem, directing the AI, and judging its output, not from reading or writing source code. The honest caveat: every foundations-first result was measured on students taught code first. No one has run the other arm yet, and I want to. I argue this at length in an essay, Another Skill.
I was inspired by how interested these non-technical students were in web development once they had a platform that let them avoid the difficulty we have lived with for decades. So, in one of the most exciting educational projects I have been involved with, I am working with Cory Gwin at GitHub on a purely conversational programming course to pilot in the fall. No code to read, write, or debug, and the focus entirely on building solutions, using them, and evaluating them. If you can talk it, you can create it. And it is the seed of something bigger than a course.
Degrees
Building from that, what does a whole degree look like in this new era? Douglas Engelbart, 1962: by augmenting human intellect we mean increasing the capability of a person to approach a complex problem situation, to gain comprehension, and to derive solutions. This work is in collaboration with colleagues at Illinois and at GitHub.
At Illinois I have been organizing a series of discussions with colleagues about this: public sessions, AI-generated synthesis, and structured discussion. What can we do with AI in our classrooms? How should our entire programs change in response to this generational technology? The pitch that follows comes out of those conversations, not out of a single mind.
One idea that came up is that we have had two populations mixed into our computer science degrees for a long time. These are real quotes from participants. Students who are fascinated, who want to know everything about everything, the details, the innards, the theory. And students who are driven, who have a vision and care about how computers work in service of solving a problem in the world.
Computer science serves the first group: computing as ends. The second, computing as means, is who a degree in applied computing would serve. These are not categories; they are dimensions, and many students mix. But for students who want to build, given what AI can do with code, it is increasingly unclear that we should spend as much time teaching them to program.
So we started to draft a proposal for a degree we call Applied Computing. We can talk about the name. It is very early, a prototype, and the working draft is linked here; I would love feedback. The goal is a degree for students who want to apply computing to problems, inspired by architecture: explore, design, prototype, critique, iterate, validate.
We designed a new core, six courses across the first two years, based on conversational programming and the assumption that these students will work with coding agents as much as possible.
Conversational Programming: they start by designing and building software through conversation with AI, getting into much faster loops of designing and evaluating solutions.
Computing in Culture, because these students need to understand how the things they build will affect the world around them, because they will.
Agentic Software Development: constructing and evaluating agents and agentic workflows. Students learn to be effective directors of AI.
AI Models and Agents: how the models actually work, placed after fluency, so students step back to reason about systems they have already built with.
Integrative Design Studio I, the first integration with an outside domain: students bring in problems from another field and build computing artifacts in response.
How Software Works: the classical programming course, what happens beneath the conversational layer, and a bridge into upper-level CS electives. It comes last, not first. That ordering is the bet, made concrete.
Outside the core are three pillars. A domain concentration, through any existing minor, so students know something about the world besides computing. Formation, through writing, literature, moral reasoning, and studio art: computer scientists who are good humans. And a studio progression, increasingly sophisticated courses that bring that domain in, ending in a capstone with a public defense. Much of this is borrowed from architecture: build, get feedback, critique others' designs, again and again.
The formation part builds toward a famous quote from Stewart Brand in 1968: we are as gods, and might as well get good at it. That was in the early days of computing.
In 2009 he updated it: we are as gods, and have to get good at it. Today we are handing students tools more powerful than anything Brand had in mind, and we have a particular responsibility for what they build. We are as gods, and we have to get good at it.
Thank you. Hope, fear, and uncertainty; assessments; courses; and degrees. Thank you to Cory and Morgan for hosting, to Leo Porter for facilitating alongside me, and to all of you for being here. I am excited to keep building this with you, in today's workshop and on Day 2.