Computing Beyond Code
Watch the Talk
AbstractAbstract
Most conversations about GenAI in the intro course still assume students write code. This session takes the other fork: a pure elective for non-technical students in which programming happens entirely through conversation with an AI agent, with no syntax, no error messages, and no stack traces. Co-led with Kevin Lin and Cory Gwin, it is deliberately a discussion rather than a pitch, since none of us has taught the course yet. We set the tools aside and work through the three things that do not change: what the course is for (goals), what students must understand (concepts), and how to give it shape so learning is felt (structure).
SummarySummary
The closing hour of the consortium’s summer workshop, following an introduction to an AI-integrated CS1 that keeps students writing code. Where that hour keeps code at the center, this one removes it entirely and asks what is left to teach when the machine can build the thing: the durable judgment that survives the tool, which is specifying, decomposing, and telling good work from bad. The hour runs as one open, facilitated conversation with the whole room, moving through three blocks, goals, concepts, and structure, with a candidate throughline that the real skill is an accurate mental model of the agent, and a nod to the architecture studio as a model for critique and felt progress. It closes, for fun, with a vote on what to even call the thing.
The Slides
ComputingBeyond Code
Welcome to Computing Beyond Code: teaching programming as conversation. This is the second hour of the GenAI in CS Education Consortium's summer workshop, and I am leading it with Kevin Lin from the University of Washington and Cory Gwin from GitHub. This hour is a conversation, and everyone is invited into it.
Leo and Dan just showed an AI-integrated CS1 where students still write code. That is one fork in the road for the intro course.
We want to talk about the other fork: a pure elective for non-technical students where, as much as we can manage, they never see code at all. No syntax, no error messages, no stack traces. The programming happens entirely through conversation with an agent.
Nobody has taught this yet, us included. That is the invitation, not a weakness. So this is a conversation, not a pitch, and we want people to jump in any time, by unmuting or in the chat.
Cory Gwin from GitHub opens with The Split, his post about a course of its own: one for non-computing students, free of integration with the CS degree. The long-term view, which Cory and I developed together, is a complete resequencing. Software architecture, complex systems, QA and how the pieces fit together come early; complex algorithms, data structures and deep software-engineering rigor come later.
Kevin Lin from UW describes Steve Seitz's course, a near-term response: a low or no-code applied course at UW this autumn, for students who already have some programming, and a showcase of today's tools. The curriculum itself is vibe-coded, regenerated to track the latest tools. That is the short-term horizon. The long term is a rethink from scratch, and that is where the rest of this session leans.
My angle is conversational programming: a pilot this fall at Illinois, an elective where students never see code. The questions I care about are which concepts survive, how to teach them without writing any, how to leave a door open for the curious to go further, and how to give the course structure. My students in Using and Understanding AI last spring have a showcase of what they built.
Cory puts it this way: you don't teach a carpenter the saw. You teach them to build, and the saw is just part of the shop. Tools change every semester, so we are setting them aside on purpose and not debating platforms today. We want the three things that don't change.
The first is goals: what a course like this is for.
The second is concepts: what students must understand.
The third is structure: how you build the course so that the learning is felt. Those are the three discussions to come, each with one of us driving.
The first discussion, which Cory drives: what is a course like this for? What should a non-technical student walk away able to do or think? We want to push past content coverage to durable capability. Computational literacy, creative confidence, judgment, getting real things done? We don't agree on the primary one, and that disagreement is worth surfacing. One way in: what would count, for you, as a student having learned something?
The second discussion is mine. With no code on screen, what must students actually understand, and what do abstraction and decomposition even mean here? My candidate answer is that the durable skill is a good mental model of the agent: predict what it will do, catch it when it's wrong, specify so it does what you meant. Classically, the notional machine is the computer executing your code. These students never see that machine, but they steer the agent, so the agent becomes the machine they need to model. The provocation: can you understand abstraction or state if you never operationalize them, or do you just get vocabulary? Is that enough?
The third discussion, which Kevin drives, is the felt-learning problem. Chatting and building works, but it doesn't feel like the ladder of a normal intro course. One project or many? What cadence? Could an architecture studio, with its desk crits, pin-ups and reviews, carry the structure? And how would you even grade it: subjective studio critique, or step-wise process rubrics that reward a clever decomposition? The question underneath: what would make you actually pilot one of these next year?
For fun: nobody agrees what to call these courses, CS0 and CS1 fit awkwardly, so we vote in the chat by typing a code. Conversational programming, vibe coding, coding agents, AI1 for reasons you know, computational thinking, computational creation, agentic development, natural-language programming, software studio, or CB1, computing beyond code, which is a wink at this session's title. Write-ins are welcome.
Here is where we are headed. Where we agree: the durable skill beats the tools, and building is the point.
Where we don't yet agree: what the goals are, how to make the learning felt, and how to grade it. That is the fun part, and it is why we wanted to think it through with this group.
I am piloting a version this fall, and we have heard of a few other pilots starting up. Let's keep in touch and compare notes.