From the SOC to the Stack: What 12 Years in Security Operations Taught Me About Building in the Age of AI

I spent twelve years in enterprise security operations. EDR platforms, firewalls, WAF configurations, SIEM tuning, SOAR automation pipelines, XDR deployments, the full stack of keeping organizations from getting breached. I wrote Bash scripts to automate log parsing at 2am. I wrote PowerShell to push policy changes across thousands of endpoints. I wrote Python to pull from threat intel APIs and feed them into detection rules.

I was not a developer. Or so I told myself.

Now I’m building internal security tooling, real products, using the same Claude APIs, Anthropic SDKs, and cybersecurity vendor APIs I’ve been staring at from the other side of the glass for over a decade. And I’m learning TypeScript, React, and Go alongside Python as actual development languages, not just scripting tools.

What surprised me most wasn’t how hard the transition was. It was how much of what I already knew transferred directly, and how the mindset that security operations builds is, in many ways, the exact mindset the age of agentic AI demands.

The World You’re Walking Into

Let me be clear about what “agentic engineering” actually means, because it’s not just a buzzword.

AI coding tools started as autocomplete. Then they became copilots. Now they’re evolving into autonomous agents, systems that can plan, implement, test, and iterate on entire features with minimal human input. The question is no longer “can AI help me write code?” It’s “how do I run a team of AI agents like a technical director, not a passenger?”

For people entering development from IT, operations, or security backgrounds, this is genuinely good news. Because the skills that matter most right now aren’t syntax. They’re judgment, systems thinking, and governance. And if you’ve spent any time in a SOC or an ops center, you’ve been building those muscles for years.

The new engineering lifecycle doesn’t look like the old one. Traditional development flows from idea to code to review to deploy. The agentic model looks more like:

Idea → Spec → Agent Execution → Review → Merge → Observe

You’re no longer the one writing every line. You’re the one defining intent, setting constraints, reviewing output, and governing the system. Sound familiar? It should. That’s what a security operations engineer does every day, except the “agents” were SIEM rules and SOAR playbooks.

Why Your Security Background Is a Superpower Here

Here’s something nobody tells beginners entering development through the AI-assisted path: most developers learn security the hard way. They ship something, it gets breached or abused, and then they retrofit controls. The security thinking comes last.

You already have it first. That’s a massive advantage.

When AI agents generate code, they generate it fast, and they generate vulnerabilities just as fast. A model asked to “build a login flow” will often hardcode secrets “just for testing” and forget to remove them. It will install dependencies without auditing them. It will skip error handlers. It will generate API endpoints that look right but don’t validate input properly.

Your instinct to ask “what’s the attack surface here?” before anything else is exactly the right instinct. Here’s how it maps to the agentic development world:

Supply chain paranoia. In security, you know that a single compromised library can take down an entire organization. The same applies to AI-generated code. When an agent installs an npm package, you need to read the package name before it runs. Never let an agent run npm install on something you haven’t verified. In 2024, the xz backdoor incident showed what a compromised dependency looks like. In the AI era, these attacks will become automated.

Secrets management. AI agents will put your API keys in places they shouldn’t be: GitHub issue comments, hardcoded in test files, printed to console logs. This isn’t malice; it’s the model optimizing for getting the task done. You need pre-commit hooks that scan for secrets before any code leaves your machine. Tools like gitleaks should be mandatory in every project. If a commit contains something that looks like an API key, it should fail. Period. If a key does leak, your incident response is simple: revoke it immediately, rotate it, check the logs, then write a post-mortem asking why the agent had access to that key in the first place.

Least privilege for agents. The same principle that governs your service accounts governs your AI agents. Never give an agent production write access without explicit approval gates. In 2025, an AI agent with full write access deleted a production database containing over a thousand executive records, then tried to cover it up by fabricating test results. Read-only database access, scoped permissions, human-in-the-loop gates for anything that modifies state. These aren’t optional.

MCP attack surfaces. Model Context Protocol (MCP) lets AI agents interact with external tools, your filesystem, your browser, your databases. It’s powerful and it’s an attack surface most new developers completely ignore. A “tool shadowing” attack demonstrated in late 2025 showed how a malicious MCP server could register a higher-priority version of a standard tool like readFile, silently exfiltrating data before returning it. Whitelist your tools. Dockerize your MCP servers with network isolation. Never connect to community MCP servers you haven’t audited yourself.

You know all of this. It’s just a new context for principles you already internalized.

The Framework: How I Actually Work

Here’s the workflow I’ve built, synthesized from what’s actually worked for me and from the best thinking I’ve found on agentic development.

Two Lanes: Exploration and Production

The single most important structural decision is running two separate lanes in parallel.

The Exploration Lane is for speed. This is where you use tools like Replit, RooCode, or similar rapid prototyping environments to spike ideas, test approaches, and build throwaway proof-of-concepts. Low governance, high velocity. No restrictions on how fast you move. The rule is: nothing from the exploration lane goes to users.

The Production Lane is for control. This is where real work lives: a project management tool like Linear as your source of truth, spec-driven development before any code is written, multi-agent orchestration with defined roles, automated code review, security scanning on every pull request, and monitoring in production. High governance, sustainable velocity.

This separation prevents experimentation from destabilizing your production systems. Every feature that proves valuable in the exploration lane gets promoted into the production lane, starting fresh with a proper spec, not with the prototype code.

Spec Before Code

Nothing gets built without a spec. A spec doesn’t have to be long. It needs a problem statement, a success metric (one number), the scope of what you’re building, and explicitly what you’re not building. This document becomes the anchor for everything an agent does. Without it, agents optimize for “completing the task” rather than “solving the problem,” and those are different things.

Defining Your Agent Team

Think of your AI agents as specialized team members with distinct roles, just like your SOC had L1 analysts, L2 investigators, and incident commanders.

An Orchestrator agent plans and delegates. It reads your spec and breaks work into tasks. An Architect agent handles system design and data modeling. A Coder agent does the actual implementation with minimal diffs and test generation. A Reviewer agent checks for security flaws, performance issues, and correctness. Each role maps to a different model capability and context need.

The goal isn’t to use one AI for everything. The goal is to route the right task to the right model, the same way you route alerts to the right analyst tier.

Automated Gates That Don’t Move

Before any code merges, it passes through gates that aren’t negotiable. Local gates: linting, type hints, real-time feedback. Pre-commit gates: formatting, linting, typechecking, secret scanning. CI/CD gates: full typecheck, unit tests, integration smoke tests, build verification, dependency audit, static analysis security scanning. If CI fails, the pull request doesn’t exist. That’s the rule.

For Beginners: The Honest Truth About This Path

If you’re early in your technical career and you’re looking at this landscape wondering how to break in, here’s what I wish someone had told me.

You do not need to memorize React hooks to be a valuable engineer in 2026. You need to be able to look at a diff generated by an agent and spot the security flaw. You need to be able to look at a proposed architecture and identify the bottleneck before it becomes a production incident. You need to understand what “race condition” means even if you never write the code that causes one.

The cost of generating code is dropping toward zero. That means the value of verifying code (reviewing it, questioning it, stress-testing its assumptions) is going to infinity. The people who will be valuable are the ones who can evaluate output quickly and accurately.

The technology stack will keep changing. Claude Sonnet, Cursor, Windsurf, whatever tools dominate next year, those will evolve. The underlying discipline won’t: define intent clearly, govern execution carefully, observe outcomes relentlessly, and maintain responsibility for everything that ships with your name on it.

That last part matters. Even if you didn’t write a line of the code, if you deployed it, it’s yours. Own it.

The Bigger Picture

Security operations taught me that you can’t control every threat, but you can build systems that detect, respond, and recover faster than the attacker can move. Agentic engineering works the same way. You can’t catch every hallucination, every bad dependency, every logic flaw an AI produces. But you can build a system (a workflow, a set of gates, a culture of verification) that catches most of them before they reach production.

The engineers who will win in this environment aren’t the ones with the most AI tools. They’re the ones with the best structured workflows and the clearest thinking about where humans need to stay in the loop.

I’m twelve years into understanding how systems fail and how to build controls that make failure survivable. Turns out that’s exactly the job description for an agentic engineer.

The SOC and the stack aren’t that different. You’re just defending a different kind of infrastructure now.

Building internal security tooling and exploring agentic development workflows. If you’re coming from an IT/security background and navigating the same transition, I’d love to connect.