Gore puts it bluntly. Instead of ten engineers building, you might have three engineers plus seven people defining acceptance criteria and designing tests. The bottleneck moves from “can we write the code?” to “do we know whether the code is right?”

This matches what I see daily. I run multiple Claude Code sessions in parallel, each producing working code at a pace I couldn’t match alone. The hard part is never the generation. The hard part is knowing whether what came out actually does what I intended, handles the edges I care about, and doesn’t quietly break something else. And it’s not just me who needs to know. My team members need to look at that same output and reach the same confidence, often without the context I had when I prompted it.

The cultural shift Gore describes is the part most teams will struggle with. Your Monday standup changes. Instead of “what did we ship?” the question becomes “what did we validate?” Instead of tracking output, you’re tracking whether the output was right. That reframes what it means to be productive. An engineer who catches a subtle misalignment in generated code before it ships has done more valuable work than one who prompted three features into existence without checking them.

This connects to something else Fowler highlights in the same post: Margaret-Anne Storey’s concept of “intent debt,” where the goals guiding a system are poorly documented or maintained. If you can’t clearly articulate what the system should do, you can’t verify that it does it. Intent debt was always a problem, but it was partially hidden when the same person writing the code also held the intent in their head. When an agent writes the code, that implicit knowledge gap becomes a concrete failure mode.

I think the teams that figure out verification workflows early will have a real advantage. Not just automated tests (though those matter), but the whole practice of clearly stating intent, reviewing output critically, and building confidence that what shipped is what was meant.

About a month ago I added a global hook that plays a short chime whenever any session finishes a task. Two minutes to configure. Can’t live without it now.

The difference is about flow. Before, I’d either stare at a terminal waiting, or context-switch and then keep interrupting myself to check which session was ready. Now the chime pulls me back at exactly the right moment. I stay in whatever I’m doing until I hear it, then go find the session that needs me. It’s kept me in a flow state in a way I genuinely didn’t expect from something so simple.

How to set it up

Drop this into your ~/.claude/settings.json:

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "powershell.exe -NoProfile -Command \"(New-Object Media.SoundPlayer 'C:\\Windows\\Media\\chimes.wav').PlaySync()\""
          }
        ]
      }
    ]
  }
}

That’s it. Windows has the sound file built in. For Mac/Linux, swap the command for afplay or paplay with a sound file of your choice.

The empty matcher means it fires on every notification, regardless of which project or session triggered it. Claude Code sends a notification whenever a session finishes and is waiting for input, which is exactly the moment you want to know about.