This is a personal field note about how I organise AI-assisted delivery in my work at Tilt. It describes my operating method, not an official Tilt policy, a client commitment or a promise that every project can be completed overnight.

The word overnight can easily create the wrong picture. It does not mean leaving an autonomous system with unrestricted access and returning to a production release in the morning.

My safe default is narrower: prepare a defined slice of work, let bounded implementation and verification continue while I am away, and return to changes that are ready for human review. Merging and deployment are separate outcomes. They happen only when the scope and authorisation explicitly include them.

The laptop may continue working after I stop typing. Accountability does not go to sleep.

The night starts with a definition of done

“Deliver this overnight” is not a useful instruction. Before the run starts, I define what delivery means for that specific scope:

  • a review-ready merge request;
  • a sequence of dependent merge requests;
  • merged changes behind a disabled feature flag;
  • or, much less often, a deployed and verified environment.

Review-ready is the default because it creates useful progress without silently expanding authority. If a production change is not explicitly allowed, the workflow must stop before production.

I also write down the objective, success measure, non-goals, dependencies and acceptance criteria. A ticket that only describes the desired interface or outcome is not yet an overnight delivery plan. It still needs answers to questions such as:

  • Which repository and base branch are authoritative?
  • Does another change have to land first?
  • Is there a migration or compatibility boundary?
  • Which part requires a product decision rather than implementation?
  • Which verification can run automatically, and which must wait for a person?
  • What condition should stop the work even if more implementation is possible?

Most overnight failures begin before the first file edit. The system was given an ambition instead of a delivery contract.

Discovery comes before implementation

Before delegating code, I review the available product material, current tickets, related work, open reviews and the actual repository state.

The purpose is not to load every document into one enormous context. It is to find contradictions while they are still cheap:

  • two tickets describing the same change differently;
  • a specification that assumes an older API contract;
  • a dependency that is still under review;
  • a manual or commercial value that software should not invent;
  • a rollout step that cannot be validated locally;
  • a security or privacy question that needs a human decision.

If the work is too large, I split it by independently verifiable outcomes rather than by arbitrary technical layers. A small vertical slice with its own acceptance evidence is more useful in the morning than three half-finished branches called backend, frontend and tests.

The Tilt tool loop

The workflow is easier to understand through the tools I use at Tilt.

  • Linear holds the product and delivery state: the objective, ticket scope, dependencies, comments, acceptance criteria and current status.
  • GitLab holds the source truth: repositories, branches, merge requests, reviews and CI. I use glab when the run needs a current command-line view of that state.
  • Slack carries time-sensitive coordination, blocker questions and the concise morning handover. It helps people respond, but it does not replace the ticket or committed documentation as the durable source.
  • Cursor Agent runs the bounded local implementation work. Each later ticket starts in a fresh session so the current repository and instructions are read again.
  • Amphetamine keeps the authorised local Mac session powered and awake overnight. It solves machine availability, not software correctness.
  • Sentry and Grafana provide runtime evidence when the scope requires operational verification and access is authorised. They are optional inputs, not a reason to expand the delivery into production.

The division is deliberate. Linear says what should happen. GitLab shows what exists and whether its checks pass. Slack keeps the humans connected. Runtime monitoring shows what the software actually did. None of them can silently grant the authority missing from another layer.

Fresh context is safer than remembered context

For each independent ticket or slice, I start with a fresh working context.

The worker reads the current ticket, committed repository rules and relevant specifications, then fetches the current remote state before planning. An old conversation can provide history, but it is not allowed to overrule the live repository or current instructions.

This matters because agent memory feels authoritative even when it is stale. A thread may clearly remember a function, migration or product decision that changed several hours earlier.

Freshness is therefore an engineering control:

  • select the intended repository and base branch explicitly;
  • fetch before planning and again before opening a merge request;
  • keep durable rules in version control;
  • treat remembered state as a hypothesis until the repository confirms it;
  • rotate to a fresh worker after a major scope change or repeated confusion.

The goal is not a thread that remembers everything. It is a worker that can reconstruct the facts required for one correct delivery.

Isolate every writer

Overnight parallelism becomes dangerous when several workers share one mutable checkout.

I use isolated worktrees and focused branches so each writer has a clear boundary. Dependencies and merge order are decided before implementation, not discovered after two branches edit the same contract differently.

Changes should remain additive where possible. Risky behaviour starts disabled, new contracts fail closed, and a worker cannot broaden its own permissions because a wider change would be convenient.

This is especially important when a project spans more than one repository. The relevant repositories may be available for reading, but one task still needs a clearly defined write scope. “You can see it” is not the same as “you may change it.”

The six-stage loop

I organise the actual run around six stages.

1. Refresh

Read the current ticket, specifications, open reviews and committed instructions. Fetch the latest remote state and identify related repositories without assuming they are unchanged.

2. Plan

State dependencies, merge order, acceptance criteria, feature-flag policy, manual gates and stop conditions before editing.

3. Implement

Work in an isolated branch. Keep the change bounded, preserve compatibility and record any assumption that could not be verified.

4. Verify

Run the relevant formatter, static checks, tests and build. Add independent review where the risk justifies it. Monitor CI and resolve review findings instead of treating an opened merge request as completion.

5. Hand over

Return a clean review surface: what changed, which checks passed, merge order, rollout state, remaining blockers and the exact actions still required from a person.

6. Clean up

Remove completed worktrees only after the branch is published, CI is green and the handover is complete. Cleanup is a verified final state, not an automatic deletion step.

The sequence is intentionally ordinary. Overnight delivery becomes dependable through disciplined software practice, not through a more dramatic prompt.

The orchestrator should not become the implementer

For a larger delivery, one long-running context owns the dependency graph and project manifest. It tracks active branches, reviews, CI state, blockers and cleanup. It delegates bounded implementation to fresh workers.

The orchestrator does not write every change itself. If it absorbs implementation, it eventually accumulates too much state, becomes a conflicting writer and loses the independent view needed to coordinate the delivery.

I also keep review context separate from implementation context when risk is meaningful. A fresh reviewer is more likely to notice a wrong assumption than the worker that already spent hours making the approach internally consistent.

Long-running contexts have rotation triggers. A clean phase boundary after context compaction is a good moment to hand over. A new ticket, changed base branch, repeated investigation or failed retries is a stronger signal to start fresh.

Stop conditions are part of the output

An overnight workflow needs explicit reasons to stop.

Mine include:

  • an ambiguous product decision;
  • missing credentials, permissions or commercial values;
  • an unplanned breaking change;
  • destructive data or infrastructure operations;
  • production exposure outside the approved outcome;
  • a dependency whose current state cannot be verified;
  • any action outside the authorised scope.

Stopping one blocked branch does not require abandoning every safe task. Independent documentation, tests or review work can continue if their scope remains clear.

The important part is that the system does not convert missing authority into a guessed decision. A useful morning handover can say, “implementation is ready, but these two choices still require a person.” That is successful delivery.

What I want to see in the morning

The ideal output is not a message saying done.

I want a compact delivery manifest:

  • each change and its review link;
  • the intended order if changes depend on one another;
  • checks and CI results;
  • unresolved review findings;
  • rollout or feature-flag state;
  • blockers and assumptions;
  • exact manual actions still required;
  • confirmation that local work was preserved or safely cleaned up.

This makes the morning review finite. I do not need to reconstruct what happened from several long conversations or inspect every branch just to discover that a required decision was skipped.

What overnight delivery actually buys

The benefit is not that eight hours of elapsed time become eight hours of senior engineering judgment. They do not.

The benefit is that well-defined mechanical and analytical work can continue between two human decision points: repository reading, bounded implementation, tests, builds, independent checks, review preparation and evidence collection.

That changes how I use the next morning. Instead of restarting from the ticket, I can review concrete trade-offs and verified changes.

At Tilt, this is the standard I use for overnight AI-assisted work: scope the authority, refresh the facts, isolate the writers, verify the result and make every remaining human decision visible.