Search First, Write Later: The Prompt That Saves You Hours

What “search first, write later” actually means

You need to drive a nail. Option one: you walk into the garage, grab a hammer — it’s right there, tried and true, comfortable, your granddad swung it too. Option two: you forge your own hammer from a raw chunk of iron, because “hey, I made it myself, that’s more fun.”

Sounds like a joke. Now the twist: option two is exactly what the agent picks by default — until you tell it otherwise. Ask it to “build a form that validates email” and it’ll cheerfully cook up its own little chunk of validation code. Even though the world has long had ready-made tools, polished by thousands of people, that do the same thing — better, more reliably, and for free.

The “search first, write later” habit is simple. You make the agent take a look around first: is there already something ready-made? And only if there genuinely isn’t — then it gets to start forging.

Why a ready-made solution beats hand-written code

You’re a vibecoder. You don’t write the code by hand — but you direct the one who does. And if you don’t steer the agent, it’ll fall back on habit and start reinventing everything from scratch. How does that hit you personally?

• Slower. Building your own from scratch takes hours. Plugging in something ready-made takes minutes.
• Pricier. The agent burns tokens A token is a small chunk of text the model uses to read and write. The more code it invents, the more tokens it spends — which means more of your money. (your money) inventing something that was already sitting on the shelf.
• Buggier. Fresh hand-written code is almost always half-baked. Ready-made stuff has already been battle-tested by millions of users.
• Scarier to fix. When your own code breaks, you untangle it from scratch. A popular library has docs and forums where someone solved your exact problem three years ago.

The difference between “the agent built me a site that fell apart in a week” and “the agent assembled my site out of solid building blocks” often comes down to a single habit: search first, write later.

Where an AI agent looks for ready-made code: four shelves

When you tell the agent to “search first,” it doesn’t rush off to code. It walks past four “ready-made shelves” — roughly in this order, from closest to farthest.

Sodi — our mascot and resident vibecoding companion — is a walking demo of the “search first” principle. In the sketch further down, instead of rushing straight to “write code,” Sodi grabs a basket and methodically works through all four shelves — “my project,” libraries, tools, the internet — and only then heads for the desk. That’s exactly how it should go: search first, code later.

1. Your own project

Start with the nearest thing. What if it’s already written somewhere in your own project? A classic case: you ask for a “submit button,” and a button just like it is already living in a neighboring file. The agent finds it and reuses it — instead of churning out a second copy of the exact same thing.

2. Ready-made libraries and packages

Next — the big wide world. There are massive warehouses of other people’s code: libraries A package (library) is a ready-made chunk of code that someone wrote, tested, and published so others can just grab it and use it. You add it with a single command. you can install with one command. Need data validation, sending emails, a nice little calendar — chances are someone already built it and put it out there.

3. Tools, extensions, and MCP

Sometimes the thing you need isn’t a library but a whole ready-made tool — like a pluggable MCP MCP is a way to hand the agent a ready-made external tool: access to a database, to email, to a calendar, and so on. No need to write any of it by hand — you just plug it in. or skill. In that case the agent has nothing to code at all — it just grabs the ready-made thing and uses it.

4. Open-source code and examples online

And only if nothing else pans out does the agent check GitHub for a similar template or example. That way, at the very least, it isn’t starting from a blank page — it’s building on someone else’s experience.

When to grab ready-made, and when to write your own

Finding something ready-made is only half the battle. Next you have to figure out: is it actually worth using? Here’s how the agent (and you alongside it) makes the call.

Example: a signup form with email validation

You tell the agent: “build a newsletter signup form — and make it check that the email is real.”

Without the right prompt: the agent cheerfully cooks up its own email check. It writes some clever formula that looks like it works but actually lets broken addresses through and blocks valid ones. A week later you find out half your people can’t sign up — and off you go to the agent to fix the thing it broke in the first place.

Now here’s how a vibecoder who gets it does it. They add one instruction to the request — “search first”:

I need a newsletter signup form with email validation.
Before you write any code, do this:

Check whether suitable code already exists in my project — maybe a similar form or validation is already there.
Look for popular, ready-made libraries for email validation and for forms. Pick the ones people actually use and that were updated recently.
Show me 2-3 options as a short list: what you found, why each is good, which one you’d choose, and why.
Only after that, plug in the chosen one. Write your own code only where nothing ready-made truly exists.

Common beginner mistakes when searching for solutions

• You ask “write X” instead of “find a ready-made X.” Without the word “find,” the agent writes from scratch by default. Add the instruction to search — every single time.
• You grab the first thing you see. Found a library? Check whether it’s alive and whether people actually use it. Abandoned code will come back to bite you at exactly the moment you have no time for it.
• You drag in a behemoth for a trifle. You don’t need a giant library for one button. Match the size to the task.
• You don’t ask what the agent picked. Ask it to show the options as a list — and you’ll see what your project stands on, with no nasty surprises.
• You reinvent what’s already in your own project. The most common and most painful case — duplicating something that’s sitting quietly in a neighboring file.