Vibe coding is a way of building software by describing intent to an AI system, running what it produces, and steering the result through conversation. The person remains responsible for deciding what to build and whether it works, but may write little of the implementation directly.
The phrase is useful because it names a real change in interface. Instead of translating every idea into syntax, a builder can describe a feature, inspect the behavior, report what is wrong, and ask an agent to revise several files at once.
A working definition
At vibecoded.fyi, we use vibe coding to mean:
Building software primarily through natural-language direction, iterative execution, and AI-generated code, with the human steering outcomes more than typing implementation.
That definition describes a spectrum, not a purity test. A project can include manually written code, generated tests, design tools, or conventional code review and still be meaningfully vibe coded. The important questions are how the implementation was produced, what the human inspected, and how the result was verified.
Vibe coding is more than autocomplete
Traditional autocomplete predicts the next token or short block while a programmer controls the surrounding implementation. A coding agent can receive a goal, inspect a repository, edit multiple files, run commands, and react to failures. The human moves from typing each operation toward specifying, reviewing, and directing a sequence of operations.
The boundaries remain fuzzy. Someone accepting occasional suggestions is using AI-assisted programming. Someone delegating whole features through prompts and evaluating the running result is much closer to vibe coding. Our comparison guide explains that spectrum in more detail.
The basic loop
Most vibe-coding sessions repeat five actions:
- Describe an outcome. Explain the user, problem, constraints, and observable result.
- Let the tool inspect and change the project. Good agents use the existing code and conventions rather than starting from an imaginary architecture.
- Run the result. A plausible explanation is not evidence that the software works.
- Report concrete differences. Screenshots, errors, failing tests, and reproduction steps are better feedback than “make it better.”
- Review before release. Check security boundaries, data handling, accessibility, failure cases, and deployment configuration.
Where the “vibe” helps
Vibe coding is particularly effective when feedback is fast and visible: prototypes, internal tools, scripts, interface exploration, test scaffolds, and small automations. It can also contribute to larger systems when the repository has strong tests, clear interfaces, and experienced review.
The risk rises when mistakes are hard to observe. Authentication, payments, personal data, destructive automation, safety-critical control, and legal or financial calculations require expertise and verification beyond whether the happy path appears to work.
What it does not remove
Natural-language control does not remove software engineering concerns. It changes who—or what—produces the first implementation. The finished system still has dependencies, permissions, error paths, performance limits, maintenance costs, and users who can be harmed by incorrect behavior.
Responsible vibe coding therefore does not mean pretending every line was manually understood. It means being honest about the method and building enough evidence to trust the outcome: tests, review, logs, threat modelling, reproducible builds, and clear limits.
Why disclose it?
A vibe coding badge is a lightweight disclosure, not a quality score. It can tell contributors that AI tools were materially involved, make the development experiment visible, and invite useful questions about review. The best disclosures add context in the README: which tools were used, what humans reviewed, how tests run, and what remains experimental.