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?

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.

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.

I was listening to the A/B Testing podcast the other day, episode 229, where Alan Page had my friend Chris Armstrong on as a guest. At one point they were talking about Verification and Validation. Two concepts that have been around forever. Two simple questions, really. "Are we building the thing right?" That's verification. "Are we building the right thing?" That's validation.

As of when writing this post in the first days of April 2026, the vibe coding community is buzzing about "Spec-Driven Development." Write a perfect specification, let the AI agents loose, sit back, and watch the magic happen. Revolutionary, right? For me, it feels like a déjà vu from the 2000s. Back then, we called it Waterfall or V-Model. The idea was the same: define everything upfront, hand it over to the people who build it, and collect your finished product at the end.

I recently listened to a podcast about "assisted migration." Scientists are helping plants and trees migrate to new areas because climate change is happening too fast for natural evolution. A tree that thrives at a certain temperature profile can't just walk north when its habitat becomes inhospitable. And also the seeds don't spread that quickly. Think acorns. So researchers look up international catalogs, find similar species that already grow in warmer climates, and carefully introduce them to new regions.

OpenAI just closed a $122 billion funding round, pushing their valuation to $852 billion. Let that sink in. A company that isn't profitable yet, valued higher than most countries' GDP. An IPO (Initial Public Offering, when a company sells shares to the public for the first time) is expected by the end of the year. Big Tech is planning to spend nearly $700 billion on AI this year alone.

Imagine you want to buy a new bike. Before you even walk into the shop, you already have a picture in your head. Where will you ride? City commute, gravel paths, weekend tours in the mountains? Luggage and how much? How often? You build a little mental model of your situation. And then, almost without noticing it, you walk into the shop and use that model as a lens.

"Why do you only point out problems? Where are your solutions?" It's a fair question. I ask it myself sometimes, scrolling through my own posts. Another rant about AI hype. Another frustrated observation about how we're losing craftsmanship. Another finger pointing at something that's broken. A bit more salt into some open wounds. And then... nothing. No neat five-step plan. No actionable takeaways.

Many teams have one. The hero. The person who stays late, works weekends, knows every corner of the codebase, and somehow holds everything together. Management loves them. Colleagues rely on them. But having a hero in your team is not a good sign. It's a symptom. Now, AI coding agents are stepping into that role. And nobody seems to notice the pattern repeating.

In psychology and cognitive science, cognitive biases are systematic patterns of deviation from norm and/or rationality in judgment. - Wikipedia on List of cognitive biases We love to treat biases like bugs in our brains. Little glitches in the wetware that we can patch once we know about them. "Oh, that's just confirmation bias," we say, as if naming the demon exorcises it.

A populist makes a statement. Eight words. It fits on a bumper sticker. It goes viral. Millions nod along. You know it's wrong. You know it's an oversimplification. You want to counter it. But here's the thing. To explain why it's wrong, you need context. You need to draw out the system. You need several minutes, just to set up the picture before you can even get to the point.

There is a new promise floating around. Let an AI agent write your tests. Let it generate your automation. Let it take that burden off your shoulders so you can focus on the "important things." Sounds great, right? Except that it isn't. Not entirely, at least. Don't get me wrong, I'm not against using AI to support testing. I use it myself.

Remember when Pluto got demoted? One day it was a planet, a proper member of the solar system. Kids learned it in school, it had its place in the lineup. Then in 2006, the International Astronomical Union decided that Pluto didn't quite meet the criteria anymore. Too small. Couldn't clear its orbit. Still there, still orbiting, but suddenly: dwarf planet. Thanks for your service.

Everyone is excited about AI coding agents. Claude Code, Cursor, Copilot, Codex, you name it. They write code, they refactor, they even debug. And yes, it's impressive to watch from the sideline. But let me ask you something: have you actually looked at the code they produce? Developers are knowledge workers. Not in the vague, corporate sense of the word. I mean literally.

Testing is an important part of systems thinking. And systems thinking is an important part of the tester's job. So what does a (software) tester actually do when it comes to thinking in systems while testing? Not in the abstract, philosophical sense. Practically. What happens in your head when you sit down to test something? I've been chewing on this for a while, and DSRP from the Drs.

I want to try describing how I think systems thinking and test cases relate. This has been brewing in my head for a while, and it connects to the mental model concept I introduced in part 0 of the Six Moves series. According to Drs. Cabrera, a mental model (M) is the way we organize (O) information (I) about a system.

Here in Germany, politicians wanted to help citizens cope with high gasoline prices. Their solution? A new regulation that allows gas stations to raise prices only once per day, at noon. The communicated intention was clear. Stop the wild price fluctuations, make prices more predictable, protect consumers. Sounds reasonable, right? Except the result is the opposite of what they said they intended.

A colleague of mine left recently. She was one of the strongest connectors I've experienced in my career. The person who remembered what was discussed three meetings or five years ago. Who noticed when someone went quiet. Who made sure the right people talked to each other before things went sideways. She didn't have a fancy title for any of this.

What? Part 7 of a six part series? Here is a small bonus. There's a trap I keep falling into. So I want to share it, maybe it's useful for you, too. You're exploring a system, you're building your mental model, you're trying to understand what's going on. And then you stumble across something. Something unexpected. Something that feels wrong. And before you even finish processing what you just observed, your brain has already slapped a label on it.

This is Part 6 of a series where I apply six systems thinking moves to the AI landscape. In Part 5 we cracked open relationships with the RDS Barbell. Now we step back and ask a different question entirely. Not what, not how, but who. The sixth move from the DSRP framework is the P-Circle. You take a topic and you lay out all the perspectives around it.

This is Part 5 of a series where I apply six systems thinking moves to the AI landscape. In Part 4 we connected the parts and watched them interact. Now we pick up one of those connections and look inside. The fifth move from the DSRP framework is the RDS Barbell. Three letters, three steps. Start with a R…

I've been warning about the dangers of AI a lot lately. And I stand by all of it. But I realized that I've been painting an incomplete picture. Because AI, used well, is genuinely useful. So let me try the other side for a change. The key question isn't whether to use AI. It's how. And the answer, as always: it depends!

I like AI. I use it every day. It helps me understand tricky things, write code, and capture ideas in new ways. And that's exactly what makes me nervous. Because there's a pattern here that I've seen before. Not with technology, but with any substance or habit that starts out making your life better and slowly, quietly, becomes something you can't function without.

There's a principle that every good craftsperson knows. Whether they work with wood, with code, or with words: the magic is in what you leave out. A well-turned wooden bowl isn't beautiful because you added more material or decoration. It's beautiful because you removed everything that wasn't the bowl. And you stopped adding when it was enough. Software used to work like that.

Over the last few months I had a weekly pair testing session with James Thomas. When I pair with James Thomas, we talk. A lot. Not about the weather or what we had for lunch, but about what we're doing and why. "I'm clicking here because I noticed this behaves differently when..." or "I want to see that, because there is a system coming later in the flow that...." The cursor moves, and the reasoning follows.

This is Part 4 of a series where I apply six systems thinking moves to the AI landscape. In Part 2 we zoomed in and found six parts inside a coding agent. In Part 3 we zoomed out and found layers both below and above. Now comes the fun part. The fourth move from the DSRP framework is the Part Party…

In 1995, scientists reintroduced gray wolves into Yellowstone National Park. The wolves had been absent for about 70 years, hunted to local extinction because people saw them as a problem. What happened after their return stunned everyone. The elk changed their behavior. Trees grew back along the rivers. Beavers returned. Songbirds came back. Even the rivers changed their course because stronger root systems stabilized the banks.

Here's a sentence I never expected to write. One indicator for the state of artificial intelligence might be whether you can get a plumber to fix your kitchen sink. At least in the US. But it shows how weirdly connected systems can be. BlackRock just invested $100 million in training plumbers, electricians, and HVAC technicians. Not because they suddenly developed a passion for copper pipes, but because the AI boom is eating through skilled trade workers at an alarming rate.

This is Part 3 of a series where I apply six systems thinking moves to the AI landscape. In Part 2 we zoomed in and discovered six parts inside a coding agent. Now we reverse the direction. The third move from the DSRP framework is Zooming Out. Instead of asking "what are the parts?", you ask "what is this thing a part of?" What larger system does it sit in?

Last week SmartBear launched BearQ, a team of AI agents that autonomously explore, learn, and test your applications. I watched the presentation and I have to say, it looks impressive. A QA Lead agent that parses your intent, hands off work to exploration agents, and comes back with results before your tea is ready. The future of testing is here, apparently.

This is Part 2 of a series where I apply six systems thinking moves to the AI landscape. In Part 1 we drew boundaries with the Is/Is Not List. Now we open the lid. The second move from the DSRP framework is Zoom In. You take a thing and you ask, what are its parts? What is it made of?

Last week, actually yesterday when writing this, SmartBear launched BearQ. An agentic QA system that autonomously explores and tests your application. About a year ago, the big news was that AI can write your code for you. So let me get this straight: AI writes the code, and now AI tests the code. What exactly are we still doing here?

Every company needs to make money. That's not a vision, that's survival. Having more income than spending is the baseline, the heartbeat that keeps the lights on. But a heartbeat alone doesn't make you alive. You need a reason to get up in the morning. And that's what a vision is. It's the reason people show up, stay late, argue in meetings, and care about the outcome.

Remember when 32 gigabytes of DDR5 cost you around a hundred bucks? That was September 2025. Six months later, the same kit costs 350 dollars or more. If you can find one at all. DRAM prices rose by more than 150% throughout 2025, and they're still climbing. Most of it only in the second half of the year. Some analysts call it "RAMmageddon."

In this morning's post, I wrote about how AI is accelerating consolidation in the IT industry. Companies are letting people go. Tool vendors are under pressure, both because of license fees and because AI can now replace entire product categories. And that pressure creates even more layoffs. It's a self-reinforcing loop. But I didn't talk about what happens next. And "what happens next" is where it gets really uncomfortable.

There's a story about Henry Ford. Ford supposedly wanted to pay his workers enough so they could afford to buy the cars they were building. Whether it's true or not doesn't matter. The point stands: your workers and your customers are often the same people. Now look at what's happening in tech right now. Atlassian just cut 1,600 jobs. Meta is planning to lay off around 15,000 people.

I recently learned something about archaeology that opened my eyes. Mostly because I somehow missed this, while it's clearly sitting in front of me. There's a whole discipline around examining ancient waste dumps. Middens, they call them. Mountains of discarded shells, broken pottery, animal bones. And it hit me: most of what archaeologists dig up is stuff people threw away or left behind.

This is Part 1 of a series where I apply six systems thinking moves to the AI landscape. Part 0 introduced the foundation: M = I × O and the Love Reality Loop. Now we get practical. The first move is the Is/Is Not List. It's a Distinction move from the DSRP framework. The idea is disarmingly simple. You take a thing, and you describe what it is.

Over the last few weeks I wrote a lot. About vibe coding. About outsourcing testing to AI. About the 10x productivity myth. About ownership, lock-in, and the bathtub that nobody is watching. I didn't plan it as a series. But looking back, all of these posts are connected. They are all attempts to explain the current state of my mental model on AI.

What happens when the richest companies in human history all push in the same direction, at the same time, across almost every industry? We're finding out right now. And if you look at it through a systems thinking lens, what you see is not just a trend. It's a cascade of leverage effects reinforcing each other. Let me explain what I mean.

I've been woodworking for about 20 years now. And if there's one thing that separates a hobbyist who makes okay stuff from someone who makes really satisfying work, it's not the tools. Trust me, I have a few Festool tools, and I still suck at using them. It's knowing which tool to reach for when and how to use it.

As long-time readers might remember, Ruth Malan has these wonderful 30-day challenges she calls "System Seeing Adventures." It is an exercise where you pick a system and you look at it through different lenses. You look at the connections, the dependencies, and the feedback loops. You use different techniques for visualization. You stop looking at the marketing slides and start looking at what is really happening.

Every few years, a new tool arrives with bold promises. Better, faster, cheaper. We've seen it with test automation frameworks, with DevOps platforms, with low-code solutions. The marketing fliers are always shiny. The demos always impressive. And the promises always the same: more output, less effort. But this time it's different. Not because AI is fundamentally better than previous hype cycles (the jury is still out on that), but because it's so generic.

My colleague James and I had a conversation the other day about this whole AI vibe-coding thing and how it affects us. And I realized that all the topics I wrote about over the last few days all lead to the same thing. The lack of ownership. A few weeks ago I wrote about what happens when you outsource testing to the AI…

Open LinkedIn or YouTube on any given day and you'll find someone confidently explaining that engineers now produce 10x the code thanks to AI. Ten times! Let it be five times. Doesn't matter. And companies are drawing the logical conclusion. If one engineer does more work by herding AI agents, you need fewer engineers. The code practically writes itself. Every bottleneck on the way gets mitigated by removing roles and people.

My friend Maaike Brinkhof recently wrote a post called "They will not break me." Her point, in a nutshell: the more they push her to offload her work to an LLM, the more she grabs pen and paper, takes her time to think, and does her work slowly and thoroughly. And it finally kicked me into writing this piece that's been bouncing around in my head for a while.

Vibe coding reminds me of micro-managing a talented junior developer. Except it's worse. Because the junior eventually learns. The junior starts anticipating your expectations, picks up patterns, develops judgment. The AI? You explain the same basics over and over. Every. Single. Task. Yes, I know about context files and skills and custom commands. I use them myself. But let's be honest here, every task you hand to an AI still needs to contain everything.