Hackathon talk · 2026

Ship it.
Together.

People, agents, and one shared brain.

Arindam Majumder

Arindam Majumder speaking at a community event
Hi, I'm

Arindam Majumder

A developer with a lot of agents.

  • Co-founder of Studio1
  • DevRel consultant at Nebius
  • Open source contributor, always shipping
  • Been on both sides of the judging table

What I love most: the shipping energy.

Say hi

Come find me.

  • Videos on YouTube
  • Thoughts on Twitter and LinkedIn
  • Questions welcome after

All my links:
linktr.ee/arindam_1729

QR code linking to linktr.ee/arindam_1729
Act 1 · Ship well

Why teams don't ship.

01

Overscoping

Months of product in a weekend. The #1 killer.

02

No plan

Coding at minute one, arguing at hour ten.

03

Broken demo

A last-minute "improvement" takes it all down.

04

Wrong team

Picked for friendship, not for the skills you need.

Sources: MIT Sloan Management Review · hackathon post-mortems on Medium and DEV
A story · my first hackathon

Both halves worked.

Me

Frontend

Built. Working.

?
My friend

Backend

Built. Working.

We never connected them. We didn't ship.

I've watched other teams make the same mistake. Our tools don't talk to each other, and neither did our context.

Hour 0–2

Plan for two hours. It saves ten.

  • Read the judging rubric first
  • Write what "done" looks like in one sentence
  • Write the 90-second demo script, before any code
  • Pick the one path the demo will walk
  • Assign roles: frontend, backend, glue, presenter
  • Agree on repo, branches, deploy target and where shared context lives

Judging criteria decide more than raw technical merit. And balanced teams beat four backend engineers who can't explain what they built.

Scope

Cut scope like you mean it.

Must

The demo path only. Log in, do the one thing, see the result.

Should

Only if the Must is deployed and rehearsed.

Could

Goes on the "future work" slide. That's not failure, that's a roadmap.

Example: a study-buddy app. Must: upload notes, get a quiz. Could: accounts, sharing, streaks.

Workflow

Merge often. Freeze early.

# the whole git policy $ git switch -c feat/quiz-endpoint $ git commit -am "quiz endpoint" $ git pull --rebase origin main $ git push # PR, merge within 1h # T-2h: code freeze. # Only bug fixes on main.
  • Ugly skeleton live by hour 4
  • Small branches, merged within the hour
  • T-2h freeze. No last-minute heroics.
  • One person owns the deploy button
The demo

90 seconds. Four beats.

1

Problem

One relatable sentence

2

Trigger

The moment the user acts

3

Aha

The thing that works live

4

Close

Why it matters, what's next

Mock what's risky. Remove every place the demo can stall. Rehearse out loud, with a timer.

Small plug · watch later

How I won the Gemma Hackathon.

Video embed
set data-yt-id on #yt-video
QR code to the video

The idea, my thought process, and the whole workflow.
youtu.be/lk6ttt6Nu_M

The problem

Four teammates. Four truths.

Asha · Cursor
API base:
/api/v1
DB: Postgres
Ben · Claude Code
API base:
/v2
DB: SQLite
Chen · Copilot
Auth: JWT
(spec changed
3h ago)
Dee · ChatGPT
Pasted README
from
hour 1

Each agent is confident and each is working from a different copy. Ask who has pasted the same README into three tools.

The ceiling

Start with AGENTS.md. Then it drifts.

178

lines differed between AGENTS.md and CLAUDE.md in one real repo

  • AGENTS.md: one file, 20+ tools read it
  • Then CLAUDE.md, .cursorrules, Copilot diverge
  • Stale docs send agents the wrong way
  • Nobody owns them or tracks changes
Sources: agents.md · Focused Labs on DEV · "AGENTS.md is not enough" on DEV
One shared source

Meet OpenLore.

A knowledge base for AI agents. One place for docs, notes and runbooks that agents and people all read, live.

Cursor
Claude Code
Copilot
OpenLoreSSH · MCP · HTTP
spec.md
api-contract.md
decisions.md

Open source · Apache 2.0 · single Go binary · self-hosted

Learn something

Stop paying to re-read your codebase.

Agents already speak ls, cat and grep. No custom API to learn.

Without shared context

  • Every request, the agent scans the repo
  • Reads file after file to find the contract
  • Burns tokens before it writes a line

With OpenLore

  • Agent greps one shared source
  • Gets just the context it needs
  • Tokens go to shaping, so cost drops

One shared API contract would have connected our frontend and backend.

Live demo 1

30 seconds to a shared brain.

$ go install github.com/aakarim/go-openlore/cmd/openlore@latest $ openlore ./docs # SSH :2222 · web + MCP :8080 $ ssh -p 2222 localhost "grep -r 'authentication' /" /spec.md: Auth uses JWT. Tokens expire after 1h. # edit spec.md, run it again: the change is already there
Live demo 2

Point your agent at it.

$ claude mcp add --transport http \ openlore http://localhost:8080/mcp > What is our API contract for the quiz endpoint? Reading /api-contract.md ... POST /api/v1/quiz takes notes, returns 5 questions.
  • Same answer for every teammate's agent
  • Update the doc once, everyone's agent is current
  • Works over MCP, so it's not tied to one tool
Trust

How do you stop a confident agent from overwriting the spec?

Read-only

The default. Writes are opt-in.

Scoped

Each identity sees only its own view.

Inbox

Agents publish findings for review, not straight to the spec.

Attributed

See who or which agent changed what, and when.

Plus per-document token budgets so agents don't drown in context. Runs as a pure-Go interpreter, with no shell escape.

Take it home

Your 24-hour playbook.

H0
Read the rubric. Write the demo script.
H2
Roles, scope, shared docs live.
H4
Ugly skeleton deployed.
H12
Demo path works end to end.
H20
Code freeze. Rehearse.
H22
Record backup demo. Sleep.

The printable checklist is in the handout: handout.html

Q&A

Questions?

  • OpenLore vs a single AGENTS.md?
  • OpenLore vs RAG or a vector DB?
  • OpenLore vs Notion or a Google Doc?

openlore.sh · github.com/aakarim/OpenLore
It's early. Issues, stars and PRs are welcome.

QR code linking to openlore.sh
openlore.sh
QR code linking to linktr.ee/arindam_1729
my links
← → navigate · F fullscreen · O overview