ThoughtWorks just dropped their 34th Technology Radar, and it’s a fascinating snapshot of where we are with AI in software development right now. Not the hype-filled future we’re promised, but the messy present we’re actually living through. The radar has 118 blips covering tools, techniques, and platforms, and unsurprisingly, it’s dominated by AI-oriented topics.
What caught my attention isn’t just what’s new. It’s what we’re being forced to revisit. Pair programming, mutation testing, DORA metrics, clean code principles. All the fundamentals that some people thought were becoming obsolete in the age of code generation. Turns out they matter more than ever, precisely because AI tools can generate complexity faster than we can understand it.
The Permission Problem Nobody Wants to Talk About
Here’s the bind we’re in: the AI agents worth building are the ones that need access to everything. Tools like OpenClaw and Claude Cowork that supervise real work tasks, or Gas Town that coordinates agent swarms across entire codebases. These aren’t toy demos. They’re genuinely useful, but they require broad access to private data, external communication, and real systems.
The radar team coined a perfect term for this: “permission hungry” agents. It’s like watching a skier who just learned to turn confidently pointing themselves at the hardest black run. The ambition is there, the capability seems to be there, but the safeguards definitely aren’t.
The fundamental problem is prompt injection. LLMs still can’t reliably distinguish trusted instructions from untrusted input. You give an agent access to your email, your codebase, your cloud infrastructure, and you’re trusting that no malicious input sneaking through will cause it to do something catastrophic. That’s not a comfortable position to be in.
This is why so much of the radar focuses on what they’re calling Harness Engineering. Not blocking AI entirely, but building the guides and sensors necessary for a well-fitting harness. Guardrails that actually work, monitoring that catches problems before they cascade, architectures that limit blast radius.
When Developers Stop Reading Code
Mike Mason shared a story in the radar about a Python codebase generated by Claude. About 100KB of code, largely working, tests passing. Everything looked fine until he noticed something alarming: the main file had grown to 50KB and when Claude needed to make edits, it started reaching for sed to find and modify code within that file instead of understanding the structure.
That’s your canary in the coal mine right there. The model was pattern matching and text manipulation at that point, not reasoning about architecture.
He also looked at the leaked 500,000 lines of Claude Code’s own codebase. His observation cuts right to the heart of it: both things are true. There’s good architecture in there, and there’s also an incomprehensible mess. You don’t get to know which is which without reading the code.
His rough framework makes sense to me. Throw-away analysis scripts? Fine, let the AI vibe it out. But anything you need to maintain, any durable code, needs regular human review. Even if that review is just a human asking a model to evaluate the code with hints about what good looks like.
The interesting part is that when you push back on the AI and say “I’m getting uncomfortable with how big this is getting, can we do something better?” it often does exactly what you want. Sensible decomposition, new classes, sometimes even unit tests. It knew how to do it right. It just didn’t volunteer it.
That’s a pattern I’ve noticed too. The models optimize for getting something working quickly, not for long-term maintainability. Unless you explicitly ask for the latter, you won’t get it.
The Complexity We Don’t See Until It’s Too Late
There’s a broader lesson here that goes way beyond AI development. Don Moynihan wrote about the dismantling of DirectFile, the IRS program that let people file taxes online for free. DOGE came in with their wood chipper and killed it as part of their “efficiency” drive.
Moynihan talked to people who worked on DirectFile and captured something I’ve seen in every large organization: a paradox of reform. The simpler a potential change appears, the more likely it hasn’t been implemented because it features deceptive complexity that others have tried and failed to resolve.
Government technology projects get mocked constantly, but the reality is they’re often dealing with edge cases and requirements that don’t exist in the private sector. DirectFile had to handle an insane variety of tax situations, integrate with legacy systems decades old, meet strict accessibility requirements, and serve everyone regardless of their technical sophistication.
The people building it understood public service. They believed government has a responsibility to serve people, which fundamentally shapes how you build technology. When that underlying principle is missing, when you think government shouldn’t be doing something at all, how good are you really going to be at making it work better?
We lost an effective tool and the IRS is now operating with 25% fewer staff and a budget 40% below 2010 levels. History suggests this isn’t just inefficient, it’s dangerous. Britain’s ability to collect taxes effectively was a major reason it won against France in the 18th century. France’s wonky tax system helped trigger a revolution.
The same deceptive complexity exists with AI agents. It looks simple: give the agent access, let it do its work, profit. But the security implications, the reliability requirements, the edge cases where prompt injection could cause real damage, those are the details that will bite you later.
I suspect the next Technology Radar in six months will have even more blips about harness engineering, more patterns for constraining and monitoring these permission hungry systems. We’re still in the phase where we’re learning what can go wrong, and every lesson is being paid for with real incidents.