For solo security engineers and small teams, the workflow is no longer “find the vulnerability, file the ticket, wait for a developer.” One practitioner’s account of what it looks like now, what it costs, and what humans are still needed for.

By Alex Farhadi

Intro

With the right AI tooling in my IDE, security engineering does not look like it used to. I do not just find vulnerabilities anymore. I fix them. I generate the code change, write the test case, and open the PR myself. Across app code, Terraform, Kubernetes manifests, CI configs.

This piece is for the small and medium-sized companies. For the builders, the solo security engineers, and the small teams trying to keep the lights on without burning out. If you are in a massive enterprise with a fifty-person security team, this might not apply to you (though maybe it should). And to be clear, I am writing about Security Engineering specifically: building things, fixing code, architecture. Not SecOps, not staring at dashboards, not responding to alerts at 3 AM.

Pull Quote: I do not just find the issue. I fix it.

My Background

I have always worked at early-stage startups and smaller tech companies, usually as the solo security person or on a tiny team. I spent years as a sysadmin and site reliability engineer before moving into Security Engineering, where I have focused on pentesting, cloud security, and container security. That history gave me a wide breadth of knowledge across systems, networking, security, and infrastructure. While I have always written code for automation and tooling, the role has evolved. I no longer just call myself a Security Engineer. I honestly consider myself a Full Stack Developer. The tooling has finally bridged the gap, allowing me to build and ship production-ready code across the entire stack rather than just scripting or advising.

How The Job Has Changed

1. No more Jira volleyball. This is the biggest quality-of-life improvement, period. In the old days, security engineering was a lot of nagging. I would find a vulnerability, write a ticket, assign it to a dev, and wait. And wait. Maybe I would have to beg a product manager to prioritize it. With AI tooling I am not asking permission or waiting for resources. I am shipping the fix.
2. Instant context. If I had to secure a codebase I did not know, I would spend days digging through files or bugging the lead engineer just to understand how the data flowed. Now I can drop into a repo, ask the AI to map out the authentication flow, and understand the context in minutes. It turns a “specialist” into a “generalist” who can actually execute. I might not know Go perfectly, but my AI tools do, so I can secure it.
3. Code review in real time. Deep manual code review used to be a luxury I did not have time for. Now I have an AI buddy that sits in the IDE with me. We go through code together. I can ask, “What edge cases are we missing here?” or “Generate a payload to test this input.” It is like having a specialized superhacker looking over my shoulder.
4. The hard truth about team size. I have to be honest about the impact here. In my experience, this efficiency comes at a cost to headcount. What used to take three security engineers, in the kind of small-team environments I work in, can now be done by one solid generalist who understands the full stack (networking, CI/CD, infra, code) and knows how to wield AI. The leverage is too high to ignore. Whether that pattern holds at larger organizations or in mature security functions is a different question, and one I cannot answer from where I sit.

The Toolkit

The Brains (ChatGPT, Gemini). For bouncing ideas around. High-level architecture plans, threat modeling sessions where I play both sides, sanity-checking my logic.

The Hands (Cursor, AI IDEs). Where the real work happens. Static analysis, code tracing, understanding a repo I have never seen before, and fixing the bugs.

The Pentesting Buddy. An AI buddy that sits in the IDE with me. We go through code together. “What edge cases are we missing here?” “Generate a payload to test this input.”

What Humans Are Still Needed For

If the AI writes the code and finds the bugs, why am I here?

The Business Interface. AI cannot explain to the CFO why we need to buy that tool, and it cannot navigate office politics. Someone still needs to translate “XSS” into “business risk.”

Risk Interpretation. An AI sees a CVSS 10.0 and screams “Critical.” A human sees that the server is behind a VPN with no external access and knows it can wait. Conversely, we spot the “Medium” bugs that are actually business-ending logic flaws.

The Puzzle Builder. AI creates the puzzle pieces (PRs, scripts, configs), but someone has to put the puzzle together, coordinate the deployments, and make sure we are not breaking prod.

Pull Quote: AI cannot explain to the CFO why we need to buy that tool, and it cannot navigate office politics.

Real Life Examples

The Dependabot nightmare. I had 200+ Dependabot alerts. Old me would have cried. New me used Cursor to ingest the findings, generate the bumps, verify the tests passed, and merge. Done in an afternoon.

Code-assisted threat modeling. Instead of taking days to read through code, or scheduling time with developers, I ask the code. “Where is the auth logic?” “What injections would you try against this API?”

Fixing the unknown. I had a Kubernetes error in a manifest I had never touched. I pasted the error into the IDE and it told me exactly which environment variable needed to be added to fix the issue. Five minutes versus two hours of Googling.

Pull Quote: I want to wake up to a notification that says “I fixed 5 things last night,” not “Here are 5 new tickets.”

What I Want To See Next

“Security Context” files. Just like a .gitignore, I want a standard file where I can define the rules of the road for the AI: what is sensitive, what is public, what our encryption standards are. So it knows the context before I even ask a question.

Auto-pilot for the boring stuff. We are close to a world where low-risk vulnerabilities (config tweaks, minor patches) are identified and fixed by the AI without me ever touching a keyboard. I want to wake up to a notification that says “I fixed 5 things last night,” not “Here are 5 new tickets.”

More generalists, fewer paper pushers. One of my long-time gripes with security people is that they can only point to things that are problems. If you cannot also fix things, you need to start.

Better dynamic analysis automation. Pentesting used to be a very specialized skill. Dynamic scanners were terrible and would only catch things like incorrect security headers and very obvious SQLi or XSS. We are getting close to a fully automated pentester I can put in the pipeline on every build.

About The Author

Alex Farhadi is a Staff Security Engineer with a multidisciplinary background spanning site reliability engineering and full-stack development. A lifelong practitioner who began exploring computer security at age 13, he specializes in a broad technical spectrum that includes API penetration testing, cloud infrastructure security, and regulatory compliance.