Een SaaS bouwen met een coding agent: een praktische workflow

Begin met een observeerbaar resultaat

Een coding agent kan een overtuigend scherm produceren nog voordat je hebt besloten wat het scherm moet doen. Begin met een klein gebruikersresultaat: een ingelogde gebruiker bewerkt zijn profiel, slaat het op en ziet de opgeslagen naam na herladen. Dat geeft zowel de implementatie als de review een concreet doel.

Neem het huidige gedrag, het gewenste gedrag en de belangrijke faalgevallen op in de brief. Noem de bestaande module die het werk bezit. Een verzoek om profielbewerking toe te voegen moet naar de authenticatielaag wijzen, in plaats van de agent een tweede gebruikersstore te laten verzinnen. Houd credentials uit prompts en screenshots — een geplakte apps/web/.env.local of sessiecookie wordt deel van het gespreksverslag.

Een werkbare brief leest zo: “Laat in het accountscherm een ingelogde gebruiker zijn weergavenaam bewerken en die na herladen zien. De auth-module bezit het gebruikersrecord; voeg geen tabel toe. Een lege naam, of een request dat het record van een andere gebruiker noemt, moet worden afgewezen. Bewijs het met pnpm test en één handmatige save op een smalle breedte.” Vijf zinnen, en het meeste giswerk is weg.

• Het gebruikerszichtbare resultaat, zo geformuleerd dat je het in de draaiende app kunt checken.
• Het bestand of de module die het gedrag vandaag bezit — en de gebieden die onaangeroerd moeten blijven.
• Minstens één faalgeval: een ongeauthenticeerde poging, ongeldige invoer of een herhaalde request.
• De check die het bewijst — een testcommando, een fixture of een expliciete handmatige doorloop.

Laat de repository zichzelf uitleggen

Documenteer hoe je de applicatie draait, welke controles deterministisch zijn en waar eigenaarschap wordt afgedwongen. In supastack legt AGENTS.md de workspacegrens vast en .ai/ de beslissingen op bestandsniveau. Deze notities zijn het nuttigst als ze de volgende bijdrager — mens of agent — vertellen waarom een implementatie bestaat, niet alleen welke bestanden veranderden. De agent-setupgids laat zien hoe de kit dat materiaal beschikbaar stelt, en de lokale setupgids is de doorloop die de agent echt zal volgen.

Vraag de agent de relevante code te lezen vóór het bewerken. Een beperkte wijziging heeft meestal de interface, zijn servergrens en de tests rond die grens nodig. De hele repository laden is minder nuttig dan de paar plekken begrijpen die bepalen of het nieuwe gedrag correct is: de ownership-check, het schema, de entitlement.

Wanneer een feature configuratie raakt, noem dan het bestand in plaats van het over te typen — “voeg de key toe aan apps/web/.env.local” houdt secrets op schijf. Dezelfde discipline geldt voor providerdashboards: beschrijf de bestemming, plak de credential niet.

Werk in kleine, reviewbare wijzigingen

Agents zijn het betrouwbaarst wanneer een wijziging één eigenaar en één checkbaar resultaat heeft. “Voeg profielbewerking toe” is reviewbaar; “verbeter de accountomgeving” nodigt uit tot refactors waar niemand om vroeg. Als een feature uiteenvalt in een schemawijziging, een servergrens en een scherm, draai ze dan als aparte briefs die elk de build groen laten.

Commit of checkpoint vóór elke agentrun. Een schone baseline maakt van een slechte output een verwijderde diff in plaats van een archeologische exercitie, en het geeft je review een stabiel voor-en-na om te vergelijken.

Review één complete wijziging per keer

Schrijf een acceptatiecheck vóór het wijzigen van gedrag. Voor profielbewerking dek je een geldige update en een ongeautoriseerde poging. Bouw de kleinste implementatie die aan die gevallen voldoet en inspecteer daarna de echte interactie met realistische tekst en een smal viewport.

Review de diff net zo goed als het resultaat. Let op gedupliceerde bedrijfslogica, brede exception-handling en nieuwe dependencies die een probleem oplossen dat de bestaande stack al dekt. Draai de controles van het project en leg vast wat ze aantonen. Een browserfixture kan een formulierinteractie verifiëren; het kan niet vaststellen dat de productiedatabase of een externe provider correct is geconfigureerd.

Elk commando beantwoordt een andere vraag. pnpm test oefent gedrag tegen deterministische fake- en lokale adapters, pnpm check dekt lint, typechecking en formatting, en pnpm build brengt de integratiefouten aan de oppervlakte die alleen tijdens bundelen verschijnen. Samen zijn ze een vloer voor review — de launchchecklist dekt wat er in de echte omgeving nog bewezen moet worden.

pnpm test
pnpm check
pnpm build

Wanneer de agent het mis heeft

Wanneer een resultaat verkeerd is, weersta dan de neiging om vervolgprompts op een slechte diff te stapelen. Keer terug naar het checkpoint, verscherp de brief rond wat verkeerd begrepen is — meestal een onuitgesproken constraint of een ontbrekende eigenaar — en draai opnieuw. Elke retry moet nieuwe informatie meedragen, niet alleen nieuwe urgentie.

Aanhoudend falen betekent meestal dat de brief context veronderstelt die de repository niet bevat. Als de agent een tweede plek blijft verzinnen om gebruikers op te slaan, is de fix een zin in AGENTS.md over waar identiteit leeft, geen strengere toon. Werk het document bij en probeer de taak dan opnieuw — de agentsgids is waar de kit deze workflow bewaart.

Veelgestelde vragen over agentworkflows

Een paar vragen komen altijd op zodra een founder een coding agent met echt productwerk gaat vertrouwen.

• Kan een coding agent zelfstandig een hele SaaS bouwen? — Hij kan de zichtbare delen snel in elkaar zetten, maar de duurzame delen — autorisatie, billing-lifecycle, data-isolatie — hebben nog steeds een brief, een check en een review nodig. Snelheid zonder die loop wordt ombouwwerk.
• Hoe groot moet een taak voor een coding agent zijn? — Klein genoeg dat je het resultaat binnen minuten in de draaiende app kunt verifiëren: één gebruikerszichtbaar resultaat, één bezittende module, één acceptatiecheck.
• Wat hoort nooit in een prompt? — Providersecrets, sessiecookies, de inhoud van .env.local en klantdata. Noem bestanden en laat de tool ze lokaal lezen in plaats van waarden naar een chatlog te kopiëren.
• Verandert door een agent geschreven code hoe ik review? — De review verschuift van typen naar lezen: inspecteer de diff op gedupliceerde logica, brede exception-handling en dependencies die een probleem oplossen dat de stack al dekt.
• Welke tests tellen het meest voor agentoutput? — Degenen die eigenaarschap en faalgedrag vastpinnen: ongeautoriseerde requests, ongeldige invoer en herhaalde submissions, niet alleen het happy path dat de demo toont.