Someone has to read it in the morning
In a quote I read it said that an agent could run a certain number of nights per week. Development that continues while the team sleeps. The result waits for them when they arrive.
That is not made up. It is genuine practice today. And the reason it has to run through an API rather than personal subscriptions is also correct: a subscription licence may not be scheduled or run in parallel. That part of the reasoning was well informed.
What was written nowhere was who reads the result in the morning.
What actually happens in a well-run setup
The agent does not work blind. It runs against the test suite, against linters and against the build, iterating until everything passes. That is machine verification before any human sees anything.
The result then lands as a proposal on its own branch, outside what is in production. Nothing deploys by itself.
And then comes the review. A human reads, understands and approves. That is the real gate. It sits in the morning.
The chain is therefore: automated run, automated verification, human review, and only after that a merge.
Why the work moves rather than disappears
The night shift does not remove the developer's work. It changes what is in it.
Less time goes into writing and more into reading. And reviewing code you did not write yourself goes slower than reviewing your own, because you first have to reconstruct what it is trying to do before you can judge whether it does it correctly.
That is not a problem in itself. It is a perfectly reasonable division of labour, and for many teams a better one.
But it has a consequence that rarely shows in a quote: if the automation makes the supplier faster, it should be visible in the hours. If it is not, the buyer pays twice. Once for the tool meant to produce the efficiency, and once for the hours the efficiency was meant to remove.
The weak setup looks identical
This is where the real risk sits, and it is not about money.
In a weak setup the morning review is a rubber stamp. Test coverage is thin, whoever reviews does not have time, and the volume is too large for anyone to understand it. Then you get a lot of code quickly, and the technical debt builds at the same rate.
From the outside it looks identical to a well-run setup. Same reporting, same delivery pace, same satisfied project manager. The difference only shows when something breaks in production, and by then it has been building for months.
A buyer cannot possibly judge that from the outside. Which is precisely why the question has to be asked in advance.
Ask about the mechanism, not the ambition
Everyone answers yes to whether they review. Nobody answers no. The question therefore has to be about how it is done.
What is required for something to count as finished, and who approves it? Can anything reach production without a named person saying yes? What test coverage exists in the new codebase, and is it built up before or during the overnight runs? How many hours a day go into review?
In a migration there is also a natural point of comparison, namely the old against the new. How is it verified that they correspond? That comparison is cheap and deterministic, and if it is missing that is a larger problem than what any line item costs.
A good answer sounds like a process. Named steps, a named responsibility, a gate that cannot be walked around.
A weak answer sounds like a reassurance. That of course they review everything, and that quality matters to them.
The difference between those two answers is not politeness. It is the difference between having built something and imagining that one would.
See also: A check that answers differently is not a check (series 56) and The questions you will be asked in eighteen months (series 58).