Back when I worked in appsec, I wrote the same tool twice for two different companies. Both times it was a layer on top of git hosting (think GitHub, GitLab, Bitbucket). The second company's version was named "Git Stitches", because "Snitches Git Stitches".

Both tools cost real engineering time but were invaluable for a small appsec team. We collected developer emails from git commits so we could introduce ourselves with a quick "if you see something, say something". We grepped for patterns across commits: "it looks like you're using md5, do you need help with that" as my friend Ash used to say in his best Clippy voice. We saw what repos got created, which were active, which were dead. We could also grep all the code in one place... You find a pattern of vulnerable code during an audit and you could expand that finding to all the codebases... Pretty powerful, especially at the time.

That was ten years ago. That was extremely helpful but it took a fair bit of time to develop (especially since during the development of the first tool, a week in, my Ruby code created a directory named ~ and I decided a bit too quickly to delete it: rm -rf ~ ...).

AI changed the math. The cost of building a similar tool today is basically zero. Vibe code it, run it on localhost or lock it behind Tailscale, add mTLS if you're paranoid. A few hours of human in the loop. You can even have an LLM inspecting commits and PRs instead of just grep, your version could be 10x more powerful than what we had.

Were those tools perfect? No. Were they the same quality as a commercial product? Also no (though plenty of commercial products are terrible). Did they bring value? A huge amount. They were useful, and made the appsec team look like we knew what we were doing. The developers thought we were part of the cool kids. We could also build stuff.

Recently, I had Claude write a CVE triage tool I now use for content curation. I SSHed into the box, installed Claude and wrote prompts. I have never read a line of the code and I have never deployed the application. I know that it is written in Ruby, that's about it. Claude did all of the work and is still doing it. Are there mistakes? Yes. Is it perfect? No. Is it saving me at least 20 to 40 hours a week? Yes.

Chesterton supposedly said "Anything worth doing is worth doing badly". Coding agents made "doing things badly" free. Once the bad version proves useful you can pay a human to rewrite a good one if needed.

This is the real shift: experimentation is free. You barely write code. You barely deploy. You barely maintain. At least until the thing proves useful. Spin up a server, run Claude in tmux, let it build, deploy, and iterate. Walk away. Come back tomorrow. Refine, improve...

Once you have the tool running and are using it regularly, you end up in one of three places. The tool is good enough and you keep using it. The tool isn't good enough but now you understand the problem deeply and you can buy a real product knowing exactly what you need. Or the problem turns out not to be worth solving.

All three are wins. The middle one matters most. Most teams contact vendors before they understand their own problem. They get pitched, they buy, they regret. If you've prototyped first, you know what questions to ask and what answers are bullshit.

The hard part of a real product isn't the prototype. It's the last 20% that makes 80% of the work (thanks Pareto): removing humans from the loop, making it universal, making it reliable, making decisions reproducible across every environment that isn't yours. That's where vendors earn their keep. Babysitting your own tool for your own use case is easy. Selling a tool that works in someone else's environment without you watching it is hard.

So before you call a vendor, vibe code something. It will not be perfect. It will most likely bring value. It will definitely teach you what to ask.