Nightshift.

01

Useful work, waiting in a queue

A version update or a well-described engineering ticket can sit behind larger priorities. I wanted a way to pick up that work, produce a small change and leave it ready for an engineer to review.

The difficult part was the handover. A generated patch needs the right repository, a clear scope, a reproducible check and somewhere for the reviewer to understand what happened. That is the service I set out to build.

02

Give the model a bounded job

A Python harness selects eligible work, checks the scope, claims the ticket and prepares a workspace. The model works on the implementation. Verification and publishing remain separate steps controlled by the harness.

Version updates use deterministic edits where generation adds no value. Ticket delivery can ask for clarification when the request is incomplete. Each capability has its own access and budget, and each run leaves a record.

The execution design separates preparation, implementation, verification and publication. Repository credentials belong to the trusted stages. The verifier reconstructs the proposed change from a clean baseline before running the configured checks.

The model proposes the change. The service checks whether it is allowed to leave the workspace.

03

A green test run is a handover point

Nightshift opens draft pull requests. An engineer still reviews the implementation and decides whether to merge. Passing the configured tests is useful evidence, but it does not settle every acceptance criterion or prove that a security finding is resolved.

Failed checks prevent publication. Unclear requests should produce questions. A human edit or a changed ticket can invalidate an earlier decision, so the service checks the state again before writing.

04

From a harness to a working pilot

The Jira delivery pilot produced changes for pen-test tickets on a Java service. The recorded draft passed independently run Maven tests and branch and pull-request CI. Human review remained the acceptance step.

The pilot also exposed edge cases that the first implementation missed. Those cases became further review and regression work. They helped shape the verification and handover boundaries, rather than becoming a reason to trust the next generated change automatically.

The platform also supports version maintenance and review-feedback workflows. The reusable workflow is also designed to support incident response, with that capability still to develop beyond the delivery pilot.

05

What I would carry into the next agent

Make the permitted work explicit. Keep verification independent. Leave enough evidence for the next person to make a decision. Those choices have mattered more than making the agent sound confident.