Software Work Is No Longer Scheduled

One of the quiet failures of most engineering organizations right now is that they still think software work needs to be scheduled.

Backlogs, roadmaps, sprint planning, quarterly prioritization — all of that evolved in a world where implementation capacity was scarce and expensive. You had to decide what wouldn’t get done, because doing something meant a human spending time on it.

That assumption no longer holds¹.

In my day-to-day work, a huge class of tasks simply does not need to be planned anymore. Small refactors. Safety improvements. Removing footguns. Tightening invariants. Writing tests that should have existed. Updating documentation that drifted. None of these require meetings or prioritization. They run continuously.

If something is annoying, brittle, or obviously wrong, it’s not “low priority.” It’s a background task.

The shift is subtle but important: work moves from the roadmap to the ambient system.

Concretely, this means you don’t need a fixit week. You don’t need to schedule an appsec review. You don’t need a quarterly push to clean things up, or to wait until user friction is reported multiple times before increasing the priority enough to involve engineering. Those rituals exist to batch work that used to be too expensive to do continuously.

The capacity is already there. The leverage is in building harnesses that continuously deploy inference into the codebase: agents that are always looking for footguns, invariants that can be tightened, tests that should exist, documentation that drifted, coverage that can be improved, logs that contain PII, tracing spans that need more granularity, or patterns that should be made illegal. If something can be specified, it can run all the time.

When capacity is abundant, the question stops being “should we do this?” and becomes “do we have enough signal to notice when it’s wrong?” If the answer is yes, the work can just happen. If the answer is no, that is what needs attention.

I am perfectly happy to throw away the majority of generated patches. Rejection is not waste; it’s training data. Every review decision tightens the system. Every “no” makes the next output better aligned. These investments compound.

What breaks is not quality. What breaks is planning.

If your organization still assumes that every improvement must compete for human time on a roadmap, you will underexploit what’s available now. You will spend energy deciding instead of shaping.

The real scarce resource isn’t capacity anymore. It’s attention applied to the right leverage points.

Footnotes

1. I describe why this assumption broke in more detail in The Production Function Changed. ↩