The Shoulder, the Agent, and the Job

A couple of weeks ago I tore something in my shoulder while climbing.

Nothing dramatic. A bad rotation on a hold I had no business being on. The kind of injury that takes ninety seconds to acquire and weeks to dismiss. The side effect I did not expect was the sleep. I would wake at four because the shoulder would not let me stay down, and I learned quickly that there is no comfortable position for a torn rotator cuff at that hour. So I would get up, drive to the office in the dark, and have ninety minutes alone before anyone else showed up.

After a couple of days of staring at email, I got bored.

I opened Claude Code.

By the end of the week, I had built a small agent that the security team and the R&D engineers could ping inside their normal flow. Threat modeling questions. Access policy lookups. The kind of "what does the company's security team think about this" questions that used to consume an hour of a senior engineer's calendar and now resolve in a Slack thread. The CSO of the company built it. At five in the morning. With a busted shoulder. As a way to not stare at email.

I am writing about this not because the agent is interesting on its own. It is, in the technical sense, not very interesting. What is interesting is the moment it produced inside the org.

The Joy Is in the Building

Let me say something out loud that I think a lot of senior security leaders feel and almost never write.

The most fun I have at this job is when I am building something.

Not when I am running the program. Not when I am presenting to the board. Not when I am closing a deal with a vendor. The moments I feel most alive in this work are the ones where I have an idea, I have access to the tools, and I am inside the loop of making the thing exist. Most of my career, that loop was closed off to me by seniority. CSOs do not write code. CSOs do not ship features. CSOs translate, prioritize, and unblock. Building was something I had done earlier in my career and had been slowly migrating away from for a decade.

AI gave it back.

Not to me specifically. To anyone in our function who is willing to sit down with the tools and remember what it felt like to make something. The agent I built in that bored ninety-minute window is not a product. It is not on a roadmap. It will probably get rewritten three times by people more competent than me before it stabilizes. That is exactly the point. Six months ago, the cost of building it would have been a quarter of an engineer's time and three rounds of prioritization. Now the cost is a senior leader's curiosity and a working laptop.

If the cost of experimentation has dropped that far, the question is not "should we build more." The question is why we are not.

Product Thinking Is the Missing Skill

For most of the history of this field, security has been a service function. We responded to tickets, reviewed designs, blocked launches, built controls, ran programs. The tools we used were bought, not built. The work product was a memo, a policy, an architecture diagram, a finding. Real software, when we needed it, was written by other people on other teams who happened to be solving security problems at the time.

That model is breaking, and not gracefully.

What is replacing it is product thinking inside the security function. Senior security leaders who can identify a workflow, prototype the smallest version of a tool that solves it, and ship it inside their own org without going through the standard four-quarter procurement and engineering cycle. That capability used to require a senior engineer on the security team and an executive sponsor willing to argue for the headcount. It now requires a leader who knows how to use AI to ship a working v0 in a morning and the institutional permission to put it in front of users.

The permission part is harder than the building part. We have spent twenty years training senior security people to be careful, methodical, and slow. Those instincts are correct for incident response and wrong for product experimentation. Both are now part of the job.

What the Org Did With It

The agent I built was not the interesting part of the story. The interesting part was what happened next.

A senior R&D engineer used it for a threat modeling question, found the answer slightly off, and rewrote a chunk of the prompt. A security engineer added a feature to pull from a knowledge base I had not connected. Another teammate forked it for a different use case entirely. By the third week, the thing I had built at five in the morning was not the thing I had built at five in the morning. It was something the team had absorbed, modified, and made theirs.

That is the move I want every security leader reading this to internalize. The CSO building a small thing is not the punchline. It is the permission slip. When the senior person in the function is visibly experimenting, the rest of the team treats experimentation as part of the job. When the senior person is visibly precious about their work or scared to ship something rough, the rest of the team treats precious-and-scared as part of the job.

You set the tempo. The tempo for the next decade is faster than the one we trained ourselves on.

The Real Reason This Matters

I am writing this for the security leaders who have not opened a coding tool in five or ten years and have decided, somewhere underneath their conscious decision-making, that this part of the job belongs to other people now.

It does not.

The threats are moving faster. The adversaries are using these tools to compress the time from idea to weaponized capability. The teams that win the next five years will be the ones whose senior leaders are inside the loop of building, not just directing. Not because every CSO needs to ship production code. Because every CSO needs to know what is now possible in a morning, what is now possible in a week, and what is now possible at all. You cannot calibrate that from the outside. You can only calibrate it by trying.

The shoulder is healing. The agent is now better than the version I built. The team has moved on to the next thing. What I am holding onto, the part I am writing this to share, is what it felt like to remember.

Build something. The job is more fun than we have been letting it be.