At 23:26 the previous evening I got a message from a client. They had not filed an issue in the system, they had written to me: something was stuck, it was blocking their process, and it was urgent. We work together on a national digital campaign with a lot of automation and admin functionality. On the client side, more than ten administrators use it daily, so a blocking bug affects a lot of people immediately.
Within five minutes, half asleep, I took three screenshots of what they had sent, handed them to Claude to process and file as a ticket in Linear. By the time I had read the finished ticket, I was asleep again. The whole thing took five minutes.
In the morning I turned on the machine and gave Claude Code a single instruction: open this issue, investigate it, reproduce it. By the time the coffee had brewed, the bug was reproduced and tested. It turned out to be a rare edge case rather than a systemic fault.
It is easy to read this as the founder being up at night, and that being the secret. The opposite is true, and that is the only interesting lesson in the whole thing.
Speed is not the achievement here
If this had depended on me being awake and sharp at night, it would not be a good story but a warning sign. Speed that rests on one person is not repeatable. Next time I will be asleep, or ill, or simply will not notice the message. Five half-asleep minutes were enough precisely because the process did not depend on whether I was awake. I only started it. I did not do most of the work, and not at that hour.
Where the time actually goes
Take the classic path from a bug report arriving at night to a reproduced bug. The report comes in. In the morning someone looks at it and decides whose it is. It gets assigned to whoever has capacity. The developer reads the chat and extracts what the bug actually is. And only then does the substantive part begin: the investigation and the reproduction.
Look at where the time goes in that chain and it turns out the substantive work is not the slow part. Response time is consumed by the dead time between handoffs — the waiting for someone to look, and the translation of a loose message into a usable task. The actual investigation is short by comparison.
In this case those two stretches were eliminated. At night the loose message became a structured ticket straight away, so the translation happened immediately rather than in the morning. And in the morning the investigation and testing ran without human time, so the waiting did not count either. AI did not replace the thinking. It replaced the dead time between handoffs.
The hidden hero is boring discipline
There is a quiet precondition to the morning working out. What got written at night was not a note saying I would look at it tomorrow, but a proper, traceable ticket: what the bug is, where it shows up, what the client sent. Claude Code could get started in the morning because it had been handed a real unit of work at night, not a three-word reminder.
That part transfers anywhere, and it is far more boring than an AI story sounds. The precondition for AI speed is input discipline — that what enters the system is a structured, unambiguous unit of work rather than a sentence tossed over the wall. Skip it and AI will quickly produce a confident but wrong ticket, with the error only surfacing later during reproduction, if at all.
What this would be without the groundwork
It is worth naming what made this possible, otherwise the whole thing is just boasting. The codebase is prepared for an AI agent to find its way around. There are tests against which a reproduction can be verified. And Linear is wired in, so the ticket did not land in a separate system. Without that, three screenshots would still have become a ticket, but nothing could have been built on it.
And both ends of the chain deliberately stayed human. I decided this was genuinely urgent, and in the morning I reviewed whether the reproduced bug was really what it appeared to be. AI carried the middle: the translation and the investigation, at the points where a person would only have been waiting and typing anyway.
The lesson
So the end of the story is not that we are fast. It is that my night self and my morning self both did very little, and that is exactly the point. Response time stopped depending on whether one person happens to be awake, available and sharp enough. An operation becomes genuinely fast when it dares to ask itself where in its chain an awake human became the bottleneck, and whether that person actually adds something there or is only waiting and translating.
