Een verstandige ontwikkelaar start geen nieuw project door een gigantisch pull-verzoek te openen. Ze doorlopen brainstormsessies, discussies met teamgenoten, prototyping, diagrammen, voorstellen, ADR’s, MR’s/PR’s en GitOps – met een Review Bot bij elke verandering – en, wanneer de schaal dit vereist, de multi-agent architectuur van Workstation om een geweldig ontwikkelteam samen te stellen dat snel productiewerk levert.
1. Wat ‘wijs’ betekent bij een nieuw project
Wijsheid is goedkoop vroeg leren en zeldzame dure fouten laat maken. De onderstaande volgorde is zo geordend dat elke stap de explosieradius van de volgende verkleint:
Brainstorm → Discuss with workmates → Prototype → Diagram → Propose → ADR
→ Implement in small slices → MR/PR + Review Bot → Merge
→ GitOps promote (dev → staging → prod) → Observe → Iterate
Optional scale-up:
Workstation multi-agent crew (Planner / Builders / Reviewers / Ops)
with human gates on risky actions
2. Brainstormen
Breng 30 tot 90 minuten alleen door voordat u de tijd van anderen doorbrengt:
- Resultaat – wat moet er gelden voor het bedrijf als we klaar zijn?
- Beperkingen — tijd, compliance, platforms, vaardigheden, budget.
- Niet-doelen - wat v1 expliciet niet zal bevatten.
- Risico's — gegevens, beveiliging, prestaties, lock-in, operationele belasting.
- Successtatistieken — kies er twee (bijvoorbeeld latentie + adoptie, of kosten + foutenpercentage).
Schrijf het op onder docs/ideas/. Ongeschreven brainstorms verdampen.
3. Discussies met collega's
Nodig de kleinste bruikbare kring uit: een peer-implementator, een eigenaar van een aangrenzend systeem en beveiliging/SRE wanneer het risico dit rechtvaardigt.
- Timebox (25–45 minuten). Sluit af met beslissingen of open vragen.
- Forceer opties: A versus B versus uitstel – geen vage overeenkomst.
- Wijs een schrijver toe; de notitie zaait het voorstel.
- Beschouw ongemak als risico voor de ADR – geen stille veto’s.
Asynchrone RFC's zijn prima als iemand de lus sluit.
4. Prototyping
Piek wanneer de onzekerheid groot is. Verstandige regels:
- Noem het een piek; stel een kalenderstop in (normaal 1-3 dagen).
- Bewaar het op een wegwerptak of
spikes/– niet polijsten. - Schrijf tien punten op wat je hebt geleerd (vooral mislukkingen).
- Beslis: promoot, herschrijf of laat het achterwege – word nooit ‘stilletjes productief’.
5. Diagrammen
Drie schetsen zijn meestal voldoende:
| Diagram | Antwoorden |
|---|---|
| Context (C4 L1) | Wie praat met wat? Grenzen vertrouwen? |
| Reeks | Gelukkig pad + één mislukkingspad |
| Inzet | Waar het loopt; configuratie en geheimenstroom |
Bewaar Zeemeermin of SVG naast het voorstel. Update wanneer bijwerkingen veranderen.
6. Voorstellen
Houd de RFC kort (1-3 pagina's): probleem, opties (minstens twee), aanbeveling, impact (beveiliging/kosten/ops), uitrol en terugdraaien, open vragen. Wanneer goedgekeurd, zet u de beslissing om in een ADR.
7. ADR — Architectuurbesluitregistraties
# ADR-00XX: Title Status: Proposed | Accepted | Superseded by ADR-00YY Date: YYYY-MM-DD Deciders: @alice @bob ## Context ## Decision ## Consequences ## Alternatives considered
Bewaar ADR's in git (docs/adr/). Koppel ze vanuit PR's. De geschiedenis vervangen in plaats van herschrijven.
8. MR en PR — de leveringseenheid
Dhr (Samenvoegverzoek) en PR (Pull Request) zijn hetzelfde idee: een reviewbare wijzigingsset.
- Klein (bij voorkeur <400 regels met betekenisvolle verschillen); één intentie per verandering.
- Beschrijving: waarom, hoe te testen, risico's, terugdraaien.
- Links: ticket + ADR + schema.
- Vroeg opstellen voor feedback; forceer nooit een samenvoeging rondom rode CI's of zeer ernstige botbevindingen zonder schriftelijke uitzondering.
## Summary ## Test plan - [ ] Unit / contract tests - [ ] Manual path … ## Risk & rollback ## References (ADR, ticket)
9. Review Bot: automatische opmerkingen die de productie beschermen
Een Review Bot is een geautomatiseerde eerste reviewer. Het vervangt mensen niet; het plaatst het saaie en het gevaarlijke op de voorgrond, zodat ontwikkelaars tijd kunnen besteden aan ontwerp en productrisico's.
9.1 Waar het commentaar op moet geven
- Beveiliging: injectie, authz-lacunes, geheime lekkage, onveilige standaardinstellingen
- Correctheid: nulpaden, rassen, gebroken migraties
- Tests: ontbrekende dekking op nieuwe vestigingen
- API/contracten: wijzigingen doorbreken zonder versiehobbels
- Ops: ontbrekende time-outs, onbeperkte nieuwe pogingen, niet-idempotente schrijfbewerkingen
9.2 Hoe het het leven van ontwikkelaars stroomlijnt
- Auteur opent binnen enkele minuten PR → botcommentaar.
- Auteur corrigeert of antwoordt voordat het mensen wordt gevraagd.
- Mens leest botsamenvatting + richt zich op architectuur en explosieradius.
- Minder nit-rondes; minder ontsnapte voetkanonnen in productie.
9.3 Beleid dat de bot nuttig houdt
- Ernst: blocker / must-fix / nit — nits mogen samenvoegingen niet blokkeren.
- Negeer gegenereerde paden; stem maandelijks valse positieven af.
- Vereist menselijke goedkeuring
auth/,infra/, IAM en geldpaden. - Laat de bot nooit de enige beoordelaar zijn van productiekritieke services.
Bekabel SaaS-bots (bijv. CodeRabbit), Cursor Bugbot of een aangepaste Action + LLM via de PR-diff. Laaglint → SAST → LLM voor de sterkste houding.
10. Best practices van GitOps voor kwaliteit op productieniveau
Gewenste staat woont in git. Een reconciler (Argo CD, Flux, etc.) zorgt ervoor dat het cluster matcht. Promotie is een fusie; terugdraaien is terugdraaien.
- Aparte app-code en env-configuratie (of clear
envs/dev|staging|prodoverlays). - Geen ad hoc
kubectl applyprikken als het gelukkige pad - alleen breekglas, gecontroleerd. - Progressieve levering: lagere omgevingen automatisch synchroniseren; gated synchronisatie voor prod.
- Afbeelding verteert over veranderlijke tags in prod.
- Beleid als code (OPA/Kyverno) voor privileges en registers.
- Observeren na synchronisatie; oefen de terugkeer.
Codekwaliteit bestaat niet alleen uit schone functies, maar ook uit schone functies hoe verandering de productie binnendringt.
11. Multi-agent-architectuur voor werkstations – het bouwen van geweldige ontwikkelingsteams
Een enkele wijze ontwikkelaar heeft nog steeds invloed nodig. Dankzij de multi-agentarchitectuur van Workstation (Agentic AI-werkstationpakketten en OpenClaw for Business waar u belichaamde of gespecialiseerde agentploegen nodig heeft) kunt u automatisch een ontwikkelteam samenstellen rond een zakelijke briefing – niet een statisch organigram.
11.1 De compositielus
- Kort — uitkomst voor belanghebbenden, beperkingen, SLA.
- Componeren — wijs rollen toe aan vaardigheden (Planner, Builder, Reviewer, Ops, Compliance).
- Bootstrap — agentruntime + MCP-tools + geheugen + audittrail.
- Uitvoeren — agenten halen werk op, implementeren het tegen Spec/AC, en beoordelen elke stap in een mini-beoordeling.
- Beoordelen tot opschonen – Review Bot + revieweragenten + menselijke poorten.
- Schip — GitOps bevordert de omgeving die er toe doet.
11.2 Rollenkaart (mens + agent)
| Rol | Agent wel | De mens is nog steeds eigenaar |
|---|---|---|
| Planner | Epics, verhalen, AC van Spec | Prioriteits- en reikwijdtebeperkingen |
| Bouwers | Parallelle implementatie, testen | Domeinoordeel over harde randen |
| Recensenten | Naleving van specificaties, beoordeling van bottriage | Architectuur- en productaftekening |
| Op | GitOps-synchronisatie, SLO-kijken, concept terugdraaien | Go-live en incidentcommando |
| HITL-poort | Escaleer risicovolle schrijfbewerkingen/uitgaven | Goedkeuren of afwijzen |
11.3 Waarom dit geweldige teams oplevert
- Specialisatie — elke agent heeft één taak; de kwaliteit neemt toe als de rollen niet vervagen.
- Doorvoer zonder chaos – parallelle bouwers achter één enkele Spec- en Review-bot.
- Gedeelde herinnering aan beslissingen — ADR's + Spec + PR-geschiedenis worden het langetermijngeheugen van het team.
- Dezelfde poorten als mensen – CI, Review Bot, CODEOWNERS, GitOps – agenten omzeilen de productiediscipline niet.
- Zakelijke snelheid – uren om een bekwame ploeg op te zetten in plaats van weken om voor elke piek in te huren.
11.4 Hoe het aansluit op het wijze pad
Brainstormen en discussiëren gebeurt nog steeds met mensen. Prototypes en diagrammen gebeuren nog steeds. De bemanning met meerdere agenten versnelt opstellen van voorstellen, ADR-steigers, implementatiesegmenten, Review Bot-triage en GitOps-promotie – terwijl mensen een oordeel blijven vellen over de uitkomsten en de risico’s. Dat is het werkstationmodel: agentische werkstations en OpenClaw-pakketten geconfigureerd voor uw workflows, niet een chatvenster dat zich voordoet als een team.
12. End-to-end kwaliteitspoorten
Local: pre-commit (fmt, lint, secrets) + unit tests PR open: CI + Review Bot comments PR merge: human approve + branch protection + required checks Main: immutable artifact (image digest) GitOps: update env overlay → sync → verify Agents: Planner/Builder/Reviewer/Ops stay inside the same gates Prod: SLOs + alerts + runbook linked from ADR/PR
13. Starterschecklist
- Creëren
docs/ideas/,docs/architecture/,docs/adr/ - Voeg PR/MR-sjabloon + CODEOWNERS + branchebescherming toe
- Schakel pre-commit + CI-vereiste controles in
- Installeer beoordelingsbot; stem padfilters en ernst af
- Schrijf ADR-0001: “We gebruiken GitOps voor de implementatie”
- Definieer env-promotieregels en een terugdraaispeldag
- Als de levering wordt geschaald: sta op met een multi-agent team van werkstations (planner/bouwers/reviewers/ops) met HITL-poorten
14. Antipatronen
- Gigantische ‘WIP, keur het goed’-PR’s
- Architectuur alleen in Slack – nooit in ADR
- Prototype samengevoegd als product zonder tests
- De Review Bot uitschakelen omdat deze zeurt
- Agenten met schrijftoegang en geen menselijke poort
- Hotfix om buiten GitOps te prikken zonder herstelplan
15. Sluiting
Een verstandige ontwikkelaar behandelt een nieuw project als een reeks leerartefacten – notities, diagrammen, voorstellen, ADR’s – en levert het vervolgens op via kleine MR’s/PR’s die worden bekeken door een Review Bot en gepromoot door GitOps. De multi-agent-architectuur van Workstation breidt die wijsheid uit naar een volledig ontwikkelingsteam: gespecialiseerde agenten, gedeelde specificaties, menselijk oordeel waar het er toe doet, en poorten op productieniveau op elk levenspad. Zo blijft de codekwaliteit geoptimaliseerd voor productie, terwijl het bedrijf nog steeds snel beweegt.
Gepubliceerd door Werkstation.
