"Kun je er even één veldje bijzetten?"

Ik zuchtte.

IJsberg: boven water één invoerveld, onder water negen lagen werk van Vue tot Kubernetes
Eén veldje boven water. Negen lagen eronder.

Want één eenvoudig veld op het scherm betekent in de praktijk al snel:

  • Vue-component aanpassen
  • TypeScript-DTO uitbreiden
  • .NET-controller bijwerken
  • validatie toevoegen
  • service aanpassen
  • mapping wijzigen
  • EF-datamodel migreren
  • CI/CD doorlopen
  • Kubernetes-deployment uitrollen

Waarom is één veldje nooit één veldje?

In mijn eigen SaaS-platform Factuur Assist tikt dit hard aan. Met 12 microservices en een Vue-frontend heeft elke service zijn eigen repo, eigen build en eigen Kubernetes-deployment. Vroeger was dit makkelijk twee uur eentonig werk: dezelfde wijziging, negen keer, over negen plekken.

Wat ik veranderde: één workspace, één sessie

Ik gooide mijn workflow om en zette AI-agents in voor de zwaarste, langste taken. Alle solutions staan nu onder één multi-root workspace. Ik stuur één Claude Code-sessie aan die context heeft over het hele ecosysteem, niet over één losse repo.

Een veldje toevoegen, nu

  • Eén scherpe instructie geven.
  • Claude past de relevante bestanden over projectgrenzen heen aan.
  • Ik review de wijzigingen en draai de e2e-test op acceptatie.

Van twee uur ploeteren naar tien minuten reviewen en testen.

Claude verbindt de projecten. Claude houdt de koppelvlakken consistent. Ik blijf verantwoordelijk voor de review.

Multi-root, monorepo of losse sessies?

Een multi-root workspace werkt voor mij, omdat de services los blijven maar Claude het geheel overziet. Een monorepo kan net zo goed, en soms is een losse sessie per repo juist rustiger. Het hangt af van hoe sterk je koppelvlakken zijn.

Multi-root workspace, monorepo of losse sessies per repo: wat werkt voor jou?