On the first day of the European Hackathon League final in Munich, the organisers put a speaker on stage before we started building: Thomas Dohmke, the former CEO of GitHub, now founder of Entire. I took notes. This is what he said, in my words, and then what I think about it.
1. We made the loop small. Now it needs to be big.
For twenty years the whole discipline of software was about shrinking the loop: agile, short sprints, tests, small pull requests. The reason is human. You can only hold a train of thought for so long before a message pulls you out of it, and twenty minutes later it's gone.
Agents change the maths. One agent writes far more code than a person, and the code piles up. He showed numbers from Linear: teams using coding agents went from about 10 pull requests a week to 57, and each one got about three times bigger.
2. Nobody reviews that much code
His description of code review was the funniest and most uncomfortable part. A pull request is like those spot-the-differences puzzles, except you only see the right-hand picture and nobody tells you how many mistakes there are. If you know the author, you skim. If you don't, you nitpick until you've found twenty things, feel you've been fair, and stop. "Nobody ever read all the lines and found all the bugs."
So what happens? More and more AI changes get merged without a human looking, and his own open-source project has more than 200 open pull requests. The answer can't be "review harder". It has to be more automation on the review side, the same way we already automated the writing.
3. The Ralph loop
Agents fail, he said, and not rarely. Give one a big task and it wanders off the path. His answer was a trick named after Ralph Wiggum from The Simpsons: give the agent the same prompt again and again. The prompt doesn't change but the context does, because the files now contain its own earlier attempt, and with each pass the result tends to improve. Add an external check that says "good" or "not yet", and you have a loop that keeps going until it's right.
The goal of the loop is to be as big as you can make it. The dream is to hand over a task at noon and come back to a result. The realistic version is to keep the agent busy while you're in a meeting, at lunch or asleep. He mentioned founders who set an hourly alarm at night to check that the agent is still running, because "if the agent isn't running, my factory is standing still".
And the budget is real. At a hackathon you have a token allowance and a prize that is smaller than what an unlimited run would cost. A business has the same maths with a bigger number.
4. The editor becomes the fallback
This is the bit I keep thinking about. The GitHub home page shows files and folders and, if you scroll, the README. It hasn't changed since 2008. But if an agent installs the dependencies and reads the code, who is that page for? Not for me.
Cursor, a company built by forking an editor, sold for a huge amount, and his point was that even they now treat the editor as the fallback. Where we really work now is a chat window, much like WhatsApp or Slack, with a sidebar you read when you have time. The editor you open maybe 5% of the time, where it used to be 95%.
5. The second most important artifact
If the chat is the interface, then the conversation is the second most important thing a project produces, after the code. Code is the only thing that actually runs on the machine. But the code was written from the conversation: the prompts, the dead ends, which decision won.
That is what Entire stores. Every time you or your agent makes a commit, it saves the session next to it, as a checkpoint, like the flag halfway through a Mario level you can return to. A few details I liked:
- The sessions are stored inside git, as objects, not as markdown files in a docs folder. If they were files, the agent would read them all and get confused about what you decided versus what you only explored.
- Secrets are stripped before anything is stored, and the command-line tool is open source (MIT).
- Your agent can search past sessions of the project, yours and your team's, so it stops repeating the same mistakes.
- It doesn't tie you to a tool: when your credits run out in one agent, resume in another.
His demo was a 3D racing game starring the company's mascot, built from his phone over a weekend, with the whole thread of prompts viewable afterwards.
What I took away
I felt the review problem this week. At the hackathon I could write more than I could read. Agents produce the code, but the part that keeps me honest is somebody asking why. That is why I built Dixi around the reasoning instead of just the answer, and it is the same idea at a smaller scale: save the reasoning with the result.
A session is a record, and records leak. The hackathon required Entire, so I used it on Dixi. The practical lesson: look at a session before it leaves your machine. I found an API key sitting in a transcript, took it out before pushing, and rotated it. His advice was simple: put keys in an environment file and never paste them into the chat.
Use the loop on yourself. Your agent gets better when it has context and a check. So do you. Give the work a verifiable finish line, then let it run.
He ended on the idea I liked most. The job is shifting, from "who converts an idea into code fastest" to "who can direct many agents well", but we are still very early. People have been building houses for twenty thousand years and still get the outlet on the wrong side of the wall. Software is a thin sliver of that timeline. And the best predictor of a good result, he said, is that you're having fun building it.
These are my notes from the talk, written from memory and a transcript. The numbers and quotes are his, as he presented them, and I haven't verified them independently.