Nico Pujia

Last weekend I participated in Berkeley AI Hackathon, and now I realize several things I did wrong. Below is my reflection so you (and my future self) don't repeat these mistakes.

As context, I built CeliacBot, an AI agent that investigates restaurants to know whether they are celiac-safe, so I don't have to. The main idea is that if online information isn't enough, it calls the restaurants, just as I'd do.

Now the mistakes:

1. Use as many sponsors as possible.¶

Although my idea made sense to fit with the sponsors I chose (they were for web browsing, LLM inference, voice AI agents, data storing, public agent listing, workflows, and app and agents observability), I should have ruthlessly prioritized 1 or 2, at most 3.

While relatively easy, setting up all external services consumes time. But that is not the main issue; the main issue with using so many sponsors is the complexity of managing so many external services. Complexity kills you.

In a hackathon, you count time in hours, not days. Every step you take should keep the software working and for that you need to reduce the chances of failure. More components in the system only increase those chances.

Besides, as the saying says, don't bite off more than you can chew. The "best sponsor" prize is for those projects which take the most out of it, not for the best projects using it. If you just use the most basic feature, let alone if your implementation is broken, all your time trying to integrate that sponsor for the sake of being in the track has been wasted time and energy. This sounds obvious, but is the kind of decisions you make if you also make the following mistake.

2. Don't sleep at all.¶

At least, I didn't fully made this mistake, as I slept a block of 90 minutes and then another one of 60. Nevertheless, now that I look back about the moments I was sleepy, I realize I was plainly useless.

Two blocks of 5 focused and energized hours beat 20 straight half-focused sleepy hours, and not only for that what you can do, but also for what you decide to do. Being sleepy makes you dumb, so you take dumb decisions, and so you end up with a much worse project, or probably even a broken one.

If the hackathon lasts 24 hours or more, prioritize for energy and mental clarity rather than for time in front of the screen. Talking about mental clarity, you need it to put yourself in the shoes of the judges to avoid making the last mistake.

3. Choose an idea very few people can actually understand.¶

Even though I scratched my own itch and solved a real problem, I think it ended up being a problem that judges couldn't really feel. Unless you have celiac disease yourself or have a close person who does, you don't understand why it matters. Most of the judges didn't even know what "celiac" means. So if judges don't understand why it matters, what are they going to say? "Cool project." And when you hear that as a response, it means it was forgettable to them. The good alternative, conversely, is, "man, that is exactly what I needed," or, "wow, this is actually useful." People are often too polite to tell you they don't care about it, so the default is an "interesting" project.

By saying this, I don't mean that you should always choose an idea that solves judges' problems. However, you can certainly choose an idea whose value proposition is more graspable. For example, the winner team on my main track created a tool for people who can't speak. Even if you don't know anyone who can't speak, you probably can feel very quickly how terrible it would be to have such condition, and so understand why a tool that addresses such problem matters. On the other hand, if I tell you that I have to call restaurants one by one, well, big deal, it's just a tedious inconvenience you sometimes have to address manually.

Aside from the hackathon, though, scratching your own itch has a pretty positive side, which is that you if you do it properly you'll end up with a useful solution to your own problem, even if very few people care about it. So it's a matter of deciding what you want to maximize the most for. Sometimes you have an idea that matches both cases, and those are the best ones.

To conclude:

• start by writing the simplest code that does only the main thing you are trying to do, and ensure it works;
• maintain your energy high;
• and analyze judges' reaction to your idea before hacking starts.

Let's see if I can win the next one.

(Cover photo taken by me at the Berkeley campus)