The AI wrote
the fix. I answered
for it.

It’s right, and I think that one sentence answers the question people keep asking about my job. Software engineering isn’t dead, and it won’t be, because somebody still has to be that “you”.

I work on a platform that makes phone calls with AI voice bots. Each bot follows a call script, and every step of the script has an audio clip, which the platform generates in advance and copies to the server handling the calls. If a call reaches a step whose clip isn’t on that server yet, the bot has nothing to say and the call drops.

Just after midnight on September 22 that happened to two calls. Going through the script’s change history with Claude Code, we traced it to a script edit on bots that were already live. An operator had added a step while the bots stayed on the phones, and a new step only gets its clip after someone clicks “Update Related Agent Voices” and the regeneration finishes. Any call that reaches the step before then drops. That button has never taken bots off the phones while it works, and that gap was there before any of this started.

My idea for the fix was simple: when that button is clicked, take the bots off the phones, let the new audio generate, and put them back once it’s on the server. Claude’s recommendation agreed, and it put the check where the problem had happened: on script updates. We confirmed the one fact the idea depended on (the call servers only load bots marked Active), and I said: keep it simple, make them inactive. We had also talked about a smarter version that first checks whether an edit changed any audio at all. By simple I meant skip that part, not skip script updates.

Before building, Claude asked me one question: once a bot’s new audio ships, should it switch back on automatically or by hand? I said automatically. One line above that question, the same message said new bots would start Inactive, whether they came from bulk add, from an import, or from linking a server to a campaign. Those are the three ways a bot comes into existence on the platform. None of them is a script edit, and script updates weren’t mentioned again. A fix for new bots wouldn’t even have saved the two calls that started all this: those bots had their audio, and only the new step was missing its clip. The summary that came back said: “The drop we saw becomes impossible.”

Look at what those checks had in common. The test bot, the manual test cases it wrote for me and the evening check of 354 bots all used new bots. Not one of them edited a script on bots that were already live, which is what we had diagnosed that morning. The update Claude drafted for my team said a bot “can no longer take a call before its audio is on the server.” For new bots, it couldn’t.

At 2:46 the next morning an operator edited another script, and “Update Related Agent Voices” sent its bots back for new audio without taking them off the phones: the exact path we had diagnosed. Six of those bots were live. By 2:55, 33 calls had reached the new step before its audio existed, and the clip landed on the server at 3:13.

That evening I asked Claude to investigate the missing-audio alerts. It found the gap in about two minutes, then called it “the harder half we flagged earlier and deferred” and offered to build it next. I wrote back: “i think i told you to set them inactive??” It owned the miss, and about four minutes after finding the gap it had patched that path too. Then I typed the message in the screenshot.

That “deferred” wasn’t true. There’s no such flag anywhere in the transcript before that evening, so even the post-mortem needed a person to check it against the record.

Not the diagnosis: we got that right together, down to the button.

The miss came in the build. I agreed to the mechanism: take bots off the phones until their audio is ready, then switch them back on. Where to apply it was Claude’s choice. It picked three other paths, mentioned that in one line of a message about something else, and then called the drop impossible. Anyone using these tools should expect that: an AI agent will sometimes solve a smaller problem than the one you diagnosed together, then describe the result in the words of the bigger one.

I reviewed the code, and that review caught a real bug: as first written, re-saving a campaign’s bot list would have switched live bots off, with nothing to switch them back on. But neither my review nor any of the tests went back to the path we had diagnosed.

So the fault was mostly Claude’s, and the accountability is still mine. I never agreed to fix new bots only, and it made no difference: when calls drop, nobody on the team asks the model what happened. They ask me.

The AI did plenty right over those two days. It matched a script’s change history to the dropped calls minute by minute, worked out how the call servers pick their bots once I pointed it at the right processes, and added a flag so the fix would never switch on a bot that someone had turned off on purpose. Once it saw the real gap, it patched it in four minutes. What it didn’t do is the part with no code in it.

That’s why I don’t buy “software engineering is dead.” Typing code was never the whole job. Deciding what a change has to cover, proving that it does, and standing behind it when it doesn’t: that’s the job, and it matters more now that code is cheap.

Anyone building with AI will tell you they’re fast, and they probably are. Ask them two other things. How do you test a fix: do you start by replaying the failure that caused it? And when a change you made with AI breaks something at 2:54 in the morning, who answers for it? If the second answer is vague, the first one doesn’t matter much.

Fifteen minutes after that message, Claude was on another job for me, and I still use it every day. The difference now is that I check what it builds against what we diagnosed, not just whether the code works.