Author: Patrick

Maryia Tuleika recently shared a story that stuck with me. A dev team had adopted AI-assisted coding tools. They were shipping faster. The backlog was moving. The demos looked good. And then someone said it: “Testing is slowing us down.”

I’ve heard that sentence before. You probably have too. They weren’t entirely wrong. They were rather stating the obvious. Code was coming in faster than anyone could meaningfully review it. But not because the testers were slow. Because the pipeline had changed and nobody had adjusted expectations around it.

Let me give you an example. Think of a production line in a factory. For years, every station along the line works at roughly the same pace. It’s not perfect, but it flows. Now imagine you bolt a turbocharger onto one station. That station suddenly produces twice as fast. Great, right? Except the next station down the line hasn’t changed at all. What you get isn’t a faster product. What you get is an ever growing pile of half-finished work sitting on the floor between two stations.

Donella Meadows would have called this a stocks and flows problem. The flow of code into the system increased dramatically. But the stock of unreviewed, untested work started piling up. The bottleneck didn’t appear because AI created it. It appeared because AI exposed it. At the old pace, the imbalance was small enough to absorb. At the new pace, it’s undeniable.

And this is where it gets interesting. Because the natural reaction is to point at the bottleneck and say “fix that.” Fix testing. Make testing faster. Automate more tests. Throw AI at testing too. But that’s treating the symptom, not the system.

The real question is: why is testing a separate gate at the end of your pipeline in the first place?

If your process treats quality as something that gets checked at the end, you’ve designed a system with a built-in bottleneck. AI didn’t create that design. Your org chart did. Your handoffs did. Your silos did. Dev writes code, throws it over the wall to QA. That worked (sort of) when everything moved at the same speed. Now one side has a jet engine and the other side has a butterfly net.

Stafford Beer said that the purpose of a system is what it does. Not what you want it to do, not what the org chart says it should do. What it actually does. And if your system consistently produces a bottleneck at testing, then your system is perfectly designed to create that bottleneck. AI just removed any remaining doubt about it.

Maryia made an observation that I think is the key insight here. The teams that navigate this well aren’t necessarily testing more. They’re testing smarter, earlier. They’ve made risk visible to the people making decisions. That’s not a testing improvement. That’s a systems redesign.

It means testing isn’t a phase. It’s a property of the whole system. It means testers aren’t gatekeepers at the end of a conveyor belt. They’re part of the conversation from the beginning. It means risk isn’t something you discover in the last step. It’s something you talk about in the first one.

AI doesn’t break your process. It shows you where your process was already broken. That’s not a threat. That’s a gift. But only if you’re willing to stop blaming the bottleneck and start looking at the flow.

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. We even had a name for the specification document. We called it “Pflichtenheft” in German, which translates to something like “book of duties.” Sounds romantic, doesn’t it?

Let me give you an example. From 2003 till 2012, I worked on the Toll Collect project in Germany. A massive undertaking to build an automated toll system for trucks on German highways. The process demanded for every release, happening every half year, that detailed specifications were finished around nine months before production. Nine months! We had to predict every requirement, every edge case, every integration point almost a year before the changes would see real traffic. (Pun intended!) We had to write, review and approve all test cases that were supposed to be performed until the time the active testing phase started, half a year before production. What could possibly go wrong? But that was the default approach back then.

And here’s the thing. We knew that this approach had issues. We knew we were terrible at writing perfect specifications upfront. That’s exactly why the industry moved toward Agile. Small increments. Fast feedback. Adapt as you learn. Start with an idea and build only as much as you need. We acknowledged our limitation and built a methodology around it.

Now, twenty years later, we’re back to “just write a perfect spec and the agent will handle the rest.” Except this time, we’re selling our old weakness as a feature. We couldn’t master upfront specification when humans were on both ends of the process. Why would we suddenly master it now that an AI agent is involved?

But wait, there’s more irony.

With Spec-Driven Development, developers are suddenly taking on the work of product owners, business analysts, and requirements engineers. You know, the roles many developers spent years avoiding. “Just tell me what to build” was the mantra. “I don’t want to sit in endless stakeholder meetings.” “I don’t care about the business side, I want to code.”

Now coding is what the agent does. And developers are left with… writing specifications. Gathering requirements. Thinking about edge cases. Understanding the business context. Exactly the work they didn’t want to do. The irony is incredible.

Don’t get me wrong. I’m not saying AI agents are useless. They’re powerful tools. But a tool doesn’t magically give you skills you never had. If you struggled to write good specs in 2003, you’ll struggle to write good prompts in 2026. The bottleneck was never the typing. It was the thinking.

Why this push for specs now? Because you want to give larger chunks of work to agents, so that they can work unsupervised for longer. You don’t want to need to stay constantly in the loop with your agents, micro-managing them. And in the worst case even context-switching between multiple projects running in parallel. We want to avoid the micro-managing or AI-shepherding.

Maybe instead of rebranding our old failures with shiny new marketing, we should be honest about what we’re actually good at and what we’re not. We’re not good at predicting the future. We’re not good at capturing all requirements upfront. We’re not good at writing specifications so perfect that no iteration is needed.

And that’s okay. That’s why we iterate. That’s why we get feedback. That’s why we work in small increments.

Unless, of course, you’ve figured out how to write the perfect spec. In that case, please share. I’ve been waiting for that secret for over two decades now.

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.

It sounds reasonable. Thoughtful, even. Helping nature adapt.

But here’s the thing. We have centuries of data on what happens when you force species into ecosystems. Rabbits in Australia. Rats on islands with flightless birds. Kudzu swallowing the American South. The pattern is clear. Forced introduction into complex systems rarely ends well.

And then there’s Yellowstone. We removed the wolves. The ecosystem slowly collapsed. Elk populations exploded, they overgrazed the riverbanks, erosion increased, beaver populations crashed. When we reintroduced the wolves decades later, the system began to heal. A rare case where we actually understood the root cause of what we’d broken.

Now let me make a sharp turn into IT.

In the news, podcasts, or LinkedIn posts you read about Big Tech and also others currently mandating AI usage for their employees. Microsoft recently told its workforce that “AI is no longer optional, it’s core to every role and every level.” Performance reviews will include metrics on how much AI you use. Not whether it helps. Not whether it improves outcomes. How much you use it.

This isn’t assisted migration. This is deliberately introducing an invasive species and hoping for the best.

We’ve seen this movie before. Remember when Agile was the thing that would save us all? Companies mandated Agile transformations top-down. The result? Studies suggest that 70 to 90 percent of enterprise Agile transformations fail or fall short of expectations. Why? Because you cannot mandate culture. What you got instead was “Zombie Scrum,” a mechanical adoption of rituals without understanding, teams going through the motions while nothing actually changes. And the feeling “Scrum doesn’t work here”.

The pattern is always the same: executive decree, forced adoption, resistance, failure, blame the methodology.

And here’s what worries me most about the AI mandates. There’s a strange paradox at play. Junior and mid-level developers are more likely to embrace AI. They need the help. They don’t have twenty years of pattern recognition in their heads. AI fills a gap for them. But experienced developers? They often say, “I can do this myself. I don’t need AI for this task.” And they’re frequently right.

So who gets rewarded in a system that measures AI usage? The people who use it, regardless of whether they need it. And who gets penalized? The experienced folks who have built up the intuition and skill that AI is supposedly augmenting.

Do you really want to lose your most experienced people because they refuse to use a tool they don’t need? Do you want to optimize for AI adoption metrics instead of actual outcomes?

We don’t know what we’re removing or damaging when we force AI into workflows. We’re experimenting on a living system without understanding its dynamics. In Yellowstone, it took decades to understand what the wolf’s absence had done. In your engineering team, you might not get decades. You might just get attrition, quiet quitting, and a hollowing out of institutional knowledge.

Assisted migration works when it’s careful, researched, and voluntary. Forced introduction of invasive species never works.

The question isn’t whether AI is useful. The question is whether mandating its use is wise. And if history, both natural and corporate, is any guide, the answer is no.

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. The race is on. But where exactly are we running?

The Lego Problem

Right now, AI feels like a giant Lego set. We have these incredibly powerful pieces, but nobody really knows what to build with them. A few folks proudly show what they have pieced together. Model providers are fighting for market share, not because they’ve figured out sustainable business models, but because they need those IPO valuations. OpenAI shut down Sora, their video generator, despite all the hype. Subscriptions are subsidized, sometimes heavily so. Supposedly Sora made a loss of 1 million dollars – per day.

The question isn’t “What can AI do?” We’ve seen impressive demos. The real question is: “What will people actually pay for, consistently, over time?” And that’s still surprisingly unclear.

Recurring Costs, Not Infrastructure

Here’s the thing that often gets lost in the excitement. Those $700 billion in annual spending? That’s not infrastructure in the traditional sense. When you build a highway or a factory, you invest once and then maintain it for decades. AI doesn’t work that way.

Let’s break it down. Of that $700 billion, roughly 40 to 60 percent goes into chips and GPUs, depending on which analyst you ask. Another quarter to a third pays for buildings and physical infrastructure. Then there’s still huge lumps of money for power and cooling. Billions of dollars, just for electricity. And here’s the thing: that money is gone. Consumed. Next year, you pay it again. And the year after that.

Chips become obsolete. Models need retraining. Compute costs come back every single year. This isn’t a foundation you build once. This is a subscription you pay forever. And as long as scientists don’t find more efficient ways to train models, the data centers will become bigger, training times longer, and models become more and more expensive to run.

And then there’s Nvidia. Can they even deliver enough chips to satisfy global demand? Every gamer knows what happens when Nvidia controls supply and demand. Prices go up. A lot. The appetite is enormous, but the kitchen might not be big enough.

The T-Online Moment Is Coming

By the end of this year, OpenAI will likely go public. Anthropic might follow. Retail investors will get their chance to buy in. I remember the early 2000s. The internet was real. It was important. It changed everything. And still, a lot of people lost a lot of money buying T-Online shares when the bubble burst. In the meantime T-Online was re-integrated into Deutsche Telekom. The product is still there, but it doesn’t play the role it used to.
AI is not going away, it will stay. But a market consolidation will happen some time in the future. Prices need to be adjusted to actual values. Subsidizing is not a long term strategy. At least not for some of the big players who don’t have other products in house that bring big bucks.

AI is also real. It’s also important. It will also change things. But $852 billion for a company that burns cash and hasn’t found profitability? Over 50% of fund managers already see AI stocks as overvalued. That should give you pause.

Eyes Open

I’m not making predictions. A lot can happen in the next six months. Maybe OpenAI finds its killer revenue stream. Maybe new products emerge that people will pay real money for. Maybe profitability is closer than we think. This is a snapshot from April 2026, not an evaluation of the moment when shares actually go live.

But that’s exactly why I’m writing this now. When the IPO hype hits, when the headlines scream about historic opportunities, remember this: the enthusiasm is high, the business models are unclear, and not everyone who digs for gold actually finds it.

Stay informed. Stay critical. And be careful with your money.

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. Every bike you look at gets filtered through it. This one is too sporty. That one has no rack mounts. This one is perfect, actually.

What you just did has a name. The Drs. Cabrera, Derek and Laura, who research systems thinking and introduced the DSRP approach to systems thinking, call it an S-to-P Jig. You built a System (S) to understand your situation, and then you flipped it into a Perspective (P) to look at something else. The system became the lens. Simple idea. Surprisingly powerful.

And here’s the thing. Every framework you have ever used works exactly the same way.

Take Scrum. Some folks, at some point, looked at how software teams were struggling and built a model. Short feedback cycles. Clear roles. Regular checkpoints. Inspect and adapt. That model got packaged into a framework with sprints, standups, retrospectives, and a backlog. And now teams everywhere use that framework as a lens to look at their projects. Scrum is a System that got turned into a Perspective. It’s an S-to-P Jig.

This is not a criticism of Scrum. It’s actually what makes it useful. The problem starts when people forget what it is.

A Scrum Master who treats the framework as a rulebook will force every project through the same lens, regardless of context. Two-week sprints, always. Daily standups, always. Story points, always. And if the team struggles, the answer is usually “we need to do Scrum better.” But what if the lens just doesn’t fit the situation? You wouldn’t use your mountain bike model to buy a cargo bike for your kids. The model needs to fit the context.

A good Scrum Master understands that Scrum is the starting system, not the goal. They look at the team, the product, the organization, the people, and they adjust. Maybe sprints are four weeks here. Maybe the retrospective format needs to change. Maybe the backlog needs a completely different structure. They use Scrum as the perspective, but they adapt the system underneath it to match what they are actually looking at.

That’s the jig in action. And it requires something that no framework can give you. The ability to understand the system behind the framework, and then consciously reshape and adjust it for your context.

Let me give you an example. I have been in a place where daily standups turned into status reports for a manager who attended every single one. The ritual was there. The intent was gone. A Scrum Master who understands S-to-P would recognize this immediately. The system has drifted, the perspective it creates is now distorted. Time to adjust. A Scrum Master who just follows the manual would tick the standup checkbox and move on.

This is, by the way, why experienced practitioners often seem to “break the rules.” They’re not ignoring the framework. They’re working from a deeper understanding of what the framework is actually trying to do, and they’re adapting it. That’s not chaos. That’s craftsmanship.

Frameworks are not answers. They are structured questions you ask about your situation. Scrum asks: are we learning fast enough? Are we aligned? Are we delivering value regularly? Those are good questions. But the format in which you ask them, that’s yours to figure out.

So next time someone hands you a framework and says “just follow the guide,” remember the bike shop. You wouldn’t walk in without knowing what you need. And you wouldn’t buy the first bike that fits the manual description of “a good bike.” You’d think about your context first, build your understanding, and then use that to guide your choices.

That’s all S-to-P is. And once you see it, you can’t unsee it.

PS: In the Shu-Ha-Ri way of looking at it, learning and following Scrum is Shu. A good scrum master and a good team is in the Ha stage. Ri is needed when your context just doesn’t fit. Either try a completely different framework or build your own. Shu-Ha-Ri is motto from Japanese martial arts. Shu: Learn the rules. Follow the rules, so that you can get to the result. The rules protect you. Ha: Remove the rules. You have achieved a natural flow. You understood why the rules are there. It is time to bend and break the rules. As you have achieved the Shu, you can do so in a safe and controlled way. Ri: Be the rule. You can build new rules for others to follow. You have reached the next level.

“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. Just the problem, sitting there, staring back at you.

So let me be honest with you. And with myself.

I feel helpless. Not all the time, but often enough. When I look at the world right now, at the speed with which we’re adopting things we don’t understand, at the confidence with which people defend positions they’ve never questioned, at the systems we’ve built that seem to run on autopilot while we pretend we’re in control. I see it. I point at it. And then I realize: I can’t fix it.

I can’t think for you. I can’t reach into your head and rearrange the furniture. I can’t replace your experiences with mine, swap your political beliefs for different ones, or force you to see what I see. That’s not how any of this works. And even if I could, it would be wrong. I’m pretty sure that I only see a fraction of the things that matter. Your thinking has to be yours.

So what can I do?

I can share tools. Not solutions to specific problems, but something more fundamental. Ways of thinking that might help you see beyond your current frame. Systems thinking. Perspectives. Relationships. Loops. The skill of zooming out and asking “what am I not seeing?” The habit of questioning your own assumptions before you question someone else’s.

This is why I talk about the Drs. Cabrera and their DSRP framework. This is why I recommend Donella Meadows. This is why I share my Systems Seeing Adventures from Ruth Malan. Not because they have the answers, but because they offer ways to find better questions. And better questions, in my experience, are worth more than premature answers.

My posts don’t offer solutions. Because I don’t have them. What I have is a belief. If more people learned to think better in systems, to shift perspectives, to see connections instead of isolated events, we might collectively stumble toward better outcomes. Not because someone told us the right answer, but because we got better at figuring things out ourselves.

That’s my contribution. It’s small. It might not be enough. I don’t offer fish, but I offer ideas so that you can learn to fish.

But it’s what I can do. So I’ll keep doing it.

Learn to think. Not my way. Your way. Just… better.

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.

The Problem with Heroes

A hero looks like a blessing. They deliver when others can’t. They jump in when things break. They carry the weight. But what’s really happening is that the system reshapes itself around them. Dependencies form. Knowledge concentrates. The team stops building resilience because the hero is always there to catch things.

And then the hero goes on vacation. Or gets sick. Or leaves.

I’ve seen this firsthand. A colleague who put in incredible hours, nights, weekends, the full package. When he finally took time off, it wasn’t like two other people could just split his workload. He had been doing the work of two or three people, yes. But you can’t simply redistribute that. The system had grown around him.

That’s the trap. The hero masks the system’s weaknesses. And when the hero is gone, those weaknesses don’t gently reveal themselves. They collapse.

AI Agents: The New Heroes

Now look at AI coding and testing agents. They produce output at a pace no human can match. Pull requests, code suggestions, entire features, regression test sets, all generated in minutes. From a high altitude, from the management flight level, this looks like pure productivity. Velocity charts go up. Throughput increases. Success, right?

But zoom in. What’s actually happening on the ground?

The team now has to review that output. Understand it. Integrate it. Debug it when it breaks in unexpected ways. The AI doesn’t attend the meetings, doesn’t explain its decisions, doesn’t carry the mental load of maintaining what it produced. How could it? You reset the context all the time. It just outputs. And outputs. And outputs.

This is flooding the zone. The work doesn’t disappear, it shifts. The AI becomes the new hero, the tireless producer that everyone depends on but that carries no responsibility for the consequences.

Heroes are usually a sign that you have not enough people, not enough communication, and/or a brittle product or process.

The Rest of the Team Drowns

Here’s what management often misses: when one part of a system overproduces, the other parts have to absorb that. Code review becomes a bottleneck. Integration gets messy. Bugs slip through because humans can’t keep up with the volume. The team that was supposed to be “accelerated” by AI is now struggling to stay afloat.

And just like with the human hero, the system becomes dependent on something that can’t sustain it. The AI doesn’t understand context the way the team does. It doesn’t know the business logic, the history, the reasons behind certain decisions. It just generates. The team has to fill in everything else.

Balance, Not Maximization

A healthy system isn’t one where a single part dominates. It’s one where the parts work in balance. The hero, whether human or AI, distorts that balance. They create the illusion of strength while weakening the whole.

Sustainable teams distribute load. They share knowledge. They build redundancy, not dependency. They design robust processes. When you let an AI agent become the central producer, you’re not building a stronger team. You’re building a fragile one with a shiny new single point of failure.

Look Closer

If you’re in a position to observe your team from above, and you see AI-generated output as a sign of success, I’d ask you to look closer. Who is reviewing that code? Who is fixing the subtle bugs? Who is carrying the cognitive load of understanding what the AI produced?

A system that relies on heroes, human or artificial, is a system waiting to stumble. What it needs is balance.

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. Spoiler: it doesn’t.

What if biases aren’t bugs at all? What if they’re systems? Complete with inputs, outputs, feedback loops, and a strange kind of logic that makes them incredibly stable. Let me walk you through three of them.

Confirmation Bias: The Spam Filter That Learns Too Well

You have a belief. Let’s say you believe that your team’s new testing approach is solid. Now information comes in. Some confirms your belief, some challenges it. Here’s where the system kicks in: confirming information flows right through. Challenging information? Filtered out. “That’s an edge case.” “They don’t understand our context.”

The feedback loop is elegant in its simplicity. The more you filter out contradicting evidence, the stronger your belief becomes. The stronger your belief, the stricter your filter. It’s self-reinforcing.

And here’s the thing: this isn’t stupid. It’s efficient. Your brain can’t process everything. It needs shortcuts. Plus, your beliefs are tied to your identity. Questioning them hurts. The system protects you from cognitive overload and existential discomfort. It’s doing its job.

But there’s a social layer too. We don’t form beliefs in isolation. We learn what to believe from our tribes. Challenging a belief often means challenging your belonging. The group rewards conformity, punishes doubt. So the social system reinforces the cognitive one. Echo chambers aren’t a bug of social media. They’re the natural output of this system, amplified.

Think of it like an email spam filter that learns from your behavior. Eventually, it gets so “good” that important messages end up in spam too. The filter works. It just doesn’t work for what you actually need.

Sunk Cost Fallacy: The Trap of Commitment

You’ve invested six months into a project. It’s not going well. Every rational indicator says: stop. But you don’t. You invest more. Why?

The system looks like this: you have a stock of investment (time, money, emotion). Abandoning the project means that stock turns into pure loss. And loss hurts. So the system’s output is: keep going. Which increases the stock. Which makes future abandonment even more painful.

This isn’t irrational in every context. Persistence is valuable. Finishing what you started signals reliability to others. In environments where giving up early was often the wrong choice, this bias helped our ancestors survive. The system is adapted to a world that doesn’t always match our spreadsheet logic.

And socially? We’ve built entire value systems around it. “Winners never quit.” “Stay the course.” We admire the founder who mortgaged everything and made it. We don’t tell stories about the ones who wisely walked away. Or about those who lost everything. Quitting is shameful. The social feedback loop punishes rational abandonment and rewards irrational persistence.

It’s like that project at work that everyone knows should be cancelled, but nobody wants to be the one to say it. Too much budget already spent. Too many careers tied to it. The system keeps it alive.

Garbage Piling Up: The Environment That Teaches Or The Broken Window Fallacy

If you were following me on social media for a bit longer, you know that this is close to my heart. It’s this time of year again, where I take a bag and head down to the river, to my “way to work” – it’s a round-trip, because I work from home – and collect garbage, before nature starts blooming. Yesterday’s tour inspired me to write this whole post.

This one operates at a purely social level. Someone leaves a bit of garbage by the river. Sometimes it’s just the wind blowing something down from the federal highway. Nobody removes it. Signal received: this is a place where people dump things. More garbage appears. Then, at certain places, larger items. The feedback loop turns one careless act into a systemic dumping ground.

The components: the physical environment is a stock. People’s behavior is a flow. And the perceived norm, “what’s acceptable here,” is the feedback mechanism that connects them.

This bias is social learning in its purest form. We look to our environment for cues about how to behave. What do others do here? If everyone else follows the rules, I probably should too. If nobody does, why would I be the exception? We’re not making independent moral calculations. We’re reading the room. And acting accordingly. Look at the distribution pattern of cigarette butts. From time to time you will find larger collections.

Speaking of cigarette butts, another epic fail in society, at least in Germany. It’s totally normal to throw cigarette butts on the ground or out of the vehicle window. You rarely get a weird look. It’s accepted behavior. Actually it can be punished, with a fine of up to 150€. But I have never heard of anyone being fined for littering with those pesky little bits of waste, that stay around for up to 10 years and introduce poison and micro particles into the ground and water.

Software testers know this pattern intimately. One “temporary” hack in the codebase. One skipped code review. One test that’s commented out “just for now.” The first piece of garbage. And suddenly the whole codebase feels like a place where standards don’t apply.

The Pattern Behind the Patterns

All three biases share something: reinforcing feedback loops. They’re not momentary lapses in judgment. They’re stable systems that resist change. And they all have a social component that makes them even stickier. We learn what to believe from our groups. We learn what commitment looks like from our culture. We learn how to behave from our environment. The social feedback loops reinforce the individual ones.

That’s why knowing about biases doesn’t make them disappear. You can’t think your way out of a feedback loop. You have to interrupt it.

So the next time you notice a bias in yourself or others, don’t ask “why are they being so irrational?” Ask instead: what system is keeping this alive? Find the loop. Find the leverage point. That’s where change becomes possible.

PS: And before you ask if I have read “Thinking Fast and Slow” by Daniel Kahnemann. Yes, I have. Over 10 years ago. And the colleague that I borrowed it to back then, still has it. Kahnemann probably has better explanations for this than me.

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.

And nobody has several minutes anymore.

This is not a communication problem. This is a structural problem. And we built it ourselves.

Systems Take Time

Any complex system, whether it’s a political landscape, an economy, a software product, or a human organization, consists of parts, relationships, and perspectives. You can’t explain it in one sentence. You have to build the picture piece by piece. You have to show how A connects to B, how B feeds back into C, how the whole thing looks different depending on where you stand.

Even if you’re good at explaining, even if you’ve spent years thinking about how to make complexity accessible, it takes time to craft that explanation. The populist throws out a slogan in three seconds. You need three hours to develop a counter-argument that actually holds up. And then you need ten minutes of someone’s attention to deliver it.

That’s the asymmetry. The simple statement is fast and cheap. The truthful explanation is slow and expensive. And in the attention economy, fast and cheap wins.

The Erosion of Attention

We didn’t get here by accident. TikTok trained us to consume in 15-second bursts. YouTube Shorts. Instagram Reels. Headlines designed for clicks, not comprehension. News reduced to tweets.

Big Tech doesn’t profit from deep understanding. Big Tech profits from engagement, from quick dopamine hits, from the endless scroll. The algorithm rewards what grabs attention fast. And what grabs attention fast is simple, emotional, and often wrong or at least not completely correct.

We’ve been conditioned. Our attention spans have been shaved down, layer by layer, until we struggle to stay with anything that requires more than a minute of focus. And here’s the uncomfortable truth: we let it happen. We chose the short video over the long article. We chose the hot take over the nuanced analysis. We trained the algorithm by feeding it our clicks.

Now we’re stuck with the consequences. The person who needs ten minutes to explain reality loses to the person who needs ten seconds to distort it.

The Same Pattern in Software

If you think this is just about politics, look at your own workplace.

“Why does testing take so long?” asks the stakeholder. They want a simple answer. They want “yes” or “no.” They want a number, a percentage, a green checkmark.

But the truth is – here it comes – it depends. It depends on the system’s complexity, on the risk profile, on what changed, on what we learned yesterday that we didn’t know last week. The real answer requires context. It requires explaining the system.

And nobody wants to hear that. They want the bumper sticker version. “Is it done?” Yes or no.

So we give them simple metrics. Test coverage. Pass rates. Numbers that fit on a dashboard. And we all pretend that these numbers capture reality, even though we know they don’t. Because the alternative, explaining the actual situation, takes too long. People tune out. They check their phones. They move on to the next meeting.

But the world is not binary. The world is a spectrum, and has many dimensions. The simple metric wins. The nuanced explanation loses.

What Do We Do?

I don’t have a solution. The asymmetry is real, and it’s not going away. But here’s what I try to hold onto:

If you’re on the receiving end, be suspicious of the easy answer. One-liners are for comedians. When someone gives you a one-liner that explains a complex problem, ask yourself: what are they leaving out? What system are they ignoring? What relationships, what feedback loops, what perspectives are invisible in that simple statement? The easy answer is almost never the true answer.

If you’re the one explaining, get better at it. Find analogies. Use concrete examples. Start with what the listener already knows. But also accept that you won’t reach everyone. Some people don’t want to understand. Some people prefer the simple lie because the complex truth is uncomfortable. You can’t force anyone to listen.

And for all of us: take the time. When something matters, resist the urge to scroll past. Sit with the longer explanation. Let someone finish their thought. The hard truth needs more than fifteen seconds. Give it the space it deserves.

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. But there is a fundamental difference between using AI as a tool and handing over your judgment to it. And that difference is where things get dangerous.

Here is what happens when an AI writes your test suite: you get a set of automated checks that walk through predefined paths. Even worse, your test suite becomes a set of prompts, and the actions and checks performed differ from execution to execution. Variation is good, but not necessarily in that aspect. They click buttons, they verify elements, they assert that certain things appear on screen. And they do it fast and reliably. So far, so good. But now you run that suite, it passes, and you feel confident. Green lights everywhere. Ship it.

So what did those tests actually verify? They verified something that the AI interpreted from the prompt it was given. And this is where it gets tricky. When you automate tests yourself, you make decisions, lots of them. You decide what matters. You decide what to check, what to skip. And I hope you also test your test, making sure it fails when the expectation is not met.

And while automating, you recognize what smells funny. You have walked through the application, you have seen it behave. You have noticed that button that shifted two pixels, that loading spinner that stayed a bit too long. You built your checks on that understanding. You know what’s behind them. I call this exploring while automating. It is not a side effect. It is part of the value.

Here is the core issue. When you write tests yourself, you build a relationship. A relationship between you, the tester, the test you create, and the code you are testing. These three things are deeply connected. The test is an expression of your understanding of the solution and its code. The act of writing it forces you to engage with the code, to question it, to develop a mental model of what it does and what it should do. When the test runs, you know what happens. When a test is green, you know what part works and what part is left uncovered. You know about the accepted risk. It was a conscious decision during implementation.

When you let an LLM write or even only perform your tests, you break that relationship. You end up with a test suite that has no connection to your understanding. It’s like reading a summary of a book and claiming you understood the author’s intent.

And there is another side to this. Even if you had the best automation in the world, there are things that automated checks simply cannot cover. Not because the technology isn’t there, but because covering them would mean checking everything on a page, every visual detail, every interaction, every timing, every state. Even visual comparison can only cover so much. Your test code would become an unreadable, unmaintainable monster. A test that nobody can understand anymore.

This is where the human factor becomes irreplaceable. When you walk through a login flow, you don’t just verify that the login works. You see things. You notice that the error message looks odd. You catch that the page layout jumps after a redirect. You feel that something is off with the response time. You process hundreds of signals simultaneously without even thinking about it. You decide which aspects deserve an assertion. That is not a skill you can automate. It’s perception, shaped by experience and context.

LLMs, as capable as they are, don’t do this. They follow the path they think is correct to fulfill a request. As long as they can find the element they expect next, they move on. They won’t notice the eerie thing happening on the side. They won’t feel the friction. They don’t have peripheral vision. If something takes longer than expected? Probably not even detected, because exchanging a ton of tokens takes time as well.

You might say that automated tests developed by humans don’t do that either, once the human is done writing them. Fair point. But here is the difference: the human built understanding while writing them. That understanding doesn’t vanish. It informs the next test, the next conversation with a developer, the next decision about what to check.

We recently had to update our React Native version in the app. Quite a few jumps, to be honest. And under certain preconditions, buttons were suddenly invisible, yet clickable. Of course an automated test might have missed that. But when you tell Selenide to check first that the button is visible and actionable before clicking, you would find this. A human tester who has seen this kind of thing before would build that check in deliberately. Can you be sure that an LLM walking through your app does the same thing every time? Even when you have branded it into the skills?

So what am I saying? Stop using AI for testing? Of course not. Use it. Let it help you with the repetitive parts, the scaffolding, the boilerplate. But don’t mistake its output for understanding. Don’t let green checkmarks replace your own eyes. The moment you stop looking at your application yourself, you stop knowing what it actually does.

Your test suite is only as good as the thinking behind it. And right now, that thinking still needs to be yours.

PS: I have written this post on March 26th. So maybe the perfect army of agents has been invented in the meantime and this post has become irrelevant. But I doubt it.