The Production Function Changed

As a principal engineer, one of the most powerful levers I have is to create policy and tools that empower others to have success by default. Linters are static verifiers that fit this shape well, and with agents, turning the lints up to 11 is one way to ensure the software they produce falls into the pit of success. In one example, I turned on no-await-in-loop from ESLint in a large TypeScript codebase, finding 600 violations. In the “before times” where implementation was constrained on human labor, this would be an expensive migration; with agents, it is a single PR to both do the lint fixes and exhaustively add test coverage.

Software organizations were built around human implementation time as the scarce input. Planning, staffing, prioritization, and risk management all assume that more software requires more engineers. Agents break that assumption.

Writing the policy was historically the cheap part. The expensive part was deploying it into a mature codebase: migrating every callsite, proving the migration preserved behavior, and stopping new violations while the cleanup was in flight. An obviously correct invariant could still fail the capital allocation test if adopting it required staffing a migration.

For example, most engineers have been paged for an outage that boiled down to a missing timeout or retry on a cross-service network call. The collective amount of engineering time spent on this failure mode is astounding. Still, there is no ESLint plugin to drop into a codebase to assert that every fetch call carries the right policy.

Because code is cheap now, we can vibe that guardrail into place with 100% code coverage and exhaustive table-driven tests, migrate the codebase in one go, and surface a descriptive failure to the model every time it writes another fetch call. The agent does not need to remember the rule up front; the verifier gives it the missing context exactly when it needs it.

The higher the agent throughput, the more policy has to be executable. Repeating the same invariant in comments on every agent-authored PR does not scale. If it matters, it belongs in a verifier owned by the repo.¹

The implementation budget applies to architecture too. Most user preference systems I have encountered are not designed, and because of that you get constructs like three-valued booleans (yes | no | shopify, in Stripe’s case) or boolean settings with unmanaged defaults. With agents, we can have the user preference system of our dreams as if we are already operating at billion-user scale: on | off | unset, plus a service-level default for unset that can change over time, and delegated registration so “preferences” or “feature flags” stay centrally managed while each business domain registers its own knobs. Before agents, this design was easy to water down because the fiddlyness would eat the team alive. Now doing it correctly costs the same as doing it shittily.

Review has to scale with implementation. At the end of a run, the agent should be treated like another member of the team: it needs to convince the reviewer to merge. We do not shoulder surf teammates while they write code, and agents do not need that either. If the evidence is insufficient, ask for the same proof you would ask from a teammate: the tests that ran, the QA plan, logs from the staging deploy, or a screenshot or video of the feature working. The agent should attach those validation artifacts to the PR before asking for review.

Once the PR carries its own proof, I do not need to watch the implementation happen. I haven’t written code by hand in months. My laptop hums with its lid half closed at night—or rides buckled into the back seat of my SUV—running caffeinate -sdi so a PR or three can get authored, pushed, reviewed, and merged while I’m asleep.

When I want an end-to-end run, I prompt Codex with $task $launch-app $local-obs $commit $push $land $github-pr-media and let it rip.

For smaller work, I reply to a Slack thread with @Codex do it. Codex web picks up the thread as context, handles a docs fixup or small ticket asynchronously, and opens a PR. By the time the PR reaches me, I am making a yes-or-no merge decision. I am not attached to the code because I did not spend the day typing it; I am evaluating the invariant and the proof.

In these workflows, human implementation is no longer the constraint. The scarce work is choosing the invariant and deciding whether the proof is sufficient.

Footnotes

1. OpenClaw’s @openclaw/fs-safe, Go’s os.Root, and Linux’s openat2(2) are representative interfaces for constraining filesystem access beneath an allowed root. ↩