AI Won't Take Your Job. But It Might Embarrass You If You Let It.
Every week someone publishes a new piece about how AI is coming for jobs. White-collar jobs, creative jobs, coding jobs, legal jobs. The tone oscillates between breathless excitement and low-grade dread, and the argument always comes down to the same thing: look at what these models can do.
And to be fair — the things they can do are genuinely impressive. Summarize a 200-page contract. Write production code from a vague description. Explain quantum entanglement to a ten-year-old. Pass the bar exam. These are tasks that humans find hard. Real hard. The kind of hard that takes years of training and still produces mistakes.
So I understand the anxiety. I really do.
But here is what the discourse consistently misses: the inverse is also true, and it is spectacular.
Moravec's Paradox, But Make It Embarrassing
In the 1980s, AI researcher Hans Moravec noticed something counterintuitive. The things computers found easy — arithmetic, chess, logic puzzles — were the things humans found hard. And the things humans found trivially easy — walking across a room, recognizing a face, understanding a joke — turned out to be extraordinarily hard to encode in software.
LLMs have a version of this problem, and it does not get talked about nearly enough.
These models are brilliant at tasks that require synthesizing large amounts of text into fluent, structured output. They are genuinely terrible at tasks that require interacting with the world as it actually is — checking whether something is true right now, navigating constraints that require real-world verification, or knowing when to stop and say "I cannot actually confirm this."
What they are especially bad at is knowing that they are bad at something.
The Naming Story
We were recently helping spin up our new company. Part of that process was finding a name — which sounds simple until you add constraints.
The criteria were:
- Something quantum-related
- A
.comdomain that was either available or clearly for sale - Three syllables or fewer
- Pronounceable — the kind of name that survives being said out loud at a conference or passed along by word of mouth
- Not already claimed by an existing company in the quantum space
Five constraints. Totally reasonable. The kind of thing a creative person with a browser and a domain registrar could knock out in an afternoon.
So we did what you do in 2026: we took the requirements to our favorite LLMs.
They generated names. Some of them were genuinely interesting. The models had clearly absorbed a lot of quantum vocabulary, and the outputs had the right texture — they sounded like they could be quantum companies.
But then every single model did the same thing. It confidently told us the domain was available. It sometimes even provided a link. And when we went to check, the domain was taken, parked, or — best of all — already the homepage of a different company in the space we were trying to enter.
Not "possibly available." Not "you should check." Available. With the certainty of a model that has no idea it cannot actually ping a WHOIS server.
The Textbook Moment
One of the team members — not an AI, a human being, with a shelf — pulled out his quantum computing textbook from undergrad. The physical one. With the spine and the margin notes.
He started flipping through it.
And he found a name: Squarewell.
As in the square well potential — one of the foundational thought experiments in quantum mechanics. You have a particle confined to a region of space with infinitely high walls on either side. Inside the well, it is free. Outside, it cannot go. The result is that the particle can only exist at specific, discrete energy levels — not a continuous spectrum, but a set of quantized states. It is one of the first problems every quantum physics student solves, and it is the conceptual bedrock for understanding how quantum systems are bounded, measured, and controlled.
For a quantum machine learning platform, the metaphor lands cleanly. Quantum ML is about finding which states are possible, which energy levels your system can occupy, and how to work within those constraints to extract useful computation. The square well is where you learn to think that way. It felt right.
He then did the things you do when you find a name: checked the domain, searched for existing companies, looked at trademark databases, ran it by a few people to see if it passed the "say it out loud" test. The whole verification loop that LLMs confidently skip over.
It cleared every constraint. We had our name.
The model had failed not because it lacked creativity or domain knowledge. It failed because the task required ground truth — live data, real-time availability, actual verification — and it had none of that. It just... filled in the gap with confidence.
A footnote on agents
Someone is going to read this and think: well, you should have used an agentic setup with real tool access. A model that can actually query a WHOIS database or fetch a live URL would not have made this mistake.
Here is the thing: they had those tools. Every model we used had web search and URL fetching available. That is actually what made it worse. We believed them at first precisely because they could have checked — and we assumed they did. The confident assertion of domain availability landed very differently coming from a model with live web access than it would have from a model we knew was working from static training data.
It took a few rounds of being burned before we stopped trusting the answers and started verifying them ourselves.
So no, agentic capability is not the escape hatch here. The problem is not that the models lacked access to ground truth. The problem is that they did not reliably use it, and gave no indication of whether they had. The confidence was identical whether the model had actually fetched the page or just pattern-matched on what a plausible domain availability response looks like.
The point stands.
What This Actually Means for Your Job
Here is the honest take: AI is not coming for your job. It is coming for the parts of your job that you were probably not excited about anyway.
The synthesis. The first drafts. The summaries. The boilerplate. The "take these five documents and give me the key themes." That stuff — yes. Models are genuinely good at it, it is faster, and pretending otherwise is just denial.
But the parts of your job that require you to interact with the world as it is? To verify, to check, to use judgment about what is actually true versus what sounds plausible? To know when the thing you are looking for is in a textbook on a shelf rather than in a prompt response?
Those parts are yours. And they are more valuable than they were before, because they are now the constraint.
The people who are going to struggle are not the ones whose jobs have boring, repetitive components — those jobs already had problems. The people who are going to struggle are the ones who hand the whole task to the model without understanding where the model's confidence ends and its competence ends.
But Let's Be Honest About the Other Half
The same week we were flipping through textbooks to find a name, we used LLMs to build the web presence for Squarewell. Design, copy, structure, the whole thing. Half a day. It looks like a real company — because it is, and because the models that are good at that kind of work are genuinely extraordinary at it.
That is not a contradiction. It is the point.
The naming task required real-world verification. The web build required synthesis, creativity, and fluent output from a well-specified brief. Same week, same team, radically different results depending on whether we matched the task to the right tool.
The Part Nobody Tells You
Here is where it gets complicated: knowing which model is good at which task is not a thing you can just look up.
Every few weeks a new model drops, benchmarks get posted, someone writes a hot take, and the landscape shifts again. The benchmarks tell you how a model performs on standardized tests. They do not tell you how it performs on your tasks, with your prompting style, and your way of thinking through a problem.
That last part matters more than people realize. Two people can use the same model on the same task and get dramatically different results, because the model is shaped by how you interact with it. Your prompts, your follow-ups, how you structure ambiguity, whether you push back or accept the first answer — all of it changes what you get. Model performance is not a fixed property. It is a relationship.
This is what we do at RamenAtA. Not just know the models — we work with them constantly, across enough different tasks and problem types to have a calibrated sense of what each one is actually good for right now, with the way real people work. That knowledge compounds fast and goes stale fast, and staying current with it is a job in itself.
You could learn all of this yourself. Plenty of people do. But it takes time to build up the intuition, and by the time you have, the landscape has moved again.
A Hammer Is Still a Hammer
I am using an AI to help write this post. That is not a secret — it says so right there in the byline. I used it to sharpen sentences, tighten structure, and catch the places where I wandered.
No. I use it a lot more than that. This is the first line I've directly written into a post. I read the posts, but generally will tell the LLM to go back and edit this or change that, but in this case I'm taking the wheel.
What I did not do is ask it to tell me something true that it could not verify, and then publish that thing as fact.
That is the whole game. Know what the tool can do. Know what it cannot. And do not let the impressive stuff blind you to the gaps.
A hammer is an extraordinary tool. It drove the nails that built every house you have ever lived in. But when you need to know whether a wall is load-bearing, you call a structural engineer — not because hammers are overrated, but because hammers do not know about walls.
AI is the most useful hammer we have ever built. That is true. It is also just a hammer.
Curious about how to actually integrate AI into your workflow without the landmines? Book a sprint with RamenAtA and let's figure out where the model ends and you begin.