Judging at CalHacks Taught Me About the Next Gen of AI Builders

Every October, several thousand students crowd into UC Berkeley's campus for CalHacks, one of the largest collegiate hackathons in the world. They have 36 hours to build something from nothing. No roadmap. No manager. No backlog. Just a laptop, a team, and a deadline.

I've been a lead mentor there since 2018. I've watched hundreds of teams go from idea to demo. I've seen projects that blew my mind and projects that crashed during the presentation. I've watched 19-year-olds build in a weekend what some startups take months to ship.

And I keep going back, not because I enjoy the sleep deprivation, but because CalHacks is the best window into what technology will look like in five years.

The Shift I've Watched

When I started mentoring in 2018, the hackathon projects were mostly web apps. Chat applications. Social networks. Marketplace prototypes. The tools were React, Node.js, Firebase. The ambition was "build a working app."

By 2023, the projects had shifted. AI was everywhere, but it was mostly wrappers. Take an API from OpenAI, add a front end, call it a product. The demo would be impressive for about thirty seconds, until you realized it was a thin layer over a model someone else built. The ambition had grown, but the depth hadn't matched.

Something changed after that. The teams that win now aren't the ones with the fanciest AI integration. They're the ones that solve a real problem and use AI as the tool, not the product.

I watched a team build a system that translates American Sign Language in real time using computer vision, not as a tech demo, but because one of the team members has a deaf sibling and wanted to solve a real communication problem.

Another team built an agricultural monitoring tool that uses satellite imagery to detect crop disease. Not because AI image classification is cool, but because one team member's family runs a farm and loses crops every season to diseases that could be caught earlier.

The pattern is clear: the best hackathon projects start with a problem, not a technology. The next generation of builders understands this intuitively.

What 36 Hours Reveals

A hackathon compresses years of startup lessons into a weekend. Every team goes through the same arc:

Hours 0-4: Scope expansion. The idea starts reasonable and grows wild. "Let's build a study tool" becomes "Let's build an AI tutor that adapts to every learning style, supports 50 languages, and generates 3D visualizations." Ambition outpaces ability by a factor of ten.

Hours 4-12: Reality check. The first API call fails. The database schema doesn't work. The frontend breaks on mobile. The AI model hallucinates nonsense. The team realizes they can't build everything they planned and starts cutting scope.

Hours 12-24: Focused building. The surviving features get real attention. Code quality goes down but shipping speed goes up. The team finds their rhythm. The project starts to take shape.

Hours 24-36: Panic, polish, demo prep. Someone discovers a critical bug at hour 30. The demo script gets written at hour 34. The slide deck gets made at hour 35. The team practices the pitch once, maybe twice, and walks into judging on caffeine and adrenaline.

This arc mirrors startup building at 10x speed. The same lessons (scope ruthlessly, ship the core feature first, don't polish what doesn't work yet, practice the pitch) apply whether you have 36 hours or 36 months.

The Mentoring Moments

The most impactful conversations happen between 2 AM and 5 AM.

That's when the tourist teams have left. The teams that remain are the ones who care enough to push through exhaustion. And at 3 AM, with the project half-broken and the deadline twelve hours away, people drop their guard and ask the real questions.

"We've been building for sixteen hours and nothing works. Should we pivot?"

"Our AI model gives wrong answers 30% of the time. Is that good enough to demo?"

"Two people on our team want to go in different directions. How do we decide?"

"I have an idea for a startup based on this project. Is it real?"

These aren't technical questions. They're judgment questions. And they're the same questions that founders face every day, just compressed into a weekend where the emotional intensity is amplified by sleep deprivation.

My job as a mentor isn't to give answers. It's to help teams think through tradeoffs. Yes, 30% error rate is too high for production, but this is a hackathon demo, and showing the concept matters more than showing perfection. Yes, pivoting at hour sixteen is scary, but continuing to build something that doesn't work is scarier. Yes, the team disagrees. Pick the version that's most demoable and argue about the vision later.

These are the same tradeoffs I make in my own products. Ship the imperfect version. Cut scope to hit the deadline. Disagree and commit.

What the Best Teams Do Differently

After seven years of mentoring, I can usually predict the winning teams by hour six. Here's what they do:

They start with the demo. The best teams write their demo script before they write their first line of code. Not because the demo is more important than the product, but because the demo forces clarity. If you can't explain your project in sixty seconds, you don't understand it well enough to build it.

They split by skill, not by feature. Weak teams assign each person a feature. Strong teams assign each person a layer: one person handles the backend, one handles the frontend, one handles the AI integration, one handles the design and pitch. This avoids merge conflicts, communication overhead, and the "nobody built the thing that connects everything" problem.

They ship ugly. The best teams have the least polished codebases. They use hardcoded values. They skip error handling. They deploy on localhost and use ngrok for the demo. They optimize for one thing: does the core feature work? Everything else is noise.

They tell a story. The winning demo isn't the one with the best technology. It's the one with the best story. "My grandmother can't read her medication labels" is a better opening than "We built a multi-modal LLM integration with OCR capabilities." Same product. Different pitch. One wins.

What This Means for the Industry

I believe hackathons are the best leading indicator for technology trends.

The students building at CalHacks today are the startup founders of 2028. The problems they choose to solve (accessibility, healthcare, education, climate, agriculture) signal what the next wave of companies will look like.

And the approach is shifting. The 2019 generation built features. The 2023 generation integrated APIs. The 2026 generation builds systems. They use AI as one component in a larger solution, not as the solution itself. They think about data pipelines, user workflows, and real-world constraints. They're more practical and less hype-driven than the generation that came before.

This gives me tremendous optimism. Not because AI is getting better (though it is) but because the people building with AI are getting wiser about how to use it.

Why I Keep Going Back

I've won 10+ hackathons myself. I've been on both sides, competitor and mentor. The competitor experience taught me how to build fast. The mentor experience taught me something more valuable: how to think about what's worth building.

Every CalHacks, I meet a team that reminds me of myself at 22, full of energy, slightly delusional about scope, and convinced they can change something with a weekend project. Most of the time, the weekend project dies on Monday morning. But sometimes (rarely, but sometimes) it doesn't.

Some of the companies I've mentored at CalHacks are real companies now. Real users. Real revenue. Real impact. That's more satisfying than any exit or metric could ever be.

I keep going back because CalHacks is the place where the next generation of builders shows you what they care about. And right now, they care about solving real problems. That's the best signal I know.