We cleaned up two years of vibe-coded tools. Seven API keys were still live.

Everything worked well enough that nobody looked

Building is the cheap part now. An idea on Tuesday is a working script by Tuesday night. So you build a lot of them, and each one leaves something behind: a folder, a Python environment, a copied .env file, sometimes a job that runs every morning.

None of it breaks loudly. A tool you stopped using does not send an error. It just sits there, holding its dependencies and its passwords, until someone goes looking. In a company that someone is IT, or a code reviewer, or the person offboarding the project. Building alone, there is no one. So for two years, nobody looked.

Duplicates all the way down

The pattern was the same every time. We would build a tool, then build a better one, and never delete the first. There were three meeting summarizers, each replaced by the next, and all of them replaced by the meeting recorder we actually use. There were four separate LinkedIn tools. There were cloned starter templates from early 2025 that never went anywhere, still carrying hundreds of megabytes of packages each.

The space was mostly caches and environments, not code. The Python package cache alone was 14.2GB. The JavaScript package cache was 8.3GB. Every project had its own copy of its dependencies, and a lot of those projects were dead.

The biggest single example was our own website. It had 16 pages, all text. It ran on Next.js and React, roughly 385 packages, with 18 known vulnerabilities including one critical. We replaced it with plain HTML and a 200 line Python build script. The homepage went from 67KB to 34KB and the site ships no JavaScript framework at all. The change removed 11,700 lines and added 3,800.

An AI will happily build you a Next.js site, because that is what a lot of sites are built with. It will not ask whether a site with 16 text pages needs one.

The credentials were the scary part

The fastest way to start a new project is to copy the .env file from the last one. So every project carried the keys of every project before it. One Google API key was sitting in three of our current projects, and the code in none of them used it.

We tested every key we found with a harmless, read-only call before deleting anything. Most were already dead. Seven were still live: OpenAI, Google, Pinecone and Firecrawl keys in folders we had not opened in over a year. Beyond the keys there were Salesforce usernames, passwords and security tokens stored as plain text in three old script folders, OAuth secrets for old LinkedIn apps, and a file literally named "pw".

The lesson here is simple and easy to miss. Deleting the file does not revoke the key. Each one had to be found in its own dashboard and turned off by hand. One Google key had been created through AI Studio, which had since been switched off in our Workspace admin. To find the Cloud project that owned it, we called an API the project did not have enabled and read the project number out of the error.

Things that fail quietly

A daily newsletter digest was set up on September 1 to run at 7am. It was meant to summarize the previous day's newsletters and email the result. It failed every morning for eight weeks. A tool it depended on had moved to a new folder, so the job could not start, and it never got far enough to write a log. Even fixed, it would have had nothing to do: no mail rule ever tagged anything as a newsletter. It never sent a single email, and nothing told us.

A calendar sync had stopped because its log folder was deleted along with a different project we retired in September. The meeting recorder broke halfway through the cleanup itself, because it read its local model's server address out of another tool's config file, and we had just uninstalled that tool. Nobody would have guessed that dependency existed. It was not written down anywhere.

The largest tool we retired this year was a lead outreach app: about 5,000 lines with a command line, a terminal UI, a web API, an MCP server and a Mac app. Its AI drafting path turned out to be dead code. The emails it actually sent came from a fixed template. Today the same job is two commands and a plain-language prompt.

What we do now

Code in one place, client files in another. Client spreadsheets and CRM exports had ended up inside code folders, next to the scripts that produced them. They now live in client folders, and code lives in one projects folder.

Check what it does before keeping or deleting it. Reading the newsletter digest took five minutes and settled the question. Without it, the safe-feeling choice is to keep everything, which is how we got here.

Test keys, then revoke them. A key found in an old folder is a key someone else might have a copy of, in a backup or a zip file. Turn it off at the source.

Fewer dependencies. We removed Node from the laptop entirely. Every package you install is code that can run on a machine holding your SSH keys and client tokens. The fewer you need, the fewer you have to trust.

Ask whether you would build it again today. For the outreach app the answer was no. A prompt does the job now.

The takeaway

The same tools that made the mess made the cleanup fast. An agent can search every folder, test every key and read every scheduled job in an afternoon. What it could not do was decide which client a folder belonged to, or whether a key was still in use somewhere it could not see. Those calls took most of the four and a half hours.

Vibe coding makes building cheap. It does nothing about owning what you built. Every tool is a small piece of software someone now has to maintain, secure and eventually retire. Inside a company that cost is spread across IT and code review. On your own, or on a team where reps and RevOps are building their own tools, it lands on whoever built it, and it usually waits until something breaks.

If your team is building with AI, the useful question is not what to build next. It is who owns what is already there.