My AI Told Me Not to Build It. I Built It Anyway.

In plain English In May I wanted to add a small tool to my AI system. My own AI reviewed it and told me not to bother. Off-mission, it said. You already have a rule like this. That was a reasonable answer, and it was wrong. Two months later I made that same tool the discipline every build in my system runs on. The AI was not lying to me. It had quietly assumed something about my business that was no longer true, and it never mentioned the assumption. That is the failure worth learning, because it will happen to you too. Here are the four questions that catch it. 五月的时候，我想在我的 AI 系统里加一个小工具。我自己的 AI 看了一眼，说不用做。它说这不在你的主线上，而且你已经有类似的规则了。这个回答听起来很合理，但它是错的。两个月后，我把同一个工具，变成了整套系统做任何东西时都要跑的纪律。AI 没有骗我。它只是默默地对我的生意做了一个假设，而那个假设已经不成立了，它也从来没告诉我。这才是真正值得学的失误，因为它也会发生在你身上。以下是四个能抓到它的问题。

TL;DR

AI does not usually fail by being stupid. It fails by assuming something about your situation and never telling you what it assumed. My own system told me a tool was redundant. Two months later that tool became the discipline my whole build process runs on. The recommendation was sound. The assumption underneath it was stale. So before you hand any job to AI, ask four things: what is it assuming, what is the simplest version, what must not change, and how will I know it is done. Four questions. They cost you thirty seconds and they save you the rework.

AI 出错，通常不是因为它笨。是因为它对你的处境做了假设，而且从来不说它假设了什么。我自己的系统告诉我某个工具是多余的。两个月后，那个工具变成了我整套开发流程的纪律。建议本身没问题，底下那个假设过期了。所以在你把任何工作交给 AI 之前，先问四件事：它假设了什么、最简单的版本是什么、什么绝对不能动、我怎么知道做完了。四个问题，花你三十秒，帮你省下返工。

The recommendation that was wrong

On 31 May I was importing a batch of 13 small tools into my AI system. Number four in the batch was a set of coding-discipline rules. Nothing fancy. Four principles about how an AI should behave when it builds something for you.

My own system reviewed it and pushed back. Its note is still in my log, word for word: flagged as off-mission, dev discipline rather than a content engine, and overlapping a rule I already had. In plain terms: skip it, you do not need this.

I built it anyway. I did not have a clever reason. It just felt like something I would want later.

31 May 2026 · what it said

"Off-mission. Overlaps a rule you already have."

23 July 2026 · what happened

The same tool became the discipline every build in the system runs on.

Both entries are in my own change log. Fifty-three days apart.

Two months later I went back to it and promoted it. Those four principles are now the shared discipline behind three different build processes in my system. The thing I was told to skip turned into the thing everything else leans on.

What it actually got wrong

Here is the part that matters, and it is not "the AI made a mistake".

The AI was reasoning correctly. Given what it believed about my business, "off-mission" was the right call. The problem is what it believed. It assumed my system was a content factory, a machine for turning out posts and captions and videos. In May, that was mostly true.

By July it was not. The system had started building things. Real tools, client systems, working software. The moment that changed, a rule about how to build carefully stopped being off-mission and became the centre of the whole thing.

The AI never said "I am assuming your business is a content operation." It just answered as if that were settled. And that is the trap. I was not handed a wrong answer. I was handed a correct answer to a question about a business I used to have.

It did not give me a wrong answer. It gave me a right answer to a question about the business I used to have.
— Weiss Ang

Somebody already named this

I am not the first person to notice this. Andrej Karpathy, one of the most respected engineers in AI, put the pattern in one sentence: the models make wrong assumptions on your behalf and just run along with them without checking.

Read that again slowly, because there are two failures stacked in it. The model assumes. Then it proceeds as if the assumption were confirmed. You do not get a warning. You get output that looks finished.

Someone packaged his observations into a free set of four rules for developers, published at multica-ai/andrej-karpathy-skills. That is the tool my system told me to skip. It is written for engineers, and if you write code you should read it as-is.

But the failure it describes is not a coding failure. If you have ever briefed a staff member badly and got back something technically correct and completely useless, you already know this problem. It is a delegation problem. Software just found it first, because programmers hand work to AI a hundred times a day and see the damage faster.

The four questions

So I translated the four rules out of engineering and into the language of someone running a business. Same principles. No code.

Ask these before the work starts, not after it comes back wrong.

What is it assuming?

Ask it directly: what did you assume about my business before answering? You will be surprised how often something wrong comes out. It assumed your customers pay upfront. It assumed you have staff. It assumed the thing that was true last year.

From: Think Before Coding

What is the simplest version?

AI loves to give you the impressive answer. Ask for the smallest thing that solves the actual problem. If it hands you a twelve-step system, ask which two steps do most of the work, and start there.

From: Simplicity First

What must not change?

Say out loud what is off-limits before it starts. My prices stay. My tone stays. This paragraph is approved, do not touch it. Without that line, AI tidies things you never asked it to tidy, and you find out later.

From: Surgical Changes

How will I know it is done?

Write the finish line first, in a form you can actually check. Not "make it good". Try "three options, under 200 words each, no price mentioned". Karpathy's own note is that these models are excellent at looping until they hit a specific goal. So make the goal specific enough to hit.

From: Goal-Driven Execution

Question one is the one that would have saved me. If I had asked my system what it assumed my business was, it would have said "a content operation", and I would have caught the stale premise in about four seconds.

What it looks like when this works

The point is not that AI should stop having opinions. It is that the opinion should arrive with its reasoning attached, so you can check the premise instead of the conclusion.

That does happen, and it is worth showing. In June I decided to fold a new tool into an existing one. My system pushed back and said the two things had different shapes and folding them would make both worse. It explained why. I read the reasoning, agreed, and built the thing separately instead. That is logged too.

Same system. Same month. One time it was wrong and I overrode it. One time it was right and I changed my mind. Both were useful, and both were useful for the same reason: the thinking was visible.

I don't sell anxiety. I install systems. 我不卖焦虑，我装系统。
— Weiss Ang

How to start this week

You do not need to rebuild anything. This is a habit, not a project.

Pick one job you already give AI every week. Your quotations, your captions, your supplier replies. One that repeats.
Run the four questions on it once. Before you send the request, not after. Write the answers in the same message.
Pay attention to question one. Ask what it assumed about your business. This is where the surprises live, and it takes ten seconds.
Keep the finish line written down. Once you have a good one for a repeating task, reuse it. That single line is worth more than any prompt template you will ever download.

You are not behind because you are not technical. This is not a technical skill. It is the same judgment you already use when you hand work to a person, applied to a machine that is extremely confident and cannot tell you what it took for granted.

The machine can do the thinking. Checking what it assumed is still your job. That part does not get automated, and honestly, that is the good news.

FAQ

Why does AI give confident answers that turn out wrong?

Because it fills the gaps in your request with assumptions, and it does not show you the assumptions. Karpathy put it plainly: the models make wrong assumptions on your behalf and run along with them without checking. The answer is not a lie. It is a correct answer to a slightly different question, and you never saw the swap happen.

What are the four questions to ask before giving AI a task?

What is it assuming? What is the simplest version? What must not change? How will I know it is done? They come from four coding principles Karpathy popularised, translated for people who do not write code. Ask them before the work starts, not after it goes wrong.

How do I know when to override what the AI recommends?

Ask it what it assumed about your business before it answered. If the assumption is wrong, the recommendation built on it is wrong too, no matter how reasonable it sounds. AI is very good at reasoning and it cannot check the premise it started from. That check is your job.

Do I need to be technical to use these four questions?

No. The principles came from software, but the failure is not a coding failure. It is a delegation failure. The same four questions work on a quotation, a hiring decision, a marketing plan or a supplier email.

What does defining done actually mean when working with AI?

It means writing the finish line before the work starts, in a form you can check. Not "make it good". Something closer to "three options, under 200 words each, no price mentioned". These models are excellent at looping until they hit a specific goal, so the goal has to be specific enough to hit.

Is it a bad sign when AI pushes back on my idea?

No, that is the behaviour you want. An AI that surfaces a tradeoff before building is doing its job. The danger is not disagreement, it is silent agreement. You want a system that says here is what I assumed and here is a simpler option, then leaves the decision with you.

Sources

multica-ai/andrej-karpathy-skills. The free four-principle guideline set for AI-assisted building, derived from Andrej Karpathy's observations on where LLMs go wrong when they code.
The May and July entries quoted in this piece are from my own system's change log. I have kept the wording as written at the time, including the part where it told me not to build the thing.

Stop guessing what your AI assumed.

The AI Solopreneur OS community is where solo owners learn to hand work to AI without losing control of it. Free to join.

Join the free community

← All articles Home →