Closed-source developer tools can't ride your coding agent's overnight loop

The maintenance gap inside a coding agent's overnight loop is the one nobody has named yet. Every dependency the agent can keep current on schedule lives in one category; every one it cannot lives in another. The boundary between them is set by access: whether an automated task can fetch, patch, and verify the source, or whether the source lives behind a vendor. The category line is operational, not ideological.

Crawshaw's prompt, quoted on Simon Willison's Weblog on 3rd August 2026, makes the constraint visible. The prompt is a one-line maintenance pattern for developer tools (the programs engineers use to write, test, and ship other software) in which an overnight scheduled task fetches upstream changes, rebases local edits, runs the test suite, and replaces the binary. The loop presupposes source access. A closed-source devtool is not just philosophically out of step; it is operationally invisible to the same overnight job that handles everything else in your stack.

The counterargument stands. Closed devtools can still be vendor-patched on a schedule, just not by your own agent. The reframe Crawshaw's prompt earns is sharper than "open source wins." It is this: if you want your agent to maintain a tool, the tool has to be open source. The test the reader can apply tonight is one line. Could a scheduled task on my machine fetch, rebase, verify, and replace this devtool without phoning home to a vendor? If the answer is no, this is the one devtool the overnight loop will never touch, and the tool the team has to maintain by hand.