Corporate Vibecoding

Vibecoding is een manier van softwareontwikkeling waarbij AI-tools het grootste deel van de code schrijven op basis van beschrijvingen in gewone taal. Het stelt mensen zonder traditionele programmeerkennis in staat om werkende software te bouwen, en versnelt het werk van ervaren developers aanzienlijk.

Corporate vibecoding is de gestructureerde toepassing van vibecoding binnen een organisatiecontext, met aandacht voor governance, kwaliteitsborging en de stap van prototype naar productie.

Vibecoding is in principe neutraal ten opzichte van compliance-eisen -- het is een werkwijze, geen tool. Organisaties in ISO 27001-gecertificeerde omgevingen kunnen vibecoding inzetten als ze duidelijke spelregels hebben: welke data mag in welke tools, wie is verantwoordelijk voor wat er gebouwd wordt, en hoe vindt kwaliteitscontrole plaats voordat iets de productie ingaat.

Vibecoding is het meest waardevol voor interne tooling, prototypes en toepassingen met een beperkt risicoprofiel. Zodra software mission critical wordt of klantprocessen raakt, zijn aanvullende eisen op het gebied van architectuur, security en beheer onvermijdelijk.

Door governance vooraf in te richten: spelregels over welke tools mogen, wie verantwoordelijk is en wat de criteria zijn voor productie.

Vibecoding is het startpunt -- AI schrijft code op basis van instructies in gewone taal. AI-Native Engineering is de professionele methodiek met gestructureerde samenwerking, kwaliteitsborging en schaalbaarheid. Vibecoding is het startpunt. AI-Native Engineering is wat er daarna komt.

Adaptive Cards zijn interactieve berichten die de actie brengen naar de plek waar je al werkt, zoals Teams en Outlook. In plaats van een melding die je naar een ander scherm stuurt, handel je de taak direct in het gesprek af. Dat scheelt klikken en context-switches.

Dat hangt af van hoeveel grip je nodig hebt. Voor voorspelbare, controleerbare processen past vaak een deterministische flow. Waar interpretatie nodig is, werkt een autonome agent beter. Wij helpen organisaties in Nederland die afweging per proces te maken, met oog voor auditability en vertrouwen.

Met vibecoding bouw je in minuten iets werkends door met AI te praten. Dat voelt geweldig, tot je oplossing moet schalen, integreren of onderhouden worden door iemand anders. Met fusion development houd je die snelheid, terwijl een engineer verantwoordelijk blijft voor structuur en keuzes.

De EPPC trekt architecten, developers en IT-beslissers, ook veel uit Nederland, die verantwoordelijkheid dragen voor Power Platform en AI. Het is een plek voor mensen die voorbij het experimenteren zijn en willen weten hoe ze slimme technologie verantwoord laten landen in hun organisatie.

Blis Digital begeleidt organisaties door heel Nederland bij low-code, fusion development en AI op het Power Platform. We denken mee over de ontwerpkeuzes: wanneer je AI autonoom laat werken en wanneer je bewust grip houdt, zodat technologie het werk eenvoudiger maakt in plaats van drukker.

Een PCF-component (Power Apps Component Framework) is een custom bouwsteen waarmee je de interface van Power Pages of Power Apps uitbreidt. Ruben zette het in als Single Page Application, omdat de standaard interface van Power Pages te generiek was voor de gebruikerservaring die hij voor ogen had.

De gebruikersgroep bleek ook extern. Bij een Canvas App betaal je licenties per unieke gebruiker, wat bij incidenteel gebruik snel oploopt. Power Pages is gemaakt voor externe gebruikers en blijft kostenefficiënt bij sporadisch gebruik, terwijl het volledig in het Power Platform geintegreerd blijft.

Rollen worden minder absoluut. Een consultant die vroeger stopte bij low-code kan nu full-code oppakken waar de oplossing dat vraagt. Dat raakt hoe je teams samenstelt, hoe je projecten prijst en wat je van een consultant mag verwachten. Blis ziet deze verschuiving in de eigen praktijk terug.

De mens neemt elke beslissing. AI schrijft codevoorstellen en denkt mee, maar de consultant controleert elk voorstel, test direct en gooit weg wat niet past. Human-in-the-loop is de kern: zonder kritische validatie van wat AI genereert, valt de kwaliteit van de oplossing weg.

Als het full-code component omvangrijk of bedrijfskritisch is. Dan weegt de kwaliteitsborging zwaarder en is een ervaren developer of pair engineering verstandiger. Vibecoding werkt goed zolang low-code het fundament vormt en full-code alleen op specifieke plekken waarde toevoegt.

Blis onderscheidt vier niveaus: prototyping, single-user applicaties, collaboratieve applicaties en mission critical software. Bij elk niveau nemen de complexiteit en de risico's toe. Prototypes en single-user tools kun je prima zelf vibecoden, bij gedeelde en bedrijfskritische systemen komen veiligheid en continuiteit onder druk.

Bij collaboratieve applicaties loggen meerdere gebruikers in dezelfde database in en voeren ze gelijktijdig acties uit. Dan krijg je te maken met rollen, rechten en data-integriteit. AI schrijft goede losse functies, maar heeft moeite met de diepe architectuur van gedeelde systemen. Zonder technische kennis loop je vast.

Blis haalt je applicatie door een eigen AI-framework met vaste regels en guardrails. Engineers bouwen de app daarmee opnieuw op of optimaliseren die, zodat security, performance en schaalbaarheid geborgd zijn. Zo hoeft niet alles met de hand opnieuw, maar wordt de oplossing wel veilig en toekomstbestendig.

Wat is jouw technische kennis, en wat is jouw risicobereidheid? Hoe hoger het niveau waarop je bouwt, hoe zwaarder die twee vragen wegen. Bij mission critical software zijn de gevolgen voor de continuiteit van je bedrijf te groot om zonder senior engineer te werken.

Zodra je richting mission critical software gaat: systemen die 24/7 draaien, veel gebruikers tegelijk bedienen en gevoelige data verwerken. De sprong van niveau 3 naar 4 is geen geleidelijke groei. Op dat punt wordt assurance noodzakelijk en schakel je een ervaren engineer in.

FTRSA staat voor FastTrack Recognized Solution Architect, een titel die Microsoft toekent aan architecten met bewezen expertise in het ontwerpen van complexe klantoplossingen op Power Platform of Dynamics 365.

In 2026 zijn dat er drie: Elianne Burgers, Albert-Jan Schot en Richard Wierenga. Ze werken alle drie bij Blis Digital.

Ja. De titel geldt een jaar. Microsoft beoordeelt jaarlijks een recente klantcase en bepaalt of de erkenning verlengd wordt.

Je werkt met een bewezen specialist voor complexe, meerjarige oplossingen, met een directe lijn naar Microsoft bij technische uitdagingen en toegang tot een internationaal netwerk van vakgenoten.

Snelheid zonder kaders bouwt schuld op. Voorkom het met duidelijke grenzen (wat mag gevibecoded worden, wat vraagt engineering), reviews en tests op AI-gegenereerde code, en een vast pad van prototype naar productie. Zo houd je het tempo van AI zónder dat je landschap onbeheersbaar wordt.

Spreek af dat AI-output verkenning is. Het prototype dient om richting te kiezen en feedback te halen bij gebruikers. Daarna bouwen developers de echte implementatie op jullie eigen design system, met code review en tests als poortwachter. Leg die afspraak vast in je definition of done, zodat snelheid later geen technische schuld oplevert.

Kijk verder dan de functies. Vraag de leverancier waar data staat, of jouw input wordt gebruikt voor training, en of er een verwerkersovereenkomst is. Tools met EU-hosting en een zakelijk abonnement geven die garanties vaker dan gratis versies. Laat je security officer de shortlist beoordelen voordat designers ermee aan de slag gaan.

Reken eerder in dagen dan in weken. Een verkennend prototype kost doorgaans een tot drie designdagen tegen een gangbaar Nederlands uurtarief. De grootste variabele is de voorbereiding: hoe scherper je doel, doelgroep en data zijn, hoe minder iteraties je nodig hebt. Onduidelijke opdrachten maken het traject duurder dan de tool zelf.

Omdat deelnemers echt klikken en daardoor vastlopen op concrete stappen. Ze reageren op gedrag in de interface, en dat levert scherpe feedback op: deze knop hoort hier. Nederlandse opdrachtgevers zeggen doorgaans direct wat er schuurt, dus je haalt in een sessie beslissingen die anders meerdere mailrondes kosten.

Vraag vooral naar regie. Kan iemand goede opdrachten formuleren, context meegeven en output beoordelen tegen jullie doel en design system? Toolkennis leert iemand in weken. Zoek daarnaast ervaring met klantsessies, want prototypes valideren met echte gebruikers bepaalt of een idee klopt voordat developers eraan beginnen.

Leg vast wie de code reviewt, wie eigenaar is van het intellectueel eigendom en welke AI-tools mogen worden gebruikt. Vraag ook hoe je partner omgaat met code die je team later zelf moet onderhouden. Zonder die afspraken weet je bij oplevering niet waar de kennis zit.

Laat juniors vooral code lezen, reviewen en uitleggen aan een collega of klant. Geef ze bewust opdrachten zonder AI, zodat ze de basis onder de knie krijgen. Combineer dat met pair programming, waarin een senior toont hoe je output van AI beoordeelt en bijstuurt.

Reken op grofweg 20 tot 100 euro per developer per maand voor een tool als Claude Code of Copilot. De grootste kostenpost is de leercurve: prompten, context aanleveren en reviewen vragen begeleiding. Plan daar een paar weken voor in, anders blijft het bij losse experimenten.

Omdat de administratieve kant, denk aan een database en rechtenmodel, in low-code snel staat, terwijl de gebruikersinterface vaak stug klikwerk blijft. Door daar een gegenereerde front-end tegenaan te zetten, houd je de snelheid van low-code en de vrijheid van eigen code. Je bouwt bovendien geen backend.

Juridisch verandert er weinig: de leverancier blijft verantwoordelijk voor wat hij oplevert, ongeacht welke tool de code typte. Praktisch betekent het dat review, tests en documentatie zwaarder wegen. Vraag je leverancier hoe hij aantoont dat gegenereerde code is gecontroleerd, en leg dat vast in de opdracht.

Leg ze vast als templates in je repository, naast de code die ze oplevert. Een patroon beschrijft input, output, foutafhandeling, performance-eis en testvoorbeelden, zodat iedereen dezelfde constraints meegeeft. Laat een tech lead nieuwe patronen reviewen zoals je code reviewt.

Zodra het draait op productiedata en de fouten die je in de praktijk ziet worden opgevangen. Concreet: tests op de kritieke paden, asserts die onrealistische waarden blokkeren, type hints als semantische grenzen en monitoring op de eerste weken live. Laat een senior developer de architectuur nog een keer doorlopen.

Meestal omdat een iteratie eindigt zonder werkende software. Als je twee of drie ronden achter elkaar uitbreidt zonder te testen tegen echte data, stapelen de aannames zich op en weet je niet meer welke stap de fout introduceerde. Sluit elke week af met iets dat draait.

Verschillen tussen twee oplossingen verraden waar het model iets verzint. Bij deze Competitive Validation laat je AI hetzelfde probleem op twee manieren aanpakken: wijken de uitkomsten fundamenteel af, dan klopt er iets niet. Zo vingen we code die asynchroon leek en in werkelijkheid alles sequentieel uitvoerde.

Houd het achter de hand als achtergrondkennis en geef AI per iteratie alleen de constraints die dan gelden. Wij startten met een bestek van 50 pagina's en kregen code terug die technisch correct maar praktisch onbruikbaar was. Werk per opdracht met input, output, foutafhandeling, performance en tests.

Behandel AI-output als code van een junior: elke pull request gaat langs een mens voordat hij gemerged wordt. GitHub Copilot genereert bij Blis Digital minimaal 80 procent van de unit tests, maar een developer controleert de dekking en de randgevallen zelf.

Reken op enkele tientjes per developer per maand voor een licentie zoals GitHub Copilot. Daarnaast kost het je team de eerste weken tijd om te leren waar de tool betrouwbaar is en waar hij misgaat. Begin met een team en meet daarna pas breder uit.

Leg vast welke AI-tools zijn toegestaan, wie de gegenereerde code reviewt en wie eigenaar is van het resultaat. Vraag ook of prompts en code bij de toolleverancier terechtkomen. Zet dit in de samenwerkingsafspraken, zodat het blijft staan als het team wisselt.

Onder de AVG mag je persoonsgegevens niet zonder grondslag bij een externe partij laten verwerken, en een AI-codetool is zo'n partij. Werk in prompts met testdata of geanonimiseerde data. Check in de verwerkersovereenkomst waar je data staat en of die voor training wordt gebruikt.

Bij kleine visuele aanpassingen, zoals een banner verplaatsen of een knop toevoegen. Tools als Builder.io en Visual Copilot maken dat mogelijk zonder designkennis, waardoor je product owner niet op een designer hoeft te wachten. Houd je designer verantwoordelijk voor het designsysteem zelf.

Begin klein: een team, een repository en enkele weken de tijd met GitHub Copilot. Spreek vooraf af wat je meet, bijvoorbeeld doorlooptijd van een story en het aantal opmerkingen bij code review. Beslis daarna pas over uitrol naar de rest.

Kritisch denken en oordeel blijven mensenwerk. AI-tools brengen efficiëntie en helpen bij leren en problemen oplossen, maar de kwaliteit van je werk hangt nog steeds af van jouw ervaring. Jij bent verantwoordelijk voor het resultaat, ook als GitHub Copilot de code voorstelt.

Je verschuift van zelf code typen naar het checken en bijsturen van AI-resultaten. GitHub Copilot doet directe codevoorstellen op basis van je projectcontext, terwijl jij de zwaktes compenseert. Reken erop dat je meer tijd in review kwijt bent dan in typen.

Meestal door gebrek aan context: GitHub Copilot leunt op je repository, dus bij een rommelige codebase en dunne documentatie zijn de suggesties zwakker. Zonder afspraken over code review verdwijnt de tijdwinst daarna in het herstellen van fouten. Meet per team, een nieuw project geeft andere cijfers dan een oude monoliet.

Zodra je behoefte niet bij de sterke punten van Copilot past. Amazon Q, JetBrains AI en Phind hebben elk eigen sterke en zwakke punten, en voor ontwerp en modelgedreven werk kijk je eerder naar Visual Copilot van builder.io. Vergelijk ze op jouw programmeerbehoeften.

Blis-testers gebruiken AI voor drie dingen: Gherkin-scenario's schrijven, met V0 snel een prototype tonen aan de klant en met Playwright MCP automatisch tests genereren en uitvoeren. Waar een test vroeger uren kostte, is dat nu vaak een kwestie van minuten.

Ja, testers blijven nodig. Risicogebaseerd testen vraagt om de juiste keuzes maken over wat je test, en dat vraagt creativiteit en pragmatisme die AI niet heeft. AI versnelt het werk, maar de tester bepaalt waar de aandacht naartoe moet.

De tester verschuift van zelf alles controleren naar samenwerken met een digitale sparringpartner. Voor een test vraagt de tester eerst aan AI hoe die het zou aanpakken, en test dan scherper op basis van die input. Zo ontstaat testen als tweegesprek in plaats van een eenmansklus.

AI helpt testers om requirements en acceptatiecriteria op te stellen in de Gherkin-structuur ('Given, When, Then'), zodat klant en developer hetzelfde plaatje zien. Met tools als V0 laat de tester binnen enkele minuten een werkende flow zien in plaats van een beschrijving op papier.

Met Playwright MCP tikt de tester het gewenste testscenario in gewone taal in, en AI schrijft en voert de technische test uit in de browser. Blis-testers zien daarbij tien keer sneller resultaat, soms wel honderd keer.

Progressive specificity betekent dat je AI in stappen steeds specifieker maakt, in plaats van in één keer een compleet bestek te geven. Blis begint breed, bijvoorbeeld 'bouw een systeem dat data uit websites haalt', en voegt per week een nieuwe eis toe op basis van wat echt nodig blijkt. Zo evolueert het systeem organisch.

Blis gebruikt drie controles: competitive validation, waarbij AI hetzelfde probleem op twee manieren oplost zodat afwijkingen opvallen, reality checkpoints met simpele asserts in de code, en semantic barriers via strikte types die AI moet respecteren. Zo vang je het op als AI code genereert die er goed uitziet maar iets anders doet dan gevraagd.

De developer wordt minder uitvoerder en meer ontwerper: van syntax schrijven naar intentie articuleren. Blis ziet teamleden die zonder een sorting algorithm te kunnen schrijven, toch complete systemen bouwen, omdat ze helder kunnen beschrijven wat het systeem moet doen. De computer begrijpt zo eindelijk wat je bedoelt.

Een systeem dat traditioneel zes maanden kostte, levert Blis nu op in zes weken. Dat komt doordat AI grote delen van de bouw overneemt, terwijl mensen zich richten op architectuur en context. Doordat er vanaf dag één met werkende software wordt getest, hebben AI-first systemen bij Blis juist minder bugs.

Evolutionary architecture betekent dat een systeem groeit via werkende tussenstappen in plaats van vooraf volledig gepland te worden. Blis begon bijvoorbeeld met een simpele scraper voor krantenkoppen en breidde die stap voor stap uit met nieuwe sites, JavaScript-rendering en slimme detectie. Na twee maanden had het systeem functies die van tevoren onmogelijk te specificeren waren.

Bij losse prompts vraag je AI af en toe iets sneller te doen, bijvoorbeeld in ChatGPT. Bij een agentic workflow richt je het hele werkproces zo in dat AI structureel een deel overneemt, met vaste constraints en vangrails. Dat verschil bracht Blis naar 30.000 regels geteste code in twee weken.

Houd de unieke, waardevolle businesslogica zelf en laat een AI-agent de rest bouwen, zoals validatie, UI en foutafhandeling. Bij Blis werkte een engineer zo aan een complexe feature met een strakke deadline en had binnen anderhalve dag een werkende versie. Dat scheelde volgens hem minstens twee weken traditioneel bouwwerk.

Een LLM-agent simuleert gebruikersgedrag, draait honderden testscenario's en signaleert afwijkingen in de logs. Dat scheelt uren repetitief handwerk en levert sneller inzicht in waar iets misgaat. Menselijke validatie blijft nodig, maar de testrol verschuift van zelf testen naar testprocessen ontwerpen en bewaken.

De twee grootste valkuilen bij Blis waren onbewust honderden euro's aan AI-tokens verbruiken zonder resultaat, en onbruikbare code krijgen omdat de AI te weinig context had. Die fouten hoorden bij het leerproces: elke misser leerde het team hoe ze de volgende opdracht beter organiseerden.

Ja, een Blis-productmanager gebruikte één Deep Research-prompt om AI een volledig ontwerpvoorstel te laten maken voor credential lifecycle automation. Binnen een half uur had hij user stories, flowdiagrammen, API-designs en een vergelijking van oplossingsrichtingen, een basis waar hij zelf sneller op kon doorbouwen.

Blis Chatty is de eigen GPT-4o-chatbot van Blis Digital in Microsoft Teams, die het team dagelijks helpt bij allerlei taken naast Microsoft Copilot. Developers en testers zetten hem in voor snellere ondersteuning bovenop externe tools zoals GitHub Copilot. Zo blijft AI-hulp direct beschikbaar in de tool waar het team al de hele dag in werkt.

In plaats van lange beschrijvingen te schrijven, laten Blis-testers op basis van screenshots of video's automatisch een rapportage genereren. Dat scheelt schrijfwerk en houdt de rapportage consistent van vorm. Het grootste voordeel is dat de tester in de flow blijft en zich kan richten op complexere vraagstukken.

AI-tools genereren inmiddels minimaal 80% van de unit tests automatisch, zonder dat een developer ze los moet uitschrijven. Blis gebruikt daarvoor GitHub Copilot, wat tijd bespaart en de kwaliteit, dekking en consistentie van tests verbetert.

Als je developers of een agency inhuurt, ga je merken dat repetitieve taken sneller gaan en developers meer tijd overhouden voor complexere vraagstukken. AI is nog geen vervanging voor menselijke creativiteit en kritisch denkvermogen, dus de kwaliteit hangt nog altijd af van de ervaring van het team.

Tools als Microsoft Playwright en ZeroStep maken het bouwen en onderhouden van UI-tests sneller en efficiënter, ook voor mensen zonder diepgaande testachtergrond. Bij Builder.io's Visual Copilot geldt hetzelfde voor visueel ontwerp: een instructie als 'verplaats de banner naar rechts' is al genoeg voor een bruikbaar ontwerp.

Ook een krachtige tool als GitHub Copilot is niet onfeilbaar, net zoals AI-foto's soms een hand met zeven vingers opleveren. Grappig op social media, maar niet geschikt voor een bedrijfsmatige context waar een subtiele fout in productie terechtkomt. Jij blijft verantwoordelijk voor het resultaat, ook als AI de code heeft voorgesteld.

Blis vergelijkt onder meer Amazon Q, JetBrains AI en Phind, elk met eigen sterke en zwakke punten. Phind is bijvoorbeeld sterk in het beantwoorden van vragen over je eigen code, terwijl GitHub Copilot vooral uitblinkt in realtime codesuggesties op basis van projectcontext. Welke tool het beste past, hangt af van je specifieke programmeerbehoefte.

Visual Copilot past AI toe op het ontwerpproces zelf, van eerste schets tot werkende interface. De tool laat zien hoe AI ook modelgedreven ontwikkeling kan versnellen. Dat geeft een kijkje in een toekomst waarin AI verder gaat dan programmeren alleen.

Softwareontwikkeling staat aan de vooravond van een grote verandering, en wie nu wacht, loopt straks achter de feiten aan. Blis adviseert vandaag te beginnen: experimenteer met een AI-tool op een klein onderdeel en leer wat het voor jouw ontwikkelproces betekent. Zo sta je aan de winnende kant zodra AI-ondersteund ontwikkelen de norm wordt.

Nee, AI-tools brengen efficiëntie en zijn waardevol bij leren en problemen oplossen. Het kritische denken en de creativiteit van een developer blijven het unieke menselijke aandeel in softwareontwikkeling. De kwaliteit van de software hangt dus nog steeds af van wie de tool bestuurt.