# Your AI Has a Bias to Build - And That's a Problem

By Wes Pomeroy. Published April 17, 2026. https://wespomeroy.com/writing/ai-bias-to-build/

Anyone who's been in corporate life for any period of time, especially in the area of software development, is familiar with the term "root cause". It's pretty well traveled, but for good reason.

In business (and in life), mistakes are always going to happen. For mistakes that have a real impact, it’s essential to address the foundational conditions, assumptions, or executions that caused that problem. Because if you don’t address the problem at its source, it’s going to keep happening.

Imagine you’re in a leaky boat in the middle of the ocean. The boat slowly fills up with water. Stuff is getting wet. People are freaking out. And everyone bails the water out of the boat. Hooray, problem solved! But the next day, the boat is full of water again. Why? Because nobody plugged the holes in the hull. The boat was sinking because it was filling up with water. But the water was just the downstream symptom. The root cause: holes in the boat.

Given this, any team with experience always tries to find and address the root cause (providing they have the time and resources, and the problem warrants it). It’s sometimes tedious and time consuming, but it almost always pays off.

AI is pretty good at finding root causes. But that’s not what this article is about. It’s about my ironic observation that AI - at least the one I used (Claude) - is very stubborn about finding the root cause, and I feel like I constantly need to push it to do so.

My LLM often feels like an eager employee who just wants to build, and move forward, and go go go. It gets caught up in the moment, occasionally ignoring recent guidance I had given to slow down and be thorough. It loves to bail water out of the boat. Problem solved! Let’s get back to building! I definitely always feel a “bias to build”.

This is particularly important to be aware of when someone is building something (even documentation) using an LLM or “vibe coding”. If your output didn’t give you what you wanted, the LLM will likely try to patch or correct the output, not the actual root cause problem that caused that bad output. This greatly increases the chance that you will run into a problem again.

Here’s an example: I’m working on something that gives me tips on how to best communicate with different people in my network, based on observations of how we’ve interacted in the past, and what approach has resulted in the most harmonious outcomes. So essentially I run a little program I created to generate this “Best Tips for Working With Them” content.

When I did this recently, I noticed that it had gotten someone’s title wrong. I pointed this out and said “This person’s title is incorrect”. The immediate response was “Sorry about that, let me go fix that title”.

No. No. No. No. No.

If I had let it, it would have happily updated the output from that profiling to fix the title. But if I ever ran the process again - for the same person or others - there is a high chance it would screw up titles again. So I had to push it with several questions and prompts:

- WHY did you get the title wrong?
- What evidence did you look at (or not look at) before you asserted that person’s title?
- How can we prevent this from happening again in the future?
- Is this an issue in any other profiles?

Remember, the “cost” of implementing something using an LLM is close to zero, so there’s no problem with completely throwing out your output and re-generating it (token use / cost willing). You would rarely do that with humans because it would take too long. But if you “generate clean”, I’d argue you will get a much more robust and quality output. The goal is to iterate to what you need. For those of us raised to avoid and minimize costly iterations, it takes a minute to get your head around. But when you do, it’s liberating.