I spent day one of CIDECODE 2026 as a mentor, watching student teams build cybercrime investigation tools against the clock. It is the third edition of the CCITR-CID Karnataka Police Tech Hackathon, held on 4 and 5 July at PES University in Bengaluru: 24 hours, three problem statements, and a room full of laptops.
I mentored one of the three verticals. Watching a full day of it up close taught me more about where student engineering is headed than any single project did.
What the hackathon actually is
Dr. Pronab Mohanty, IPS, Director General of Police, CID, Special Units & Economic Offences, Karnataka, and Dr. Suryaprasad J, Vice Chancellor of PES University, inaugurated the hackathon together and lit the ceremonial lamp before the 24 hour build began.
CID Karnataka runs this through its Centre for Cybercrime Investigation Training & Research (CCITR), in partnership with PES University. Teams of 3 or 4 students submit a synopsis, get screened, get a mentor for a few weeks, then show up for a 24 hour build.
The prize pool is over 5 lakh rupees: 2,10,000 for the winning team, 1,50,000 for runners up, 90,000 for third place, and 60,000 consolation prizes, three teams deep on the top three and six teams deep on consolations. Winning teams also get an internship at CCITR, CID.
Three problem statements this year:
- Automated bank statement analysis. Ingest bank statements in different formats, flag suspicious activity, trace fund flow across accounts.
- APK threat analysis with C2 detection. The one I mentored.
- SOCMINT-based suspect profiling. Correlate a suspect’s scattered social media accounts, usernames, emails, and phone numbers into one profile using public data.
The vertical I mentored
The official brief for my vertical read like this: analyze Android APK files using static and dynamic techniques, identify malicious behavior, detect command and control infrastructure, and extract forensic artifacts an investigator can actually use. APK fraud is rising fast in India, and a lot of it hides its real behavior until the app is actually running, so static analysis alone misses it.
The best team under this brief did not stop at “we found a suspicious string.” If static analysis turned up a Telegram bot token embedded in the app, they took that token and went and searched for the credentials tied to it, chaining a static finding straight into an active lead. That is the difference between a tool that flags things and a tool that hands an investigator a next step.
The AI research trick that beat everyone else
The team I’d rate highest across the whole floor did not win on hardware or on raw feature count. They won on a research habit: they used AI to research their problem space, but they asked it questions from a different domain than the one everyone else was staring at.
That sideways question surfaced an angle nobody else built for, and it made their whole submission richer. Not a bigger feature list, a feature list nobody else had the idea to build. That is a research skill, not a coding skill, and it showed.
Model access mattered too, plainly. Teams with better model access built more capable pipelines, and that was visible in the room. But the team that combined good model access with an unusual research question outperformed teams that only had one of the two.
Hardware still counts
One team built on an NVIDIA Jetson Nano, running their analysis on dedicated hardware instead of a laptop and a cloud API key. It was not the most polished demo I saw, but it was the only one that was not just software, and that kind of novelty is worth something a pure software stack cannot fake.
The split I was not expecting
I mentor a lot of student teams, and the year-of-study gap showed up here more cleanly than it usually does.
First and second years were confident and fast, and mostly lost. They could get a result, and they were completely sure the result was right, but they could not explain what was running underneath it. Ask what framework their agent was built on, or what the API call underneath a tool actually did, and the explanation ran out fast.
Third and fourth years were a different story. They had grown up coding by hand first and adding AI on top of that later, in that order, and it showed in how they debugged. When something broke, they knew which layer to look at. The seniors on the APK vertical were running full agentic workflows for detection and tool swapping and could still walk me through every step of why it worked.
Everyone in that room is technically talented. The gap is not talent. It is whether you built your instincts on the stack before you built them on the assistant. I do not think that is a verdict on this year’s juniors, I think it is a preview of the default path for anyone who starts on AI-first tools before they have ever had to debug without one. Third and fourth years here had years of hand-coding to fall back on. The classes behind them will not have had that runway, and that gap is worth watching, not dismissing.
The models in the room
Across teams, one thing came up enough times that I trust it as a pattern rather than a one-off: Fable 5 was consistently the strongest model for planning, and specifically for telling a team clearly where a plan had gone wrong. Anthropic’s models generally were the ones teams trusted most when the output actually needed to be right.
I am not going to pretend that is a rigorous benchmark. It is a mentor’s afternoon of watching a dozen teams debug in real time, which is its own kind of signal, just not a controlled one.
What I am watching for on day two
Day one was building. Day two is presenting to the jury, and that is where the research-driven team and the hardware team either hold up under questions or do not. I have my own guess at who does best, based on what I saw, but a guess made before the jury round is just that, a guess.
The thing I will actually carry forward from today: the best team I saw did not out-code anyone. They asked a better question before they wrote a line.