Projects
Every project is a curated run of timed tasks. Start a session — or join a friend's with a code — your agent builds, live checks score you, and AI judges review the result.
Tags
Shape
Session length
3 h 15 min 7 parts Handmade Claude Code Reinvent the Wheel Build a coding agent from nothing. Not a prompt pasted into a chat window — a program that runs the loop: sends a conversation to a model, executes the tools the model asks for, feeds the results back, and keeps going until the job is done. Then give it hands (files, shell, permissions), a memory (AGENTS.md, sessions, compaction), a way to learn (skills, hooks, subagents), a way to plug in the world (MCP), and finally a face: a terminal UI you would actually sit in. Seven sessions, one codebase. You start each part in the folder where the last one ended (or in an empty one, and your previous work is fetched for you), and every part opens by re-checking the contract the previous part earned — so a campaign carried honestly pays from its first check. The shape, frozen in part one You declare one command; the platform keeps it in session memory: agent: <command> started as: <command> -C <dir> [--yes] -p "<prompt>" Without -p the same command opens the terminal UI (part six). The model behind the harness is a pluggable provider: every model call runs the command in AGENT_MODEL_CMD, writes the request to its stdin as JSON and reads the reply from its stdout. The checks plug in a scripted model, which is how a harness gets graded exactly; wiring a real API behind the same interface is your job — and your reward, because from part two on the thing codes for you. The parts 1. The Loop — the headless agent: one prompt in, one answer out, the model protocol, a tool round trip, many turns, a provider registry with switchable models, retries, turn caps and the bill. 2. The Tools — read, write, edit, glob, grep and bash with real semantics; errors that come back as results; timeouts; a permission engine with allow/deny rules; parallel tool calls. 3. Context and Sessions — AGENTS.md up the tree with imports, @file mentions, environment in the system prompt, resumable sessions, and compaction when the context runs out. 4. Skills, Hooks and Agents — skills discovered and invoked, slash commands, pre/post tool hooks that can block, prompt and stop hooks, layered settings, and subagents that run their own loop. 5. MCP — stdio servers from .mcp.json: the handshake, tools advertised to the model and called through the server, errors, a server that will not start, prompts as commands, resources as mentions, environment and shutdown. 6. The TUI — the interactive face: a prompt, streamed answers, tool calls rendered, permission questions, slash commands, a status line with the bill, and an interrupt key that actually interrupts. 7. ACP — the agent inside an editor: the Agent Client Protocol over stdio, so any ACP client (Zed, Neovim, JetBrains…) can drive the same loop — sessions, streamed chunks, tool calls reported, permissions asked, cancellation, the editor's unsaved files, the client's MCP servers. How it is scored Every rung is verified by deterministic checks against your running agent — they start it with a scripted model, watch what it sends and does, and compare exact results. The review panel does not wait for the end: each judge sits on the rungs where its subject is decided and reads the repository as that rung lands — architecture where a seam appears, performance where a loop or a process is paid for, code quality and tests where the edge cases live, technical governance where a decision should be written down, developer experience — what the tool prints, how it fails, how it explains itself — where the output is the point, judged from terminal recordings and raw output you deliver on request, and harness review where a contract is decided: what the model is shown and handed back, what the tool refuses or asks before doing, how faithfully it speaks the protocol in play. A rung you never reach is a verdict you never get. One judge reads each session whole. The Agentic judge looks at how you engineered the agent that built the part — instructions committed, skills and hooks written and actually run, servers wired up and called — and pays one verdict per session. Only what that session added counts; the set-up you carried in from an earlier part is context, not credit. Wrapping claude, codex, gemini, aider or any other coding agent, or building on an agent SDK that owns the loop for you, is not building one. The loop, the tools, the permission engine, the MCP client and the TUI are yours. HTTP clients, JSON parsers and terminal-drawing libraries are tools, not the wheel. ai-agentharnesstui +2 Open 
5 h 30 min 5 parts Handmade ChatGPT Reinvent the Wheel· 1 played Build ChatGPT from nothing. Not a prompt pasted into somebody else's window — the product itself: a chat that streams the answer word by word, settings where a person plugs in the model providers they pay for and picks the model, accounts so that more than one person can use it, and projects that carry their own instructions. Five sessions, one codebase. You start each part in the folder where the last one ended, or in an empty one and your previous work is fetched for you, and add one capability — scored by a judge panel against the whole running product. The model is never yours: it is whatever OpenAI-compatible server a person configures, spoken to in either of the two protocols in the wild, Chat Completions or Responses. Bring your own provider to build against; a local server or a stub is fine. The parts 1. The Chat — a conversation that streams the answer word by word, remembered across a restart, many conversations with titles, and a provider that fails without breaking the page. 2. Providers — a settings page for the model servers you pay for, on either protocol, keys written once and never shown again. 3. Models — the models each provider offers, a model per conversation shown on every reply, switching mid-way, and a default. 4. Accounts — sign up and sign in, and see only your own providers, conversations and settings, with isolation enforced where requests arrive. 5. Projects — conversations grouped under a name, with instructions every one of them starts from. The judges Each part is scored by a panel — product fit against the scenarios, plus architecture, data, code and test quality, technical governance and creativity where each applies — and by UX review, which asks you for screenshots and a screencast of the running product. Keep the product runnable and the plan in TODO.md honest; both are evidence. Wrapping an existing chat product (Open WebUI, LibreChat, a hosted chat SDK) is not building one. HTTP clients, JSON parsers, UI frameworks and databases are tools. ai-chatllmweb +3 Open 
15 min Handmade find Reinvent the Wheel· 10 tasks· ~21 reviews· 1 played Reinvent the Unix classic find from scratch. The participant's agent builds a command-line tool that walks a directory tree and prints the paths that match the given predicates: <run command> <path> [predicates] You declare the run command yourself in a run: line, and it is captured into session memory — so any language and any entry point works (run: sh myfind.sh, run: python3 finder.py, run: node find.js, …). Each task fires real invocations of that captured command against a fresh randomly-named fixture tree, captures stdout, and compares it with the truth read from the filesystem itself. Whatever you declare is exactly what the checks run. Calling the system find — or piping any other traversal tool — is not building one; the tool must walk the filesystem itself with the language's own directory API. Output is a set of paths, one per line, each prefixed with the start path exactly as it was given (<path>/<sub>). Order is not graded — the checks compare the set — except where a task says otherwise. The start path itself is a candidate and is subject to the predicates, just like real find. The agent progresses linearly — each task unlocks the next predicate of the tool, in this order: Setup: declare the run: command (captured to session memory) (10) Print every path in the tree (10) -name <glob>: filter by the entry's basename (20) -type f / -type d: filter by kind (20) -maxdepth N: limit how deep the walk descends (40) -size ±Nc: filter by byte size (40) -newer <ref>: modified more recently than a reference file (40) -empty: empty files and empty directories (40) Predicates compose with implicit AND (30) -o (OR) and ! / -not (60) cliunixtool Open 
15 min Handmade ls Reinvent the Wheel· 10 tasks· ~21 reviews Reinvent the Unix classic ls from scratch. The participant's agent builds a command-line tool that lists directories: <run command> [flags] [path] You declare the run command yourself in a run: line, and it is captured into session memory — so any language and any entry point works (run: sh myls.sh, run: python3 lister.py, run: node ls.js, …). Each task fires real invocations of that captured command against a fresh randomly-named fixture tree, captures stdout, and compares it with the truth read from the filesystem itself. Whatever you declare is exactly what the checks run. Calling the system ls is not building one — the tool must read the filesystem itself. The agent progresses linearly — each task unlocks the next flag of the tool, in this order: Setup: declare the run: command (captured to session memory) (10) Plain listing: alphabetical, one name per line (10) Hidden files: dotfiles unseen until -a (20) A missing path fails politely (20) Long format -l: mode, size, mtime (40) Human sizes -lh (40) Sort by time -t (40) Sort by size -S (40) Reverse -r, composing with -t (30) Recursive -R (60) cliunixtool Open 
2 h 15 min 5 parts Handmade PostgreSQL Reinvent the Wheel Build a database server from nothing. Not a toy REPL over a file — a process that binds a port, serves many clients at once, parses and plans SQL, keeps pages on disk, survives being killed mid-write, indexes what it stores, and finally replicates and partitions it. Five sessions, one codebase. You start each part in the folder where the last one ended (or in an empty one, and your previous work is fetched for you), and every part opens by re-checking the contract the previous part earned — so a campaign carried honestly pays from its first probe. The shape, frozen in part one You declare two commands; the platform keeps them in session memory: serve: <command> started as: <command> <port> <datadir> sql: <command> started as: <command> <port> The server listens, stores and serves. The client connects, sends SQL from stdin and prints the replies. Every check in every part drives your database the way a real user would — over a socket, through your own client — and compares the replies against a text format that never changes across the five parts. The parts 1. The Server — bind a port, speak the protocol, serve concurrent clients, keep one shared database, survive a bad statement, stop when asked. 2. The SQL Engine — projection, WHERE with real operators, UPDATE, DELETE, ORDER BY, LIMIT, aggregates and GROUP BY. 3. The Storage Engine — pages on disk, data and schema that survive a restart, transactions, a write-ahead log, and recovery from a process killed mid-flight. 4. Indexes and Plans — a real index maintained on every write, a planner that chooses between a sequential and an index scan, EXPLAIN that shows which, and a hundred thousand rows that must not bring it to its knees. 5. Distribution — a replica that syncs, streams, stays read-only and catches up after downtime; WAIT that acknowledges; partitioned tables with pruning. How it is scored Every rung is verified by deterministic probes against your running server — they start it, talk to it, and compare exact replies. Each part then closes with a review, where a panel reads the repository and scores what the probes cannot: architecture, performance, code quality, tests, and technical governance — whether the decisions behind the code are written down and the conventions are enforced by tooling. Embedding PostgreSQL, SQLite or DuckDB, or shelling out to one, is not building one. The socket handling, the parser, the planner and the storage are yours. databasesqlnetworking +1 Open More projects are coming soon