DORA metrics have been a reliable compass for engineering teams for over a decade. Deployment frequency, lead time for changes, change failure rate, mean time to recovery, and reliability give teams a shared language for talking about delivery performance. The research behind them is solid, the benchmarks are well-established, and most engineering leaders know what good looks like for each metric. What is less discussed is how AI-assisted development changes the baseline assumptions those metrics were built on. Not whether DORA metrics are still relevant — they are — but how the same numbers can mean something different when a significant portion of your codebase is being generated by AI coding tools. Deployment Frequency Goes Up. Sometimes for the Wrong Reasons. AI coding assistants accelerate code production. Developers who use them ship features faster, close tickets quicker, and generate pull requests at a higher rate than before. For teams tracking deployment frequen...
The fight to maintain security has moved to the engineer’s messy desktop. Last week, AI search provider Perplexity open-sourced an internal tool, Bumblebee, for checking developer machines, either Linux or macOS, for vulnerable software. Continuous integration pipelines have baked security checks into them, with Software Bills of Materials (SBOMs) ensuring that the correct version of a package makes it to runtime. So malicious attackers are gravitating to the underbelly of enterprise security, the developer’s laptop. Most developer machines are no doubt teeming with unpatched and outdated software, byproducts of various experiments and projects. There’s probably an outdated version of Node.js on most machines, or perhaps a never-used Warp terminal. Or maybe they downloaded a malware-infested package at some point, and it is just sitting on the hard drive waiting to be activated. And certainly, many Perplexity engineers have plentiful recipes for agents lying around, which cou...