Author: Richard Seroter

You’ve vibe coded an app? Congrats. That’s cool. Maybe you’re completely new to programming, or you’ve been doing it awhile. It’s possible you’ve seen some of the horror stories online of folks vibe coding something, deploying it, and then watching it collapse as folks flooded and hacked it. Yikes. It’s important to pay attention to quality attributes. Sometimes called non-functional requirements, these are key aspects of a well-built software system. They include traits like usability, maintainability, security, reliability, scalability, availability, and flexibility. While you might expect (hope?) that your vibe coding service created software that always adheres to these concepts, you shouldn’t assume so. And either way, these are important characteristics to understand if you want to mature as a software creator.

You can get AI to help here, though. I used Google AI Studio and Gemini 2.5 Pro to generate some prompts you could apply after you’ve built an app using Bolt, Vercel’s v0, Lovable, or Gemini Canvas. Maybe you plug those generated prompts into the Gemini CLI after you’ve downloaded the code from your vibe coding session. Here’s my initial prompt, which you could take and adjust however you want:

I’ve vibe coded an app, and now want to make sure it’s of high enough quality to ship to production. I’m not a professional developer. Suggest 3-5 comprehensive and understandable LLM prompts I should now offer my agentic CLI to check for software quality attributes like usability, reliability, performance, observability, security, repeatability, scalability, availability, flexibility, and maintainability.

Below is the direct output from Gemini, including the proposed prompts that hardens your software while making it more fault tolerant and scalable.

Here are 4 comprehensive prompts designed to be fed to your agentic CLI. They are structured to cover all the quality attributes you mentioned in a logical, step-by-step manner.

The Strategy: From Code to Cloud

We’ll use a layered approach. Think of it like building a house:

1. The Blueprint & Foundation: Is the code itself clean, organized, and easy to understand? (Maintainability, Flexibility)
2. The Walls & Locks: Is the application secure and can it handle errors gracefully? (Security, Reliability)
3. The Engine & Plumbing: Can the app perform under load and tell you when it’s sick? (Performance, Scalability, Observability)
4. The Assembly Line: Can you build and deploy it consistently every single time? (Repeatability, Availability, Scalability)

Prompt 1: The Code Quality & Maintainability Audit

Goal: This prompt focuses on cleaning up the existing “vibe code.” It makes your app easier for you (and your AI agent) to understand, modify, and extend in the future.

Attributes Covered: Maintainability, Flexibility, Repeatability (at the code level).

Act as a senior software engineer and mentor conducting a thorough code review of my entire project. Your goal is to improve its long-term maintainability, flexibility, and readability. Analyze the whole codebase and provide the following:

1.  **Refactoring for Clarity:** Identify the top 5 functions or classes that are too long, complex, or have unclear names ("code smells"). For each, provide a refactored version that is simpler, follows the Single Responsibility Principle, and has clearer naming.
2.  **Configuration & Secrets:** Scan the code for any hardcoded configuration values (like API endpoints, database strings, or magic numbers). Suggest extracting them into a centralized configuration file (e.g., `config.js`, `.env`, or `settings.py`) and provide the template for this file. Flag any plain-text secrets immediately.
3.  **Dependency Review:** List all external libraries and dependencies. Point out any that are deprecated, have known major issues, or could be replaced by a more standard/modern alternative.
4.  **Automated Quality Gates:** Generate a configuration file for a standard linter and code formatter for my project's language (e.g., `.eslintrc.json` and `.prettierrc` for JavaScript/TypeScript, or `pyproject.toml` for Python with Black and Ruff). This ensures future code stays clean.
5.  **Documentation:** Generate a template for a `README.md` file that includes a project description, setup instructions for a new developer, and an explanation of the core project structure.

Prompt 2: The Security & Reliability Hardening

Goal: This prompt switches focus to making your app robust against attacks and resilient to failure. It assumes the code is now cleaner from Prompt 1.

Attributes Covered: Security, Reliability, Availability.

Act as a paranoid but helpful security and reliability engineer. Your mission is to identify and help me fix potential security vulnerabilities and sources of unreliability in my application. Analyze the entire codebase and provide a report with actionable code suggestions for the following:

1.  **Security Vulnerability Scan (OWASP Top 10):**
    *   **Input Validation:** Find all points where the application accepts user input (API endpoints, forms, etc.). Check for potential injection vulnerabilities (SQL, NoSQL, Command).
    *   **Cross-Site Scripting (XSS):** Check if output to the user is properly sanitized or escaped.
    *   **Authentication/Authorization:** Review how users are authenticated and how their permissions are checked. Look for common flaws.
    *   **Insecure Dependencies:** Scan my `package.json`, `requirements.txt`, etc., for dependencies with known security vulnerabilities (CVEs) and suggest updated, secure versions.

2.  **Error Handling & Reliability:**
    *   Identify all critical code paths (e.g., database calls, external API requests, file I/O).
    *   Pinpoint areas lacking proper error handling (e.g., missing `try...catch` blocks or unchecked errors).
    *   For each area, suggest adding robust error handling that prevents the app from crashing and provides a clear error message or fallback.

3.  **Availability Checkpoint:**
    *   Suggest creating a simple health check endpoint (e.g., `/healthz` or `/status`). This endpoint should return a `200 OK` status if the app is running and can connect to its essential services (like the database). Provide the code for this endpoint.

Prompt 3: The Performance, Scalability & Observability Tune-Up

Goal: Now that the app is clean and secure, let’s make it fast and ensure you can see what’s happening inside it when it’s running.

Attributes Covered: Performance, Scalability, Observability.

Act as a Site Reliability Engineer (SRE) focused on performance and observability. Your goal is to ensure my application can handle growth and that I can diagnose problems in production. Analyze the codebase and suggest improvements in these areas:

1.  **Performance Bottlenecks:**
    *   **Database Queries:** Identify any database queries performed inside loops (N+1 query problem). Suggest how to optimize them into a single, more efficient query.
    *   **Heavy Computations:** Find any computationally expensive operations or inefficient algorithms that could block the main thread or slow down responses. Suggest optimizations or asynchronous execution.
    *   **Data Handling:** Look for places where the app loads very large amounts of data into memory at once. Suggest using pagination, streaming, or chunking.

2.  **Observability - Logging & Metrics:**
    *   **Structured Logging:** Review my current logging (or lack thereof). Propose a structured logging strategy (e.g., JSON format). Refactor 3-5 key `console.log` or `print` statements to use this new structured logger, including important context like user ID or request ID.
    *   **Key Metrics:** Identify the 3 most important metrics for my application's health (e.g., API request latency, error rate, number of active users). Show me where and how to instrument the code to capture these metrics, even if it's just with a logging statement for now.

3.  **Scalability Review:**
    *   Identify anything that would prevent me from running multiple instances of this application (horizontal scaling). This usually involves checking for in-memory state that should be moved to a shared store like a database or Redis (e.g., session stores, caches, locks).

Bonus Prompt 4: The Production-Ready Deployment Blueprint

Goal: This prompt bridges the gap between your laptop and a real server. It makes your deployment process automatic, reliable, and repeatable.

Attributes Covered: Repeatability, Availability, Scalability.

Act as a DevOps specialist. My application is now clean, secure, and performant, but I need a professional and repeatable way to deploy it. Based on my project's language and framework, generate the necessary files and configurations to containerize it and set up a basic deployment pipeline.

1.  **Containerization:** Create a multi-stage `Dockerfile`. The first stage should build the application (installing dev dependencies and compiling assets), and the final stage should be a lean, production-optimized image containing only the necessary runtime files and dependencies. Add comments explaining each step.
2.  **Local Development Environment:** Create a `docker-compose.yml` file. This file should define my application's service and any other services it depends on (like a database or a cache). This will allow any developer to spin up the entire stack with a single command (`docker-compose up`).
3.  **Configuration Management:** Create a `.env.example` file that lists all the environment variables the application needs to run (from Prompt 1), with placeholder values. This file serves as a template for production, staging, and development environments.
4.  **Continuous Integration (CI):** Generate a basic CI pipeline configuration file for GitHub Actions (`.github/workflows/ci.yml`). This pipeline should trigger on every push to the main branch and automatically:
    *   Install dependencies.
    *   Run the linter and code formatter checks (from Prompt 1).
    *   (If you have them) Run any automated tests.
    *   Build the Docker image to ensure it works.

By running your app through these four prompts, you’ll have systematically addressed the most critical software quality attributes, transforming your “vibe-coded” project into something you can be confident shipping to production.

Is this fun to do? I dunno. Maybe not as much fun as watching an agentic service crafting software right before your eyes. But it’s the right thing to do.

The “what” and the “how” in software engineering occasionally change at the same time. Often, one triggers the other. The introduction of mainframes ushered in batch practices that capitalized on the scarcity of computing power. As the Internet took off, developers needed to quickly update their apps and Agile took hold. Mobile computing and cloud computing happened, and DevOps emerged shortly thereafter. Our current moment seems different as the new “what” and “how” are happening simultaneously, but independently. The “what” that’s hot right now is AI-driven apps. Today’s fast-developing “how” is AI-native software engineering. I’m seeing all sorts of teams adopt AI to change how they work. What are they doing that you’re not?

AI natives always start (or end) with AI. The team at Pulley says “the typical workflow involves giving the task to an AI model first (via Cursor or a CLI program) to see how it performs, with the understanding that plenty of tasks are still hit or miss.” Studying a domain or competitor? Start with Gemini Deep Research or another AI research service. Find yourself stuck in an endless debate over some aspect of design? While you argued, the AI natives built three prototypes with AI to prove out the idea. Googlers are using it to build slides, debug production incidents, and much more. You might say “but I used an LLM before and it hallucinated while generating code with errors in it.” Stop it, so do you. Update your toolchain! Anybody seriously coding with AI today is using agents. Hallucinations are mostly a solved problem with proper context engineering and agentic loops. This doesn’t mean we become intellectually lazy. Learn to code, be an expert, and stay in charge. But it’s about regularly bringing AI in at the right time to make an impact.

AI natives switched to spec-driven development. It’s not about code-first. Heck, we’re practically hiding the code! Modern software engineers are creating (or asking AI) for implementation plans first. My GM at Google Keith Ballinger says he starts projects by “ask[ing] the tool to create a technical design (and save to a file like arch.md) and an implementation plan (saved to tasks.md).” Former Googler Brian Grant wrote a piece where he explained creating 8000 character instructions that steered the agent towards the goal. Those folks at Pulley say that they find themselves “thinking less about writing code and more about writing specifications – translating the ideas in my head into clear, repeatable instructions for the AI.” These design specs have massive follow-on value. Maybe it’s used to generate the requirements doc. Or the first round of product documentation. It might produce the deployment manifest, marketing message, and training deck for the sales field. Today’s best engineers are great at documenting intent that in-turn, spawns the technical solution.

AI natives have different engineer and team responsibilities. With AI agents, you orchestrate. You remain responsible for every commit into main, but focus more on defining and “assigning” the work to get there. Legitimate work is directed to background agents like Jules. Or give the Gemini CLI the task of chewing through an analysis or starting a code migration project. Either way, build lots of the right tools and empower your agents with them. Every engineer is a manager now. And the engineer needs to intentionally shape the codebase so that it’s easier for the AI to work with. That means rule files (e.g. GEMINI.md), good READMEs, and such. This puts the engineer into the role of supervisor, mentor, and validator. AI-first teams are smaller, able to accomplish more, capable of compressing steps of the SDLC and delivering better quality, faster. AI-native teams have “almost eliminated engineering effort as the current bottleneck to shopping product.”

There are many implications for all this. Quality is still paramount. Don’t create slop. but to achieve the throughput, breadth, and quality your customers demand requires a leap forward in your approach. AI is overhyped and under-hyped at the same time, and it’s foolish to see AI as the solution to everything. But it’s a objectively valuable to a new approach. Many teams have already made the shift and have learned to continuously evaluate and incorporate new AI-first approaches. It’s awesome! If you’re ignoring AI entirely, you’re not some heroic code artisan; you’re just being unnecessarily stubborn and falling behind. Get uncomfortable, reassess how you work, and follow the lead of some AI-native pioneers blazing the trail.