Who Answers the Phone

I wrote the SMPP service at Salesforce and that meant when it stopped talking to the aggregator, it was my phone ringing at 3:00 AM. On one of those calls our network team had already looked and told me the problem was not on our end, and the endpoint engineers had already looked and told us the problem had to be on our end. Both parties concluded it was in the software. Both of them were right about their own equipment and the service was still down. That was the part I couldn't leave alone. If both answers were right, then we were asking the wrong question.

The problem was a dropped VPN connection handled by our global network team, and it wasn't monitored. Nobody was lying. Everyone was correct inside the boundary they were responsible for, and it was outside those boundaries where the failure lived.

What I did next matters more than finding it. I wrote connection healing and reporting, so the service could detect the drop, cycle the connection, and bring itself back without anyone awake to watch it. If that failed, it set off alarms for our network team. The calls stopped. I've known engineers who would not have written that, who liked being the one who rushed in and fixed it while everyone watched. I understand the appeal. It is something I have never wanted. For me the marker of success is the software runs so well you forget it's there. If the thing you built needs you conscious at three in the morning to keep working, you are not finished, you're just famous.

I've been thinking about that night again because of an argument people are making about AI and responsibility, and something about the argument has been bothering me.

Someone generates an application, ships it, and cannot answer a single question about the code or the language it was written in. When it breaks, there is no author to ask. The code has an origin but no owner. I have seen exactly this, up close, more than once. I audited two applications posted in Linux communities and found critical flaws in both, and in one case the developer denied the flaw existed until I showed him the specific lines and pointed him at the installer script in his own repository, at which point he figured out his application was installing a service he did not know about. That was a privilege escalation. Any local user, or any malicious browser tab, could get root. He was not malicious. He simply had no relationship with what he had published, other than probably an impossibly long prompt. The people worried about this are describing something real, and I am not pretending otherwise to make my case easier.

The mistake is treating authorship as the source of responsibility. The argument assumes that writing something is what makes you responsible for it, and that severing authorship severs accountability. Authorship was never the source. I have inherited code from contractors who wrote every line by hand, invoiced, and were gone before the first production incident, and the phone still rang, and it rang for whoever was left holding it rather than for whoever typed it. Vendors ship SDKs nobody reads. Teams inherit systems from people who left the company. Half of this industry runs on code whose author is unreachable and always has. The split between the person who writes a thing and the person who answers for it is as old as the first program, and it is structural, and no model created it.

So something did change. The people worried about this aren't imagining that either.

What the model did was make the split cheap. It used to take a contract, a vendor, or an employee leaving the company to end up responsible for code you did not write. Now it takes an afternoon. The volume went up by orders of magnitude, and volume is what made a longstanding problem visible, and when a longstanding problem becomes visible people blame whatever was in the room when they noticed.

The question is not who wrote it. The question is who answers the phone.

That sorts people more accurately than origin ever could. A developer who hand-typed every line and then pushed the consequences onto a maintainer or a user has not kept responsibility, they kept credit. A developer who used a model heavily and is still the one who gets called, who can open the file and tell you why it is shaped the way it is, who will be there in six months when the assumption underneath it stops being true, has kept the thing that matters. One of those people is dangerous and one is not, and you cannot tell them apart by asking what generated the code.

Here is what code ownership looks like for me.

I decide what the product is for, the tools and languages used, and what I am willing to put my name on. I created tooling that helps turn that into a written specification and acceptance criteria before anything is built. Criteria written after the fact are a description of what you got rather than a definition of what you wanted. The models can propose the plan, the implementation, and the fixes. They can argue that my approach is wrong. What they cannot do is accept their own proposals. I approve the plan, triage the review findings, decide when a failed approach should be abandoned, and authorize every push. Delegation changes who produces the work. It does not change who owns the decision. This is not a novel arrangement. It is how I've worked with a junior engineer, a contractor, a fabrication shop, or anyone else whose output you are going to sign your name to.

That tooling became Cadence. I built it to enforce this instead of trusting myself, or the model, to remember it, and the rule I care about most is a stop condition. Knowing when to stop is part of engineering judgment. When adversarial review finds something, the model gets two attempts at it, and then it has to stop and ask. Not because the second attempt is likely to be wrong. Sometimes another attempt is exactly what you need. Sometimes the fact that you keep needing another attempt is the information. A model that cannot recognize it is chasing the wrong shape will keep chasing it, generating variation after variation of a fix that was never going to work, and it will do this cheerfully and indefinitely. Being stuck is a judgment state. Recognizing that the approach is wrong rather than the implementation is a decision, and decisions belong to the person who answers for them, so the rule forces the question back to me. How would I do this? That is the whole point of the stop. It is the same instinct as the connection healing, run in the other direction: build in what the system can be trusted to handle without you, and put a hard wall everywhere it cannot.

I know where this makes me unpopular. There is a growing practice of writing one long prompt, letting it run, and shipping whatever comes out, and the people doing it will tell you they are being efficient. They are not being efficient. They are producing artifacts that nobody has ever evaluated, at a rate no reviewer can absorb, and then putting them in front of users. The cost does not disappear because they did not pay it. It moves. It lands on the maintainer who has to triage the issue, the volunteer who reviews the submission, the person downstream who trusted that someone competent had looked at this. That transfer is the actual harm, and it is worth being blunt about, and it is not what a ban on generated code catches.

The tool is a capable specialist with a hard boundary, correct inside its frame, blind to everything outside it, exactly like the network team and exactly like the endpoint engineers. Correct within scope has never been the same as working. Somebody has to hold the whole thing, and that somebody has to be a person, because only a person can answer for the outage.

Keep the decisions. Answer the phone.