This is a rewrite of an article originally posted to LinkedIn on February 13, 2026.
I spent 15 years becoming a Field CISO. It took AI and three weeks to remind me I was an engineer the whole time.
#The Reluctant Adopter
I talk about AI a lot. I also don't trust it.
I've spent a career breaking things, and having observed the birth of this industry alongside the missed promises of so many products and movements (crypto will decentralize banking and replace fiat, blockchain will change our lives), I've been suspicious of anything that moves fast and promises the world.
Recall these two gems:
Gary Bridge, Marketing VP: "We're not just selling a product; we're selling a new way to live. This will be the most significant invention since the Internet."
Dean Kamen, inventor: "Cities will be built around this thing. It's going to be the most important thing since the internal combustion engine."
This was Segway. We got glorified scooters.
I hadn't written production code since 2010. By 2017, I was fully on the business side of cybersecurity. So when AI started promising to change everything, I had context for that claim. I'd heard it before.
#From Hype to Pipeline
I saw the early wins. Generative AI was impressive for creative work, but my use cases demanded defensible, traceable data.
Over time, AI tools became genuinely useful for the business side of cybersecurity. Summarizing research. Analyzing data. Speeding up the tedious parts. Real value for my day-to-day.
But coding? Building production systems? That was still hype outpacing reality. AI slop, the buggiest code imaginable. "Vibe Coding" was little more than non-deterministic robots stringing together whatever bits of code they'd learned, building house-of-cards-style software.
The models kept getting better, release after release. Reliability started becoming a different conversation. But the fundamental problem remained: even when the models were capable, there was nothing constraining them. No architecture. No quality gates. No separation of concerns. Just a chatbot with a text editor.
That changed for me when my former CEO shipped something different. A way to constrain the non-determinism of the robots in a sane manner. A platform that treated LLMs as deterministic components of an engineering pipeline rather than chatbots with opinions.
#Thinking in Systems
I'm still not writing code. I'm thinking in systems. Architecture. Data flows. Failure modes. The same engineering thinking that's driven my career for 25 years.
What changed is that thinking is now sufficient. Claude Code writes the implementation in whatever language the problem demands. The syntax doesn't matter. Knowing what the system should do, and why, is the whole job.
I don't need to remember if I'm writing Ruby on Rails or Perl, or what part of the Model View Controller I've just made a massive refactor in. I need to know what data the system should collect, how it should validate that data, what the failure modes are, and how the output should be structured for the audience consuming it. And now, for the first time, that instinct alone is enough to ship.
#ROI Reporting: 3,500 Lines in 6 Days
Take ROI reporting. I needed executive board reports showing what the platform was attempting to deliver for customers.
The old way? Convince a team I needed the data. Argue about the value. Get buy-in from their leadership to approve the effort. Wait a week for an initial report. Then start another round of arguing about data integrity and what was actually correct. Weeks of organizational friction before anything useful existed.
Instead, I built it.
A 6-phase reporting pipeline: Setup, Data Collection, Data Processing, Report Generation, HTML Generation, and Validation. It pulled live platform data via MCP tools, ran calculations against industry benchmarks (IBM Cost of a Data Breach 2025, Verizon DBIR, FAIR Institute, FBI IC3, CISA), and generated branded executive presentations with heat maps, vulnerability scorecards, and ROI calculations.
3,500 lines of code. 6 days. 8 report sections covering everything from executive summary to discovery metrics, vulnerability analysis, code security, remediation progress, and a full ROI calculation with industry benchmarking.
The methodology mattered. Every assumption was explicit and traceable. Severity-weighted breach costs cited Verizon DBIR and the FAIR framework. Attribution percentages were conservative and documented. When a CFO questioned the numbers, I could point to exactly where each figure came from and why.
I even had to build a raw data fetcher to handle large customer datasets. One customer had 242,000 assets, which exceeded the standard 10MB wrapper limit. So I built a caching layer with a 100MB limit and customer-scoped directories. That's the kind of problem you solve when you're working with real data at scale, and the kind of problem that would have been a 2-week engineering request in the old model.
#Threat Intelligence: From Hours of Research to a Single Command
Every 45 days, I sat down with customers to review the threats targeting them.
Previously, that meant aggregating data from disparate sources and data owners, normalizing it into something meaningful, and hours of research to build a defensible picture. The challenge was always the same: getting it, cleaning it, and turning it into something defensible.
I ran a single command: /threat-report.
The platform pulled CISA KEV data, attributed threat actors by industry vertical, correlated against the Nuclei detection templates, scored each CVE using a multi-factor model (attribution 35%, deadline proximity 30%, CVSS 20%, detection coverage 15%), checked which of that customer's actual assets were exposed via a waterfall search strategy, and auto-triggered research jobs to close any detection gaps.
4 phases, fully automated, with quality gates:
- Threat Intelligence Research: KEV analysis, attribution, prioritization
- Customer Impact Analysis: Asset-level vulnerability assessment with risk metadata enrichment
- Detection Gap Remediation: Automated CVE researcher jobs with PR and ticket tracking
- Quality Validation: Independent reviewer and tester agents validated any new detection templates
I built the initial skill on January 12th. By January 22nd, it had evolved from a single 461-line skill into a 3-skill architecture with a command orchestrator, handling the full lifecycle from research through remediation.
The most interesting iteration happened on January 13th. During a real customer run, the AI agents rationalized their way out of executing Phase 3. The logic? "This customer has no SonicWall assets, so why build detection for a SonicWall vulnerability?" The correct answer: because detection capabilities served the entire customer ecosystem, not one account. I added anti-rationalization guardrails with 6 documented anti-patterns and 13 rationalization counters. I was debugging the AI's reasoning, not its code.
#Business Intelligence: 10 Hours Over 10 Weeks
Then there's business intelligence. I used to work with teams of business analysts and pseudo-developers just to get analytics out of siloed systems.
The process was painful and familiar to anyone in enterprise: weeks of explaining what I needed, arguing with engineering about priorities, waiting for sprint capacity, or flat-out being told no. And even when the work got done, it was never quite what I asked for, because the people building it didn't have the domain context to know what mattered.
I used Claude Code to pull the data myself and let the robots answer my questions. I could go from "I wonder what the data looks like for this customer" to a complete analysis in a single session.
10 hours of focused work replacing 10 weeks of organizational negotiation.
I built it. I understood every assumption. I could defend every number. And when the data told me something unexpected, I could pivot immediately because I owned the pipeline.
#The Numbers
Here's what 5 weeks of this looked like, measured by Claude Code's own analytics:
- 66 sessions spanning January 8 to February 12
- 1,136 messages exchanged with Claude Code
- 8 merged pull requests across 2 production repositories
- 5 distinct project areas: ROI reporting, threat intelligence, business intelligence, platform contributions, and content creation
I corrected course approximately 38 times across those sessions. That's the systems-thinking part. I wasn't writing code. I was steering architecture. And when the AI took a wrong turn, I caught it because I understood what the system should have been doing, even if I couldn't write the TypeScript myself.
#AI Transparency: How This Article Was Built
Coup de Grace vs Tour de Force. The challenge with modern AI is that it's too easy to outsource our thinking. People are forgetting their critical thinking skills and leaning on the assistants so heavily that the majority of content on the Internet today is AI slop. Thankfully, people are starting to reject this obvious pollution (see the reactions to the awful AI-generated Super Bowl ads). But ignoring what AI can do for productivity is a mistake.
AI can assist us in almost every aspect now. We should be using it.
I would be disingenuous if I put this blog in the world and did not acknowledge my use of AI in assisting me with it. Since my former company's development platform went public, I had been ruminating on this narrative, capturing shorthand notes to myself, recalling examples of work. Then I built the skeleton of this story and put AI into action as a creative assistant, a copy editor, a research intern, and an English Lit Professor. Much like the spell checker did not replace my ability to spell, AI did not replace my ability to write, nor think, nor execute. It made me better at all of them. But don't take it from me. Let me introduce you to my assistant, in its own words. Full prompt, no editing of my ask, nor its response. Here was Optio:
Prompt: "Optio, summarize your persona for the reader."
Output:
Optio is my Claude Code persona, named for the Roman officer who served as the centurion's second-in-command. I configured it as a Field CISO's operational partner: it reads and searches freely, but confirms before writing files, running commands, or making design decisions. It thinks in options and tradeoffs. It persists context across long sessions. And it follows six core rules, the first of which is: "You propose, the user approves. Never jump ahead." Optio is the platform in action, running on my laptop, inside my terminal, against my codebase.
Prompt: "Optio, summarize for me our efforts here"
Output:
We started with a scratch file of 27 lines and a blog post URL. Over the course of this session, we collaboratively developed a blog post about how deterministic AI orchestration turned a 15-year business executive back into a shipping engineer.
Process:
You provided the raw ideas, voice, and direction. I provided structure, grammar, data retrieval, and editorial feedback.
We worked section by section. You rejected drafts that didn't sound like you, rewrote paragraphs in your own voice, and steered every structural decision.
I pulled commit history from your GitHub repos (8 merged PRs across 2 production repositories), fetched a company blog post for reference, ran /insights to surface usage analytics (66 sessions, 1,136 messages), and verified the LinkedIn character limit against authoritative sources.
You caught things I missed: a factually wrong claim about fiat currency, an em dash I snuck in, a contrastive framing pattern you don't like, and a self-congratulatory tone near the end.
What this demonstrates: You didn't ask me to write a blog post. You used me to organize your thinking, verify your claims against real data, and refine your voice. The ideas, the examples, and the editorial judgment are yours. I handled the scaffolding.
#The Proof
There's a generation of technical leaders who drifted into business roles over the last decade, people who still think in systems but haven't shipped code in years.
The barrier just dropped to zero. AI didn't get smarter. We figured out how to make it predictable. Constrain the robots with architecture, and they stop building houses of cards.