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 one path: an operator edits a script and adds a step, then clicks “Update Related Agent Voices” to regenerate the audio for every bot on that script. The bots keep taking calls while that runs, so any call that reaches the new step before its clip lands on the server drops.

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.

The plan Claude put in front of me 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, and none of them was the path we had diagnosed. Script updates weren’t on the list, and nothing in the plan said it was leaving them for later. I approved it, and 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 updated a script and regenerated the voices of 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.

Early the next morning an operator updated a script and clicked “Update Related Agent Voices”: the exact path we had diagnosed. Six of the bots on that script were live, and they stayed live while the system generated the new clip. From around 2:54, 33 calls reached the new step before its audio did; the clip landed about 19 minutes later.

That evening I asked Claude to investigate the missing-audio alerts. It found the gap in about two minutes and said it plainly: the gate made new bots wait for their audio, but did nothing when that button sent live bots back for new audio. Four minutes later it had patched that path too. Then I typed the message in the screenshot.

Its apology owned the miss, with one claim that wasn’t true. It said it had flagged script edits as “deferred” when it built the gate. There’s no such flag anywhere in the transcript, 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 step after it. The fix covered three other paths, skipped the one we had diagnosed, 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.

But the plan listed its scope, and I approved it. I reviewed the code too, 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. I read the code carefully and never held the plan up against the diagnosis. That check was mine to make.

When calls drop, nobody on the team asks the model what happened. They ask me.

Give the AI its due. 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 by reading the processes running on them, 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.

For the record, I gave Claude its next task about fifteen minutes after that message, and I still use it every day. The difference now is that I read its plans against the problem, not just its code against the plan.