Dit artikel is het eerste in een reeks waarin ik uitleg hoe je helemaal vanaf nul begint met vibe coding..
Niet alleen hoe je een kunstmatige intelligentie vraagt om wat code te schrijven, maar hoe je het goed aanpakt: met een systeem dat fouten tot een minimum beperkt en een zekere codekwaliteit garandeert. Inclusief documentatie, een geschiedenis van codewijzigingen en een testsysteem. Net als professionele ontwikkelteams, maar zonder dat je zelf ontwikkelaar hoeft te zijn.
Daarvoor moeten we eerst onze computer voorbereiden en de nodige tools configureren.
Aan het einde van deze eerste handleiding hebben we een computer die klaar is voor vibe coding en hebben we met GitHub en Railway een kleine testapp gepubliceerd.
Waarom ik Linux aanraad voor vibe coding
Je kunt prima aan vibe coding doen op Windows, Linux of macOS. De belangrijkste AI-tools werken op alle drie de systemen, rechtstreeks of via compatibele omgevingen.
Ik ga Linux gebruiken, omdat het een hoop dingen eenvoudiger maakt en waarschijnlijk minder fouten oplevert dan Windows. Als we per se Windows willen gebruiken, kunnen we met WSL2 een Linux-omgeving binnen Windows 11 draaien. Maar daarmee voegen we nog een configuratielaag toe die het bij problemen ingewikkelder kan maken.
Met Linux werken we rechtstreeks in de omgeving waarin we de tools zullen uitvoeren, zonder afhankelijk te zijn van een extra subsysteem.
En macOS? Dat gebruik ik niet, dus daar kan ik niet uit eigen ervaring over oordelen. Maar gezien het succes van de Mac Mini en het feit dat de terminal en de Unix-omgeving een workflow mogelijk maken die sterk op die van Linux lijkt, vermoed ik dat het net zo geschikt is voor ontwikkeling.
Liever een tweede computer of een aparte schijf
Ik raad ook aan om niet op je belangrijkste werkcomputer te experimenteren met softwareontwikkeling en AI-agents, vooral zolang je nog aan het leren bent.
Niet omdat deze tools op zichzelf gevaarlijk zijn — al kunnen ze dat ook zijn — maar omdat ze afhankelijkheden kunnen installeren, opdrachten kunnen uitvoeren, bestanden kunnen wijzigen en dingen kunnen doen die we misschien helemaal niet willen.
Daarom houd ik die omgeving liever gescheiden van de computer waarmee ik dagelijks werk. Je weet inmiddels dat ik liever het gebruik van mijn pc opsplits dan er achteraf spijt van krijg dat ik dat niet heb gedaan.
Idealiter gebruik je een tweede computer, maar daarvoor hoeven we niet meteen een nieuw apparaat te kopen. Als je er geen hebt, is een oplossing die ik bijzonder prettig vind Linux op een externe SSD installeren en die via USB opstarten op een compatibele pc..
Zo kan ik Linux opstarten als ik wil ontwikkelen en de rest van de tijd gewoon Windows blijven gebruiken. Programma's, projecten en instellingen blijven op de SSD staan, zonder dat ik op de hoofdschijf een Linux-partitie moet maken.
Maar let op: het is geen volledige isolatie. Linux kan andere aangesloten schijven benaderen als we die koppelen en de nodige rechten geven. We moeten dus blijven opletten welke acties we toestaan.
Zelf gebruik ik de opstelling uit het artikel: Linux Mint Xfce geïnstalleerd op een SATA-SSD in een USB 3.0-behuizing.
Vanaf nu ga ik ervan uit dat je Linux Mint al hebt geïnstalleerd, dat het goed opstart en met internet verbonden is.
Welke tools hebben we nodig voor vibe coding?
Voordat we beginnen, is het handig om te weten wat we gaan installeren en waarom.
| Tool | Functie |
| Linux Mint Xfce | Besturingssysteem |
| Terminal | Opdrachten en agents uitvoeren |
| Git | Versiebeheer voor code |
| Node.js | JavaScript-tools en -applicaties uitvoeren |
| npm | JavaScript-pakketten installeren |
| Codex | AI-programmeeragent |
| Antigravity | Tweede agent, gebruikt als auditor |
| Claude Code | Alternatief voor Codex of tweede betaalde agent |
| GitHub | Coderepository's |
| Railway | Applicaties online publiceren |
| Linear | Project- en taakbeheer |
| Notion | Documentatie en eisen, optioneel |
| LocalWP | Lokale WordPress-ontwikkeling, optioneel |
De meeste tools zijn gratis of hebben een gratis versie. Je kunt met Codex beginnen op het gratis ChatGPT-abonnement, binnen de gebruikslimieten. Een betaald abonnement kan handig zijn als je meer capaciteit nodig hebt.
Mijn systeem: één AI programmeert en een andere controleert
We zouden alles met één AI kunnen doen, maar ik werk liever met twee agents die verschillende rollen vervullen:
- Analist-programmeur: interpreteert de eisen, stelt oplossingen voor, schrijft code en verhelpt fouten.
- Auditor: beoordeelt wijzigingen, zoekt problemen en controleert of de ontwikkelde software aan de eisen voldoet.
Het idee is dat niet dezelfde AI die het werk heeft gedaan het ook beoordeelt. Een goed opgezette, onafhankelijke controle kan fouten vinden die de eerste agent heeft gemist.
In een volgend artikel leg ik het loopsysteem uitgebreid uit.
Welke combinatie van AI-systemen kies je?
Ik zie drie interessante mogelijkheden.
| Betaalde abonnementen | Analist-programmeur | Auditor |
| Betaalde ChatGPT | Codex | Antigravity |
| Betaalde Claude | Claude Code | Antigravity |
| Betaalde ChatGPT + Claude | Claude Code | Codex |
In deze handleiding gebruik ik de eerste combinatie: Codex als analist-programmeur en Antigravity als auditor.
Als je ChatGPT-abonnement 18 euro per maand kost, kun je met de gratis toegang tot Antigravity de code laten controleren zonder een tweede abonnement. Zo:
- Betaal je niet voor twee AI-diensten.
- Gebruik je Codex binnen de limieten van je ChatGPT-abonnement.
- Laat je de code nakijken door een model uit een andere familie.
Antigravity biedt gratis toegang onder de geldende voorwaarden en gebruikslimieten, die kunnen veranderen, let op.
Als je alleen voor Claude betaalt, kun je Codex vervangen door Claude Code en Antigravity als auditor behouden.
En als je zowel ChatGPT als Claude betaalt, stel ik voor Claude Code als analist-programmeur en Codex als auditor te gebruiken. Die combinatie zou ik kiezen als ik toch al voor beide diensten betaalde, maar dan betaal je wel voor twee tools.
Goed, nu we alle tools hebben opgesomd, beginnen we met de eigenlijke handleiding.
Stap 1. Linux Mint bijwerken
We openen de terminal van Linux Mint.
In Xfce kan dat vanuit het applicatiemenu of met de sneltoets Ctrl + Alt + T.
Eerst werken we de pakketbronnen bij en installeren we de beschikbare updates:
sudo apt update && sudo apt upgrade -y
Linux vraagt om het wachtwoord van de gebruiker.
Als de update belangrijke systeemonderdelen of een nieuwe kernelversie installeert, is het verstandig opnieuw op te starten voordat je verdergaat.
Nu installeren we de basisgereedschappen:
sudo apt install -y curl git ca-certificates
Dan hebben we:
- curl, om bestanden van internet te downloaden.
- git, om repository's te beheren.
- ca-certificates, om certificaten van HTTPS-verbindingen te controleren.
We controleren of Git werkt:
git –version
Dit zou het versienummer moeten tonen.
Een opmerking over de terminal en zijn cache
Tijdens de installatie kan het gebeuren dat een tool correct is geïnstalleerd, maar de terminal toch zegt dat de opdracht niet bestaat.
Vaak komt dat doordat het installatieprogramma een nieuwe map aan de omgevingsvariabele PATH heeft toegevoegd, terwijl de terminal die wijziging nog niet heeft geladen.
Daarom is het aan te raden de terminal helemaal te sluiten (niet alleen het tabblad) en een nieuwe te openen na de installatie van tools die de omgeving aanpassen.
We starten een nieuwe terminalsessie om de bijgewerkte configuratie te laden.
Stap 2. Node.js en npm installeren
Met Node.js kun je JavaScript buiten de browser uitvoeren.
We gebruiken het voor webprojecten, automatisering en ontwikkeltools. npm is de pakketbeheerder ervan, waarmee je gemakkelijk afhankelijkheden installeert.
Om de handleiding eenvoudig te houden, gebruiken we de LTS-versie van Node.js via NodeSource.
Eerst downloaden we het configuratiescript:
curl -fsSL https://deb.nodesource.com/setup_lts.x -o nodesource_setup.sh
We voeren het uit:
sudo -E bash nodesource_setup.sh
En installeren Node.js:
sudo apt install -y nodejs
Nu controleren we beide programma's:
node –version
npm –version
Als beide hun versienummer tonen, kunnen we verder.
We kunnen ook het gedownloade script verwijderen:
rm nodesource_setup.sh
Node.js is niet nodig om de zelfstandige versies van Codex of Claude Code te draaien, maar we gebruiken het wel voor webprojecten en andere tools.
Stap 3. Codex installeren, onze analist-programmeur
Codex is de programmeeragent van OpenAI. Hij kan bestanden doorzoeken, code aanpassen, opdrachten uitvoeren, fouten analyseren en ons helpen complete projecten vanuit de terminal te beheren.
Voor de installatie gebruiken we het officiële installatieprogramma:
curl -fsSL https://chatgpt.com/codex/install.sh | sh
Of via npm:
npm install -g @openai/codex
We hoeven niet beide opdrachten uit te voeren. In deze handleiding gebruiken we het zelfstandige installatieprogramma.
Daarna controleren we:
codex –version
Als de terminal de opdracht niet herkent, sluiten we hem helemaal af en openen we een nieuwe.
Codex verbinden met ChatGPT
Om Codex te starten typen we:
codex
De eerste keer biedt het de beschikbare aanmeldmethoden aan.
We kiezen aanmelden met ChatGPT, openen de browser wanneer daarom wordt gevraagd en geven toestemming voor de verbinding.
Na het aanmelden kunnen we de opdrachten bekijken.
Bijvoorbeeld om een van de beschikbare modellen en redeneerniveaus te kiezen:
/model
Om de sessiestatus te bekijken:
/status
En om de machtigingen van de agent te controleren:
/permissions
Welke modellen beschikbaar zijn, hangt af van ons account en de Codex-versie.
Belangrijk: ik raad af de agent vanaf het begin onbeperkte rechten te geven. Ook als we speciaal hiervoor een nieuwe schijf gebruiken, kunnen we handelingen die belangrijke bestanden, externe opdrachten of gekoppelde diensten betreffen beter handmatig beoordelen.
Alternatief: Claude Code installeren
Als je Claude Code als analist-programmeur hebt gekozen, verloopt de procedure ongeveer hetzelfde.
We installeren de officiële client:
curl -fsSL https://claude.ai/install.sh | bash
We controleren:
claude –version
En voeren de diagnose uit:
claude doctor
Om de agent te starten:
claude
We doorlopen het aanmeldproces.
Voor de rest van de handleiding gebruik ik Codex, maar de ontwikkelinstructies zijn ook aan te passen aan Claude Code.
Stap 4. Antigravity installeren als auditor
Nu installeren we onze tweede agent.
Antigravity heeft een grafische toepassing, maar hier hebben we de CLI-versie nodig, die we rechtstreeks vanuit de terminal kunnen uitvoeren.
Het officiële installatieprogramma voor Linux is:
curl -fsSL https://antigravity.google/cli/install.sh | bash
De standaardlocatie van het uitvoerbare bestand is:
~/.local/bin/agy
We controleren:
~/.local/bin/agy –version
Als het direct met agy werkt, hoeven we verder niets te doen.
Anders kunnen we de map toevoegen aan PATH:
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
We sluiten de terminal helemaal af en openen een nieuwe.
We controleren:
agy –version
Aanmelden bij Antigravity
We openen:
agy
Bij de eerste start doorlopen we de configuratiewizard.
We kunnen de weergavevoorkeuren instellen en ons aanmelden via de methoden die voor ons account beschikbaar zijn.
We moeten ook bevestigen dat we de projectmap vertrouwen voordat de agent toegang tot de bestanden mag krijgen.
Voorlopig hoeven we geen automatische audit in te stellen. Dat doen we zodra we ons eerste project hebben.
Belangrijk: agents kunnen dezelfde repository gebruiken, maar het is niet verstandig als ze tegelijkertijd dezelfde bestanden aanpassen. Daarom ontwikkelt de ene agent en beoordeelt de andere het werk.
Stap 5. GitHub CLI installeren
We hebben Git al, maar moeten onze computer nog met GitHub verbinden.
Met Git beheer je lokaal de versies. GitHub is bedoeld om externe repository's te hosten, samen te werken en de code buiten de computer te bewaren.
We installeren GitHub CLI:
sudo apt install -y gh
We controleren:
gh –version
Onze identiteit instellen in Git
Voordat we commits maken, geven we aan welke naam en welk e-mailadres aan onze wijzigingen worden gekoppeld:
git config –global user.name "Tu Nombre"
git config –global user.email "tu-correo@example.com"
We vervangen de voorbeeldwaarden door onze eigen gegevens.
We kunnen de configuratie controleren:
git config –global –list
Aanmelden bij GitHub
We voeren uit:
gh auth login
We selecteren GitHub.com en volgen de instructies.
Als we voor aanmelden via de browser kiezen, laat GitHub CLI een tijdelijke code zien en een adres waar we die moeten invoeren.
Zodra de toegang is toegestaan:
gh auth status
Hiermee controleren we of GitHub CLI ons account herkent.
Voor professionele projecten gebruiken we privé-repository's en zetten we geen wachtwoorden of API-sleutels in de code..
Stap 6. Railway installeren
Railway is een platform om apps te publiceren zonder zelf een server te hoeven configureren en beheren.
In deze handleiding gebruiken we het eerst om een kleine HTML-website te publiceren en te controleren of onze workflow werkt.
Railway is niet verplicht voor vibe coding. We zouden ook een andere aanbieder zoals Vercel kunnen gebruiken, maar Railway helpt ons na te gaan of we onze code van een lokale repository naar een online bereikbare applicatie kunnen brengen.
We installeren Railway CLI:
bash <(curl -fsSL https://railway.com/install.sh)
Installatie via npm is ook mogelijk:
npm install -g @railway/cli
We kiezen slechts een van beide methoden.
We controleren:
railway –version
Railway verbinden
Eerst maken we een account aan via:
Daarna typen we in de terminal:
railway login
De browser wordt geopend om de toegang goed te keuren.
We kunnen controleren welk account verbonden is:
railway whoami
Railway heeft mogelijkheden met beperkte tegoeden en betaalde abonnementen. Voordat we diensten publiceren die permanent moeten blijven draaien, is het verstandig de voorwaarden en verbruikslimieten te controleren.
Stap 7. Linear en eventueel Notion instellen
Voor deze twee tools installeren we geen desktopapplicaties.
Linear wordt onze projectmanager. Hier organiseren we functies, bugs, taken en versies.
We kunnen een account aanmaken op:
Later richten we een project in en bepalen we hoe we het met onze ontwikkelworkflow verbinden.
Notion is optioneel. We kunnen het gebruiken voor het schrijven van requirementsdocumenten of PRD's (Product Requirements Document).).
Bij eenvoudige projecten kunnen we de eisen ook opslaan in een Markdown-bestand binnen de Git-repository zelf. Documentatie is nuttig als ze helpt bij beslissingen en verduidelijkt wat we moeten ontwikkelen. We hoeven niet voor iedere kleine wijziging uitgebreide documenten te maken.
Voorlopig volstaat het om de accounts aan te maken en te controleren dat we toegang hebben.
Stap 8. De privacy van AI-tools controleren
Voordat we agents gebruiken voor echte code van klanten, is het de moeite waard de privacyinstellingen te bekijken.
In ChatGPT kunnen we naar Instellingen > Gegevensbeheer gaan en de optie uitschakelen waarmee onze gesprekken worden gebruikt om de modellen te verbeteren. We moeten ook de specifieke instellingen voor Codex controleren.
Bij Claude en Antigravity bekijken we de opties voor datagebruik ter verbetering van producten, bewaartermijnen, telemetrie en commerciële berichten. Elke dienst heeft zijn eigen voorwaarden.
En er is iets wat we goed moeten begrijpen: het uitschakelen van training betekent niet dat de code niet meer naar de AI-aanbieder wordt verzonden. Modellen die in de cloud worden gehost, moeten de benodigde informatie ontvangen om hun werk te doen.
Daarom houden we ons aan een paar basisregels:
- Deel geen privésleutels, wachtwoorden of tokens.
- Houd inloggegevens buiten GitHub.
- Beperk de machtigingen van elke tool tot wat nodig is.
Stap 9. Alles controleren voordat we beginnen
Nu sluiten we de terminal helemaal af en openen we hem opnieuw.
We controleren de ontwikkeltools:
git –version
node –version
npm –version
GitHub en Railway:
gh –version
railway –version
En onze AI-agents:
codex –version
agy –version
Als we Claude Code gebruiken:
claude –version
claude doctor
We controleren ook of we nog aangemeld zijn:
gh auth status
railway whoami
De versiecontroles vertellen ons of de programma's zijn geïnstalleerd. De aanmeldcontroles laten zien of we toegang hebben tot onze accounts.
Maar we moeten nog een complete functionele test uitvoeren.
Stap 10. Onze eerste ontwikkelmap aanmaken
We maken een kleine website om te controleren of alles werkt.
In Linux Mint kunnen we een map op het bureaublad aanmaken en daar meteen een terminal in openen.
We kunnen het ook met opdrachten doen:
mkdir -p ~/Proyectos/mi-primera-app
cd ~/Proyectos/mi-primera-app
Het is belangrijk Codex vanuit de projectmap te starten. Zo kan de agent met de benodigde bestanden werken zonder onze hele computer te hoeven doorzoeken.
Stap 11. Codex vragen een applicatie te programmeren
We starten:
codex
Nu vragen we om een eenvoudige applicatie:
Ik wil een applicatie in HTML, CSS en JavaScript waarmee ik een takenlijst kan maken, taken als voltooid kan markeren en kan verwijderen. Bewaar de taken in de lokale opslag van de browser, zodat ze bij het vernieuwen van de pagina niet verdwijnen. De interface moet responsive zijn en op mobiel en desktop werken. Gebruik afzonderlijke bestanden en vermijd onnodige frameworks of afhankelijkheden. Maak ook een README met instructies om de app uit te voeren.
Codex analyseert de eisen en maakt de bijbehorende bestanden aan.
Als het klaar is, bekijken we wat er is gemaakt. Bij zo'n project kan dat iets heel eenvoudigs zijn:
mi-primera-app/
├── index.html
├── style.css
├── script.js
└── README.md
Als er geen afhankelijkheden of buildstappen zijn, kunnen we het HTML-bestand rechtstreeks in de browser openen.
Voor een test die meer op een echte server lijkt, kunnen we ook Python gebruiken, dat meestal al in Linux Mint aanwezig is:
python3 -m http.server 8000
Daarna openen we:
http://localhost:8000
We controleren of we taken kunnen aanmaken, afronden en verwijderen en of ze na het vernieuwen van de pagina bewaard blijven.
Om de server te stoppen drukken we in de terminal op Ctrl + C.
Stap 12. Een repository op GitHub aanmaken
Zodra de app lokaal werkt, slaan we de eerste versie op.
We kunnen Codex vragen Git en een .gitignore-bestand klaar te zetten, maar de aanmaak van de repository moet onze goedkeuring krijgen.
We kunnen het ook handmatig als volgt doen:
Vanuit de projectmap:
git init
We voegen de bestanden toe:
git add .
We maken de eerste commit:
git commit -m "Primera version funcional"
En maken een privé-repository op GitHub aan:
gh repo create mi-primera-app –private –source=. –remote=origin –push
Deze opdracht maakt de externe repository aan, verbindt onze map en uploadt de eerste versie.
Vanaf nu bewaart GitHub de geschiedenis van de wijzigingen die we publiceren.
Voordat we echte code uploaden, moeten we altijd controleren of .gitignore gevoelige bestanden, inloggegevens en mappen uitsluit die niet in versiebeheer horen.
Stap 13. Het project op Railway publiceren
Nu gaan we controleren of GitHub als bron voor onze uitgerolde code kan dienen.
We gaan zelf naar het Railway-dashboard en maken een nieuw project aan.
We selecteren Deploy from GitHub Repo, geven GitHub toestemming als we dat nog niet hebben gedaan en kiezen onze repository.
Railway beschikt over een buildsysteem met de naam Railpack, dat statische HTML-projecten herkent.
Daarom hoeven we Codex niet te vragen een Node.js-server of een package.json te genereren alleen maar om onze kleine applicatie te publiceren..
Railway analyseert de repository en bereidt de uitrol voor.
Als dat mislukt, bekijken we de logboeken en bestandsstructuur voordat we iets wijzigen.
Zodra de app is uitgerold, gaan we naar de netwerkinstellingen van de dienst en genereren we een openbaar domein.
We openen het adres in de browser.
Als onze takenlijst online werkt, hebben we onze eerste uitrol voltooid.
Stap 14. Controleren of GitHub en Railway verbonden zijn
Er ontbreekt nog een belangrijke test.
Dat de app op Railway verschijnt, bewijst dat we een versie hebben uitgerold, maar we willen ook zeker weten dat latere wijzigingen die naar GitHub worden gestuurd correct worden gepubliceerd..
We gaan terug naar het project en starten Codex:
codex
We vragen:
Voeg aan de applicatie een knop toe waarmee alle voltooide taken worden verwijderd. Behoud het huidige ontwerp, controleer of het werkt en voer geen uitrol uit. Ik wil de wijzigingen controleren voordat ik ze in Git opsla.
We testen de nieuwe functie lokaal.
Wanneer we hebben gecontroleerd dat alles werkt, slaan we de wijzigingen op:
git add .
git commit -m "Añadir limpieza de tareas completadas"
git push
Als automatische uitrol in Railway is ingeschakeld voor deze branch, detecteert het platform de nieuwe commit en maakt het een nieuwe versie.
We wachten tot de uitrol correct is afgerond en openen de openbare applicatie opnieuw.
Als de nieuwe knop zichtbaar is en werkt, hebben we de hele keten geverifieerd: Linux > Codex > Git > GitHub > Railway.
Dat is veel betrouwbaarder dan Codex simpelweg de openbare URL geven en vragen of alles verbonden is.
Stap 15. Antigravity om een audit vragen
We hebben nu een applicatie ontwikkeld en gepubliceerd.
Nu komt bij deze test onze tweede agent in beeld. We doen het hier zo om te testen of alles werkt, maar ik zeg er alvast bij dat bij echte software, in plaats van testsoftware, de audit plaatsvindt VOORDAT er iets wordt ontwikkeld of naar productie wordt geüpload.
We openen een terminal in de projectmap en voeren uit:
agy
We geven concrete instructies:
Treed op als onafhankelijke technische auditor. Controleer deze applicatie en ga na of ze aan de functionele eisen voldoet. Zoek naar JavaScript-fouten, beveiligingsproblemen, toegankelijkheidsproblemen, problemen met het responsive ontwerp en mogelijke fouten in de lokale opslag. Onderzoek ook de repositorystructuur en of die correct is voorbereid voor Railway. Wijzig geen bestanden. Lever een rapport, gerangschikt naar ernst, waarin je aangeeft hoe ieder probleem kan worden gereproduceerd en welke oplossing je voorstelt.
De auditor moet de code beoordelen en, waar mogelijk, zelf controles uitvoeren. We willen niet dat hij alleen zegt dat alles prima is.
Als hij fouten vindt, gaan we terug naar Codex, geven we het rapport en vragen we om de nodige correcties.
Daarna herhalen we de tests en de audit.
Bij kleine projecten kan één controle voldoende zijn. Bij belangrijkere projecten hebben we geautomatiseerde tests en aanvullende controles nodig.
Dit staat bekend als de Loop-methode..
Als we Claude Code en Codex gebruiken
Het werkt op dezelfde manier. Claude Code ontwikkelt het project en Codex controleert de wijzigingen.
We kunnen Codex starten en de interactieve beoordelingsfunctie gebruiken:
/review
Welke tool we precies gebruiken, is niet het belangrijkste. Het belangrijkste is dat we de verantwoordelijkheden scheiden en dat de gevonden problemen echt zijn.
Nu is onze computer klaar om webapplicaties te maken met frameworks zoals Astro of zelfs volledig vanaf nul.
In dit artikel leg ik bijvoorbeeld uit hoe je de website voor je bedrijf maakt met dit systeem. Of zelfs je complete digitale kanaal voor heel weinig geld..
Als je goed kijkt, gebruiken die websites geen database, dus hebben we er in deze handleiding ook geen geïnstalleerd. Als dat wel nodig is, kunnen we Convex of Supabase gebruiken. Daarover schrijf ik een ander artikel.
Misschien wil je dit systeem ook gebruiken om te ontwikkelen voor WordPress, zoals ik. Lees dan verder.
Stap 16 (optioneel). LocalWP installeren en voorbereiden op WordPress
Tot slot installeren we LocalWP.
Met deze tool kunnen we WordPress op onze eigen computer draaien, inclusief webserver, PHP en database, zonder de wijzigingen op een echte website te hoeven publiceren.
We downloaden het officiële Linux-installatieprogramma vanaf:
We kiezen de .deb-versie die geschikt is voor Ubuntu, Debian en Linux Mint.
Na het downloaden kunnen we het bestand openen met het grafische installatieprogramma of in de downloadmap deze opdracht uitvoeren:
sudo apt install ./nombre-del-archivo.deb
We vervangen de voorbeeldbestandsnaam door de naam van het werkelijk gedownloade bestand.
Daarna starten we LocalWP vanuit het applicatiemenu en controleren we of het goed opent.
Verderop in dit artikel leg ik uit Hoe je een WordPress-website kloont met Local WP en hier hoe je het onder Windows optimaliseert..
In een volgend artikel over vibe coding voor WordPress bespreken we het systeem en de workflow die ik gebruik:
- Hoe ik functies definieer.
- Hoe ik beslis tussen een plugin en alle code in de bestanden van het child theme.
- Welke bestanden ik onder versiebeheer plaats.
- Wat buiten GitHub-versiebeheer blijft.
- Hoe ik test.
- Hoe je publiceert op hosting die geen Railway is (in mijn geval Webempresa).
Zoals je ziet, is er genoeg om over te praten.
Voordat ik afsluit, wil ik nog een tool noemen die in bepaalde situaties nuttig kan zijn.
Optioneel: spraakdictatie gebruiken om instructies te geven
Een voordeel van werken met AI-agents is dat we functies in gewone taal kunnen uitleggen. Daarom kunnen dicteertools interessant zijn.
Zelf gebruik ik dit wanneer de functie die ik wil beschrijven uitgebreid is en ik het makkelijker vind om haar mondeling uit te leggen, zodat de transcriptie rechtstreeks in de terminal verschijnt.
Whisper en tools die het lokaal draaien maken deze vorm van dicteren mogelijk. Op Linux kun je bijvoorbeeld kiezen voor OpenWhispr of Handy..
Het is geen onmisbaar hulpmiddel. Je kunt het later toevoegen als het je nuttig lijkt.
Conclusie: onze computer is klaar voor vibe coding
Hiermee hebben we het eerste deel van het proces afgerond.
Linux Mint werkt, Git en Node.js zijn geïnstalleerd, twee AI-agents zijn beschikbaar, GitHub is verbonden en Railway staat klaar om applicaties te publiceren.
En het belangrijkste: we hebben een complete proef uitgevoerd. We maakten code met een AI, controleerden die, uploadden haar naar GitHub, publiceerden haar op Railway en lieten een tweede agent het resultaat beoordelen.
Dat is de basis van het systeem dat ik wil gebruiken.
Ik wil traditionele programmering niet vervangen door een reeks geïmproviseerde instructies. Het idee is om met kunstmatige intelligentie sneller te ontwikkelen en tegelijk grip te houden op de eisen, versies en resultaten.
In het volgende artikel gaan we naar het interessantste deel: hoe je met Linear een vibe-codingproject organiseert, eisen vastlegt, taken verdeelt tussen analist-programmeur en auditor en een herhaalbare ontwikkelmethode opzet..
Daarna passen we dezelfde aanpak toe op WordPress met LocalWP, GitHub en Webempresa.
En dan gaan we ontdekken hoe ver we kunnen komen met AI-ontwikkeling zonder elke regel code zelf te hoeven schrijven.
Veelgestelde vragen
Kan ik aan vibe coding doen zonder te kunnen programmeren?
Ja, maar dat betekent niet dat we niet hoeven te begrijpen hoe applicaties werken. Weten wat een repository is, hoe je een functie test en hoe je een wijziging terugdraait, blijft heel nuttig.
Waarom twee AI-systemen gebruiken?
Omdat ik het schrijven van code gescheiden houd van de controle ervan. Een tweede agent kan problemen ontdekken die de eerste niet heeft gezien. Toch vervangen automatische controles noch tests noch menselijk toezicht.
Moet ik verplicht voor ChatGPT en Claude betalen?
Nee. In deze handleiding gebruik ik Codex met een ChatGPT-abonnement en Antigravity als auditor via de gratis toegang, die aan limieten onderhevig is. Als je alleen voor Claude betaalt, kun je Claude Code als ontwikkelaar gebruiken.
Waarom gebruiken we Git en GitHub?
Git houdt wijzigingen bij en kan eerdere versies herstellen. GitHub host de externe repository en maakt het makkelijker om die aan andere diensten te koppelen, zoals Railway.
Moet ik Node.js installeren?
Nee. Voor een eenvoudige HTML-app of de zelfstandige versies van Codex en Claude Code heb je Node.js niet nodig. Voor veel webprojecten en tools uit het JavaScript-ecosysteem wel.
Is Railway gratis?
Railway biedt beperkte gratis opties en tegoeden, maar geen onbeperkte middelen. We moeten het verbruik in de gaten houden en de prijzen controleren voordat we apps permanent online laten draaien.
Kan ik deze methode gebruiken voor WordPress-ontwikkeling?
Ja. In de volgende handleiding behandelen we dat met LocalWP. Het verschil is dat WordPress een database en mediabestanden heeft die we apart van de met Git beheerde code moeten behandelen.
Kan ik dit allemaal op Windows of Mac doen?
Ja. Windows ondersteunt eigen tools en WSL2. Op macOS lijkt de terminalworkflow op die van Linux. In deze handleiding gebruiken we Linux Mint omdat ik voor die omgeving heb gekozen en daarop mijn tests ga uitvoeren.
Waarom Linux op een externe SSD installeren?
Omdat je daarmee een aparte ontwikkelomgeving hebt zonder het hoofdsysteem te wijzigen. Je kunt je tools en bestanden meenemen naar een andere compatibele computer. Maak wel back-ups en beschouw de externe SSD niet als absolute bescherming.

Geef een reactie