De waarheid over "Vibe Coding" / "Prompt engineering"

Projectcriteria

Ik stelde duidelijke criteria op voor het project:

• Bouw een complete front-end en back-end applicatie
• Implementeer persistente opslag
• Dockeriseer de applicatie
• Integreer een headless CMS (Prismic)
• Maak het deploybaar

Daarnaast wilde ik dit benaderen als een "blinde" ontwikkelaar, waarbij ik AI een redelijke kans gaf om problemen op te lossen voordat ik ingreep. Ik zou alleen handmatig problemen oplossen na 45 minuten of langer vast te zitten.

Initiële Setup

Ik begon met het aanmaken van een project met front-end en back-end mappen. In de front-end voerde ik $ npx create-nextapp uit, en in de back-end gebruikte ik $ npx express-generator om de basis te leggen.

Deze commando's zijn gemakkelijk te vinden op de homepages van Vercel en Express, dus ik beschouw dit niet als "ontwikkelingswerk". Toch had ik ook kunnen testen of AI deze commando's zelfstandig kon genereren.

Vervolgens vroeg ik Claude om de dockerisatie en Redis persistente opslag op te zetten: I have a #backend and #frontend folder that I need dockerized and I want to implement persistent storage for my backend

Dit commando leverde direct een grotendeels werkende oplossing op. Hoewel het aanvankelijk wat problemen had met environment variables, leidde het prompten met de foutmeldingen tot een oplossing binnen 1-2 iteraties.

Dit genereerde een redis-service, frontend-service, backend-service en redis-storage, wat een solide basis vormde voor het project.

Binnen 15 minuten hadden we een robuuste applicatiebasis gevestigd.

Setup en Initiële Uitdagingen

Ik maakte een Prismic-project aan gebaseerd op een NextJS template, dat ik in mijn front-end map integreerde. Dit leverde een basispagina, standaard slices en wat demo-content op.

Ik wilde meer dynamische en complexe pagina's maken met geneste data en dynamische entiteiten, waarmee gebruikers nieuwe entries en geneste elementen kunnen toevoegen. Specifiek maakte ik een pagina voor kalender-evenementen, met lijsten met datum, naam, locatie en vereiste velden.

Ik prompte Claude: please implement a new customType called "Events" which allows me in Prismic to add event entries, it must have a Name, Location and Date fields, additionally a requirements textarea field

Dit onthulde de eerste uitdaging: Prismic vereist een specifieke structuur voor het implementeren van dynamische en geneste data, met bepaalde limieten en restricties.

Claude genereerde een onjuiste definitie en kon het probleem niet direct oplossen. Het raakte vast in een lus, afwisselend "main" toevoegend en verwijderend, en vervolgens in een cyclus van UIDs en andere willekeurige velden in de definitie nadat ik het vroeg om de standaardpagina te bestuderen voor een oplossing.

Zelfs na het tonen van een werkend voorbeeld uit de Prismic-documentatie, kon Claude het probleem niet oplossen via prompts alleen.

45 minuten na het aanpakken van dit ene probleem, greep ik handmatig in en schreef de definitie zelf, waarbij ik de geneste structuur vereenvoudigde.

Custom Slice Implementatie

In dit stadium hadden we geen custom slices als basis voor AI om mee te werken. Echter, ik wist dat we er enkele nodig hadden om dynamische contentweergave op een herbruikbare manier mogelijk te maken.

Ik prompte Claude: I need a custom slice called: "Event Details" which needs an image on the left, title, description and CTA on the right, please make it responsive, implement using scss module files

Aangezien ik het ontwerp nog niet had afgerond, liet ik het werken met het bestaande template-project.

Probleem nummer 2) De slice werd gemaakt in een oudere indeling en geplaatst in de verkeerde map. Hoewel de code bruikbaar was, verwachtte ik mijn nieuwe slice te zien bij het herstarten van Prismic's slicemachine.

Er verscheen niets, dus prompte ik Claude: I'm using Prismic version x, we created this slice but I'm not seeing it in my slice machine. Het verontschuldigde zich voor de misverstand en begon de structuur aan te passen om de juiste slice-definitie en schema-gebruik te waarborgen.

Het verscheen nog steeds niet - Na verschillende prompts om te onderzoeken waarom de slice niet verscheen, verontschuldigde het zich opnieuw en herschreef de slice volledig. Deze keer verscheen het in mijn slicemachine na het implementeren van het laatste ontbrekende stuk: het exporteren van de slice-component.

Probleem nummer 3) - Mijn pagina kon de slice niet zien. Toen ik Claude vroeg waarom: I'm seeing my new slice in the slicemachine, but my page cannot see and use the slice, ging het verder met het updaten van mijn customTypes om de slices te kunnen gebruiken, terwijl het tegelijkertijd extra wijzigingen aanbracht aan mijn pagina.

Als ik nieuw was geweest in Prismic, had ik misschien aangenomen dat deze extra wijzigingen, zoals Adding a UUID aan de pagina, nodig waren voor slice-weergave.

Dit benadrukt een kritiek probleem met "Vibe coding": je moet de onderliggende oplossingen en geschreven code begrijpen om deze over-reaches en hallucinaties van Claude en vergelijkbare AI's te kunnen identificeren.

Ik verwierp de voorgestelde wijziging en prompte Claude: please only focus on implementing our custom slice and no other change.

Content Migratie Uitdagingen

Ik wilde het systeem vullen met ongeveer 24 evenement-items om een nieuwe evenementenlijstpagina en evenementendetailpagina te maken.

Prismic biedt een handige oplossing genaamd content migraties, die typisch 10-15 minuten kost om op te zetten voor eenvoudige data-transformaties en imports. (Complexere data-migraties vereisen natuurlijk meer tijd.)

Ik vroeg Claude om twee taken uit te voeren:

• please generate for me 24 event mock items based on the slice and customTypes of #sliceName and #customTypeName
• please generate for me a Prismic content migration for version x.y.z so we can take our 24 event mock items in #mocks so get us 24 event entities for #customType

Het genereren van de mock-content verliep soepel de eerste keer, waarbij het zelfs een lokale afbeelding uit de public map incorporeerde.

Het maken van de migratie bleek een uitdagend proces te zijn.

Prismic vereist deze basisstructuur:

import * as prismic from "@prismicio/client";
const repositoryName = "PROJECT_NAME"
const token = "API_KEY";

// Create the Prismic client
const writeClient = prismic.createWriteClient(repositoryName, {
       writeToken: token,
});

// Create a migration
const migration = prismic.createMigration();
// Create the entity
migration.createDocument(
      {
       // The document
      }, 'Document_Name'
);

await writeClient.migrate(migration, {
       reporter: (event) => console.info(event),
});

Claude kon deze aanvraag niet vervullen Prismic probeerde de client SDK en API te gebruiken om de migratie te laten werken, maar kon het niet voltooien zonder fouten.

Zonder een bestaand migratiescript in het project als basis, en werkend met enigszins verouderde documentatie, miste het belangrijke criteria, wat succesvolle implementatie verhinderde.

Na 45 minuten greep ik in, schreef de basis en gebruikte Claude's gegenereerde mock-data om de migratie te maken. Binnen 10 minuten had ik mijn content naar Prismic gepusht en zichtbaar in mijn project.

Initiële Design Pogingen

Ik deelde verschillende Prismic-ontwerpen met Claude/Cursor, promptend: I want my website to look and feel like these example images, please use MUI components and create a MUI theme that matches the style in the attached images

Dit leidde tot het herschrijven van alle pagina's, het maken van initiële componenten en het updaten van de layout met een theme en theme-creation methode.

Aangezien het gegenereerde ontwerp nog steeds afweek van mijn gepresenteerde voorbeelden, maakte ik de prompts specifieker: in the attached images we see the "card" has a white background, a rough border-radius of 30px, the colors are actually # # # and # for primary, secondary and complimentary colors, the buttons need x,y,z

Ongeveer 70% van de prompt werd correct toegepast, met enkele overgeslagen gebieden. Ik prompte opnieuw voor de ontbrekende elementen: we're missing the styling for textareas, radio buttons etc.

Problemen die ik tegenkwam:

• Claude paste Tailwind classes toe ondanks dat we Tailwind niet in het project gebruikten
• Claude gebruikte style/CSS variabelen die niet bestonden
• Claude gebruikte herhaaldelijk dezelfde kleuren in plaats van variabelen te maken

API Implementatie en Uitdagingen

Ik ging de back-end map in en prompte Claude: create me a few express APIs that will take advantage of our Redis persistent storage, we're building a "team manager" for our football team, we need to be able to add, edit and remove players, here is the field structure I want to use {....}, please also consider authentication and validation of the APIs and implement API routes in nextJS #frontend folder as a secure pass-through for the calls to not expose our tokens

Het begon deze bestanden te maken en te schrijven, waarbij het NPM packages voorstelde om te installeren en goede auth-opties en implementaties aanbood.

Het eerste probleem - Het mapste URLs incorrect over verschillende systemen en endpoints, waarbij het backend:8000 en localhost:8000 op verschillende plaatsen door elkaar haalde.

Ik vroeg Claude om dit op te lossen met een utility, wat het creëerde, maar ik vond het niet de optimale oplossing. In plaats van .env variabelen te gebruiken, hardcodeerde het waarden. Echter, blind gaand, corrigeerde ik dit niet omdat het technisch werkte.

Het tweede probleem - Docker stopte met mounten en bouwen. Tijdens dit proces brak Claude het express-proces, wat verschillende prompts vereiste om de gecreëerde problemen aan te pakken: references utilities it never actually created or mismatch syntax and imports.

Het laatste probleem - Hoewel het de scaffolding implementeerde voor alle API-lagen, vereiste het registratie bij externe oAuth-services in plaats van een in-house implementatie te bieden.

Verschillende extra prompts waren nodig om de implementatie werkbaar te maken. Het eindresultaat leek relatief veilig en bruikbaar.

De valkuil waar ik in viel - Met gedetailleerde kennis van wat nodig was, wat te vangen en wat acceptabel was, kon ik problemen identificeren. Iemand nieuw in oAuth zou dit bewustzijn misschien niet hebben, wat mogelijk beveiligingskwetsbaarheden in hun projecten zou blootleggen.

Ik vertrouw Claude niet om een oplossing te bieden voor iets zo gevoeligs als authenticatie op dit niveau. Zijn initiële afhankelijkheid van externe providers zou zijn manier kunnen zijn om ontwikkelaars die hier blind in gaan te beschermen.

Ik besteedde extra tijd aan het updaten van de front-end met nieuwe schermen om deze endpoints te consumeren en de team-manager te bouwen. De design system updates werden goed toegepast, hoewel het af en toe design/layout variaties introduceerde die correctie vereisten.

Na 6 uur: Naarmate meer componenten op hun plaats vielen, versnelde de voortgang. Echter, ik liep tegen terugkerende problemen aan bij het maken van nieuwe complexe customTypes en Slices in Prismic voor andere pagina's. Nieuwe criteria en enigszins verhoogde complexiteit leidden vaak tot loops met Claude.

Laatste Uitdagingen

Ik wijdde de laatste 2 uur aan opschoning, het verfijnen van de visuele aspecten van bestaande features om een presentabel eindproduct te creëren.

Ik prompte Claude met verschillende commando's:

• please make all pages mobile friendly
• please fix bugs x,y,z etc
• please create for me a not-found and error.js app files in our style
• please document the project both inline and in readme files

Hier begonnen de zaken steeds frustrerender te worden. Mobiele stijlaanpassingen braken desktop layouts. Bugfixes creëerden soms visuele problemen of konden problemen niet oplossen zonder handmatige interventie (vooral met Prismic). De not-found en error.js bestanden hadden stijlproblemen. Het creëerde af en toe nieuwe spookbestanden in plaats van bestaande te repareren of te herschrijven.

Ongeveer 40% van mijn tijd werd besteed aan loops, het afwijzen van wijzigingen en het herhalen van prompts.

De uitgebreide context die nodig was voor "vibe coding" leek Claude te overweldigen, wat resulteerde in significant tijdverlies.

Vibe coding is geen professionele praktijk

Hoewel het een over het algemeen leuke en af en toe frustrerende ervaring was, bleek het een waardevol experiment te zijn.

Mijn belangrijkste inzicht is dat Vibe coding geen plaats heeft in een professionele werkomgeving. Claude kan dienen als een uitstekend "basis"-tool en "sparringpartner", maar het is geen betrouwbare bron van waarheid en standaarden. Als je AI gebruikt om problemen op te lossen zonder diepgaande kennis, kun je gemakkelijk vast komen te zitten in loops en niet verder kunnen.

Wat ik leerde

Als je echt gepassioneerd bent over het oplossen van een probleem, kan AI situaties presenteren die je kennis verdiepen wanneer het op de juiste manier wordt gebruikt. Claude introduceerde regelmatig nieuwe problemen die oplossingen vereisten. Door deze handmatig aan te pakken, krijg je waardevolle inzichten in slechte versus goede praktijken en leer je mogelijk enkele best practices.