Perhaps we have forgotten that some things are supposed to take time. There is a line about the Ents in The Lord of the Rings that has stayed with me for years. Treebeard explains that Old Entish is a slow language, and then adds the part that actually matters, which is that "we never say anything unless it is worth taking a long time to say." There is something almost absurdly incompatible with the AI age in that idea.
Last night I ran Midnattsloppet. Ten kilometres through Södermalm, in August, surrounded by thousands of people who all seemed to have prepared better than I had. I had not run more than six kilometres in a year. I had not trained. I went in with a plan, and the plan was to go slow.
I went slower than the plan.
There is a particular kind of satisfaction in watching a model load. The layers march across the terminal one at a time as llama.cpp offloads them to the GPU, the numbers climb, and then comes the line that tells you how much VRAM is left over. I remember sitting in front of that line the first evening the second card was in the machine. Two Radeon AI PRO R9700, sixty four gigabytes of VRAM between them, and llama.cpp reporting [XX.X] GB for the weights of a thirty billion parameter coder model at four bit quantization. Room to spare, I thought. The hard part is over. Everything from here is just usage.
AI is fantastic. Genuinely, without irony. We have all been handed the ability to vibe-code every idea we have ever had in the shower, and we are using it enthusiastically. I have a folder on my machine called "projects" that would be more honestly named "the graveyard", and inside it sit at least four tools that do roughly the same thing, written within a month of each other, by me, for me, because on each of those four evenings I was completely certain that this time I had finally figured it out.
I've come to realize that my greatest strength and one of my biggest weaknesses are probably the same thing.
I'm endlessly curious. I get excited by ideas, I enjoy solving problems, and I genuinely love learning new things. When something catches my interest, I don't just want to understand it. I want to build it, improve it, and see how far it can go.
I've been thinking a lot about waiting lately. Not the dramatic kind. The ordinary kind. Waiting for a build to finish. Waiting for someone in procurement to decide whether a tool I needed last month can be approved this month. Waiting for a security review. Waiting for legal. Waiting for a meeting to start because everyone is still hunting for the HDMI cable. Waiting for a colleague to come back from holiday, because of course the one answer I need is locked inside their head and nowhere else. Waiting because somebody marked an email High Importance, apparently unaware that Outlook still has no button labelled "ignore until tomorrow, this is not actually important."
For a while now I have had the same nagging question that I suspect a lot of people in security and IT have been quietly circling. Which local model is actually good enough for the work I do, and what does "good enough" even mean once you stop hand waving? Not the leaderboard scores, not the demos where someone asks a model to write a haiku about Kubernetes, but the actual workloads. Reading a log. Spotting a brute force that turns into a successful login. Writing an incident report without quietly inventing a threat actor that never existed.
There is a question circling the industry right now, and it is one worth sitting with rather than answering too quickly: does AI in the development pipeline actually make the things we ship more secure, or does it mostly just give the bad actors a better toolkit?
The honest answer is probably both. Which is not a satisfying thing to say, but it happens to be true.
I do not remember exactly when it changed because things like this never happen all at once and maybe that is why it becomes so difficult to notice while it is happening, because one year becomes another and life keeps moving and work keeps demanding things from you and suddenly you wake up one morning with medication beside the coffee machine and realize that somewhere along the way your body stopped quietly cooperating with the life you built around stress, bad sleep, too much sitting still and the constant idea that you would eventually take care of yourself later when there was more time.
I have spent the past week trying to piece together what actually happened with Trivy. Reading advisories, cross-referencing timelines, digging through GitHub issues and incident discussions, trying to separate confirmed facts from speculation. The more I read, the less comfortable I got. Not because the details were unclear, but because they were clear, and the implications kept getting worse.
The tool you run to find vulnerabilities in your container images was the one stealing your cloud credentials. That is what happened on March 19, 2026, when Aqua Security's Trivy scanner and its GitHub Actions integration were compromised in one of the more targeted supply chain attacks I have seen against the DevSecOps ecosystem.
If you have been running aquasecurity/trivy-action in a CI/CD pipeline over the past few months, read this carefully.