Slik gjør du PC-en klar for vibe coding – steg for steg

Denne artikkelen er den første i en serie der jeg skal forklare hvordan du kommer i gang med vibe coding helt fra bunnen av.. 

Ikke bare hvordan du ber en kunstig intelligens om å skrive kode, og så er det det. Jeg vil vise hvordan du gjør det skikkelig, med et system som begrenser feil og sikrer en viss kodekvalitet. I tillegg skal vi dokumentere alt, føre oversikt over kodeendringer og ha et testsystem. Akkurat som profesjonelle utviklingsteam, men uten at du trenger å være utvikler.

Første steg er derfor å klargjøre datamaskinen og konfigurere verktøyene vi trenger.

Når vi er ferdige med denne første veiledningen, har vi en PC klar for vibe coding og har publisert en liten testapp ved hjelp av GitHub og Railway.

Hvorfor jeg anbefaler Linux til vibe coding

Du kan fint drive med vibe coding på Windows, Linux eller macOS. De viktigste KI-verktøyene fungerer på alle tre, enten direkte eller gjennom kompatible miljøer.

Jeg kommer til å bruke Linux, fordi det forenkler ganske mye og trolig gir oss færre feil enn Windows. Hvis vi absolutt vil bruke Windows, kan vi bruke WSL2 for å få et Linux-miljø inni Windows 11. Men det legger til enda et konfigurasjonslag som kan gjøre ting vanskeligere når problemer oppstår.

Med Linux jobber vi direkte i miljøet der verktøyene skal kjøres, uten å være avhengige av et ekstra delsystem.

Og macOS? Jeg bruker det ikke selv, så jeg kan ikke si det sikkert. Men ut fra det jeg har sett, suksessen til Mac Mini og det faktum at terminalen og Unix-miljøet gir en arbeidsflyt som ligner veldig på Linux, virker det som et like godt alternativ for utvikling.

Helst en ekstra datamaskin eller en separat disk

Jeg anbefaler også å unngå å eksperimentere med utvikling og KI-agenter på den viktigste arbeids-PC-en, spesielt mens vi fortsatt lærer.

Ikke fordi disse verktøyene er farlige per sé, selv om de også kan være det, men fordi de kan installere avhengigheter, kjøre kommandoer, endre filer og utføre handlinger vi kanskje ikke ønsker.

Derfor foretrekker jeg å holde dette miljøet atskilt fra maskinen jeg bruker til daglig. Du vet jo at jeg heller vil holde ulike bruksområder på PC-en atskilt enn å angre på at jeg ikke gjorde det.

Det ideelle er en ekstra PC, men vi trenger ikke kjøpe en ny maskin. Hvis du ikke har en, er en løsning jeg liker spesielt godt å installere Linux på en ekstern SSD og starte fra den via USB på en kompatibel PC..

Da kan jeg starte Linux når jeg vil utvikle, og bruke Windows som vanlig resten av tiden. Programmer, prosjekter og innstillinger blir liggende på SSD-en, uten at jeg må opprette en Linux-partisjon på hoveddisken.

Men det gir ikke fullstendig isolasjon: Linux kan få tilgang til andre tilkoblede disker hvis vi monterer dem og gir nødvendige tillatelser. Vi må fortsatt passe på hva vi godkjenner at verktøyene kjører.

Jeg kommer til å bruke oppsettet jeg beskriver i artikkelen: Linux Mint Xfce installert på en SATA-SSD i et USB 3.0-kabinett.

Herfra forutsetter jeg at du allerede har installert Linux Mint, at det starter som det skal, og at du er koblet til internett.

Hvilke verktøy trenger vi til vibe coding?

Før vi begynner, er det greit å vite hva vi skal installere, og hvorfor.

Verktøy	Funksjon
Linux Mint Xfce	Operativsystem
Terminal	Kjøre kommandoer og agenter
Git	Versjonskontroll for kode
Node.js	Kjøre JavaScript-verktøy og -apper
npm	Installere JavaScript-pakker
Codex	KI-agent for programmering
Antigravity	En annen agent som brukes som revisor
Claude Code	Alternativ til Codex eller en ekstra betalt agent
GitHub	Kodelagre
Railway	Publisere apper på internett
Linear	Prosjekt- og oppgavehåndtering
Notion	Dokumentasjon og krav, valgfritt
LocalWP	Lokal WordPress-utvikling, valgfritt

De fleste av disse verktøyene er gratis eller har et gratisnivå. Du kan begynne med Codex på gratisnivået til ChatGPT, innenfor bruksgrensene. Et betalt abonnement kan være nyttig hvis du trenger mer kapasitet.

Systemet mitt: Én KI programmerer, en annen kontrollerer

Vi kunne gjort alt med én KI, men jeg foretrekker å jobbe med to agenter med ulike roller:

• Analytiker og utvikler: tolker kravene, foreslår løsninger, skriver kode og retter feil.
• Revisor: gjennomgår endringer, ser etter problemer og sjekker at det vi har utviklet, oppfyller kravene.

Poenget er at den som gjennomgår arbeidet, ikke skal være den samme KI-en som utførte det. En uavhengig og godt gjennomført gjennomgang kan oppdage feil som den første agenten har oversett.

I en senere artikkel skal jeg forklare loop-systemet ordentlig.

Hvilken kombinasjon av KI-verktøy bør vi velge?

Jeg ser tre interessante alternativer.

Betalte abonnementer	Analytiker og utvikler	Revisor
Betalt ChatGPT	Codex	Antigravity
Betalt Claude	Claude Code	Antigravity
Betalt ChatGPT + Claude	Claude Code	Codex

I denne veiledningen bruker jeg det første alternativet: Codex som analytiker og utvikler, og Antigravity som revisor.

Hvis ChatGPT-abonnementet ditt koster 18 € i måneden, kan du bruke gratistilgangen til Antigravity til å gjennomgå koden og slippe et ekstra abonnement. Dermed:

• Du slipper å betale for to KI-tjenester.
• Bruker du Codex innenfor grensene til ChatGPT-abonnementet ditt.
• Lar du en modell fra en annen familie gjennomgå koden.

Antigravity tilbyr gratis tilgang underlagt gjeldende vilkår og kvoter, og de kan endre seg, bare så du vet det. 

Hvis du bare betaler for Claude, kan du erstatte Codex med Claude Code og beholde Antigravity som revisor.

Hvis du betaler for både ChatGPT og Claude, foreslår jeg at du bruker Claude Code som analytiker og utvikler, og Codex som revisor. Det er kombinasjonen jeg ville valgt hvis jeg allerede betalte for begge tjenestene, men du må betale for to verktøy.

Vel, nå har vi gått gjennom verktøyene, så da begynner vi på selve veiledningen.

Trinn 1. Oppdater Linux Mint

Vi åpner terminalen i Linux Mint.

I Xfce finner vi den via programmenyen eller med hurtigtasten Ctrl + Alt + T.

Først oppdaterer vi pakkelisten og installerer tilgjengelige oppdateringer:

sudo apt update && sudo apt upgrade -y

Linux ber oss om brukerpassordet.

Hvis oppdateringen installerer viktige systemkomponenter eller en ny kjerneversjon, bør du starte på nytt før du fortsetter.

Nå installerer vi grunnverktøyene:

sudo apt install -y curl git ca-certificates

Da har vi:

• curl, for å laste ned ressurser fra internett.
• git, for å administrere kodelagre.
• ca-certificates, for å kontrollere sertifikater for HTTPS-tilkoblinger.

Vi sjekker at Git fungerer:

git –version

Den skal vise versjonsnummeret.

En liten detalj om terminalen og hurtigbufferen

Under installasjonen kan det skje at et verktøy installeres riktig, men at terminalen sier at kommandoen ikke finnes.

Ofte skyldes det at installasjonsprogrammet har lagt til en ny mappe i miljøvariabelen PATH, og at terminalen ennå ikke har lastet inn endringen.

Derfor anbefaler jeg å lukke terminalen helt (ikke bare fanen) og åpne en ny etter at du har installert verktøy som endrer miljøet.

Vi starter en ny terminaløkt for å laste inn den oppdaterte konfigurasjonen.

Trinn 2. Installer Node.js og npm

Node.js lar oss kjøre JavaScript utenfor nettleseren.

Vi skal bruke det til webprosjekter, automatisering og utviklingsverktøy. npm er pakkebehandleren som gjør det enklere å installere avhengigheter.

For å gjøre veiledningen enklere bruker vi LTS-versjonen av Node.js gjennom NodeSource.

Først laster vi ned konfigurasjonsskriptet:

curl -fsSL https://deb.nodesource.com/setup_lts.x -o nodesource_setup.sh

Så kjører vi det:

sudo -E bash nodesource_setup.sh

Og installerer Node.js:

sudo apt install -y nodejs

Nå kontrollerer vi begge programmene:

node –version

npm –version

Hvis begge viser hvert sitt versjonsnummer, kan vi fortsette.

Vi kan også slette det nedlastede skriptet:

rm nodesource_setup.sh

Node.js er ikke nødvendig for å kjøre de frittstående versjonene av Codex eller Claude Code, men vi skal bruke det i webprosjekter og andre verktøy.

Trinn 3. Installer Codex, vår analytiker og utvikler

Codex er programmeringsagenten fra OpenAI. Den kan utforske filer, endre kode, kjøre kommandoer, analysere feil og hjelpe oss med hele prosjekter direkte fra terminalen.

Vi bruker den offisielle installasjonsløsningen:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Eller via npm:

npm install -g @openai/codex

Vi trenger ikke kjøre begge kommandoene. I denne veiledningen bruker vi det frittstående installasjonsprogrammet.

Deretter kontrollerer vi:

codex –version

Hvis terminalen ikke finner kommandoen, lukker vi den helt og åpner en ny.

Koble Codex til ChatGPT

For å starte Codex skriver vi:

codex

Første gang får vi valget mellom tilgjengelige autentiseringsmetoder.

Vi velger å logge inn med ChatGPT, åpner nettleseren når vi blir bedt om det, og godkjenner tilkoblingen.

Når vi er inne, kan vi se på kommandoene.

For eksempel, for å velge mellom tilgjengelige modeller og nivåer av resonnering:

/model

For å kontrollere øktstatus:

/status

Og for å gjennomgå tillatelsene agenten får:

/permissions

Tilgjengelige modeller avhenger av kontoen vår og Codex-versjonen.

Viktig: Jeg anbefaler ikke å gi agenten ubegrensede tillatelser fra starten. Selv om vi har satt opp en egen disk til dette, er det best å godkjenne manuelt operasjoner som berører viktige filer, eksterne kommandoer eller tilkoblede tjenester.

Alternativ: Installer Claude Code

Hvis du har valgt Claude Code som analytiker og utvikler, er fremgangsmåten omtrent den samme.

Vi installerer den offisielle klienten:

curl -fsSL https://claude.ai/install.sh | bash

Vi sjekker:

claude –version

Og kjører diagnostikk:

claude doctor

For å starte agenten:

claude

Vi følger innloggingsprosessen.

I resten av veiledningen bruker jeg Codex, men utviklingsinstruksjonene kan tilpasses Claude Code.

Trinn 4. Installer Antigravity som revisor

Nå skal vi installere vår andre agent.

Antigravity har en grafisk app, men her er vi interessert i CLI-versjonen som kan kjøres direkte fra terminalen.

Det offisielle installasjonsprogrammet for Linux er:

curl -fsSL https://antigravity.google/cli/install.sh | bash

Standardplasseringen til den kjørbare filen er:

~/.local/bin/agy

Vi sjekker:

~/.local/bin/agy –version

Hvis den fungerer direkte med agy, trenger vi ikke gjøre noe mer.

Hvis ikke kan vi legge katalogen til i PATH:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc

Vi lukker terminalen helt og åpner en ny.

Vi sjekker:

agy –version

Logg inn i Antigravity

Vi åpner:

agy

Ved første oppstart følger vi konfigurasjonsveiviseren.

Vi kan velge visningsinnstillinger og fullføre innloggingen med metodene som tilbys for kontoen vår.

Vi må også bekrefte at vi stoler på prosjektmappen før vi lar agenten få tilgang til filene.

Foreløpig trenger vi ikke konfigurere automatisk revisjon. Det gjør vi når vi har vårt første prosjekt.

Viktig: Agentene kan dele et kodelager, men det er ikke lurt å la begge endre de samme filene samtidig. Derfor skal den ene utvikle og den andre gjennomgå.

Trinn 5. Installer GitHub CLI

Vi har allerede Git, men må fortsatt koble datamaskinen til GitHub.

Git lar oss holde kontroll på versjoner lokalt. GitHub brukes til å lagre eksterne kodelagre, samarbeide og ta vare på koden utenfor datamaskinen.

Vi installerer GitHub CLI:

sudo apt install -y gh

Vi sjekker:

gh –version

Konfigurer identiteten vår i Git

Før vi lager commits, angir vi navnet og e-postadressen som skal knyttes til endringene:

git config –global user.name "Tu Nombre"

git config –global user.email "tu-correo@example.com"

Vi erstatter eksempelverdiene med våre egne opplysninger.

Vi kan kontrollere konfigurasjonen:

git config –global –list

Logg inn på GitHub

Vi kjører:

gh auth login

Vi velger GitHub.com og følger instruksjonene.

Hvis vi velger innlogging via nettleseren, viser GitHub CLI en midlertidig kode og en adresse der vi skal skrive den inn.

Når tilgangen er godkjent:

gh auth status

Da ser vi om GitHub CLI gjenkjenner kontoen vår.

For profesjonelle prosjekter bruker vi private kodelagre og unngår å legge passord eller API-nøkler inn i koden..

Trinn 6. Installer Railway

Railway er en plattform for å publisere apper uten å måtte konfigurere og administrere vår egen server direkte.

I denne veiledningen skal vi i første omgang bruke den til å publisere en liten HTML-nettside og kontrollere at arbeidsflyten fungerer.

Vi må ikke bruke Railway for å drive med vibe coding. Vi kunne brukt andre leverandører som Vercel, men Railway passer godt til å kontrollere at koden kan gå fra et lokalt kodelager til en app som er tilgjengelig på internett.

Vi installerer Railway CLI:

bash <(curl -fsSL https://railway.com/install.sh)

Det finnes også en installasjonsmetode via npm:

npm install -g @railway/cli

Vi velger bare én av de to metodene.

Vi sjekker:

railway –version

Koble til Railway

Først oppretter vi en konto på:

https://railway.com

Deretter kjører vi i terminalen:

railway login

Nettleseren åpnes slik at vi kan godkjenne tilgangen.

Vi kan kontrollere hvilken konto som er tilkoblet:

railway whoami

Railway tilbyr nivåer med begrensede kreditter og betalte abonnementer. Før vi publiserer tjenester som skal kjøre permanent, bør vi sjekke vilkårene og forbruksgrensene.

Trinn 7. Opprett kontoer i Linear og eventuelt Notion

Vi skal ikke installere skrivebordsapper for disse to verktøyene.

Linear blir prosjektstyringsverktøyet vårt. Her organiserer vi funksjoner, feil, oppgaver og versjoner.

Vi kan opprette en konto på:

https://linear.app

Senere skal vi konfigurere et prosjekt og bestemme hvordan det kobles til utviklingsarbeidsflyten.

Notion er valgfritt. Vi kan bruke det til å skrive kravdokumenter eller PRD (Product Requirements Document).).

I enkle prosjekter kan vi også lagre kravene i en Markdown-fil i selve Git-lageret. Dokumentasjon er nyttig når den gjør det enklere å ta beslutninger og avklare hva som skal utvikles. Vi trenger ikke lage omfattende dokumenter for hver lille endring.

Foreløpig holder det å opprette kontoene og kontrollere at vi kommer inn.

Trinn 8. Gå gjennom personverninnstillingene for KI-verktøyene

Før vi bruker agentene på ekte kundekode, er det verdt å gå gjennom personvernalternativene.

I ChatGPT kan vi gå til Innstillinger > Datakontroller og slå av valget om å bruke samtalene våre til å forbedre modellene. Vi må også se på de spesifikke kontrollene for Codex.

I Claude og Antigravity sjekker vi valgene for bruk av data til produktforbedring, lagringstid, telemetri og markedsføringskommunikasjon. Hver tjeneste har sine egne vilkår.

Og én ting må vi ha klart for oss: å slå av trening betyr ikke at koden slutter å bli sendt til KI-leverandøren. Skybaserte modeller trenger å motta informasjonen de skal bruke for å gjøre jobben sin.

Derfor følger vi noen grunnleggende regler: 

• Ikke del private nøkler, passord eller token.
• Hold innloggingsopplysninger utenfor GitHub.
• Begrens tillatelsene til hvert verktøy til det som er nødvendig.

Trinn 9. Kontroller alt før vi starter

Nå lukker vi terminalen helt og åpner den igjen.

Vi sjekker utviklingsverktøyene:

git –version

node –version

npm –version

GitHub og Railway:

gh –version

railway –version

Og KI-verktøyene våre:

codex –version

agy –version

Hvis vi bruker Claude Code:

claude –version

claude doctor

Vi kontrollerer også at vi fortsatt er innlogget:

gh auth status

railway whoami

Versjonssjekkene forteller oss at programmene er installert. Innloggingssjekkene viser at vi har tilgang til kontoene våre.

Men vi må fortsatt utføre en fullstendig funksjonstest.

Trinn 10. Opprett vår første utviklingsmappe

Vi skal lage en liten nettside for å kontrollere at alt fungerer.

I Linux Mint kan vi opprette en mappe på skrivebordet og åpne en terminal direkte derfra.

En annen mulighet er å gjøre det med kommandoer:

mkdir -p ~/Proyectos/mi-primera-app

cd ~/Proyectos/mi-primera-app

Det er viktig å starte Codex fra prosjektmappen. Da kan agenten arbeide med filene den trenger, uten å måtte utforske hele datamaskinen.

Trinn 11. Be Codex programmere en app

Vi starter:

codex

Nå ber vi den lage en enkel app:

Jeg vil ha en app med HTML, CSS og JavaScript der jeg kan opprette en oppgaveliste, merke oppgaver som fullførte og slette dem. Lagre oppgavene i nettleserens lokale lagring, slik at de ikke forsvinner når siden lastes på nytt. Grensesnittet må være responsivt og fungere på mobil og datamaskin. Bruk separate filer og unngå unødvendige rammeverk og avhengigheter. Lag også en README med instruksjoner for hvordan appen kjøres.

Codex analyserer kravene og oppretter de nødvendige filene.

Når den er ferdig, sjekker vi hva den har laget. I et slikt prosjekt kan resultatet være så enkelt som:

mi-primera-app/

├── index.html

├── style.css

├── script.js

└── README.md

Hvis det ikke finnes avhengigheter eller et byggesteg, kan vi åpne HTML-filen direkte i nettleseren.

For å teste på en måte som ligner mer på en ekte server, kan vi også bruke Python, som vanligvis finnes i Linux Mint:

python3 -m http.server 8000

Deretter åpner vi:

http://localhost:8000

Vi kontrollerer at oppgaver kan opprettes, fullføres og slettes, og at de fortsatt finnes når vi laster siden på nytt.

For å stoppe serveren trykker vi Ctrl + C i terminalen der den kjører.

Trinn 12. Opprett kodelageret på GitHub

Når appen fungerer lokalt, lagrer vi den første versjonen.

Vi kan be Codex klargjøre Git og en .gitignore-fil, men opprettelsen av kodelageret skal godkjennes av oss.

Vi kan også gjøre det manuelt slik:

Fra prosjektmappen:

git init

Vi legger til filene:

git add .

Vi lager den første commiten:

git commit -m "Primera version funcional"

Og vi oppretter et privat kodelager på GitHub:

gh repo create mi-primera-app –private –source=. –remote=origin –push

Denne kommandoen oppretter det eksterne kodelageret, kobler til vår lokale mappe og laster opp den første versjonen.

Fra nå av lagrer GitHub historikken over endringene vi publiserer.

Før vi laster opp ekte kode, må vi alltid kontrollere at .gitignore utelukker sensitive filer, innloggingsopplysninger og mapper som ikke skal lastes opp til versjonskontrollen.

Trinn 13. Publiser prosjektet på Railway

Nå skal vi kontrollere at GitHub kan fungere som kilde til koden vi publiserer.

Vi går manuelt inn i Railway-kontrollpanelet og oppretter et nytt prosjekt.

Vi velger Deploy from GitHub Repo, gir GitHub tilgang hvis vi ikke har gjort det allerede, og velger kodelageret vårt.

Railway har et byggesystem som heter Railpack, og som gjenkjenner statiske HTML-prosjekter.

Dermed trenger vi ikke be Codex om å lage en Node.js-server eller en package.json bare for å publisere den lille appen vår..

Railway analyserer kodelageret og klargjør publiseringen.

Hvis prosessen mislykkes, går vi gjennom loggene og filstrukturen før vi endrer noe.

Når appen er publisert, går vi til tjenestens nettverksinnstillinger og oppretter et offentlig domene.

Vi åpner adressen i nettleseren.

Hvis vi ser oppgavelisten vår fungere på internett, er den første publiseringen fullført.

Trinn 14. Kontroller at GitHub og Railway er koblet sammen

Vi mangler fortsatt en viktig test.

At appen vises på Railway, viser at vi har publisert én versjon. Men vi vil også forsikre oss om at senere endringer som sendes til GitHub, også blir publisert riktig..

Vi går tilbake til prosjektet og åpner Codex:

codex

Vi ber den om følgende:

Legg til en knapp i appen som sletter alle fullførte oppgaver. Behold det nåværende designet, sjekk at funksjonen virker, og ikke publiser noe. Jeg vil gjennomgå endringene før jeg lagrer dem i Git.

Vi tester den nye funksjonen lokalt.

Når vi har bekreftet at den fungerer, lagrer vi endringene:

git add .

git commit -m "Añadir limpieza de tareas completadas"

git push

Hvis vi har aktivert automatisk publisering fra denne grenen i Railway, oppdager Railway den nye commiten og lager en ny versjon.

Vi venter til publiseringen er ferdig uten feil, og åpner den offentlige appen på nytt.

Hvis den nye knappen vises og fungerer, har vi kontrollert hele kjeden: Linux > Codex > Git > GitHub > Railway.

Det er en langt mer pålitelig test enn bare å gi den offentlige URL-en til Codex og spørre om alt er koblet sammen.

Trinn 15. Be Antigravity gjennomføre en revisjon

Nå har vi en app som er utviklet og publisert.

Nå kommer vår andre agent inn i testingen. Her gjør vi det slik for å sjekke at alt fungerer, men jeg kan allerede si at i ekte programvare, ikke testprogramvare, skal revisjonen utføres FØR vi utvikler noe og før vi legger noe i produksjon.

Vi åpner terminalen fra prosjektmappen og kjører:

agy

Vi gir den konkrete instruksjoner:

Oppfør deg som en uavhengig teknisk revisor. Gå gjennom denne appen og kontroller at den oppfyller de funksjonelle kravene. Se etter JavaScript-feil, sikkerhetsproblemer, tilgjengelighetsproblemer, feil i responsivt design og mulige feil i lokal lagring. Undersøk også kodelagerets struktur og om appen er riktig klargjort for Railway. Ikke endre noen filer. Lever en rapport sortert etter alvorlighetsgrad, og forklar hvordan hvert problem kan gjenskapes, og hvilken løsning du foreslår.

Revisoren skal gjennomgå koden og, når det er mulig, kjøre kontroller. Vi vil ikke bare ha en beskjed om at alt er bra.

Hvis den finner feil, går vi tilbake til Codex, gir den rapporten og ber om nødvendige rettelser.

Deretter gjentar vi testene og revisjonen.

I små prosjekter kan én gjennomgang være nok. I viktigere prosjekter trenger vi automatiserte tester og flere kontroller.

Det er dette som kalles Loop-metoden..

Hvis vi bruker Claude Code og Codex

Prinsippet er det samme. Claude Code utvikler prosjektet, og Codex gjennomgår endringene.

Vi kan starte Codex og bruke den interaktive gjennomgangsfunksjonen:

/review

Hvilket verktøy vi bruker, er ikke det viktigste. Det avgjørende er å holde ansvarsområdene atskilt og sørge for at problemene som blir rapportert, er reelle.

Da har vi en maskin som er klar til å lage nettsider og webapper ved hjelp av rammeverk som Astro eller til og med utvikle dem helt fra bunnen av. 

I denne artikkelen forklarer jeg for eksempel hvordan du kan lage nettsiden til bedriften din med dette systemet. Eller til og med hele den digitale kanalen din for svært lite penger..

Som du ser, bruker disse nettsidene ingen database, og derfor har vi ikke installert noen i denne veiledningen. Hvis vi trenger en, kan vi bruke Convex eller Supabase. Det lar jeg bli tema for en annen artikkel.

Det kan også hende du vil bruke systemet til å utvikle for WordPress, slik jeg gjør. Da bør du lese videre.

Trinn 16 (valgfritt). Installer LocalWP og klargjør det for WordPress

Til slutt installerer vi LocalWP.

Med dette verktøyet kan vi kjøre WordPress på vår egen datamaskin, med webserver, PHP og database, uten å måtte publisere endringene på et ekte nettsted.

Vi laster ned det offisielle installasjonsprogrammet for Linux fra:

Releases

Vi velger .deb-versjonen som er kompatibel med Ubuntu, Debian og Linux Mint.

Når den er lastet ned, kan vi åpne den med det grafiske installasjonsprogrammet eller kjøre følgende fra nedlastingsmappen:

sudo apt install ./nombre-del-archivo.deb

Vi erstatter eksempelnavnet med det faktiske filnavnet vi lastet ned.

Deretter starter vi LocalWP fra programmenyen og kontrollerer at det åpnes riktig.

I denne artikkelen forklarer jeg videre Slik kloner du en WordPress-nettside med Local WP og her hvordan du optimaliserer det i Windows..

I en senere artikkel om vibe coding for WordPress skal vi se på systemet og arbeidsflyten jeg bruker:

• Hvordan jeg definerer funksjonene.
• Hvordan jeg avgjør om jeg skal lage en plugin eller legge alt i filene til barnetemaet.
• Hvilke filer jeg versjonskontrollerer.
• Hva som holdes utenfor GitHub-versjonskontrollen.
• Hvordan jeg tester.
• Hvordan det lastes opp til en webvert som ikke er Railway (Webempresa i mitt tilfelle).

Som du ser, er det mye å ta tak i.

Før vi avslutter, vil jeg tipse om et annet verktøy som kan være nyttig i enkelte tilfeller.

Valgfritt: Bruk stemmediktering til å gi instruksjoner

En av fordelene ved å jobbe med KI-agenter er at vi kan beskrive funksjonalitet med vanlig språk. Derfor kan det være nyttig med dikteringsverktøy.

Selv bruker jeg det når funksjonen jeg vil ha, er omfattende, og det er lettere å forklare den muntlig og få transkripsjonen rett inn i terminalen.

Whisper og verktøy som kjører det lokalt, gjør denne typen diktering mulig. På Linux kan du for eksempel bruke OpenWhispr eller Handy..

Dette er ikke et nødvendig verktøy. Du kan legge det til senere hvis du synes det er nyttig.

Konklusjon: Nå er datamaskinen klar for vibe coding

Dermed har vi fullført første del av prosessen.

Vi har Linux Mint oppe og går, installert Git og Node.js, gjort to KI-agenter tilgjengelige, koblet til GitHub og klargjort Railway for publisering av apper.

Og viktigst av alt: Vi har gjennomført en fullstendig test. Vi har laget kode med én KI, kontrollert den, lastet den opp til GitHub, publisert den på Railway og gjennomgått resultatet med en annen agent.

Det er grunnlaget for systemet jeg vil bruke.

Jeg prøver ikke å erstatte tradisjonell programmering med en serie improviserte instruksjoner. Tanken er å bruke kunstig intelligens til å utvikle raskere, men samtidig beholde kontrollen over krav, versjoner og resultater.

I neste artikkel går vi løs på den mest interessante delen: hvordan du organiserer et vibe coding-prosjekt med Linear, definerer krav, fordeler oppgaver mellom utvikleren og den som gjennomgår koden, og får en arbeidsflyt du kan bruke om igjen..

Deretter bruker vi samme system på WordPress med LocalWP, GitHub og Webempresa.

Og det er da vi virkelig begynner å se hvor langt vi kan komme med KI-utvikling uten å måtte skrive hver eneste kodelinje selv.