Those of us who have been writing code since at least the early 2000s are familiar with the stereotype of the “cowboy coder.” The term is sort of a double insult — it’s an insult to the individual developer, and it’s also unhelpfully gendered. While I’ve never heard anyone called a cowgirl coder, I have met all types of people who fit the pattern. This is a software developer whose primary development style is improvisational. Cowboy code is characterized by anti-patterns, pasted snippets from the web or from other projects, and a general state of confusion and disarray.
Put another way, cowboys and cowgirls were vibe coding before it was cool. Having enjoyed a long enough career to see the consequences of this style of software development — both in my own work, work I’ve inherited, and in projects I have championed as a business leader and consultant — I worry about the long-term costs of the current wave of vibes.
What’s vibe coding? Essentially, it’s coaching an LLM or AI agent like Claude Code or Copilot through a software development task or project and generally accepting its output at face value. In some cases, the work of the agent would be well beyond the skill or comprehension of the human driver.
New Old Web is a blog published by Alley and Lede. We're researchers, strategists, designers, and developers who want to make the internet a fun place to live and work.
At the NPA Summit a couple weeks ago, a product leader at Airtable, Anthony Maggio, gave the keynote on the first day. It was largely about the benefits of artificial intelligence in product development organizations, and while I didn’t agree with the broad applicability of his ideas to news gathering, his underlying thesis of product development seemed sound to me. Vibe coding is for prototyping, not production.
This should strike fear into the heart of any veteran software developer, and product managers should take heed, because an overzealous product manager can make a cowboy out of the most pure-hearted software developer. As a young developer, how many times did I spike a feature, build a prototype, or just prove that something could be done with every intention of a production-quality refactoring, only to have a business stakeholder insist it be shipped right away? Countless times! Were some of these instances entirely my fault? Absolutely. It feels good to have your work validated.
What are the consequences of shipping prototypes to production? Day one technical debt, lack of sufficient testing, lack of user feedback, organizational buy-in, and potential for security and performance issues. There are nuanced cases where a few of these drawbacks could be acceptable, but proceed with caution!
Are there cases where the vibe-coded thing is good enough to ship to production? Not by reasonable definitions of vibe-coding and production. If a highly competent engineer used AI to help build a production-hardened application, that’s not vibe-coding. If your production environment is just a place for investors to get excited about your product, it’s a glorified demo site, not production, and most definitely not pre-production. If you’ve vibe-coded something that’s just to make life easier for you or your team, great. No objection.
For those products that do have an audience, the best thing to do with these vibes is to funnel them into user testing. It’s never been easier to get a working product in front of real user, and that’s a huge advantage. But the siren song of the working demo is hard to resist, and it will test the most purehearted product managers in a far greater and more consequential way, because the cowboys can now produce an astonishing volume of code. We’ve traded horses for jetpacks.
There’s a seductive line of thinking that none of this matters, that the AI will be soon be good enough to fix all the mistakes it made in the first place. It’s just a new verse to an old cowboy song: We can afford to refactor it once it’s gotten traction.
Nah, let’s just build it right in the first place.
