One of the most underrated skills in working with AI is stubbornness.
Not prompting.
Not knowing the name of every new model.
Not having the perfect stack of agents, plugins, CLIs, MCP servers, and automation frameworks.
Stubbornness.
The willingness to keep going after the first output is bad.
Because the first output is often bad.
This is where I think a lot of people bounce off AI. They try it for something real, get a mediocre result, and immediately go back to the way they were doing it before.
“AI can’t write good enough articles.”
“It takes more time to review than to write it myself.”
“The code is too buggy.”
“It overcomplicates simple things.”
“It gets too much wrong.”
“It’s too generic.”
“I tried it. It wasn’t useful.”
And honestly, I get it.
A lot of those complaints are true.
AI does write generic first drafts. It does produce buggy code. It does miss edge cases. It does over-engineer simple features. It does confidently produce work that looks complete but falls apart under review.
That is the part AI boosters often skip.
Most of my AI journey has not felt like some clean, futuristic productivity montage. It has felt like fumbling through half-working tools, bad assumptions, broken dependencies, confusing docs, weird environment issues, and outputs that miss the mark in ways that are hard to explain.
Even getting a basic environment running can be an ordeal.
You are wiring up MCPs, skills, plugins, CLIs, local models, API keys, dependencies, permissions, repo conventions, and whatever else the current toolchain requires. You spend hours trying to get to one working sample app, one decent workflow, one useful content asset, or one internal tool that actually does what you need.
It is not always elegant.
Sometimes it is just brute force.
I experienced this again recently while working on content marketing for Mycro.
I am building a separate content repo to help with the heavy lifting: social assets, carousel concepts, short-form scripts, reusable content systems, and the pieces around them. The goal is not to have AI magically “do marketing.” The goal is to build a system that helps me produce better work more consistently without starting from zero every time.
At first, the output was absolute shit.
Generic. Overwritten. Too polished in the wrong ways. Missing the point. Saying things Mycro would never say. Creating assets that technically followed the prompt but clearly did not understand the taste, restraint, or positioning I wanted.
It had the shape of content.
It did not have the judgment.
This is the moment where most people quit.
And to be clear, quitting feels rational.
If the output is bad, reviewing it takes a long time, and you still have to rewrite half of it yourself, it is easy to decide the whole thing is a waste of time.
The same thing happens with writing.
You ask AI for an article draft and it comes back sounding like every bland LinkedIn post you have ever scrolled past. The structure is predictable. The language is sanitized. The insight is obvious. It uses phrases you would never use.
So the natural response is: I could have written this faster myself.
And maybe you could have.
The same thing happens with code.
You ask AI to build a feature and it gives you something that technically kind of works, but the implementation is bloated. It creates abstractions you did not ask for. It ignores patterns already in the codebase. It misses obvious edge cases. It introduces bugs. It turns a simple fix into a small architecture project.
So the natural response is: I could have done this faster myself.
And again, maybe you could have.
But that is also the trap.
If you are measuring only the first output, AI often looks worse than doing the task manually.
The article is not good enough. The code is not clean enough. The carousel is not sharp enough. The workflow is not stable enough. The automation breaks too easily. The agent needs too much babysitting.
But the first version is not the verdict.
The first version is diagnostic information.
Why was the writing generic?
What examples would have anchored the voice?
What words would I never use?
What point of view was missing?
Why was the code bloated?
What constraint would have forced a simpler implementation?
What test would have caught the bug?
What existing pattern should it have followed?
Why did the content miss?
Was the strategy unclear?
Was the hook lazy?
Was the CTA too thirsty?
Was it trying to sound like a brand instead of a person?
That is the loop.
You are not just asking AI to make a thing.
You are using the bad version to discover the missing instructions, missing examples, missing tests, missing constraints, and missing taste.
Then you make those findings durable.
That last part matters.
The goal is not to win one prompt.
The goal is to improve the system.
Instead of accepting the bad output, you keep pressing.
Why is this bad?
What is missing?
What would make this feel more like us?
What would make the code simpler?
What quality bar should this have hit?
You take the bad output to another LLM entirely and ask for critique. You ask it to identify where the strategy is weak, where the voice is off, where the code is fragile, where the implementation is overbuilt, where the claims feel generic, where the asset loses the thread.
Then you bring that feedback back into the builder.
You do not just say, “Make it better.”
You say, “Here is what failed. Here is why it failed. Here is what good looks like. Now update the skill so this does not happen again.”
You turn taste into instructions.
You turn recurring misses into QA checks.
You turn vague preferences into examples and anti-examples.
You turn coding mistakes into tests, lint rules, conventions, and review steps.
You turn “this does not sound like me” into voice rules.
You turn “this code is too much” into implementation constraints.
You turn “this carousel is boring” into a sharper content rubric.
You make Claude and Codex work in the same terminal session so they can check each other’s work. You let one model create, another critique, and another pressure-test the result against the actual goal.
None of that happens from one prompt.
It happens because you were annoyed enough to keep going.
The leverage does not usually show up at the beginning. At the beginning, AI often sucks your time. You can spend a whole day trying to generate one reel, one carousel, one landing page section, one feature, one internal tool, or one workflow that would have been faster to do manually.
That feels like failure if you are measuring only that one artifact.
But sometimes the artifact is not the point.
The point is the system you are building behind it.
The first article takes too long because you are not just writing an article. You are finding your voice rules. You are building your editorial bar. You are teaching the system what claims are too generic, what examples matter, and what kind of language feels false.
The first feature takes too long because you are not just shipping a feature. You are teaching the system your repo structure, your preferred patterns, your tolerance for abstraction, your testing expectations, and the kind of code you do not want to maintain later.
The first carousel takes all day because you are not just making a carousel. You are defining the content strategy. You are shaping the voice. You are building the review loop. You are discovering what the AI gets wrong. You are creating the skill that will make the tenth carousel easier and the fiftieth carousel much better.
That is the trade.
AI work often feels inefficient right before it becomes leverage.
It is slow, clumsy, and frustrating until the moment the system starts to hold. Then suddenly something changes. You are not starting from scratch anymore. You have a workflow. You have reusable context. You have QA. You have examples. You have tests. You have a machine that can help carry more of the load.
That is when it starts to feel a little magical.
Not because the model became perfect.
Because you stayed with the problem long enough to teach the system what good looks like.
I think this is the real dividing line for AI adoption.
It is not between people who use AI and people who do not.
It is between people who treat bad output as proof that AI does not work and people who treat bad output as diagnostic information.
The first group tries it, gets frustrated, and goes back.
The second group keeps asking:
Why did this fail?
What context was missing?
What rule would have prevented it?
What example would have helped?
What test should have caught this?
What should the next agent check before calling this done?
That mindset compounds.
Because once you start thinking this way, you stop seeing AI as a vending machine where prompts go in and finished work comes out.
You start seeing it as rough but powerful system-building material.
You still need judgment.
You still need taste.
You still need domain expertise.
You still need to know when something is wrong.
Maybe more than ever.
But if you have those things and you are willing to be stubborn, the ceiling gets much higher.
You can build workflows that would have required a team.
You can create internal tools that would have sat in a backlog forever.
You can turn repeated manual work into reusable systems.
You can make multiple models critique, improve, and pressure-test each other.
You can move from “AI helped me make this one thing” to “AI helped me build the machine that makes this kind of thing.”
That is the shift.
And it is uncomfortable because the early stages do not feel like leverage. They feel like wasted time.
But that is true of a lot of meaningful skill acquisition.
The first time you build the system, it is slower than doing the task yourself.
The second time, it is still probably slower.
Then one day, it is not.
That is why stubbornness matters.
You have to be willing to push through the awkward stage where the writing is not good enough yet, the code is not clean enough yet, the workflow is not stable yet, the output is not on brand yet, and the whole thing feels like it might be more trouble than it is worth.
Sometimes it will be.
Not every task deserves a system. Not every workflow needs AI. Not every bad output is worth saving.
But the people who never push past the first bad version will never find the parts that do scale.
They will keep saying AI is not useful for serious work.
Meanwhile, the stubborn people will be quietly turning their frustration into infrastructure.
Leave a Reply