Stuur de AI gerichter aan met je eigen LOVABLE.md regels

Gelukkig heeft het platform een ingebouwde functionaliteit om dit permanent op te lossen: het projectspecifieke regelbestand, beter bekend als LOVABLE.md. Op lvbl.nl zien we dat veel gebruikers deze optie links laten liggen, terwijl het een van de krachtigste knoppen is om controle te houden over je applicatie. Als onafhankelijk platform voor de Nederlandse Lovable-community leggen we je uit hoe je deze functie praktisch inzet.

Herhaling voorkomen met vaste projectinstructies

Wanneer je aan een serieuzere app werkt, wil je niet in elke prompt hoeven herhalen dat je TypeScript gebruikt, dat knoppen de stijl van je bestaande design system moeten volgen, of dat foute invoer altijd in het Nederlands afgehandeld moet worden. Zonder centrale instructies neemt de AI bij elke nieuwe chatfase zelf beslissingen op basis van algemene patronen. Een regelbestand in de root van je repository werkt als een permanent handboek voor de AI. Elke keer dat Lovable een opdracht verwerkt, leest het eerst deze basisinstructies door.

Het bestand maakt gebruik van gewone Markdown-opmaak en staat direct in de bestandsstructuur van je project. Je kunt het bestand rechtstreeks aanmaken via de code-editor in Lovable of toevoegen via je gekoppelde GitHub-repository. Zodra het bestand aanwezig is, neemt de AI de daarin beschreven regels automatisch mee bij het genereren en aanpassen van onderdelen.

Wat zet je precies in het regelbestand

Een valkuil is om een compleet handboek van tien pagina's in het bestand te proppen. AI-modellen werken het beste met korte, heldere en direct toepasbare afspraken. Verdeel je bestand daarom in vier duidelijke categorieën: de gebruikte technologieën, UI- en ontwerpafspraken, backend- en dataconventies en taalvoorkeuren.

Onder de technologieën geef je aan welke frameworks bepalend zijn. Denk aan een instructie als: gebruik uitsluitend Tailwind CSS voor styling en importeer pictogrammen altijd uit Lucide React. Zo voorkom je dat de AI ineens inline CSS-stijlen introduceert of een tweede iconenbibliotheek installeert die je bundel onnodig zwaar maakt.

Bij de ontwerpafspraken leg je vast hoe componenten worden opgebouwd. Schrijf bijvoorbeeld voor dat herbruikbare elementen zoals knoppen, invoervelden en modale vensters altijd uit de bestaande UI-map gehaald moeten worden in plaats van dat er bij elke pagina een nieuw element wordt geschreven. Dit houdt de codebase opgeruimd en voorkomt visuele afwijkingen tussen pagina's.

Structureer je instructies met duidelijke grenzen

De effectiviteit van je regels valt of staat met de manier waarop je ze formuleert. Vage instructies zoals schrijf schone code of maak het gebruiksvriendelijk hebben weinig effect. De AI heeft duidelijke kaders nodig. Geef daarom niet alleen aan wat er wel moet gebeuren, maar stel ook expliciete grenzen aan wat absoluut niet mag.

Een sterk voorbeeld van een negatieve regel is: maak nooit rechtstreeks verbinding met externe API's vanaf de frontend, maar gebruik altijd Supabase Edge Functions voor het ophalen van externe data. Met één zo'n regel voorkom je dat de AI per ongeluk geheime API-sleutels blootlegt in je client-code. Je bouwt op die manier vanaf het eerste moment een veiliger fundament.

Ook op het gebied van taal en lokalisatie levert het bestand direct winst op. Als je bouwt voor een Nederlandse doelgroep, kun je vastleggen dat alle systeemmeldingen, foutboodschappen en knopteksten in natuurlijk Nederlands geschreven moeten worden. Ook kun je afdwingen dat datums altijd volgens de Nederlandse standaard worden weergegeven.

Een praktisch voorbeeld voor je dagelijkse workflow

Stel dat je bouwt aan een urenregistratie-app. Een eenvoudig LOVABLE.md bestand voor dit project kan er als volgt uitzien:

Het bestand begint met de algemene uitgangspunten: deze app is gebouwd met React, Tailwind CSS en Supabase. Vervolgens definieer je de UI-regels: gebruik voor alle formulieren de afhandeling via React Hook Form met Zod-validatie. Hergebruik bestaande dialogen en maak geen losse pop-ups. Tot slot leg je de datastructuur vast: alle bedragen worden opgeslagen als centen in de database om afrondingsfouten te voorkomen.

Wanneer je nu in de chat vraagt: voeg een pagina toe waar gebruikers een factuur kunnen aanmaken, zal Lovable automatisch een formulier bouwen met Zod-validatie, de bestaande UI-componenten gebruiken en de bedragen correct omrekenen. Je hoeft deze details niet meer in je chatvenster mee te geven.

Houd het bestand compact en actueel

Omdat het regelbestand meegaat in je versiebeheer, groeit het mee met je project. Verandert je architectuur? Dan pas je het bestand aan. Stap je over van client-side datastorage naar een database, dan schrap je de oude regels en voeg je de nieuwe toe. De AI past zich bij de eerstvolgende prompt direct aan de nieuwe situatie aan.

Let er wel op dat je het bestand compact houdt. Een richtlijn is om het bestand onder de honderd regels te houden. Als het bestand te lang wordt, kan het model bepaalde instructies over het hoofd zien of minder gewicht toekennen aan cruciale beveiligingsregels. Verwijder regels die vanzelfsprekend zijn geworden en focus op de uitzonderingen en specifieke eisen van jouw app.

Door een kwartier te investeren in een goed LOVABLE.md bestand verander je de AI van een losbandige assistent in een gedisciplineerde ontwikkelaar die precies bouwt volgens jouw standaarden. Het is de snelste manier om een professionele en consistente codebase neer te zetten.