At 18:10 on a Tuesday, Thandeka, the tech lead at Keurbooms Software, put five tasks on a list and went home. Each task named one stale feature flag in Lagoonbook, the company's booking and payments platform, and asked a background coding agent to remove it. By 06:40 the next morning there were five pull requests waiting. Three were merged by 09:30. One was revised and merged after lunch. One was closed without anyone reading the diff, because the evidence attached to it showed the flag was still being hit by a small number of tour operators on an old mobile app.
That closed pull request was the most useful thing the night produced. It showed the team that the agent's code was not the main product of the night. The evidence was.
This series follows Keurbooms Software, a fictional company in Plettenberg Bay with a nine-person engineering team, through a handful of nights in which background coding agents work on Lagoonbook and the mornings in which people decide what to keep. Some nights go well. One goes badly in an instructive way. By the end the team has a written charter for what the night shift may touch. Everything about the company, its people, its code and its numbers is invented. The mechanisms are not.
The premise: work that does not need anyone awake
Keurbooms Software is typical of small product teams. Thandeka leads engineering. Pieter carries the on-call phone most weeks. Ayesha owns the product and the roadmap. There are always more small, worthwhile jobs than there are hours: flags that were switched on months ago and never removed, dead code paths, missing tests for behaviour everyone relies on, patch upgrades nobody has had time to read.
Background coding agents are tools that take a task, work on a copy of the repository without a person watching each step, and return a proposed change, usually as a pull request. Several vendors now offer them, and teams can also build their own from an agent framework and a continuous-integration runner. This series does not compare products. It is about the operating model around any of them: what you give them, what you accept back, and who decides.
The tempting framing is "the agents work while we sleep, so we get more done". The more accurate framing is "the agents prepare work while we sleep, so that the morning is spent deciding rather than typing". That difference shapes everything else in the series. A night shift that produces work nobody can verify quickly has not saved time; it has moved the effort to the morning and added risk.
Why stale flags were the right first job
Thandeka chose stale feature flags for the first night on purpose. A feature flag is a switch in code that lets a team turn behaviour on or off without a deployment. Once a feature has been fully rolled out and has stayed on for a while, the flag and the old code path behind it become clutter. Every stale flag is a branch that must still be read, tested and reasoned about.
Removing one has four properties that make it good night work:
- It is small. One flag usually touches a handful of files.
- It is checkable. Production telemetry can show whether the old branch has been used at all in recent weeks.
- It is reversible. If something goes wrong, one revert restores the previous code. No data changes.
- It has an obvious owner. Each flag in Lagoonbook records who created it.
Compare that with a task such as "make the checkout faster". It sounds just as small, but it has no single checkable outcome, it could be solved in many ways with different trade-offs, and its success can only be judged with production measurements that do not exist at 03:00. Part 2 of this series shows what happens when a task like that reaches the night list.
The general rule the team took from this is the same one CloudNala applies to agents in business processes: use the least autonomy that can handle the work. Removing a flag needs an agent that can read code and edit files, not one that decides what the product should be. Our article on why AI-native does not mean AI everywhere makes the same case for software design.
The evidence pack
Before the first night, Thandeka wrote a short instruction that every night-shift pull request had to follow. The agent was told to put the evidence at the top of the description, before any explanation of the code. The reviewer reads that evidence first and only opens the diff if it holds up.
Each part has a job.
Why. The reason the change is safe, stated as a fact that can be checked. For a flag removal at Keurbooms, that means the flag has been fully on (or fully off) in production for at least six weeks, with the dashboard link.
Scope. One flag per pull request, with the files touched listed. Small pull requests are not a style preference here. A reviewer can verify a 40-line change in minutes; a 900-line change bundling six flags gets skimmed and approved on trust, which defeats the point.
Proof. The existing test suite passes, and the agent has added or pointed to a test that exercises the path being kept. If the only tests that covered the flag were deleted with it, the reviewer cannot tell whether the kept behaviour is still tested.
Telemetry. Zero recorded executions of the removed branch over the agreed window. This is what closed the fifth pull request on the first morning. The flag had been on for everyone on the web app, but an older version of the mobile app, still used by some tour operators, sent a header that forced the old path. The code and the tests looked fine. Only the telemetry showed the old path was still in use.
Undo. A statement that the change can be reverted with one commit and involves no data migration. If that is not true, the task should not have been on the night list.
Run record. What the agent was asked, which tools it used, how long it ran and what it cost. This is not there to police the agent. It lets the team see whether a task class is cheap and reliable enough to keep, and it makes a strange result traceable. A trace is not an evaluation, but without one there is nothing to evaluate.
Who decides in the morning
The agents at Keurbooms can open pull requests. They cannot merge them, and they cannot deploy. That boundary is set in the repository's permissions, not in the agent's instructions, so it does not depend on the agent following a rule. Our piece on why agentic development still needs an acceptance authority explains why the acceptance decision has to belong to a named person with the context to make it.
At Keurbooms that person is whoever owns the area of code, with Thandeka as the fallback. The review is deliberately short and in a fixed order: evidence, then scope, then diff. If the evidence fails, the pull request is closed with a one-line reason, and the reason goes back into the task list so the same mistake is not repeated the next night. An automated review comment from another model can help find problems, but it does not replace this step; AI code review is a filter, not a sign-off.
The team also agreed on one thing that turned out to matter: closing a pull request is a normal, good outcome. If reviewers feel they must merge whatever the night produced because the work has already been "done", the night shift becomes a pipeline for pressure rather than for useful changes.
What the first week showed
Over the first five nights the agents opened 22 pull requests, all flag removals and dead-code cleanups. Seventeen were merged, three were revised and merged, and two were closed on telemetry. Median review time was about seven minutes. Nothing was reverted. These are fictional figures for a fictional team, but the shape is typical of the work: high acceptance on narrow, well-specified tasks, with the closures being the cases where reality differed from what the code suggested.
The less visible result was cultural. Pieter, who had spent two years meaning to clean up the flag list, said the value was not that the agent wrote the code. It was that the agent did the tedious investigation, assembled the evidence and left him a decision that took minutes instead of an afternoon. That is the useful version of the night shift. It is also why the work stays within the delivery system rather than replacing it.
What changed in the team's rules
After the first week, Keurbooms wrote down four rules. They become the core of the charter in Part 4.
- Night tasks must be small, reversible, owned and checkable by a test or by telemetry.
- Every night pull request carries the evidence pack at the top. No evidence, no review.
- Agents can propose; people merge. Permissions enforce this, not prompts.
- A closed pull request feeds back into the next night's instructions.
None of this is specific to coding agents. It is ordinary engineering discipline applied to a new kind of contributor, the same thinking behind the guides, guards, checks and sensors described in our framework for trustworthy coding agents.
Key points
- The product of a night shift is evidence and a decision-ready pull request, not code alone.
- Good night work is small, reversible, owned and checkable. Stale flags and dead code fit; vague improvement goals do not.
- Put the evidence pack at the top of every pull request and read it before the diff.
- Telemetry catches what code and tests cannot, such as an old client still using a branch.
- Agents propose and people merge, enforced by repository permissions.
- Closing a pull request is a good outcome and should improve the next night's instructions.
Next: Part 2, The night the agent split everything into services. All parts are on the series page.
How CloudNala can help
CloudNala helps engineering teams introduce background coding agents without losing control of their codebase. We help you choose the first task classes, write the evidence-pack template and agent instructions, set repository permissions so agents can propose but not merge, and measure acceptance, revert and review time over the first month so you can decide, on evidence, what the night shift should do next.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Talk to us about coding agents in your delivery pipeline or write to us at consult@cloudnala.co.za