Opinion

Every developer who has been around a while has heard the excuse, usually delivered with a shrug: "works on my machine." The bug is real, the user is not lying, and the developer genuinely cannot reproduce it, because their laptop has a library version, an environment variable, or a cached file that the server does not. The phrase became a joke because it was always technically true and completely useless. We are now watching the exact same failure reappear in a new costume, and it says "it works on my prompt."

You have seen it. Someone demos a prompt that produces a perfect answer. It goes into the product. Within a day the support channel fills with outputs that are wrong, malformed, or unhinged, and the author is baffled, because it worked when they ran it. It did work when they ran it. That is precisely the problem, and it is the same problem we thought we solved twenty years ago.

Same disease, new organ

The old bug came from an environment you did not control and could not see. Your machine had state that the deployment target did not share, so behavior that depended on that hidden state broke the moment it moved.

A prompt has the same hidden state, just in different places. When you tested it, you fed it your clean example, in your phrasing, on the model version you happened to be pointed at that afternoon. Production feeds it a user who writes in fragments, pastes an emoji, switches to Spanish halfway through, or sends the empty string. Same prompt, wildly different input distribution. The prompt did not change. The world around it did, and the prompt had no defenses because you only ever tested it in the world where it worked.

There is a second layer that makes it worse than the original. The old bug was at least deterministic. Given the same machine and the same input, you got the same result every time. A language model is not deterministic by default. The identical prompt with the identical input can return a good answer now and a broken one on the next call. "Works on my prompt" is therefore weaker than "works on my machine," because it does not even reliably work on your prompt. It worked the three times you tried it, and you called that done.

We already know the cure

Here is the part that should be encouraging. The industry did not just complain about "works on my machine" for two decades. We killed it, with a set of practices so ordinary now that juniors assume they always existed: version everything, test against realistic inputs in an environment that mirrors production, put it all in a pipeline that runs before anything ships. The discipline was the answer. The same discipline is the answer here, and prompt engineering is mostly refusing to relearn it the hard way.

What that looks like in practice is not exotic. Pin your model version, because a silent upgrade is a config change that can break every prompt at once. Keep a real test set of messy, adversarial, empty, and multilingual inputs, and run your prompt against all of them, not against the one clean example that made the demo look good. Run each case more than once, because a single pass through a non-deterministic system tells you almost nothing. And gate deployment on those results, so a prompt cannot reach users until it has survived the ugly inputs.

None of this is new thinking. It is testing and version control and continuous integration, pointed at a prompt instead of a binary. The reason teams skip it is that prompts feel like writing, not engineering. You type a sentence in plain English, the model does something clever, and it looks less like code than a note to a coworker. That feeling is the trap. A prompt is a program with an input space larger and stranger than any function you have ever written, and treating it as casual text is how you end up shipping the empty string straight into production.

The teams that will be trusted with AI features are not the ones with the cleverest prompts. They are the ones who looked at "it works on my prompt," recognized an old enemy in a new coat, and reached for the boring tools that beat it the first time. The excuse was funny once. Please do not make us laugh at it twice.

For a long time the comforting story about AI went like this: sure, it can crunch numbers and play chess, but it will never do the human things, the creative things, the intuitive things. That was the line, repeated confidently, for years. I want to gently point out that the line keeps moving, and it is moving in a direction that deserves more honesty than it usually gets.

The AI safety conversation is obsessed with the ceiling: the smartest model, the frontier, the hypothetical superintelligence. I think we are watching the wrong number. The change that will actually reshape the world this decade is not that the best model got smarter. It is that a good-enough model got almost free.

Every few months a bigger model lands and the timeline decides intelligence just went up a notch. Meanwhile the people actually shipping features are not sitting around waiting for more parameters. They are fighting a different battle entirely, one that no benchmark score fixes: getting the right information in front of the model at the right moment. That, not size, is where most AI features live or die now.

The model is smart. It just does not know your stuff.

A frontier model has read a staggering slice of the public internet. What it has not read is your customer's last three support tickets, your internal pricing rules, the state of the order the user is asking about, or the document sitting in the tab next to your app. On everything that matters to your actual product, the smartest model on earth starts out ignorant, and no amount of extra parameters changes that. The knowledge it needs lives in your systems, and the job is delivery.

Watch where real failures come from. When an assistant confidently invents a policy, it is usually not because the model was too dumb to reason. It is because nobody put the real policy in front of it, so it filled the gap with something plausible. Swap in a bigger model and you get a more articulate wrong answer. Give a smaller model the right paragraph and it answers correctly. The bottleneck was never the brain. It was the briefing.

More context is not the same as better context

The obvious counter is that context windows are exploding, some models now take a million tokens or more, so just throw everything in and let the model sort it out. This does not work, and it is worth understanding why, because it kills the laziest version of the idea.

Long-context models do not attend evenly across everything you give them. The well-documented "lost in the middle" effect shows models reliably use what sits at the start and end of a long input while quietly glossing over the stuff buried in the middle. Stuff a huge context full and you can watch quality sag, not climb, as the signal gets diluted by noise the model has to wade through. There is a reason people now talk about "context rot," the way a model's grip loosens as the window fills with marginally relevant material. Dumping is not the answer. Curation is.

So the skill is not fetching more. It is fetching less, better. Retrieval that surfaces the three passages that matter instead of the thirty that might. A memory layer that remembers the two facts about this user that change the answer, and forgets the noise. Tool calls that pull a live value at the moment it is needed instead of a stale snapshot baked into a prompt an hour ago. Every one of those is a context problem wearing a different hat.

Why this is where the frontier actually is

Look at where serious effort is going and the shift is obvious. RAG, agents, tool use, memory systems, the whole apparatus is engineering to assemble the right context on the fly. None of it makes the base model smarter. All of it makes the model better-informed at the instant it answers, and that turns out to matter far more for whether your feature works.

This is also why two teams using the identical model ship wildly different products. The model is a commodity they both rent from the same API. The difference is entirely in what each team feeds it: how they chunk and rank their documents, when they call which tool, what they choose to remember and what they let go. That plumbing is the actual product. The model is the easy part, because you can buy it off a menu.

I am not claiming bigger models are pointless. A stronger model does more with a messy briefing and is more forgiving of a sloppy retrieval step, and that is real. But the returns from a better model are shrinking while the returns from better context are wide open, because most teams have barely started on the context side. If your AI feature is underperforming, the honest first question is almost never "do I need a bigger model." It is "did I actually give it what it needed to answer." Nine times out of ten, you did not, and that is a problem you can fix this week without waiting for anyone's next release.

Every AI demo lies a little. Not always on purpose, and not always a lot, but a demo is a performance, and performances are staged. The person on stage picked the example that works, ran it until it behaved, and cut the boring parts. That is not fraud, it is showmanship, and it is fine as long as you know you are watching a show and not a measurement. The trouble starts when you mistake one for the other and sign a contract on it.

I have sat through a lot of these, built a few, and been fooled by more than I would like to admit. The tricks are consistent enough that you can learn to spot them in real time.

The four moves to watch for

The most common one is the cherry-picked example. The prompt on stage is not a random input. It is the one that survived a hundred tries backstage, chosen precisely because the model nails it. A demo is one data point, presented as if it were the average. The task is not "can it do this once" but "how often does it do this," and the single triumphant run tells you nothing about the second number.

Then there is the hidden retry. On a prerecorded demo you are watching the take that worked, and you have no idea how many came before it. Even live, watch closely: a quiet reload, a rephrased prompt, a "let me try that again," and suddenly you are seeing attempt three sold as attempt one. If the presenter would not let you type your own prompt and accept whatever came out, ask yourself why.

The third is the latency edit. Real models pause. They think, they stream, they sometimes take fifteen seconds. Demo videos quietly cut that dead air, so the thing that takes ten seconds in your app looks instant on stage. It is one of the most common edits in a polished product video and one of the easiest to forget when you picture the model in your own workflow, where the wait is real and your users are watching a spinner.

The fourth is the staged input. The document is clean, the question is unambiguous, the data is perfectly formatted. Your Tuesday is a smudged scan, a half-finished sentence, and a spreadsheet with three header rows. Demos run on inputs shaped to fit the model. Production runs on whatever walks in the door, and the gap between those two is where most disappointment lives.

The questions that cut through it

You do not need to be a skeptic about the technology to be a skeptic about the demo. You just need to ask the questions the staging was designed to keep you from asking.

• Can I type my own prompt, right now, and we keep whatever comes out?
• How many times did you run this before it worked, and what is the success rate over, say, fifty tries?
• Is this real time, and if it is a video, was the timing edited?
• Show me it failing. What does a bad case look like, and how does the product handle it?

That last one is the tell. A team with a real product will happily show you a failure, because they have thought hard about the unhappy path and built for it. A team selling a demo will deflect, change the subject, or insist failures are rare, which is the answer of someone who has not looked. The willingness to show you the ugly case is the single strongest signal that there is something solid behind the polish.

None of this means demos are worthless. A good one shows you what is possible on a great day, and knowing the ceiling is genuinely useful. Just remember that you buy the floor, not the ceiling. The question that actually matters is not "how good is it when everything goes right" but "how good is it when everything goes normal," and no stage demo will ever answer that for you. You find that out by putting your own messy inputs in front of it, watching where it breaks, and deciding whether you can live with the breaks. Everything before that step is a trailer, and you would not review a movie off the trailer.

Agentic AI is the phrase every vendor deck and every board meeting is chasing this year. It is also, for most of the companies rushing to deploy it, a mistake they have not noticed yet. I say this as someone who thinks agents are genuinely useful. That is exactly why the current stampede worries me.

Ask a language model a question it has no business answering and watch what happens. It answers. Fluently, in complete sentences, with the same even tone it uses for the things it actually knows. The confidence does not move. That gap, between how sure the model sounds and how sure it should be, is the single most dangerous thing about the current generation of these tools.

People call this hallucination and treat it like a bug that a bigger model will fix. It is not a bug. It is baked into how the models are trained.

We taught them to guess

Think about how a model is graded. On most benchmarks a correct answer scores a point, a wrong answer scores zero, and "I do not know" also scores zero. Line those incentives up and the math is brutal: if abstaining pays the same as being wrong, you should always guess. A model that guesses on every uncertain question will beat an honest one that admits its gaps.

So that is the model we built. OpenAI researchers have made the point directly: under binary grading, systems are rewarded for guessing and penalized for saying they are unsure. We optimized for good test-takers, and good test-takers do not leave answers blank. The confident wrong answer is not the model failing. It is the model doing exactly what we rewarded.

Confidence is not knowledge

Here is the part that trips up smart people. We are wired to read fluency as competence. Someone who speaks in clear, structured, well-organized sentences usually knows their subject, because for humans that fluency was expensive to fake. Models make it free. A model produces the same polished prose whether it is reciting a fact or inventing one, and our instinct to trust the smooth talker fires anyway.

That is why "always check the output" is weaker advice than it sounds. Checking is exactly the effort the fluent answer discourages. The better the prose, the less you feel the urge to verify, and the more the one wrong sentence in twenty slips through.

Designing for a witness who never doubts

I do not think the answer is to distrust these tools. I use them every day and they are genuinely good. The answer is to stop treating a model like a source and start treating it like a very fast, very well-read assistant who is constitutionally incapable of saying "I am not sure." Once you accept that, the design choices get clearer.

Put the model where being wrong is cheap and visible: drafting, brainstorming, summarizing text you can see, writing code you are about to run and test. Keep it away from places where a confident fabrication is expensive and hard to catch, like a medical dose, a legal citation, a number that flows straight into a decision with no human in the loop. Retrieval helps, because grounding an answer in a document you can inspect turns "trust me" into "here is where it came from." And when you can, prefer systems that surface uncertainty at all, even a rough confidence score, over ones that render everything in the same calm voice.

There is real research now on training models to abstain, to earn credit for admitting a gap instead of being punished for it. I hope it works. Until it ships, the burden sits with us, and the honest move is to build workflows that assume the machine will never tell you when it is out of its depth. It will keep talking. The question worth sitting with is why we find that so much more comforting than a system that occasionally, usefully, went quiet.

There was no dramatic moment, no single announcement, no headline that said it plainly. But somewhere in 2026, without a parade, open-weight models stopped being the scrappy underdog and became the default sensible choice for a huge slice of real work. It was a quiet war, and the open side won more of it than anyone expected.

For about two years, "prompt engineer" was a job you could put on a resume and watch people's eyebrows go up. Six-figure listings, breathless threads about the magic phrase that cracked GPT open, whole courses selling the secret incantations. I want to be careful here, because the backlash overcorrected. Writing good prompts is a genuine skill and it will stay one. It is just not a career, and pretending otherwise did nobody any favors.

Here is the distinction that got flattened. A skill is something you use inside a job. A career is the job. Spreadsheet formulas are a skill. "Excel engineer" was never a role, even in the years when knowing Excel cold made you far more valuable than the person next to you. Prompting is heading down the same road, and quickly.

The tricks are decaying on purpose

Think about what the famous prompt hacks actually were. "Let us think step by step." "You are a world-class expert." "I will tip you 200 dollars." "Take a deep breath." These worked because early models needed a nudge to behave, and people found the nudges by trial and error. They were patches for the model's weaknesses.

But every one of those weaknesses is a bug the labs are actively fixing. Reasoning models now think step by step without being asked, because that behavior was trained in. Newer models shrug off the fake tip and the flattery because they were tuned to ignore that kind of manipulation. The clever phrase that earned you a screenshot last year does nothing this year, and that is not an accident. The whole direction of model development is to understand what you meant, so you have to say less. A skill built entirely on the model failing to understand you has a short shelf life by design.

I have watched people memorize prompt templates the way you would memorize keyboard shortcuts, and then act surprised when a model update makes half of them pointless. The templates were never the skill.

What actually survives

Strip away the incantations and look at what makes one person consistently get better results than another. It is not secret words. It is that they can state what they want. They know what a good answer looks like before they ask. They give the relevant context and leave out the noise. They notice when an output is subtly wrong and can say why. They break a fuzzy goal into parts a machine can actually chew on.

Notice that none of that is about the model. That is editing, specification, and clear thinking, the same muscles a good manager uses to brief a new hire or a good writer uses to structure an argument. Those skills were valuable before language models and they will be valuable after, because they are about knowing your own mind well enough to hand the intent to someone, or something, else.

The parts of prompting that do stay technical are drifting toward normal engineering anyway. Structuring context, wiring up tools, chaining calls, evaluating outputs at scale, managing what goes in the window. That work is real and growing, but it looks like software work, and the people doing it call themselves engineers, not prompters.

So what should you do with this

Learn to prompt well. Seriously. Anyone who uses these tools daily should get fluent, the same way anyone in an office should be able to write a clear email. Fluency compounds and it is cheap to acquire. Just do not build an identity on it, and do not pay a lot for a certificate in it.

If you want the durable version of this skill, practice saying exactly what you mean to a smart colleague who takes you completely literally and has no idea what is in your head. That is most of prompting, and it happens to be most of thinking clearly, which was always the thing worth getting good at. The models will keep meeting you halfway. Your job is to have something worth meeting them with.

I want to make a small, cranky request on behalf of clear thinking everywhere: stop calling everything an agent. The word has been stretched so far that it now means anything from a genuinely autonomous system to a chatbot that calls one API. When a word means everything, it means nothing, and the fuzziness is not an accident. It is marketing.

Every few weeks someone asks me if AI is a bubble, usually hoping I will pick a team. Yes or no, hype or real, tulips or telephones. I find the question a little boring, because the honest answer is that it is obviously both, and the useful conversation starts only after you accept that.

Read enough launch posts and you notice something strange: every new model is state of the art. All of them. Simultaneously. That cannot be true, and yet each chart is technically honest. Welcome to the benchmark wars, where nobody is exactly lying and almost everyone is being misled, gently, on purpose.

Somewhere in the last two years, a chat box became the default answer to every product question. Need a feature? Add a chat box. Onboarding confusing? Chat box. Settings page too complex? Ship an assistant. The reasoning is never stated out loud, but it goes something like: language models are amazing at conversation, therefore conversation is the interface. That second step is where a lot of otherwise good products are quietly getting worse, and someone should say so plainly. A chat box is a fantastic interface for some things and a genuinely bad one for many others, and the difference is not subtle.

What a good button already knows

Consider the humble thermostat dial, or the volume slider, or a date picker. These interfaces have a property that chat throws away: they show you the entire space of what you can do, and they take you there in one motion. You see the range, you see where you are in it, and you move. There is no ambiguity about whether you were understood, because you did not describe your intent in words that could be misread. You just did the thing.

Now do the same task in chat. "Set the temperature to 70." The system has to parse it, maybe ask if you meant Fahrenheit, confirm it heard you, and hope you did not typo 700. You have taken an action that a dial handles in half a second and turned it into a small negotiation. This is worse. It is not worse because the model is dumb. It is worse because you replaced a direct manipulation with a description of a manipulation, and descriptions can fail in ways that turning a dial cannot.

The pattern generalizes. Any task where the set of choices is small, known, and structured is a task where a button, a toggle, a slider, or a form beats a chat box. Booking a flight, filtering products by price, picking a delivery date, toggling a setting: these are solved problems, and they were solved by making the options visible and clickable. Hiding them behind "how can I help you today?" is not innovation. It is making the user do the work of remembering and typing what a dropdown would have simply shown them.

Where chat actually earns its place

I am not against the chat box. I am against using it for everything, which is a different thing. Conversation is the right interface exactly when the alternatives break down, and there are clear cases.

• The action space is huge and open-ended. You cannot put a button for every possible question about a 200-page document, so "ask it anything" genuinely beats a menu.
• The user does not know the right vocabulary yet. When someone cannot name what they want, describing it in plain language and letting the system map it to features is a real gift.
• The task is inherently linguistic. Drafting, summarizing, translating, rewriting. Here the input and output are both text, so a text interface is not a compromise, it is the natural shape.

Notice what these have in common. Chat wins when the space of possibilities is too large or too fuzzy to lay out in advance. The moment the options are finite and nameable, a visible control wins, because it removes the guesswork on both sides.

The real cost of getting this wrong

The seductive thing about a chat box is that it is easy to build and looks modern, and it quietly transfers effort from the designer to the user. A good form is hard to design. You have to think about the fields, the order, the defaults, the errors. A chat box lets you skip all of that and say, in effect, "you figure out what to type." That is not a better experience. It is an unfinished one, dressed up as a feature, and users feel the difference even when they cannot name it.

The best AI products I have used lately do something smarter than picking a side. They use chat as an on-ramp and then hand you a real control. You describe what you want in words, and the system responds not with more words but with the actual slider, the actual form, the actual button, pre-filled and ready to adjust. Language gets you into the neighborhood fast. Direct manipulation lets you land precisely. That is the pattern worth copying, and it starts with admitting that the chat box, for all its charm, is a tool and not a religion.

I am instinctively allergic to tech regulation written by people who have never shipped anything. A lot of the EU AI Act fits that description. It is late, convoluted, and parts of it will age badly. And yet, reading through what actually takes effect in 2026, I keep landing somewhere uncomfortable: most of it is the kind of thing the industry should have done on its own and did not.

There is a huge industry teaching people how to use AI: prompt courses, tool roundups, productivity threads without end. Almost nobody teaches the skill that is quietly becoming more valuable than any of them: knowing when not to use it. In 2026, the people doing the best work are not the ones using AI the most. They are the ones who know when to close the tab.

Here is an uncomfortable result that deserves more airtime than it gets. In 2025 the research group METR ran a randomized trial with experienced open-source developers on real issues from repositories they already knew well. With AI tools allowed, they finished tasks 19 percent slower. Afterward, the same developers estimated that AI had made them about 20 percent faster. They were slower and felt faster, by nearly the same margin. That gap is the whole story, and it is worth sitting with.

Why fast can feel faster than it is

The researchers pointed at reduced cognitive effort. AI-assisted work felt easier, and we quietly file easier under faster even when the clock disagrees. Watching a model produce a wall of plausible code feels like progress in a way that staring at a blank editor does not, and the feeling is real even when the output is not saving you anything.

The catch is what the feeling hides. You did not write the code, so now you have to read it, and reading someone else's code closely enough to trust it is not free. If it is wrong in a subtle way, you pay twice: once to spot the problem and again to fix it, often after you have already convinced yourself it was fine. The generation was fast. The verification was not, and verification is the part that does not show up in the demo.

Before I am accused of doom: I should note METR themselves later flagged that their study design had problems, partly because the developers who benefit most from AI would not join a no-AI condition even at 50 dollars an hour. So do not read 19 percent as a law of nature. Read it as a real, measured case where the tool that everyone assumed was a speedup was not, and the users could not tell. That is the part that generalizes.

Where the time actually leaks

The productivity leaks are boring and specific, which is exactly why they are easy to miss.

• Reviewing confident nonsense. The failure mode that costs the most is a wrong answer delivered with total assurance: a made-up function that looks real, a plausible statute that does not exist, a config flag that was never a flag. Confident and wrong is more expensive than obviously broken, because obviously broken you catch in a second and confident-wrong you ship.
• Context-switching. Every trip out to the tool and back is a small tax on your attention, and enough small taxes add up to a workday where you were busy and moved nothing.
• The almost-right rabbit hole. The model gets you 80 percent of the way, and you spend longer chasing the last 20 percent through its logic than you would have spent writing the thing yourself. Nudging a nearly-correct output into a correct one can cost more than starting clean.

None of these feel like waste in the moment. They feel like work. That is the trap.

It still works, when you aim it right

I am not telling you to put the tools down. I use them daily and would be slower without them, which is precisely why I take the paradox seriously instead of waving it off. The tools genuinely help, but the win is conditional, and the conditions are learnable.

They shine when verification is cheap or the stakes are low. Boilerplate you can eyeball in seconds. A first draft you were going to heavily rewrite anyway. A language or API you half-remember, where the model jogs your memory faster than the docs. Throwaway scripts. Anything where being roughly right is good enough and checking is quick. In those spots the speedup is real and often large.

They quietly cost you when verification is expensive and correctness is non-negotiable. Subtle logic in unfamiliar code. Anything security-sensitive. Domains where you cannot easily tell right from wrong-but-plausible, which is exactly where the model's confidence is most dangerous, because you have no cheap way to check it.

The skill, and it is a skill, is noticing which situation you are in before you reach for the tool, not after. The developers in that study were not fools. They were experienced people who genuinely could not feel the slowdown while it was happening. That is the real lesson. The tool is not the problem and neither are you. The problem is that speed and the feeling of speed have come apart, and the only fix is to occasionally check the clock instead of trusting the vibe.

I write with AI most days and I am not going to pretend I do not. It drafts, it rephrases, it gets me past the blank page. So take what follows as a note from someone who likes the tool, not someone who wants it banned. There is a cost to handing it all your writing, and it is quiet enough that you can rack up a lot of it before you notice.

Writing is thinking, and you can skip the thinking

The uncomfortable truth about writing is that most of the work is not the words. It is the figuring out. You think you understand an idea until you try to put it in a sentence and discover the hole in the middle of it. The struggle to phrase something is the struggle to actually know it. That is not a flaw in writing, it is the entire point.

When you let a model produce the sentence, you get the artifact without the process. The paragraph looks like understanding. It reads like you thought it through. But the mental work writing usually forces, the part that turns a vague sense into a real position, quietly did not happen. You skipped the gym and kept the mirror.

This is not a hunch. A 2025 study out of MIT wired people up while they wrote essays with an LLM, a search engine, or nothing, and the LLM group showed the lowest engagement, what the researchers called cognitive debt. A separate study of 319 knowledge workers found that the more people trusted the AI, the less critical thinking they reported doing. The effect is measurable, and it points the way you would fear.

Everyone starts to sound the same

There is a second cost, harder to measure and easy to feel. These models write in a house style: smooth, balanced, agreeable, faintly corporate. Lean on it and your writing drifts toward that average. The odd phrasing that was actually yours gets sanded off. Multiply that across everyone using the same handful of models and you get a strange flattening, a web where a lot of prose has the same tidy cadence and no fingerprints.

Voice is not decoration. It is the trace of a specific person having a specific thought. When you outsource the sentence, you outsource the fingerprint, and the reader feels the absence even when they cannot name it. Half of why anyone reads a particular writer is to hear how that person, and no one else, would put it.

Where I actually draw the line

I am not arguing for writing everything by hand out of principle. That would be its own kind of pose. The line I try to hold is about what the writing is for.

If the goal is to move information from A to B, a status update, a boilerplate email, a summary nobody will reread, let the model do it and get your afternoon back. The thinking there is not worth protecting. But if the writing is where you work out what you believe, an argument, a design you are still unsure of, anything you will have to defend later, write the first pass yourself. Struggle through the bad draft. That draft is you learning the subject, and the model cannot do that part for you. It can only hide that you skipped it.

The skill you stop using is the skill you lose. Not dramatically, not all at once, just a slow softening you do not clock until the day you sit down to write something that matters and find the muscle is not there. Keep writing the things worth thinking about. Let the machine have the rest.

Every executive survey says AI budgets are going up. A quieter set of numbers says most of that money is not paying off. Only about a quarter of enterprise AI initiatives deliver the ROI they promised. That gap is the most interesting, and least discussed, story in corporate AI, because the reason for it is almost never the thing everyone blames.

Open almost any app you used happily a year ago and there is a new little sparkle icon in the corner, promising an AI assistant you did not ask for and probably will not use. The bolt-on chatbot is the defining product decision of the year, and I think it is quietly making a lot of software worse. I say this as someone who loves the underlying technology.

The first time I used an AI assistant to fix a gnarly bug, I felt two things at once: relief that it was solved in four minutes, and a small, nagging sense that I had been robbed. Not by the tool. By myself. Two weeks later the same class of bug showed up in a different file, and I stared at it like a stranger. The AI had solved the problem. I had learned nothing.

This is the part of the AI conversation that gets flattened into slogans. One camp says friction is waste and anything that removes it is pure gain. The other says we are raising a generation that cannot think. Both are too neat. The honest position is that some struggle is where understanding gets built, and some struggle is just pain with no payoff, and the whole skill now is telling them apart.

Not all friction is the same

There is a concept from learning research called desirable difficulty. The idea is that certain kinds of effort, retrieving something from memory instead of rereading it, working a problem before seeing the solution, make the knowledge stick harder precisely because they were hard. The difficulty is not a tax on learning. It is the mechanism of learning. When you struggle to recall how a data structure works and then get it right, you are not being inefficient. You are laying down the thing that lets you recall it next time without help.

Now compare that to the friction of fighting a badly documented API for an afternoon, or hand-formatting a table, or writing the same boilerplate for the tenth time. That friction teaches you nothing you did not already know. It is the pain of a task, not the effort of learning. Handing it to a machine is an unambiguous win, and anyone romanticizing it has confused suffering with growth.

The trouble is that these two kinds of friction feel identical in the moment. Both are annoying. Both make you want the answer now. And the AI is equally happy to dissolve either one. So the tool that saves you from pointless boilerplate is the same tool, with the same one-keystroke ease, that saves you from the productive struggle that would have made you better. It does not know the difference, and if you are not paying attention, neither will you.

The muscle you do not know you are losing

Here is what worries me, and I say this as someone who loves these tools and uses them all day. The loss is invisible while it happens. You do not get a warning that says your debugging intuition is atrophying. You just notice, months later, that you reach for the assistant a beat earlier each time, that the threshold of difficulty at which you give up and ask has quietly dropped. The struggle you skip does not announce itself. It shows up as an absence, later, when the tool is not there or is confidently wrong and you have lost the ability to check it.

There is a real professional risk in this. The senior engineer who is valuable is valuable because of ten thousand small struggles that built judgment. If the next cohort skips those struggles, they arrive at senior titles with junior instincts, and they will not know it, because the code shipped and the tests passed the whole way up.

A rule I actually use

I have started asking one question before I hand something off: will I need to understand this again? If the answer is yes, if this is a domain I work in, a system I own, a skill I want, I do the struggle first and let the AI check my work or fill the gaps. If the answer is no, if this is a one-time chore in a corner of the world I will never revisit, I hand it over without a shred of guilt and move on with my afternoon.

This is not a call to suffer for its own sake. Suffering for its own sake is a religion, not an engineering practice. It is a call to be deliberate about which difficulties you outsource, because the machine will take all of them if you let it, and a few of them were the point.

I still fixed that bug in four minutes. I would do it again. But now, on the problems I actually care about getting good at, I make myself sit in the not-knowing a little longer before I ask. It is slower. It is also the only part of the work that is still making me better, and I am not ready to give that up for a faster Tuesday.