Your Developers Outnumber Your Security Team 80 to 1

Somewhere in your org there is roughly one security engineer for every eighty developers.

Maybe it’s 1:60 on a good year, 1:120 on a bad one. The exact number doesn’t matter. What matters is the shape of it. One person, or one small team, is accountable for the security of code, infrastructure and agents produced by a group nearly two orders of magnitude larger.

The instinct (and I’ve watched a lot of smart people have this instinct) is to read that number as a hiring problem. We’re understaffed. We need to grow the team. Get me two more security engineers, and we’ll close the gap.

I don’t think that will solve anything. I think it’s worse, and I think it’s even more interesting.

Staffing gaps close when you hire. This one widens.

Here’s the part that changed in the last two years.

Every developer in that group of 80 is now an AI-amplified output machine. Pick the tool they use to write code, agents, infra and docs; it doesn’t matter which. The point is that a single engineer today ships more code, touches more infrastructure, and generates more surface area than the same engineer did eighteen months ago, and the line is going up and to the right.

Now look at the other side of the ratio. Security engineering headcount is flat. Not because you don’t want to hire, but because good security engineers are rare, expensive, hard to keep, and even a great hire spends weeks getting to net-positive against a backlog that grew the entire time you were recruiting.

So, one side of the ratio is growing fast, and the other side is growing slowly, if at all. That is not a gap. A gap is a fixed distance you can march across. This is two curves diverging. It gets wider every quarter you do nothing, and (this is the uncomfortable part) it gets wider faster the more successful your engineering org is. In early days this gap is ignored; soon after it becomes too large to close it.

I’m an engineer at heart, and I’ve seen this exact shape before. It’s a system where load grows exponentially faster than the capacity serving it. You don’t fix that kind of system by adding a couple more servers. The math doesn’t care how hard you’re working. You have to change the architecture.

Your org chart is the architecture here. And the architecture has a hidden assumption baked into it: that a human being reviews the security-relevant work. That assumption held when the ratio was 1:20, and code was written at human speed. That quietly broke, and most orgs haven’t updated the design.

Three responses we see over and over again.

Once you accept the ratio can’t be hired away, there are really only three responses, and I’d bet you recognize all of them:

1. Try to hire out of it anyway. The market’s dry, comp is brutal, and the curve outruns you regardless. This is the honest attempt that doesn’t work.
2. Slow the developers down. Nobody accepts this, and shadow AI usage means you couldn’t enforce it if they did. This is the answer that sounds responsible and isn’t feasible in reality.
3. Quietly ignore the risk. Review coverage drops, the queue gets triaged harder, and nobody says out loud that a growing fraction of what ships was never actually looked at. This is what most organizations are doing right now, whether or not they’ve admitted it.

None of those change the math. Two of them just make you feel better about not changing it.

The only variable you control is leverage.

The one move that actually bends the curve is changing what a single security engineer can cover. Do not replace them; anyone selling you “no more security engineers” is selling you a story. Instead, amplify them. Give the one person leverage over the eighty; so that detection engineering, infrastructure review, and remediation scale with the code instead of falling behind it.

This is the only answer that survives contact with the math. Engineers like problems with clean fixes, and this isn’t one you can buy your way out of with headcount. But the ratio isn’t going back to 1:20, and the output side only accelerates from here. The one thing you actually control is how much a single engineer can reach.

That’s the problem worth solving. Everything else is triage on a queue that grows while you sleep.

Eno Thereska, engineer at heart, building Trent.