Seven Hours, Three Check-Ins, One Working Product

In August I ran an experiment I'd been putting off. I pointed a coding agent at a full functional clone of a well-known paid task manager — the kind with keyboard shortcuts power users have muscle memory for, and the genuinely awkward recurring-schedule logic underneath — gave it the target, gave it permission to keep going until the thing actually worked, and went to bed.

It ran for about seven and three-quarter hours. I checked in three times.

By morning there was a working two-service application: a documented API with a real database behind it, a full front end, and passing tests at three levels. Not a mockup. Not "here's the scaffolding, now a developer takes over." A thing you could open and use.

The wrong lesson from this story is expensive, so let me be precise about what it does and doesn't mean.

This was a capability test, not a product

I was not building something to ship or hand to anyone else. I was buying a number — an honest measurement of how far one unattended overnight session goes on a build that is production-shaped rather than demo-shaped. The output stayed internal. The point was the measurement.

I chose a clone of an existing commercial app deliberately, and for one boring reason: the requirements were already settled. Somebody else had spent years deciding what the buttons do. No stakeholder debates, no half-finished specification, no "actually, can it also do time tracking." Every ambiguity that normally eats a build had been resolved before I started.

That is the cleanest possible test condition, and I'll come back to why it matters more than the seven and three-quarter hours does.

Research came before code

The first thing the session did was not write code. It ran a separate research pass over the target's published documentation and interaction model — how the app actually behaves, in its own words, rather than how a competent developer would assume it behaves.

That pass caught several non-obvious behavioural details that were later confirmed to matter. Which is the whole argument for doing it. An agent that starts typing immediately produces something plausible very fast, and plausible is the expensive failure mode: it looks finished, it passes a casual look, and the wrongness surfaces weeks later in the one workflow nobody tested. Twenty minutes of reading the manual first removed a category of that.

If you take one process detail from this post, take that one. Separate the "what does this thing actually do" pass from the "build it" pass, and make the first one produce written findings the second one has to work from.

What "production-shaped" actually meant

The word people abuse here is "built." An agent can produce something that looks like a task manager in twenty minutes. A screenshot is not a system.

Here is what was on the machine in the morning:

• A real database with migrations, not an in-memory array that forgets everything when the process restarts.
• A documented REST API — the interface written down, not inferred by reading the code.
• Three layers of test coverage: unit tests, integration tests, and browser-driven end-to-end tests that actually click things.
• A front end implementing the target's layout, its keyboard shortcuts, and its scheduling and repetition rules — the last of which is where these apps hide their real complexity. Repeating tasks are a swamp. Every date edge case you can think of lives in there.

The tests are the part that matters, and they are the reason this worked at all. The agent was not told to write code. It was told to reach a verified working state. Those are different instructions and they produce different nights. One ends with a plan and a confident summary; the other ends with a passing suite and a list of things that broke and got fixed at 3am while I was asleep.

By the end of the session the backend end-to-end suite stood at 42 passing tests, and it had grown steadily through the night as each new feature arrived with its own coverage.

Two things I asked for mid-session

Three check-ins across a night is not much supervision, but it isn't zero, and what I asked for during them is instructive.

First: a second authentication system, separate from the normal session login, built specifically so that AI agents could operate the app programmatically. API keys, not human login flows. I've written before about giving agents their own scoped credentials instead of your passwords, and this is that principle arriving as a design requirement on day one rather than a retrofit two years later. That addition alone carried 15 of those 42 tests; the original 27 were everything else.

Second: an import wizard, so an existing user's historical data from the original app could actually come across. That is the difference between a clone and a replacement. A tool you can't move your existing life into is a toy.

Both got built inside the same session.

The friction was external, not internal

Here's the part I didn't predict.

Nothing inside the build became the bottleneck. Not the database, not the scheduling logic, not the browser tests. The agent worked through those.

The wall was someone else's file format. The original app's export files — the ones it hands you when you ask for your own data back — have no published schema. There is no official document describing what is inside them. The only reliable knowledge is what the user community has reverse-engineered and written up over the years.

So the importer got built on folklore. It works, but it works the way a locksmith works from a key someone traced onto a napkin, not from the manufacturer's drawing.

That produced the decision I like most out of the whole night: three supported import formats, in decreasing order of fidelity, each one carrying an explicit written warning about the interaction detail it cannot fully recover. Not a silent lossy import that quietly drops your recurrence rules and lets you find out three weeks later. A stated limit, up front, per format.

Most teams don't have that instinct, and it generalises well past importers. When your system can't do something perfectly, say so at the boundary. Silent degradation is how you lose trust you never get back.

The two conditions, and neither one is free

So: does an overnight session now beat a conventional team estimate?

Under two conditions. Both of them are real work, and neither is done by the agent.

One: the requirements have to be genuinely settled. My clone had a finished specification because a company spent years writing it. Your internal tool does not. If three people in your business still disagree about what the tool should do, an agent will build all three versions confidently and none of them correctly, faster than any team could. Speed of construction doesn't help while the blueprint is still an argument.

Two: verification has to be built in, not bolted on. The agent has to be authorized and required to iterate until the tests pass — to act as its own quality gate. Ask an agent for a plan and it will hand you a beautiful plan. Ask it for a passing test suite and it has to actually be right. That authorization is a governance decision you make before the session starts, not a technical setting you flip afterwards.

Where both conditions hold, the build-versus-buy arithmetic on internal tools has genuinely moved — this is one data point dropped onto the build-vs-buy framework I've written about before, not a rewrite of it. Where they don't hold, nothing has changed at all, and the overnight session just gets you to the wrong answer before breakfast. The first condition — settling what the thing should actually do — is the one people skip, and the design gate I now run before any code exists precisely because of that.

The bottom line

The scarce resource stopped being construction. For a well-specified internal tool, building it is now close to free and close to overnight. What is scarce is knowing exactly what you want, and insisting the machine prove its work instead of describe it.

That's a management problem wearing an engineering costume.

I pointed an agent at a production-shaped build, went to bed, and woke up to a working product with passing tests. For companies in Dubai and across the UAE, this lands on a very specific pile: the finance spreadsheet everyone hates, the procurement approval that lives in a messaging thread, the customer-support tracker nobody could ever justify months of developer time for. That justification has changed; the specification hasn't, and somebody still has to sit down and decide what the thing does.

If you've been deferring an internal tool for years, or you want to know which of your current subscriptions are now genuinely worth replacing and which absolutely aren't, that's the kind of question I map out in a single consulting day. Book a consulting day or send me an inquiry first if you'd rather talk before booking.