I wrote about day one of CIDECODE 2026 while the teams were still building. Day two was the jury round, and the results did not go the way I expected.
The team I rated highest did not place
On day one, one team on my vertical stood out for how they researched the problem, not for how much they built. They used Fable to explore the problem space, deliberately asking it questions from a domain that was not the one everyone else was staring at, and worked around the limits that put on a direct answer. That angle surfaced gaps in the brief that almost every other team left alone.
Some of their members had placed second in this same hackathon last year, so this was a team with real returning experience behind it. I expected that experience plus this year’s research to be enough to win. They did not secure a prize at all.
Talking to people afterward, the reason was not the work. It was the pitch. The presentation lacked clarity and simplicity, and every feature they had built was real and it worked, but the explanation of each one ran long and layered, competing for the judges’ attention inside a time limit that did not have room for that. Feature after feature got the same treatment: the mechanism explained before the value, so by the third one the panel was parsing implementation detail instead of asking what problem it solved. A judging round is a few minutes per team. If the panel cannot follow what a feature does, it does not matter how well it does it.
Three teams I scored as equal took first, second, and third
Separately from that team, I had three other teams on my vertical scored dead even. I expected all three to end up competing for second place.
They took first, second, and third, in that order.
The common thread across those three was not raw technical depth. It was that each of them could explain their own project in a straight line: here is the problem, here is what we built, here is what it finds. That is the whole lesson from day two for me. Communicating the value simply is not a soft skill you tack on at the end. In front of a jury, it is the product.
What the first place team actually got right
The team that won first on my vertical had built something CID and Karnataka Police could plausibly use as it stood, not a demo that needed another two months of work to become real.
It is a genuinely strong result, and I mean that. It is also a hard thing to watch happen to the team I personally rated higher on research, because the gap between them was presentation, not substance. Congratulations to all three winners on my vertical. That is not a hedge, it is the honest read.
The generational gap looked different up close this time
I wrote after day one that the split was not about talent, it was about whether someone built their instincts on the stack first or on the assistant first. Day two sharpened that for me in one specific way.
First and second year teams were confident, and that confidence held up right until someone asked what their code actually did underneath the tool calls. Part of why the confidence is so easy to hold onto is that the tools do not require you to earn it anymore. Someone with no engineering background can describe a feature in plain language and get back something that runs and looks finished, and there is nothing in that experience that tells them whether it will hold up past a demo.
That is the part a 24 hour build cannot test. A lot of what gets built fast right now looks finished without anyone involved having shipped anything to a real customer, under a real SLA, under real legal obligations for how the data gets handled. None of that shows up here, so none of that confidence gets tested either.
Third and fourth year teams are the ones actually benefiting from this moment, and they are walking a tightrope while they do it: old enough to have debugged by hand before AI tools existed, young enough that the tools are now the default way they work. That combination is not going to be available to the class behind them in the same way, which is worth watching over the next few years, not just this one hackathon.
A short conversation that stuck with me
Between rounds I talked to someone working out of the founder’s office at Razorpay, building an internal system to automatically discover gaps between what customers need and what the product currently does, then route each one to a decision: ship a fix, ship a new feature, or flag it for a person to look at, instead of leaving that triage to manual review. Small conversation, but it was a useful reminder that the same problem the hackathon teams were chasing, turning a mess of raw signal into something a person can act on, is exactly what production teams are paid to solve every day, just with a lot more riding on getting the decision right.
Trying the problem statements myself
Watching two days of this from the mentor’s side left me with a question I cannot answer from the sidelines: how hard are these problem statements actually, for someone with production experience behind them instead of 24 hours and a laptop?
I want to find out directly. Over the coming weeks I plan to work through the APK analysis problem statement myself, and see where a professional’s approach to it actually differs from a student team’s, beyond just having more time. If it turns into something Karnataka Police or CID could use as a tool or a small service, open source or not, that is the outcome I am building toward. Mentoring showed me the gap. Building it is how I find out if I can help close it.