De bottleneck zit niet meer in de code

Written on
21 May 2026
by
Albert-Jan Schot
CTO
Share

We nemen je mee in:

AI maakt software bouwen makkelijk. Een engineer genereert in uren wat vroeger weken kostte. Maar sneller bouwen is alleen waardevol als je weet wát je bouwt. En voor wie. En waarom.

Bij Blis noemen we dat voortraject AI-native discovery: het proces waarin je met werkende prototypes valideert wat je gaat bouwen, voordat de echte software ontwikkeling begint. In de tweede aflevering van Blis Bytes ging ik erover in gesprek met Pauline van Duin, Business Consultant, en Christian Boer, mede-oprichter en partner en AI Engineer.

Werkend prototype in dagen, voordat de bouw begint

Bij de meeste softwareprojecten werkt het nog zo: je beschrijft wat je wilt in een document, een team interpreteert dat, en een paar sprints later zie je voor het eerst wat het geworden is. Herken je het nog? Die demo waarbij je denkt: dat is niet wat ik bedoelde.

Wij draaien dat om. Onze business consultant maakt binnen dagen een werkend prototype. Een klikbare applicatie waar je doorheen navigeert. Pauline: "Ik hoef niks meer uit te leggen. Ik kan gewoon zeggen: kijk, dit is wat je hebt gezegd. Klopt dit?"

Dat verandert het gesprek. Je reageert op iets wat je kunt zien en aanraken. Keuzes die anders weken vaag bleven, maak je in één sessie.

Die prototypes gaan mee naar productie. De engineer zet vooraf technische guardrails op: architectuurregels en componentstandaarden die passen bij jouw project. Christian: "Als je die guardrails goed neerzet, kun je prototypes maken die bijna end-stage zijn. Prima te gebruiken richting productie."

Dat is de kern. Je valideert met werkende software, voordat de echte bouw begint.

Eén gedeeld brein voor het hele projectteam

In een traditioneel project gaat kennis verloren bij elke overdracht. De consultant schrijft een document, de engineer interpreteert het, de product owner corrigeert het twee weken later bij de sprintreview. Je kent het.

Wij werken met wat we een shared brain noemen. Eén gedeelde kennisbasis per project: discoveryresultaten en technische kaders naast de validatieafspraken met jou als opdrachtgever. Alles gestructureerd, alles gevalideerd.

De engineer kan terugvinden wat er in de klantgesprekken is besproken. De consultant kan opvragen wat er al in de code staat. Pauline: "We werken vanuit dezelfde basis."

Voor jou als product owner: je hoeft iets maar één keer te zeggen. Als er iets verandert, is de hele driehoek direct op de hoogte.

De gouden driehoek: jij zit erin. Dat vraagt wat.

Bij Blis werken we in de gouden driehoek: jij als product owner, en een business consultant en een engineer vanuit ons. Drie rollen, één team. Dat betekent dat jij er niet eens per twee weken bij een sprintreview naar kijkt. Je bent aangehaakt in de loop van het werk. Continu meedenken, continu valideren.

Dat is een andere manier van samenwerken dan veel organisaties gewend zijn. En ja, dat vraagt meer van je als opdrachtgever.

Maar het levert ook meer op. Omdat alles sneller gaat, maak je keuzes wanneer het ertoe doet. Niet pas bij de volgende sprint. Pauline: "Er is heel veel voortgang mogelijk. Maar om dat mogelijk te maken moeten die keuzes wel gemaakt worden."

Het voelt misschien als waterval, omdat er zoveel in het voortraject gebeurt. Pauline: "Het is juist veel iteratiever. Je werkt sneller." Je ziet eerder resultaat, valideert vaker en stuurt bij terwijl het nog kan.

Twee prototypes, twee perspectieven

Onze consultant maakt altijd twee prototypes. Eén voor de volgende release. Concreet: dit kun je verwachten. En één als stip aan de horizon, de visie van het product.

Dat geeft een gezonde spanning. Want als opdrachtgever wil je altijd zo ver mogelijk vooruit. Het team moet steeds de vraag beantwoorden: kunnen we dit nu al oplossen, of is het te vroeg? Die afweging maak je samen. Met werkende software in je handen.

Software ontwikkeling verandert, het vakmanschap blijft

De tools die we gebruiken vervagen de grens tussen rollen. Onze consultant bouwt zelf werkende prototypes. Onze engineer maakt steeds vaker strategische presentaties. Maar de expertise erachter blijft anders. De consultant vertaalt problemen naar oplossingen. De engineer zorgt dat die oplossingen stevig staan in productie. Ze delen gereedschap. Hun vak is complementair.

En daar zit de komende maanden ook de grootste verandering. Christian: de modellen en tools zijn al goed genoeg. Het gaat om hoe je je team eromheen organiseert.

AI-native discovery draait om waar de waarde zit. In de keuzes die je maakt voordat je één regel code schrijft. Wil je horen hoe dat er in de praktijk uitziet?

Luister of kijk de hele aflevering van Blis Bytes: [LINK]

Of wil je weten hoe dit er voor jouw project uitziet? Plan een discovery.

Veelgestelde vragen

Wat is AI-native discovery?
AI-native discovery is het voortraject van software ontwikkeling waarin je met werkende prototypes valideert wat je gaat bouwen, voordat de echte bouw begint. De business consultant maakt binnen dagen een klikbaar prototype op basis van klantgesprekken. Zo maak je keuzes op basis van werkende software in plaats van documenten.

Wat is de gouden driehoek bij software ontwikkeling?
De gouden driehoek is een teamopzet van drie rollen: de product owner (de opdrachtgever), een business consultant en een engineer. Ze werken als één team aan hetzelfde project, met een gedeelde kennisbasis. De product owner is continu aangehaakt in plaats van alleen bij sprint reviews.

Wat is een shared brain in een softwareproject?
Een shared brain is een gedeelde kennisbasis per project waar alle discoveryresultaten, technische kaders en validatieafspraken in staan. De consultant, de engineer en hun AI-tools werken allemaal vanuit dezelfde basis. Dat voorkomt kennisverlies en misverstanden tussen rollen.