How to Choose a Tech Stack in the AI Era: Follow the Patch Velocity, Not the Hype
Direct answer: Don't choose a tech stack for hype or benchmark scores. Choose it for the people behind it: a committed core team, a predictable release and support schedule, a proven security process, and a record of shipping fixes fast when something major breaks. In the AI era, vulnerabilities are being found faster than ever, so the speed of patches, fixes and coordination, which I call patch velocity, matters more than raw performance.
I've been part of plenty of stack debates as a CTO at MarginTop Solutions. Most of them argue about the wrong things: which framework is trending, which runtime wins a synthetic benchmark. After October 2026, I think about this question differently. This post explains why.
Why hype and benchmarks are the wrong starting point#
- Hype fades; maintenance doesn't. The framework everyone is excited about this year may lose its maintainers in three. Your product will still need security patches in year five.
- Benchmarks measure the wrong bottleneck. Most business applications spend their time in the database, the network and third-party APIs, not the language runtime. A 2× faster runtime rarely makes a 2× faster product. We explained this in business logic first, not the perfect stack.
- Performance is fixable later; abandonment isn't. You can add caching, queues or a faster runtime to a well-maintained stack. You can't add a security team to an abandoned one.
What AI changed about security#
Vulnerability research used to be slow, expensive and specialist work. That's no longer true:
- In 2024, Google's Big Sleep agent found an exploitable memory-safety bug in SQLite, one of the most heavily tested codebases in the world, before it reached a release.
- DARPA's AI Cyber Challenge showed autonomous systems finding and patching real vulnerabilities in widely used open-source software.
- At least one of the research teams behind PHP2Shell, two critical bugs in PHP's core engine disclosed in October 2026, used AI models as part of discovery and remediation, according to Google Cloud's write-up.
- Maintainers report the other side too: a flood of AI-generated bug reports, many of them false positives, that still have to be triaged.
The consequence: discovery is no longer the bottleneck. Patching is. Old, quiet code is getting fresh eyes, and attackers have the same tools defenders do. When a critical bug lands, what matters is how quickly the fix gets from the maintainers to your production servers.
Patch velocity: the metric that matters now#
Patch velocity is the time between "a vulnerability is known" and "your production systems are fixed". It has two halves:
- Upstream velocity: how fast the stack's maintainers confirm, fix, release and coordinate with distributions, cloud providers and security vendors.
- Your velocity: how fast your team can rebuild, test and deploy the fix.
You control the second half. You choose the first half when you pick a stack.
Case study: PHP2Shell#
PHP2Shell is a good example of strong upstream velocity:
- Researchers reported privately, and the PHP security team developed fixes under embargo.
- Linux distributions and LTS vendors got the patches early.
- When details leaked a day before the planned disclosure, the team released immediately: four supported branches patched on the same day.
- Cloudflare and Google shipped protections the same day, and the advisories were honest about what was confirmed and what was only suspected.
As dams at Exakat put it in his analysis of how a PHP fix reaches production, "It is quiet coordination, and it worked." On our side, a containerised setup let us patch every project within 24 hours, on the main day of Dashain. Neither half alone would have been enough.
The counter-example from the same incident: teams on PHP 8.1 and older got no official fix. A stack is only as safe as the supported version you're actually running.
How to evaluate a stack: a checklist#
| Question | Good sign | Red flag |
|---|---|---|
| Who maintains it? | A funded foundation or company, with several paid core maintainers | One volunteer, or a company whose business no longer depends on it |
| Is there a published support policy? | Clear dates for bug-fix and security support per version | "Use the latest", with no end-of-life dates |
| Is there a security process? | A security contact, private reporting, advisories with CVEs | Security issues reported in public GitHub issues |
| How did they handle their last critical bug? | Days, coordinated with distros and vendors, clear advisory | Weeks of silence, or a fix only in an unreleased branch |
| Is the release cadence predictable? | A fixed yearly or regular schedule you can plan upgrades around | Irregular big-bang releases with breaking changes |
| How deep is the dependency tree? | A rich standard library and a few well-maintained packages | Hundreds of transitive micro-packages from unknown maintainers |
| Can you hire for it? | A large talent pool and plenty of documentation | A handful of experts, mostly in other time zones |
Apply this to every layer you depend on: the language, the framework, the database, your container base image and your hosting provider.
How mainstream stacks score#
The good news is that most mainstream stacks pass. PHP has the PHP Foundation, paid core developers, a fixed November release cycle and published end-of-life dates. Node.js has the OpenJS Foundation, a security working group and scheduled security releases. Python has the PSF and a security response team. Go, Java and .NET are backed by large companies with formal security programs. Frameworks like Laravel, Symfony, Django and Rails publish support windows and security policies.
The risk is rarely the language. It's the long tail: the small library nobody remembers adding, the abandoned admin-panel plugin, the trendy framework whose maintainers moved on. That's where patch velocity drops to zero.
Why this is how we chose our stack#
When we chose Laravel and PHP at MarginTop, the reasons were hiring, delivery speed and ecosystem maturity, as I wrote in why we chose Laravel over Node.js. In hindsight, the most valuable property turned out to be the one we talked about least: a mature, committed team upstream, with a security process that works under pressure.
Make your half fast too#
Choosing a stack with good upstream velocity is only half the job:
- Stay on supported versions, and schedule upgrades every year. See the PHP upgrade playbook.
- Use one base image and reproducible builds, so a patch becomes a rebuild instead of a hunt.
- Automate dependency alerts (Dependabot, Renovate,
composer audit,npm audit), and act on the critical ones within days. - Keep the dependency tree small. Every package is a team whose patch velocity you now depend on. Our build vs buy framework covers this.
- Practise. If you've never rebuilt and redeployed everything in a few hours, you won't manage it on the night it matters.
Key takeaways#
- Don't choose a stack for hype or benchmarks. Choose it for the committed team, support policy and security process behind it.
- AI has made vulnerability discovery faster and cheaper, so the bottleneck is now patching.
- Patch velocity has two halves: upstream (the maintainers) and yours (your build and deploy pipeline). You choose the first when you pick a stack.
- PHP2Shell showed both halves working: coordinated upstream fixes in hours, and downstream teams patching within a day.
- The real risk usually lives in the long tail of small, unmaintained dependencies, so keep that tail short.
Sources#
- Google Project Zero: From Naptime to Big Sleep
- Google Cloud: Responding to core PHP vulnerabilities
- Exakat: From Commit to Production
- FOSS Force: Fresh eyes on old code, AI and open source security
- php.net: Supported versions
Choosing a stack for a new product, or worried about the one you have? Get in touch. We'll help you look past the hype.