.env.example says DATABASE_URL=postgres://localhost:5432/app. The compose file the team uses for local work mounts a volume and sets DATABASE_URL=sqlite:///data/app.db. The CI workflow exports DB_URL, a name the code stopped reading two refactors ago. Production has a secret called DATABASE_URL that nobody has looked at since the last rotation. Each of those files is valid, and every linter you could point at them passes them. The app still behaves differently on three machines, and the first person to find out is whoever is on call.

A nightly agent job triages new issues. One night an issue arrives with a 400 KB log attached. The agent reads it, a tool call fails, the agent retries, and the loop runs until the month’s token budget is gone. Meanwhile cron, which has no idea what a token is, starts the next run on schedule. Now two copies are fighting over the same issue tracker.

Cron was built for jobs that cost nothing, finish in seconds and do the same thing every time. Agent jobs cost money per token, run for an unpredictable time and can loop. The useful ones are still boring and periodic: summarize what changed in a repo since yesterday, triage new issues each morning, check a competitor’s pricing page weekly. What they need is a scheduler that stays as small as cron and adds four things: a cost ceiling, a timeout that actually kills, an overlap rule, and state carried between runs. Anything past that is an orchestration platform, a different and much larger product.

Cloudflare shipped Worker Previews today, and the headline is easy to state. Every git branch gets its own running Worker, with its own URL, its own config, its own logs, its own traces. You run npx wrangler preview, and the branch you’re sitting on becomes something you can open in a browser and click through. Cloudflare says you can run hundreds of them side by side without them touching each other or production.

Mobile testing is harder than web testing for reasons that are partly technical and partly organizational. The technical reasons: the diversity of physical devices, OS versions, screen sizes, and hardware configurations that a production mobile app must run on is several orders of magnitude larger than the browser matrix that web applications face. The organizational reasons: mobile development cycles historically moved faster than testing infrastructure could keep pace with, producing teams that ship without adequate test coverage and accumulate testing debt that compounds with each release.