Computing Beyond Code · Computing Beyond Code

1ComputingBeyond 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.

2The other fork

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.

3intro-cory

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.

4intro-kevin

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.

5intro-geoffrey

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.

6We're setting the tools aside

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.

7Goals

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?

8Concepts

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?

9Structure

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?

10What do we even call it?

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.

11Where we're headed

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.