I Taught My Grandma To Vibe Code (Here’s What Happened)

My grandma managed inventory spreadsheets for a textile company for 40 years. She calculates compound discounts in her head faster than most people can with calculators, but has zero coding experience. 

When I suggested building a garden tracking app together using AI, her skepticism was almost instant.

Two hours in, she had a working web application until we asked for one more thing, and the app broke. This is an all-too-common story of vibe coding. 

Now, I have a framework for understanding what vibe coding actually delivers versus what it promises, so you can look beyond the marketing hype and make actual use of the product. 

First, What Is Vibe Coding?

Vibe coding is building software by describing what you want in plain English and letting AI write the code for you. 

Former Tesla AI director and OpenAI co-founder Andrej Karpathy coined the term in February 2025 when he tweeted: “There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” 

The post exploded with over 5 million views, capturing a development approach that was already spreading through the tech community. 

Instead of learning programming languages and wrestling with syntax, you just tell an AI what you want to build. The AI generates the code. You become a product manager rather than a programmer, focused on what the app should do instead of how to make it work.

Why Does Vibe Coding Matter Now?

87% of companies face talent shortages or expect to within the next few years, according to McKinsey. 

AI coding tools like Bolt.new, Lovable, Replit Agent, and Cursor promise to solve this problem by improving productivity for existing developers and allowing non-devs to test their ideas quickly.

The numbers back up the hype:

• In March 2025, Y Combinator revealed that 25% of their Winter 2025 batch had 95% of their codebases generated by AI. 
• In April 2025, Microsoft CEO Satya Nadella revealed that 20–30% of the codebase was written by AI.
• A quarter of startups in YC’s current cohort have codebases that are almost entirely AI-generated. 
• Google CEO Sundar Pichai reported similar figures, stating over 25% of Google’s code is AI-generated.

We’ve gone from basic autocomplete to writing entire applications with minimal human input. 

But the same features that make vibe coding accessible, like natural language input, autonomous code generation, and automatic complexity handling, create serious problems when your app needs to grow beyond that first version. 

What Can You Actually Build with Vibe Coding?

When you can actually build with vibe coding depends on three things:

• How complex your app needs to be
• Whether you can spot bad code and security holes
• If you know when to stop adding features

If your app requirements are simple, and you can identify technical gaps and resist unnecessary feature additions, vibe coding can help you deliver fast functional results.

However, as complexity grows or if you need to build production-grade apps, professional review and architectural planning become non-negotiable.

My grandmother’s experience building a garden tracking app showed exactly where these limits are.

What Happened in Hour One? Simple Instructions Worked

There are at least a dozen AI vibe coding platforms like Bolt, Lovable, OpenAI Code, Claude Code, Google Opal, etc. 

We started with the OpenAI Codex extension in VS Code because I already had a subscription, but I’d recommend starting with Bolt.new, Lovable, or Vercel for a more visual vibe-coding experience. 

Our first prompt: “Build a garden tracking app where I can record what I planted, when I planted it, and how much I harvested. Include a way to see which plants performed best each season.”

This prompt worked because it contained three critical elements:

• Clear data structure (plant name, planting date, harvest amount, season)
• Defined output (performance comparison by season)
• Specific use case context (personal garden tracking)

Within a few minutes, Codex generated a complete application. It had an SQLite database with tables for plants, plantings, and harvests, REST API endpoints for CRUD operations, a Python frontend with data tables and input forms, and basic styling with CSS.

It even had some demo data by default.

The web app looked good. That’s vibe coding’s superpower and its greatest danger. But before I jump into that, let me explain what’s actually happening behind Codex’s thinking. I played around with the app, figured out what we had and what else we needed. 

What Happened Behind the Interface

The generated code made architectural decisions for a single-user application. The database schema could handle new entries easily. The API followed RESTful conventions. The frontend components were separated logically. 

However, I noticed that it did not make critical security considerations by default. There was no input validation, no authentication layer, no rate limiting, no consideration of SQL injection vulnerabilities, and no encryption.

The AI agent’s architecture assumed a trusted single user in a controlled environment.

Considering this was a project for my grandma and no one else, these omissions are manageable risks. However, for anyone considering vibe coding to build a multi-user web application, these are critical security risks that simply can’t be ignored. 

I commonly see discussions about this on Reddit or PostStatus: developers successfully iterate on AI-generated code because they identify these gaps and implement proper security layers. Non-technical users see a working app and assume production-readiness.

What Happened in Hour Two? Feature Creep Became Obvious

The app worked as intended, and this breakthrough moment helped her build confidence. My grandmother started thinking about improvements. This is where vibe coding’s limitations become apparent.

We tried a feature request: “Add the ability to upload photos of each plant so I can see what they looked like at different growth stages.”

This seemingly simple request triggered a cascade of architectural complexity.

Database schema and app module changes required:

• New photos table with columns: id, plant_id (foreign key), photo_url, upload_date, growth_stage
• Relationship definition between plants and photos (one-to-many)
• Migration strategy for existing data

Backend modifications needed:

• File upload endpoint with multipart form handling
• File storage solution (local filesystem vs. cloud storage)
• New API endpoints for photo CRUD operations
• Update existing plant endpoints to include photo data

Frontend changes required:

• File input component with drag-and-drop
• Image preview functionality
• Photo gallery display for each plant
• Update existing plant cards to show thumbnails
• Loading states for upload progress

OpenAI Codex attempted to implement everything simultaneously. The latest model GPT5-Codex-High was able to make this work within ~5 minutes from entering the prompt. 

The problem is that it created buggy and insecure code. Here’s what broke:

• The original plants table structure changed
• Frontend components that referenced the old schema stopped working
• CSS conflicts between new photo components and existing UI (as visible in the screenshot) emerged

And then there was the overengineering problem: Codex generated a complex system with unnecessary image processing and data taken for each photo, etc. 

Each fix attempt introduced new problems. Update the database schema, break the API. Fix the API, break the frontend. Resolve frontend issues, discover new backend bugs. The codebase that worked perfectly with 200 lines of code now sprawled across 1,500 lines with interconnected dependencies.

The Non-Extensible Architecture Trap

The app’s architecture was optimized for only what we asked for in the first hour. With vibe coding, you have to be very specific, and that’s the difficult part for non-developers.

You wouldn’t know what extensible architecture means if the AI implemented it.

If you have a simple app ready and then need to extend it, a non-extensible architecture would mean rewriting the code from scratch for the AI. 

Architectural assumptions from the first hour:

• Single table design (reasonable for simple data)
• Direct API-to-database queries (fast for read-heavy operations)
• Inline component definitions (acceptable for small UIs)
• No separation between business logic and data access (fine for simple CRUD)

Why these assumptions became constraints:

• The single-table design prevented proper relational data modeling for photos
• Direct queries required complete rewrites when the schema changed
• Inline components meant changes cascaded through the entire codebase
• No business logic layer meant every feature touched the database directly

We were past the return point. Too much code existed to abandon. Each fix attempt consumed more tokens trying to salvage an architecture that couldn’t support the new requirements.

What Happened in Hour Three? Token Exhaustion and Barely Functional Code Emerged

After the photo upload feature worked, we attempted additional improvements.

• “Add categories for plant types (vegetables, herbs, flowers)”
• “Show planting recommendations based on season”
• “Let me mark plants as favorites”

Each request followed the same pattern: Codex attempted thorough implementation for some seemingly simple asks, introduced breaking changes, created overengineered solutions, and consumed thousands of tokens trying to fix resulting bugs.

The app works just fine, and my grandma was satisfied with the output. 

As a developer, though, I could clearly see we were on the last leg in terms of code. A few more features and the app would be a mess. 

via Imgflip

Why Is This Such a Common Problem?

Coding agents are just large language models “prompted” to output code. 

So they have all the problems that regular large language models have, including:

• Not being specific about what’s expected of them
• Making up random function calls (hallucinations)
• Writing complicated code for simplistic goals

Also, as chat history grows, coding agents hit their context window limits. 

• Original architecture decisions and their rationale
• Subsequent modifications and their interdependencies
• Current bugs and their root causes
• Desired functionality for new features

Each new prompt was interpreted in isolation without a full understanding of architectural history. The AI suggested solutions that made sense for individual features but created systemic conflicts when integrated with existing code.

This Reddit guide emphasizes: “When the chat gets very big, just open a new one. The AI context window is limited. If the chat is very big, it will forget everything earlier, forget any patterns and design, and start producing bad outputs.”

But opening a new chat meant losing all context about what existed. Providing that context consumed tokens. Even with “summarized” context, we’re still missing important details when it comes to code. 

We Faced the TEA App Problem at a Smaller Scale

The TEA app demonstrated this exact failure pattern at production scale. Launched in 2023 as a women’s safety platform, it rapidly scaled to 1.6 million users. 

Then, in July 2025, it failed catastrophically:

• The breach: Security researchers discovered an unsecured Firebase storage bucket containing 72,000 user images, including 13,000 verification selfies and government IDs. A second database exposed 1.1 million private messages.
• The technical failures: API keys hardcoded in source code, Firebase bucket publicly accessible without authentication, no runtime protections, and no security review layer. Experts linked these vulnerabilities to vibe coding practices, where feature velocity eclipsed security architecture.
• The outcome: An Anonymous 4chan poster discovered and shared download tools. Class-action lawsuits filed within 48 hours. The platform shut down. Average breach cost: $4.88 million.

TEA’s failure has the same pattern we experienced at such a tiny scale, which makes me wonder why people don’t verify AI-generated code. 

We had an initial implementation that worked well; however, feature additions complicated the architecture, security considerations were overlooked for new functionality, and systemic vulnerabilities were unknowingly left open for exploitation.

How To Vibe Code Without Experiencing the Same Problems We Did

If you’re not a developer, it’s impossible to avoid the problems entirely. However, there are ways to minimize problems. 

1. Start With Ruthless Feature Minimalism

Define the absolute minimum feature set before writing the first prompt, but always resist the temptation to add features during the initial development.

Effective scoping framework:

List all desired features

Identify the 3–5 features that validate your core hypothesis

Build only those features in version one

Ship, validate, and iterate

Do not give prompts like, ‘Build me this whole feature.’ The AI will hallucinate and produce terrible code. Break down any feature into at least 3–5 sequential requests.

If you can’t identify the minimum feature set, use the “Plan mode” or “Chat mode” available in most of the AI coding tools. 

This lets you tell the agent what you want in natural language and allows AI to figure out how to break the app into individual features or files. 

2. Commit to Git After Every Working Feature

For a non-developer, version control can sound complicated, but it’s a necessary addition. Git is a version control tool that creates restore points when feature additions break existing functionality. 

Git workflow for vibe coding:

Initialize the repository before the first prompt

Commit after the initial working version

Create a new branch for each feature addition

Commit frequently during feature development

Test thoroughly before merging to the main branch

You can tell the coding agent of your choice to do this for you if you’re not comfortable with Git commands. 

3. Design for Extension in Initial Prompts

Your first prompt defines the codebase. Simple prompts will only give you a working app until you start asking for new features. 

Instead, ask for an extensible architecture right from the beginning. 

• Ineffective initial prompt: “Build a garden tracking app where I can record what I planted and harvested.”
• Effective initial prompt: “Build a garden tracking app with an extensible database schema that can accommodate future features. Use a modular architecture where frontend components, API endpoints, and database access are separated. Include clear documentation of schema and API structure for future modifications.”

This does increase the token usage to start with. However, when you begin adding new features, the AI will not need to waste tokens refactoring the old code to accommodate requests. 

4. Choose Tools Based on Architectural Stability

• Bolt.new, Replit agent, and Lovable: Excellent for single-session prototypes and easy deployment. Poor for multi-session feature additions. Architecture becomes progressively more fragile with each modification.
• Claude/OpenAI/Gemini coding agents: Sometimes useful for complex coding, but can feel more complicated compared to the visual web-apps we’ve seen before.
• DreamHost Liftoff: Great as a WordPress foundation with proven extensibility patterns. WordPress architecture is designed for modification and plugin additions. This solves the non-extensible architecture problem by starting with a battle-tested extensible foundation. 

5. Implement Security From Hour One

Similar to extensibility, you want to integrate security right from the first prompt. So, along with asking for an extensible, modular architecture, you also want to add security-first components to the initial prompt.

Here’s an example of how I’d add security in the first prompt: “Build a garden tracking app with bcrypt password hashing, input validation on all fields, parameterized SQL queries to prevent injection attacks, rate limiting on all API endpoints, and secrets stored in environment variables never exposed to frontend code.”

If you’re building a client-facing app, here are a few things to keep in mind:

• Never trust client data—validate and sanitize server-side
• Keep secrets in environment variables
• Verify permissions for every action
• Use generic error messages—detailed logs for developers only
• Implement ownership checks to prevent unauthorized data access
• Protect APIs with rate limits

Understanding how generative AI works helps you recognize when AI makes security assumptions that create vulnerabilities.

6. Know When To Start Fresh vs. Continue

Recognize the signs that continuing will waste tokens.

Start fresh when:

• Token consumption exceeds 300k without working features
• Each bug fix introduces two new bugs
• Architectural modifications break multiple existing features
• Chat history exceeds 30 exchanges
• You cannot explain the current codebase architecture

Continue when:

• New features integrate cleanly with existing code
• Bug fixes resolve issues without side effects
• Token consumption stays within budgets
• Architecture remains comprehensible

When the AI gets it wrong and goes in the wrong way, returning, changing the prompt, and sending again would be much better than completing this shit code.

7. Review With AI Security Analysis

After building core functionality, copy the complete codebase to Gemini 2.5 Pro for comprehensive security analysis. I prefer this language model because of its large context window of two million tokens so you can move the entire code base into it. 

Security review prompt: “Act as a security expert. Analyze this complete codebase for vulnerabilities. Identify SQL injection risks, XSS vulnerabilities, authentication weaknesses, authorization flaws, credential exposure, and any OWASP Top 10 issues. Provide specific code locations and remediation recommendations.”

This approximates a professional security review at a fraction of the cost. 

It is insufficient for production deployment, but it identifies catastrophic flaws in prototypes before they reach users.

When Does Vibe Coding Make Business Sense?

You don’t have to discard vibe coding altogether just because it is unable to create complicated applications right now. Here are a few cases when I think a vibe-coded prototype or app actually makes sense.

• Rapid concept validation: Build prototypes in hours to test market interest. Average validation cost dropped from $15,000–$100,000+ to under $500. Use vibe coding to answer: “Do customers want this enough to use it?”
• Internal process automation: Provide tools for your team where you control access and accept higher risk tolerance because blast radius remains limited. Internal tools can iterate toward security rather than requiring security from day one.
• Pre-development specification: Understand requirements before hiring developers to reduce expensive miscommunication. Vibe-coded prototypes serve as interactive requirements documents.
• MVP for fundraising: Demonstrate functionality to investors while being transparent about technical maturity. Many startups use vibe-coded MVPs to secure seed funding, then rebuild properly with professional teams.

When Professional Development Becomes Non-Negotiable

Customer-facing applications processing any user data require a professional security review. The cost of incorrect security implementation exceeds any savings from vibe coding.

Some cases where you need professional review include: 

• Multi-user authentication
• Payment processing
• Personal information storage
• Public-facing deployment
• Situations involving compliance requirements (such as GDPR, CCPA, HIPAA)

Microsoft’s CEO revealed 30% of the company’s code is now AI-generated. Google reported similar figures. Both maintain extensive security review processes, automated testing, and human oversight. 

Production deployment requires similar safeguards regardless of code generation method.

Understanding whether AI will replace developers helps set realistic expectations about what you can safely build and deploy alone. Explore the best online resources to learn code to bridge the gap between vibe coding prototypes and production-ready systems.

FAQs About Vibe Coding

What is vibe coding, and how is it different from traditional programming?

Vibe coding is the process of building applications by describing requirements in plain English to an AI, which generates the code for you. Unlike traditional programming, which demands knowledge of programming languages, vibe coding shifts focus to product management and intent rather than manual coding.

Can non-developers build production-ready apps using vibe coding?

While vibe coding lets non-developers quickly prototype functional apps, most AI-generated code lacks the security and robustness needed for production deployment. That said, vibe-coded prototypes are great for concept validation.

What are the biggest risks of using AI-generated code for app development?

The most significant risks include security flaws (like missing validation, authentication, rate limiting, and protection against SQL injection), non-extensible architecture, and feature creep that leads to fragile or broken systems. The TEA app breach is an example of rapid development without proper security review, resulting in catastrophic consequences.

When does it make sense to use vibe coding for real business projects?

Vibe coding is ideal for rapid prototyping, internal tools, pre-development specification (requirements gathering), and MVPs for fundraising. However, for customer-facing apps or ones that process sensitive data, always invest in professional development and security reviews.

The Bottom Line: Know Your Architectural Limits

My grandmother maintains her simplified garden tracker for personal use. She also added functional analytics (the navbar button didn’t go anywhere before) to see how her garden is performing. 

This works as a single-user app. If you’re building a platform for multi-client use, you could still create vibe-coded prototypes, MVPs, etc., to get the ball rolling. But relying solely on vibe coding without understanding what’s going on is simply repeating the story of the TEA app. 

Vibe coding democratizes software creation while introducing new responsibilities. You can build apps in 30 minutes. However, you must understand architectural limits, security implications, and token consumption patterns before shipping to users.

The future belongs to builders who understand the prototype-production gap. 

Ready to build your first web app? Start with DreamHost Liftoff for WordPress-powered vibe coding that includes extensible architecture, managed hosting, security infrastructure, and proven scalability from day one. Build fast. Extend safely. Own your code.