adlk.ioI'm a prime millennial, so the first game I properly played was Super Mario Land on the classic Game Boy. The game is a year younger than I am, but I grew up on the countryside where the clocks turned a bit slower, so it stayed new to me for quite a while.
What I remember best is that the screen only scrolls to the right. You can't walk back. Something shows up, you jump, and within a second you know if that was a good idea. Then the next thing shows up. Nobody ever called that stressful. It was the most fun you could have on four AA batteries.
My working days play like that now. Thursday this week was a good one, so here it is.
Thursday
At the start of the week a customer asked if Franz Mail can print. It couldn't.
Franz Mail is an extremely young mail client. It's stripped to the minimum feature set, and it brings a lot of AI and algorithmic productivity features, some of which I haven't seen in any other mail client, e.g. sender intelligence, or identifying the ideal time to send a message, based on reciprocity among other things. At the same time it lacks a lot of what people expect from a regular mail client. I keep a mental list of those missing things. Printing was on it, as I expected the demand to come at some point. A mental list has no deadlines though. A concrete request is the moment where that demand materializes, and that's how most items leave my list.
So on Thursday morning printing was one of four Claude Code sessions at work next to each other. They ranged from a larger feature to smaller bugfixes and quality of life improvements. Codex ran next to them all day. Those sessions review what the others produce, so I don't count them as work streams, and a few were only there to judge what another agent was about to do.
Four is about the top for me. I try to limit myself to three or four parallel sessions, as that's the mental capacity I have most of the time. Larger features often need more attention, and then I either run one work stream only or leave the others stale until I have the capacity to pick them up again. Sometimes less is more, and it really depends on the complexity of what I'm working on.
The first printing commit is from 08:49. By 10:06, ⌘P printed whatever page was in front and Franz Mail printed the open conversation. Then came a strict validation and verification process. The agent builds end-to-end tests for the feature and autonomously tests it end to end, with the scenarios that matter in mind. After that comes the actual human UAT (user acceptance testing), and only then it's really finished. That was at 11:04. Printing is self-contained and had been through all of that, so it could go into the release that was due the same day.
In between, two things showed up that weren't on any list. A sync log turned out to be writing a quarter of a gigabyte a day. That was fixed at 08:59. And the app could freeze while mail was syncing. That one got its own debug session, which came back with three database lookups that scanned a whole table where they should have used an index. Fixed and verified by 10:57. Both were found and fixed before the release went out that evening.
My part in all of this was directing: saying what I want, reading what comes back and saying what's wrong with it, four times in parallel.
At 12:05 I answered Vera, the marketing agent from part five. Our paid ads experiment doesn't add up yet, so the campaigns are paused, and her weekly packet proposed two things: correct a comparison page that had gone out of date, and define properly how we measure before any money goes back in. I typed #1 approved #2 approved into Telegram. The page was corrected in English, German and French and went live the same day. The measurement draft was waiting for me afterwards.
And Franz 6.8.0 went out as a stable release that same Thursday, with printing in it. A question from the start of the week, answered in Thursday's release.
The spot I couldn't get past
Compare that with a feeling I used to have regularly. I'd be debugging one thing for days, and it took me ages to figure out what the actual issue was. What I remember most are the evenings, closing the laptop and feeling I hadn't done anything productive all day.
In the game that's the one spot in a level you can't get past. You don't even lose lives. You just stop moving, and a jump and run where you stop moving isn't much of a game.
Thursday's freeze is the kind of bug that used to cost me those days. The app was frozen while one process took more than 1,000 seconds, so over 16 minutes. This time my part was short. I explained the issue, gave my hypothesis and pointed the agent towards the debugging artifacts, and with that my work was done until the fix came back for me to check. The digging was the agent's. It came back with the three lookups, and my hypothesis turned out to be right.
That's also my answer to why any of this needs AI at all. Tagging a release or running a test suite is a script, and I wouldn't call it anything else. Reading through hundreds of queries to find the three that hang an app is a judgment call, and that kind of judgment call is what used to eat my days. Even small things like drafting a changelog like the one for 6.8.0 have become easily possible, and before that I wouldn't have had changelogs this engaging and informative.
I still have evenings where I'm mentally drained, which is fair for any work where you need to think. But I hardly ever have the feeling anymore that a whole day produced nothing.
With five people it never did
I've run Franz with up to five people, and no day looked like that Thursday. Nobody was slacking. A team needs a rhythm: a request becomes a ticket, the ticket gets a priority, the priority gets a slot. If I had jumped at everything that came in with five people behind me, I'd have pulled all of them off whatever they were doing, and that's a terrible way to run a team. So reacting was something I had to ration.
I ration it a lot less today. I still pick what's worth a reaction, and a single mail rarely is on its own. "Reactive" is what founders get told not to be, and I'd argue it depends on what a reaction costs. If reacting derails a sprint, don't. If it means one more session next to the ones that are already running, it's a cheap way of listening to customers.
Lean startup, on steroids
The Lean Startup was the book everybody in startups had read back in the days. Build, measure, learn, and the faster you get around that loop, the more you learn. I never had a problem with the theory. The loop was expensive to run, that's all.
Thursday closed four of them: printing, the freeze, the log and the comparison page. Each one started with something arriving, then I decided, then it got built and checked, and it was out the same day I picked it up.
I'd call it the lean startup from back in the days, on steroids. My decision in each loop is as big as it ever was. Everything around the decision got small.
And not everything in the level is an obstacle. The printing request was a coin. So is a conversation that sparks an idea which perfectly fits what Franz should be. I can pick that up on the day it happens, while I still remember why it was exciting, and quite often there's still room left in the day afterwards.
To be fair, not every loop is a morning. One of the major new features in Franz 6.8.0 is the magic bar, and that one was massive. It took weeks to get from the initial concept to a sketch, to a prototype, to the first user testing and the refinements after that. So no, not all work gets done in an hour or two. But earlier a feature of that size would have pulled me away from all the other work for a much longer period, quite possibly months. This time the small loops kept closing next to it.
Truth be told, it's always about pacing. It doesn't matter if you're doing a middle distance triathlon or a sprint, it comes down to what the goal is. Sometimes the goal is a simple hardening release with nothing but bug fixes and minor improvements. Sometimes it's preparing the app for what's to come. Stuffing everything into a release just because it's possible is never the answer. Pacing is, and pacing is a race strategy.
A jump and run works the same way. You sprint where the way is clear, and you slow down before a tricky jump. If you hold down the run button for the whole level you end up in a hole, and if you never touch it you run out of time. And you don't need every coin to reach the flag.
Friday
Friday looked nothing like Thursday, which is sort of the point.
A support mail showed that the new pricing plans have no entitlements in the old app. For people on a new plan who still run an old version, the old app doesn't unlock what's in their plan until they update, as it has never heard of those plans. There were two ways out: ship an API update so old apps understand the new plans, or write to the few users it affects. I investigated if the API update was worth it. It wasn't. It would only matter for a few hours, a day or two at the longest, until the new release lands for the affected users, and then the problem fixes itself. So a few people get a mail from me asking them to update their client.
A good part of the day went into getting 6.8.0 into the Mac App Store. The App Store is slowly picking up as an additional growth and monetization route for Franz, so keeping it on par with the version on the website is worth the effort. Release work is the kind I do semi-hands-on at my own machine. I don't hand it to the agents on the Mac mini. The agent prepares, and I stay close.
And Friday isn't done as I write this. Right now we're fixing a bug with the transcription of WhatsApp voice messages, and while we're in there we're improving the assistant surface, so that discovering and transcribing voice messages gets easier in multiple languages. That one also surfaced through a support request, which came in on Thursday.
Two days: a feature, a freeze, a log, a marketing decision, a pricing edge case, a store release and a transcription bug. And a blog post, apparently.
What the player still does
Speed is only fun when the jumps count, so a few rules sit under all of this. In part three I promised the ones that stop an agent from cheating on tests. The agent that repairs failing tests overnight has to reproduce the failure first. Then it has to classify it as a bug in the test or a real bug in the app, and say which in the pull request. It's told to never weaken an assertion, add arbitrary sleeps, or skip a test to go green. Above five failing specs it doesn't start at all, as that many failures usually share one cause. The model that fixes comes from a different family than the one that built. And it stops at the pull request. It doesn't merge.
The figure from part one still describes the whole setup, Thursday included.
What stays with me is spotting what's coming, picking the jump and knowing what Franz should be. No agent decided that a young mail client needs printing this week. I did, as the demand I'd been expecting had shown up.
If your team wants to try this
Start with the part you can copy tomorrow. It doesn't need a Mac mini or agents with job titles. It needs one developer who runs two sessions where there used to be one, and who spends the time that frees up on reading what comes back.
Then count your loops. How many things arrived this week, got a decision, got built, got checked and went out? And for the ones that didn't make it, which step was the slow one?
None of this is about the same work with fewer people. A team of five that closes loops like this gets to say yes a lot sooner, whenever a yes is the right call.
The last part of this series is the bill for all of it, line by line.
If you're a founder working out how much of this you can hand over, and where the line should sit, that's the work I do with teams. Let's talk.
