Echte WordPress-workflows vibecoden met behulp van de Kinsta API

De sleutel tot een concurrentievoordeel voor moderne WordPress-bureaus ligt niet langer in het schrijven van geweldige code. Bureaus die willen groeien automatiseren repetitieve taken, verlagen de operationele kosten en verkorten de time-to-market, en bieden klanten diensten die beter op maat zijn.

Het integreren van AI-tools in productieprocessen is cruciaal voor bureaus die hun workflows willen automatiseren. In deze context wint Vibe Coding – het nieuwe, door AI aangestuurde ontwikkelingsparadigma – elke dag meer aan populariteit.

Vibe Coding is echter geen makkelijke manier om code te schrijven. Hoewel het klopt dat je geen jarenlange ervaring nodig hebt om te profiteren van Vibe Coding, is een grondig begrip van programmeren en de talen die je gebruikt wel cruciaal. En dat is nog niet alles. Naast traditionele programmeervaardigheden is het nu essentieel om een breder scala aan vaardigheden te ontwikkelen. Weten hoe je de krachtigste AI-aangedreven tools gebruikt, is daar zeker een van.

Ben je klaar om de WordPress-workflows van je bureau met Vibe Coding aan te pakken? Lees dan verder.

Vibe Coding voor WordPress-workflows

Mocht je het nog niet gebruiken: Vibe Coding is een ontwikkelingsmethodiek die gericht is op efficiëntie en het optimaal benutten van middelen. Met Vibe Coding hoef je geen regels code meer te schrijven en ga je naar een hoger abstractieniveau: het niveau van intentie. Jij, als ontwikkelaar, bepaalt de architectuur, de logica en de technische en zakelijke vereisten van een webproject, terwijl je het daadwerkelijke coderen overlaat aan de AI-agent.

Het toepassen van de Vibe-aanpak voor procesautomatisering biedt aanzienlijke voordelen: een kortere time-to-market, democratisering van automatisering, en flexibiliteit en aanpasbaarheid van processen. Deze voordelen zorgen voor meer efficiëntie en schaalbaarheid. Dankzij workflowautomatisering en de introductie van Vibe Coding kunnen WordPress-bureaus makkelijker opschalen, omdat het binnenhalen van nieuwe klanten de werkdruk en overheadkosten niet verhoogt.

Maar voordat je dit gaat vieren, moet je je wel realiseren dat Vibe Coding geen wondermiddel is dat op magische wijze goed gestructureerde, onderhoudbare code oplevert die altijd werkt zoals verwacht. Om dit nieuwe paradigma toe te passen, moet je begrijpen hoe AI-agents werken en moet de architectuur worden ontworpen volgens principes en best practices die ervoor zorgen dat het een betrouwbare aanpak is voor een WordPress-bureau.

In de volgende paragrafen gaan we dieper in op het opzetten van een automatiseringsworkflow voor het opstarten van een nieuw WordPress-project, waarbij we een praktische aanpak volgen op basis van een echt praktijkvoorbeeld: we bekijken hoe je een vooraf geconfigureerde WordPress-siteblauwdruk die op Kinsta wordt gehost, kunt klonen met behulp van GitHub Copilot en de Kinsta API.

Hopelijk helpt dit artikel je om de voordelen van automatisering te begrijpen en hoe je Vibe Coding effectief kunt toepassen in de ontwikkelingsworkflow van je bureau.

Je automatiseringstoolkit

Allereerst heb je een blueprint-site nodig die op Kinsta wordt gehost. Voor dit voorbeeld hebben we een nieuwe site aangemaakt en de thema’s Astra, GeneratePress en Neve geïnstalleerd. We hebben ook Yoast SEO, Starter Templates en andere ondersteunende plugins voor het Astra-thema geïnstalleerd.

Om een kloon van je site te maken, moet je via de Kinsta API toegang krijgen tot je Kinsta-hostingomgeving. Je hebt een Kinsta API-sleutel nodig, je bedrijfs-ID en de ID van de omgeving die je wilt klonen.

Je kunt je bedrijfs-ID vinden in de URL van je MyKinsta-dashboard (de parameter idCompany) en in het gedeelte Site-informatie in MyKinsta, door naar Sites > sitenaam > Info te gaan. In hetzelfde gedeelte vind je ook je omgevings-ID.

Tot slot heb je een IDE nodig om in te werken. Er zijn tal van opties beschikbaar, waaronder veelgebruikte ontwikkelomgevingen zoals Visual Studio Code of Cursor, of AI-gerichte ontwikkelomgevingen zoals Lovable. Je kunt ook een webgebaseerd prototypingplatform gebruiken, zoals Google AI Studio. Dit is ideaal om prompts te testen in een geïsoleerde testomgeving voordat je aan de daadwerkelijke ontwikkeling begint.

Voor dit artikel hebben we Google AI Studio gebruikt voor het bouwen van prompts en GitHub Copilot in Visual Studio Code om de app te bouwen. Dit is waarom deze opzet zo goed werkt:

• Wijdverbreid gebruik: GitHub Copilot is ontzettend populair en vormt voor veel WordPress-bureaus al een essentieel onderdeel van de tech stack. Door het in te zetten voor een project om je workflow te automatiseren, hoeft je team geen tijd te besteden aan het leren kennen van nieuwe ontwikkeltools.
• Directe toegang tot het bestandssysteem: Copilot heeft toegang tot het bestandssysteem van je project. Hierdoor kan het direct de benodigde bestanden aanmaken, inclusief configuratiebestanden, en code schrijven op basis van je verzoeken.
• Agentinstructies: Je kunt algemene regels op projectniveau definiëren via een configuratiebestand met de naam .github/copilot-instructions.md. De agent volgt deze systeeminstructies strikt op, zodat elk bestand aan je projectstandaarden voldoet.

Met deze functies in gedachten gaan we eens kijken hoe GitHub Copilot werkt.

Coden met GitHub Copilot: modi, contextvenster en agentinstructies

Begrijpen hoe GitHub Copilot werkt, is essentieel om het volledige potentieel ervan te benutten. In dit gedeelte maak je kennis met de basisconcepten van Copilot.

Copilot-modi

Er zijn drie verschillende modi die je kunt gebruiken om met GitHub Copilot te communiceren, en elke modus bepaalt het soort gesprek dat je met de chatbot voert.

Plan: In de Plan-modus genereert Copilot een gestructureerd plan, opgedeeld in taken, dat vervolgens wordt overgedragen aan de Agent-modus voor uitvoering (lees hieronder voor meer details). Hierdoor blijft de agent scherp gefocust op de algemene projectdoelen en kan hij de voortgang effectief bijhouden.

In de Plan-modus biedt Copilot een gedetailleerde routekaart, samen met stappen voor de uitvoering en controle. Nadat je het voorstel hebt bekeken, kun je je feedback geven om eventuele aanpassingen door te voeren. Als het plan aansluit bij je behoeften, kun je doorgaan met de uitvoering.

De Plan-modus biedt een uitgebreide set tools die je kunt vinden onder ‘Configure Tools’, direct in het chatvenster.

Agent: In de Agent-modus analyseert Copilot je verzoek, raadpleegt een AI-model over hoe de taak opgelost moet worden, en gaat aan de slag. Zodra de eerste iteratie is voltooid, voert Copilot een controle uit om eventuele fouten op te sporen en bepaalt het welke aanpassingen nodig zijn – of het nu gaat om codewijzigingen, terminalopdrachten of het aanroepen van tools.

Standaard zijn alle beschikbare tools vooraf geselecteerd in de Agent-modus.

Voor meer informatie over agents kun je de officiële VS Code-documentatie raadplegen.

Ask: De Ask-modus is bedoeld om vragen te stellen via het chatvenster. Deze modus wordt aanbevolen voor hulp en algemene vragen over coderen.

Deze drie GitHub Copilot-modi volgen een precieze chronologische en logische volgorde binnen de ontwikkelingscyclus van een applicatie.

Tijdens de eerste fase van de projectarchitectuur helpt de Plan-modus je bij het uitstippelen van de logische stappen van je roadmap – waarbij je bepaalt welke bestanden je moet aanmaken, welke afhankelijkheden je moet installeren en wat de onderliggende architectuur is.

In de daadwerkelijke codeerfase neemt de Agent-modus het aanmaken van bestanden en het genereren van code over. In deze fase wordt de agent autonoom. Jouw rol verschuift naar die van supervisor: je geeft de nodige feedback om knelpunten op te lossen of specifieke delen van de codebase te verfijnen.

De Ask-modus komt weer goed van pas tijdens de debugfase. In deze modus helpt Copilot je twijfels weg te nemen, uitzonderingen af te handelen en je code te documenteren.

Contextvenster

Context is alles wat het model kan zien terwijl het een antwoord verwerkt. Het bevat zaken als je chatgeschiedenis, de bestanden in je lokale of externe werkruimte, systeem- en custom instructies, uitvoer van tools en alle verwijzingen die je expliciet aan de chat toevoegt.

De kwaliteit van de antwoorden hangt af van de context, dus het is cruciaal om het model de juiste, relevante informatie te geven.

Het model heeft geen onbeperkt geheugen. Het contextvenster is de maximale hoeveelheid gegevens – gemeten in tokens (delen van woorden of code) – die een LLM tijdens één verzoek-en-antwoordcyclus tegelijk kan verwerken en ‘in gedachten houden’. In VS Code kun je zien hoeveel tokens er beschikbaar zijn in je contextvenster door op het pictogram rechtsonder naast het chatvenster te klikken.

Het contextvenster vertegenwoordigt het kortetermijngeheugen van het model. Als het overbelast raakt, kan de agent onjuiste of inconsistente gegevens teruggeven. Een nog groter risico is ‘contextvervuiling’, wat gebeurt wanneer het contextvenster vol raakt met irrelevante informatie. In beide gevallen – of het nu door overbelasting of contextvervuiling komt – kan Copilot bugs genereren, hallucineren of niet-geoptimaliseerde code produceren.

Om te voorkomen dat je urenlang bezig bent met het verkrijgen van schone, bugvrije code, is het essentieel om strikte ‘chat-hygiëne’ te hanteren. Je kunt dit doen door tabbladen te sluiten die je niet strikt nodig hebt, door expliciete bestandsverwijzingen te gebruiken om aan de context toe te voegen, je chatgeschiedenis te comprimeren met /compact, of simpelweg een gloednieuw chatvenster te openen om fris te beginnen met een schone context.

Agentinstructies

Agentinstructies leggen de gedragsregels vast die direct invloed hebben op hoe de agent code genereert en verschillende ontwikkelingstaken afhandelt. Dit zorgt ervoor dat je code krijgt die voldoet aan je bedrijfsnormen, uitsluitend geautoriseerde bibliotheken gebruikt of strategische gegevens zoals API-sleutels volledig veilig houdt.

In plaats van deze aanwijzingen handmatig in elke afzonderlijke prompt op te nemen, kun je je custom instructies in een Markdown-bestand specificeren, zodat de antwoorden altijd aansluiten bij je bedrijfs- en projectvereisten. Als je meerdere instructiebestanden hebt, voegt VS Code deze automatisch samen en voegt ze toe aan de chatcontext.

Door nauwkeurige instructies te geven, zal Copilot de parameternamen in API-verzoeken niet door elkaar halen en geen fouten maken bij het verwerken van reacties van een externe dienst.

Maar maak je niet te veel zorgen als dit ingewikkeld lijkt. GitHub Copilot kan namelijk een instructiebestand voor je genereren. Volg simpelweg de stappen die in de officiële documentatie staan beschreven.

Nu we de basis hebben behandeld, leer je in het volgende deel hoe je met GitHub Copilot in VS Code een WordPress-applicatie voor workflowautomatisering kunt vibecoden op basis van de Kinsta API. Tijd om je mouwen op te stropen en aan de slag te gaan.

Een echte WordPress-automatiseringsworkflow vibecoden

Net als bij traditioneel coderen bestaat vibecoden van een geavanceerd project, zoals een WordPress-workflowautomatisering, uit een reeks logische fasen gedurende de hele levenscyclus van de softwareontwikkeling.

Daarom hebben we het proces van het vibecoden van een WordPress-workflowautomatiseringsproject opgesplitst in een reeks logische stappen. Laten we elke fase eens onder de loep nemen en ontdekken wat er verandert wanneer we gaan vibecoden:

Regeldefinitie

In deze fase moet je de algemene richtlijnen definiëren die de kaders vastleggen waarbinnen de agent zal werken. Dit houdt in dat je contextbestanden maakt waarin de tech stack, beveiligingsrichtlijnen en gestructureerde logpatronen worden vastgelegd.

Nadat je een nieuwe projectmap in VS Code hebt aangemaakt, is je eerste stap het openen van de Copilot-chat en het starten van een gesprek met de agent om de projectblauwdruk te definiëren. In deze beginfase werk je vooral in de Ask-modus om de meest geschikte taal voor je project te bepalen en je set instructies voor de agent op te stellen.

Kies de taal voor het project

Als je nog geen keuze hebt gemaakt voor je tech stack, moet je eerste vraag gericht zijn op het achterhalen van de taal die het meest geschikt is voor je project. Voor onze automatiseringsworkflow vroegen we Copilot om de voor- en nadelen van Node.js versus Python op een rijtje te zetten:

Copilot gaf een gedetailleerd overzicht van de voor- en nadelen van beide talen en raadde uiteindelijk Node.js aan:

Instructies voor de architect-agent

Vervolgens vroegen we Copilot hoe we de instructies voor onze agent het beste konden opzetten om hallucinaties te minimaliseren en contextverlies te voorkomen:

Copilot raadde aan om onze agentinstructies over meerdere bestanden te verdelen. Dit zou contextvervuiling voorkomen.

Nu we de aanbeveling van Copilot goed begrepen, gingen we verder met het plannen van de architectuur van onze instructies voor de agent.

We schakelden Copilot over van de Ask-modus naar de Plan-modus en vroegen hem om de bestandsstructuur te schetsen voor ons modulaire instructiesysteem met aparte .md-bestanden:

Copilot begon de stappen uit te stippelen, gaf duidelijke uitleg en stelde een reeks vragen om de regels af te stemmen op de opzet van ons project.

We gaven Copilot de volgende links:

https://api-docs.kinsta.com/api-reference/wordpress-sites/get-list-of-company-sites
https://api-docs.kinsta.com/api-reference/wordpress-sites/get-site-by-id
https://api-docs.kinsta.com/api-reference/wordpress-sites/clone-existing-site

Copilot heeft de uitvoeringsfasen uitgesplitst, de technische redenen voor zijn keuzes uitgelegd en gevraagd of we klaar waren om de wijzigingen door te voeren.

Als je het voorgestelde plan goedkeurt, schakelt Copilot automatisch over van de modus ‘Plan’ naar ‘Agent’. De AI-agent werkt dan rechtstreeks op je lokale bestandssysteem om je agentinstructiebestanden op te bouwen.

De afbeelding hieronder toont een voorbeeld van het bestand copilot-instructions.md:

Iteratieve ontwikkeling

Dit is de fase waarin de code wordt gemaakt. De AI-agent genereert de projectbestanden en scripts, terwijl jij als ontwikkelaar optreedt als architect en regisseur van het proces. Met andere woorden: tijdens deze fase vraag je Copilot om de applicatiestructuur en code te maken, geef je de benodigde input en feedback, evalueer je de beschikbare opties en neem je strategische beslissingen.

De volgende stap in ons project voor het automatiseren van de WordPress-workflow is het initialiseren van het Node.js-project en het definiëren van de bestandsstructuur. We zijn teruggegaan naar de Plan-modus en hebben Copilot gevraagd de volgende stappen te plannen:

Copilot stelde een gedetailleerd plan op, samen met aanvullende informatie over relevante bestanden, uit te voeren controles en te nemen beslissingen. Nadat we het antwoord zorgvuldig hadden bekeken, zijn we begonnen met de uitvoering.

Als dit je veel werk lijkt, maak je dan niet te veel zorgen. Je vraagt Copilot simpelweg om alle benodigde handelingen voor je uit te voeren.

Tijdens het genereren van de bestanden zal Copilot je waarschijnlijk om feedback vragen over punten die verduidelijking behoeven, of om je toestemming voordat het doorgaat met specifieke handelingen. Bekijk de verzoeken en ga verder zoals aangegeven.

Zodra een handeling is voltooid, vertelt Copilot je wat je vervolgens moet doen:

Het gesprek gaat verder met vragen en antwoorden totdat Copilot alle bestanden en code voor je app heeft aangemaakt. In de volgende prompt hebben we Copilot in de Plan-modus gevraagd om een template te genereren voor het bestand .env en de juiste beveiligingscontroles in te stellen (fail-fast).

De volgende afbeelding toont het bestand .env.example dat door Copilot is gegenereerd:

Vervolgens hebben we gevraagd om een index.js-bestand te genereren waarin de volledige logica van de app is verpakt. Voor een geavanceerdere app zou het beter zijn geweest om het script in meerdere bestanden op te splitsen; voor deze app vonden we het echter prettiger om alle logica in één script te houden.

Tijd om ons script uit te voeren. Voordat we begonnen met het klonen van de site, hebben we een .env-bestand aangemaakt op basis van .env.example en de plaatshouders vervangen door de daadwerkelijke waarden voor KINSTA_API_KEY, KINSTA_COMPANY_ID en SOURCE_ENVIRONMENT_ID.

Zodra je klaar bent met het script en de omgevingsvariabelen, open je de VS Code-terminal en typ je npm start.

Als alles naar behoren werkt, zie je een nieuwe site met een algemene naam verschijnen in MyKinsta. Als de prompt een foutmelding geeft, kopieer je simpelweg de foutmelding uit de terminal en plak je die in de Copilot-chat, zodat de assistent deze kan beoordelen, de oorzaak kan achterhalen en passende oplossingen kan voorstellen. Mogelijk word je om aanvullende feedback gevraagd.

Op dit punt wil je misschien verbeteringen of nieuwe functies aan je app toevoegen. Voor ons voorbeeld was de generieke sitenaam die door het script werd gegenereerd niet ideaal. Daarom zijn we verder gegaan met de tweede iteratie.

Je applicatie finetunen

Nadat we onze eerste mijlpaal hadden bereikt – het automatisch klonen van een WordPress-site die op Kinsta wordt gehost – vroegen we Copilot om een functie toe te voegen waarmee gebruikers bij uitvoering een eigen sitenaam kunnen opgeven.

Het endpoint /sites/clone van de Kinsta API vereist 3 parameters: company, source_env_id en display_name. Terwijl de eerste twee parameters vastliggen als omgevingsvariabelen in ons .env-bestand, wordt de parameter display_name automatisch gegenereerd door het script.

Als we de gebruikers van de app een fallback-omgevingsvariabele hadden gegeven, zouden ze meer flexibiliteit hebben gehad, terwijl ze nog steeds een extra parameter rechtstreeks via het npm run-commando hadden kunnen doorgeven.

We hebben dit verzoek doorgegeven aan Copilot. De agent heeft de benodigde wijzigingen doorgevoerd door zowel index.js als .env aan te passen en leverde het volgende antwoord:

Tot slot hebben we onze app onder verschillende omstandigheden getest volgens de instructies van Copilot:

• We hebben npm run zonder parameters uitgevoerd.
• We hebben een standaardwaarde ingesteld voor de constante SITE_NAME in het bestand .env en hebben npm run opnieuw uitgevoerd.
• We hebben de parameter SITE_NAME=your-site-name handmatig toegevoegd aan het npm run-commando.
• We hebben het script uitgevoerd met zowel de npm start -- --site-name your-site-name – als de npm start -- --site-name=your-site-name-syntaxis.

In deze cyclus van continue verbetering hebben we ook een functie geïntegreerd om handmatige invoer te normaliseren naar een leesbare weergavenaam, terwijl we nog steeds naadloos slug-achtige waarden zoals my-awesome-wordpress-website accepteren.

Daardoor worden beide volgende commando’s ondersteund:

npm start -- --site-name="My Awesome WordPress Website"
npm start -- --site-name=my-awesome-wordpress-website

Als je tot hier bent gekomen, gefeliciteerd, je hebt zojuist je allereerste app voor workflowautomatisering ge-vibecodet. Controleer nu de plugins, thema’s en de front-end. Als je nog extra functies bedenkt om je script te verbeteren, blijf dan simpelweg bouwen volgens de hierboven beschreven iteratieve aanpak.

Fail-fast-beveiligingscontroles

Voor een kritieke app die gevoelige gegevens gebruikt, zoals je API-sleutels, is het essentieel dat het script strenge controles uitvoert op belangrijke punten in de uitvoering en, in geval van een fout, duidelijke berichten geeft over het soort fout en de uitvoering onmiddellijk stopt (zie de prompt hierboven).

GitHub Copilot heeft ‘fail-fast’ op drie cruciale niveaus doorgevoerd:

Omgevingsvalidatie: Op dit niveau controleert het script of de omgevingsvariabelen aanwezig zijn voordat er API-calls worden gedaan of taken worden uitgevoerd. De volgende afbeelding toont Copilots uitleg over deze controle in de chat:

Je code ziet er natuurlijk misschien anders uit dan in de afbeelding, maar het gaat hier om de aanpak.

API-responsvalidatie: Zodra het klonen begint, controleert het script meteen of er een bewerkings-ID is. Als het script een ongeldige ID ontvangt, stopt het de uitvoering direct, waardoor het niet een half uur lang hoeft te blijven pollen. Hieronder staat de uitleg van Copilot:

Nette foutafhandeling: Elke fout op welk punt dan ook in de keten (validatie, API, polling) komt naar boven, wordt vastgelegd in de logs en stopt de uitvoering van het script netjes.

De fail-fast-aanpak heeft verschillende voordelen, waaronder:

• Geen verspilde API-calls
• Duidelijke foutmeldingen
• Je weet meteen wat er mis is

Voor WordPress-bureaus die een app als deze misschien moeten opschalen en tientallen sites in één keer moeten klonen, zorgt deze aanpak ervoor dat scriptfouten op elk niveau meteen worden opgemerkt, waardoor wordt voorkomen dat ze een kettingreactie veroorzaken met meerdere mislukte bewerkingen.

Als je applicatie echter bedoeld is om op te schalen, wil je een systeem voor unit-tests opzetten.

Unit-testen met Jest

Tijdens de ontwikkelingsfase voerde Copilot zelfstandig verschillende lokale tests uit, waaronder:

• npm run check — die na elke bewerking worden uitgevoerd, om syntaxfouten op te sporen.
• npm start — meerdere keren uitgevoerd om API-reacties te observeren en bugs op te sporen.
• npm start 2>&1 | head -30 — die worden uitgevoerd om gestructureerde loguitvoer in realtime vast te leggen en te lezen.

Hoewel deze tests Copilot hielpen om behoorlijk wat bugs op te sporen, zijn ze vrij eenvoudig en werken ze eigenlijk alleen voor een simpele app. Bovendien hebben ze een groot nadeel: elke keer dat je npm start uitvoert, activeer je een sitekloon. Hierdoor kun je al snel tegen de limiet van je pakket aanlopen, zoals je in de afbeelding hieronder kunt zien:

Bovendien kunnen deze tests niet in een CI/CD-pijplijn worden uitgevoerd zonder je inloggegevens bloot te geven.

Om je applicatie echt te kunnen opschalen, is het essentieel om een robuust framework voor unit-tests te gebruiken, zoals Jest.

In plaats van de servers van Kinsta elke keer met echte verzoeken te belasten, kun je met Jest API-reacties onderscheppen en simuleren (mocking). Zo kun je het gedrag van je software volledig geïsoleerd testen.

Bovendien kun je, omdat de API-calls worden gesimuleerd, met Jest je volledige testsuite uitvoeren binnen automatiseringspijplijnen zoals GitHub Actions, zonder dat je je productie-inloggegevens hoeft te gebruiken.

Om Jest aan de praat te krijgen in je automatiseringsproject, kun je Copilot om stapsgewijze instructies vragen of het zware werk aan hem overlaten.

Zodra Jest is geconfigureerd, kun je al je tests in één keer uitvoeren met npm test. Je kunt ook een specifiek bestand selecteren of tests uitvoeren in de Watch-modus:

Het is ook goed om te weten dat Copilot ingebouwde chatcommando’s heeft die je helpen bij het uitvoeren van unit-tests met Jest:

• /tests genereert een testbestand voor het momenteel geopende bestand. Als je /tests in de chat typt, genereert Copilot Jest-tests voor de functies die het in dat bestand vindt.
• @workspace /tests doet hetzelfde als de vorige opdracht, maar dan met de volledige projectcontext.

Terwijl je met Copilot chat in de Ask-modus, krijg je aanbevelingen en tips die je door je unit-tests loodsen:

Open een nieuwe chat voor deze test en zorg ervoor dat deze is ingesteld op Agent mode. Plak vervolgens het commando dat Copilot eerder heeft gegeven rechtstreeks in de chat:

@workspace /tests for pollUntilComplete and KinstaClient using fetch mocks

Druk op Enter en je ziet de redenering van Copilot en de stapsgewijze handelingen in de chat verschijnen. Het vraagt je elke keer om bevestiging van de uitvoering van het commando wanneer er een test wordt uitgevoerd, totdat elke fout is verholpen.

Documentatie en deployen

Goed gedocumenteerde code is essentieel voor het onderhoud van je codebase. Daarom hebben we Copilot gevraagd om een README.md-bestand aan te maken in de hoofdmap van het project. We hebben het gevraagd om de app te beschrijven, de vereisten te specificeren, uit te leggen hoe je het .env-bestand moet configureren, de verschillende manieren om de applicatie te starten te schetsen en te laten zien hoe je de tests uitvoert.

We zijn een nieuwe chat begonnen in de Ask-modus, hebben de bestanden index.js en package.json aan de context toegevoegd (zie de snelkoppeling #filename van Copilot) en hebben Copilot de volgende prompt gegeven:

Copilot gaf een voorbeeld van een README.md-bestand. We hebben het zorgvuldig bekeken en zijn overgeschakeld naar de Agent-modus om het bestand aan te maken.

De volgende stap was het documenteren van de code zelf. Met het index.js-bestand open, hebben we de volledige code geselecteerd om deze aan de chatcontext toe te voegen en de volgende prompt in de Ask-modus verstuurd:

Copilot heeft het bestand index.js bijgewerkt met inline documentatie zonder de code aan te raken.

Omdat we weer in de Ask-modus zaten, had Copilot geen toestemming om onze bestanden aan te passen. Dus zijn we overgeschakeld naar de Agent-modus en hebben we Copilot gevraagd het bestand index.js bij te werken met de voorgestelde wijzigingen.

De laatste stap is het deployen van de applicatie. Hier zijn twee belangrijke opties:

• Bewaar de applicatie op een lokale computer. Deze oplossing is ideaal als je besluit om het aanmaken van de site handmatig te starten, bijvoorbeeld direct nadat een nieuwe klant een contract heeft getekend.
• Integreer het script in een CI/CD-pijplijn door de code naar een GitHub-repository te pushen. Het aanmaken van de site kan dan handmatig of automatisch worden gestart als reactie op een specifieke gebeurtenis. Deze oplossing is perfect als je met meer gestructureerde en schaalbare workflows werkt.

Als je kiest voor de lokale computer of een utility-server, ben je helemaal klaar. Als je de meer gestructureerde CI/CD-pijplijnroute kiest, kan Copilot je helpen de perfecte prompt te schrijven.

Onze applicatie is klaar. Nu is het opstarten van een nieuw WordPress-project net zo simpel als het uitvoeren van de volgende opdracht:

npm start -- --site-name="My Awesome WordPress Website"

Vibe Coding en automatisering: de toekomst van vooruitstrevende WordPress-bureaus

Vibe Coding is niet zomaar een simpele manier om code te schrijven. Het is een nieuwe ontwikkelingsmethodiek die de rol van de ontwikkelaar helemaal opnieuw definieert – niet langer een programmeur in de traditionele zin, maar de regisseur van een iteratief proces dat verkenning, planning, coderen, verbeteren, testen, debuggen, documenteren en deployen bevat.

Als dit de toekomst is van softwareontwikkeling en de schaalbaarheid van bureaus, dan is samenwerken met een vooruitstrevend hostingplatform essentieel om concurrerend te blijven in het AI-tijdperk. Door de kracht van de Kinsta API te benutten en AI-agenten in te zetten met duidelijke regels, grondige tests en gedegen documentatie, hoeft je bureau niet meer constant brandjes te blussen en kun je op een efficiëntere, voorspelbaardere en schaalbaardere manier gaan werken.

Klaar om je WordPress-workflows te verbeteren en je ontwikkelingstijden drastisch te verkorten? Bekijk onze pakketten of neem contact op met ons verkoopteam en begin vandaag nog met het opzetten van je automatiseringspijplijn.