The New Computing: Education in the AI Era
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. By embracing AI, we can graduate students who are categorically different from their peers—with the judgment to identify problems worth solving, the skill to direct intelligence toward solutions, and the character to pursue societal good.
I am taking up this challenge in my own teaching. At the assignment level, I am redesigning CS1 to incorporate an independent project allowing students to learn and collaborate with AI. At the course level, I am developing two new classes for a general audience: using and understanding AI and conversational programming. At the program level, I am designing a new Applied Computing degree representing a holistic vision of the new computing—interdisciplinary, design-focused, AI-enabled.
SCI can prepare every graduate to play a leading role in determining how AI is built, used, and governed. Realizing this vision calls for team-building leadership that creates an environment where faculty explore together, support each other, and set the standard for other institutions.
SummarySummary
A vision talk delivered as part of the search for Chair of the School of Computing Instruction at Georgia Tech. The talk argues that AI’s emergence creates both an opportunity and a responsibility for computing educators—to redesign assessments, courses, and degrees so that graduates can shape the AI era. It walks through three concrete steps already underway: a Spring 2026 redesign of CS 124 around independent student-driven projects with time-on-AI grading; Using and Understanding AI, a new course for non-technical students built entirely through conversational programming; and a draft Applied Computing undergraduate degree inspired by architectural pedagogy. It closes on the role of educators—and on SCI specifically as the team uniquely positioned to lead through this moment.
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—each arrival came with its champions and its mourners. 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.
AssessmentsAssessments
I have taught introductory computing at the University of Illinois since 2017. The traditional model: 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 have 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, and students reported they didn’t learn much. 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 with Claude about feasibility; the second half is structured building sessions. Different students choose different scopes—about half finish their MVP and then go on to a series of additional tasks they pick with their project mentor.
Because no two projects are the same, we grade for effort, not progress. We instrument students’ Claude sessions, use AI itself to distinguish substantive engagement from off-task chatter, and target an average of four hours per week over six weeks. That collapses an effort distribution that used to vary wildly—one student stuck on a nasty bug, another getting a lot of help—into something fair. Everyone starts in a different place; everyone makes roughly the same amount of progress through a much bigger idea space.
This coexists with rigorous assessment of classical programming. CS 124 still has 15 hours of proctored assessment per semester in our computer-based testing facility, a large bank of problems, debugging exercises, solution-based autograding, and frequent small assessment with rolling retakes. The pre-AI pedagogy that worked still works. What we don’t yet know is what the right balance between classical fundamentals and agentic development should be—or what specifically makes someone a good AI collaborator. That, I think, is the most important open question in the computing education field right now.
Courses: Using and Understanding AICourses: Using and Understanding AI
This semester I launched a new course on exploring generative AI for non-technical students, designed to work as a general-education entry point into AI literacy. The pilot is small and intentional. 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. After a decade hand-building CS 124’s infrastructure, the contrast was striking. The full transcript of how the course site was built is online if you want to watch me get frustrated and proud in turns.
We meet twice a week. Inductive sessions use interactive artifacts—a digit-recognition CNN students can train in the browser before we ever name the mechanism. Discussion sections use AI-supported conversational preparation: students arrive having already worked through the readings in conversation with an agent, so the human-to-human conversation in the room starts on common ground. Labs use AI to build things.
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, and the two coordinate. We validated it against adversarial personas. The hardest to defeat was the confident bullshitter.
Conversational assessment matters because the value of feedback falls off with delay. Tight feedback loops keep students inside the window where feedback still changes behavior. AI lets us autograde the open-ended work that used to demand slow human evaluation—and we can place that assessment inside the CBTF, proctored, on a computer, with AI integrated rather than excluded.
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, focused on building, evaluating, and iterating on what they make.
Degrees: Applied ComputingDegrees: Applied Computing
Through a series of 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. It’s early; the working document is online and feedback is genuinely welcome.
The core leans on conversational programming first, classical programming later. Six courses across the first two years: Conversational Programming and Computing in Culture (Y1 Fall), Agentic Software Development (Y1 Spring), AI Models and Agents and Integrative Design Studio I (Y2 Fall), How Software Works (Y2 Spring). The order is deliberate—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, 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. Entrepreneurship has the same shape: iterative work, public defense, real users.
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.” Twenty-six years later, we are handing students tools more powerful than anything Brand had in mind. The verb shifts again. We have a particular responsibility for what they build.
EducatorsEducators
For a decade, computing education has been in one-to-n mode—scaling what we already know how to teach. AI puts us back into zero-to-one mode. We have to figure things out: through experimentation, through collaboration with computing-education researchers, and most of all by learning from each other.
Students need us. The sentiment analysis I ran on r/gatech for this talk showed students worrying about the job market, about AI, about honor-code anxiety. They are looking for our voice—and our voice is conspicuously absent. They want to see us understanding what they are going through, learning these tools ourselves, and updating our curricula for the present they are already in.
There is a divergence to navigate too. For curious students, AI is fantastic—a 24/7 tutor willing to talk about Aristotle’s notion of friendship at 6:30 in the morning or race conditions over lunch. For students with intrinsic motivation, AI is a multiplier. For students without it, AI just does the homework. We spend a lot of time asking what students are doing with AI. We should spend more time asking what AI can do with students—how it can build fires of curiosity that the rest of the education then has something to work with.
The team I want to be part of has shared goals, communication and visibility, and community and connection. Shared goals because this is not a zero-sum game—your course getting better and mine getting better are the same outcome for the students who take both. Visibility because we will not navigate this moment without seeing what each other is doing, sharing material, talking constantly. Community because COVID pushed us apart and AI risks pushing us further apart still—online conversations can now be entirely synthetic. If we want human connection, we have to do it face to face, in spaces students want to be.
SCI is a unique structure: a school of computing educators, a team already assembled, in a position to lead. I am here because I want to join your team.
Slides
The New Computing
Thank you, Professor Varma, for that warm introduction. 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. This talk is about where computing education has to go in the AI era: assessments, courses, degrees, and the educators who will get us there.
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. 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 something AI does not let you skip.
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.
I can't give a talk about education without mentioning our computer-based testing facility. It is tremendously valuable to my own class, and I think it is a tool we are going to want and need more and more, not just for our own courses, in the era of AI.
But there is an open question here, and SCI is in a great position to lead on it: I don't know what CS 1 is supposed to look like in the future. We have a mix right now of classical programming and agentic development, and I don't know the right mix. Nor do I know what students need to know to be effective AI collaborators. What makes people good at this? I think that is the most important open question in computing education right now.
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 semester 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.
At the end of the course, students took one of these conversational assessments in our computer-based testing facility. Another shout out to the CBTF, which I think is going to be incredibly important in the era of AI, letting us do proctored assessment on a computer that brings AI into the room.
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.
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.
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. 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.
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. Later in the program we do teach them to write code by hand, and this course is also a bridge into upper-level CS electives.
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. I wonder what the version of that quote is for today, because we are handing students tremendously powerful tools. More than ever, we have a role to play in helping them do good things with them.
Educators
In the last section, I want to talk about our role as educators, and about the team I want to be part of and help foster. Plutarch: the mind is not a vessel to be filled, but a fire to be kindled. We have been in one-to-n mode, scaling up our ability to teach computing. AI puts us back into zero-to-one mode. We have a lot of exploration to do, and a lot of learning from each other.
Our students need us in this moment. I ran a sentiment analysis on the r/gatech subreddit. Students are worried about honor codes, about the job market, about assessment: we are living in an age where you can vibecode startups but they want us to write code using pencil and paper. They are looking to us to understand what they are going through, to learn these tools ourselves, and to update our programs for the present, much less the future.
Educators also have a huge role to play in the divergence these tools create.
My vision is a world where these tools support human curiosity, and they are fantastic at it. For a small monthly fee you have the world's most capable tutor at your beck and call. You want to talk about Aristotle's notion of friendship at six thirty in the morning, or race conditions over lunch? Go for it. For students with intrinsic motivation, these tools are amazing multipliers.
For students without it, they do the homework. We think a lot about what students are doing with AI, and maybe less about what AI is doing for students. We should think more about what AI can do with students, and make sure we build fires of curiosity and creativity.
I think we will do this as a team. I have started to play a lot of Frisbee, so here are some Frisbee images.
A shared goal. We have the students and the curriculum, something we do together that we care about. This is not a zero-sum game: my course getting better and your course getting better can happen together.
Communication and visibility. A team can see what everyone is doing on the field and respond. We need to know what people are doing in their courses, share it, and talk constantly, so we can learn from each other and address challenges as they arise.
Community and connection. COVID pushed us apart, and in a world where AI can pass as a human, are you sure who you are talking to online? If we want human connection, we need to do it face to face, in spaces where faculty, staff, and students want to be. I think students are hungry for it.
So I am here because there is a team here. SCI is a unique organization that has assembled a team of computing educators and put them in a position to work as one. I am here because I want to join your team.
Thank you for listening. Hope, fear, and uncertainty; assessments; courses; degrees; and educators. Thank you to Cynthia Bryant and Sharon Hamilton for arranging my visit. I am excited to talk with all of you, right now and throughout the day.
Frequent small assessment in CS 124: about fifteen short proctored assessments across the semester, with retakes and dropped low scores. That is universal design, not accommodation, and performance gaps across gender and prior experience shrink significantly under this model.
The opposite shape is the midterm and the final. Big stakes, big anxiety, slow feedback, and a large share of the grade riding on a couple of days. It is the wrong shape for learning.
Another interactive artifact from Using and Understanding AI: a neuron explorer, zooming in on what a single artificial neuron does with different inputs. Same idea as the digit network: see the thing work before we explain it.