September 4, 2025
Earlier this year, Andrej Karpathy coined the term vibe coding: reimagining software creation with AI where
"… you fully give in to the vibes, embrace exponentials, and forget that the code even exists… just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."
Rather than manually typing each line of code, summon software with plain language: explain what you want to build, let an LLM like ChatGPT or Claude (maybe integrated with a code editor like Cursor or Windsurf) generate the code, run, refine, and repeat until it works.
Now, non-technical hobbyists and entrepreneurs can breathe software to life with plain-English prompts. Vibe coding lowers the entry barrier, enables rapid prototyping and iteration without traditional programming knowledge, and empowers non-technical creatives.
Tips for Vibe Coders
- 1. Stick to personal projects or get an early professional review
- 2. Use strict rules in your prompts
- 3. Watch the LLM work to understand basic structure and design
- 4. Prioritize well-known languages and concepts
- 5. Use standardized tools and common safeguards
- 6. Minimize overhead
- 7. Value your time
Use vibe coding for personal projects or early stage prototypes, rather than production builds or as a new startup, unless you thoroughly understand the attack vectors on what you’re building or have another set of seasoned and technical eyes looking at your project. An initial technical consult can help you build much more quickly, effectively, and safely by providing detailed feedback and suggested structure for your project (which will be valuable for detailed prompting). A legal consult can help you design your product to minimize liability vectors, do a quick entity and trademark name search before you get too attached to a name, and help you spin up a lightweight and simple single-member LLC or other entity; later, website terms and conditions, license agreements, and your own trademark filing.
Personal offline applications or static websites are a great first project.
Your first prompt should be the longest and most detailed but also constrained in the breadth and complexity of the desired output, with effective structure. In other words, start with as much detail as possible for a limited and parameterized goal. Ensure the LLM knows to use comments and create local tests, and a thorough README.md (a how-to document) covering the building, structure/design, and use of the project. Describe what you want to build and the rules for building as precisely as possible. If you’re using Cursor, create a global .cursorrules file describing your preferences and requirements: for example, specify that every code change must be accompanied by an analysis of performance considerations and whether any new dependencies were introduced (for example a new software library or external API, and what implications those have).
After your initial prompt, try to add one feature at a time and ensure it works as intended to avoid amassing too much “tech debt” and creating multiple simultaneous avenues for broken code. Otherwise, you may wind up trying to fix unknown bugs and create more tech debt and bugs in the process.
Treat the output as first draft. Run it locally (on your device) before you host it online where third parties can access. You must understand the basic structure and dependencies of your product before you market and sell it. Even if it’s merely a hobby project, you’ll use it more effectively and gain more from the experience if you understand the basics of what’s happening under the hood.
Knowing external dependencies and structure is essential for security and liability: do you have user rate limiting, a paywall, or other authentication of some sort to prevent running up a massive bill or denial of service? How about prompt injections if you use AI? If you aren’t sure and don’t know what they mean, re-visit #1 in this list.
LLMs generate code by pulling from their training data and online sources; the output will be higher-quality for programming languages with extensive history, documentation, examples, and general knowledge. Vibe coding websites in HTML + CSS + Javascript, for example, is often much more practical and advisable than attempting to vibe code Ethereum smart contracts in Solidity or Vyper both due to the substantially greater and ossified data pool for the former, and severe security implications for the latter. Of course, if you’re not sure what language or framework would be best, try a consult or even ask the LLM for a comparison on age, popularity, training corpus, etc.!
Avoid exposing sensitive data—keep prompts minimal, sanitize sensitive terms, and prefer local and client-side tools when possible to minimize leakage. Make sure you keep things like API keys in a proper secrets.env file that doesn’t get publicly exposed, or it will be exploited! If you don’t know what this means, you should not push something with an API key to production. Monitor dependencies (software code from others that’s used in your project), and try to use specific versions of third party software and commonly-used or native imports.
Try unique domain names and extensions, minimizing third-party integrations, and any recurring subscription expenses to keep costs low. To reiterate: be very careful about integrating per-call or other rate-based third party services (for example, an LLM’s API) into your application or site, as malicious actors will try to exploit gaps in your security or authentication, and harness the service or processing for free (free for them; those costs wind up on your bill). Keeping third party subscription services in your product minimal or avoiding them entirely can help your bottom line and security (and sanity).
Cloud hosting platforms like Netlify or Vercel can streamline some of your backend on a budget. They take your site or app code by automatic GitHub connection or simple drag-and-drop of your files, build the output, and host it within seconds. Setup and integration with your domain name can take some practice, but once you get a hang of the process, servers, speed, and host security are quickly taken care of and scales quickly: you can use an account for multiple sites and apps.
If you’re considering devoting time to building out a startup around your product, don’t forget to include your time spent building, testing, marketing, providing support, etc. in your profitability calculations. On the other hand, don’t forget about valuing other vibe coding intangibles:
• whether your product is useful for your own business or personal life
• the value of your product as a portfolio or resume showpiece, and
• the personal satisfaction of building something you wouldn’t have attempted without AI
Risks for Vibe Coders
Unsurprisingly, vibe coding software products without understanding how they work carries risks (and unknown unknowns can be the most dangerous):
- Security vulnerabilities
Vibe coders often skip (or don't know to do) foundational safety checks: missing input validation, introducing outdated libraries (or careless versioning, which can lead to breaking changes or unexpected errors), or creating back doors.
- Economic or access vulnerabilities
If users of a product aren't authenticated, rate-limited, or otherwise parameterized, they can abuse the product. A common example of this is a product that uses an LLM API (like ChatGPT) on the backend and charges users a fixed monthly fee but allows them unrestricted access, leading to massive bills for the host.
- Technical debt
Accrues when conflicting, complicated, duplicative code is accepted without understanding; over time, it makes codebases huge and maintenance fragile and error prone.
- Data leakage
Tools that send project context to cloud APIs and expose internal logic, secrets, or customer data can lead to exploits or legal/regulatory issues.
- Lost contextual alignment
LLMs often lack situational awareness, and may not interpret your intentions how you expect. They may output technically correct code that misses intended business logic, edge cases, or policy compliance.