A Little Productive Chaos: What Hackathons Can Teach Us About Learning AI

There is a moment in almost every hackathon when things feel a little chaotic. As long as that moment doesn’t last too long, it probably means you’re doing something right.

Here’s what it looks like when I’m running a virtual hackathon: People who may not have known one another an hour earlier are trying to agree on a problem worth solving. One person is experimenting with a tool they’ve never used before; someone else is questioning whether they’ve defined the problem correctly. Meanwhile, the entire team is trying to create something they can put in front of others and learn from.

From a traditional instructional design perspective, the process can look pretty messy. And that may be part of why a hackathon works.

This October, as part of ATD Intensive: AI, we’re bringing back an optional hackathon that will run alongside three virtual learning days. Participants will form teams, tackle a challenge, explore AI tools, create prototypes, get feedback, and keep working on their ideas. We’re not expecting polished products at the end. We’re creating a place to learn by making something.

When we introduced the hackathon during last year’s AI Intensive, I wasn’t entirely sure what would happen. I’ve run a few project-based learning and hackathon-like experiences, but I really hadn’t tackled something this big.

Nearly a dozen teams formed. They identified problems, selected user groups, explored tools, developed ideas, built prototypes, and iterated solutions. What they created ranged from proof-of-concept to useful to hilariously over-the-top.

And then something amazing happened. In the weeks and even months following ATD Intensive, people told me how much they had learned from the hackathon. They hadn’t just learned about AI; they had actually used AI while solving an ambiguous problem with other people. They made decisions about tools, ran into limitations, changed direction, and worked through different ideas about what they were trying to build.

TD professionals can demonstrate AI tools and teach prompting techniques. We can provide frameworks and examples. But at some point, people need a chance to mess around with the tech, see what other people do, ask some naïve questions, and figure out what works.

The challenge in designing a hackathon is figuring out how much structure to provide.

With too little, teams can burn valuable time trying to figure out what they’re supposed to be doing. With too much structure, you’ve designed all the discovery out of the experience.

I’m aiming for just enough structure to get people moving. I’m presenting the challenge, setting some boundaries, and providing a destination (the demo showcase at the end). I’m not giving teams a recipe for what happens in between.

Each team also gets access to a prefab workspace on a shared Miro board, which is an interactive digital whiteboard. Some early activities will help people share their own knowledge and experience onto the board, figure out whose problem they want to solve, and develop a shared idea of what they might create.

The prefab activities aren’t intended to walk them through a perfect design process. They’re to keep a newly formed team from spending the first hour staring at one another wondering where to start.

After that, we give them room to work.

The collaboration itself turned out to be another part of the learning. People join a group of people they usually don’t know in advance. Pretty quickly, they have to figure out what they want to work on, how they’ll work together, who wants to do what, and how they’ll keep things moving between the live sessions.

One team approached this last year in a way I especially loved. Hackathons tend to conjure up images of intense, energetic groups working together in real time. This team decided they didn’t want that. They deliberately took an almost anti-chaotic approach.

People came into the Miro board asynchronously, often when it was quiet. They contributed at different times and in different ways and figured out how to make that work for the group. They didn’t assume collaboration required everyone to be in the same place at the same time, working in the same way. I certainly hadn’t designed that process for them. They figured it out for themselves, and that became part of what they learned.

At the end of the hackathon, we hold a demo showcase. Sometimes that’s daunting for an all-volunteer, mixed-skillset project.

I always love what comes out of the showcases. I expect some clever ideas. Some things probably won’t work. And based on last year, I’m hoping at least a few will be ridiculously funny. I do not expect polished, production-ready AI applications. That’s not the point.

What I hope participants leave with is more experience making choices about AI rather than simply hearing about those choices. They’ll have tried tools, built something, seen what happened when other people got involved, changed their minds a few times, and learned something about how they work with other people when nobody quite knows the answer yet.

Even better: everyone will have had the experience of forming a team and figuring it out together. AI is changing too quickly for us to wait until we have everything figured out before we help people learn to work with it. We need places where it’s OK to try something, find out it doesn’t quite work, adjust, and try again, even if sometimes that gets a little chaotic.

I think I’m OK with that.