I've organized and judged over a dozen hackathons in the last 15 years, though it had been a couple years since my last one. That changed last month, when I was asked to judge two: one at Semgrep and one at DataGrail.
While I was expecting them to be better with AI coding tools, I wasn't expecting them to be as good as they were.
Before AI, the typical hackathon experience had a predictable shape. There were a few standout teams that had both a great idea and managed to get something impressive working in time. A few others had great, ambitious ideas, but ran out of time. There would also be a handful of decks with wireframes and no real code, and at least one demo that crashed mid-presentation, which got props for having live code. Judges learned to give credit for ambition and grade on a generous curve.
The hackathons last month felt completely different. Every project was a hit. One after another, teams delivered marvelous, working demos.
There were no PowerPoint slides, no wireframes, and no big demo crashes. Every team shipped something with working code, polished UI, and real data. And the presenters had strong confidence in their projects.
Instead of asking, “Which demos worked?” we were left asking, “How do we pick a winner when every project is this strong?” This presented a new and fun challenge for judges.
Two hackathons, similar stories
The DataGrail hackathon included non-engineers. Employees from across the company, without technical backgrounds, worked to automate better solutions to problems they see every day. Every single group had a working demo that solved a real pain point for the company and a tool they could actually use after the hackathon to make their job easier.
At my new company, Semgrep, where I recently joined the team as co-CTO and VP of Engineering, our recent hackathon was across the Engineering, Product, and Design org. The projects weren't experiments or toys. They were features with immediate impact on customers and the company. Some of the demos were completely new ideas, and others were working solutions to product ideas that had been discussed for months but had never been prioritized. I was sitting next to Daghan, the Semgrep VP of Product, who kept a constant refrain throughout the demos: “Ship it!”
Ship it used to come with an asterisk
The biggest compliment at a hackathon is when a tech leader says, "Ship it."
For most of the past decade, that phrase came with an asterisk. Judges said it, knowing the demo had been held together with shortcuts, mocked interfaces, and hardcoded data. Shipping it for real meant someone would have to go back and rebuild the foundation properly with real error handling, real data pipelines, and real security. The idea might have been worth shipping. The code was almost never.
That’s changing. AI tools aren’t just speeding teams up. What comes out of a 24-hour hackathon now actually feels like a real prototype, not just a demo. When someone says, “Ship it,” they might actually mean it.
What separates good from great
Here's the thing I kept noticing across both hackathons: the best projects weren't the ones that built the most. They were the ones that built the right thing.
The teams that stood out had a clear point of view on the problem they were solving. They could tell you in one sentence what the problem is, why existing solutions fall short, and what their solution solves. That clarity showed up in the scope they chose, the features they cut, and the way they demoed. The differentiator was product-centric thinking, not just technical execution.
AI has made it so much easier to build things. Now the real challenge isn’t whether you can code something, but whether you know what’s worth building. The people who stand out aren’t just fast; they have strong opinions and real product sense.
The case for running more hackathons
Both experiences left me thinking the same thing: we should be doing this more.
The focused energy of a hackathon with small teams, clear time boxes, no meetings, and real stakes produces a different quality of thinking than a normal sprint. When the output is increasingly shippable, it’s not just a fun side event. It's a legitimate way to move a roadmap forward and shape the product strategy with speed.
The companies that figure out how to channel hackathon energy into their regular development cycle will have an advantage. I'm convinced of it now more than ever.
Come build with us
We’re building something worth shipping at Semgrep, and we’re looking for people who think the same way. Sound like fun? Check out our open roles: https://semgrep.dev/about/careers.
.jpg)
