What happens when the work that made senior security engineers valuable also becomes the work we automate?
Something is changing in security engineering.
For much of my career, one of the hardest parts of the job was vulnerability investigation: taking attacker-controlled input, following it through an unfamiliar system, and working out whether it could eventually do something it shouldn't.
The difficult part was rarely knowing that a pattern was dangerous. It was knowing where to look.
That intuition compounds over years of doing the work. You learn which paths deserve attention, which assumptions are worth challenging, and when something that looks harmless deserves another hour.
For a long time, that was a meaningful advantage. I think the economics of that advantage are starting to change.
Finding impactful vulnerabilities is one of the core responsibilities of a security engineer. The exact work varies between product security assessments, code review, penetration testing, red teaming, and vulnerability research, but much of it contains the same two ingredients.
The first is knowing security. You need to recognize bug classes, understand why certain patterns are dangerous, reason about trust boundaries, and know how software tends to fail.
But in my experience, that isn't where most of the time goes.
Most of the time goes into investigation.
You start with attacker-controlled input and follow it through parsers, services, RPC boundaries, and unfamiliar internal frameworks until you understand enough of the surrounding system to answer a few simple questions. Can the attacker really control this value? Can this path be reached? Does a security check happen before or after the dangerous operation? Does the behavior actually matter?
The problem is that there are always more paths than there is time.
So experienced security engineers get good at allocating attention. You learn which thread to pull and which one to abandon. A less experienced engineer might investigate ten plausible paths and discover that nine go nowhere. A more experienced one may discard several of those paths much earlier.
That isn't magic. It's accumulated experience.
For a long time, scarce human attention made that experience extremely valuable.
Vulnerability investigation is becoming much easier to automate.
The important change is not simply that a machine can read code faster. It is that automation changes the cost of exploring another hypothesis.
A human reviewer constantly has to make choices. Is this suspicious enough to justify another hour? Should I keep following this path? Is it worth spending the afternoon learning this subsystem?
Those decisions exist because our attention is expensive.
Automation operates under a different constraint. It can open another file, follow another call, test another assumption, and explore several hypotheses at the same time.
It will still get things wrong. It will misunderstand code and produce false positives.
But that is not the threshold that matters.
Automation does not need to outperform an experienced security engineer at every investigation for the role to change. It only needs to make the next investigation cheap enough to run.
For years, part of senior security expertise was knowing where not to spend time. When looking in the wrong place becomes cheap, some of that advantage changes.
There is an obvious objection.
Today's systems still struggle with business logic, distributed state, incomplete context, novel protocols, and product assumptions that exist nowhere in the code. The cases where understanding what the product is supposed to do matters more than understanding what a function does remain difficult.
I don't think you can hand a complex product to an automated system and consider the security assessment done.
That isn't the argument.
The shift becomes meaningful much earlier.
If automation handles enough routine investigation that a security engineer no longer spends most of their week manually exploring plausible code paths, the difficult problems remain, but the human spends proportionally more time on them.
That alone changes the job.
My instinct is that some of that work moves upstream.
If proving individual vulnerabilities becomes cheaper, preventing entire classes of them becomes relatively more valuable. That means getting involved earlier in architecture, threat modeling, trust boundaries, API design, hardening decisions, and secure platform primitives.
Instead of repeatedly finding authorization mistakes, help design an authorization model where making the mistake is difficult. Instead of reviewing unsafe uses of the same API, change the API. Instead of proving that attacker-controlled input can reach a dangerous operation, ask why the architecture allows that path to exist at all.
This is still deeply technical work. The unit of impact simply changes.
Finding one vulnerability improves one path.
Changing the design can remove thousands of potential paths.
There is another part of security engineering that becomes more important as investigation gets cheaper: judgment.
Imagine an automated assessment produces a large number of technically valid findings.
Which ones matter? Which represent meaningful customer risk? Which should block a launch? Which deserve months of engineering effort? Which are technically exploitable but practically irrelevant?
Automation can help answer these questions too, but an organization still needs someone to own the decision.
A system can produce an answer.
Someone still has to decide whether that answer should change what the company does.
This is where the argument gets uncomfortable.
If vulnerability investigation becomes less central to the job, we may also be automating away part of the process that taught security engineers how to become good.
I developed much of my judgment by doing the work, not only from the vulnerabilities I found, but from the ones I didn't. The dead ends. The assumptions that turned out to be wrong. The issue that looked severe until I understood the surrounding architecture. The harmless-looking behavior that became interesting only after following it into another subsystem.
Those experiences build intuition because they repeatedly teach you what matters and what doesn't.
So there is a tension here.
We may need future security engineers to spend more time exercising judgment. But what if vulnerability investigation was one of the primary ways we learned that judgment?
Telling a junior engineer to "focus more on architecture" does not solve the problem. Architecture requires context. Risk decisions require experience. Good judgment usually comes from seeing enough systems behave in ways you did not expect.
If we automate much of the work that provided those repetitions, we need to think seriously about what replaces them.
Today's senior engineer often has an advantage built from thousands of small investigations. They have seen enough systems to recognize patterns early, know when a finding matters, and reason about consequences that are difficult to capture in a rule or test case.
If the next generation performs fewer of those investigations manually, we cannot assume they will arrive at the same intuition through a shorter path.
Perhaps automated systems become training partners. Perhaps junior engineers spend more time reviewing machine-generated investigations and challenging their conclusions. Perhaps we intentionally preserve hands-on investigative work because it has educational value even when a machine could perform it more efficiently.
I don't know which model wins.
But there is an organizational risk in assuming that automating the work and automating the learning are the same thing.
They aren't.
A colleague and I recently discussed whether the Security Engineer role becomes more clearly split between two specializations.
One side leans further into engineering: building security platforms, improving automated analysis, creating developer tooling, building evaluation harnesses, and finding places where the systems are blind.
The other leans further into security: architecture, threat modeling, product design, hardening decisions, and helping engineering teams make better decisions before implementation begins.
This split already exists to some degree. It may simply become more pronounced.
There is also a human side to this transition.
Some security engineers love the puzzle. I do.
There is something deeply satisfying about starting with a strange behavior, disappearing into an unfamiliar system, and eventually understanding something nobody else noticed. For some engineers, that is not merely part of the job. It is why they chose it.
If more of that investigation becomes automated, not everyone will be excited about moving toward architecture, platform engineering, or risk decisions.
Some will move toward design. Some will build the systems doing the investigation. Some will focus on the problems those systems still cannot solve. And some may decide that the new version of the job is no longer the one they wanted.
That is part of the transition too.
I used to think one of the defining skills of a senior security engineer was knowing where to look.
After years of investigating systems, you develop an intuition for which thread deserves your attention. That skill still matters, but the constraint that made it so valuable is changing.
Machines make looking in the wrong place much cheaper.
That pushes the human contribution somewhere else: toward system design, consequence, deciding what matters, and finding the places where automation is wrong.
But there is a catch.
The investigation we are beginning to automate is also part of how many of us learned those skills in the first place.
That leaves me with a question I don't think our profession has answered yet:
If machines become good at the work that taught us to become senior, how does the next generation become senior?
I don't know the answer.
But I think that question matters more than whether a machine can find the next vulnerability.
The craft has changed.
Now we need to figure out how we teach the new one.