The model can write the code. It still can’t own the system — here’s why that job stays

A model will write a service. It will not own a system. I keep saying that in staffing conversations because people hear “AI writes code” and slide to “then we do not need owners.” Owners are not typists. Owners are the people who know what must not change, what can fail closed, and what we promised a customer in a thread the repository never saw. The code is the easy artifact now. The system is still a political, temporal, data-shaped thing. That job stays.

The shipping loop — merge, radius, incident — is why I still want an engineer in the loop. This is the layer above the loop: who is allowed to say what the system is.

A system is not a folder of files

A system is the data you cannot lose, the hops you cannot time out, the vendor you cannot replace on a Friday, the legal sentence on a field, the on-call who will actually wake up. A model can list those if you paste a perfect doc. It cannot tell you which doc is a lie. It cannot tell you that the diagram is six months stale and the real source of truth is a spreadsheet in finance. Ownership is knowing where the lies are and still making a change that does not pretend the diagram is true.

I have asked a model to “add retries.” It added retries. The system already had a consumer that was not idempotent. The owner would have known because they had been in that incident. The model had the file. It did not have the scar.

Ownership is the data, not the handler

The handler is cheap to generate. The schema is not. Once a column exists in production with a meaning, you own that meaning for years. Models will add columns the way they add variables. Owners ask whether this is a new fact or a denormalization we will regret, whether we can backfill, whether a report already uses a different name for the same idea. I have cleaned up generated fields that meant three things in three services. That cleanup was the job. The field was a completion.

Tenancy, retention, encryption: those are system properties. They do not live in the function the model highlighted. They live in a decision someone has to keep making when a PM asks for a convenience dump. The model will write the dump. The owner will say no, or will say yes with a store and a date it dies.

Ownership is time

Systems have clocks. Certificates, leases, cron, DST, “this batch must finish before the market opens.” Models are bad at time because time is environment. Staging clocks lie. Local clocks lie. An owner has been burned by a Monday 00:00 that was UTC in one job and local in another. I do not need the model to invent cron. I need a person who will not put a 30-day lock on a row without saying who unlocks it if they leave.

Cost is time’s cousin. A generated worker that polls every second is a bill. An owner feels bills. A model feels the ticket. I have shipped a generated poller and then owned the invoice. Next time the owner is in the design, not in the surprise.

Ownership is the dependency graph you cannot see in one file

The model sees the import. The owner sees the vendor, the SLA, the person who approved the DPA, the fallback if that vendor is down. Adding a package is a system change. Models add packages to look complete. Owners treat each new name as a thing they might page about. I now ask, on generated PRs: what new runtime name did we just take responsibility for. If the answer is “a helper,” I read the helper. If the answer is “a service,” we are not done.

The same is true inward. Deleting a module the model thinks is unused can delete the one path a partner still hits. Owners grep the outside world: logs, tickets, that one mobile build. Models grep the repo. The repo is not the world.

Ownership is saying what we will not build

A system is also a list of refusals. We will not be a second source of truth for balances. We will not run this report in the request path. We will not store raw cards. Models are completers. Completers do not love refusals. They will scaffold the second ledger if the ticket sounds like it. An owner is the person whose job includes disappointing a ticket. That disappointment is architecture.

I have used a model to draft the “no” RFC. I still had to be the person who held the no when the RFC got comments. Holding is not a completion. Holding is a quarter of meetings. The job stays because someone has to be in those meetings with the right to lose social points.

Why the job does not evaporate when the code gets faster

Faster code production increases the rate of system-shaped decisions. More diffs means more chances to add a column, a hop, a vendor, a clock. If we staff fewer owners because typing got cheaper, we will get a larger system with a smaller memory. That is how you get a year of green PRs and a data model nobody will touch. I would rather fewer features and a model someone can still hold in their head. Ownership is that holding. Models do not hold. They generate the next piece and forget the constraint unless you paste it every time. Pasting every time is not ownership. It is a prompt habit. Habits slip. Owners are supposed to slip less on the constraints that ruin companies.

The job stays because someone must be accountable when the system contradicts itself. Two services, two truths, one customer. A model can propose a sync. An owner has to pick the truth and retire the other. Picking is a political act inside a technical costume. I will not assign that act to a session id.

What I still let the model own

Drafts. Tests I will rewrite one of. A first map of call sites. A summary of a thread I already read. I do not let it own the schema change, the vendor add, the new clock, or the public refusal. Those four go through a person with a name on the system. If that sounds conservative, it is because I have already paid for the other policy. The other policy was faster for a month and then we could not explain the data.

I also let the model challenge my map. “What did you forget.” Sometimes it names a hop I skipped. I still decide whether the hop is real. Challenge is useful. Authority is not transferable to the challenge.

How I staff it now

Every live system has a named owner and a backup, written down. They may use models all day. They still own the schema, the refusals, the vendor list, and the clocks. New services do not ship without those names. Generated services especially do not. A generated service with no owner is how we get the cute name I get paged into after the author is gone.

I will keep paying for people who can hold the system. I will let models write more of the code those people used to type. I will not confuse the two. The code is becoming abundant. Coherent systems are not. The scarcity moved. The job followed the scarcity. That is why it stays, and why I get restless when a slide says the opposite. The slide can write a service. It cannot own the Monday after.

If you are early in the job and worried the model took your seat, look at what seat it took. It took some typing. It did not take the right to say what the system is not. Learn the data, the clocks, the vendors, the refusals. Those are slower to learn than syntax and slower to automate. I would rather train for that slowness than for a faster snippet. The snippet is already fast. The system is still a person, or it is a mess that only looks like a system in the generated README.