Flooding the Zone, or Why Cheap Output Isn’t Free

AI has made producing documents almost free. A few prompts, a couple of minutes, and you have a risk analysis, a complete SOP, or a technical file section that looks polished and professional. The cost of output has collapsed. Not to zero, mind you. It takes electricity, water cooling the data centers, and money for the API tokens. But compared to the cost of a human writing it? Close enough to free.

But reading those documents? That cost hasn’t changed at all.

Attention is the bottleneck. It always was. The hard part was never writing the document. It was making sure someone understands it, reviews it, signs off on it. In regulated environments, like in my case for the past 5 years, medical devices under the MDR, this isn’t optional. A human at a notified body will sit down and read your clinical evaluation report. Some humans in your team will review every change to your risk management file. These people have finite hours and finite cognitive capacity. You can generate documents faster than ever. They can’t read them faster than ever.

And yet, the temptation is obvious. If producing documents is nearly free, why not produce more? Why not let AI draft everything, expand everything, cover every edge case with another paragraph? Because you’re not saving time. You’re shifting the cost from the writer to the reader. You’re making someone else’s job harder so yours feels easier. Which is a trap!

There’s a deeper problem than volume. It’s ownership. When someone writes a document, they own it. They know why a sentence is there. They can defend a decision, explain a trade-off, engage in a discussion about the content. When AI writes the document and a human just reviews it (or doesn’t), that ownership evaporates. The person whose name is on the document can’t answer detailed questions about it. They can’t have a meaningful conversation about the reasoning behind it. They become a signature on something they don’t fully understand.

And when you ask them about a specific risk mitigation or a design decision and the answer is “Ask Claude…” and they don’t mean the colleague from France, then you have produced something that is not worth having.

Here’s another thing that’s going sideways. Because AI is good at parsing large amounts of unstructured data, people have started treating that as a design principle. Markdown files used as data storage. Hundreds of documents. Huge documents serving as memory for the next AI session. Unstructured, inconsistent, but hey, the model can handle it. And yes, it can. But the moment a human enters the loop, and in regulated contexts a human must enter the loop, that mess becomes their problem.

The pre-AI principles still apply. If data belongs in a database, put it in a database. Structured, queryable, version-controlled. AI is excellent at working with structured data. In fact, it’s better at it than at parsing sprawling unstructured files. So why are we going backwards? Why are we burning tokens on parsing messy text when we could spend fewer tokens querying clean data?

And when a document is genuinely intended for a human reader, then write it for a human reader. Short. Precise. Respectful of their time. And if no human will ever read the document? Then why does it exist? For the sake of producing output? To feel productive? Come on!

The real skill in 2026 isn’t generating more. It’s knowing what deserves to exist and in what form. It’s owning what you produce, not just signing what a model produced for you.

Respect the reader’s time. It’s the most expensive resource in the chain.

What Am I Actually Writing About? A Reflection After 42 Days

I caught up with my friend Stu Crocker a couple of weeks ago. We talked about a lot of things. He asked about my blogging process, how the posts come together, where the ideas come from. And then he asked something I hadn’t fully thought about. Across all these posts, on very different topics, is there a core thread? A personality, an intent, something that runs through the whole thing?

I couldn’t tell him what it was.

After I ended a 42 day streak of posting every day, and posting nearly 60 posts over the last 8-9 weeks, it’s time to find out what it is.

How the Posts Actually Come Together

The process is simple. Ideas arrive on my morning or evening walks. Usually two minutes or one duck later, they’re gone, unless I capture them. I started to use Claude’s speech-to-text, stammer my thoughts into it, and a small skill I “built” turns the verbal mess into a scaffold. When I get home, I take that scaffold into WordPress and then or later write the post. Claude helps with research, with reviewing for typos and grammar, sometimes with pushing back on a weak argument or bad structure.

Writing is where the actual thinking happens. The scaffold is never the final post. I restructure, cut, find what I actually meant. The post that ends up online is not the one I started with. That’s the point.

So when Stu mentioned this core thread, I realized I could actually check with the help of AI. I asked Claude to read my last 50 posts, February through April, and tell me what it saw.

What Came Back, the Generous Part

The summary was flattering in places.

A practitioner who doesn’t panic in either direction. Someone who uses AI daily and still writes carefully about its risks. Someone teaching the thinking rather than handing out conclusions. Craft as ethics, not as a metaphor I reach for. Systems thinking as the spine underneath almost everything. Still learning out loud, citing others generously, refusing the guru position.

Fine. Not sure about all of it. I’ll take it. But that’s the easy half.

What Came Back, the Uncomfortable Part

I’m repeating myself. Meadows’ bathtub shows up three times. The junior-developer-with-amnesia appears over and over. “Velocity without verification is just negligence with extra steps” got used twice, word for word.

I forgot I’d made the points already. Meadows’ bathtub is a classic in the first half of her book “Thinking in Systems: A Primer”. With reader numbers being somewhere between 15 and 100, the duplication probably doesn’t matter that much.

But I’m arguing with CEOs in posts read by testers. The rhetorical questions about “do you really want to lose your senior people” are aimed at people who aren’t in the room. My actual readers are already nodding. That’s not persuasion, that’s a choir rehearsal.

Yes, I agree. As I post it on LinkedIn, who knows who will get it pushed into their feed. But I agree, the main audience is my kin.

Some posts reached outside my domain. Especially the macroeconomic ones. When I write about testing, teams, and codebases, I’m on solid ground. When I write about Nvidia chip supply or the AI bubble, I’m just another guy with opinions.

True again. But especially at the moment the global situations are those, where systems thinking is very valuable. And I read and listen to a lot of news, so I have the information to connect.

And the big one. Of the last 50 posts, maybe three aren’t primarily about AI. A reader landing on the blog today would not think this is a blog about software testing or systems thinking. They’d think I’m an AI commentator.

That’s not what I set out to be.

The Mirror, Not the Answer

Stu didn’t hand me a conclusion. He handed me a mirror. Asking Claude to hold it up was a worthwhile experiment. The mirror showed me both sides. You don’t get to keep only the flattering half. Of course it only gave me the good things in the beginning, I had to explicitly ask it for the negative feedback.

Stepping Off the Treadmill

I’ve said what I wanted to say about AI for now. The warnings are on record. When I find myself writing the same warning over and over again, that’s not adding insight anymore. That’s rehashing. (I hope I used the right word.)

The blog run of the last 8 weeks or so started as a place to process thoughts on software testing and systems thinking. The rants on AI misuse just came along, and I tried to use them in a way to teach systems thinking. Probably with less success. Either rant or teach.

The systems thinking part is where I want to put my attention next. Fewer posts. Better posts. Scarcity over flood. If a thought is worth interrupting your day with, it should earn the time.

As one of my favorite woodworkers coined: “Stay humble. Make something.” I even have it as a t-shirt. Three times.

Glue or Process Band-Aid?

You know that feeling when you’re the one holding things together? When you spot something missing in the process, and you take ownership to take care of it? When you do things that are not in your role description, but they help to improve your job?

There are two roles that look similar from the outside but are fundamentally different.

The Glue Person brings the right things together. You enable flow. You connect parts that need connecting. The interfaces exist, they just need someone to make them work smoothly. You’re creating lasting cohesion.

The Process Band-Aid stretches over holes. You’re rapidly patching gaps, compensating for missing structures, filling in process steps that should exist but don’t. You’re not enabling the system. You’re masking its deficits.

Both feel like helping. Both look like being indispensable. But one is sustainable, the other is not.

Here’s where it gets interesting. The real question isn’t about you at all. It’s about the system you’re operating in.

If you’re a Glue Person, that tells you something healthy about your organization. There are interfaces, handoffs, collaboration points that genuinely benefit from someone connecting them. The parts exist, they’re well-defined, they just need someone to facilitate the flow between them.

If you’re a Process Band-Aid, that’s diagnostic information too. It means there are structural holes. Missing processes. Undefined responsibilities. The system has gaps, and instead of closing them, the organization has learned to rely on you to stretch over them. You’re not solving a problem. You’re hiding it.

And here’s the uncomfortable test: What happens if you leave tomorrow?

If you’re glue, the connections you’ve built should hold. The parts you’ve brought together should be able to stand on their own, or at least know how to find each other. Your absence might slow things down, but it won’t break the system.

If you’re a band-aid, everything you’ve been covering up gets exposed. The wound is still there. It was always there. You were just preventing anyone from seeing it.

Now, should it break? That’s the real question. Because sometimes exposing the gap is exactly what the system needs to finally address it. As long as you’re compensating, there’s no pressure to fix the underlying problem. The pain is hidden. The symptom is managed. The cause remains.

So what do you do with this? I’m not saying stop helping. That’s not realistic, and honestly, sometimes being a band-aid is what keeps things running while you figure out the structural fix.

But start making it visible. Every time you stretch over a gap, name it. Document it. Say out loud: “I’m doing this because we don’t have a process or person for X.” Make the compensation explicit. Because the system can only learn if it sees its own gaps.

Finding Your Way or Why My Dad Can’t Use Windows

I recently switched companies. New team, new processes, new tools. After a decade of using Jira, I’m now working with Azure DevOps. Different interface, different terminology, different quirks. And yet, within a few days, I felt at home. Not because I’m particularly clever. But because I have heuristics.

My father doesn’t have these. He’s been using computers for decades, but every Windows or iOS update throws him off. If a button moves, he’s lost. If a menu looks different, he calls me. He learned to use his PC by memorizing or rather writing down exact sequences: click here, then there, then type this. It works, until it doesn’t. When Microsoft or Apple rearrange the furniture, his map is useless.

The difference between us isn’t talent or experience. It’s the question we ask when facing something unfamiliar.

My father asks: “Where is the button I need? HELP!”

I ask: “What are the parts of this system? What do I want to achieve? What could the way there look like?” Looking for clues that spark attention. “Follow me!”

This is a heuristic I have used ever since. And now I learned from the Drs. Cabrera about their DSRP framework and the cognitive jigs. One of those jigs they call the S-to-P jig, short for System-to-Perspective. The idea is simple. You take an existing system you know and apply it to new perspectives. Don’t memorize the surface. Understand the structure.

Let me give you an example. When I opened Azure DevOps for the first time, I didn’t look for a tutorial. I asked myself: What does a work item tracking system need? It needs a way to manage work items. It needs links between items. It probably has different item types. There’s likely some kind of hierarchy or grouping. And hey, maybe even a test management module as it seems. And those all work more or less the same, don’t they?

Then I went looking for those parts. Where does Azure DevOps list items? Ah, there. How do links work here? Slightly different from Jira, but the concept is the same. And the test management module? Yes, and it still looks surprisingly similar to what I remember from Team Foundation Server back in 2013.

The tool changed. The questions didn’t.

This is what a heuristic or S-to-P jig does. It gives you a starting point when you don’t know the territory. You’re not stumbling around hoping to recognize something. You’re actively exploring with a mental checklist: What are the parts? How do they relate? What’s missing?

When you know which problem you need to solve, then there is usually a pattern you have seen before that can be applied as jig. If the solution you look at is not radically new, spoiler alert, there rarely is, then you will see common and returning patterns. Once you understand that structure, you can navigate variations. Jira, Azure DevOps, Trello. They’re all rearranging the same furniture.

My father doesn’t see furniture. He sees a room that must look exactly like it did yesterday. And when it doesn’t, he’s stuck. Which is especially fun when he has printer problems. (Boy, I hate printers!)

If you already have a good understanding of how a system roughly works, then applying that understanding to new situations is very helpful.

Looking Into the Crystal Ball

I want to take a look in my slightly broken crystal ball, and try to explain what I see for the future of AI, based on the news, podcasts, social media, experience, and some heuristics.

I don’t do this because I have any special insight. I don’t. But writing things down is sharing. And when I look back at this article in half a year or three years, I can make fun of today’s Grumpy. So here it is, a snapshot of what I think is happening right now in the GenAI market, and where I expect it to go over the next few months, maybe years.

Let me start with the obvious. The last three years have been wild. ChatGPT opened the floodgates in late 2022, and since then we’ve had a cascade of models, companies, products, and demos. Everybody with a computer has used GenAI by now. As search replacements, with those AI summary sections at the top. We got access to all sorts of GenAI. Image and video generation, voice clones, coding assistants, and so much more. The public got handed something genuinely new, and we’ve been poking at it with sticks to see what it does and can do.

And this is where it gets interesting. Because I think OpenAI, Anthropic, Google, or any of the other big players didn’t actually know what GenAI was good for when they shipped it. Not really. They knew it was powerful. They knew it could do impressive things in demos. But concrete, reliable, money-making applications? That was unclear.

So what did they do? They gave it away. Cheap or free, to everyone, all at once. And we, the public, became the world’s largest focus group. Millions of people running millions of experiments in parallel, figuring out what this stuff is actually useful for. Lawyers feeding it contracts. Students using it for homework. Developers pairing with it. Marketers cranking out copy. Kids making memes. Populists spreading fake news.

This wasn’t generosity. It was scouting. A resource was handed out with no clear application, and the job of finding the applications was crowdsourced to the public. That’s a fascinating inversion of how technology usually rolls out. Normally you know what a tool does before you sell it. With GenAI, the tool came first and the use cases had to be discovered.

And now, a few years in, the picture is starting to crystallize.

Look at where the big players are putting their real engineering effort. Coding, testing, designing. Claude Code, Cursor, GitHub Copilot, OpenAI’s Codex, countless startups building developer tools. That’s not a coincidence. Coding is the first place where the productivity gain is measurable, repeatable, and valuable enough that companies will write large cheques for it. A senior engineer costs real money. The ROI is clear, and the market is enormous.

Compare that to the consumer side. Yes, ChatGPT has hundreds of millions of users. Yes, a lot of people pay $20 a month for Plus subscriptions. But the economics of consumer subscriptions are brutal compared to enterprise contracts. A single Fortune 500 customer can be worth more than a million individual subscribers, with less churn and less support overhead. If you’re running one of these companies and you’re thinking about where to invest for the next quarter, the answer isn’t “more features for casual users”.

The pressure for this shift is only going to grow. These companies have taken enormous amounts of money from investors. They’ve built infrastructure that costs a fortune to run. And the big ones are on a path to the public markets. Once you IPO, or even once you’re clearly on the runway to IPO, patience for “we’re still figuring out the business model” disappears. Shareholders want revenue growth. Revenue lives in B2B contracts, not in keeping the free tier generous.

So here’s what I expect to see.

GenAI for end users won’t disappear, but it will stop being the product. It’ll become the loss leader. The thing that keeps the brand familiar, that feeds training data, that gets people comfortable with the technology so their employers will buy the enterprise version. Free tiers will get thinner. Rate limits will tighten. The most capable models will sit behind higher price tiers or, increasingly, behind enterprise contracts.

The actual products, the ones that will pay the bills, will be domain-specific. Legal AI that helps with analysis, research, and writing. Industrial solutions for running of complex machines. Pharma research tools that help with drug discovery. Financial compliance systems that read regulatory filings. Software engineering tools that integrate with your codebase and your ticketing system. These are the places where someone will pay serious money because the value is clear and the alternative is expensive human labour.

You’ll see consolidation too. Not every company currently claiming to do GenAI will survive. The ones that did nothing but wrap a prompt around somebody else’s API are already struggling. The ones without a clear industry focus will get squeezed. The winners will either be the foundation model providers themselves or the companies that have deep domain expertise and real enterprise relationships. Everybody in the middle is in trouble.

For casual users like most of us, this means the next few years will feel different. The pace of “wow, look what it can do” demos aimed at the general public will slow down. The exciting releases will start being things nobody outside a specific industry cares about. A new model for legal document analysis. A breakthrough in protein folding. A coding assistant that can handle larger codebases. Impressive to specialists, invisible to everyone else.

That’s not a bad thing. It’s how technology normally matures. The sampling phase ends. The application phase begins. The market sorts itself into segments where real value gets created and real money gets paid.

GenAI is a resource, but nobody knew what to do with it. It took a gigantic social experiment to find that out.

Now it’s time to focus on the money.

Hey Siri, is AI Fatigue a Thing?

The other day I scrolled through my LinkedIn feed and noticed something. AI, AI, AI. Three out of four posts are about AI in one way or the other. New tools, new prompts, new ways to be more productive. And somewhere between the tenth and twentieth post, a word popped into my head: AI fatigue.

So I asked Bing: “Is AI fatigue already a thing?” The answer came back in capital letters: YES. Together with, of course, an AI-generated summary. The irony wasn’t lost on me.

Turns out, since 2025 there are actual reports and studies about people suffering from AI fatigue. AI fatigue, as it turns out, is not just one thing. It’s a whole family of exhaustions. (1) There’s the constant pressure to adopt yet another tool, to keep up with updates and new features. (2) There’s the cognitive drain of reviewing AI output instead of creating, turning us from makers into judges. (3) There’s the endless flood of AI-generated “slop”, filling our feeds with hollow noise and fake news.(4) And there’s the sheer hype fatigue, the relentless drumbeat of AI everywhere you look. Four flavors of exhaustion, and most of us are tasting multiple of them at once.
Even though this post is triggered by number (4), this post focuses on (1) and (2).

What triggered this reflection was a report from Anthropic titled “Estimating AI productivity gains.” The numbers are impressive and frightening. Current AI models could increase US labor productivity growth by 1.8% annually over the next decade. That would double the growth rate we’ve seen since 2019. The median task shows 80% time savings. Sounds like progress, right?

But here’s the question nobody seems to be asking. Progress for whom?

From news articles and podcasts, I’m hearing something different. Management has discovered a new instrument. And it’s not being used to make work easier or more meaningful. It’s being used to squeeze more out of people. Faster. More. More efficient. At any cost. There’s this constant pressure now, this unspoken threat hanging over every desk: AI could replace you. So you better speed up. You better adopt. You better produce.

It feels less like a tool and more like a whip, like a threat.

And if you look at it from a purely capitalistic perspective, it makes sense. Companies are not in the business of keeping humans healthy and happy. They’re in the business of generating value. And right now, AI promises to generate more value with less human involvement. Which means the humans can produce more and more output in the same time. They just need to focus on the parts that AI can’t solve yet, and use AI as efficient as possible for the rest.

And the human cost? AI fatigue is real. People are being forced to use tools they don’t understand, don’t trust, or simply don’t like. Some companies even reward the employees with the highest token usage. The pressure mounts. The exhaustion grows. We’re optimizing productivity at the expense of wellbeing. We’re measuring output while ignoring the people producing it. And with tokenmaxxing you only guarantee two things. More income for AI providers and a warmer planet thanks to unnecessary resource use.

Proponents say that AI handles the stupid and easy jobs, so that humans can focus on the tough parts. But constantly working on the tough parts is draining energy. And work models don’t account for that. Managers now expect you to work 40+ hours a week on the tough parts only.
In a good world the work days would become shorter, because people with the help of AI can now manage 40 hours of work in let’s say 25 hours. So why not cut the work week down to 30 hours or less. People sometimes need a few stupid tasks to regenerate mentally. Or they need other means. Like longer breaks.

Professional athletes don’t train all day the hard moves and tactics. They also train the simple things, the basics. Because the simple things are the foundation for the hard things. By outsourcing the foundation you will lose a vital part of the package.
It’s like when an F1 drivers uses his F1 car to get to the train station or running errands. Driving the whole time at maximum speed.

I don’t have a neat answer here. But I do have a question: Where does this end? Is “more productivity” really the goal we should be chasing? Or do we need a different conversation entirely, one about what good work actually means, about sustainable pace, about treating people as humans rather than resources to be optimized?

I know that companies need to make money. But for the long run, maybe it’s time to stop asking “How can AI make us more productive?” and start asking “What kind of work do we actually want to do?” and “How can we balance work and life in these new times?”

AI Doesn’t Understand the World (yet)

There’s a video by woodworker John Malecki called “AI vs Man” where he tries to build a cutting board designed by AI. The image looks, well, interesting. Complex patterns, different wood tones. The only problem: it’s physically nearly impossible to assemble.

This is the design John settled on, that looked actually doable.

The AI generated an interesting looking result. But it has no idea how you’d actually make it. It doesn’t think about which pieces need to be glued first, how grain direction affects stability, or whether the geometry even allows for assembly. It just sees patterns in training data and predicts what a cutting board should look like. And that prediction can be completely disconnected from reality.

This isn’t just a woodworking problem. The craft community has been fighting this battle for a while now.

Etsy and Ravelry are flooded with AI-generated crochet and knitting patterns. They come with polished images of adorable amigurumi animals, intricate shawls, cozy socks. People pay for the patterns, start working, and discover: they don’t work. NBC News reported on frustrated buyers who found patterns with impossible stitch counts, garments that couldn’t physically fit together, instructions that contradicted themselves.

One Reddit user, a crocheter with over 15 years of experience, wrote that the AI images fooled them at first. It was only when they looked closer that they noticed “stitches that weren’t there” and designs that were simply impossible to create with yarn and a hook.

There’s a wonderful earlier experiment called SkyKnit, where researchers fed thousands of knitting patterns into a neural network and let it generate new ones. The knitters who volunteered to test them called it “Operation Hilarious Knitting Disaster.” The AI produced patterns requiring 6,395 stitches in a single row. Patterns that would immediately unravel. Patterns that turned into “long whiplike tentacles.” The knitters had to debug the AI output, because they actually understood how yarn behaves in the physical world.

Why does this happen?

AI, especially generative AI, is fundamentally a pattern-matching system. It predicts the next likely token, pixel, or word based on statistical patterns in its training data. It doesn’t simulate physics. It doesn’t understand that wood expands across the grain, that yarn has tension, and that knots must be attached to other knots.

Humans learn these things through their bodies. You cut wood and feel the resistance. You knit a row and notice when something’s off. You fail, adjust, and build intuition over thousands of repetitions. This is what cognitive scientists call embodied cognition. Knowledge that lives in your hands, your muscles, your sensory experience. Some call it “muscle memory”, but it’s more than that.

AI has none of that. It has never held a chisel. Never felt a thread snap. Never assembled a single physical object. It can mimic the appearance of expertise with impressive accuracy. But appearance is all it has.

And here’s the danger: people are selling these phantom plans. On Etsy, on random websites, often for real money. The images look professional. The descriptions sound confident. And if you don’t know enough about the craft to spot the problems, you might not realize you’ve been had until you’re halfway through a project that can’t be finished.

So what can you do?

If it looks too perfect, be suspicious. Check the reviews. Look for photos of actual finished projects, not just the listing images. Ask yourself: can I trace the steps from raw material to finished product? If the seller can’t show you that path, maybe they don’t know it either.

AI is a powerful tool. But it doesn’t understand the physical world. It mimics the appearance of understanding. And that difference can cost you time, money, and a lot of frustration.

Trust the people who have actually built things. They know what’s possible because they’ve done it with their hands.

Talk to the Machine, or Why We Chat with AI But Not Each Other

Lisa Crispin recently dropped a comment under one of my posts.

“It seems funny to me that people are willing to turn things over to an agent, but they don’t want to collaborate with other humans to do a better job of building quality in.”

A little sad, if you think about it.

With the rise of AI coding assistants suddenly everyone is prompting. People spend hours iterating with ChatGPT or Claude. They refine their prompts, try different angles, patiently wait for the response, adjust, try again. They have entire conversations with the machine about architecture decisions, edge cases, test strategies.

And yet. Ask them to walk over to a colleague and have a five-minute conversation about the same thing? Too much effort. Too awkward. Takes too long. Don’t want to interrupt.

I find myself wondering, what’s the psychology here? The friction is lower, that is clear. But is the machine “safer” because it doesn’t judge? Because we stay in control of the conversation? Because asking a human might feel like admitting we don’t know something? I genuinely don’t have the answer. But the pattern is hard to ignore.

Here’s the thing though. AI doesn’t skip the conversation. It just delays it.

You can prompt your way to code. Lots of code. Fast code. But without talking to your teammates first, that code arrives without shared understanding. Nobody discussed what problem we’re actually solving. Nobody aligned on the approach. Nobody mentioned that other edge case, or that dependency, or that thing the customer said last week.

So the code lands. And then come the pull requests that miss the point. The bugs that could have been avoided. The incidents that escalate. The rework. The frustration. All the conversations you skipped? They happen anyway. Just later, angrier, and almost certainly more expensive.

This is where in my opinion the difference shows. Teams that talk first and then use AI tools to execute? They scale. The AI amplifies their shared understanding. It accelerates what they’ve already aligned on.

Teams that prompt instead of talking? They drown. In code nobody asked for. In PRs that go nowhere. In technical debt that piles up because nobody stopped to ask “wait, is this what we actually need?”

This echoes what Lisa Crispin and Janet Gregory have championed for years: the human side of building software – the talking, the collaborating, the shared understanding – isn’t overhead. It’s the work.

AI changes nothing about this. If anything, it makes it more obvious. The teams that were already good at communication? They’re getting better, faster. The teams that weren’t? They’re just producing more stuff that misses the mark. At higher speed.

So here’s my ask. Before you open that chat window with your AI assistant, try something radical. Talk to a human first. Ask a colleague what they think. Have the awkward conversation. Align on the problem before you generate the solution.

The AI will still be there when you’re done. And it’ll be a lot more useful once you actually know what you’re building.

No agent can save you from not talking to each other.

The Tech Radar is Blinking Red

ThoughtWorks just dropped Volume 34 of their Tech Radar, and it reads less like a technology map and more like a warning letter. Several signals on the same screen, all pointing the same way. If you’ve been following my posts, none of them will surprise you. What’s new is that one of the most respected consultancies in our industry is now saying it out loud. I have picked out a few topics to focus, as at least half of the Caution blips were mentioned in some of my blog posts recently.

Cognitive debt

Teams shipping code faster than they can understand it. The Radar now names it explicitly: codebase cognitive debt. As AI generates more code, the gap between the humans on the team and the software they supposedly own keeps growing.

“Weaker system understanding also reduces developers’ ability to guide AI effectively, making it harder to anticipate edge cases and steer agents away from architectural pitfalls. Left unmanaged, teams reach a tipping point where small changes trigger unexpected failures, fixes introduce regressions and cleanup efforts increase risk instead of reducing it.” What sounds like one of my recent blog post is actually from blip 36 of the TechRadar.

Measuring the wrong thing

Blip 38 of the Radar also sits in the Caution ring, and it should make every engineering leader uncomfortable. It’s called coding throughput as a measure of productivity. The warning is simple. If you measure AI success by lines of code generated or pull requests opened, you will get exactly that. A flood of it. And not much else. It’s the age-old metric gamification, and obviously AIs are good at it as well.

This is a classic systems thinking trap. You optimize for the metric, not the outcome. Goodhart’s Law in a hoodie. The Radar points out what actually happens. Reviewers drown in barely-reviewed AI output, cycle times go up instead of down, and the effort to adapt generated code to the team’s architecture and conventions gets hidden from the numbers. The dashboard looks great. The deliveries do not.

ThoughtWorks suggests a better signal: first-pass acceptance rate. How often does the AI output get used with minimal rework? Optimize for that metric and it will do good. That’s a number that actually means something, and it connects directly to the DORA metrics. If the acceptance rate is low, change failure rate goes up and lead time stretches. If it’s high, you’re genuinely getting faster. Throughput alone tells you nothing.

Semantic diffusion and the flood of novelty

In a companion blog post, ThoughtWorks describes two things that are really the same problem wearing different clothes.

The first is semantic diffusion. New AI terms are proliferating faster than shared meaning. ThoughtWorks admits that while compiling the Radar, they had to spend serious time just clarifying what words actually meant. Everyone uses them slightly differently. If the authors of the Radar can’t agree on definitions, what chance does your delivery team have? You end up in meetings where everyone nods and leaves with different conclusions. And I have written about problems with semantics before the advent of GenAI.

The second is scale. For this edition, ThoughtWorks received more than 300 proposed technologies. Many were only weeks old. Some had barely any contributors, and one of those contributors was often a coding agent itself. Read that again. We’re now in a world where AI is producing the tools that AI is supposed to help us evaluate.

Both come back to the same thing. Novelty is outpacing understanding. The map can’t keep up with the territory, and the territory is partly being drawn by the very thing we’re trying to map. How do you make informed decisions in that environment? You probably don’t. You guess, or you follow whoever is loudest on LinkedIn.

So what

ThoughtWorks’ own conclusion is blunt: the current cognitive demand isn’t sustainable and will likely undermine the very gains AI is supposed to deliver. Let that land for a second. The productivity paradise we keep being sold is already eating itself.

This isn’t a tool problem. You can’t buy your way out of it. It’s a technique problem, and underneath that, a human problem. It’s about whether the humans on the team still understand their software, still share a language, still operate as a team, and can still make sense of the landscape they’re working in.

None of this means AI is bad. But the Radar has now confirmed, with data and client experience behind it, what a lot of us have been saying from the sidelines. If you build faster than you understand, you are not winning. You are accumulating a debt somebody will have to pay.

Slow down. Read your code. Talk to your colleagues. Agree on what the words mean. And when the next “revolutionary” agent framework drops this week, maybe sit that one out.

The Radar is blinking red. Look at it.

PS: If you haven’t read the Radar yourself yet, do. It’s free. And unlike most vendor content, it’s written by people who actually have to clean up the mess afterwards.

The Convenient Scapegoat?

When it takes a team two weeks to add a button, the problem isn’t the button. And the solution isn’t AI.

I’ve been there. Literally. A simple button on a screen. Two calendar weeks. And if you’re on the outside looking in, you think: what are these people doing all day? Are they incompetent? Lazy? You see a button. You think it’s a button problem. But what you don’t see is the teams that need to coordinate, the approval stages, the deployment that only happens fortnightly, and the legacy system nobody dares to touch. The button is easy. The organization around it is not.

And this is where it gets interesting. Because when leadership looks at that two-week button story, they don’t see organizational complexity. They see inefficiency. They see cost. And now, conveniently, they see a solution: AI.

Here’s what I’ve been observing. The IT industry has been under pressure for a while. Long before anyone typed a prompt into ChatGPT. Companies grew their tech teams aggressively for years. Salaries went up. Headcounts went up. But did the output go up proportionally? Honestly, in many places, it didn’t. The structures became heavy. Diligent, well-trained developers who truly think about what they’re building have always been rare. And surrounding them with layers of process and coordination didn’t make things faster. It made things expensive.

So the pressure to consolidate was already there. The uncomfortable truth that “we hired too many people and built too much complexity” was sitting in the room. But nobody wanted to say it out loud. Restructuring is a hard sell. It means admitting mistakes. It means difficult conversations.

Then AI arrived as the perfect narrative. “We’re not cutting people because we over-hired. We’re cutting people because AI makes us more efficient.” That’s a much easier story to tell. To the board. To investors. To the press. AI becomes the scapegoat for a correction that was coming anyway. It’s not a lie, exactly. But it’s not the whole truth either. Studies are still not consistently showing an actual increase in productivity.

And here’s what worries me. I see highly talented people, folks that companies would have fought over just two or three years ago, struggling to find new roles. Not because they’re not good enough. But because the calculus has shifted. Cheaper people plus AI looks like a solution on a spreadsheet. Leaders and investors see AI as a performance multiplier for everyone, so why pay top dollar for senior expertise when you can pay less and sprinkle some AI on top?

But let me ask you this. When you replace the people who actually understood why the button took two weeks, what do you think happens? The button won’t take two weeks anymore, sure. It might not get built at all. Or it gets built fast, in the wrong place, solving the wrong problem, breaking something downstream that nobody on the new, leaner team even knows exists. Speed without understanding is just faster failure.

So which one is the bubble? Is it AI, with all its promises and hype and investor fever dreams? Or is it IT itself, with decades of inflated teams and salaries that didn’t always match the value delivered? Maybe both. I honestly don’t know. But I do know that pretending one neatly fixes the other is dangerous. That’s not strategy. That’s wishful thinking with a narrative attached.

The consolidation is real. AI is real. But using one to justify the other without actually thinking it through? That’s how you lose the people who understood your systems. The ones who knew why the button took two weeks and, more importantly, knew how to make it take two days. And that kind of knowledge doesn’t show up on any dashboard. By the time you notice it’s gone, it’s too late. And more AI won’t fix it.