personal_asset
It's Not That AI Isn't Smart Enough. It's That I'm Not Qualified to Boss It Around Yet
People who think they can outsource their work to AI and just pocket the spread usually aren't stopped by AI being too weak. They're stopped by their own lack of judgment. AI never gives you one answer; it hands you a pile of suggestions that contradict each other, and using it well comes down to telling which one applies now and which one applies later.
Outsourcing my work to AI. I briefly had that dream too.
There's a joke that circulates in programmer circles: an American developer subcontracts their work to a counterpart in another country for a third of the pay, then pockets the remaining two-thirds while doing nothing. A while back, staring at a pile of my own automation tasks — data cleanup, debugging scripts, picking topics for my public account posts — I caught myself having a similar thought: if AI can write code, look things up, and give advice, maybe I could move myself from doing the work to being the client. Hand it a task, collect the money, done.
Once I actually tried it, I found out what was stopping me. It wasn't that AI couldn't come up with suggestions. It was that what it gave me was never one suggestion — it was a pile of them, and they often contradicted each other.
One night in early August, I opened the backend of my personal knowledge base as usual, just to check that day's ingestion log. Two lines in, I froze: the same entry had been written in multiple times. Tracing back through the code, I found the culprit — the dedup logic depended on a search endpoint that occasionally returned a 404. The system's fallback at the time was: "if we can't check, assume it's not a duplicate and allow the write." A fallback that sounded perfectly reasonable. But that "degrade without blocking" default was exactly the most permissive path available: the moment the endpoint failed, everything got classified as safe to write, and the same batch of content kept getting rewritten week after week, with the system returning HTTP 200 the entire time — not a single error. Nobody caught it until a manual check.
That's when it clicked for me: what AI — or any automated system — hands you was never a one-line answer. It's a whole set of suggestions that constrain each other. "Favor fault tolerance, don't let the system freeze up on day one" and "favor precision, don't let your fallback path quietly become the new default" are both correct advice. They just apply at different points in time. The first belongs to the stage right after launch, when you haven't mapped the edges yet. The second belongs to the moment the system has stabilized — that's when you go back and check whether your fault-tolerant path has quietly turned into a shortcut nobody's responsible for. Treat the second piece of advice as if it were a one-time fix you could apply on day one, and the problems don't go away. They just detonate later.
The people who can actually hand work to AI and step back aren't better than me at the technical side. What they've built is a habit: when two conflicting suggestions land, they don't pick one right away. They lay them out on a timeline first — this one fixes the error in front of me right now, that one waits until the system has stabilized — and handle them separately, instead of swallowing both whole or trusting neither. Skip that step, and throwing more AI at the problem just gets you to chaos faster.
These days when I'm editing an automation script, I've picked up a clumsy habit: before I act on a suggestion from AI, I write a one-line comment marking it "now" or "later." Not elegant, but it stops me from mistaking a fault-tolerance default for a problem that's actually been solved.
Next time AI throws you a pile of contradictory suggestions, label them by timing first — this one now, that one later — before you touch anything. That beats agonizing over whether the advice is trustworthy.