Your agent won't tell you it already exists

Before I let an agent write a line of a new build, I make it do something that feels like a waste of clock time: go find out whether the thing I am about to ask for already exists. Not the app. The primitive underneath it. The queue, the diffing, the retry logic, the date math, whatever the real core turns out to be. Most of the time it does exist, as a boring standard library or a format someone nailed down a decade ago, and the ten minutes it took to find that out are the cheapest ten minutes in the whole build.

If you are asking whether you just reinvented the wheel with AI, the honest answer is that you probably did, and it is not exactly your fault, because a vibe coded build has no built-in moment where anyone checks. The fix is a research pass before you generate: name the problem in plain terms, survey what already solves it, and only then delegate the build. An agent will build whatever you describe, fast and sure of itself, and it will never stop to tell you the field solved this years ago.

why does vibe coding make this so easy to do

The instant result is the trap. You describe a thing, the agent generates it from first principles, it runs, and the small hit of it working carries you straight to the next feature. Nowhere in that loop is the one question that would have saved the week: does this already exist. The agent has no incentive to raise it. It is not withholding anything; it simply generates against your description and has no model of the wider field it is quietly competing with.

The public version of this made the rounds recently. A developer vibe coded an entire language and compiler to do proof-checking, and the discussion around it pointed out, not unkindly, that formal verification tools already do exactly that and have for years. The build ran. It was also a decades-behind reinvention of a solved field. That is the whole shape of the vibe coding trap: the speed that makes it great is the same speed that carries you past the check. Working is not the same as right, and an agent measures working.

how do I stop rebuilding something that already exists

I build spec-first, and the spec has a front end most people skip. Before the spec says what to build, it asks what already builds it. This is the same discipline I use inside a build, where the architect reads the existing source before writing the next piece, pointed one step earlier: read the field before you write the first piece.

Concretely, I make the agent state the problem as a category, not as my app. Not "a thing that runs my tasks in order" but "this is a job queue." Then I have it list the standard solutions to that category and say why each one does or does not fit. Only then do I decide whether I am building something or wiring something that exists. The way I build now is six delegations, zero rollbacks, and on most of those builds one delegation produces nothing but that survey. It ships no code. It is still the delegation that earns its keep the most, because it is the one that turns "build me an X" into "actually, a standard Y already does this, wire it." AI orchestration without that step is just fast reinvention with a metal layer nowhere in sight.

what the research pass actually catches

The failure mode it catches is confusing "it runs" with "it is the right design." You get a working artifact fast, and you only find the ten-times simpler standard approach after you have built and started maintaining the wrong one. The expensive part was never the build. It is the maintenance tail on a custom thing that a maintained standard would have carried for you, for free, including the edge cases you have not hit yet and the security fixes you will never hear about. A research pass catches the mistake at the cheapest possible moment, before the code exists, the same place spec-first discipline catches every other kind of disagreement.

This is the front door of the same discipline I wrote about in keeping a vibe coded build readable months later. There, the spec is the artifact you re-read later, so the build stays explainable. Here, the spec is the thing that stops you building the wrong artifact in the first place. Same metal layer, SpecMesh, two different walls it keeps you off of. If you are trying to work out when you need a spec and not just a prompt, this is one of the clearest cases: the prompt gets you a build, the spec gets you the right build.

If you are formalizing how you build with AI and want to compare notes on where the research pass fits before generation, work with VibeKoded. Send me what you are about to build, and I can help you figure out whether it is a build or a wiring job before you spend the week on the wrong one.

questions that keep coming up

How do I run the survey if I am a newcomer and do not know the standard tools? Make the agent do it out loud. Ask it to name the category the problem belongs to, then ask it for the established tools and formats in that category and what each is good and bad at. Then sanity check the list against a quick search. You do not need to already know the field; you need to force the question before the code, not after.

Isn't researching first just slower? It is minutes against a maintenance tail measured in months. The survey is one cheap delegation that either confirms you are building something genuinely new or hands you a solved tool to wire in. Both outcomes are faster than discovering the standard approach after you have shipped and started maintaining the reinvention.

The reason I run that boring survey delegation is not caution for its own sake. It is that a vibe coder moving fast is exactly the person most likely to build a beautiful, working, redundant thing, because the tools make building cheaper than checking. Move the check in front of the build, where it costs ten minutes, and the trap mostly stops closing on you.