Patrick “Grumpy” Prill

More Output Is Not More Value, or Why AI Might Break Your System 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.

AI turns the faucet wide open. More code, more output, better looking dashboards. But nobody's watching the bathtub. A systems thinking look at why more output isn't more value.

You Ship It, You Own It. 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…

You prompted it. You shipped it. You own it. The lack of ownership is the real problem with AI vibe-coding. And it's also why quality suffers. Generating stuff by the dozens means nothing if you're absent from your own output.

AI Increases Output by 10x. Especially Stress. 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.

AI gives your engineers x-time output. So you fire people. Push faster. Ship bugs with confidence. And watch your ops team burn at 2am. The defects didn't disappear. They just arrived later, at a higher cost. To the whole team and company. Slow down, zoom out and scale the whole system.

Friction-Maxxing, or The Case for Elbow Grease 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.

The best devs I know are lazy in the smart way. But AI is making us lazy in the dumb way. Like cleaning products that promise no scrubbing needed, we're skipping the elbow grease. Problem is, friction is how we learn. Time to learn how to distinguish necessary friction from unnecessary.

Vibe Coding is Like Groundhog Day 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.

LLMs don't learn, they're not deterministic, and reviewing their output is a full-time job. Running multiple agents in parallel without proper supervision? That's not velocity. That's negligence with extra steps.

Vibe Coding and the Return of Throwing Stuff over the Fence I touched on this topic in my last post. I want to elaborate on this phenomenon some more. Testers, remember the old days? Developers on one side, testers on the other. A fence between them, and code flying over it like a catapult delivery. "Here, we're done. Go find the bugs." No context, no conversation, no shared understanding. Just a lobbed artifact and a prayer.

Vibe coding brought the old dev-tester silo back. Except now engineers are the ones getting half-baked deliverables thrown over the fence. One person + AI agents won't replace a cross-functional team. "You need the full package, man!" New post ✍️

Context is the System – What AI Prompting and Systems Thinking Have in Common There is a quote I want to come back to, from Elisabeth Hendrickson: "The word 'context' is shorthand for the cumulative effect of all the past decisions that we cannot change now." Lately I've been thinking about it from a completely different angle. Not in the retrospective sense of "how did we get here", but in a prospective sense. What context do I need to provide, so that someone, or something, can make a good decision going forward?

Providing context to an AI is the same as describing the system in Systems Thinking. No context, generic answer. Good context, more useful answer. It's that simple.
Because, you know, IT DEPENDS!

Welcome to Mount Stupid or The Illusion of Expertise If you think that the Mount Everest base camp can be a crowded place, you have not yet been to the top of Mount Stupid. And why is there a parallel between AI and woodworking? Let's find out. Mount Stupid is this virtual place that someone tends to reach when learning about a new topic. They start looking into it, and experience a steep learning curve.

AI coding tools make Mount Stupid a very crowded place. Everyone thinks now they know how to build software.
10 years ago I talked TestBash Brighton about the Dunning-Kruger effect. Today this phenomenon has reached new heights. Thanks to everyone thinking they are now software engineers!

You are Part of the System Today, we go meta. When listening to a podcast this morning, the above sentence stood out for me. But it was not really further discussed. "You are part of the system." I had to stop the podcast to get my head around that sentence. And understand just how much valuable information is in this statement. When drawing a picture of a system, putting a multi-dimensional mental model into a 2D representation, one often ignores an important aspect.

When you describe a model or a system, you tend to forget the influence of yourself. Of course, you don't draw yourself into the model. Your context (a big, invisible box) highly influences it.

Systems Thinking seems to be important, but how does it work? Systems Thinking is basically Thinking. Systems Thinking approaches or frameworks have been invented to bring structure to thinking and enable modeling and sharing mental models. This also helps to practice thinking, when you have some more tangible ideas to talk about. Because thinking about thinking is quite on the meta level. M = I x OA Mental Model is Information combined with Organization…

Recently Systems Thinking gained more popularity. There was even a Ministry of Testing event around it. Most of the time I only hear or read that Systems Thinking is important and all the benefits of it. But nobody explained how to actually do it. I try to slightly close that gap.

Eine Rede, die Anerkennung verdient. In 1 Minute zeigt @ricardalang.bsky.social , wie man mit der AfD umgehen sollte und ja, sie spricht Friedrich Merz zurecht die Kanzlerfähigkeit ab. Hut ab vor dieser Rede!

The System of a Button Buttons are all over the screen I'm looking at. There will be buttons on the screen you read this. There's buttons in your house, in your car, everywhere. And every button is more than just a button. A button is a complex system. "Come on, now you exaggerate!", you might say. Let me explain. A button has a purpose. When you press or click the button, something should happen.

Have you ever thought about the system of a "Button"? A button is an experience. And there is so much attached to it. Let me explain.

Empathy – Understanding Motivation in Systems In the Systems Seeing Adventure we used an Empathy Map on Day 9. This is a nice tool to look at a system from other perspectives. In this case from other humans. My current favorite approach to systems thinking is the DSRP-method. The P stands for Perspective. The idea is to use the perspective of any element of the system to improve its model.

We are (still/mostly) working with real people. Users, colleagues, customers. When we want something from them, it helps to understand what they want, so that we can provide these information. This saves time and helps us to understand the system better.

Putting Lipstick on the Pig: The Downside of Automation One issue that I see every now and then is that we tend to automate things because we can. I'm guilty of that myself. Ever since I started writing scripts and tests and tools and what not, I started to automate things. Because I can. Don't get me wrong, automating things is useful and a fantastic opportunity to reduce stupid work.

Automating processes as they are can sometimes be like putting lipstick on a pig. Just because you automate it, doesn't make the process better. Maybe start by looking at what you need to automate, before jumping straight into coding.

Happy birthday ladies!!! @rosiesherry.com and @emjaykay80.bsky.social

The adventure continues. After a week of practicing some things, we are now defining a key situation and start applying different lenses. This post includes some colorful circles, bad drawings and an empathy map. I took the freedom to bundle 4 days.

Having a process doesn’t mean you get good or consistent results A topic that keeps coming back to me is pondering about simplification of processes. What is a simple process and what is a complicated or complex process? In which constraints does it make sense to have more or less details? Just because it looks simple doesn't mean it is simple. And just because it looks complex doesn't mean it is complex.

Quality Eats Process for Breakfast. That was the title of a workshop I gave 8 years ago. The message I tried to convey still stands. It's hard to define processes which result in consistent products. Wood working, baking, coffee. But especially in IT.

Grumpy Pappy is the name set on your blog. So Gemini didn’t do any magic with that.

Which reminds me of my recent hate on YouTube and why they offer me all the English and American channels with translated titles. I found the option to turn off the crap that the video plays in German. But that one…

One day I will find the right words, and they will be simple. This quote is by American novelist and poet Jack Kerouac. And ever since I read this, I aim to achieve it. So far without success. Finding the right and simple words is hard work. The same is said with the quote "I wanted to write you a short letter, but I only had time for a long one", which is assigned to Goethe, Lichtenberg, Pascal, Swift and others.

One day I will find the right words, and they will be simple. So far I was not successful. But I keep trying.

Systems Seeing Adventure – Day 5: Attending (more) Closely If you want to know more about the System Seeing Adventure, check out this link. My TL;DR: of this session is: What seems simple is rather complex, if you only look close enough. Today's task was to look at a picture and note what we see. The system and the interactions. How is it communicated and conveyed. The picture to look at can be found…

Day 5 of the Systems Seeing Adventure. Today's task was to look at a picture and note what we see. The system and the interactions. How is it communicated and conveyed.

A painting of a bird next to the words "this dumb fucker should've stayed in school"

What comes after „Clusterfuck“?! Asking for a friend.

Enjoy the process Too often I am, and probably we all are, result-driven. Get there fast, get it done, get it out of the way. Or get it automated or implemented in a way that I can reproduce something quickly by the dozen. This applied to nearly every aspect of my life.And I see my daughter now reading a lot of books. But she is always keeping track of how many pages still to read, and likes finishing books.

I was asking myself last year, why am I trying to get things done as quickly as possible? And it boils down to enjoying the accomplishment more than the journey of reaching it.

Systems Seeing Adventure – Day 4: Ackoff on Systems If you want to know more about the System Seeing Adventure, check out this link. The task for Day 4 is watch and sketchnote the TED talk by Dr. Russ Ackoff on Quality Improvements of Systems. I have tried sketchnoting in the past and it was not very successful. This talk by Dr. Ackoff was just a rapid fire of smart statements worth noting down.

Day 4 of the Systems Seeing Adventure. This time it's about watching a TED talk from Dr. Russ Ackoff. The talk is absolutely brilliant. And the task was about sketchnoting and some analysis. Warning: no sketchnoting happened. Not my forte.

System Seeing Adventure – Day 3: Explore System Concepts The task on day 3 is to explore system concepts and make concept cards out of them. I will pass on this drawing challenge and rather focus on the write-up here. I'm aware of two system concepts that helped me the last 10 years. A decade ago I read the book "Thinking in Systems" by Donella H. Meadows. The basic elements that were used in this approach are stocks, inflow and outflow.

This is day 3 of the system seeing adventure. It's about exploring system concepts. As I'm quite biased on this topic, I explain the concepts that I'm following at the moment, which are helpful to me as of now.

The concept of “enough” This weekend - when you read this, last weekend - I listened to my favorite woodworking podcast. And the topic was "Gratitude, Appreciation and the concept of Enough". "Enough" is a topic that lately rumors in my head all the time. When I look at politics, careers, economics, global warming, ecosystems, billionaires, and all topics along this line. Why do we always need more, more, more.

Testing is never done. So we need to find ways to determine, what is "enough".

System Seeing Adventure – Day 2: Draw your Org (incl. my take on orgs) The task on day 2 is not only to draw your org, but draw it in three different ways. The org to draw I choose was my company in its current state. Next step: Draw your org - 3 different ways That was harder than imagined. Next step: Jot down what you learned about your org. Rather team-centric view For some non-tech related functions I have no idea how they are organized…

Day 2 of the system seeing challenge set by Ruth Malan here https://www.linkedin.com/posts/ruth-malan-4558153_system-seeing-journal-starter-kit-2025-edition-activity-7282070530961141761-xDk7

I need to get that book.

Enjoying complexity Many years ago I learned the basics about the Cynefin Framework. The very basics. To repeat these very basics, Cynefin differentiates events into five different domains. Simple or obvious, Complicated, Complex, Chaos and Unknown or disorder. This helps to understand how to perceive situations and make sense out of them. Cynefin is based among others on systems thinking, which makes it sometimes a bit tricky to distinguish.

Enjoying complexity

Many years ago I learned the basics about the Cynefin Framework. The very basics. To repeat these very basics, Cynefin differentiates events into five different domains. Simple or obvious, Complicated, Complex, Chaos and Unknown or disorder. This helps to understand how to…

A self-made scraper plane standing on a workbench.

Several pieces of formatted wood from ash, hornbeam and apple tree, partially with patterns glued on them.

I built me a scraper plane. Based on plans from an Aussie woodworker. The plane is made from pieces of hornbeam, ash tree and apple tree. The blade is from an old Anant jointer plane.