Epistemic Programming and the Working Group Experience at ITiCSE 2026
This past July I traveled to Madrid for ITiCSE 2026, the ACM conference on Innovation and Technology in Computer Science Education, where I took part in Working Group 7: Bringing Inquiry-driven Programming into Practice: Towards a Research Agenda for Epistemic Programming. It was one of the most rewarding professional experiences I’ve had in a while, both for the ideas we developed and for the unusual way the work came together.
What a working group actually is
If you’ve attended an academic conferences, you know the usual rhythm: you present a paper as a talk or maybe a poster, sit in on sessions, and catch up with colleagues between talks. An ITiCSE working group is a different experience and not one I’ve participated in before. It’s a months-long research collaboration that happens to culminate at the conference rather than being contained by it.
Our group of roughly a dozen faculty and graduate students — spread across the United States and Europe — began working together back in March, meeting virtually and working asynchronously to lay the groundwork: scoping the project, agreeing on methods, and starting to gather and organize our data. Then came the intense part. In the three days immediately preceding the conference, the whole team gathered in person and worked for long hours each day to finish our analysis and draft the first full version of our report. After Madrid, we returned to our home institutions and continued (mostly asynchronously) to complete the draft, which we submitted for review on September 13. We expect to hear back about the outcome in November.
There’s something special about that structure. The pre-conference sprint, in particular, creates a kind of focused, shoulder-to-shoulder collaboration that’s rare in academic life — a room full of people from different countries and career stages, all pulling in the same direction toward a shared deliverable. It’s demanding, but it builds the kind of momentum and camaraderie that’s hard to manufacture any other way.
Epistemic Programming: process over product
The idea at the center of our working group is Epistemic Programming (EP) — the use of programming as a means of inquiry and knowledge construction rather than as a vehicle for building software. In an epistemic frame, a learner and a computer engage in a kind of conversation: you write a little code to ask a question of your data or a model, look at what comes back, refine your question, and iterate your way toward understanding. The goal isn’t a finished, working program; it’s the insight the process produces along the way.
Our report approached this from several complementary angles — a Delphi-inspired process to surface how researchers themselves understand EP, a literature review, interviews with educators, and an analysis of student artifacts. I was part of the Artifact Review subgroup, where I helped code a quarter of the artifacts we examined and worked heavily on the summative synthesis of our findings. That work culminated in a chord diagram visualization that captures how different epistemic actions connect and flow within students’ computational work — one of the pieces of the project I’m most proud of.
What excites me most is how closely EP aligns with how we already teach in CMSE. Our courses treat programming as a tool for asking and answering questions with data and models — exactly the knowledge-construction stance EP describes. Seeing our everyday practice reflected in an emerging international research framework was genuinely energizing.
Additionally, that resonance is more than just validating; it’s practically useful. As Director of Undergraduate Studies in CMSE, one of my responsibilities is helping to shape the undergraduate Data Science program, and EP gives me a principled vocabulary for the design work ahead. A data science curriculum is, in many ways, an epistemic-programming curriculum by nature: students write code not to ship software but to wrangle, model, and interrogate data in pursuit of answers. The EP framework helps make that implicit stance explicit, offering a way to articulate what we actually want students to be able to do — pose a question, translate it into computation, evaluate what comes back, and revise — and to sequence those capacities deliberately across a program rather than leaving them to emerge by chance.
Future-proofing computing education in the AI era
There’s a further reason I think this framing matters right now. As generative AI reshapes what it means to “write code,” a lot of computing education built around producing correct programs suddenly feels precarious. If the product is the point, and a model can generate the product, what’s left to teach?
Epistemic programming offers an answer by shifting the emphasis from product to process. If we teach students to use computational tools to construct knowledge — and, crucially, to interrogate the outputs of their tools and question whether results are accurate and reliable — then the durable skill isn’t the syntax; it’s the disciplined habit of inquiry. Students who can build understanding computationally and critically evaluate what their tools hand back should retain that capacity even as the mechanics of writing code continue to evolve alongside AI. In that sense, an epistemic approach isn’t just aligned with good teaching today; it’s a way to future-proof computing education for whatever comes next.
I’ll share more once we hear back on the review this fall. In the meantime, I’m grateful to my WG7 collaborators for a memorable few days in Madrid and a project I’m excited to keep building on.