Vibe coding met AI: beginnersgids voor Codex en Claude Code

Vibe coding is software bouwen door in gewone taal met een AI-codeagent te werken. Jij beschrijft het doel, de agent leest de code, past bestanden aan, draait tests en legt uit wat er is veranderd. Voor beginners kan dat voelen alsof programmeren opeens toegankelijk wordt. De echte vaardigheid zit niet in blind prompts typen, maar in sturen, controleren, testen en klein houden wat de agent doet.

Augustus 2026 check: Werk je met Codex of Claude Code, lees dan ook Claude Code Auto Mode, waarom AI-bewijs mensenwerk blijft en de AI-vertrouwenscrisis rond Anthropic.

Vibe coding werd populair nadat Andrej Karpathy in februari 2025 beschreef hoe hij steeds vaker met AI bouwde door te praten, te draaien, fouten terug te voeren en de agent opnieuw te laten proberen. Sindsdien is de term groter geworden dan de oorspronkelijke grap. Hij wordt nu gebruikt voor een brede manier van werken waarin mensen ideeën, schermen, functies en bugs in natuurlijke taal aan AI-codeagenten geven.

Voor CryptoFocus is dit onderwerp relevant om twee redenen. Ten eerste schuift AI-coding snel richting gewone kenniswerkers, founders, marketeers, analisten en redacties. Ten tweede kan de Web3-wereld hier veel winnen, maar ook veel verliezen. Een kleine dashboard-app is een prima leerproject. Een DeFi-contract, wallet, bridge, trading bot of custody-tool bouwen zonder stevige code-review is een ander verhaal.

Wat is vibe coding?

Vibe coding betekent dat je software bouwt via een gesprek met AI. Je hoeft niet elke regel code zelf te typen. Je vertelt wat je wilt maken, de AI-codeagent leest de projectmap, schrijft of wijzigt bestanden, draait commando’s en helpt fouten oplossen. Dat kan in een editor, in een terminal, in een desktop-app of via een combinatie van tools.

De term klinkt losjes, maar goed vibe coden is juist vrij gedisciplineerd. Het werkt wanneer je het werk klein maakt, duidelijke grenzen geeft en de agent steeds laat bewijzen dat de code werkt. Het mislukt wanneer je vage wensen blijft stapelen, grote wijzigingen accepteert zonder diff, packages laat toevoegen zonder reden of foutmeldingen teruggooit zonder diagnose.

Waarom deze Gids anders is

Veel bestaande gidsen leggen uit wat vibe coding is en laten daarna één demo bouwen. Dat is nuttig, maar het mist het deel waar beginners later op vastlopen: de app werkt niet meer, de agent blijft rondjes draaien, er zijn te veel bestanden aangepast, er zitten onveilige afhankelijkheden in het project of niemand weet welke prompt tot welke wijziging leidde.

Deze Gids gebruikt daarom een andere volgorde. Eerst leer je hoe je een veilige werkomgeving maakt. Daarna kies je Codex, Claude Code of allebei. Vervolgens bouw je een kleine crypto-notities app zonder API-keys, zonder echte transacties en zonder financieel advies. Pas aan het einde kijken we hoe je de aanpak kunt uitbreiden naar serieuzere projecten.

Voor wie is vibe coding geschikt?

Vibe coding is geschikt voor beginners die een idee tastbaar willen maken, voor redacties die interne tools willen bouwen, voor founders die een prototype nodig hebben, voor analisten die dashboards willen maken en voor developers die saaie migraties of testwerk willen versnellen. Het is minder geschikt voor mensen die elke AI-output direct publiceren, geen Git willen gebruiken of niet bereid zijn foutmeldingen rustig te lezen.

Als je nog nooit hebt geprogrammeerd, kun je hiermee beginnen. Je hoeft niet meteen JavaScript, TypeScript, React, Git en terminalcommando’s volledig te beheersen. Je moet wel snappen wat een map is, wat een bestand is, wat een terminal doet, waarom een test faalt en waarom een commit een terugvalpunt is. De agent kan veel uitleggen, maar hij kan jouw verantwoordelijkheid niet overnemen.

Codex en Claude Code: wat doen ze?

Codex en Claude Code zijn AI-codeagenten. Ze zijn sterker dan een gewone chatbot omdat ze in een projectmap kunnen werken. Ze kunnen bestanden lezen, code aanpassen, commando’s uitvoeren, tests draaien en op basis van foutmeldingen een nieuwe poging doen. Dat maakt ze geschikt voor echt ontwikkelwerk, zolang je ze binnen duidelijke grenzen laat werken.

Codex is vooral interessant als je vanuit het OpenAI-ecosysteem werkt. Je kunt Codex gebruiken via de CLI, de desktop-app, de IDE-extensie en cloud- of reviewworkflows. De officiële documentatie legt veel nadruk op context, AGENTS.md, planmodus, sandboxing, approval policies, tests en review.

Claude Code is Anthropic’s agentische CLI voor softwarewerk. De officiële documentatie beschrijft Claude Code als een terminaltool die codebases begrijpt, over bestanden heen werkt, Git-taken kan uitvoeren en aangepast kan worden met CLAUDE.md, auto memory, skills, hooks, subagents en IDE-integraties.

Wat moet je installeren?

Voor deze Gids heb je drie basisdingen nodig: Git, Node.js en één AI-codeagent. Git bewaart je stappen. Node.js laat de voorbeeldapp draaien. Codex of Claude Code doet het agentwerk. Als je al een editor zoals VS Code gebruikt, is dat handig, maar niet verplicht voor het volgen van de stappen.

Installatiecommando’s veranderen. Gebruik de officiële documentatie als de commando’s op jouw machine afwijken. Op macOS en Linux kun je Codex in veel gevallen installeren met de standalone installer. Voor Claude Code adviseert de huidige documentatie ook een standalone installer of Homebrew, terwijl de oude npm-route als verouderd wordt behandeld.

# Codex CLI
curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex login

# Claude Code
curl -fsSL https://claude.ai/install.sh | bash
claude auth login

# Basischecks
git --version
node --version
codex --version
claude --version

Veilig beginnen: Git, sandbox en permissies

De belangrijkste beginnersregel is simpel: laat een agent nooit onbeperkt op je hele computer werken. Een goede agentomgeving heeft grenzen. Bij Codex heten die grenzen onder meer sandbox mode en approval policy. Bij Claude Code werk je met permission modes, allowed tools, settings en eventueel hooks. De namen verschillen, het principe is hetzelfde: de agent mag niet meer kunnen dan nodig is voor de taak.

Begin met een schone projectmap. Zet er geen belastingdocumenten, wachtwoorden, seed phrases, private keys of exchange-exports in. Gebruik Git voordat je de agent laat bouwen. Git is geen luxe. Git is je terugknop.

mkdir vibe-crypto-notities
cd vibe-crypto-notities
git init

# Maak alvast een bestand dat geheimen buiten Git houdt.
printf ".env\n.env.local\n*.pem\n*.key\n" > .gitignore

git add .gitignore
git commit -m "Start project met gitignore"

Gebruik in Codex de permissions-instellingen of de slash command /permissions om te zien in welke modus je werkt. Als je alleen wilt overleggen of plannen, gebruik read-only. Als de agent in de projectmap mag schrijven, is workspace-write met approvals meestal verstandiger dan volledige toegang. Gebruik full access alleen in een omgeving die je zelf al hebt afgeschermd.

In Claude Code kun je de agent ook beperken. Je kunt bijvoorbeeld in planmodus werken, tools toestaan of weigeren, en hooks gebruiken om bepaald gedrag te blokkeren. Voor beginners is het genoeg om eerst te leren: plan zonder edits, implementeer klein, review daarna.

Het voorbeeldproject: een crypto-notities app

We bouwen een kleine app voor persoonlijke crypto-notities. De app heeft een lijst met coins of thema’s, een notitieveld, een risicolabel, een onderzoekstatus en een filter. Alles blijft lokaal in de browser via localStorage. Er is geen exchange-koppeling, geen wallet, geen orderknop en geen adviesmodule.

Waarom dit project? Omdat het realistisch genoeg is om waarde te hebben, maar klein genoeg om te controleren. Je leert componenten, state, opslag, filtering, styling, tests, foutoplossing en review. Dat zijn dezelfde bouwstenen die later terugkomen in dashboards, researchtools en interne workflows.

Stap 1: laat de agent niet meteen bouwen

De eerste prompt is de belangrijkste prompt. Vraag niet om code. Vraag om begrip, vragen en een plan. Dit voorkomt dat de agent meteen een te grote architectuur kiest of allerlei packages installeert die je niet nodig hebt.

Ik ben beginner en wil een kleine React + TypeScript app bouwen:
een lokale crypto-notities app voor onderzoek.

Werk eerst in planmodus. Schrijf nog geen code.

Doel:
- Ik wil coins of thema's kunnen toevoegen.
- Per item wil ik thesis, risico, status en notities opslaan.
- Alles blijft lokaal in de browser.

Grenzen:
- Geen walletkoppeling.
- Geen exchange-API.
- Geen trading bot.
- Geen financieel advies.
- Geen extra packages zonder uitleg.

Done when:
- Je hebt de bestaande map bekeken.
- Je stelt maximaal 5 verduidelijkende vragen als iets ontbreekt.
- Je geeft een klein stappenplan dat ik kan goedkeuren.

Let op de woorden schrijf nog geen code. Die zin is geen formaliteit. Hij verandert de rol van de agent. De agent wordt eerst analist en pas daarna bouwer. Als de agent toch code begint te schrijven, stop hem en herhaal de grens.

Stap 2: kies je basisstack

Voor een beginner is React met TypeScript een redelijke keuze, omdat de toolchain breed wordt gebruikt en AI-agenten er goed mee overweg kunnen. Je kunt ook starten met gewone HTML, CSS en JavaScript. Voor deze Gids kiezen we React + TypeScript omdat je zo meteen leert werken met componenten, types en buildchecks.

Je kunt de agent de setup laten doen, maar laat hem uitleggen welke commando’s hij uitvoert. Dit maakt het verschil tussen leren en toekijken. Een goede agent zal aangeven dat een Vite-template logisch is voor een kleine front-end app.

Maak nu de minimale React + TypeScript setup met Vite.

Regels:
- Gebruik zo min mogelijk dependencies.
- Leg kort uit welke commando's je uitvoert.
- Pas nog geen visueel ontwerp toe.
- Na de setup moet npm run build werken.

Voer daarna de build uit en rapporteer wat is gelukt of mislukt.

Als je zelf de commando’s wilt uitvoeren, kan dat zo:

npm create vite@latest . -- --template react-ts
npm install
npm run build
npm run dev

Stap 3: bouw het datamodel voordat je schermen maakt

Beginners willen vaak meteen een mooi scherm. Dat is begrijpelijk, maar bij vibe coding is het beter om eerst het datamodel helder te maken. Wat is een notitie? Welke velden zijn verplicht? Welke statussen bestaan? Welke risico’s wil je tonen? Een agent die dit overslaat, gaat later refactoren omdat de basis te vaag was.

Maak eerst alleen het datamodel en een kleine set voorbeelddata.

Gebruik TypeScript-types voor:
- AssetNote
- RiskLevel
- ResearchStatus

Velden:
- id
- name
- ticker
- thesis
- riskLevel
- status
- notes
- updatedAt

Voeg 3 voorbeelditems toe, maar gebruik geen beleggingsadvies.
Laat daarna zien welke bestanden je hebt aangepast.

Goede voorbeelddata is concreet zonder aanbeveling te worden. Een neutrale Bitcoin-thesis over netwerkwaarde en monetair experiment is bruikbaar. Een koopoproep is dat niet. Zeker op een site met crypto-onderwerpen moet je de grens tussen researchtool en advies helder houden.

Stap 4: bouw één scherm, geen complete applicatie

Laat de agent daarna één scherm bouwen: een overzicht met cards of rijen, plus een formulier om een item toe te voegen. Vraag niet tegelijk om donkere modus, grafieken, login, export, animaties en live koersen. Elke extra wens vergroot de kans dat de agent veel bestanden tegelijk verandert.

Bouw nu één bruikbaar scherm:
- links of bovenaan een formulier om een assetnote toe te voegen
- daaronder een overzicht van bestaande notes
- toon name, ticker, riskLevel, status, thesis en updatedAt
- houd het ontwerp rustig en leesbaar
- geen externe UI-library

Controleer daarna:
- npm run build
- of er TypeScript-fouten zijn
- welke bestanden zijn gewijzigd

Vraag de agent na de wijziging om een korte uitleg in gewone taal. Niet omdat je elke regel meteen moet snappen, maar omdat de uitleg je helpt beoordelen of de agent het doel begreep. Als de uitleg vaag is, vraag door voordat je verder bouwt.

Stap 5: voeg lokale opslag toe

De app wordt pas nuttig als notities blijven bestaan na refresh. Voor een eerste project is localStorage goed genoeg. Het is niet geschikt voor gevoelige data, maar prima voor een leerapp met niet-gevoelige testnotities. Laat de agent expliciet rekening houden met corrupte data, lege opslag en toekomstige aanpassingen.

Voeg lokale opslag toe met localStorage.

Regels:
- Gebruik één duidelijke storage key.
- Als opgeslagen data ongeldig is, moet de app terugvallen op voorbeelddata.
- Schrijf kleine helperfuncties voor load en save.
- Voeg eenvoudige tests toe voor deze helpers als testsetup al aanwezig is.
- Geen externe storage packages.

Rond af met buildcheck en diffsamenvatting.

Dit is een goed moment om te leren hoe foutafhandeling eruitziet. Een agent die alleen het blije pad bouwt, maakt vaak een demo die werkt zolang alles meezit. Vraag daarom om failure cases: lege opslag, kapotte JSON, ontbrekende velden en dubbele tickers.

Stap 6: voeg filters en statussen toe

Nu de app werkt, kun je hem bruikbaarder maken. Voeg filters toe op risico, status en zoekterm. Dit is klein genoeg voor één agentronde, maar rijk genoeg om echte logica te bevatten. Laat de agent de filterfunctie los testbaar maken, dus niet verstopt in een grote component.

Voeg filters toe:
- zoekterm op naam, ticker en thesis
- filter op riskLevel
- filter op status

Architectuur:
- Zet filterlogica in een aparte functie.
- Maak de UI eenvoudig.
- Voeg tests toe voor de filterfunctie.

Accepteer geen grote refactor zonder eerst uit te leggen waarom die nodig is.

De laatste regel in die prompt is belangrijk. AI-agenten kunnen bij kleine wensen soms een grote herschikking voorstellen. Soms is dat terecht. Vaak niet. Vraag altijd om de reden. Als de reden zwak is, laat de agent een kleinere wijziging maken.

Stap 7: laat tests en buildchecks verplicht worden

Vibe coding zonder checks is gokken met extra stappen. Een beginner hoeft niet meteen testarchitectuur te beheersen, maar moet wel leren dat code pas af is als de belangrijkste checks lopen. Voor een front-end project zijn minimaal build, lint en een paar unit tests zinvol. Als je project nog geen tests heeft, laat de agent een lichte testsetup voorstellen en vraag waarom die keuze past.

Stap 8: review met een tweede agent

Een slimme workflow is om Codex en Claude Code niet als rivalen te zien, maar als twee rollen. Laat de ene bouwen en de andere reviewen. Dat werkt vooral goed als je de reviewer geen schrijfrechten geeft of expliciet vraagt om alleen bevindingen te rapporteren. Zo voorkom je dat twee agents elkaars keuzes blijven overschrijven.

Review deze wijziging alsof je een senior engineer bent.
Schrijf geen code en pas geen bestanden aan.

Controleer:
- bugs of edge cases
- security- en privacyrisico's
- onnodige dependencies
- ontbrekende tests
- onduidelijke naamgeving
- plekken waar een beginner later vastloopt

Geef bevindingen op volgorde van ernst.
Gebruik bestandsnamen en concrete redenen.

In Codex kun je hiervoor de reviewfunctie gebruiken, bijvoorbeeld via /review in een sessie of codex review buiten de interactieve omgeving. In Claude Code kun je een aparte sessie starten en vragen om review zonder edits. Als jouw versie een plan- of read-only-achtige modus biedt, gebruik die voor reviews.

AGENTS.md voor Codex

AGENTS.md is een instructiebestand voor Codex. Het wordt automatisch gelezen wanneer Codex in een project werkt. Zie het als een korte handleiding voor de agent: hoe het project draait, welke commando’s belangrijk zijn, welke stijl je wilt en welke grenzen niet overschreden mogen worden.

Maak het bestand niet lang. Goede agentinstructies zijn concreet en toetsbaar. Slechte instructies zijn vaag: maak goede code, denk goed na, zorg dat het mooi is. Zeg liever welke commands moeten draaien en welke keuzes eerst uitgelegd moeten worden.

# AGENTS.md

## Project
Dit is een kleine React + TypeScript app voor lokale crypto-notities.
De app is educatief en geeft geen financieel advies.

## Commands
- Install: npm install
- Dev server: npm run dev
- Build: npm run build
- Lint: npm run lint
- Tests: npm test

## Werkstijl
- Maak kleine wijzigingen.
- Leg een plan uit voordat je meerdere bestanden wijzigt.
- Voeg geen dependency toe zonder reden en alternatief.
- Houd logica testbaar buiten grote componenten.
- Rond af met buildcheck en diffsamenvatting.

## Niet doen
- Geen walletkoppeling.
- Geen exchange-API of echte orders.
- Geen private keys, seed phrases of API-keys in code.
- Geen financieel advies of koopsignalen.

CLAUDE.md voor Claude Code

Claude Code gebruikt CLAUDE.md en auto memory om projectcontext en voorkeuren mee te nemen. De officiële documentatie adviseert om projectinstructies kort, specifiek en gestructureerd te houden. Voor beginners is het doel hetzelfde als bij Codex: minder herhalen, minder misverstanden en minder grote sprongen.

# CLAUDE.md

We bouwen een kleine educatieve crypto-notities app.
De gebruiker is beginner en wil leren wat elke stap doet.

## Gedrag
- Stel vragen als requirements ontbreken.
- Maak eerst een plan bij multi-file changes.
- Wijzig niet meer bestanden dan nodig.
- Rapporteer gewijzigde bestanden na elke taak.
- Vraag toestemming voordat je dependencies toevoegt.

## Validatie
- Draai npm run build na codewijzigingen.
- Draai tests als testsetup bestaat.
- Als een check faalt: diagnoseer eerst, fix daarna pas.

## Grenzen
- Geen echte tradingfunctionaliteit.
- Geen walletintegratie.
- Geen secrets in code of prompts.
- Geen claims die financieel advies lijken.

Promptbibliotheek voor beginners

Goede prompts zijn klein, concreet en toetsbaar. Ze bevatten het doel, de context, de grenzen en wat klaar betekent. Een prompt hoeft niet literair te zijn. Hij moet vooral de agent minder ruimte geven om verkeerde aannames te maken.

Hoe voorkom je de debugging-lus?

De klassieke vibe-coding-fout is de debugging-lus: je plakt een foutmelding, de agent verandert code, er komt een nieuwe fout, de agent verandert nog meer code, en na tien rondes weet niemand meer wat het probleem was. Dit voelt actief, maar vaak wordt de code slechter.

De oplossing is om diagnose en fix te scheiden. Vraag eerst om oorzaakonderzoek zonder edits. Laat de agent exact aanwijzen welke foutmelding, welk bestand en welke aanname relevant is. Pas daarna laat je één gerichte wijziging maken. Als de fout na twee pogingen niet weg is, start je een nieuwe sessie met een samenvatting en de huidige diff.

Deze fout verschijnt na npm run build.
Diagnoseer eerst. Wijzig nog geen bestanden.

Geef:
1. de directe oorzaak
2. het bestand waar je zou kijken
3. de kleinste mogelijke fix
4. welk risico die fix heeft

Pas de fix pas toe nadat ik akkoord geef.

Wanneer gebruik je Codex, wanneer Claude Code?

Als beginner kun je met beide tools hetzelfde type project bouwen. Het verschil zit in workflow en gevoel. Codex past goed bij gebruikers die vanuit ChatGPT, de desktop-app of een gestructureerde reviewworkflow denken. Claude Code past goed bij mensen die terminal-first willen werken en veel waarde halen uit CLAUDE.md, hooks, skills en commandoregelautomatisering.

De praktische keuze: kies één hoofdagent voor de eerste week. Leer hoe die agent plant, bestanden wijzigt, toestemming vraagt, tests draait en diffs uitlegt. Voeg pas daarna de tweede agent toe als reviewer. Twee onbekende tools tegelijk leren geeft vaak ruis.

Wat moet je zelf blijven begrijpen?

Je hoeft niet alles te weten voordat je begint. Je moet wel weten welke vragen je moet stellen. Bij elke wijziging wil je kunnen antwoorden: welk bestand is aangepast, waarom was dat nodig, hoe kan ik het draaien, welke check bewijst dat het werkt en hoe kan ik terug als het misgaat?

Vraag de agent vaak om uitleg, maar vraag om uitleg op het juiste niveau. Leg alles uit levert meestal lange tekst op. Beter is: Leg deze functie uit in vijf bullets, noem de input, output, side effects, failure cases en test. Dat geeft informatie waarmee je echt kunt reviewen.

Security: wat mag de agent niet doen?

De OpenSSF-richtlijnen voor AI-codeassistenten maken één punt scherp: jij blijft de developer, de AI is de assistent. AI-code kan bugs, kwetsbaarheden, onveilige dependencies en verzonnen patronen bevatten. Gebruik daarom dezelfde basisdiscipline als bij menselijke code: review, testen, statische analyse, dependency checks, documentatie en versiebeheer.

Voor crypto en Web3 ligt de lat hoger. Een gewone UI-bug is vervelend. Een fout in walletlogica, signing, key management, bridges, smart contracts of trading kan blijvende schade geven. Gebruik vibe coding daar alleen als hulpmiddel voor uitleg, scaffolding, tests of onderzoek, niet als enige kwaliteitslaag.

Wil je eerst zonder live orders begrijpen hoe API-rechten, regionale toegang en orderlimieten werken? Gebruik dan onze technische API-gids als afgebakende voorbereiding; die gids beschrijft geen live accounttest.

Van vibe coding naar spec-driven werken

Vibe coding is sterk in ontdekken. Je kunt snel zien of een idee werkt, welke schermen nodig zijn en waar de frictie zit. Maar zodra een project belangrijker wordt, moet je de losse chatgeschiedenis omzetten naar levende specificaties: requirements, acceptatiecriteria, dataflows, testcases en technische grenzen die in de repo staan.

Die overgang is het verschil tussen een leuke demo en software die je kunt onderhouden. Gebruik vibe coding om te verkennen. Gebruik specificaties om te bouwen wat blijft. Dat sluit aan bij de bredere les uit het DORA-onderzoek: AI-adoptie is geen toolprobleem alleen, maar een systeemprobleem. Teams hebben versiebeheer, duidelijke standaarden, goede data, kleine batches, platformkwaliteit en meetbare feedback nodig.

Een 7-daags leerpad voor beginners

Je leert vibe coding sneller door zeven kleine sessies te doen dan door één dag alles tegelijk te proberen. Elke dag heeft één doel en één tastbaar resultaat. Na een week heb je een werkende mini-app en, belangrijker, een werkwijze die je kunt herhalen.

Veelgemaakte fouten bij vibe coding

Beginnersfouten zijn normaal. Het probleem is niet dat je fouten maakt, maar dat AI-agenten fouten snel kunnen vermenigvuldigen. Een verkeerd patroon staat binnen seconden in vijf bestanden. Daarom helpt het om veelvoorkomende fouten vooraf te herkennen.

Hoe gebruik je Codex en Claude Code samen?

De combinatie wordt sterk wanneer je rolverdeling helder is. Laat bijvoorbeeld Codex de eerste implementatie doen, commit de werkende stap en laat Claude Code daarna reviewen. Of draai het om. Wat je niet wilt: twee agents in dezelfde map laten editen zonder tussencommit. Dan verlies je herleidbaarheid.

Gebruik verse context wanneer het gesprek rommelig wordt. Agenten hebben contextvensters en chatgeschiedenis kan zwaar worden. Als een sessie te veel aannames bevat, vraag om een korte projectstatus en start een nieuwe sessie met die status, de huidige Git-status en de relevante foutmelding.

Wat betekent dit voor SEO, content en CryptoFocus?

Vibe coding is meer dan een developeronderwerp. Redacties kunnen interne dashboards bouwen, researchlijsten opschonen, bronchecks automatiseren, visualisaties prototypen en contenttools maken. Voor een site als CryptoFocus is de waarde vooral intern: sneller experimenteren met data, AI en Web3-onderwerpen zonder elke kleine tool uit te besteden.

De grens blijft belangrijk. Een contenttool die bronlinks verzamelt is laag risico. Een tool die marktdata interpreteert en koopadviezen genereert is hoog risico. Een parser voor openbare documenten is laag tot middel. Een walletanalyse met adressen van lezers of klanten raakt privacy. Vibe coding versnelt uitvoering, maar het maakt slechte productkeuzes niet beter.

Wanneer ben je klaar om serieuzer te bouwen?

Je bent klaar voor een groter project wanneer je kleine wijzigingen kunt laten maken, tests kunt draaien, diffs kunt lezen, dependencies kunt beoordelen en met Git kunt terugrollen. Niet wanneer je eerste demo toevallig werkt. Een demo is bewijs dat iets kan starten. Onderhoudbare code bewijst dat het kan blijven bestaan.

Veelgestelde vragen over vibe coding