SYSTEEMONTWERP
FIELD NOTE 02 / 15De prompt is niet het systeem.
Revenue teams blijven AI behandelen als een zeer getalenteerde freelancer zonder manager, werkinstructies of definitie van afgerond werk. Daarna geven ze de prompt de schuld wanneer het werk afdwaalt.
Stop met vastleggen wat AI moet zeggen. Begin met vastleggen hoe het werk moet verlopen.
DEEL DEZE FIELD NOTE
Geef het nuttige signaal door.
We verwarden een instructie met een operationeel model.
De eerste golf AI op het werk leerde iedereen hetzelfde ritueel. Open een leeg vak. Leg uit wat je wilt. Bekijk het antwoord. Voeg nog drie bijvoeglijke naamwoorden toe. Herhaal totdat het werk aannemelijk oogt of de vergadering begint.
Dat is nuttig voor persoonlijke taken. Het is een slechte basis voor commercieel werk dat zich herhaalt over mensen, systemen en klanten heen. Een prompt beschrijft een output. Hij bepaalt zelden wie de beslissing draagt, welke gegevens leidend zijn, wat AI mag veranderen, hoe kwaliteit wordt beoordeeld of wat er gebeurt als de situatie afwijkt van het ideale verloop.
Het resultaat is promptfolklore. Eén collega heeft een magische alinea. Een ander heeft zeventien voorbeelden in een document genaamd FINAL_v6. De organisatie heeft activiteit, maar geen gedeeld systeem dat ze kan onderzoeken of verbeteren.
Een prompt kan het werk starten. Hij kan het werk niet besturen.
De specificatie wordt het waardevolle document.
Softwareteams herontdekken specificaties omdat AI implementatie sneller kan genereren dan mensen hun bedoeling kunnen uitleggen. Bij specificatiegedreven ontwikkeling verschuift het belangrijke werk naar voren: bepaal wat het systeem moet doen, maak daar een plan van, splits het werk op en laat een agent vervolgens binnen expliciete grenzen implementeren.
Dezelfde omkering is belangrijk voor commerciële teams. Als een AI-systeem accountonderzoek voorbereidt, moet de specificatie niet bij de merkstem beginnen. Ze moet beginnen bij de beslissing die het onderzoek ondersteunt. Wat moet de verkoper vóór het gesprek weten? Welke bronnen zijn toegestaan? Hoe recent moet een signaal zijn? Welke claims vereisen een bronvermelding? Wat moet worden weggelaten bij lage zekerheid?
Zodra de specificatie expliciet is, worden prompts implementatiedetails. Modellen kunnen veranderen. Tools kunnen veranderen. De commerciële bedoeling blijft begrijpelijk.
Specificeer het revenue system in vijf delen.
Een bruikbare specificatie is geen vereistendocument van 90 pagina's. Het is een compacte afspraak tussen het bedrijf, de mensen die het werk doen en het systeem dat namens hen handelt.
Doel → Context → Beslissingen → Acties → Bewijs
- 01Doel
Het commerciële resultaat en de gebruikersbeslissing die het systeem moet verbeteren.
- 02Context
Leidende input, actualiteitsregels, uitsluitingen en de benodigde bedrijfskennis.
- 03Beslissingen
Oordelen die het systeem vormt, drempels die het hanteert en gevallen die het moet escaleren.
- 04Acties
Wat het mag opstellen, aanbevelen, bijwerken of verzenden, inclusief goedkeuringen en rechten.
- 05Onderbouwing
Kwaliteitscontroles, resultaatmetingen, logboeken en feedback die de volgende uitvoering verbeteren.
Een specificatie bepaalt de omhulling die variabel modelgedrag betrouwbaar maakt.
Stop met AI te vragen zich als software te gedragen.‘Onderzoek dit account’ is een verzoek. Geen systeem.
Stel dat een salesteam AI-gegenereerde briefings vóór gesprekken wil. Het verzoek klinkt eenvoudig. De verborgen beslissingen zijn dat niet. Welk bedrijf is het account als namen overeenkomen? Telt een vacature als bewijs voor een strategische prioriteit? Hoe oud mag een financieringsaankondiging zijn voordat ze een weetje wordt? Mag het systeem een probleem afleiden uit een technologiekeuze?
Een systeemspecificatie maakt die vragen zichtbaar voordat ze inconsistente output worden. Ze kan twee bronnen voor wezenlijke claims vereisen, waarneming van gevolgtrekking scheiden, signalen ouder dan zes maanden negeren, onzekerheid tonen en goedkeuring vragen voordat iets in het CRM komt.
De gegenereerde briefing kan nog steeds variëren. Het proces eromheen zou dat niet moeten doen. Input, rechten, beslisregels, controles en verantwoordelijkheid kunnen expliciet blijven, ook wanneer taal probabilistisch is.
- Definieer de beslissing vóór het op te leveren werk.
- Benoem de leidende bronnen voordat je tools verbindt.
- Beschrijf de uitzondering voordat je het ideale verloop verfijnt.
- Kies het goedkeuringsmoment voordat je autonomie geeft.
- Bepaal welk bewijs de specificatie na de lancering verandert.
Een specificatie moet leren zonder weer folklore te worden.
De eerste specificatie zal onjuist zijn. Echte klanten leveren uitzonderingen op die workshops niet opleveren. Het doel is niet elk uitzonderlijk geval te voorspellen. Het is nieuwe kennis een plek geven.
Wanneer een briefing dochterbedrijven herhaaldelijk verwart met moederbedrijven, pas je de entiteitsregel aan. Wanneer verkopers een onderdeel negeren, onderzoek je of de informatie zwak is of gewoon slecht geplaatst. Wanneer een compliancebeoordelaar een claim afwijst, pas je de bewijsdrempel aan. Het systeem verbetert doordat operationele feedback een expliciet document verandert, niet doordat iemand stilletjes nog een zin aan een privéprompt toevoegt.
Dat is de verschuiving van AI gebruiken naar AI beheren. De prompt is niet langer het product. De beheerde kringloop wordt het product.
Bewijs en verder lezen.
De post op sociale media die aanleiding gaf tot het bredere betoog over operationele systemen.
02GitHub Spec KitDe specificatiegedreven werkwijze en het referentiemateriaal van GitHub.
03Specificatiegedreven ontwikkelingHet pleidooi voor specificaties als primair werkdocument in plaats van wegwerpdocumentatie.