FarseerTech
Paid in Production № 01 · Field Note
For the people accountable when the AI ships

Your AI velocity is manufacturing liabilities

If you lead engineers, you'll recognize this one. It usually starts as the best week of the quarter — and ends as somebody else's 3 a.m.

This isn't an argument against speed. Agents make creation cheap — they just don't make ownership cheap. The failure mode isn't velocity; it's the durable artifact nobody signed up to own. Here's how it goes:

The life of an agent-built tool, a comic in three panels. Day 1: a builder ships an agent-built tool, thrilled, surrounded by /vibe and works-on-my-machine stickers. Day 60: the builder leaves for a new team, waving goodbye, their tools list now out of office forever. Day 365+: a different engineer is paged at night by an alert from a tool nobody owns that somehow has prod access, ownership unknown. Footer: the builder moves on, the bill stays. The bill always finds a forwarding address. 🔍 Tap to zoom

🔍 Panel text is small on phones — tap the comic to enlarge.

Strip away the cartoon and the mechanism is serious: the agent made the artifact cheap to create, but nothing made it cheap to own. The friction everyone wanted gone was doing quiet work — it was the gate that forced someone to decide whether a thing was worth owning before it existed.

The friction was not just the obstacle, it was also the filter.

And this isn't only about internal tools. The artifact might be a dashboard, a script, a generated API, a workflow automation, a data pipeline, a runbook, a remediation bot — or any other feature you ship. The arc is identical. Each one adds to your obligation surface: the set of things someone is now on the hook to run, secure, and keep correct. Agents grow that surface far faster than anyone is growing the list of owners.

The problem isn't that agents create things. It's that temporary things quietly become durable.

What actually fixes it

The fix isn't slower agents. It's treating agent-built artifacts like production assets the moment they become durable. Build whatever you want — prototype aggressively. But once an artifact is durable, it needs three things:

01
Ownership is a precondition
An artifact earns durability only when it has a named owner and the one decision it serves. Nobody willing to maintain it? Then it stays a prototype, or it's deleted — it never becomes durable. The orphans are the whole problem.
02
Standardize one signal: usage
Pick a single way to answer: is anyone actually depending on this? Not just human opens — dashboard views, API calls, downstream reads, alert references, workflow runs, dependency links. You can't expire what you can't measure.
03
Then give everything a TTL
Treat a durable artifact like a database record: append it, but with a time-to-live. Usage renews the lease; silence lets it lapse — no reads in a quarter and it archives itself. Rare-but-critical artifacts don't get exempted by vibes; they get an explicit bypass for incidents, compliance, or migrations. We got very good at INSERT. We just never wrote the TTL — so the stack became an append-only log nobody compacts.
$ tools --list # append-only · no TTL set TOOL LAST USED STATUS metrics-dash-v2 8 months ago EXPIRED oncall-helper never opened EXPIRED latency-rollup yesterday ✓ ALIVE cost-explorer-fork 5 months ago EXPIRED Usage is the TTL signal most teams forget to collect.
three of four were append-only. nobody set the TTL.

Each of these does the job the old friction did for free: it forces the question speed made cheap to skip — not "can we build it," but "who depends on it, and who owns it, a year from now."

Agents make creation cheap. They don't make ownership cheap. Any artifact that becomes durable without an owner, a usage signal, and a renewal path isn't velocity — it's deferred liability.

Paid in Production № 01
Comic, enlarged