Round 1 · Notebook · 12 September 2026
The first round of Season 1 ran on Saturday. The task, secret until 17:00 CET, was a personal notes app in one HTML file: multiple notes in Markdown with a live preview, persistence across reload, search, delete. Ninety minutes, any AI. Here is what happened, how it was judged, and exactly how the winner got there.
Result #
| # | Entrant | Tool | Rating | Entry |
|---|---|---|---|---|
| 1 | @P1s0 | Claude, plus a ChatGPT session | 1192 | open the app |
| 2 | @schwarzkopfb | GPT-5.6 Sol, Build agent | 1008 | open the app |
Both entries passed all five items of the functional checklist. With two survivors there is one comparison to make, so this round was a single head to head, judged by an LLM that drives both apps side by side through the interface only and never sees the source. Ratings are a Bradley-Terry fit over the results, starting from a 1100 baseline. Two entries is a small field, and the ratings will move a lot in Round 2.
The judge's verdict, verbatim #
The judge ran the same probes on both apps and wrote one note per dimension. A is @P1s0, B is @schwarzkopfb. This is the full text.
- Functional depth (40%) · A
- A's preview rendered heading, bold/italic, inline + fenced code, list, link, a real bordered table and task-list checkboxes (clickable in Read mode, which wrote the change back and showed '✓ Saved'), while B rendered the same source with the table left as raw pipes and task items as literal '[ ] unchecked task' (B did render blockquotes, which A left as a literal '> a quote').
- UX & polish (25%) · A
- A keeps sidebar, search, title bar and pane scrolling fixed while panes scroll internally, offers Write/Split/Read modes, '436 words · 2 min read', 'Saved · 1 min ago' and search results labelled '1 match in 1 note' with the hit highlighted; B's editor+preview grow the whole page so after a long note the search box, note list, New-note and delete controls scrolled off-screen.
- Robustness (20%) · A
- Both autosaved typed text through an immediate reload with no save click and both kept a delete after reload, but B became effectively stuck after the long-note probe, scrolling up and even a reload left the chrome unreachable and the code block clipped off the right edge, whereas A stayed fully usable at ~440 words (A's flaws were milder: auto-title only captured the first character, giving notes named 'F'/'S', and reload reselected a different note).
- Ambition (15%) · A
- A shipped inline #tag parsing with a clickable tag filter, pinning, Export all, an Undo toast after deletion, a keyboard-shortcut help panel (Ctrl+N/K/S, Esc, Ctrl+Enter) and Read-mode task checkboxes that edit the Markdown source; B offered only the core editor/preview with no visible extras.
- Overall · A, clear
- Both apps autosave and both filtered search correctly to the single matching note with a designed empty-result state, so the baseline spec is met by both. A pulls ahead on markdown breadth and holds its layout under load, whereas B's page grew to full note height and left the search box, note list and delete button unreachable. A's extras are deeper too. A is not flawless (blockquotes render literally, auto-titles collapsed to a single letter, and reload reselected a different note), but B's missing tables and task lists plus the long-note layout breakage outweigh those.
One correction we owe @schwarzkopfb. The first automated smoke run marked his delete button as broken. It was not. His app asks "are you sure?" before deleting, and the test harness was silently dismissing that dialog. We fixed the harness to accept dialogs the way a person clicking OK would, re-ran the test, and it passed 5 of 5. The corrected result is the one that counts, and the harness now behaves correctly for everyone from here on.
How the winner got there #
This is the part the ladder exists for. @P1s0's session ran 59 minutes and 17 prompts, in Claude. Not one of those prompts contains code, and several contain typos, because none of that mattered. What mattered is the order things happened in. Prompts are quoted as typed.
15:11 · prompt 1
Im participating in a challenge. the rules: [pasted the full rules page]
First move: give the AI the rules, before the task even exists. The reply came back with a plan for how to approach a timed build, so by the time the task was pasted the model already knew what the judge would be looking for.
15:13 · prompt 3
[pasted the task] … Lets summarize the requirement, possible approach then lets barainstorm
Summarise before building. The model turned the brief into "five hard requirements a judge will check, in this order". That list is the smoke test almost word for word, reconstructed from the rules alone.
15:16 · prompt 4
Do a wide research what is the users biggest problem with ios notes and google notes. how can it be solved, implemented here
Five minutes in, a research step. Not "build me a notes app" but "what do people hate about the notes apps they already have". This is where the tags, pinning and export came from.
15:18 · prompt 5
list all the decisions i need to make to make it unique.
Separates deciding from building. The model listed every product call with a recommended default, and the human overrode exactly one: the name. The app is called Jegyible.
15:23 · prompt 7
Create a very detailed prompt for this task.
The pivotal move. Instead of building, the model was asked to write the spec, a 13,000-character build prompt. Twelve minutes of the ninety went into this and nothing had been built yet.
15:25 · prompt 8
Review the requirement, rules. Is there anything left out?
A review of the spec against the rules before a single line of code. It found five gaps, two of them material, including that the resubmission rule was going unused.
15:28 · prompt 9
lets create it now
Twenty-eight minutes in, the build starts. Everything before this was setup, and it is why the build took one prompt.
15:39 · prompt 10
Write and read distinction is not clear. only can click once. in full screen it is bothering that both is there and cant dynamically chose between. that is not user friendly. Analyze the issue
The human opened the app and used it, then reported what a user would feel, not what a developer would see. "Analyze the issue", not "fix it". The reply found a real bug behind the complaint.
15:42 · prompt 11
Lets discuss the issue first without fixing in. how to fix it. The read and write should be a visible option. the read should be interactive too. tags are not clear. how to use them.
Discussion before code, again. "The read should be interactive" is the sentence that produced the clickable task checkboxes the judge singled out.
15:44 · prompt 12
Are these fulfilling the markdown requirement?
Verification. The model's answer began "Let me check rather than assert" and found that only one of three planned features actually met the requirement. This is the prompt that stopped a confident wrong answer from shipping.
15:46 · prompt 13
i still have time. 30 min.
Time awareness, stated out loud so the model plans against it. The reply budgeted the remaining half hour and started with the requirement gap first.
15:55 · prompt 14
why i cant add more tas?
A bug report from testing, four words and a typo. The model found two real defects behind it.
16:01 · prompt 15
what do i need to submit for this? "Your session transcript goes in with the file. No transcript, no entry."
Reading the rules again with 30 minutes left, and getting the export sorted before the deadline rather than after.
16:02 · prompt 16
besides the tags, analyze the whole program and requirement. is it user friendly?
A final whole-app review as a user. The model wrote a test harness for itself, and its reply admits "my harness was wrong" about one check. The human was supervising, the model was checking, and the checking was itself being checked.
16:07 · prompt 17
Lets do it
Last fixes. The entry was submitted at 16:23, seven minutes before the window closed.
What the runner-up did
@schwarzkopfb took a different approach: two prompts and eight minutes. The task went into a Build agent running GPT-5.6 Sol, then one request to spin up a dev server and smoke test the result. He submitted at 15:15, fifteen minutes after the drop, with 75 minutes still on the clock. That a first-pass build cleared every functional check says a lot about the tooling and about the person driving it. Where it lost ground was on things that only surface in a second look as a user: which Markdown features a judge would try, and how the layout behaves once a note gets long. The format rewards that second look, and the rules allow resubmitting right up to the close, which is worth knowing for Round 2.
What we learned #
The gap between the two entries was not the model, and it was not ability either. Both tools produced working apps on the first pass. The difference was time and iteration: one entrant treated the first build as the entry, the other spent another hour testing, questioning and steering. That second phase is what this ladder measures, and the ninety minutes are there to be used. Round 1 showed that more clearly than a bigger field might have.
Two of twenty is a small turnout, and we are saying so rather than dressing it up. Six people opened the task, four of them did not ship. Ninety minutes on a Saturday afternoon is a real ask. A seat covers the whole season, so everyone who sat this one out can start next week.
The harness had bugs, and the live round found them. The dialog issue above was one. Both fixes are in place and we will keep publishing corrections like this rather than quietly re-running things.