A new name for a very old idea — now powered by AI
"I just see stuff, say stuff, run stuff, and it mostly works. I'm talking to the AI like it's a very smart rubber duck that solves everything." — Andrej Karpathy, coining the term "vibe coding" (2025)
Core idea
Using AI assistants (Copilot, Claude, GPT-…) as your primary implementation partner — you describe intent, AI writes code, you guide and verify.
Why it matters
Dramatically accelerates the implementation phase. A solo developer can produce work that previously needed a team — if done right.
Natural language → codeAI pair programmerSolo → team speedHuman still in charge
2
// the danger
The Misconception
Most vibecoding failure is not an AI problem — it's a process problem
❌ chaos mode (wrong)
No spec or plan, just "vibe it"
Prompt AI, accept everything blindly
Skip testing ("AI doesn't make bugs")
Patch over problems instead of fixing root cause
Lose track of what the code does
Ship broken, unmaintainable code
✔ structured mode (right)
Clear goal & design before AI
Human reviews every generated block
Tests written alongside code
Correct the cause, not the symptom
Documentation kept up to date
Iterative, versioned, auditable
The uncomfortable truth: AI amplifies both good habits and bad ones. Structure matters more with AI, not less.
3
// framework
The 4 Rules of Vibecoding
Same rules as traditional software development — AI changes nothing here
1
PLAN
Know your target and goal before writing a single prompt. Define scope, design, constraints.
01
2
IMPLEMENT
Write the code — with AI as your co-pilot. You drive. Review everything that's generated.
02
3
TEST
Verify it works. Unit tests, integration tests, manual play-throughs. AI-written code needs more testing, not less.
03
4
CORRECT
Fix what's broken. Iterate. This is not failure — it is the process. Ship, observe, improve.
04
// rule 01 of 04
Rule 1PLAN
Know your target. Know your goal. Before you open the AI chat.
What to plan
Problem statement & success criteria
Architecture & tech stack
Data model & system boundaries
Feature scope (what's in / out)
Security requirements up front
Why it matters with AI
AI is infinitely helpful — but it needs direction
Vague prompt → plausible-looking wrong code
Plan becomes your system prompt context
Easier to review AI output against a spec
Avoids massive late-stage refactors
Rule of thumb: If you can't explain the goal in two sentences without jargon, you're not ready to prompt the AI yet.
1
// rule 01 — case study
Planning in Practice: CyberQuest
A 27,500-line game built by one person — planning made it possible
Documentation before code
PROJECT_OVERVIEW.md — complete scope & FAQ
GAME_ARCHITECTURE.md — 70+ pages of technical design
SYSTEMS.md — 60+ pages of all game systems
SCENES.md — 80+ pages of scene catalog
STORY.md — full screenplay (1491 lines, 20 parts)
RULES.md — game design philosophy
STORYBOARD.md — visual panels per scene
200+
pages of docs
7+
design docs
Key insight
The docs were written first. Every AI prompt was grounded in an already-designed system. The AI never had to guess intent — it was always told exactly what to build and why.
// example: prompting with context
"Per GAME_ARCHITECTURE.md §3.2,
implement the evidence viewer
component with these exact fields..."
// rule 02 of 04
Rule 2IMPLEMENT
Human drives. AI builds. You integrate, review, and own every line.
🎯
You define
What to build, interfaces, constraints, architecture decisions
🤖
AI generates
Boilerplate, patterns, algorithms, documentation, test stubs
👁
You verify
Every generated block. Logic, security, style, correctness
Critical mindset shift: You are not typing code — you are engineering it. The keyboard just changed. Responsibility did not.
2
// rule 02 — workflow
The AI Collaboration Loop
Prompt → Generate → Review → Integrate → Repeat
📝
Prompt
Precise context & goal
→
🤖
Generate
AI writes the block
→
🔍
Review
Read every line
↑ fix & re-prompt
🔗
Integrate
Merge into codebase
→
🏁
Verify
Run tests, commit
Key: Small, focused prompts beat large, vague ones. One concern per prompt. Name everything by its spec name. Include context from your docs.
// rule 02 — ai strengths
What AI Does Well
Leverage these — your time is better spent on design and review
Rule: Use AI for the how. You own the why and what.
// rule 02 — case study
Implementation: CyberQuest
Solo developer · Vanilla HTML/CSS/JS · No frameworks · No build step
27,500+
lines of code
33
game scenes
250+
hotspots
80+
project files
Engine highlights
4,000+ line main game engine (game.js)
Dialogue, inventory, quest, evidence systems
Investigation cork board
Regional Michelin-style paper map
Optional voice narration (Web Speech API)
Development timeline
Started: early 2025
v0.6-alpha: first public pre-release
v1.0 (Feb 15, 2026): 18 scenes, full game
v1.1 (Feb 27, 2026): expanded to 33 scenes
v1.2 (Mar 7, 2026): production polish + security
Why no framework? "Maximum compatibility, zero build complexity, easy to understand and modify, no toolkit rot." — the plan made this a deliberate choice, not an accident.
// rule 03 of 04
Rule 3TEST
AI-written code needs more testing, not less. Trust but verify — always.
What to test
Unit tests — every function, every path
Integration — how systems interact
Security — OWASP Top 10 checklist
Manual playthroughs / exploratory test
Edge cases AI might have missed
Why AI makes testing harder
Confident-sounding code can still be wrong
AI satisfies the happy path, misses edge cases
Security anti-patterns introduced silently
You can't review what you didn't write carefully
Scale: more code generated → more surface area
Golden rule: If it's not tested, it doesn't work. This was true before AI. It's even more true now.
3
// rule 03 — case study
Testing in Practice: CyberQuest
v1.2 — Production hardened through systematic quality assurance
179
unit tests
179
passing ✔
Unit test coverage
All engine systems tested independently
Inventory, dialogue, quest, evidence
Save/load format v2
Puzzle logic (ROT1 cipher, passwords)
Edge cases: null inputs, corrupted save data
Security Audit (SECURITY_AUDIT.md)
Static security audit at v1.2
CSP compliance — extract inline scripts
Frame-ancestors header applied
Fixed _storage null-injection bug in DI
Production console.log suppressed on non-localhost
Iteration is not failure. It is the process. Ship, observe, improve, repeat.
What correcting means
Fix bugs raised by tests — at the root cause
Refactor AI output that works but is brittle
Address security findings immediately
Update docs when reality diverges from spec
Cut scope that doesn't serve the goal
The versioning discipline
Commit small, logical increments
Tag releases (v0.x → v1.0 → v1.1 → v1.2)
Changelogs tell the story of corrections
Revert if a "fix" breaks more than it heals
Each correction improves the AI prompt quality too
Mindset: The difference between vibecoding chaos and vibecoding mastery is whether you treat each bug as a surprise — or as the expected next step.
4
// rule 04 — case study
Correcting in Practice: CyberQuest History
Every version tells a story of plan → implement → test → correct
v0.6-alpha
First public pre-release — core engine, initial scenes, basic systems. Proof of concept that the architecture worked.
v1.0 Feb 15
Production release — 18 scenes, 20 story parts + epilogue. All core systems implemented and tested. 200+ pages of documentation. Mobile support, voice narration, save/load.
v1.1 Feb 27
Expanded release — 15 new scenes (total 33). Pause system, scene-based clock, save format v2. Hackerspace, ASTRON, LOFAR, Westerbork scenes. Engine grew from 1,490 → 2,704 lines.
v1.2 Mar 7
Production polish — 179/179 unit tests passing. Fixed _storage null-injection bug. Security hardening (CSP, frame-ancestors). Removed debug files. CC BY-SA 4.0 license. PRODUCTION READY ✔
// the framework
The Full Cycle
It's not a waterfall. It's a loop. Each pass increases quality.
● Plan — define before prompting
● Implement — human-guided AI
● Test — verify every output
● Correct — root cause, not patches
Each loop → higher quality
// mindset
Co-Pilot, Not Auto-Pilot
Human judgment is the irreplaceable ingredient in vibecoding
Auto-pilot (wrong)
"The AI wrote it, it looks fine, ship it."
AI generates plausible code. Plausible is not the same as correct. The model cannot know your full context, your users, your constraints, or your intentions.
Co-pilot (right)
You hold the controls. AI handles turbulence. You navigate, decide on routing, make judgment calls. You are responsible for the destination — and for landing safely.
What stays human
Architectural decisions
Security and privacy judgment
User empathy and UX decisions
Risk assessment and trade-offs
Code review and final merge authority
Accountability for the shipped product
The goal is not to replace engineering discipline. It is to amplify engineering speed while preserving engineering discipline.
// lessons learned
Pitfalls to Avoid
These patterns account for most vibecoding failures in the wild
🎯
No plan, no direction
Starting to prompt before the goal is clear. AI fills the vacuum with plausible-but-wrong solutions. Result: spaghetti that technically runs.
🤖
Accepting all AI output blindly
Every generated line needs to be read and understood. "It compiled" is not a review. Subtle logic errors accumulate silently.
🔓
Skipping security review
AI commonly introduces XSS, injection, or unsafe deserialization. Always run OWASP checklist. The CyberQuest CSP/injection fix in v1.2 is a real example.
🏔
Scope creep enabled by AI speed
AI makes adding features too easy. Scope grows faster than tests and docs. Stick to the plan — the plan exists for a reason.
🩹
Patching symptoms, not causes
Asking AI to "fix the error" without understanding why it happened produces fragile patches. Debug first, then prompt.
// actionable
Best Practices
One concrete tip per rule — start here
Rule 1 — Plan
Write a one-page spec before the first prompt
Define done: measurable success criteria
Decide tech stack and non-negotiable constraints
Create a doc for each major subsystem
Include the spec in your system prompt
Rule 2 — Implement
One concern per prompt — stay focused
Read every generated line before pasting
Name things by your spec name, always
Prefer small, composable functions
Commit small and often
Rule 3 — Test
Write tests for spec, not for AI output
Let AI generate test stubs, you fill logic
Run security checklist on every new feature
Exploratory testing catches what unit tests miss
Treat a passing test suite as the baseline
Rule 4 — Correct
Understand the root cause before re-prompting
Update docs when code diverges from spec
Tag each stable state as a version
Revert when a patch breaks more than it fixes
Each correction sharpens your next prompt
// case study summary
CyberQuest — Stats Dashboard
A complete picture of what vibecoding with discipline produced
27,500+
lines of code
179/179
tests passing
200+
pages of docs
v1.2
production
33
game scenes
250+
hotspots
2,000+
dialogue lines
40+
evidence docs
1 developer · solo project · ~3 months Javascript 92.6% · CSS 2.6% · HTML 2.4% · Python 2.3%
Zero dependencies · No build step · No install Just open index.html in a browser
// live example
See It: CyberQuest
Operation ZERFALL — A techno-thriller point-and-click adventure
What it is
A Sierra-style point-and-click adventure game built with pure vanilla HTML, CSS, and JavaScript. You play Ryan Weylant, a Dutch hacker near the German border, who uncovers a Russian infiltration operation via SSTV transmissions.
Key features
33 handcrafted SVG scenes (~10 MB)
Realistic hacking tools (HackRF, Flipper Zero)
Investigation cork board + regional map
Voice narration (Web Speech API)
Mobile-friendly, works offline
// Play online
https://ryanweylant.tech/
// Source code
https://github.com/reinvelt/CyberQuest
// Run locally
$ git clone https://github.com/reinvelt/CyberQuest
$ cd CyberQuest && python -m http.server 8000
Why it's a good vibecoding example
200+ pages of design docs written first
179 automated tests, security audit done
4 clear versioned releases with changelogs
One person — team-scale output
// looking ahead
The Future of Vibecoding
Where is this heading for engineering practice?
⚡
Velocity keeps increasing
AI models improve rapidly. The gap between "a plan in your head" and "working software" will keep shrinking. The bottleneck shifts entirely to human judgment and design.
🏗
Architecture skill becomes king
When AI can write the code, the hardest skill is knowing what to build and how to structure it. System design and domain knowledge grow in value.
🔒
Security is non-negotiable
More AI-generated code means more surface area faster. Security review, threat modeling, and automated audits are not optional extras — they are table stakes.
📐
Specs become the product
Clear, precise specifications that can be fed to AI are the core asset. Writing good specs is the new "write good code." The same care applies.
🧪
Testing accelerates too
AI can generate test suites from specs. The discipline of writing testable, well-specified systems pays double — faster implementation and faster verification.
🔄
Rules stay constant
Plan. Implement. Test. Correct. These four rules pre-date AI and will outlast every AI model. The tools change. Discipline doesn't.
// conclusion
Done right, vibecoding is just software development
1
Plan
→
2
Implement
→
3
Test
→
4
Correct
→ loop
AI changes the keyboard. It does not change the rules. CyberQuest: 27,500+ lines · 33 scenes · 179/179 tests · 1 developer · 3 months
Play: ryanweylant.tech · Source: github.com/reinvelt/CyberQuest