Building an AI Hackathon Prototype That Keeps Human Judgement in the Loop

Summary

An AI hackathon prototype is a small working system, built in limited time, that uses AI models to address a real problem and that its team can demonstrate and explain. This article looks at the AI Hackathon (www.aifm.asia) from an engineer's point of view. OPERiON is organising it as part of PENtastic Startup Month 2026, hosted by Digital Penang.

The central idea comes from Ts. Lukas J. Tan. Use AI fully, but keep the parts that belong to people: choosing the problem, exercising judgement, taking responsibility for the outcome and speaking in your own voice. For programmers, that idea becomes a set of concrete architecture decisions. The sections below cover those decisions, the trade-offs behind them and how to present the result.

The Technical Problem: Fast Generation, Weak Ownership

With current AI tools, a team can produce code, interface copy, slides and a pitch script in a few hours. The danger is rarely that the output fails to run. The danger is that nobody on the team can explain why the system has the shape it has, which decisions the model made and which decisions people made.

In engineering terms, this shows up as three failure modes:

• Unframed problem. The team starts from what a model can do, not from an observed problem and the people affected by it.
• Opaque decision path. Model output goes straight to the end user. There is no point where a person reviews it, overrides it or records a choice.
• Template sameness. Generated code structure, interface text and pitch narrative drift towards the same patterns, so different teams end up with demos that look and sound alike.

Lukas has noticed the third pattern well beyond software. Speeches and presentations increasingly share the same vocabulary, grammar, structure and tone, as though they came from a single template. He admits he nearly fell into that trap himself. In a codebase the same thing appears as boilerplate that nobody chose deliberately and a README that could describe any project.

Architecture: Separate What the Model Generates from What People Decide

A practical reference architecture for a hackathon-scale AI system has five layers. Each layer has one clear owner and one clear responsibility.

1. Problem definition. A short, versioned statement of the observed problem, who experiences it and what a useful result would look like.
2. Input and data handling. Validation, minimal data collection and context assembly before anything reaches a model.
3. Model adapter. A thin interface that hides the specific AI provider, so the rest of the code does not depend on one vendor.
4. Human decision point. An explicit step where a person accepts, edits or rejects the model's draft, and where that choice is logged.
5. Presentation layer. The interface and the demo, which show the end user and the judges where AI assists and where people decide.

The data flow is deliberately linear, so it can be explained on one slide:

user input
  -> validate and minimise
  -> assemble context
  -> model adapter (draft only)
  -> human review (accept / edit / reject)
  -> decision log
  -> response to user

The key property is that the model only ever produces a draft. Authority stays with the review step. This reflects a point Lukas makes about AI generally: it can help organise thinking, but it cannot form personal judgement on our behalf.

Implementation Details

Write the problem statement as data

Put the problem framing in the repository next to the code. That makes it reviewable, and it makes any scope change visible in version history.

# problem.yaml
observed: "What we saw happening, in plain words"
affected_people:
  - "Who experiences it"
success_signal: "What would tell us the prototype helped"
out_of_scope:
  - "What we are deliberately not solving this weekend"

Wrap the model behind an adapter

The pseudo-code below is not tied to any particular provider's API. The aim is a single place to change prompts, swap models or return a recorded response when the network fails.

class ModelAdapter:
    def __init__(self, client, prompt_template):
        self.client = client
        self.template = prompt_template

    def draft(self, context):
        prompt = self.template.render(context)
        text = self.client.generate(prompt)   # provider-specific call
        return Draft(text=text, prompt=prompt, source="model")

Make the human decision explicit

def review(draft, reviewer):
    choice, final_text = reviewer.decide(draft)   # accept | edit | reject
    decision_log.append({
        "draft": draft.text,
        "final": final_text,
        "choice": choice,
        "reviewer": reviewer.id,
    })
    return final_text if choice != "reject" else None

The decision log does real work. It shows the team how often the model's draft was actually used, and it gives the judges evidence that people stayed responsible for the outcome.

Treat secrets and data with care

• Keep API keys in environment variables, never in the repository or on a slide.
• Use synthetic or consented sample data. Do not paste real personal information into prompts.
• Collect only the fields the problem statement needs.

Test what can be tested

Write ordinary unit tests for the deterministic parts: validation, context assembly and the decision log. For model output, the team writes a small fixed set of test cases and reviews the results by hand against the success signal in problem.yaml. Report what you observed. Do not quote accuracy figures you have not measured.

Prepare the demo deployment

Make the prototype start with one command. Keep a recorded fallback response for when connectivity fails, and if you use it, say so on stage. An honest demo is worth more than a polished one that hides its limits.

Presenting the System Is Part of the Engineering

Lukas points out that presenting well means more than speaking in front of an audience or designing attractive slides. It means helping a manager, interviewer, client, partner or investor understand why something matters. For a technical team, a strong presentation answers a few direct questions:

• Which problem did we observe, and who is affected?
• Where does AI assist, and where do people decide?
• What did we test, and what did we see?
• What is unfinished, and what would we build next?

A repository built this way also becomes a record of the builder. It shows which problems a young person cares about, how they think, how they use tools, how they work in a team and how they turn an idea into something tangible. That is what future employers, partners and investors look for.

Pitfalls and Trade-offs

• Speed versus understanding. Accepting generated code wholesale saves time now. It costs you later, the moment someone asks how it works.
• Adapter overhead. An abstraction layer adds a little code. In return it gives you a fallback path and freedom to change provider.
• Review friction. A human decision point slows the flow. That friction is intentional where the outcome affects people.
• Polish versus honesty. Hiding limitations may impress for a few minutes. Naming them shows judgement.
• Narrow team roles. Not every strong contributor writes code. Observers, designers, analysts and people who bring a team's ideas together all shape a better system.

FAQ

What is an AI hackathon prototype?

It is a small working system, built in limited time, that uses AI to address a real problem and that its team can demonstrate and explain.

Do participants need advanced programming skills?

No. Participants can come from different academic backgrounds without a complete set of technical skills. Willingness to take part, learn and test ideas matters more.

Why add a human review step to an AI prototype?

Because AI can draft, but people remain responsible for choices and outcomes. A logged review step makes that responsibility visible.

How should a team test model output without benchmarks?

Write a small fixed set of realistic cases, review the outputs against your success signal and report only what you observed.

Who organises the AI Hackathon?

OPERiON organises it as part of PENtastic Startup Month 2026, hosted by Digital Penang. Details are at www.aifm.asia.

Conclusion

A good AI hackathon prototype is not the one that generated the most. It is the one whose team chose a real problem, kept judgement with people, tested honestly and can explain every layer in their own words. Seen that way, architecture is a means of building the solution and of showing who you are as a builder.

Students, educational institutions, businesses and community groups are welcome to take part in the AI Hackathon at www.aifm.asia. If your organisation is considering a similar human-in-the-loop AI system, you are welcome to read one of our case studies or book a Discovery Session with our team.