ByteCode.NewsSubmit
Use quotes for an exact word.

Subscribe

RSSPodcast
Log in

Alan Williamson: With AI, No One Can Hide

Alan Williamson1 wrote "With AI, no one can hide," which says that technical debt used to be an interest payment and is now a security crisis, because the obscurity that kept old flaws unexploited has been retired by AI-driven exploit discovery. His evidence is PHP2Shell and the scramble that followed it. His close is that "later" is no longer a date you can put on a roadmap.

He is not writing for the typical BCN reader - and BCN isn't really targeted at Alan's readers. Alan's audience is the C-suite and the private equity operators who hire him to look under a company's rug; BCN's audience is the people who know what is under the rug because they put it there. Those are different audiences, and they usually get different versions of every story, weeks or months apart, if the second audience gets a version at all.

This time the gap was days. BCN ran "That free beer has a brewer" which used the same two CVEs to make a practitioner's argument about who maintains the runtime and what they are paid for it2. Alan uses them to tell boards that the maintenance window they have been deferring is now a liability with a timer on it.

Same event, both ends of the org chart, one week. From Alan's write-up:

This is exactly what Jason Clinton, Anthropic's Deputy CISO, warned about this week. Looking at the chaos of the PHP meltdown, his message was blunt: "As bad as things have gotten in the past four days, they are going to get a lot worse before they get better."

That's the whole thing. A story about a scripting language's memory handling has stopped being a PHP story, and it has stopped being a security-team story. It is now a budget story, written by someone who writes budget stories for the executives.

The standout element for me is that we're seeing an awful lot of handwringing about AI along with a lot of investment in its output - and everyone's busy reacting, trying to figure out what this new thing can and will do, and thus everyone is constantly being surprised by capabilities and outcomes. The PHP2Shell outbreak is just data - but it's data that shows that everyone needs their own oars in the water, that we need to be using our agency more than we are.

Alan's warning to the suits is needed: we need to be actively engaged, and the suits need to be engaged as well. If the powers that control our employers start listening and watching at last, we might see some real advances.

If your leadership starts reading posts like Alan's3, the conversation you have been losing for five years, the one where patching is unglamorous and the system might not come back up, is about to be reopened from the other side. When that conversation comes up, you want your answer to already exist: a cadence, a test that proves the thing came back up, a dependency list somebody actually reads. The ask is going to arrive. Being ready for it is cheaper than being surprised by it.


  1. Disclosure: Alan is the goon who got me into actually writing where other people could see, at Java Developer Journal. I ended up succeeding him at JDJ as editor. He's a Java Champion and a swell person.

    ↩
  2. Because they're usually not paid for maintenance of the runtime, and that's dumb.

    ↩
  3. If your leadership doesn't read posts like Alan's, they should. Why not hand them Alan's content itself? If not Alan, they need to be reading someone like him: someone who knows both engineering and management.

    ↩

Comments (2)

niftiness at October 29, 2026

I’ve long thought that “technical debt” was a term that obscured more than it revealed. I first encountered it when working at Chiliad when they hired an “agile” consultant to wreck team cohesion, spew gibberish about “swim lanes” and derail projects, shortly before they ran out of money and went belly up.

Before that euphemism was invented, the same thing was called failure, sloppiness, or not paying attention. And if you look at software as an engineering discipline, that’s exactly what it is. But the business side of the industry has been at war with that kind of engineer-attitude for decades: It values speed of delivery far more than whether the thing works. Often speed is the only thing valued at all - the product only needs to look like it works for long enough to fool investors, sell the company and then it’s someone else’s problem. A few times at Sun I was involved with integrating tech obtained through an acquisition that appeared to have been written by kindergartners. I’ve been the guy who did the due diligence for other companies considering acquiring someone. Once in a while it’s good, most of the time it’s junk. That is normal in the industry.

What is happening now is effectively the bill coming due for that - for prioritizing speed over quality.

Any software project has a point at which it’s effectively “finished” - where the return on further tinkering with the underlying plumbing is deemed to have too minimal a return to justify it, and it is lived with as is for better or worse.

AI is simply raising the bar for where that point is. Where poor judgement was used about the point of diminishing returns in the first place, it’s going to hurt a bit. And it should.

In the long run, there is some hope that this will act as a forcing function that raises the quality and reliability of software for everyone who relies on it, and an extinction event for truly broken technology. In the long run, that’s a blessing not a curse.

A good use for AI in all of this would be to migrate off of broken tech - no one with a business on the line should be running PHP in 2026 - never mind the well-known security and quality issues, generating html on the server that you could trivially do on the client is simply burning money for nothing.

There are SO many overly complex tools to solve simple problems, in use because they developed a cult following - take GraphQL - it was invented to solve a head-of-line blocking and browser connection-limit problem that hasn’t existed since HTTP2 was introduced, and breaks client side caching badly (you can remove vast amounts of load from your servers by handling cache headers really tight and almost no web APIs do).

A plague that culls the most fundamentally broken tech in our industry was long overdue.

dreamreal at October 29, 2026

Yep.

Log in to comment