Software Growth

Vibe coding

Vibe coding is building software by prompting an AI and accepting its code without reading it. What it changes for SaaS founders, what it doesn't, and the risks.

Vibe coding is building software by describing what you want to an AI model and accepting the code it writes without reading it. The one-line rule: if nobody reviews the code, it's vibe coding; if you review it, test it and can explain it, it's AI-assisted engineering.

For SaaS founders, vibe coding changes one thing a lot: writing software is now fast and cheap, for you, your competitors and your customers. It changes very little about what makes a SaaS business last, which is getting found, being trusted and keeping the product running for years. This guide covers where the term comes from, what it changes, what it doesn't, the risks, and a worked example of when vibe coding a tool actually saves money.

Where the term comes from

Andrej Karpathy, a co-founder of OpenAI and former head of AI at Tesla, coined the term in a post on X on February 2, 2025. He described talking to an AI coding tool by voice, clicking "Accept All" on every change, pasting error messages back in without comment, and letting the code grow "beyond my usual comprehension." He was clear about where it belonged: "It's not too bad for throwaway weekend projects."

…forget that the code even exists.

Andrej Karpathy / Post on X (February 2, 2025)

The term spread fast. Collins Dictionary named vibe coding its Word of the Year for 2025. As it spread, people started using it for any code written with AI help. Programmer Simon Willison pushed back within weeks and gave the definition this guide uses:

Building software with an LLM without reviewing the code it writes.

Simon Willison / Not all AI-assisted programming is vibe coding (March 19, 2025)

Willison's test for production code is that he won't commit anything he couldn't explain to someone else. Karpathy has since drawn the same line. In an April 2026 talk at Sequoia's AI Ascent, he described "agentic engineering" as the more serious discipline taking shape on top of vibe coding.

Vibe coding, AI-assisted engineering and no-code

  • Vibe coding: you describe, the AI writes, you run it and see if it works. Nobody reads the code.
  • AI-assisted (or agentic) engineering: AI agents write most of the code, and a person reviews, tests and understands it before it ships.
  • No-code: you build with a visual tool's ready-made blocks. You never see code, but the platform's vendor maintains it for you. With vibe coding there is real code, and nobody is maintaining it unless you do.
A two-by-two grid. The horizontal axis is how much of the code a person reads, from none to all of it. The vertical axis is what breaks if it's wrong, from only you to customers. Bottom left, vibe code it: prototypes, demos, personal tools. Top left, danger zone: paying customers' data or money with nobody reading the code. Top right, highlighted, AI-assisted engineering: agents write it, you review and test it. An arrow labeled before you charge for it points from the danger zone to AI-assisted engineering.
Adapted from Andrej Karpathy (February 2025) and Simon Willison (March 2025). Schematic.

The decision rule: match how much of the code you read to what breaks if it's wrong. Vibe code prototypes, demos, internal experiments and personal tools freely. Before anything touches paying customers, their data or their money, move it to the top right.

What vibe coding changes for SaaS founders

Building gets cheap

A minimum viable product that used to take a quarter can now take days, so you can test more ideas before committing to one. Indie hacker Pieter Levels put it this way on October 2, 2026: he can now "build things faster than I get new ideas." Jon Yongfook, founder of Bannerbear, says features that took him a week in 2022 now take an afternoon.

Competing on features gets harder

The same speed is available to every competitor. In his September 2026 essay How to Pivot Your SaaS Company in the Age of AI, Yongfook calls competing on features "dead": a competitor's claim of "10x more features" can be invalidated by a motivated developer in days.

Rob Walling and Einar Vollset make the same point in episode 855 of Startups for the Rest of Us (October 20, 2026), where "your customer builds it" is the first of ten ways AI attacks a SaaS business. Walling's warning for founders with complex products: if customers only use five of your hundred features, they only need to vibe code those five.

Some customers build instead of buying

Levels is the extreme case. On September 9, 2026 he listed the services he had replaced with his own vibe-coded versions, from image resizing to error monitoring, for about $25,000 a month in savings. On October 11 he said he had cancelled almost all of his business subscriptions and was moving on to personal ones, predicting "a tidal wave of cancellations once people find out how much money they can save."

Walling, in episode 842 (July 21, 2026), argues most businesses won't follow. A dentist or a gym doesn't want to host, secure, back up and maintain its own software to save $5,000 to $20,000 a year. He expects the damage to land on specific categories: cheap consumer and prosumer apps, and simple single-feature utilities. If your micro-SaaS is one feature behind a login, he thinks you're exposed.

What vibe coding doesn't replace

Paired bars comparing effort before AI coding agents with effort now. Under got fast: prototype or MVP, feature parity with a competitor, internal tools and admin screens, and single-feature utilities all shrink to a small fraction of their former effort. Under still slow, still your job: getting found, earning trust with data and money, running it for years, and security reviews and compliance barely move.
Adapted from Rob Walling (episode 842, July 2026), Jon Yongfook (September 2026) and Pieter Levels (September to October 2026). Schematic: relative effort, not measured.

Every trusted voice on this topic lands in the same place: the code was always the cheap part. What protects a SaaS business is the moat around the code, and vibe coding doesn't build any of it.

AI writes the code. It does not write your distribution.

Rob Walling / Episode 842: What is the Future of SaaS in an AI World? (July 21, 2026)

  • Distribution. Walling's point is that apps could always be cloned. Getting people to know you exist, switch to you and stay is the hard part. Yongfook goes further: if you have an audience, it's now worth more than your codebase.
  • Trust. In episode 855, Walling and Vollset ask who would switch payroll to a vibe-coded clone to save $49 a month, or trust a vibe-coded e-signature tool with a million-dollar contract. When the cost of being wrong is high, customers pay for a vendor they trust.
  • Operations. Yongfook's example is transactional email: "the code was never the hard part." Deliverability, abuse and being on call are. Levels found the same thing with web scraping. On September 4, 2026 he gave up and kept paying ScrapingBee, because his scraper kept getting blocked. Five days later, with help from other developers and better proxies, he got his own version to work. Walling summed it up in episode 855 (in the segment from 40:47): web scraping "isn't hard to build, but keeping it working is brutal."

The risks

Security

Code nobody has read can leak data, expose keys or run up bills. In Veracode's 2025 GenAI Code Security Report (July 30, 2025), 45% of code samples from more than 100 AI models failed security tests, and newer, larger models were no better at writing secure code than older ones. Willison's beginner rules still apply: watch for secrets like API keys, be careful with private data, and set billing limits on any usage-priced API.

Even heavy users treat this as ongoing work. On October 25, 2026, Levels described spending a full day having an AI agent security-audit every server he runs, and suggested founders now need a monthly "security week."

Maintainability

Karpathy's own description includes the problem: the code grows beyond his comprehension, and some bugs he works around rather than fixes. That is fine for a weekend project. In a product you'll run for years, it becomes technical debt that nobody on the team understands, and every future change gets riskier.

Compliance and accountability

If you handle health records, payments, payroll or signatures, "the AI wrote it" is not an answer a regulator or a customer will accept. Vollset's example from episode 855: nobody wants to take on a HIPAA compliance risk to save $500 a month.

Worked example: should you vibe code a replacement?

This example is fictional. A founder running a SaaS at $15,000 MRR pays $400 a month for an image-resizing API. With a coding agent she could build her own in about 8 hours and host it for $20 a month. She expects about 2 hours a month of upkeep: dependency updates, a broken edge case, a check after each outage. She values her time at $100 an hour.

Line chart of cumulative cost over 12 months. Keep paying rises steadily to $4,800. Building, counting the founder's time, starts at $800 and rises to $3,440, crossing below keep paying after about 4.4 months. Building, counting only cash, rises to $240, which makes the savings look like $4,560.
Fictional example. Assumes 8 hours to build, 2 hours a month to maintain, time valued at $100 an hour and $20 a month of hosting.
  • Keep paying: $400 × 12 = $4,800 a year.
  • Build, cash only: $20 × 12 = $240 a year. On paper she saves $4,800 − $240 = $4,560.
  • Build, counting her time: 8 hours × $100 = $800 to build, plus ($20 + 2 hours × $100) × 12 = $2,640 to run. Total $3,440, so the real saving is $4,800 − $3,440 = $1,360 a year.
  • Break-even: $400 × months = $800 + $220 × months, so about 4.4 months.

The real saving is $1,360 for 32 hours of her time. Now apply the test Walling uses in episode 842: growing by $1,000 of MRR adds $12,000 of ARR, which is $60,000 of enterprise value at a 5x ARR multiple. If the same 32 hours spent on marketing added even $300 of MRR, that's $3,600 of ARR and $18,000 of value at 5x, far more than $1,360. Building to save money only wins when the bill is large compared with the upkeep. Change the bill to $2,500 a month and the same build saves $30,000 − $3,440 = $26,560 a year.

Walling's decision rule: there are only two good reasons to build your own version of a tool. Either it's really expensive and you can cut the cost by 90% or more, or no product on the market does what you need.

What changed in September and October 2026

How to use vibe coding as a SaaS founder

  • Prototype freely. Use it to test ideas, build demos for customer interviews and make internal tools only you will use.
  • Review before customers touch it. Anything that handles customer data, payments or logins gets read, tested and understood by someone.
  • Keep secrets out. Don't paste API keys or customer data into prompts, and set spending limits on usage-priced services.
  • Run a security pass. Ask an agent to audit the code and server, then fix what it finds, and repeat it regularly.
  • Spend the time you saved on distribution. If code is cheap for everyone, the advantage goes to the founder who uses the saved time to reach customers.

Common mistakes

  • Calling all AI-assisted coding "vibe coding," then either shipping unreviewed code or dismissing tools that would help.
  • Shipping a vibe-coded prototype straight to paying customers with no review.
  • Counting only the subscription you cancel and not the hours you'll spend maintaining the replacement.
  • Treating your feature list as your moat when a competitor or customer can rebuild it in days.
  • Assuming the new vibe-coded competitors will last. Walling's view in episode 842 is that more apps getting built doesn't mean more companies getting built.

Sources

Back to the SaaS glossary