Maakt AI nearshore developers overbodig?

AI verlaagt de waarde van laag-contextueel uitvoerwerk en verhoogt de waarde van engineers die output kunnen beoordelen en verantwoordelijkheid nemen. We zetten het onderzoek naast elkaar en benoemen per bron wat het wel en niet aantoont.

De vraag komt bijna elke maand langs, en hij is terecht: als AI een groeiend deel van de code schrijft, waarom zou je dan nog developers uit Kosovo aan je team toevoegen?

Het eerlijke antwoord is dat de vraag te grof gesteld is. Er is werk waarvan de waarde daalt en werk waarvan de waarde stijgt, en die twee zitten in hetzelfde vak. Hieronder zet ik het beschikbare onderzoek naast elkaar, benoem ik per bron wat die wel en niet aantoont, en beschrijf ik wat dat betekent voor de keuze tussen je eigen team, een geïntegreerde nearshore engineer en een leverancier die losse tickets afwerkt. Waar het onderzoek ophoudt en onze eigen analyse begint, zeg ik dat erbij.

Het korte antwoord

Voor bepaalde afgebakende taken kan minder capaciteit nodig zijn. Eerste versies, boilerplate, testopzet, documentatie en eenvoudige schermen gaan sneller dan twee jaar geleden. Dat merk je in elk team dat de tools serieus gebruikt.

Dat is niet hetzelfde als het verdwijnen van complete productteams. Er is geen onderzoek dat aantoont dat organisaties standaard een vast percentage minder developers nodig hebben. Wat er is, zijn metingen per taak, enquêtes over gebruik en vertrouwen, gebruiksdata van modelaanbieders en verwachtingen van werkgevers. Die vier soorten bewijs meten verschillende dingen, en dat is precies waarom de discussie zo rommelig is.

Onze eigen conclusie, en dat is een standpunt van tre plus en geen onderzoeksuitkomst: het model van zo goedkoop mogelijke handjes op afstand staat onder druk. De engineer die AI als gereedschap gebruikt, output kan tegenspreken en verantwoordelijkheid neemt voor productiecode wordt juist waardevoller.

Wat AI aantoonbaar al verandert

Het duidelijkst zichtbaar is de verschuiving binnen taken. Codegeneratie, het opzetten van tests, documentatie, eerste versies van een interface en terugkerend omzetwerk zijn sneller geworden. Dat is geen belofte uit een verkooppraatje: het is het werk waar developers de tools zelf het vaakst voor inzetten.

De Stack Overflow Developer Survey 2025 is hier de bruikbaarste graadmeter, en het is enquêteonderzoek onder deelnemers die zich zelf aanmelden. Het beeld dat daaruit komt is dubbel: de adoptie is hoog, het vertrouwen in de uitkomst blijft beperkt. Developers gebruiken de tools dagelijks en controleren, debuggen en herschrijven de output alsnog zelf. Precies dat controleren is werk dat een mens moet kunnen doen, en dat vraagt kennis van de codebase.

De Anthropic Economic Index van 28 april 2025 kijkt vanaf de andere kant: gebruiksdata van één aanbieder over hoe zijn eigen modellen worden ingezet. Daaruit blijkt dat coding agents veel taken zelfstandig oppakken, en tegelijk dat er feedbackloops en menselijke validatie omheen blijven bestaan. Anthropic benoemt zelf dat de dataset alleen het gebruik van eigen producten toont en dus geen representatief beeld van de hele markt geeft. Houd er ook rekening mee dat een modelaanbieder een belang heeft bij het beeld dat zijn producten veel werk overnemen.

Het onderscheid dat in bijna elke discussie ontbreekt: het automatiseren van een taak is niet het vervangen van een functie. Een developer die alleen tickets omzet naar code voert weinig taken uit die niet te automatiseren zijn. Een engineer die een productbeslissing terugduwt, een migratie in stappen plant, een securityrisico ziet in een gegenereerde query en het onderhoud van vier jaar oude code kent, doet iets anders. Beide heten developer. Ze zijn niet op dezelfde manier vervangbaar.

Waarom de onderzoeken elkaar lijken tegen te spreken

Wie drie koppen leest over AI en productiviteit, ziet drie richtingen. Dat komt niet doordat een van de onderzoekers ongelijk heeft, maar doordat ze verschillende dingen meten bij verschillende mensen.

DORA 2025: enquête- en veldonderzoek

Het DORA-rapport State of AI-assisted Software Development 2025 is enquête- en veldonderzoek onder softwareteams. De kernboodschap is dat AI vooral een versterker is van wat er al is. Teams met heldere prioriteiten, een gezonde deliverystroom en goede review- en testgewoonten halen er meer uit. Teams met onduidelijke prioriteiten en een brakke pijplijn versterken ook hun problemen: meer output die niemand kan beoordelen. Tools alleen leveren geen volwassen engineeringorganisatie op.

Wat dit niet aantoont: dat een specifiek team met een specifiek toolpakket een bepaalde snelheidswinst haalt. Het is zelfrapportage op organisatieniveau, geen gemeten doorlooptijd per ticket.

Stack Overflow 2025: enquête met zelfselectie

De enquête laat zien wat developers doen en wat ze ervan vinden. Sterk punt is de schaal, zwak punt is de zelfselectie: mensen die de survey invullen zijn niet automatisch een doorsnede van alle developers. Gebruik hem dus voor richting (breed gebruik, gemengd vertrouwen), niet als bewijs voor rendement.

METR: experiment met een kleine groep

Het productiviteitsonderzoek van METR is het interessantste stuk bewijs, omdat het echt meet in plaats van vraagt. In de studie uit 2025 werkten ervaren open-sourcedevelopers aan taken in hun eigen codebase, en het opvallende resultaat was vertraging in plaats van versnelling: deelnemers dachten sneller te zijn dan ze waren. In de update van 24 februari 2026 wijzen nieuwere metingen mogelijk op versnelling, maar METR is daar zelf voorzichtig over, omdat selectie-effecten in wie meedoet en welke taken worden gekozen de uitkomst kunnen vertekenen.

Wat dit betekent voor jouw team: het is een experiment met een kleine groep in een specifieke situatie, namelijk zeer ervaren mensen in code die zij al door en door kennen. Dat is de situatie waarin AI het minst toevoegt. In onbekende code of bij standaardwerk kan het beeld anders zijn. Precieze percentages uit dit onderzoek doorrekenen naar personeelsplanning is niet verantwoord, en METR zegt dat zelf.

World Economic Forum: verwachtingen van werkgevers

Het Future of Jobs Report 2025 is een uitvraag bij werkgevers over wat zij verwachten. Daarin staan AI en machine learning, big data en softwareontwikkeling tegelijkertijd bij de rollen en vaardigheden waarvan de vraag volgens werkgevers het snelst groeit. Dat is nuttig als signaal over waar bedrijven denken te investeren, en het is uitdrukkelijk geen bewezen toekomstige uitkomst. Verwachtingen van werkgevers zijn eerder in de geschiedenis onjuist gebleken.

Eurostat: officiële statistiek

Eurostat publiceert cijfers over ICT-specialisten en moeilijk vervulbare vacatures. Twee dingen zijn daar relevant: een aanzienlijk deel van de bedrijven die ICT-specialisten zochten had moeite die vacatures te vullen, en een deel van de bedrijven laat ICT-functies uitvoeren door externe leveranciers.

Bij dat tweede punt gaat het vaak mis in samenvattingen. Dat externe leveranciers ICT-functies uitvoeren betekent niet dat die bedrijven hun hele ICT-afdeling hebben uitbesteed. Het kan om één functie gaan, om beheer van een systeem, om een tijdelijke opdracht. De statistiek zegt iets over de gewoonte om externe capaciteit te gebruiken, niet over de omvang daarvan per bedrijf.

Wat de verschillen verklaart

Zet je die bronnen naast elkaar, dan zie je vijf factoren die de uitkomst bepalen: het type taak (nieuw en afgebakend versus oud en verweven), de ervaring van de developer, de staat van de codebase, het teamproces rond review en testen, en de meetmethode zelf. Een onderzoek dat op één van die vijf anders is ingericht, komt tot een andere conclusie. Dat is geen tegenspraak, dat is het onderwerp.

Welk nearshore-model onder druk staat

Vanaf hier is het analyse van tre plus, gebaseerd op wat we bij klantteams zien, niet op onderzoek.

Het model dat het moeilijkst gaat krijgen is het model dat het altijd al lastig had, alleen valt dat nu sneller op. De kenmerken: prijs is het belangrijkste argument, het werk komt binnen als losse tickets, er zitten meerdere overdrachtsmomenten tussen de vraag en de code, de developer kent het product niet, kwaliteitscontrole gebeurt aan de kant van de klant en er is geen langdurig eigenaarschap omdat mensen rouleren.

In zo'n opzet is de bijdrage van de developer precies het deel dat AI het snelst opneemt: gespecificeerd werk zonder context uitvoeren. Als jouw eigen team een ticket met AI in een uur kan afronden, is een goedkope kracht die er twee dagen over doet en drie vragen terugstuurt geen besparing meer. Voeg daar review- en herstelwerk aan de klantkant bij en het rekensommetje kantelt helemaal.

Welk nearshore-model sterker kan worden

Ook dit is onze analyse. De opzet die volgens ons sterker wordt, ziet er anders uit: engineers werken in dezelfde sprint, dezelfde backlog, dezelfde tooling en dezelfde code review als het Nederlandse of Belgische team. Ze kennen het domein, ze zitten bij het overleg waarin de keuze wordt gemaakt en ze zijn er volgend jaar nog.

AI is in die opzet gereedschap van de engineer. Het versnelt het schrijven, het neemt het beoordelen niet over. Wie de gegenereerde oplossing moet kunnen afkeuren, heeft productkennis, ervaring met productie en de vrijheid nodig om nee te zeggen. Dat is precies het tegenovergestelde van een leverancier die afrekent per opgeleverd ticket.

Dat sluit aan bij wat DORA over versterking zegt: als een team goed staat, levert AI meer op. De volgorde is dus niet eerst goedkope capaciteit toevoegen en dan hopen op kwaliteit, maar eerst het team en het proces op orde, dan capaciteit toevoegen die daarin past. Hoe dat er in de praktijk uitziet, staat bij development team uitbreiden en bij dedicated developers.

Waarom nabijheid juist bij AI belangrijk blijft

Dit is het punt waar het meest overheen wordt gekeken. AI maakt de uitkomst van werk onvoorspelbaarder in plaats van voorspelbaarder. Een gegenereerde oplossing kan er goed uitzien en toch de verkeerde aanname bevatten. Dat merk je niet in een specificatie, dat merk je in een gesprek en in review.

Onvoorspelbaar werk vraagt korte feedbacklijnen: even een vraag stellen voordat iemand een halve dag de verkeerde richting inloopt, samen naar een pull request kijken, een keuze uitleggen aan degene die het domein kent. Een gedeelde Europese werkdag maakt dat praktisch mogelijk. Bij Kosovo is er geen tijdsverschil met Nederland en België, dus een vraag uit de ochtendstandup is dezelfde ochtend beantwoord.

Dat is een praktisch argument, geen productiviteitsclaim. Ik ga hier geen percentage aan hangen, want dat percentage kan ik niet onderbouwen. Wat ik wel zie: hoe vaker AI-output moet worden geverifieerd, hoe zwaarder overleg meeweegt. Het locatievraagstuk zelf, dus nearshore tegenover offshore, hebben we uitgewerkt in nearshore versus offshore development.

Welke setup past bij welke situatie

De volgende matrix is een standpunt van tre plus, bedoeld als denkhulp. Het is geen onderzoeksuitkomst en geen belofte over resultaat.

Die laatste rij is bewust hard opgeschreven. Wij leveren capaciteit binnen jouw team, geen uitbesteed project met resultaatgarantie. Wie dat laatste nodig heeft, is bij ons aan het verkeerde adres, en dat is beter vooraf duidelijk dan na drie maanden.

Hoe herken je een AI-native nearshore engineer?

In sollicitatiegesprekken zie ik twee valkuilen. De eerste is beoordelen op frameworks: iemand kent de juiste woorden en de codebase blijkt daarna toch te zwaar. De tweede is nieuw: beoordelen op promptvaardigheid. Vlot met een assistent werken is een handigheid, geen vak.

Waar we zelf op letten, en dit is onze werkwijze en geen norm uit onderzoek:

Probleembegrip

Vraagt iemand waarom iets gebouwd moet worden voordat het gaat over hoe. Kan iemand een eenvoudiger alternatief voorstellen dan wat er gevraagd is.

Productie-ervaring

Heeft iemand code onderhouden die live stond, met gebruikers die klagen en logging die je 's nachts wakker belt. Dat verandert hoe iemand naar een gegenereerde oplossing kijkt.

Review en tests

Kan iemand een pull request van een ander goed beoordelen, en een test schrijven die daadwerkelijk faalt bij het probleem dat hij moet vangen.

Security en datagebruik

Ziet iemand het verschil tussen een query die werkt en een query die te veel teruggeeft. Weet iemand welke data niet in een externe tool hoort.

Foutafhandeling en documentatie

Wat gebeurt er als de koppeling eruit ligt, en kan iemand een keuze opschrijven zodat een collega hem volgend jaar begrijpt.

AI-output kunnen tegenspreken

Het belangrijkste signaal: kan iemand uitleggen waarom hij een voorgestelde oplossing heeft weggegooid. Wie dat nooit doet, controleert niet.

Verandert AI de kostenberekening?

Ja, maar anders dan de meeste rekensommen suggereren. Minder geschreven regels code of minder uren typewerk betekent niet automatisch lagere totale kosten van een product. De kosten zitten voor een groot deel in onderhoud, in het inwerken van nieuwe mensen, in fouten die laat gevonden worden en in werk dat opnieuw moet.

Wat je volgens ons wel moet meewegen: hoe snel er iets van waarde live staat, wat de kwaliteit van de oplevering is, hoe onderhoudbaar het resultaat blijft, of dezelfde mensen er volgend jaar nog zijn en hoeveel productkennis er in je team achterblijft. Een goedkope oplossing die elk kwartaal opnieuw uitgelegd moet worden, is geen goedkope oplossing.

Nieuwe berekeningen ga ik hier niet maken, want dat zou een schijnnauwkeurigheid geven. Wat een uitbreiding per maand kost, staat op kosten developmentteam, en de bredere opbouw van werkgeverskosten staat in wat een developer je werkgever echt kost.

Wanneer nearshore géén goede keuze is

Er zijn situaties waarin ik zou afraden om nu capaciteit toe te voegen, hoe goed de kandidaat ook is.

Als er niemand aan jouw kant is die technisch kan meebeslissen, blijft ook een sterke engineer wachten op antwoorden. Als het om een klus van enkele weken gaat met een duidelijk einde, is dat een opdracht en geen rol. Als de zoektocht alleen over het laagste tarief gaat, kom je in het model terecht dat volgens ons juist onder druk staat.

Als je met gevoelige data werkt zonder afspraken over toegang, opslag en welke gegevens in externe tools mogen, dan is dat het eerste dat geregeld moet worden. En als de verwachting is dat één AI developer alle productproblemen oplost, dan wordt die verwachting niet waargemaakt, door niemand.

Conclusie

De vraag is niet of AI developers overbodig maakt. De vraag is welk soort developmentwerk nog waarde toevoegt naast een assistent die code kan schrijven.

Ons antwoord, als standpunt: niet meer developers inkopen, maar de juiste engineers toevoegen aan een team dat AI goed kan benutten. Nearshore heeft toekomst waar nabijheid, context, eigenaarschap en AI-vaardigheid samenkomen. Waar die vier ontbreken, was het model ook zonder AI al kwetsbaar.

Wil je weten welke rol in jullie situatie past, kijk dan bij AI engineers en developers inhuren. Werkt jullie team met Nederlandse of Belgische productteams en gaat het vooral over capaciteit, dan is nearshore developers de betere ingang.

Zes vragen die we vaak krijgen

Zijn door AI minder softwaredevelopers nodig?

Voor bepaalde afgebakende taken is minder tijd nodig, en dat kan de behoefte aan capaciteit voor dat werk verlagen. Een percentage dat voor alle organisaties geldt bestaat niet, en geen van de bronnen in dit artikel geeft er een. Werkgevers verwachten volgens het Future of Jobs Report 2025 juist groeiende vraag naar AI-, data- en softwarevaardigheden, en dat is een verwachting en geen gemeten uitkomst.

Gaat AI nearshore development vervangen?

Onze analyse: AI vervangt niet het samenwerken, het beoordelen en het eigenaarschap. Wat wel onder druk staat is het model van goedkope uitvoerende capaciteit zonder productcontext. Wie nearshore zo inzet, moet daar rekening mee houden.

Wat is een nearshore AI engineer?

Een engineer die in jouw team meedraait vanuit een land in dezelfde werkdag, en die AI-tools gebruikt als onderdeel van zijn vak: sneller een eerste versie, en daarna zelf beoordelen, testen en corrigeren. Het is geen aparte functietitel bij ons, het is een eis aan de manier van werken.

Wanneer is een AI Automation en Data Engineer nodig?

Als het knelpunt niet in je product zit maar tussen je systemen: koppelingen, dataflows, rapportages en werk dat elke week met de hand gebeurt. Dat is ander werk dan features bouwen. Zie AI automation en data engineers.

Waarom blijft tijdzone-overlap belangrijk?

Omdat AI-output geverifieerd moet worden en verificatie overleg vraagt. Een vraag die dezelfde ochtend beantwoord wordt, voorkomt een halve dag in de verkeerde richting. Dat is een praktisch voordeel, geen meetbare productiviteitswinst die ik hier ga beloven.

Is nearshore met AI automatisch goedkoper?

Nee. Minder uren typewerk is niet hetzelfde als lagere totale kosten. Onderhoud, inwerken, herstelwerk en continuïteit bepalen het grootste deel van de rekening. Vergelijk daarom time-to-value en onderhoudbaarheid, niet alleen het maandtarief.