In times of uncertainty, focus on principles

Sun, 25 Oct 2026 08:02:34 -0300

I was faced with an interesting question: what does the future of cybersecurity look like over the next two years, given that AI models are improving exponentially?

Honestly, we are still figuring out what the present looks like. Just this week we had at least ~~five~~ six¹ high-profile security incidents and vulnerabilities that made the news. It feels like things are already out of hand today. How can one even begin to prepare for the future?

How can we secure our software properly when there are swarms of tireless agents with near-infinite knowledge ready to poke around everything until they find a hole?

To try to answer these questions, I need to draw a parallel with how AI changed software development.

Everything is changing …

Three years ago, it would have been impossible for the average developer to anticipate the changes that the world of software would go through.

I never imagined my beloved editor would become read-only. I never imagined that most of my daily interactions at work would be with bots. And I certainly never imagined I’d be able to build entire features while walking my dogs.

So what actually changed? New tools. Harnesses. Prompt engineering (gone already?). Context gymnastics (still relevant?). MCPs. An infinite number of bots and assistants.

Perhaps the most exciting change, though, is the rise of agentic and autonomous behaviors, such as continuously looping on a particular issue until a solution is found. Claude never rests, except when its usage limit is hit.

… yet some things haven’t changed

Watch one of those loops closely and ask yourself what the agent is doing. It reads some code. It looks up existing documentation and surrounding functions. It makes a change. It runs the tests. If they fail, it reads the output, figures out why they failed and tries again. Once they pass, it opens a PR, and a human (or another bot) reviews it. After the merge, the change goes to production.

Sounds familiar? It does to me – it’s what I did every day for over a decade. And what made me productive is also what makes AI productive today.

AI can change a specific part of the code without understanding the whole because the code has boundaries. It knows what it can safely change because there are contracts. It knows when it broke something because there are tests that catch regressions. It can try again in seconds because the feedback loop is fast. It understands business rules because there is documentation. It can deploy a change to production within minutes because the pipeline is efficient.

Clear boundaries. Explicit contracts. Good test coverage and documentation. Fast feedback loop and deployment pipeline. Behind each of these are principles that existed long before LLMs, and they are as important in 2026 as they were in 2006. Or maybe even more important today.

In fact, they matter more than ever

A software project needs the proper building blocks to unlock the full power of agents. Take the feedback loop, for example. I actually wrote about it in a previous blog post:

“The feedback time, that is, the time it takes for a developer to iterate between making changes and observing the changes is the single, most important individual productivity metric you should monitor.”

Well, in 2026 we should replace “developer” with “agent”, but my point is the same.

Why are these principles more important today than, say, five years ago? I believe it’s mainly due to potential agentic reach.

Before LLMs, the average developer maybe opened a couple of PRs per week. Now that “code is cheap”, a developer armed with a few agents can open dozens of PRs per day. GitHub’s infrastructure can barely keep up.

That’s today. Two years from now, it may very well be the case that the vast majority of commits and PRs are fully autonomous, with no human in the loop. Maybe a single project will see hundreds of PRs each day, automatically chasing newly created Jira tickets or any anomaly seen in logs or exceptions.

And while today it seems like human code review is the bottleneck, a few years from now that step may no longer require a human, and what will matter is how productive and efficient an agent can be at delivering correct, verifiable work on its own.

That’s what I mean by potential agentic reach – how much useful work an agent can accomplish, and how quickly, without requiring human intervention. And the foundations of the project play a major role in determining both how far that reach can extend and how quickly agents can get there.

Of course, one could wonder: what prevents a sufficiently intelligent agent from fixing my foundations for me? Nothing, really – and you should certainly have it improve yours. But how well an agent can fix the foundations depends on how solid they already are. Once the basics are in place, each improvement will make the next one easier.

Enter the agentic hacker

But remember, this post is about cybersecurity, not software development! The reason I drew this long parallel is that the software development world got disrupted by LLMs before security did, so it is the closest thing we have to a preview of what’s to come.

Now watch the agentic hacker loop. An attacker’s agent scans and probes your infrastructure or application. It reads the error, adjusts and tries again, endlessly, until it finds something. Mind you, this agentic hacker loop is already a reality.

Do you see the similarities with the development loop? Except this time the agent is working against you. Good foundations extend your agent’s reach and shrink the attacker’s.

Once an attacker finds a hole, what happens next depends on your foundations. Does that vulnerability give them access to one isolated service with short-lived credentials, or your entire infrastructure? Can they move laterally? Can you detect and stop them before too much damage is done? And how quickly can you patch the hole?

That last question is particularly important. Take PHP2Shell, for example. In 2024, the PHP security team had already identified signs of the underlying problem, but couldn’t establish a concrete exploit path. Proposed fixes had serious technical trade-offs, and work eventually stalled. Two years later, AI helped researchers develop working exploits, while the PHP team was still struggling to ship a fix.

And that’s only half of the story. Once the fix was released, how long did it take you to deploy it? Minutes? Days? Or are you still unpatched because you are stuck on an end-of-life PHP version?

Other fundamentals show up in this week’s incidents too. One of eMudhra’s CAs had a private key that was, for more than a year, literally the number 4, exposing many basic and embarrassing process flaws². And at LiteLLM, an exposed key was never revoked, allowing an attacker to take over the release pipeline and push backdoored releases to PyPI.

These are different incidents with familiar engineering lessons: independent verification, least privilege, defense in depth, the ability to confidently change an existing codebase – in other words, the importance of getting the fundamentals right.

Bet on what endures …

I’ve made a few predictions, but I wouldn’t bet on what cybersecurity will look like two years from now. Even if LLMs magically plateaued tomorrow, we’d spend years catching up with what they can already do today.

I will bet on principles, though. They have been, they still are, and they will remain the building blocks that determine how far agents can go – yours and your attacker’s. At least for the foreseeable future, whatever that means.

And while that may sound like an obvious thing – of course we should focus on best practices!³ – let’s ask an honest question: how many times have you thought “this is not good” or “this is such a hack” at a former or current company? Or even on your own work device?

We’ve been getting away with those hacks for years. So what changed? Certainly not the principles, as we’ve seen. But the economics around security have changed.

… and adapt to the new reality …

Before LLMs, security was priced on the assumption that skilled attackers have limited time and resources. A skilled attacker costs money, gets tired and has to pick their targets carefully. Automated scans were generally not sophisticated enough to find complex vulnerabilities on their own. Most bugs would never get exploited because nobody would pay attention to them. To a certain extent, security by obscurity seemed good enough for most companies.

Now that’s no longer the case. Velocity, persistence and sophistication have changed permanently. This is the new reality, and either you adapt or you risk being caught off guard. We weren’t given much time to prepare for agentic hackers, even though we’ve had decades to get the fundamentals right. And with most companies still sitting on mountains of tech debt, we are in for a bumpy ride.

Adaptation is both bottom-up (starting from you) and top-down (starting from your employer).

Let’s take a simple example. Do you have production access to your infrastructure from the same OS in which you run pip install? Do your agents have access to local files and credentials? Are you logged in to your logging provider in the same browser profile you are using to read this very post? That’s an awful lot of trust placed in a single environment – compartmentalize!

… in which everyone is resourceful

Of course, companies need to adapt as well. Most companies overlook security. “It won’t happen to us”. “No one will look into this obscure bug”. “We don’t have the resources”. Management needs to wake up. These excuses don’t hold anymore, and the longer companies take to act on both their (lack of) security and their pile of tech debt, the worse the outcome for them.

Ah, “we don’t have the resources”, my favorite excuse in corporate America. Everyone is more resourceful now – your attacker, your competitor and you. The bar for security has been raised. If you genuinely can’t afford to meet it, you need to acknowledge the risk you are accepting, including the possibility of your entire database ending up in some leak from an extortion group.

Assume your infrastructure is being probed around the clock, so you should probe it from the inside to catch issues before attackers do. Same for your application – someone is pentesting it constantly, so you should be too.

Similarly, you need autonomous agents scanning your containers, logs, exceptions, commits and Jira tickets to automatically detect, raise and help fix critical security issues.

More importantly, you need to clear the way for those agents to be effective. Get rid of the tech debt that makes your software difficult to change. If your agent finds a critical vulnerability but it takes you months to patch it, you’ve lost the race. Once again, your agentic reach is limited by the foundations of your systems.

Unsurprisingly, this all takes place on top of basic, old and well-known principles. The principles haven’t changed. The cost of ignoring them has.

For comments, please see discussion on Hacker News.

PHP2Shell. TiDB leak. eMudhra incident. LiteLLM. GitLab. Brotli. ↩︎
Worse, in June 2025 there was another eMudhra incident in which CRLs were signed with an incorrect private key, resulting in invalid ECDSA signatures. Did anyone wonder why there were two private keys for the CRLs? Isn’t that a red flag that something was fundamentally wrong with their processes? ↩︎
It’s worth distinguishing principles from best practices. My take is that a best practice is an implementation of a principle. Best practices change over the years, whereas principles rarely do. For example, human code review is a best practice today, but it might not be tomorrow. The principle behind it – independent verification – will still be relevant if (or when) agents replace humans in code review. ↩︎

Software Engineering on Renato's Runtime Reflections