Like everything else in engineering, AI has changed the hackathon. Gone are the days when you had to demo some kludgy, half-assed thing that ran on a mocked-up UI, static data, and prayers.
Now, no matter how much garbage you pour in, your agents make sure your demo looks great. Just kidding; your demo will likely work great too.
Hackathon projects can be almost production-ready by demo day. But how do you manage the pace of AI development further compressed into only a few days? How can ad hoc teams work together while making the most of their agents?
If it’s been a while since your last hackathon and you’re wondering how to keep your team on track, or if you’ve never done a hackathon before, these tips from real engineers are for you.
1. Choose the direction of your ambition
A “Be More Ambitious” mantra is making the rounds for hackathons and for working with AI in general. But even with agent superpowers, deadlines and the need for teamwork mean you have to make tradeoffs. That’s one aspect of engineering that hasn’t changed yet.
If you have 48 hours and a team spread across time zones that doesn’t usually work together, then you need to choose what to aim for.
One of our engineers called a hackathon “an exercise in constrained optimization.” You only have so much time, and you can either:
demo something that covers a lot of ground, explores what’s possible, and is “good enough for now”
demo a narrowly scoped, fully formed feature that’s integrated with existing products and essentially ready to ship
As the following graph shows, from point A (before AI), you can go either up to B or over to C (with AI). B is the same feature set at higher quality; C is more features at the same quality.
Of course, there’s a whole “have your cake and eat it too” area of the graph between B and C to explore (see D).
How you balance focus and breadth also depends on your company’s products and stage of growth. Companies with a really solid foundation and the primitives to build on it are far more likely to reach or surpass the “cake zone” with less effort.
Look at what your team can reuse before you limit an idea. Existing components can make a big experiment practical.
Make the decision early: agree on whether you want to explore more possibilities or aim for something smaller and shippable. And make sure to give your agents the same goal.
2. Work backwards from the demo and prototype often
Think about how you want to communicate the value of your project before you start building it. What does someone do? What happens? Why is that useful or interesting?
One engineer calls this “retro-synthesis”: imagine the demo, then break it into pieces the team can work on. You’re forced to consider scope, responsibilities, and how to communicate the idea.
Build a small working version of the demo early: a kind of “walking skeleton,” something that connects the essential parts that you can iterate on.
At the same time, you don’t always need the full demo to share an idea with your team. Now that prototyping ideas with agents is virtually free, you have a tangible way to start a conversation. Use small prototypes to explore and learn. If you disagree about how a feature should behave, demonstrate one use case and then talk about it.
The benefit of the early demo and small prototypes is that your team always has something concrete to respond to. And when you keep your prototypes small enough to change or discard, you don’t lose momentum.
3. Adopt a continuous sharing mindset
Be deliberate about sharing intent, findings, and direction, especially on a distributed team. If you’re working while your teammate sleeps, you need to communicate to hand off the work. Leaving them to catch up on 20 agent sessions across 3 accounts with 6 separate branches in 3 repos and about a hundred individual commits is… not cool.
Some teams in this situation found that real human communication, by message or in a call, was the key to moving together onto the next thing and solving issues efficiently. Every direction they explored independently was understood by the whole group.
One team gave every member the authority to make a pivoting decision. That’s how they had to work to get the project done. But imagine the chaos of a no-hierarchy team, with everyone declaring a pivot on every finding, if they weren’t all continuously sharing intent. The convergence of understanding allows a team to succeed working across time zones.
In one case, a team abandoned an approach after finding a fundamental flaw, setting aside several hours of work. Another teammate was offline. The handoff needed to explain what they had discovered, why the direction changed, and the effect on the work.
Here’s a practical template for communicating a change in direction:
The discovery: What do you know now that you didn’t know before?
The decision: What changes because of that discovery?
The next work: What should people and agents continue, start, or stop?
The team also shared agent sessions through tools such as Amp, so someone could pick up an existing session when a colleague logged off.
4. Try “pairalleling” with agents
If you’re working in person, or your remote team’s time zones overlap, try what one team called “pairalleling”: working on separate tasks with your agents while staying on a call together.
First, they discussed what they wanted to build, broke it into tasks, and used Linear to track progress when they were async.
Then they started building. During their live calls, they asked questions as the work evolved. Does this fit with your part? Does this direction make sense? I’ve run into something that might affect you.
They also chatted while the agents worked. The shared time made the work less isolated.
The team noted that they avoided oversharing every detail of what they were doing. They stuck with communicating important updates or milestones.
Agree on who owns each part and what the parts need from each other. Keep a shared record for people working asynchronously, and use your overlap hours to ask questions and collaborate.
Bonus: Learn how other engineers work
We’ve all heard hackathon organizers say, “Work with people you don’t usually work with.”
One bonus of working with new people, now that everything in engineering is changing completely every four months, is that you get to observe their workflows up close. You get a complete look at how someone works, from start to finish, for a single project. You can learn from how they approach the work and how they manage their agents. Sometimes you get to learn about tools you didn’t know existed.
Another thing organizers like to say is “just have fun!” Let’s be honest. Ending a hackathon with a successful demo that impresses everyone is pretty fun. If these tips help you succeed in your next AI-fueled hackathon, or you have your own tips to share, we’d love to hear about it.