Why I still use find and replace.

There’s a tool that’s been in Microsoft Word since 1983. It has no machine learning model behind it. It can’t hold a conversation. It doesn’t get better over time. You tell it to find a string of characters and replace it with another string of characters, and it does exactly that. Every instance. Every time. Without exception.

It is, by any modern measure, completely stupid.

It is also, for that one job, more reliable than AI.

What reliable actually means

When I say reliable I don’t mean impressive. I don’t mean capable. I mean: does the thing you said you’d do, completely, without missing any.

Find and replace is reliable because it has no interpretation layer. It doesn’t decide which instances seem most relevant to your request. It doesn’t weight some parts of the document more heavily than others. It doesn’t generate output that looks like a complete result while quietly skipping the instance in the middle of page 14 that didn’t match the pattern it expected.

It finds the string. It replaces the string. Done.

Ask an AI to do the same job and you get something that sounds considerably more capable. It’ll understand context. It’ll handle variations. It’ll explain what it did. And it will probably get most of them. The instances in obvious places, written the way it expects, in the parts of the document it weighted most heavily during processing.

The one in the quiet middle of a 400-line file, written slightly differently, sitting in a comment rather than active code? That one might survive. The AI will tell you it got everything.

Why this happens

Large language models don’t read documents the way a compiler reads code, or the way find and replace reads a file. They attend to documents. They weight different parts of the input based on what seems most relevant to the immediate prompt. Content at the start and end tends to get more attention. Dense, unusual patterns get noticed. Repetitive, unremarkable sections get skimmed.

This is not a bug. It’s how the architecture works, and it’s what makes these tools extraordinary at so many things. Understanding intent, generating nuanced output, reasoning across complex problems. The selective attention is the feature.

But selective attention is the failure mode for jobs that require exhaustive, systematic processing. A security review that misses the vulnerability in the boring middle of the file isn’t a security review. A rename operation that gets 97% of instances leaves 3% of instances with the old name, which is enough to break things, and the 97% will make you confident it’s fine until it isn’t.

The problem with confident output

The harder issue is that AI output doesn’t come with a reliability indicator. Find and replace shows you a count: 47 instances replaced. You can verify that. You can run it again and get zero results, which confirms it’s done.

AI tells you it reviewed the codebase for security issues and found three things worth addressing. That output is generated based on what a thorough security review looks like, applied to the parts of the code it actually processed carefully. The three things it found may be real. The things it didn’t mention may be fine, or they may be the thing that causes the incident six months from now. The output looks identical either way.

And here’s the part that makes this genuinely hard to guard against: the output doesn’t just sound complete, it sounds authoritative. Fluent, well-structured, confident prose is the signal we’ve always used to evaluate whether someone knows what they’re talking about. For humans, that correlation is real. Fluency takes understanding. The writing is evidence of the thinking.

AI breaks that correlation without breaking the reflex. The prose is fluent because it’s pattern-matched to what expertise sounds like, not because there’s verified knowledge underneath it. We read it and the part of our brain that evaluates credibility responds, because that signal has been reliable our entire lives. By the time doubt forms, we’ve already accepted the output. There’s more on why this happens and why it’s so hard to correct for here.

This is not a reason to stop using AI tools. It’s a reason to be precise about what you’re asking them to do, and honest about what they’re actually doing when they do it.

What this means if you’ve vibe-coded something

If you used Cursor, Lovable, Bolt, or any AI tool to build your app, and you’ve been using the same tools to fix problems as they come up, you have probably experienced this without having the language for it. You describe a bug, the AI fixes it, and a week later something adjacent breaks in a way that seems unrelated but isn’t. The AI fixed what it could see. It skimmed past the connected piece it didn’t expect to be relevant.

Over time, this produces a codebase where problems don’t get fixed so much as redistributed. The symptom moves. The underlying issue stays.

A human reading the code, actually reading it, brings something the AI structurally cannot: exhaustive attention. The ability to notice the thing in the quiet middle of the file that doesn’t match any pattern worth weighting, precisely because it doesn’t fit. The thing that’s wrong in a boring, unremarkable way.

That’s not intelligence. It’s method. And for certain jobs, method is what matters.

Find and replace is forty years old and I use it constantly. Not because I think it’s smarter than AI. Because I know exactly what it will and won’t do, and I choose my tools accordingly.

Knowing which tool fits which job is most of what experience actually is.

MV Studio provides technical support and maintenance retainers for founders who built fast with AI tools and need a human in the loop to keep things running properly. Start with a conversation.