The method
How Street University is made
One person, a roster of AI agents and a Jira board. This page shows how the game has been built since the first commit: who does what, how the work is checked, what it costs and what went wrong. Every number below is produced by a script at each release; none is typed by hand.
How to read itNine counts of the same project, all taken at the same moment. Weeks run from the first commit; releases are the version tags in git. The two code counts leave out comments and blank lines: the first is the game, the second the probes that test it.
Sourcegit, Jira, the export presets and the translation files of the game · snapshot of 5 November 2026
The timeline
Three eras on one axis
The way of working changed twice, and both times the change is visible in the data: first plans kept in markdown files, then tickets and a roster of agents, then a second AI plan working next to the first.
- commits per week
- tickets created per month
- rejections per month (a ticket sent back from review)
- release tag
- First commit: a prototype under the working title “Homeless City”, renamed nine days later.
- The roguelike direction is chosen: the first entry of the changelog.
- Multiplayer in one day: on the local network in the morning, over the internet with Epic Online Services in the evening. The brief gives the reason in one line:
si usa EOS perché è gratuito
(EOS is used because it is free). - Jira, CLAUDE.md, ORCHESTRAZIONE.md and the roster of agents are all born on the same day.
- First build on TestFlight; from now on Android goes through the Play Store.
- Epic approves the Brand Review in six hours. This website exists because that review asked for one.
- v0.40, the largest release so far, and a jump in the version numbering.
- Codex joins as the second plan.
- An inventory of every probe is taken, and a regression suite enters the gate of every lot.
- Codex is paused by the author's decision.
How to read itTime runs from left to right, one bar per week. Above the axis, the commits of that week. Below it, the tickets created each month and, inside them, the rejections. The coloured bands are the three eras, the notches are the release tags, and the numbered dots are the ten milestones listed underneath.
How to read itTime runs from top to bottom, one row per week, grouped by era. The bar on each row is the commits of that week, with the number beside it. On the right, one bar per month is the tickets created that month, and its darker part the rejections. The dashes on the vertical line are the release tags; the numbered circles are the ten milestones listed underneath.
Sourcegit log of the development branch, the history of every Jira ticket, the changelog of the repository · snapshot of 5 November 2026
The turning point
16 July, minute by minute
The second era starts on a single afternoon. This is the sequence as Jira and git recorded it.
- 13:49
The epics are created, all in the same minute.
8 epics
- 13:50
The next ticket is not a task. It is titled “LEGGIMI” (read me) and it explains to the agents how the board is meant to be used.
- 13:50–13:53
The backlog is poured in: dozens of tickets in a handful of minutes.
29 tickets
- 16:15
The author writes his first tickets by hand. They have a title and nothing else.
- evening
By the evening the first sprint is under way: the count beside is the tickets taken in hand before midnight. The first one is closed the next morning.
23 tickets taken in hand that day
Born that day
- Jira — the board where every piece of work becomes a ticket.
- CLAUDE.md — the standing instructions every session reads first.
- ORCHESTRAZIONE.md — how work is split into lots and delegated.
- The roster — four agents, one role each.
- Sprint 1 — opened and worked the same day.
No document says why the switch happened that day; the reason is not written down anywhere, and this page does not invent one. What the record shows is the sequence. On the two days before, playtests produced dozens of reports at once. And the markdown briefs had stopped talking to each other: three days later one of them still notes, about two others, R1/R2 non risultano implementati
(R1/R2 do not appear to be implemented).
How to read itRead the column from top to bottom: each row is a moment of 16 July 2026, with the time on the left and what was created in Jira at that time on the right. The list beside it is what else came into existence the same day.
Sourcecreation time of each Jira ticket, git log of that day, the briefs kept in the repository · snapshot of 5 November 2026
The organisation
The chain of command
One person decides; everything else is a relay. A ticket goes down as a brief, comes back up as a diff, and reaches the author as a comment of at most 900 characters. His answer is two letters.
- one ticket
- gate verdict
The trip of one ticket
- The author writes a ticket in Jira, or approves one written for him, and puts it in the sprint.
- The first bridge reads the sprint once, groups the tickets by the files they touch, and writes one closed brief per lot: the full text of the ticket, the files, what must not be touched.
- A builder, a Claude agent or a Codex one, works inside that brief only. It never reads Jira and never commits. It returns a diff and a short report.
- The gate: a second model, one that did not write the code, checks the real diff against the ticket line by line and hands a verdict to the first bridge. A report is not a proof.
- The first bridge commits the lot and writes the Jira comment: at most 900 characters, opening with what was not tested.
- The author tries it on a real device and answers ok or ko. A ko sends the ticket back to the queue, and his comment becomes the new requirement.
How to read itRead it from left to right and back. Each arrow carries the name of what travels on it; the moving dot is one ticket making the whole trip. The numbered list underneath is the same trip in words.
Sourcethe orchestration rules and the workflow files of the repository · snapshot of 5 November 2026
The pace
The sprints
A sprint here is a batch of tickets the author moves onto the board. A ticket that comes back from review is counted as a rejection, and the rejections are published with everything else.
- tickets that went through the sprint
- of which sent back from review while the sprint was open
A new sprint every 4.6 days on average
From 18 September the darker part almost disappears: the three sprints that follow count 0, 0 and 1 tickets sent back. The author's own explanation: those sprints were multiplayer work only, and the work moved on to the next thing rather than stopping to mark tickets as done. Read those three bars with that in mind.
How to read itOne bar per sprint, in order. The height is the number of tickets that went through that sprint; the darker part is how many of them were sent back from review at least once while that sprint was open. A ticket that crosses two sprints is counted in both.
Sourcethe sprints of the Jira board and the status history of every ticket · snapshot of 5 November 2026
The authors
Who made what
No single tool made this game. Each kind of output has its own author, and where a count exists it is shown next to it.
| Output | Made by | In numbers |
|---|---|---|
| Code | Claude models, each signing its own commits; since September Codex sol on tightly scoped lots |
1,664 commits signed by a model and 157 by hand. On the Codex side: 281 lots, 188 gates, 138 reviews, 60 consultations, 31 inquiries. |
| Sprites and images | Codex image generation: first sol, from 8 September Astra for every sprite. PixelLab for two weeks in July, then retired. Nano Banana on test benches only |
421 PNG in the game, 664 raw files kept beside them. Since 22 July every generation is two tickets joined by a Blocks link, and only the author closes the second: 197 tickets carry that link. |
| Music | Suno | 12 tracks, levelled at −16 dB RMS. Where a loop is cut, the point is chosen by measuring the jump at the seam: 0.44 dB for the chosen cut, against 3.76 dB for the longest one. |
| Sound effects | ElevenLabs, through its MCP server | 35 effects, brought to −20 dB RMS and measured by a script rather than judged by ear. |
| Translations | Claude | 8 languages, 2,708 lines in the translation files. |
| Tester notices | WhatsApp through an MCP server, plus Telegram | At every release the closed-beta testers are told one by one, from the same spreadsheet that holds the list. |
| Tickets | Jira: the Atlassian MCP server for a single write, scripts for everything else | Reading one ticket through the server cost 9,400 characters, and one with 16 comments 53,111 bytes. A script that filters first lets only the text in. |
Commits by signature
On licences: the commercial licence of a generated asset follows the plan that was active on the day it was generated, not the plan active today. The provenance inventory writes not determined
wherever the proof is missing: 105 of the 421 PNG have a source named file by file.
How to read itOne row per kind of output. The middle column says who made it; the right one gives the counts, or the measure that decided a choice. The bars show how the signed commits split among the models.
Sourcethe commit trailers in git, the register of the Codex runs, the provenance inventory of the assets and the changelog · snapshot of 5 November 2026
Testing
How it gets tested
Nothing reaches the author on trust. Every lot goes through the same seven steps, in the same order, and the comment that closes it opens with what was not tested.
349 probes, counted one by one
- 158 alive: they run by themselves and pass
- 155 not automatic: they need a person looking
- 34 broken: they no longer run
- 2 obsolete: what they tested is gone
The seven steps before a ticket comes back
- The real diff. What actually changed in the files, not what the agent's report says changed.
- Compile check. The scripts that were touched must load. It sees neither warnings nor shaders, and the steps below exist because of that.
- Regression suite. 23 probes plus the compile check and two smoke runs: 538 seconds on 8 October 2026. One failure and the lot does not go on.
- A test shot someone looked at. Taken from the game's own viewport and opened as an image: a file that exists is not a file that was seen.
- A comment of 900 characters at most. Its first line says what was not tested.
- The author, on a real device. The only step no agent can do.
- ok or ko. Two letters. A ko sends the ticket back to the queue, and the comment that comes with it becomes the new requirement.
Five false greens
Five times a check said yes with the defect still there. Each one became a written rule.
The shader that would not compile
The check saidThe test shot showed natural colours.
What was thereThe shader was broken and the engine had quietly fallen back to its default material: the colour swap was not being applied at all.
1 August 2026
The test shot that had died
The check saidThe compile check passed, the runner printed exit 0, the images were in the folder.
What was thereA renamed function had killed the script that takes the shots. The images were the ones left by the run before.
12 August 2026 · ticket SU-382
The exit code that meant nothing
The check saidThe watcher exited with 0, the code agreed for «approved».
What was thereA network error. The last line of its own log still said the review was in progress.
26 August 2026
The GET that proved nothing about the POST
The check saidA GET to the address answered ok, and a commit declared the queue working.
What was thereThe queue had never delivered a single file: on a POST the server answered with a redirect, and the game followed it with the wrong method.
17 August 2026
The warning the compile check could not see
The check saidThe compile check exited 0 and the ticket went to review.
What was thereA warning that the editor treats as an error: the scene would not open.
13 August 2026
How to read itThe list is the path of every lot, top to bottom. The ring counts every probe script in the repository by what it is today, not by what it was written for. The five cards are cases, each with its date.
Sourcethe inventory of the probes, the regression suite and the memory files of the project · snapshot of 5 November 2026
The costs
The economy of tokens
The work runs on two flat-rate plans, so the limit is not money: it is a usage window that fills up. These are the measurements the rules came from.
What an average lot costs, by role
These are estimates, not bills. Dollar equivalents at list prices, measured on 242 launches between 15 and 29 August 2026; the work itself runs on a subscription. In raw tokens an architect lot is 14.5 million and a developer lot about 11 million. Starting any agent costs 40–46 thousand tokens before it has done anything.
98% is context read again
- 98% context read again
- 2% new work
Of the 6.13 billion tokens of two measured weeks, 98% was not work: it was the conversation being read again at every request. This is why files are not read whole and reports have a ceiling.
76% is spent by the session that orchestrates
- 76% orchestrating session
- 24% agents
Between 4 and 7 September 2026, 942 million tokens out of 1,235 went to the orchestrating session, not to the agents it launched. Hence a threshold: at 250 thousand tokens of context the session closes what is open and hands over to a new one.
The window, and the 90% rule
Each plan has a usage window. Before spending, a script reads how full it is. At 90% no new agent is launched: the ones in flight finish, their tickets get closed, and the session writes down where it stopped.
Two incidents, the same mistake
22 September 2026. 16 search agents launched together: the window went from 2% to 63% in 25 minutes.
8 October 2026. 8 readers in parallel, to collect the material for this very page: from 0% to 62% in 13 minutes. The rule already existed.
Two plans side by side
Claude
The first bridge: it splits the work, decides, verifies, closes, and writes to the tracker. Its roster builds.
Codex
A second roster from 4 September 2026: builders, the gate on every lot, the images. Stopped by the author on 8 October 2026; only the generation of sprites remains.
How to read itThe bars compare the roles with each other, in estimated dollars per average lot. The two strips split one total into its two parts. On the gauge the dashed line is the threshold and the two marked stretches are how far each incident went, and how fast.
Sourcethe orchestration rules of the repository, with the date of each measurement, and the memory file on the two incidents · snapshot of 5 November 2026
The lessons
Rules born from failures
Every mistake made once becomes a file: one fact, why it matters, how to apply it. The agents get the index of those files at the start of every session. There are 258 of them.
Memories written, by month
Twelve of them, word for word
The rules are written in Italian, in the first person, by the model that made the mistake. Here they are translated; the Italian version of this page quotes them to the letter.
In Jira comments Ivan writes only ok/ko and what is wrong; the long comments are mine, the connector posts them under his account
a test shot that cannot reproduce the defect is not a proof, it is a tautology
A rejection about something I cannot perceive (a sound, a gait) is closed by translating Ivan's word into ONE measurement that answers his question, not mine
An endpoint that answers ok to a GET may deliver nothing on a POST
A watcher job that exits 0 does not mean «condition reached»: check the fact, not the exit code
A test shot that dies halfway leaves the images of the previous run in the folder — they look like a successful check; always look at the timestamp and the log
A shader that does not compile cannot be seen — Godot falls back to the default material and the test shot looks correct
A single permission prompt freezes ALL the parallel agents, not only the one that asked: in an unattended sprint it is worth hours of standstill
A workflow with 10+ Fable agents in parallel on huge files takes the five-hour window from 2% to 63% in 25 minutes
an eyeball estimate of length, in Italian with numbers and paths, is systematically 5-25% short
The Atlassian connector ignores the field filter and always sends the whole description plus every comment; reads go through tools/jira_leggi.sh
a line that would already be true BEFORE running the command is an announcement, and gets deleted.
How to read itEach bar is a month and counts the files born in it. Each quote carries the file it comes from and the day the rule was written.
Sourcethe memory folder of the project and the instructions file of the repository · snapshot of 5 November 2026
The game
The architecture of the game
One diagram for what all of this builds: a multiplayer game with no server of its own, where one player's device is the authority.
How to read itOn the left, what runs on every device. In the middle, who decides: one device is the host and the others follow it through a relay. On the right, the outside services the game calls.
Sourcethe project file of the game, its multiplayer design document and the export presets · snapshot of 5 November 2026
The tools
The MCP fabric
Claude Code sits in the middle; each server is a spoke that reaches something outside the repository. A spoke is not always the best road: where a plain script did better, the spoke says so.
- the script won here
- retired
- Atlassiansingle comments and status changes on JiraReading moved to a script: the server cannot narrow the fields, so asking for a title brought back the whole description and every comment.
- ElevenLabssound effects from a written promptOne file named .mp3 was raw stereo audio with no header: every result is measured before it is used.
- Codexa second opinion inside the conversationLots, gates and reviews start from a script as a separate process, so their output stays out of Claude's context and only a short result is read.
- WhatsAppthe release notices to the testersHere the server won: it replaced driving the web client inside a browser.
- Chromethe store consoles and the checks on the web buildThe screenshots of this very page come from a script instead: animations have to run in real time to be photographed.
- Nano Bananaimage generation, on test benches onlyIt never became the production road for the sprites.
- PixelLabpixel-art generation, two weeks in JulyRetired: since the end of July sprites are generated in one place only.
How to read itEach spoke is one server. The first line says what travels through it. The second, where there is one, says what was learned: a spoke marked as beaten by a script is still in use, but for less than it was installed for.
Sourcethe MCP configuration of the project and the orchestration rules of the repository · snapshot of 5 November 2026
To take away
What to replicate tomorrow morning
A minimum kit, in six items. None of them needs this project.
- An instructions file the agents read at every session, kept short enough to be read whole.
- One file per phase of the cycle — tickets, sprint, testing, release — opened only when that phase begins.
- A written procedure for each critical point: before closing a ticket, when one comes back rejected, before a release.
- The tracker read through scripts that return only the text that is needed, not through a general connector.
- A meter of the usage window, read before spending, with a threshold at which work stops.
- One memory file per trap already paid for: the fact, why it matters, how to apply it.
Still open
What does not add up yet
Four things that are true today.
- Part of the backend is still on Apps Script. The function meant to replace it has been written and deployed since 18 September 2026; the switch has not been made.
- 79 tickets out of 1,140 are not closed.
- The test log stops on 3 November 2026. Since then the results go into the ticket comments, where the author reads them, and the log has not been kept.
- The regression suite has no room left. It takes 538 seconds against a ceiling of 600: the next probe that enters pushes an old one out.