De afgelopen twee jaar is de softwarewereld verliefd geworden op een nieuwe term: vibe coding.
Het idee is verleidelijk: open je favoriete AI-ontwikkelomgeving, beschrijf een idee, en zie software bijna als vanzelf voor je ogen ontstaan.
Een website nodig? Bouw het. Een app nodig? Bouw het. Een marketplace, CRM, portal, dashboard, chatbot of mobiele app? Bouw het. De drempels die ooit een idee scheidden van een werkend product verdwijnen in een tempo dat weinigen een paar jaar geleden voor mogelijk hielden.
Het is een indrukwekkende prestatie, maar ook potentieel gevaarlijk. Want hoewel AI ongelooflijk goed is geworden in het hélpen bouwen van software, heeft het ons niet beter gemaakt in het bepalen of die software eigenlijk wel zou moeten bestaan. Dat onderscheid kan wel eens een van de bepalende vraagstukken van het AI-tijdperk worden.
Bij Loggix hebben deze ontwikkelingen tot veel discussies geleid over waar softwareontwikkeling naartoe gaat. Tijdens een van die gesprekken introduceerde oprichter Jeroen Lutmers een concept dat een ander perspectief biedt op de toekomst van softwareontwikkeling: Necessity-Driven Development.
Niet omdat software langzamer gebouwd zou moeten worden. Niet omdat innovatie beperkt zou moeten worden. Maar omdat de economie van software zo drastisch verandert, dat de hele branche wel eens de verkeerde vraag zou kunnen stellen.
Decennialang werd softwareontwikkeling beperkt door de implementatie zelf. Systemen bouwen was duur. Ervaren ontwikkelaars waren schaars. Elke nieuwe functie betekende een aanzienlijke investering in tijd en geld. Of een organisatie nu Waterfall, Agile, Scrum of Lean Startup volgde, al deze methodieken probeerden uiteindelijk hetzelfde probleem op te lossen: hoe beheersen we de kosten en complexiteit van het bouwen van software?
Vandaag verdwijnt die beperking in rap tempo dankzij AI. Één ontwikkelaar kan in een middag genereren waar vroeger weken, misschien maanden, werk voor nodig was. Complete applicaties worden opgezet vanuit een prompt. API's, interfaces, integraties en bedrijfslogica worden steeds meer een commodity. Wat ooit moeilijk was, wordt routine.
En daar begint de paradox. Als iets goedkoop wordt, gebruiken mensen er meer van. Als software makkelijk te maken is, gaan organisaties automatisch meer software maken. Veel meer. Functies die vroeger zorgvuldig werden afgewogen, worden nu in minuten gegenereerd. Complete modules worden toegevoegd omdat ze nuttig lijken. Nieuwe workflows ontstaan omdat ze ooit nodig zouden kunnen zijn.
De verleiding om eerst te bouwen en later te denken wordt met elke verbetering in AI groter. De branche moet — als het dat nog niet doet — snel ontdekken dat er een groot verschil is tussen software die gebouwd kan worden en software die gebouwd zou moeten worden.
In plaats van de vraag “Wat kunnen we bouwen?” moeten we vragen:
“Wat is het kleinste dat moet bestaan om het probleem van vandaag op te lossen?”
Het verschil lijkt op papier subtiel, maar verandert de rol van software fundamenteel. Binnen deze filosofie is software niet langer een groot ontwerp dat jaren van tevoren wordt uitgedacht. In plaats daarvan wordt het een evoluerend antwoord op echte behoeften. Een magazijnmanager heeft geen goed zicht op de voorraad. Los dat probleem op. Een maand later heeft de inkoopafdeling goedkeuringsworkflows nodig. Breid het systeem uit. Drie maanden later moet de boekhouding beter geïntegreerd worden. Pas het opnieuw aan.
Elke toevoeging wordt gerechtvaardigd door noodzaak, niet door verbeeldingskracht. De software groeit omdat de praktijk het vereist. Niet omdat een roadmap het voorspelde. Niet omdat een brainstormsessie het zich voorstelde. En zeker niet omdat AI het makkelijk maakte om te genereren. Ironisch genoeg zal dit idee voor veel FileMaker-ontwikkelaars opvallend bekend klinken.
Lang voordat AI onderdeel werd van het gesprek, pasten FileMaker maatwerkontwikkelaars al een vorm van Necessity-Driven Development toe. Ze zaten aan tafel met bedrijfseigenaren, planners, administratief personeel, magazijnmedewerkers en financiële teams. Ze luisterden. Ze observeerden. Ze herkenden knelpunten en bouwden oplossingen rond de werkelijke operationele behoefte. Een beter planningsscherm. Een ontbrekend rapport. Een workflow die dubbel werk wegnam. Een koppeling die handmatige invoer overbodig maakte. De waarde werd nooit gemeten aan de hoeveelheid geschreven code. Die werd gemeten aan de hoeveelheid weggenomen frictie.
Jarenlang stond deze manier van werken vaak in de schaduw van discussies over programmeertalen, frameworks en architectuur. Maar AI verschuift de aandacht misschien stilletjes terug naar precies de vaardigheden die maatwerkontwikkelaars al decennia cultiveren. Want hoewel AI in razendsnel tempo code kan genereren, worstelt het nog altijd met een veel complexere uitdaging: het begrijpen van noodzaak. Een AI-model kan een dashboard maken. Het kan niet altijd bepalen of dat dashboard nodig is. Het kan een workflow genereren. Het kan niet altijd vaststellen of die workflow het onderliggende probleem daadwerkelijk oplost. Het kan een nieuwe functie bouwen. Het kan niet betrouwbaar beoordelen of die functie meer waarde dan complexiteit oplevert.
Die beslissingen vragen context. Ze vragen bedrijfsinzicht. Ze vragen menselijk beoordelingsvermogen. Terwijl implementatie steeds toegankelijker wordt, wordt begrip schaarser. En schaarste creëert waarde. Dat inzicht leidt tot een intrigerende mogelijkheid. Het AI-tijdperk verkleint het belang van ervaren softwareprofessionals misschien helemaal niet. In plaats daarvan tilt het een ander soort vaardigheden naar de voorgrond. De ontwikkelaar van de toekomst besteedt wellicht minder tijd aan het schrijven van code en meer tijd aan het ontdekken van noodzaak. De analist die begrijpt waarom een proces faalt, wordt misschien waardevoller dan de engineer die nog duizend regels code kan genereren. De architect die patronen binnen een organisatie herkent, creëert wellicht meer waarde dan de specialist die één specifiek framework beheerst. In een wereld waarin het maken van software vrijwel niets meer kost, wordt weten wat je níet moet bouwen een concurrentievoordeel.
Toch brengt Necessity-Driven Development een eigen uitdaging met zich mee. Als software continu evolueert om aan nieuwe behoeften te voldoen, wat voorkomt dan dat het een onbeheersbaar monster wordt? Iedereen die lang genoeg met bedrijfssystemen heeft gewerkt, heeft dit zien gebeuren. Een simpele applicatie wordt een grotere applicatie. Een grotere applicatie wordt een platform. Na verloop van tijd stapelen nieuwe eisen zich op, overlappen workflows, dupliceert functionaliteit zichzelf en groeit complexiteit sneller dan waarde. Zonder discipline kan noodzaak uiteindelijk chaos creëren.
Misschien is de toekomst niet AI als programmeur. Misschien is de toekomst AI als tuinman.
Hier ligt misschien de meest transformerende rol van AI. Een tuinman maakt niet elke plant in een ecosysteem. In plaats daarvan zorgt hij ervoor dat groei gezond, in balans en duurzaam blijft. Hij snoeit overbodige takken. Hij herkent duplicatie. Hij reorganiseert waar nodig en maakt ruimte voor toekomstige groei.
Software heeft binnenkort misschien precies dit soort zorg nodig. Stel je een AI voor die continu een project monitort en vragen stelt zoals:
- 🌱Hebben we hier al een component voor dat dit oplost?
- 🌱Kan deze functionaliteit hergebruikt worden in plaats van opnieuw gebouwd?
- 🌱Wordt deze workflow overbodig?
- 🌱Voegen we complexiteit sneller toe dan waarde?
- 🌱Kunnen deze vijf modules samengevoegd worden tot één?
In plaats van simpelweg meer software te genereren, wordt AI verantwoordelijk voor de samenhang van het hele ecosysteem. Het wordt de tuinman.
De implicaties van die verschuiving zijn ingrijpend. Voor het eerst in de geschiedenis van softwareontwikkeling kunnen de kosten van het máken van software lager worden dan de kosten van het beslíssen wat er gemaakt zou moeten worden. De bottleneck verschuift. Weg van implementatie. Naar begrip. Weg van syntax. Naar noodzaak. En dat is misschien waarom zoveel ervaren FileMaker-ontwikkelaars beter gepositioneerd zijn voor de toekomst dan ze zelf beseffen.
Jarenlang hebben zij gewerkt op het snijvlak van mensen, processen en technologie. Ze hebben geleerd verborgen eisen naar boven te halen, organisatorische complexiteit te doorzien en oplossingen te bouwen die meegroeien met de bedrijven die ze bedienen. Terwijl een groot deel van de branche zich richtte op het optimaliseren van het coderen zelf, verfijnden zij de kunst van het begrijpen.
Nu AI softwareontwikkeling blijft transformeren, wordt dat onderscheid mogelijk steeds belangrijker. Want de vraag is niet langer of AI software kan schrijven. Dat kan het. De echte vraag is of we software blijven bouwen omdat het kán, of dat we uiteindelijk alleen nog bouwen wat we nódig hebben. Als het antwoord het laatste is, is Necessity-Driven Development wellicht veel meer dan een methodologie. Het kan de filosofie worden die softwareontwikkeling in het AI-tijdperk definieert.
