Who Built This?

The Tenth Demo Video

We recently finished judging a large global agent hackathon. More than a thousand teams submitted, and over 900 submissions qualified for full technical review. I spent days going through repositories, architecture diagrams, submission forms and a lot of demo videos.

I’ve been judging hackathons for quite some time, and I’ve seen some big events. But this was on another scale. The first few videos were fine. Each followed the familiar SaaS launch script. A persona gets introduced, a problem gets staged and (yeah, you guessed it right) the agent saves the day. By about the tenth, I was fairly sure many teams hadn’t written their own pitch. The videos all had the same pace, the same buzzwords and the same made-up users with neat job titles (LOL 😂). My guess is the teams each asked a model, and the model gave everyone roughly the same pitch. A very few teams were smart enough to add their own spin to it, but most didn’t even bother.

What I couldn’t tell, video after video, was who had built the thing, why they cared about the problem, or what it did when reality pushed back. Those are the things a demo is supposed to show, and a generated script can’t show them because none of it is in the brief. I’d have traded all that polish for one honest detail, like the edge case that cost a night or a failure the team had handled.

This is my personal opinion and nothing more. We had more than twenty judges across very different domains, and this is one judge’s reading of the repositories and the architecture. Still, after those days I reached a conclusion I didn’t enjoy. As a test of engineering, the hackathon has largely lost its signal. When nearly every team prompts an assistant with the same brief, the result mostly measures who summarised the guidelines best. That said, prompting is a skill in its own right, and as awareness grows and people get better at using AI, it becomes harder & harder to distinguish engineering ability from skillful prompting.

Where I’m standing matters here. I’ve taken part in more than a hundred hackathons since 2020 (yes, an unreasonable number), on Devpost, lablab.ai, Devfolio and a few other platforms. I won something at roughly 86% of them, and the grand prize or first place overall at somewhere between 40 and 50%. The first number is easy to check, since 43 of my 48 public projects on Devpost carry a winner ribbon, and the second is my own count because a few projects are private. Devpost even featured me once. Nearly all of it happened remotely. Most of the hackathons were based in the US, followed by Canada, with others in the UK, Germany, Dubai, Switzerland and a few other countries. Remote and hybrid formats were the only reason a student from a tier-B town in West Bengal could win prizes at some of the best-known and most competitive international hackathons, including HackNYU, Caltech’s Hacktech, Stanford’s TreeHacks, MIT’s HackMIT, Harvard’s HackHarvard and UC Berkeley’s Cal Hacks, and could spend many other weekends at events like Hack the North, CalgaryHacks, SwampHacks, & many others, all without a visa or a round-trip plane ticket.

Note that, some international (in-person only) hackathons do offer travel reimbursements to help cover the cost of getting there, especially if your profile stands out, or (sometimes) if you’re from a region that’s underrepresented in tech. For example, I was accepted to Stanford’s TreeHacks, which offered travel support of up to around $1,000 (in some cases). For someone travelling from India (like me), where a round-trip flight to the US alone can eat up a large part of that amount, this kind of support can make a real difference, even if it doesn’t cover everything. AdventureX in China offered travel subsidies too when I was accepted last year, though my semester exams kept me from attending in person, so my friends went there, and I ended up joining remotely instead. The support varies by event, and with international travel costs and funding becoming harder to navigate, these opportunities aren’t always straightforward. Still, they show that access to global hackathons isn’t necessarily limited to those who can afford to travel entirely out of pocket.

Tbh, I’m a little shy about all that. Hackathons were simply some of the most fun I had in college, and I skipped plenty of parties for that adrenaline without regret. Most of it happened before gen-AI could do any of the work. Back then a bug at 3 a.m. meant Stack Overflow, hundreds of open tabs, diet coke and a teammate who had fallen asleep on the Discord call, or in a Slack huddle or as an avatar parked in a corner of Gather Town, whichever the organisers had picked. Now it means asking an (AI) agent, which fixes the bug, rewrites the documentation and politely suggests a feature nobody asked for. I’m down to two or three events in the last year and a half, and I still get the same rush, though these days part of the night goes to reviewing pull requests from a teammate that never sleeps. Sometimes, I wonder, how much I’ve changed as a person, and how much the world has changed around me.

None of it was solo. Subham Sahu and Gaurang Ruparelia pushed me harder than anyone, and along with Aziz Abdullaev they’re the teammates closest to my heart. My college friends Sandipan, Saif Ali, Sarthak Chakraborty and Debdut Goswami were part of it too, and Joshua Wolk, Emily Nguyen, Jasmine Wu, Muntaser Syed, Stanley Lee, Nghi Ho, Nate and Ali Shariatmadari were among the many others I built with. Some of those teammates are now at MIT, Stanford, at at big-tech corps like Vercel and a few unicorns. Some are also helping to steer Super Intelligence (SI) forward at OpenAI, and at Tesla. I’ve written before about one of those weekends, and my one regret is that I never wrote about the rest while they were happening.

What a Win Used to Prove

A hackathon win used to be one of the more honest credentials in software. It said you could take a vague problem on a Friday, write code against a hard deadline, debug the integration that broke at three in the morning, and still have something working on Sunday. We read winners as resourceful engineers who were fast and had enough architectural sense to pick a design that would survive the weekend.

Most weekends went roughly like this.

The loops were where you learned things. An idea fell apart at the first question from a mentor, so you went back and picked another. The integration broke at three in the morning, so you either fixed it or cut scope and lived with a smaller demo. On the weekend I remember best, I got about three hours of proper sleep across two nights, mostly in short naps between team syncs. Our teams were often spread across the globe, so someone was always awake.

That cost is the reason a win meant anything. In 1973, the economist Michael Spence asked when a credential can tell an employer something about the person holding it. His answer, part of the work behind his share of the Nobel prize, is that a signal separates people only if it costs the less capable more to produce.^[1] He was precise about what happens when it doesn’t.

Read that last clause again with nine hundred agent submissions in mind.

The time box supplied the cost. A working system in a weekend was cheap for someone who had fought (say) OAuth callbacks and silent webhooks before, and out of reach for someone who hadn’t, so judges never had to measure that difference themselves.

To be fair to the past, a win was never a code review. Major League Hacking’s standard rules spell out that the judging criteria don’t include how good your code is or how well you pitch,^[2] and Devpost’s standard rules (for most hackathons) have long said judges “may choose to judge based solely on the text description, images, and video provided in the Submission.”^[3] What a win certified was narrower than “great engineer”, namely that a team could ship under pressure. It’s worth noticing, too, how little an online judge may be asked to look at.

The Same Point, as Arithmetic

Suppose a fraction $\pi$ of the teams in a field are strong. A strong team produces a convincing submission within the window with probability $q_s$, and a weaker team with probability $q_w$. Bayes’ rule gives the chance that a convincing submission came from a strong team.

• $\pi$ is the base rate, i.e., the share of strong teams in the field.
• $q_s$ is the probability that a strong team ships something convincing in the time allowed.
• $q_w$ is the same probability for a weaker team.

Everything interesting sits in the likelihood ratio $q_s / q_w$. While it’s large, a convincing submission is strong evidence. As it falls towards 1, the answer slides back to $\pi$, and the win tells you nothing you didn’t know before you pressed play. Changing $\pi$ moves every answer up or down without making the evidence any sharper.

Here are some illustrative numbers, not measurements. Take $\pi = 0.2$, and before assistants say $q_s = 0.8$ and $q_w = 0.1$.

A convincing submission meant roughly a two in three chance that you were looking at a strong team. Now give everyone an assistant that writes the boilerplate, the glue code, the interface and the pitch script, which are exactly the parts weaker teams used to run out of time on. Say $q_s = 0.9$ and $q_w = 0.7$.

That’s barely above the 20% you started with, and the likelihood ratio has fallen from 8 to about 1.3.

Something like this has been measured, though not at hackathons. When economists studied generative AI at a large customer-support operation, productivity rose 14% on average, “including a 34% improvement for novice and low-skilled workers but with minimal impact on experienced and highly skilled workers.”^[4] Strong teams didn’t get worse. Weaker teams got much better at producing the one thing being judged, so the judged thing stopped carrying information.

The Idea Was the First Thing Handed Over

None of this is an argument against AI coding assistants. Using them is the sensible default in 2026, and very few engineers want to write boilerplate by hand again. The qualities that earned respect at a hackathon was architectural judgement, an original idea, clear system boundaries, guardrails that behave the same way every time, an understanding of how the thing fails, and knowing what not to build.

The tools are also improving at an unusual pace. Ramez Naam, who is sceptical of the more dramatic forecasts, still calls frontier progress since early 2024 “blisteringly fast”,^[5] and OpenAI says it now has an “automated research intern” for well-defined research tasks under human direction.^[6] The products get cheaper as they improve, too. OpenAI cut the price of Luna, its most cost-efficient GPT-5.6 model, by 80% this July.^[7] For students, most of that is good news.

What changed at this hackathon happened before any code was written, because many teams handed over the idea itself. You paste the brief into a coding agent, the agent proposes a project and launches sub-agents for research, code and the interface, and the team reviews what comes back. The demo video can come out of the same session now, since tools like Remotion publish skills that let coding agents build videos in code.

Touching upon the same, what a project like that mostly measures is how readily the team accepted what came back. It also saves a lot of time, which is why it’s so tempting.

Access decides how far you can take this, as I’ve written before. The plans built for all-day agent use start at $100 a month, which is a lot for a student in India. Inside OpenAI, the median researcher was using more than $600 of inference a day at API prices by mid-August.^[6] Money buys speed as well, since running agents in parallel means, in OpenAI’s words, “trading higher token use for stronger results and faster time-to-result”.^[7] Some people pay because they feel they have to, others use credits their employer covers, and the best-equipped teams start the weekend ahead for reasons that have little to do with skill.

People do use the free routes, though the paid tools still lead by a wide margin.

Even inside the labs, more output hasn’t meant proportionally more progress. By Naam’s reading of OpenAI’s charts, its researchers used about 124 times more tokens per person while experiments per researcher rose about 1.6 times.^[5] Anthropic’s system card for Opus 5.5 says the model “mostly tests incremental ideas and prefers less ambitious hypotheses”, and METR, writing in the same card, expects full automation of AI research to need large improvements in researcher “judgement” or “taste”.^[8] That’s the part a hackathon is supposed to test, and by the labs’ own account it’s still a weak spot for the models.

It may also explain why so many submissions looked alike. A NeurIPS 2025 best paper tested more than seventy language models on open-ended prompts and found that even models from different companies produce “strikingly similar outputs”.^[9] In one example, two models from the same family wrote the identical motto, “Empower Your Journey: Unlock Success, Build Wealth, Transform Yourself.”

The cost to builders worries me more. In a randomised study Anthropic published this January, engineers learning an unfamiliar Python library with an AI assistant scored 50% on a follow-up quiz, against 67% for those who coded by hand, and the widest gap was on debugging.^[10] It was a small study, so I hold the numbers loosely, but the authors’ conclusion stays with me, that “AI-enhanced productivity is not a shortcut to competence”. A hackathon is one of the few places where you build competence under real pressure. The catch is that short-term speed can come at the expense of long-term competence, quietly accumulating what we might call cognitive debt.

The Rubric Became the Architecture

The pattern that bothered me most had nothing to do with videos.

Participants received a rubric describing three technical tracks, along with a list of recommended platform services. Far too many teams pasted that rubric into a model and asked for an architecture that ticked every box, so each phrase in the rubric became a component.

Marilyn Strathern, an anthropologist writing about university audits in 1997, put this in the form usually credited to the economist Charles Goodhart.^[11]

A rubric is a measure, and a model handed one as a specification will satisfy it literally.

Human in the loop (HITL) is the row that’s easiest to get wrong. Approval gates belong in front of actions that are high impact or hard to reverse, and Google’s guidance on securing agents asks for explicit human confirmation on actions “deemed critical or irreversible”.^[12] Nothing like that happened where these pauses appeared, so an automated check, even another agent reviewing the output, would have done the job. A gate with nothing behind it mostly trains people to click approve without reading, which Anthropic’s engineers call approval fatigue.

Observability had the same problem. Tracing becomes observability when it answers a real question, like which tool call failed for which user, or whether yesterday’s prompt change made the answers worse. Hamel Husain has argued that unsuccessful AI products “almost always share a common root cause: a failure to create robust evaluation systems.”

Declared on the Form, Missing From the Repo

Respect at hackathons used to go to the team that built something reliable with the fewest moving parts. This time, many teams seemed to measure architectural maturity by how many managed services they could name, because those services were on the list.

A basic task-routing workflow doesn’t need an asynchronous message broker. In dozens of projects, the submission form declared message queues and enterprise databases that appeared nowhere in the repository. Checking isn’t hard. A real queue means a client import and a publish call somewhere, and a real database means a driver and a connection string. When none of that exists, the box on the diagram is decoration, and I’d honestly rather the team had left the service out.

Even the choices nobody had asked about converged. Document stores held the state, the frontends used the same standard framework, and security meant Model Armor, Google Cloud’s prompt screening service. None of these is a bad choice on its own. What bothered me was seeing the same combination in submission after submission, which suggests the choice came from the same prompts rather than from the teams.

People who build agents for a living keep arguing for fewer parts. Anthropic’s guide to building agents recommends “the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.”^[13] Multi-agent designs can pay off, as Anthropic’s own research system shows, but they cost more and they have to earn their place.

Security, Mostly by Prompt Filter

The enterprise track was meant to test whether builders understood the security problems specific to agents, namely identity, least privilege, deterministic execution boundaries and sandbox isolation. The default answer was a prompt filter in front of the model plus an LLM “critic” agent to judge user input, labelled enterprise grade. Both try to catch prompt injection, which is when instructions hidden in text the agent reads (a web page, an email, a support ticket) push the model into doing something its user never asked for. Underneath that layer, the track looked like this.

• Identity. Out of hundreds of submissions, fewer than ten verified the token on an inbound agent-to-agent call. The rest checked neither its cryptographic claims nor its audience.
• Sandboxing. Only a tiny fraction ran untrusted, dynamically generated code inside a dedicated, locked-down sandbox.
• Privilege. Tool calls routinely shared the same cluster-admin service account credentials.

A prompt filter can’t see any of those problems.

What a Filter Can and Can’t Do

In December ‘25 the UK’s National Cyber Security Centre put the root cause in one sentence.^[14]

SQL injection was tamed by keeping code and data apart with parameterised queries, and a model has nothing equivalent, since, as the NCSC puts it, “there is only ever ‘next token’.”

So a filter is a classifier guessing at intent, and the attacker gets to keep guessing back. In “The Attacker Moves Second”, researchers from OpenAI, Anthropic, Google DeepMind, ETH Zurich and elsewhere took twelve published defences, most of which had reported near-zero attack success, and beat most of them more than 90% of the time with adaptive attacks.^[15] Model Armor was one of the detectors they tested. With its score fed back to the attacker and Gemini 2.5 Pro behind it, the adaptive attack got through 90% of the time, and even a fixed, off-the-shelf injection got through 28% of the time, against 30% with no defence at all.

In fairness to Model Armor, the same paper says detectors still help against “unsophisticated or opportunistic attacks”, and its documentation is candid about its limits. It checks each prompt “independently as a single-turn request”, and very long inputs get skipped rather than screened.^[16] Google’s own paper on securing agents is clear about where such tools fit. Guard models “are non-deterministic and cannot provide absolute guarantees. […] They must work in concert with deterministic controls.”^[12]

The LLM critic has the same weakness, because it reads the same attacker-controlled text as the agent it’s guarding. It’s good at catching sloppy output, and I wouldn’t bet a cluster on it.

A security boundary is whatever still holds after you assume the model has been completely talked into doing the wrong thing. Designing from that assumption is what OWASP means when it says to “Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.”^[17]

Identity on Every Hop

When one agent calls another, it’s making a network call between two services. The caller has to prove who it is, and the receiver has to check that the proof was meant for it. Most of these systems pass around signed tokens called JWTs, and a token’s audience claim names the service it was issued for.

The specs are explicit about this. The A2A protocol, the open standard Google started for agents to call each other, says a server “MUST authenticate every incoming request” and authorise every operation, though it leaves the mechanics to the implementer.^[18] The JWT standard says a token whose audience doesn’t include the receiving service “MUST be rejected.”^[19] The Model Context Protocol (MCP), the usual way to connect tools to models, goes further wherever it uses authorisation, saying servers “MUST reject tokens that do not include them in the audience claim or otherwise verify that they are the intended recipient of the token.”^[20] That audience check is what stops a token minted for one agent from being replayed against another.

Cloud Run, on Google Cloud, does some of this for you. With its invoker check on, it rejects calls that lack a valid Google-signed ID token whose audience matches the service’s URL.^[21] But every service runs as a service account, an identity for software rather than a person, and a service with none set runs as the Compute Engine default account. That account may hold the Editor role, which can change almost anything in the project, and Editors can invoke private services. So if every agent runs as the default account and it still holds Editor, every agent can call every other one, and the edge check doesn’t keep any of them apart.

When an agent checks callers itself, or sits behind a public endpoint, the check has to live in code. With Google’s Python auth library it’s short.

1from google.auth import exceptions
2from google.auth.transport import requests as google_requests
3from google.oauth2 import id_token
4
5THIS_SERVICE = "https://payments-agent-abc123-uc.a.run.app"
6ALLOWED_CALLERS = {"planner-agent@my-project.iam.gserviceaccount.com"}
7_transport = google_requests.Request()  # reuse; cache certs in prod
8
9def authenticate_caller(authorization: str) -> str:
10    scheme, _, token = authorization.partition(" ")
11    if scheme.lower() != "bearer" or not token:
12        raise PermissionError("missing bearer token")
13    try:
14        claims = id_token.verify_oauth2_token(
15            token, _transport, audience=THIS_SERVICE
16        )
17    except (ValueError, exceptions.GoogleAuthError) as err:
18        raise PermissionError(f"invalid token: {err}") from err
19    caller = claims.get("email")
20    verified = claims.get("email_verified") is True
21    if not verified or caller not in ALLOWED_CALLERS:
22        raise PermissionError("caller not allowed")
23    return caller

Warning

audience=THIS_SERVICE is the argument that’s easiest to leave out. Without it the library doesn’t check the audience at all, so a token minted for any other service passes.^[22] Google’s own Cloud Run sample omits it, which is safe only when Cloud Run’s edge has already verified that same token. In a public service it accepts tokens meant for anyone.

Two more details matter. verify_oauth2_token also checks the token’s iss claim, which the lower-level verify_token skips. And the allowlist is authorisation, a separate question from authentication, because a valid token tells you who is calling but not whether they’re allowed to do this.

One Identity per Tool

Kubernetes (K8s), where many teams run their containers, has a role called cluster-admin that grants “super-user access to perform any action on any resource”. The project’s own guidance says that “pods shouldn’t be assigned service accounts that have been granted powerful permissions”.^[23] When every tool call shares a credential like that, one successful injection through any tool gets everything that credential can touch, which is the whole cluster.

Give each agent its own identity with only the permissions it needs, and let it call only the services it uses. On Cloud Run that takes three commands.

1SA=planner-agent@PROJECT_ID.iam.gserviceaccount.com
2
3gcloud iam service-accounts create planner-agent
4
5gcloud run deploy planner --image=IMAGE_URL \
6  --region=us-central1 --service-account="$SA"
7
8gcloud run services add-iam-policy-binding payments-agent \
9  --region=us-central1 \
10  --member="serviceAccount:$SA" --role=roles/run.invoker

--service-account sets the identity the service runs as, and roles/run.invoker, granted on the payments service alone, lets the planner call that one service and nothing else. Do the same for every agent, then take Editor away from the default account, or anything still running as it can call payments anyway. Google’s per-agent Agent Identity has been generally available since April 2026, but you have to opt in.

Sandboxing Generated Code

Code a model generates at runtime is untrusted code, and it belongs in a sandbox, an isolated environment where it can’t reach the host machine or your credentials. An ordinary container makes a weak one because it shares the host’s kernel. Google’s GKE Sandbox documentation gives “AI agents that generate and execute code, often without supervision” as an example of untrusted workloads that leave a cluster more exposed to container escapes. The tools exist. gVisor runs containers on its own user-space kernel, Firecracker microVMs boot in under 125 milliseconds, and K8s has an Agent Sandbox project for this case. Very few submissions used any of them.

When Hackathon Habits Ship

My frustrations as a judge pale in comparison to my concerns as an architect. Habits formed on weekend projects tend to stick, and people reach for them at work on Monday.

We don’t have to imagine where that leads. In July, Hugging Face published a timeline of an intrusion by an autonomous agent that was running inside an OpenAI capability evaluation. The agent escaped its sandbox and reached infrastructure where one connector credential had been shared across clusters and bound to the K8s superuser group. “One stolen system credential was therefore cluster-admin everywhere: impersonating it, the agent held cluster-admin on two clusters within one second.”^[24] It’s the same shared-credential mistake I kept seeing in the enterprise track, this time in production.

In April, a coding agent on a staging task at a startup called PocketOS found a Railway API token in an unrelated file. The token had been created to manage custom domains, but it carried authority over the whole API, and the agent used it to delete the production volume and its backups in nine seconds. The founder’s post-mortem has a line I keep coming back to.^[25]

Now picture a generation of engineers learning architecture the way it showed up in those repositories. They delegate the problem to a prompt, stack redundant agents to look sophisticated, skip identity checks at runtime and trust a prompt filter to hold the perimeter. A demo video won’t show any of that, and I honestly don’t know how long it takes to unlearn.

Tip

What changes when it ships. Log every tool call against the identity that made it, so an incident timeline is a query rather than guesswork. Alert on policy denials and failed audience checks, since a spike in either can be the first sign of probing. Deny by default and expect a noisy first week, and re-run the least-privilege review whenever you add a tool.

The View From India

Some of this lands differently in India, where a lot of you are reading from.

Remote hackathons opened the door. For a student far from the Silicon Valley of India (Bangalore, or ಬೆಂಗಳೂರು), a prize at Stanford or MIT used to mean a visa and a flight, which in practice meant it didn’t happen. Online, it meant a Discord server and a time-zone headache. Most well-known events have since gone back to being in person, and flying to North America for a weekend isn’t realistic for most Indian students.

There’s a catch, though. In remote judging the artefact is all a judge has, and that’s exactly what got cheap. An in-person event can watch you build and see who is driving the keyboard at three in the morning, which an online event can’t. So the format that made the global circuit reachable from India is the one where the signal has worn thinnest.

Why people show up has changed too. Where I’m from, in West Bengal, hackathons weren’t even common until about three years ago, and the wave during COVID was mostly Web3. I’ve built and won at Web3 hackathons too, but I was never drawn to the space. From what I’ve seen, most people now enter for jobs and internships more than for the fun of building, and I understand why, since companies here hire through hackathons. Flipkart’s GRiD drew 468,312 registrations in its fifth season, and its winners have received pre-placement interviews for internships and full-time roles.^[26] Amazon’s first ML Challenge, in 2021, gave its winning teams pre-placement interviews for ML roles,^[27] and Adobe promised the top 50 teams of its 2025 hackathon pre-placement interviews and a chance at a paid internship.^[28] India still moves a little slower than the US and Canada, but the hiring pipeline is real.

There’s also a habit in campus culture that makes this worse. Many of us grew up learning, without anyone saying it out loud, that helping someone else means they get ahead and you fall behind, and years of rank-based exams with a fixed number of seats reinforce it. It isn’t universal, and it varies a lot from place to place, but it’s the wrong lesson for this kind of work. The teams that taught me the most were strangers in three time zones who treated a shared Discord channel and regular check-ins as non-negotiable.

Put the two together and you get the worst version of the signal problem. When hackathon wins go straight onto a résumé for placements and internships, a generated submission is a cheap way to add a line. Once enough people add the same line, it stops meaning anything, and the students who did the real work get pooled with everyone who didn’t. Those are often the students who most needed a signal that didn’t depend on which college they went to.

If you’re a student here, the most useful thing I got from a hundred-odd hackathons was the people I built with. Help the person next to you, even if you were taught not to.

What Judges and Builders Can Do

Agents cut both ways here. They make it easy to fake much of a project, and just as easy to tune the README and the form to whatever an AI reviewer is likely to reward. They make judging faster too. With a thousand entries to get through, some judges, from what I’ve seen, now hand most of the review to an agent when they have the compute, instead of reading the code the way judges used to. I understand the temptation. But a model grading text that another model wrote mostly rewards whoever produced the most convincing text, and that’s the cheapest thing in the whole pipeline now.

For judges and organisers

• Read the repository, not the form. If the form says there’s a queue, ask for the line that publishes to it.
• Write the rubric as problems, not services. Recommended services turn into the architecture, while failure modes to handle, like a poisoned document, turn into a design exercise.
• Ask what they decided not to build. A team with an answer has made decisions.
• Ask cold questions, live. Where do you verify the caller? What happens if the model is fully compromised? MLH’s organiser guide already suggests asking a team to explain a random bit of its code when a project looks suspicious. These are the defensible parts of a project, the decisions you can only defend if you made them.
• Break it in front of them. Hand the agent a document with an injected instruction and watch what it can reach.
• Don’t ban the tools. MLH’s standard rules have explicitly allowed AI coding tools since July 2025 and ask teams to disclose them,^[2] and bans leak anyway. In pilot runs of Anthropic’s skill study, a quarter to over a third of people told not to use AI used it regardless.^[10]

For builders

• Write the problem statement yourself before you open the assistant.
• Start with one agent, and add a second when you can name what the first can’t do.
• Keep a short list in the README of what you chose not to build, and why.
• Make sure every box on your diagram has a line of code behind it.
• Assume the model will be compromised, and design your security so that still holds.
• Be able to explain any file in your repo with the assistant closed.
• Show a failure in your demo, along with how the system handled it.
• Say which AI tools you used and which parts they wrote.

Back to That Weekend

Building fast with AI is the new baseline. But if we stop drawing hard boundaries, enforcing deterministic state transitions and scoping tools on purpose, we aren’t really engineering systems anymore.

The next generation of software can be far more capable than anything I shipped on those Slack/Discord-fuelled weekends, as long as the people building it take the wheel back. Let a model write as much of the code as you like, but the architecture and the trade-offs are still yours to defend.

Nobody on that team cared where I’d studied. They cared whether my part of the code worked when they pulled it, and that’s still what I look for when I judge.

TL;DR

• A win meant something because a working system in a weekend was expensive to fake. Assistants made that artefact cheap, so the skill now lives in decisions a demo doesn’t show.
• The tools keep improving and getting cheaper, but the strongest models still cost real money every month.
• Teams let AI pick the idea, write the pitch and draw the architecture, so submissions converged and rubric phrases became components that often weren’t in the repository.
• Fewer than ten enterprise-track teams verified tokens on agent-to-agent calls, and tool calls routinely shared one cluster-admin credential, which no prompt filter can fix.
• Real boundaries come from identity, least privilege, policy outside the model and sandboxes.
• In India, remote events opened the global circuit and companies now hire through hackathons, but remote judging relies on the very artefacts that got cheap.

Thanks for reading. Comments and corrections are welcome.

P.S.: I still couldn’t tell you what we won that weekend. I remember the teammates, though.