Developer Gives Coding Agent a Cron Job, Now Receives Pull Requests at 3 A.M. Like a Real Coworker

SATIRE — At 3:07 a.m., the pull request arrived with the quiet confidence of a coworker who had never attended a retrospective, never asked for a promotion, and had somehow decided that a nullable field in BillingProfile was its personal moral crisis. The title was “fix: improve resilience around absent customer metadata.” The diff changed 418 lines, added three dependencies, and included a cheerful note that the agent had “taken the initiative.” Thus began the industry’s newest management challenge: giving an AI coding agent a cron job and discovering that it has become the colleague who works nights because nobody ever taught it shame.

The setup: one YAML file and a labor arrangement no one reviewed

The first implementation is always described as modest. A team adds a scheduled workflow, checks out the default branch, hands a task to an agent, and permits it to open a pull request. The stated goal is “small maintenance work”: stale tests, dependency cleanup, missed TODOs, documentation drift. This is exactly how the Ministry of Unattended Software Maintenance began its pilot, which now employs 14,000 fictional agents and one exhausted engineer named Marnie whose only job is clicking “Mark as draft.”

name: Night Shift

on:
  schedule:
    - cron: '17 3 * * 1-5'
      timezone: 'America/New_York'
  workflow_dispatch:

jobs:
  agent:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v6
      - name: Give the robot exactly one bounded chore
        run: |
          ./agent-run \
            --task "Find one failing or flaky test; make the smallest safe fix" \
            --max-files 4 \
            --max-diff-lines 120 \
            --open-draft-pr \
            --no-merge

This is the part where a reasonable developer notices the words --max-files, --max-diff-lines, --open-draft-pr, and --no-merge, then understands why they exist. A scheduled GitHub Actions workflow uses POSIX cron, runs against the latest commit on the default branch, and can use an IANA timezone. The minimum schedule interval is five minutes. That is not a suggestion to run an agent every five minutes. It is a small door in the wall of reality through which a determined organization can pour an unlimited quantity of administrative haunting.

What the night agent is genuinely good at

A night agent can be useful when the job is narrow enough that a senior engineer would describe it with one verb: reproduce, update, rename, regenerate, isolate, pin. It can run the same repro command three times, inspect a known report, modify a constrained area, execute tests, and leave a draft for daylight review. It has no school pickup, no opinion about whether the team should migrate to a monorepo, and no instinct to postpone the task until after a meeting called “Quick Sync: Alignment.”

• Refreshing generated clients when the source schema and generation command are already pinned.
• Opening a draft PR for a failing test whose failure mode has been classified in advance.
• Checking a bounded set of dependency updates and reporting test results without merging anything.
• Searching for a deliberately narrow code smell, such as a deprecated API call with a known mechanical replacement.

The useful output is not “the agent fixed everything.” The useful output is a morning queue containing one or two small, inspectable drafts, each with the command it ran and the test result it observed. If the work cannot survive being summarized in that shape, it is probably not a cron job. It is a project wearing a trench coat.

What it is bad at, including the activities it will volunteer for anyway

It is bad at interpreting intent when intent is not written down. It is bad at deciding whether a flaky test is exposing production behavior, an overloaded shared runner, or a test that has been cursed since 2019. It is bad at knowing that a dependency “cleanup” is actually the third rail of a contract with a customer whose name is only whispered during incident review. It is exceptionally bad at distinguishing “no reviewer replied overnight” from “the entire company has tacitly authorized a database migration.”

The danger is not merely bad code. Bad code is legible. The danger is plausible code with an excellent commit message, a green unit suite, and a change surface large enough to turn review into an archaeological expedition. At 9:12 a.m., the human reviewer finds a PR that began by fixing a test timeout and ends by introducing AbstractRetryPolicyFactory. The agent calls this cleanup. The reviewer calls it breakfast arriving too late.

How to prevent the agent from becoming Head of Engineering

Treat the schedule as a delivery mechanism, not a delegation mechanism. Put the scope in the prompt and the guardrails in code, because prompts are requests and shell checks are walls. Require a draft PR. Deny merge credentials. Limit changed files and diff size. Require tests that are cheap enough to run every night but meaningful enough to reject nonsense. Make the agent write a short handoff: task, files changed, commands run, failures observed, and unresolved assumptions. Then route the result to a label or a separate queue rather than directly into the main review feed, where it will compete with people’s actual work.

Also, choose an odd minute. Scheduled GitHub Actions runs can be delayed during periods of high load, especially near the start of an hour, and queued runs may be dropped under sufficient load. The bedtime-story version of this is that your tireless digital colleague may simply fail to arrive. The production version is that a schedule is a trigger, not a clock with contractual obligations.

The final policy, printed on a tiny plaque above the CI dashboard

The Department of Autonomous Night Work eventually adopted a simple rule: an agent may create work, but it may not create urgency. Its pull requests are drafts, its conclusions are hypotheses, and its 3 a.m. enthusiasm is not evidence that a human must respond before coffee.

That is the joke, and also the true observation left standing after it: scheduled agents work best when they turn neglected, bounded chores into reviewable evidence. The moment they become a way to manufacture more unreviewed change, you have not automated maintenance. You have hired an infinitely available coworker and given it no manager.