Een complete softwareafdeling met 160 digitale specialisten. Van architecten, ontwikkelaars en databasespecialisten tot beveiligingsexperts, kwaliteitscontroleurs en infrastructuurdeskundigen. Een afdeling die software ontwerpt, bouwt, controleert en beheert, en ondertussen zelf steeds slimmer, sneller en veiliger wordt. Bij The Spidermonkeys werken we al met deze nieuwe manier van softwareontwikkeling. We noemen het onze AI Factory.
Stel je nou eens voor…
Je zit op maandagochtend met een kop koffie achter je laptop. Je hebt een idee voor een nieuwe applicatie. Misschien wil je een bedrijfsproces automatiseren waar medewerkers iedere week uren aan kwijt zijn. Misschien wil je verschillende systemen met elkaar verbinden, of heb je een compleet nieuw digitaal product bedacht.
Je weet ongeveer wat je wilt bereiken, maar hoe je dat technisch moet realiseren? Geen idee. En eigenlijk zou dat ook helemaal niet jouw probleem moeten zijn.
Normaal gesproken begint op dat moment een behoorlijk traject. Je gaat met softwareontwikkelaars praten, er worden wensen verzameld, ontwerpen gemaakt en technische specificaties geschreven. Vervolgens wordt er gepland, gebouwd, getest, aangepast en opnieuw getest. Als alles goed gaat, heb je na een aantal weken of maanden een applicatie die ongeveer doet wat je oorspronkelijk voor ogen had.
Maar stel je nou eens voor dat je voor dat hele proces een complete softwareafdeling tot je beschikking hebt.
Een afdeling met kennis van vrijwel alles wat bij softwareontwikkeling komt kijken. Van productstrategie en functionele analyse tot architectuur, databases, gebruikersinterfaces, beveiliging, privacy, infrastructuur en kwaliteitscontrole. Een afdeling waar je niet voor iedere nieuwe vraag eerst iemand hoeft te zoeken die toevallig over de juiste deskundigheid beschikt, maar waar de benodigde specialisten afhankelijk van de opdracht worden samengebracht.
En stel je vervolgens eens voor dat die afdeling niet uit honderden medewerkers bestaat, maar uit een slimme combinatie van kunstmatige intelligentie, specialistische vaardigheden, technische infrastructuur, automatisering en menselijke regie.
Dat is de gedachte achter onze AI Factory.
Bij The Spidermonkeys werken we inmiddels met deze digitale softwareafdeling. We gebruiken haar in onze dagelijkse softwareontwikkeling en bouwen tegelijkertijd voortdurend verder aan de mogelijkheden. Inmiddels hebben we een catalogus van 160 digitale specialisten uitgewerkt, verdeeld over zestien vakgebieden. Een deel van die deskundigheid passen we al toe, andere rollen ontwikkelen we verder of voegen we stapsgewijs toe.
Zo ontstaat een softwareafdeling die niet alleen steeds meer werkzaamheden kan uitvoeren, maar ook voortdurend beter wordt in wat ze doet.
Waarom zouden we eigenlijk beginnen met programmeren?
Een van de eerste vragen die we onszelf stelden, was waarom softwareontwikkeling nog zo sterk georganiseerd is rondom het schrijven van code. Natuurlijk is programmeercode noodzakelijk om software te laten functioneren, maar voor degene die een applicatie nodig heeft, is die code eigenlijk helemaal niet interessant. Die persoon heeft een probleem dat opgelost moet worden, een proces dat beter kan of een idee dat werkelijkheid moet worden.
Neem bijvoorbeeld een organisatie waar medewerkers dagelijks gegevens overtypen tussen verschillende systemen. De traditionele aanpak is om te onderzoeken welke schermen, formulieren en koppelingen nodig zijn om dat proces te digitaliseren. Vervolgens gaan ontwikkelaars die functionaliteit bouwen.
Maar misschien stellen we dan wel de verkeerde vraag. Waarom zouden medewerkers überhaupt nog gegevens moeten overtypen? Misschien kunnen we het hele proces automatiseren. Misschien kan AI de informatie rechtstreeks uit documenten, gesprekken of bestaande systemen halen. Of misschien bestaat er al een oplossing die we kunnen hergebruiken.
Als je begint met de opdracht om een formulier te bouwen, krijg je waarschijnlijk een formulier. Maar als je begint met de vraag hoe je administratief werk kunt verminderen, kom je mogelijk tot een veel betere oplossing.
Daarom begint softwareontwikkeling bij ons niet met programmeren, maar met een gesprek over het gewenste resultaat. We gebruiken AI om samen te onderzoeken wat we werkelijk willen bereiken. Daarbij mag AI kritisch zijn, doorvragen, alternatieven voorstellen en ons wijzen op zaken waar we zelf nog niet aan hebben gedacht. Het doel is om niet te snel in een technische oplossing te schieten, maar eerst goed te begrijpen welk probleem we proberen op te lossen.
Pas wanneer dat helder is, ontstaat er een opdracht. En juist daar begint onze AI Factory een interessante rol te spelen.
Van een idee naar een opdracht die de fabriek begrijpt
Stel dat we na een aantal gesprekken precies weten wat we willen bereiken. We hebben een duidelijk doel geformuleerd en kunnen beschrijven hoe de uiteindelijke oplossing voor de gebruiker moet functioneren.
In een traditionele organisatie zou een technisch team dat doel verder uitwerken. Er moeten architectuurkeuzes worden gemaakt, afhankelijkheden worden onderzocht, beveiligingseisen worden vastgesteld en werkzaamheden worden verdeeld. Binnen onze AI Factory organiseren we die voorbereiding met behulp van gespecialiseerde kennis, vaste processen en AI.
De fabriek moet een opdracht niet klakkeloos accepteren, maar eerst kritisch onderzoeken of deze compleet en uitvoerbaar is. Welke functionaliteiten zijn nodig om het doel te bereiken? Welke systemen moeten samenwerken? Welke gegevens worden verwerkt en welke beveiligingsmaatregelen zijn daarvoor noodzakelijk? Zijn er bestaande onderdelen die we kunnen hergebruiken, of moeten er daadwerkelijk nieuwe componenten worden ontwikkeld?
En misschien nog belangrijker: hoe weten we straks dat het resultaat correct is?
Want het is niet voldoende dat een applicatie er goed uitziet of dat de programmeercode zonder fouten wordt uitgevoerd. We willen vooraf kunnen vaststellen welke handelingen een gebruiker moet kunnen uitvoeren, welke resultaten daarbij horen en welke situaties absoluut niet mogen voorkomen. Daarom werken we met duidelijke acceptatiecriteria en een omschrijving van wat daadwerkelijk als afgerond mag worden beschouwd.
Wanneer er nog belangrijke vragen openstaan, moet de fabriek die kunnen herkennen en aan ons voorleggen. Niet iedere technische keuze hoeft door een mens te worden gemaakt, maar beslissingen over het gewenste resultaat, belangrijke risico's en bevoegdheden blijven onze verantwoordelijkheid.
Uiteindelijk willen we toe naar een situatie waarin we samen met AI een doel formuleren, de fabriek dat doel vertaalt naar een compleet uitvoeringsplan en wij vervolgens akkoord geven op het geheel. Daarna hoeft niet iedere volgende technische stap opnieuw door een mens te worden goedgekeurd, zolang de werkzaamheden binnen de afgesproken kaders blijven. En vanaf dat moment begint het echte fabriekswerk.
Een organisatie met 160 digitale specialisten
Om te begrijpen hoe wij onze AI Factory organiseren, helpt het om even niet aan software te denken, maar aan een grote technische afdeling waarin je voor vrijwel ieder vraagstuk de juiste deskundigheid kunt inschakelen.
Heb je een ingewikkeld databaseprobleem? Dan is er een databasespecialist beschikbaar. Moet een applicatie geschikt zijn voor duizenden gelijktijdige gebruikers? Dan worden specialisten ingezet voor performance, schaalbaarheid en belastingstests.
Gaat het om de verwerking van persoonsgegevens, dan zijn er specialisten voor privacy, gegevensbescherming, toegangsrechten en beveiligingsarchitectuur. En wanneer een applicatie moet voldoen aan bepaalde kwaliteitsnormen, kunnen specialisten op het gebied van ISO 9001, ISO 27001 en compliance worden ingezet om de relevante eisen en bewijsvoering te beoordelen.
Binnen onze AI Factory hebben we inmiddels een catalogus van 160 digitale specialistische rollen uitgewerkt, verdeeld over zestien vakgebieden. Die specialisten vertegenwoordigen de volledige levenscyclus van softwareontwikkeling. Van productstrategie en functionele analyse tot architectuur, programmeren, testen, beveiliging, infrastructuur, deployment, monitoring en onderhoud.
Maar ook de fabriek zelf heeft specialisten nodig. Denk aan een specialist die onderzoekt waarom werkzaamheden vastlopen, een specialist die technische afhankelijkheden bewaakt, iemand die controleert of verschillende processen elkaar niet tegenwerken en een specialist die oplossingen vastlegt zodat ze later opnieuw gebruikt kunnen worden.
Het bijzondere is dat we deze deskundigheid niet organiseren als 160 afzonderlijke medewerkers die voortdurend beschikbaar moeten zijn. We organiseren haar als een groeiende bibliotheek van digitale specialistische rollen, ondersteund door kennis, technische standaarden, procedures en gereedschappen.
Afhankelijk van de opdracht stelt de fabriek daaruit de juiste combinatie samen. Voor een relatief eenvoudige opdracht zijn misschien maar enkele specialisten nodig, terwijl een ingewikkeld softwareproject tientallen verschillende deskundigheden kan vereisen.
Een deel van deze rollen gebruiken we al in onze dagelijkse werkzaamheden. Andere ontwikkelen we verder of voegen we stapsgewijs toe. Zo groeit de afdeling mee met de vraagstukken die we tegenkomen, zonder dat we voor iedere nieuwe vaardigheid een compleet nieuw team hoeven samen te stellen.
Wie benieuwd is welke deskundigheid we binnen onze digitale softwareafdeling organiseren, kan verder lezen in ons tweede artikel: Maak kennis met de 160 specialisten van onze AI Factory.
Hoe werkt zo'n digitale specialist eigenlijk?
Achter deze manier van werken zit een combinatie van verschillende technologieën. Een belangrijk onderdeel daarvan zijn onze Factory Agents. Dat zijn intelligente uitvoerende onderdelen die worden aangestuurd door taalmodellen, ook wel Large Language Models genoemd.
Maar een taalmodel op zichzelf is nog geen betrouwbare softwareontwikkelaar, databasearchitect of beveiligingsspecialist. Daarvoor heeft het meer nodig. Het systeem moet weten welke taak het uitvoert, welke verantwoordelijkheden daarbij horen, welke technische afspraken gelden en welke gereedschappen gebruikt mogen worden. Daarnaast moet het beschikken over de juiste kennis en instructies om werkzaamheden op een consistente manier uit te voeren.
Die specialistische vaardigheden noemen we skills. Een skill kan bijvoorbeeld beschrijven hoe een databasestructuur veilig wordt aangepast, welke controles verplicht zijn voordat een wijziging wordt doorgevoerd en hoe wordt vastgesteld dat de gegevens na afloop nog correct zijn.
Een beveiligingsskill kan juist voorschrijven hoe risico's worden onderzocht, welke controles noodzakelijk zijn en welke handelingen nooit zonder aanvullende toestemming mogen plaatsvinden.
Daarnaast maken we onderscheid tussen de vaardigheden die nodig zijn en de hoeveelheid intelligentie die we daarvoor inzetten. Een eenvoudige technische controle vraagt immers iets anders dan het ontwerpen van een complexe softwarearchitectuur. Voor relatief eenvoudige werkzaamheden kunnen kleinere en goedkopere taalmodellen voldoende zijn, terwijl ingewikkelde vraagstukken meer redeneercapaciteit kunnen vereisen.
Door die onderdelen van elkaar te scheiden, kunnen we voor iedere opdracht de juiste combinatie van kennis, gereedschappen, context en intelligentie kiezen. En dat is belangrijk, want we willen niet alleen een slimme fabriek bouwen. We willen ook dat die efficiënt omgaat met tijd, capaciteit en kosten.
Wie houdt het overzicht?
Een afdeling met zoveel specialisten klinkt prachtig, maar daarmee ontstaat onmiddellijk een nieuw probleem. Want wie bepaalt welke werkzaamheden uitgevoerd moeten worden? Wie zorgt ervoor dat de juiste specialisten op het juiste moment worden ingezet? En wie bewaakt dat verschillende werkzaamheden elkaar niet in de weg zitten?
Stel dat er aan een nieuwe applicatie wordt gewerkt. Een onderdeel van de software heeft een databasewijziging nodig, terwijl een ander onderdeel afhankelijk is van een nieuwe API. Ondertussen moeten bestaande functionaliteiten blijven werken en mogen verschillende wijzigingen elkaar niet verstoren. Dat vraagt om regie.
Daarom hebben we binnen onze AI Factory een duidelijke scheiding aangebracht tussen de besturing, de intelligentie en de technische uitvoering.
De besturing ligt bij onze Factory Controllers. Je kunt een controller zien als de productieleider van de fabriek. Hij houdt overzicht over de opdrachten, organiseert werkzaamheden, bewaakt afhankelijkheden en zorgt dat beschikbare capaciteit zo efficiënt mogelijk wordt ingezet.
De inhoudelijke werkzaamheden worden uitgevoerd door Factory Agents. Zij gebruiken de specialistische vaardigheden die nodig zijn om problemen te analyseren, oplossingen te ontwikkelen en resultaten te controleren.
Voor het daadwerkelijke technische werk maken die agents gebruik van Factory Workers. Dat zijn computeromgevingen waarop software kan worden opgehaald, gebouwd, getest en technisch verwerkt. Een Factory Worker is dus geen digitale medewerker, maar de technische werkplek waarop opdrachten worden uitgevoerd.
Door die verantwoordelijkheden te scheiden, kunnen we verschillende werkzaamheden naast elkaar laten plaatsvinden, terwijl de centrale regie bewaakt dat alles uiteindelijk samenkomt in één werkend resultaat.
Wanneer een onderdeel vastloopt, hoeft niet automatisch de hele opdracht opnieuw te beginnen. De fabriek moet kunnen vaststellen waar het probleem zit, welke werkzaamheden daardoor worden geraakt en hoe het proces veilig kan worden voortgezet. Daarmee wordt de organisatie van het werk minstens zo belangrijk als het daadwerkelijke programmeren.
Waarom zouden we dezelfde fout twee keer maken?
Tijdens softwareontwikkeling ontstaan voortdurend nieuwe inzichten. Soms ontdekken we een slimmere manier om een database te organiseren, soms vinden we een beveiligingsprobleem en soms blijkt dat een bepaalde technische aanpak in de praktijk helemaal niet goed werkt.
In traditionele ontwikkeltrajecten wordt die kennis niet altijd structureel hergebruikt. Een probleem dat in het ene project is opgelost, kan in een volgend project opnieuw ontstaan. Dat vinden wij eigenlijk onlogisch.
Daarom werken we binnen onze AI Factory met een principe dat we Never Twice noemen. De gedachte daarachter is eenvoudig: wanneer we een probleem eenmaal goed hebben opgelost, willen we voorkomen dat we dezelfde fout opnieuw moeten onderzoeken.
Dat betekent niet dat een AI model vanzelf alles onthoudt. We leggen kennis juist expliciet vast in technische documentatie, herbruikbare componenten, standaarden, tests en specialistische skills.
Wanneer een bepaalde fout vaker voorkomt, kan dat aanleiding zijn om een nieuwe automatische controle toe te voegen. Wanneer een technische oplossing betrouwbaar blijkt, kan die worden omgezet in een herbruikbaar onderdeel. En wanneer een werkwijze goed functioneert, kunnen we die beschikbaar maken voor andere opdrachten.
Voordat er iets nieuws wordt ontwikkeld, moet daarom worden onderzocht of er al een bewezen oplossing bestaat die we kunnen gebruiken. Zo voorkomen we niet alleen dubbel werk, maar proberen we ook de kwaliteit van de fabriek steeds verder te verhogen.
Iedere opdracht levert daarmee niet alleen nieuwe software op, maar kan ook bijdragen aan betere kennis, betere controles en betere werkwijzen.
Wie controleert of het resultaat werkelijk klopt?
Een van de belangrijkste uitgangspunten van onze AI Factory is dat degene die iets bouwt niet automatisch degene is die bepaalt dat het goed genoeg is. Dat klinkt logisch, maar bij AI is het extra belangrijk.
Wie regelmatig met taalmodellen werkt, weet dat ze soms behoorlijk overtuigend kunnen vertellen dat een opdracht volledig is afgerond, terwijl er bij nader onderzoek toch fouten blijken te zitten. Daarom organiseren we onafhankelijke controles.
Wanneer een onderdeel van de software is ontwikkeld, kan het resultaat worden beoordeeld op codekwaliteit, architectuur, beveiliging, prestaties en naleving van technische afspraken. Daarnaast voeren we automatische tests uit om te controleren of afzonderlijke onderdelen correct werken en of verschillende systemen goed samenwerken.
Ook onderzoeken we of nieuwe wijzigingen bestaande functionaliteit verstoren. Stel dat we een nieuwe functie toevoegen waarmee gebruikers documenten kunnen uploaden. Die functie kan uitstekend werken, terwijl door dezelfde wijziging ineens het downloaden van bestaande documenten niet meer mogelijk is.
Dan is de nieuwe functionaliteit misschien correct gebouwd, maar het totale resultaat natuurlijk niet acceptabel.
Daarom is kwaliteitscontrole bij ons geen laatste stap die pas aan het einde van een project plaatsvindt. Het is een doorlopend onderdeel van het productieproces.
Wanneer een controle een probleem ontdekt, moet dat probleem terug naar de juiste uitvoerende specialist. Die onderzoekt de oorzaak, voert een gerichte correctie uit en laat het resultaat opnieuw controleren.
En wanneer dezelfde fout blijft terugkomen, moet de fabriek kunnen herkennen dat er iets structureels misgaat. Misschien ontbreekt er belangrijke kennis. Misschien is de opdracht niet duidelijk genoeg. Of misschien is er een technische afhankelijkheid die eerder over het hoofd is gezien.
Het doel is dat de fabriek niet eindeloos dezelfde handelingen blijft herhalen, maar steeds beter leert vaststellen waarom iets niet werkt en welke aanpak nodig is om verder te komen.
Een digitale gebruiker die écht door de applicatie loopt
Technische controles zijn belangrijk, maar ze vertellen niet altijd het volledige verhaal. Een applicatie kan probleemloos bouwen, alle automatische tests doorstaan en toch voor een gebruiker nauwelijks bruikbaar zijn.
Misschien ontbreekt er een knop die volgens het ontwerp aanwezig moet zijn. Misschien wordt belangrijke informatie buiten het zichtbare scherm weergegeven, werkt een formulier niet op een mobiele telefoon of ziet een gebruiker gegevens die helemaal niet voor hem bedoeld zijn.
Daarom willen we dat onze AI Factory niet alleen de techniek controleert, maar ook daadwerkelijk onderzoekt hoe een applicatie voor gebruikers functioneert. Daarvoor gebruiken we het principe van een UI Walker.
Je kunt zo'n Walker zien als een geautomatiseerde gebruiker die zelfstandig door een applicatie navigeert. Hij opent de website in een browser, bekijkt de schermen, klikt op knoppen, vult formulieren in en controleert of de verwachte resultaten verschijnen.
Stel dat we een applicatie bouwen waarin medewerkers verlof kunnen aanvragen. Dan is het niet voldoende dat de software technisch een verlofaanvraag kan opslaan.
We willen ook controleren of een medewerker het aanvraagformulier daadwerkelijk kan vinden, of de juiste velden zichtbaar zijn en of de aanvraag na het opslaan terugkomt in het overzicht.
Vervolgens kan de Walker de applicatie openen vanuit het perspectief van een leidinggevende en controleren of die de aanvraag kan beoordelen. Daarna kan hij opnieuw inloggen als medewerker om vast te stellen of de beslissing correct zichtbaar is geworden.
En wat gebeurt er wanneer een medewerker probeert een aanvraag van iemand anders te bekijken? Wordt dat correct tegengehouden?
Zo kunnen we complete gebruikersscenario's doorlopen, waarbij niet alleen wordt gekeken naar wat er technisch gebeurt, maar ook naar wat een gebruiker daadwerkelijk ziet en kan doen.
Daarbij kan een Walker ook controleren of schermen overeenkomen met de afgesproken ontwerpen en of informatie op een logische manier wordt gepresenteerd.
Wanneer er iets niet klopt, wordt dat teruggekoppeld aan de fabriek. Een gespecialiseerde agent kan het probleem onderzoeken, de oplossing aanpassen en vervolgens kan de Walker dezelfde handelingen opnieuw uitvoeren.
Op die manier proberen we het verschil te overbruggen tussen software die volgens de techniek werkt en software die voor de gebruiker daadwerkelijk werkt. Want uiteindelijk is dat laatste natuurlijk waar het om draait.
Van werkende code naar een werkende applicatie
Stel dat alle controles zijn geslaagd. De architectuur klopt, de software voldoet aan de technische afspraken, de beveiligingstests zijn uitgevoerd en de UI Walker heeft vastgesteld dat de belangrijkste gebruikersscenario's correct functioneren.
Dan hebben we een mooi resultaat, maar nog niet noodzakelijk een bruikbare applicatie. Want de software moet ook daadwerkelijk beschikbaar worden gemaakt voor de mensen die ermee gaan werken.
In de traditionele wereld is dat vaak een afzonderlijk traject. Er moeten servers worden ingericht, databases worden voorbereid, beveiligde verbindingen worden geconfigureerd en applicaties worden geïnstalleerd.
Wij zien geen principiële reden waarom een groot deel van die werkzaamheden niet ook onderdeel kan zijn van hetzelfde gecontroleerde productieproces. Daarom omvat onze AI Factory ook specialisten op het gebied van infrastructuur, netwerken, deployment, backup, monitoring en betrouwbaarheid.
Wanneer een applicatie een nieuwe omgeving nodig heeft, moet de fabriek kunnen onderzoeken welke capaciteit daarvoor nodig is en welke bestaande voorzieningen gebruikt kunnen worden. Als er nieuwe infrastructuur nodig is, kan die binnen vooraf vastgestelde bevoegdheden worden voorbereid en ingericht.
Vervolgens kan de software worden uitgerold naar een acceptatieomgeving, waar opnieuw wordt gecontroleerd of alles correct functioneert. Pas wanneer de juiste controles zijn geslaagd en de benodigde vrijgaven zijn gegeven, kan dezelfde bewezen softwareversie naar productie worden gebracht.
Ook daarna is het werk nog niet afgelopen. De fabriek moet kunnen controleren of de applicatie bereikbaar is, of de verbindingen functioneren, of gebruikers kunnen inloggen en of de belangrijkste processen daadwerkelijk werken.
En wanneer een uitrol problemen veroorzaakt, moet er een gecontroleerde manier zijn om terug te keren naar een vorige werkende versie.
Dat is een belangrijk onderscheid in onze visie: we willen niet alleen het schrijven van code automatiseren, maar de hele weg van een goedgekeurde opdracht naar een daadwerkelijk werkende oplossing.
Een afdeling die ook na oplevering blijft werken
Eigenlijk is het vreemd dat we softwareontwikkeling vaak behandelen als een project dat op een bepaald moment klaar is. Want zodra een applicatie wordt gebruikt, verandert de wereld eromheen alweer. Er komen nieuwe wensen, systemen krijgen updates, beveiligingsproblemen worden ontdekt en gebruikers vinden nieuwe manieren om met de software te werken.
Daarom zien wij het beheer en de verdere ontwikkeling van software als een logisch vervolg op het bouwproces.
Stel dat een applicatie plotseling veel langzamer wordt. Dan kan de fabriek helpen om de oorzaak te onderzoeken, vast te stellen of het probleem in de database, de applicatie of de infrastructuur zit en een oplossing voor te bereiden.
Of stel dat een softwarebibliotheek een beveiligingsprobleem blijkt te bevatten. Dan willen we dat de fabriek kan onderzoeken welke applicaties daarvan afhankelijk zijn, welke maatregelen nodig zijn en hoe een veilige update kan worden uitgevoerd.
Ook daarvoor hebben we specialisten nodig, zoals monitoringexperts, incidentonderzoekers, hersteldeskundigen en specialisten die technische afhankelijkheden bewaken.
En zelfs het verbeteren van de fabriek zelf wordt onderdeel van die organisatie. Een specialist kan zich richten op het onderzoeken van werkzaamheden die opvallend veel tijd kosten, terwijl een ander onderzoekt waarom bepaalde opdrachten regelmatig vastlopen. Weer een ander kan vergelijken welke taalmodellen de beste resultaten leveren voor specifieke soorten werkzaamheden.
Zo ontstaat een afdeling die niet alleen software ontwikkelt, maar ook haar eigen werkwijze voortdurend kan onderzoeken en verbeteren. Niet doordat AI vanzelf steeds slimmer wordt, maar doordat we verbeteringen aantoonbaar vastleggen, toetsen en beschikbaar maken.
En geven we de fabriek dan zomaar toegang tot alles?
Natuurlijk niet. Sterker nog, hoe zelfstandiger we de fabriek willen laten werken, hoe belangrijker het wordt om zorgvuldig na te denken over bevoegdheden en beveiliging.
Een specialist die een gebruikersinterface ontwikkelt, hoeft bijvoorbeeld helemaal geen toegang te hebben tot een productiedatabase. Een proces dat tests uitvoert, hoeft niet zelfstandig nieuwe servers te mogen bestellen. En een systeem dat een probleem ontdekt, mag niet automatisch iedere denkbare wijziging in een productieomgeving uitvoeren.
Daarom ontwerpen we onze fabriek rondom duidelijke mandaten, gescheiden omgevingen en controleerbare handelingen. Een uitvoerend onderdeel krijgt de toegang die noodzakelijk is voor zijn opdracht, maar niet meer dan dat.
Ook willen we dat de fabriek kan vastleggen welke werkzaamheden zijn uitgevoerd, welke beslissingen zijn genomen, welke controles hebben plaatsgevonden en op basis waarvan een resultaat is goedgekeurd.
Daarbij is het essentieel dat informatie van verschillende klanten en organisaties gescheiden blijft. Werk voor de ene organisatie mag niet zomaar gebruikmaken van vertrouwelijke gegevens of specifieke projectkennis van een andere organisatie.
Ook moeten we onderscheid maken tussen werkzaamheden die veilig zelfstandig kunnen worden uitgevoerd en handelingen waarvoor expliciete menselijke goedkeuring nodig blijft. Een nieuwe functionaliteit ontwikkelen binnen een afgebakende testomgeving is immers iets heel anders dan een productiedatabase verwijderen of een belangrijke beveiligingsinstelling aanpassen.
Daarom bevat onze bibliotheek ook specialisten voor informatiebeveiliging, privacy, toegangsbeheer, risicobeoordeling, ISO normen, audit trails en naleving van wetgeving.
Onze ambitie is dus niet om AI onbeperkte vrijheid te geven, maar om een systeem te bouwen dat zo zelfstandig mogelijk kan functioneren binnen zorgvuldig vastgestelde grenzen.
De mens bepaalt het doel en de verantwoordelijkheden. De fabriek organiseert en voert het werk uit binnen die afspraken.
Wat betekent dit voor de softwareontwikkelaar?
Als we softwareontwikkeling op deze manier organiseren, verandert natuurlijk ook het werk van de mensen die software ontwikkelen. Misschien is de vergelijking met de autoindustrie wel interessant.
Vroeger werden auto's voor een groot deel met de hand gebouwd. Tegenwoordig zijn complete productielijnen geautomatiseerd en werken robots, machines en gespecialiseerde systemen samen om auto's te produceren.
Dat heeft het werk in die industrie ingrijpend veranderd. Maar het heeft niet de behoefte weggenomen aan mensen die begrijpen hoe auto's worden ontworpen, hoe productielijnen functioneren, hoe kwaliteit wordt gecontroleerd en hoe problemen moeten worden opgelost.
Misschien gebeurt er met softwareontwikkeling iets vergelijkbaars. De softwareontwikkelaar van de toekomst schrijft mogelijk veel minder code met de hand, maar moet juist veel beter begrijpen hoe software als geheel functioneert.
Hoe ontwerp je een goede architectuur? Hoe herken je beveiligingsrisico's? Hoe beoordeel je of een AI systeem de juiste technische keuzes heeft gemaakt? Hoe formuleer je een opdracht die voldoende duidelijk is om zelfstandig uitgevoerd te worden? En hoe weet je of het resultaat werkelijk voldoet aan de oorspronkelijke bedoeling?
Dat vraagt om technische kennis, analytisch vermogen en een goed begrip van bedrijfsprocessen. Ik verwacht daarom niet dat programmeren als vakgebied verdwijnt, maar wel dat de verhouding tussen zelf code schrijven, ontwerpen, regisseren en controleren behoorlijk gaat veranderen.
En misschien ontstaat er zelfs een nieuwe generatie softwareontwikkelaars die vooral gespecialiseerd is in het organiseren en aansturen van intelligente softwareproductie.
Wat betekent dit eigenlijk voor het onderwijs?
Tijdens het ontwikkelen van onze AI Factory merk ik dat ik steeds vaker nadenk over wat deze veranderingen betekenen voor de mensen die nu worden opgeleid tot softwareontwikkelaar.
Want wat moet een student vandaag leren om over vijf jaar nog goed voorbereid te zijn op het werkveld?
Natuurlijk blijft het belangrijk om te begrijpen hoe programmeertalen werken, hoe databases zijn opgebouwd en hoe software veilig en betrouwbaar wordt ontwikkeld. Zonder die kennis wordt het bijzonder lastig om te beoordelen of een AI systeem goed werk levert.
Maar is het nog logisch om het grootste deel van een opleiding te richten op het zelfstandig produceren van code, wanneer AI dat werk steeds sneller kan uitvoeren?
Misschien moeten we studenten veel meer leren hoe ze problemen analyseren, doelen formuleren, technische oplossingen beoordelen en samenwerken met gespecialiseerde AI systemen.
En hoe toetsen we dan hun kennis? Stel dat een student met behulp van AI in een middag een applicatie ontwikkelt waar vroeger enkele weken programmeerwerk voor nodig waren. Is dat dan een uitzonderlijk goede prestatie, of heeft de student vooral geleerd hoe hij de juiste opdrachten aan AI moet geven?
En is dat laatste eigenlijk niet óók een belangrijke professionele vaardigheid?
Misschien moeten we bij het beoordelen van studenten veel meer kijken naar de kwaliteit van hun keuzes, hun begrip van de architectuur, de manier waarop ze risico's herkennen en hun vermogen om aan te tonen dat een oplossing correct functioneert.
Want wanneer AI steeds meer van het daadwerkelijke programmeerwerk overneemt, wordt het vermogen om verantwoordelijkheid te dragen voor het eindresultaat alleen maar belangrijker.
Dat is een discussie die volgens mij niet alleen binnen softwareopleidingen gevoerd moet worden, maar in de hele IT sector.
Onze AI Factory is nooit af. En dat is precies de bedoeling.
Bij The Spidermonkeys werken we inmiddels met onze eigen AI Factory. We gebruiken AI in onze dagelijkse softwareontwikkeling om opdrachten uit te werken, technische oplossingen te ontwerpen, code te ontwikkelen, controles uit te voeren en problemen te onderzoeken.
Tegelijkertijd bouwen we voortdurend verder aan de fabriek zelf. Dat is misschien wel een van de interessantste eigenschappen van onze manier van werken. We ontwikkelen niet eerst jarenlang een systeem dat op een bepaald moment klaar moet zijn. We gebruiken de mogelijkheden die er vandaag al zijn en verbeteren de fabriek terwijl we ermee werken.
Wanneer we ontdekken dat een bepaalde controle ontbreekt, onderzoeken we hoe we die structureel kunnen toevoegen. Wanneer een proces regelmatig tegen hetzelfde probleem aanloopt, proberen we niet alleen dat ene probleem op te lossen, maar ook de oorzaak weg te nemen.
En wanneer een nieuwe technologie of een beter taalmodel beschikbaar komt, onderzoeken we of we daarmee bepaalde werkzaamheden slimmer of efficiënter kunnen uitvoeren.
Daarbij kijken we niet alleen naar snelheid. We willen ook dat de fabriek betrouwbaarder, veiliger, goedkoper en beter controleerbaar wordt.
Een snellere fabriek die meer fouten maakt, is immers geen betere fabriek. En een zelfstandiger systeem zonder duidelijke bevoegdheden en controles is niet wat wij willen bouwen. Daarom moet iedere verbetering uiteindelijk aantoonbaar bijdragen aan de kwaliteit van het geheel.
Onze bibliotheek van specialisten groeit, bestaande skills worden verfijnd en de samenwerking tussen de verschillende onderdelen van de fabriek wordt steeds verder verbeterd. Tegelijkertijd bouwen we aan de regie, infrastructuur en controles die nodig zijn om steeds grotere en complexere opdrachten verantwoord uit te voeren.
Zo ontstaat een bijzondere wisselwerking.
We gebruiken de AI Factory om software te ontwikkelen, maar we gebruiken diezelfde manier van werken ook om de AI Factory verder te ontwikkelen.
Iedere opdracht levert ervaring op. Iedere fout kan aanleiding zijn voor een structurele verbetering. Iedere succesvolle oplossing kan worden omgezet in herbruikbare kennis. En iedere nieuwe vaardigheid vergroot de mogelijkheden van de fabriek.
Daarmee wordt onze AI Factory niet een softwareproduct dat op een dag definitief klaar is, maar een digitale afdeling die voortdurend blijft groeien en zich blijft ontwikkelen. Een afdeling die vandaag al voor ons werkt en morgen weer meer kan dan vandaag.
Stel je nou eens voor…
We keren nog even terug naar die maandagochtend met een kop koffie. Je hebt een idee voor een applicatie, maar nog geen technische specificaties, geen programmeerteam en geen uitgewerkte architectuur. Je begint gewoon met een gesprek.
Samen met AI onderzoek je wat je wilt bereiken en welke oplossing daarvoor het meest geschikt is. Je bespreekt de mogelijkheden, scherpt het doel aan en laat de fabriek onderzoeken wat er nodig is om het te realiseren.
Wanneer de opdracht compleet is en je akkoord hebt gegeven, begint de fabriek met haar werk.
Uit een bibliotheek van 160 digitale specialisten worden de juiste deskundigheden geselecteerd. Misschien begint een softwarearchitect met het ontwerpen van de oplossing, terwijl een databasespecialist onderzoekt hoe gegevens het beste kunnen worden opgeslagen. Een UI specialist ontwerpt de gebruikerservaring en een beveiligingsspecialist kijkt vanaf het begin mee naar mogelijke risico's.
De Factory Controllers organiseren het werk en zorgen dat de verschillende werkzaamheden in de juiste volgorde worden uitgevoerd. Factory Agents brengen de benodigde intelligentie en vaardigheden mee, terwijl Factory Workers de technische omgevingen beschikbaar stellen waarin het werk daadwerkelijk plaatsvindt.
Tijdens het bouwen wordt voortdurend gecontroleerd of de technische afspraken worden nageleefd. Onafhankelijke specialisten beoordelen de resultaten, automatische tests controleren de functionaliteit en een digitale gebruiker loopt daadwerkelijk door de applicatie om vast te stellen of alles werkt zoals bedoeld.
Wanneer er iets niet klopt, wordt het probleem onderzocht en gecorrigeerd. Eerder opgedane kennis wordt hergebruikt, zodat de fabriek niet telkens dezelfde fouten hoeft te maken.
Zodra de oplossing aan de afgesproken kwaliteitseisen voldoet, wordt de benodigde omgeving voorbereid en kan de software gecontroleerd worden uitgerold. Daarna blijft de fabriek helpen om de applicatie te monitoren, onderhouden en verder te verbeteren.
En gedurende dat hele proces blijf jij verantwoordelijk voor het doel, de kaders en de belangrijke beslissingen, zonder dat je iedere technische handeling zelf hoeft te begeleiden.
Misschien duurt het nog even voordat deze volledige werkwijze op grote schaal vanzelfsprekend is. Er zijn nog genoeg technische, organisatorische en veiligheidsvraagstukken die we moeten oplossen.
Maar de afzonderlijke mogelijkheden ontwikkelen zich razendsnel. En door ze op een verstandige manier met elkaar te verbinden, ontstaat er iets wat veel verder gaat dan een AI assistent die programmeurs helpt om sneller code te schrijven.
Er ontstaat een nieuwe manier om software te maken. Een manier waarbij we niet langer vooral nadenken over hoeveel programmeurs we nodig hebben om een idee te realiseren, maar over hoe we een complete digitale softwareafdeling met specialistische kennis, intelligente technologie en betrouwbare processen kunnen inzetten om dat idee werkelijkheid te maken.
Stel je nou eens voor dat softwareontwikkeling straks niet meer draait om hoeveel code we kunnen schrijven, maar om hoeveel goede ideeën we daadwerkelijk werkelijkheid kunnen maken.
Dat is de toekomst die wij bij The Spidermonkeys voor ons zien. En met onze AI Factory werken we vandaag al aan die toekomst.
The Spidermonkeys
Wij bouwen niet alleen software. Wij bouwen aan een nieuwe manier om software te maken.