Agentic engineering: sneller SaaS opleveren

Agentic engineering is onze term voor ervaren engineers die software bouwen met coding agents (AI-codeerassistenten) zoals Claude Code en Codex. De agent leest de codebase, schrijft code, draait tests en herhaalt dat in een lus. De engineer bepaalt wat er gebouwd wordt, hoe het in de architectuur past en of het resultaat goed genoeg is om te mergen.

Dit artikel is voor CTO's, oprichters en engineering leads die willen weten hoe dat werkt bij een echt SaaS-product, waar de code jarenlang onderhouden moet worden. Autocomplete stelt de volgende regel voor. Een coding agent kan een goed afgebakende taak oppakken, een tiental bestanden wijzigen, de testsuite draaien en terugkomen met een pull request. De tijd van engineers verschuift van typen naar specificeren, reviewen en beslissen.

Het verandert ook wat er mis kan gaan. Agents maken snel code die aannemelijk oogt, ook code die aannemelijk oogt en op een subtiele manier fout is. Met de werkwijze hieronder halen we die snelheid en houden we de kwaliteit waar die moet zijn.

Agents doen hun beste werk bij taken met een duidelijk doel, duidelijke grenzen en een manier om het resultaat te controleren. Ze hebben moeite met vage verzoeken die productinzicht vragen of die het hele systeem raken.

• Juiste omvang: één stuk van een feature, één migratie of één integratie-endpoint. Iets wat een ervaren engineer in 15 tot 30 minuten kan reviewen.
• Afgebakend: noem de bestanden, modules of lagen die binnen de scope vallen, en wat niet mag veranderen.
• Controleerbaar: zeg hoe je succes controleert, zoals slagende tests, een schone typecheck of een screenshot van het nieuwe scherm.
• Met context: houd in de repository een AGENTS.md- of CLAUDE.md-bestand bij met conventies, commando's, notities over de architectuur en dingen om te vermijden. Zo begint elke sessie met dezelfde spelregels.

Grote stukken werk deelt een engineer eerst op. Dat opdelen is ontwerpwerk, en dat blijft bij mensen.

Het betrouwbaarste patroon dat we gebruiken, is de specificatie en de tests schrijven voordat de agent de implementatie schrijft. Tests maken van een vaag verzoek een uitvoerbare definitie van klaar. Ze geven de agent ook een lus die hij zelf kan doorlopen: implementeren, tests draaien, repareren, herhalen.

Neem facturatie per gebruikersplek (seat-based billing) in een SaaS-product. De engineer legt de randgevallen vast in tests:

import { describe, expect, it } from "vitest";
import { prorateSeatChange } from "./billing";

describe("prorateSeatChange", () => {
  const period = { start: new Date("2026-09-01"), end: new Date("2026-10-01") };
  const base = { period, seatPriceCents: 3000 };

  it("charges for the remaining days when seats are added mid-period", () => {
    const result = prorateSeatChange({ ...base, from: 5, to: 7, at: new Date("2026-09-16") });
    expect(result.amountCents).toBe(3000);
  });

  it("issues no refund when seats are removed", () => {
    const result = prorateSeatChange({ ...base, from: 7, to: 5, at: new Date("2026-09-16") });
    expect(result.amountCents).toBe(0);
  });

  it("rejects a change outside the billing period", () => {
    expect(() => prorateSeatChange({ ...base, from: 5, to: 6, at: new Date("2026-10-02") })).toThrow(RangeError);
  });
});

Daarna implementeert de agent prorateSeatChange tot de tests slagen. De engineer kijkt de tests zorgvuldig na, omdat een agent die tests moet laten slagen soms de tests zelf aanpast. Onze regel is simpel: agents mogen tests toevoegen, en elke wijziging aan een bestaande test krijgt een expliciete reden in de pull request.

Sneller schrijven helpt alleen als de review het tempo bijhoudt. Code van een agent krijgt dezelfde review als code van een collega, en op sommige plekken een strengere. Waar we op letten:

• Wijzigingen waar niemand om vroeg: opnieuw opgemaakte bestanden, hernoemde variabelen, nieuwe dependencies of refactors buiten de taak.
• Duplicatie: een nieuwe helper, terwijl een bestaande hergebruikt had moeten worden.
• Stille foutafhandeling: brede try/catch-blokken, ingeslikte fouten en fallbacks die fouten verbergen.
• Kwaliteit van tests: tests die de implementatie controleren in plaats van het gedrag, of die juist het onderdeel wegmocken dat getest wordt.
• Prestaties: N+1-query's, ontbrekende indexen en API-aanroepen binnen loops.

Kleine pull requests houden dit behapbaar. We mergen liever vijf kleine, goed gereviewde wijzigingen per dag dan één grote wijziging die niemand helemaal heeft gelezen.

Het patroon is steeds hetzelfde. Agents zijn sterk waar het werk goed gedefinieerd en controleerbaar is. Engineers zijn eigenaar van elk besluit dat duur is om terug te draaien.

Een coding agent voert commando's uit op een machine met toegang tot je code. Behandel hem met dezelfde zorg als elke andere automatisering met schrijfrechten.

• Draai agents in geïsoleerde omgevingen, zoals containers of aparte worktrees, zonder credentials voor productie.
• Houd secrets buiten de repository en buiten de context van de agent. Gebruik tokens met beperkte rechten en een korte levensduur voor alles wat de agent moet aanroepen.
• Beperk welke commando's zonder goedkeuring mogen draaien, vooral alles wat deployt, verwijdert of aan infrastructuur komt.
• Behandel inhoud die de agent leest, zoals issues, webpagina's en README's van dependencies, als onbetrouwbare input die prompt injection kan bevatten.
• Houd dependency scanning, secret scanning en statische analyse in CI, en laat een mens elke merge naar de main branch goedkeuren.

1. 01Voeg een AGENTS.md toe met je conventies, commando's en notities over de architectuur.
2. 02Zorg dat tests, typechecks en linting snel draaien met één commando.
3. 03Kies één soort goed gedefinieerde taken, zoals beheerschermen of integratie-endpoints, en gebruik agents eerst daarvoor.
4. 04Werk bij nieuwe features tests-first, met een duidelijke regel voor wijzigingen aan bestaande tests.
5. 05Houd pull requests klein en review de output van agents regel voor regel.
6. 06Richt sandboxing en rechten voor commando's in voordat je het gebruik uitbreidt.

Zo bouwen onze engineers elke dag software voor klanten. Onze case over een SaaS-scale-up laat het effect op de doorlooptijd zien, en onze aanpak beschrijft hoe we projecten uitvoeren met coding agents.