Goedkoop bouwen, duur beslissen

Oorspronkelijk in het Engels, lees het origineel.

Dertig jaar lang was het bouwen het schaarse in software. Mensen waren er weinig, dus de backlog was lang. Toen hielden de handen op schaars te zijn: een agent schrijft de feature, een tweede reviewt 'm, en de manager van de servicedesk zet in een lunchpauze een intern tool in elkaar. De wachtrij liep leeg, en de voor de hand liggende conclusie was dat de rem weg was.

Dat is 'ie niet. Hij is verschoven. Weg van engineering, naar de business, naar het trage werk van beslissen wat de moeite waard is om te bouwen en dat precies kunnen zeggen. Bouwen is niet langer de rem. Beslissen wel.

De brug die we al probeerden

We hebben business en engineering eerder overbrugd, en we hebben een naam voor de versie die faalt: de proxy Product Owner. Iemand die eisen de ene kant op doorgeeft en status de andere, zonder mandaat over beide. Scrum.org zet 'm bij de anti-patronen, en terecht: een tussenpersoon die niet mag beslissen is een bottleneck met een nettere titel. Context verwatert bij elke overdracht, en vragen stapelen zich op terwijl niemand in de kamer het antwoord mag geven.

Richt AI op die naad en de verleiding is om de doorgeefrol te automatiseren. Maar een doorgeefluik zonder oordeel wordt geen oordeel door het sneller te maken. Het wordt een bottleneck op machinesnelheid, en zet je er een warme, zelfverzekerde stem bovenop, dan wordt het erger: een tool die gezag uitstraalt dat het niet heeft. Mensen voelen de nep.

Twee banen onder één titel

Het werk op die naad is eigenlijk twee banen. De ene is techniek: een vage intentie omzetten in precieze begrippen, een datamodel, acceptatiecriteria. De andere is oordeel: wat is dit waard, welke afweging accepteer je, wie mag ja zeggen. De eerste is te automatiseren, want het is vaardigheid. De tweede niet, want het is mandaat.

Houd ze uit elkaar en de tool ontwerpt zichzelf. Automatiseer de techniek, laat het oordeel bij de persoon met het mandaat, en bouw de tool zo dat 'ie het verschil kent. Die tool is wat we bouwen. We noemen 'm Clarion.

Wat Clarion moet doen

De meeste eisen gaan over terughoudendheid, niet over slimheid.

• Praat met de business, niet met de developer. De ingang is een gesprek, geen command line.
• Lever een inspecteerbare spec, met herkomst. Elk begrip draagt waar het vandaan komt, zodat bij tegenstrijdige claims de volgorde van vertrouwen zichtbaar is in de tekst in plaats van verstopt in een model. Leesbaar voor een auditor, en per besluit voor een klant.
• Dwing de juiste vraag af. Vraag om een balans en een model geeft er een, maar een fiscale balans en een saldibalans zijn verschillende documenten. Clarion weigert een ongedefinieerd begrip en vraagt welke je bedoelde, voordat er een regel gebouwd is.
• Leg bloot, beslis nooit. Als de spec afwijkt van de strategie of twee stakeholders botsen, zet Clarion de claims naast hun bewijs en legt de keuze bij wie het mandaat heeft. Het draagt die beslissing nooit als de zijne.
• Leg vast wat ertoe doet, niet alles. Een spec die elke uitspraak hamstert, rot tegen de derde maand. Het houdt de begrippen en besluiten die terugkomen, en de afwijkende stem in plaats van een vlak gemiddelde.
• Deterministisch waar het kan, en klaar voor een gereguleerde omgeving. Grijp alleen naar een model waar oordeel nodig is, en houd het audit-spoor bij dat de toezichthouder gaat opvragen.
• Ademt Scrum-principes, negeert het dogma. De increment leidt en bewijs beslist discussies; prioriteiten blijven economisch en worden opnieuw gerangschikt, niet bevroren tot een must-have-lijst waar alles een must is.

Wat het veld al heeft

Houd de markt tegen drie vragen. Richt het zich op de business in plaats van de developer, laat het een open spec achter die je kunt inspecteren, en past het in de enabling-wereld, die waar software een proces dient dat het zelf niet is, wat het in bank, verzekering en logistiek ook gereguleerd maakt?

• Spec-driven frameworks (BMAD, Spec Kit, Kiro, Tessl) zetten de spec vooraan, maar elk ervan is gebouwd voor een developer achter een terminal.
• PM-suites (ChatPRD, de AI in Jira, Confluence, Productboard) richten zich op de business, maar leveren proza.
• Requirements-platforms (Jama, DOORS) zijn inspecteerbaar en klaar voor regulated, maar zwaar en engineer-gericht.
• Decision-engines zijn business-owned en auditeerbaar, maar coderen de regels die een draaiend systeem uitvoert, geen build-time specs.

Geen enkele tool combineert alle drie: een voordeur voor de business, een open spec die iedereen kan inspecteren, en een fit voor de enabling, gereguleerde wereld waar de rem nu zit.

Dit is geen theorie. In de interviews die we deden, binnen en buiten Baseflow, komt steeds hetzelfde patroon boven: ervaren productmensen hebben al met de hand een ruwe versie gebouwd, waarin de AI ze feature voor feature interviewt terwijl een zwerm agents bouwt en een tweede agent reviewt. Het werkt. En elke keer was de dichtstbijzijnde tool een developer-framework, gebogen in de vorm van een Product Owner.

In de open lucht gebouwd

Clarion gaat die lege plek in, en we bouwen 'm in de open lucht. Wat het moet verdienen is vertrouwen, en vertrouwen overleeft geen zwarte doos met een warme stem. Een spec die je niet kunt lezen is het oude proxy-probleem opnieuw: een gezag dat niemand kan inspecteren.

Dus voordat je naar een machine grijpt om op die naad te zitten, schrijf twee lijstjes: wat het moet doen, en wat het nooit mag veinzen. Het tweede lijstje is het moeilijkste, en het telt zwaarder. Een vertaler is eerlijk over wat 'ie niet is: hij heeft geen mandaat, en zegt dat ook. Laat dat lijstje weg, en je hebt geen vertaler gebouwd.

Je hebt net de proxy Product Owner geautomatiseerd.