The AI builder mindset: why the meta-question changes everything

Confession time. For six months, every time an AI agent shipped me garbage, my first reflex was: “this model sucks.”

Rage quit. Restart. Change the prompt. Sometimes change the model entirely. And the next day, exact same errors, all over again.

Meanwhile, my dev buddy working on the same kind of projects was getting twice as fast as me. Not because he had a better model. Because he had better logic when something broke.

And that logic, the one I took way too long to figure out, is what separates devs who struggle forever from devs whose agents get better every single week.

Act 1, the first-impression trap

You know the script.

You ask Claude (or any agent) to ship a feature. It generates 200 lines. You run it. Crash. Or worse: it compiles, it runs, but it’s architectural garbage, a repository imported directly into a widget, business logic stuffed into a build(), a 400-line file with three classes inside.

And right there, two worlds split.

The first world, the one I lived in for six months, is the world where you treat the symptom. You paste the error into the chat. The AI fixes it. You ship. Next.

Except the next week, the AI makes the exact same mistake in another file. You re-paste the error. It re-fixes. You re-ship. By the end of the month, you’ve spent 40 turns on the same problem without ever actually solving it.

That’s the trap. You solve incidents instead of solving the class of incidents.

Act 2, the real problem isn’t the AI

When I started comparing my runs to my buddy’s, I saw it.

The AI made the same mistakes for both of us. Except for him, they only happened once.

Not because his model was smarter. Because every time something broke, he asked himself a question I systematically skipped:

“How do I make this never happen again?”

Not “how do I fix this now.”

“How do I make this never happen ever again.”

And the answer to that question is never a fix in the code. It’s a change in the agent’s logic.

It’s the exact same difference between a junior who patches a bug and a senior who patches the system that produces bugs.

Same with AI. It’s not going to get better on its own. You’re the one who has to teach it not to make the same mistake.

And to do that, you need to understand a fundamental distinction.

Act 3, prompt vs skill: the line that changes everything

A prompt is a one-shot instruction. A request. A single move.

“Generate me a login screen with this design.”

A skill is a durable instruction. A rule that auto-applies every time you enter the relevant context.

“Whenever you touch login, read auth_architecture.md first, never put business logic in the widget, and always use the Riverpod pattern defined in auth_provider.dart.”

A prompt is disposable. A skill is capitalizable.

You can write 200 prompts a month and end the year exactly where you started. Write 10 well-crafted skills in the same period, and every prompt after that becomes better by default, without you needing to repeat anything.

It’s the difference between teaching to fish and giving a fish, applied to an agent that never forgets.

And it’s exactly the lever most devs miss. They stay in “prompt” mode forever. They retype their custom instruction every single time. They fix the same errors on loop. They never capitalize.

But AI is the most capitalizable tool ever invented for a solo dev. As long as you flip the logic to the right side.

Act 4, the 3 reflexes when something breaks

Here’s where it gets concrete.

When an AI agent produces an error, bad architecture, file in the wrong place, pattern violating your conventions, you have exactly three possible reflexes. And only the third one grows your system.

Reflex 1, rage quit

“AI sucks.”

You close the session. You write the code by hand. You tell yourself you’re faster on your own anyway.

It’s the most human reflex and the most insidious one. Because short term, you feel productive. You shipped the feature. But you lost twice: you wasted the tokens of a failed run, and you let go of an opportunity to make the agent better.

Rage quit is the reflex of the dev who’ll say two years from now: “I tried AI, it wasn’t for me.” Spoiler: it was for him. He just didn’t stick.

Reflex 2, i report

“AI, you screwed up. Here’s the error. Fix it.”

The AI fixes it. You ship. You move on.

Better than rage quit. At least you’re moving. But it’s exactly the trap I described earlier: the same error will come back next week, because nothing has changed in the agent’s logic. You patched a symptom.

90% of devs who use AI stay here. Forever.

Reflex 3, the meta-question

“OK, AI screwed up. How do I make this never happen again?”

Now you’re going up a level. You’re not fixing the code anymore. You’re fixing the system that produced that code.

Concretely, that can mean:

• Adding a rule to the relevant SKILL.md
• Creating an architecture file the agent must read before touching that area
• Replacing a fuzzy instruction with a precise example in the docs
• Identifying a recurring pattern and formalizing it as a written convention
• Discovering your skill is mixing “decision context” and “execution context” and re-splitting it

It’s slower. The first time, it’s noticeably slower. Instead of saving 5 minutes on a fix, you spend 20 updating your skill.

But it’s the only reflex that turns a cost into an asset.

Act 5, the compounding doc

A well-written skill is exactly like a rental property investment.

At first, it’s thankless. You drop 10 lines of rules into a markdown file, and you wonder “is this actually going to change anything?”. You see nothing right away.

But on the second avoided error, you feel something.

By the tenth, your skill starts running on its own.

Three months in, the agent knows your codebase better than half your former coworkers did. It respects your patterns without you having to think about it. It anticipates traps it used to fall into.

And the magic part is that every line you add stacks on top of all the previous ones. Your skill grows, but more importantly it gets smarter. Today’s meta-question prevents tomorrow’s errors in contexts you hadn’t even anticipated.

That’s the compounding. Today’s effort pays multiple times, in future situations you haven’t seen yet.

And there’s a bonus nobody calculates: your skill survives model changes.

I wrote most of my skills under Opus. I switched to GLM 5.1 when Opus 1M was retired. The system barely flinched. Why? Because the business logic was in the skill, not in the model. The model changes. The skill stays.

A dev with 50 well-written skills owns an asset nobody can take from them. A dev with 50 prompts they retype from scratch every day will, two years from now, still have 0 skills and still be retyping the same prompts.

The gap widens exponentially.

The logic in one sentence

If you only take one thing from this article: every AI mistake is a chance to make it better forever.

Not for that one run. For all the future ones.

And the line between “I use AI” and “I have an agent that feels like me” comes down to a single habit: taking 20 minutes instead of 5, every time something breaks, to update the skill instead of the code.

It’s slower. It’s more annoying. It’s also the only thing that compounds.

Conclusion: you’re an investor, not a consumer

The right mental model isn’t “I use AI to code faster.”

It’s “I’m building an agent that feels like me, and every day it becomes a little more me.”

You’re not an AI consumer. You’re an investor in your own system.

And like any good investment: what pays isn’t the one-off stroke of genius. It’s the discipline repeated long enough for compound interest to do its job.

The meta-question is your entry ticket.

If you want to see how I actually structure my skills, I covered it in How I optimized my AI agents’ context and in My AI agent system for automating my indie dev business.

So, which reflex are you on? 😄