Een jaar of twee geleden zou je een ingenieur kunnen vragen of ze AI gebruikten om code te schrijven, en dat kon nuttig zijn, maar vandaag wordt dat steeds normaler onderdeel van hoe software wordt gebouwd.
De verandering is verrassend snel gegaan. De 2026 Developer Ecosystem Survey van JetBrains, gebaseerd op meer dan 15.000 professionele ontwikkelaars, toont aan dat 90% van de ontwikkelaars tussen mei en juli 2026 minstens wekelijks AI-codeeragenten op het werk gebruikten, waarbij 68% ze dagelijks gebruikten. Claude Code alleen werd door ongeveer 39% van de professionele ontwikkelaars wereldwijd gebruikt op het werk, omhoog van 18% in januari. In de VS bereikte dat aantal 47%.
Dat betekent niet dat elke ontwikkelaar plotseling gestopt is met zelf code te schrijven. Het betekent dat de manier waarop ontwikkelaars werken verandert. In plaats van elke regel handmatig te schrijven, gebruiken veel ingenieurs nu AI om ideeën te verkennen, delen van een functie te schrijven, bugs op te sporen, onbekende code te begrijpen, tests uit te voeren en problemen sneller op te lossen.
Voor startups stelt dat een behoorlijk belangrijke vraag: Als uw ingenieurs al op deze manier werken, moet uw wervingsproces hen dan nog steeds beoordelen alsof AI niet bestaat?
AI heeft de manier waarop ingenieurs werken veranderd
Al lange tijd was GitHub Copilot de naam die de meeste mensen associeerden met AI-ondersteunde codering. Het werd een vertrouwd onderdeel van de toolkit voor ontwikkelaars, vooral omdat het rechtstreeks in de tools werkte die ontwikkelaars al gebruikten.
Maar de markt is snel veranderd.
Volgens de laatste survey van JetBrains daalde de adoptie van GitHub Copilot op het werk van 29% een jaar eerder naar 21% in mei-juli 2026. Claude Code groeide ondertussen van 18% in januari naar 39% in dezelfde periode. GitHub Copilot is nog steeds veel breder bekend, met 79% van de ontwikkelaars wereldwijd die ervan hebben gehoord, maar bewustzijn en daadwerkelijk gebruik zijn niet langer hetzelfde.
Dat is een belangrijke onderscheiding voor iedereen die ingenieurs aanneemt.
Je hoeft niet per se te weten welk AI-hulpmiddel momenteel het belangrijkste is. Hulpmiddelen zullen blijven veranderen. Wat telt is dat AI-codeeragenten zijn gegaan van iets waarmee ontwikkelaars experimenteerden naar iets dat velen nu als onderdeel van hun normale werkdag gebruiken.
Met andere woorden, het hulpmiddel kan veranderen, maar de nieuwe manier van werken is al hier.
Wat dit voor je team betekent
Dit is nog belangrijker wanneer je ingenieurs aanneemt voor een startup.
Een klein engineeringteam heeft het luxe niet om maanden elke functie handmatig op te bouwen. Je hebt mensen nodig die een probleem kunnen begrijpen, goede beslissingen kunnen nemen, snel kunnen handelen en weten wanneer iets nader onderzoek nodig heeft.
AI kan helpen bij een deel van dat werk, maar het vervangt niet de persoon die de beslissingen neemt. Dat is eigenlijk het belangrijkste deel van deze verschuiving.
Een ontwikkelaar kan een AI-agent vragen om iets in minuten op te bouwen. Maar overweeg wat er daarna gebeurt:
1. Wat gebeurt er als het antwoord er correct uitziet maar niet correct is?
2. Wat gebeurt er als de AI een belangrijke vereiste verkeerd begrijpt?
3. Wat gebeurt er als het iets in één deel van de applicatie verandert en stilletjes iets anders ergens anders breekt?
Dit zijn engineeringsvragen, en ze worden steeds belangrijker, niet minder.
JetBrains' onderzoek toont aan dat ontwikkelaars die deze hulpmiddelen gebruiken aanzienlijk variëren in hoeveel werk ze AI laten doen. Onder ontwikkelaars die Claude Code het meest gebruiken, rapporteert ongeveer 32% dat agenten meer dan 80% van hun code genereren. Dat betekent dat er geen enkele 'AI-ontwikkelaar'-workflow bestaat. Sommige mensen gebruiken agenten intensief, terwijl anderen nog steeds het meeste coderen zelf doen.
Het doel van je interview zou dus niet moeten zijn om iemand te vinden die AI alles laat schrijven. Het moet zijn om te begrijpen hoe ze het gebruiken en of ze weten wanneer ze het niet moeten vertrouwen.
Vraag niet alleen of ze AI gebruiken, vraag hoe ze het gebruiken
Als je je interviewproces bijwerkt, is een van de gemakkelijkste veranderingen ook een van de nuttigste. Stop met het behandelen van AI-ervaring als een eenvoudige ja-of-nee-vraag.
Heb je Claude Code gebruikt?
Ja.
Dat vertelt je niet veel.
Vraag de kandidaat in plaats daarvan om je te vertellen over een echte situatie:
1. Waar hebben ze een AI-coderingshulpmiddel gebruikt?
2. Wat probeerden ze op te bouwen?
3. Wat lieten ze het hulpmiddel afhandelen?
4. Wat hebben ze zelf gecontroleerd?
5. Maakte de AI een fout? Hoe hebben ze het opgemerkt?
Het antwoord kan je veel meer vertellen dan de naam van het hulpmiddel dat ze gebruiken.
Iemand die zegt: "Ik gebruik AI om sneller code te genereren," heeft je eigenlijk niet verteld hoe ze werken. Maar iemand die zegt: "Ik laat de agent de eerste versie afhandelen, maar ik merkte dat het een verkeerde aanname maakte over hoe onze databaserelaties werkten, dus ik stopte het en herschreef dat deel zelf," geeft je iets veel nuttigs.
Die persoon toont oordeel — en dat is de vaardigheid waar startups om geven.
AI-vaardigheid betekent niet AI-afhankelijkheid
Er is hier ook een valstrik. Alleen omdat iemand AI intensief gebruikt, betekent dat niet automatisch dat ze een beter ingenieur zijn. In feite kan het tegenovergestelde gebeuren wanneer iemand alles wat een AI-hulpmiddel produceert zonder begrijp accepteert.
De beste ingenieurs zijn niet noodzakelijk degenen die AI het meeste werk laten doen. Het zijn degenen die weten welk werk ze eraan moeten geven, hoe ze het moeten aansturen en hoe ze moeten controleren wat er terugkomt. Dit onderscheid wordt steeds belangrijker nu codeeragenten steeds grotere delen van het werk kunnen afhandelen.
Anthropic's analyse van ongeveer 400.000 Claude Code-sessies ontdekte dat mensen over het algemeen de planningsbeslissingen nemen, zoals bepalen wat moet worden gedaan, terwijl Claude veel van de uitvoering afhandelt. Het onderzoek ontdekte ook dat mensen met meer domeinkennis meer werk per instructie gedaan krijgen.
Dat is een nuttige manier om over de toekomst van engineering na te denken. De waarde ligt niet simpelweg in sneller code typen. Het ligt in weten wat moet worden gebouwd, de juiste richting geven, problemen opsporen en bepalen of het resultaat echt goed genoeg is om uit te brengen.
Wat moet "senior ingenieur" nu betekenen?
Deze verschuiving roept ook een grotere vraag op over anciënniteit.
Traditioneel was een senior ingenieur iemand die moeilijke technische problemen onafhankelijk kon oplossen, architectonische beslissingen kon nemen, het werk van anderen kon controleren en een team kon helpen vooruit gaan. Die dingen zijn nog steeds belangrijk, maar nu is er nog een laag.
Een sterke senior ingenieur zou steeds meer moeten weten hoe je effectief met AI-hulpmiddelen werkt zonder hun oordeel aan hen over te geven.
Ze zouden een groot probleem in kleinere stukken moeten kunnen opsplitsen, een AI-agent nuttige richting moeten geven, het resultaat moeten controleren, subtiele fouten moeten opsporen en moeten begrijpen wanneer iets handmatig doen eigenlijk veiliger of sneller is.
Dat is een ander soort vaardigheid dan eenvoudigweg weten hoe je code schrijft, en het is iets dat je interviewproces daadwerkelijk kan testen.
Het verschil komt snel naar voren
Stel je voor dat je twee ontwikkelaars voor dezelfde rol interviewt.
De eerste kandidaat vertelt je dat ze het afgelopen jaar AI gebruiken en zegt dat het hen helpt om "veel sneller code te schrijven."
De tweede kandidaat vertelt je over een recent project waarbij ze een AI-agent gebruikten om een databasemigratie door te werken. De agent produceerde het meeste van de initiële implementatie, maar de kandidaat merkte op dat het verkeerd had begrepen hoe historische records waren verbonden. Ze merkten het probleem op tijdens testen, veranderden de benadering en controleerden de uiteindelijke migratie handmatig voordat het in de buurt van productie zou gaan.
De tweede kandidaat heeft niet alleen aangetoond dat ze weten hoe je een AI-hulpmiddel gebruikt. Ze hebben iets veel waardevols aangetoond: oordeel. Ze weten wanneer ze moeten delegeren, wanneer ze het resultaat ter discussie moet stellen en wanneer ze zelf de controle moet nemen.
Dat is het soort signaal waar je wervingsproces naar zou moeten zoeken.
Wat oprichters moeten veranderen
Je hoeft je interviewproces niet in één nacht volledig te herbouwen. Begin met een paar eenvoudige veranderingen.
Vraag kandidaten hoe AI in hun normale workflow past. Geef ze een praktisch probleem en sta ze toe om de hulpmiddelen te gebruiken die ze normaal zouden gebruiken. Focus vervolgens je vragen op de beslissingen die ze namen, niet alleen op de code die ze produceerden.
Vraag wat de AI verkeerd deed, wat ze controleerden en wat ze niet zonder toezicht een AI-agent zouden laten afhandelen.
Die vragen geven je een veel duidelijker beeld van hoe iemand daadwerkelijk op je team zal werken.
En maak het interview niet tot een test van wie de meeste AI-hulpmiddelen kent, aangezien hulpmiddelen zullen veranderen. De belangrijke vaardigheid is leren hoe je met hen werkt zonder het vermogen om onafhankelijk na te denken te verliezen.
Dit gaat over meer dan Claude Code
De grootste verschuiving is niet dat Claude Code populair is geworden. Het is dat AI-ondersteunde ontwikkeling onderdeel wordt van de normale definitie van softwareengineering.
JetBrains ontdekte dat 90% van de professionele ontwikkelaars in het midden van 2026 minstens eenmaal per week AI-codeeragenten op het werk gebruikten. Dat betekent niet dat traditionele engineeringvaardigheden zijn verdwenen. Het betekent dat de baan nu nog een laag van het werken met machines omvat die steeds grotere delen van de implementatie kunnen afhandelen.
Dus als je wervingsproces kandidaten nog steeds alleen vraagt om te bewijzen hoe goed ze zonder AI code kunnen schrijven, meet je misschien alleen een deel van hoe ze eigenlijk zullen werken als ze je team toetreden.
De vraag is niet langer eenvoudig: "Kan deze persoon goede code schrijven?"
Het wordt steeds meer: "Kan deze persoon elk beschikbaar hulpmiddel gebruiken, inclusief AI, terwijl hij of zij toch goede engineeringsbeslissingen neemt?"
Dat is een veel nuttiger vraag voor een startup om te beantwoorden.
En als je niet de tijd hebt om je wervingsproces rond de manier waarop ingenieurs vandaag daadwerkelijk werken opnieuw op te zetten, helpt MyNextDeveloper door startups te verbinden met gevetted ingenieurs en AI-talent die moderne ontwikkelingswerkstromen begrijpen en vanaf dag één kunnen bijdragen.
TL;DR
AI-codeeringshulpmiddelen zijn snel onderdeel geworden van hoe ontwikkelaars werken, vooral bij startups. Dat betekent dat het aannemen van ingenieurs alleen op basis van hoe goed ze zonder AI code kunnen schrijven je niet langer het hele verhaal vertelt. Wat nu telt is of ze weten hoe je AI effectief gebruikt, zijn fouten opmerkt en zelf goede beslissingen neemt. De beste ingenieurs gebruiken AI niet alleen om sneller code te schrijven — ze weten wanneer ze het moeten vertrouwen, wanneer ze het ter discussie moeten stellen en wanneer ze het over moeten nemen.
Wil je een high-performance remote tech team bouwen?
Bekijk MyNextDeveloper, een platform waar je de top 3% van softwarehandwerkslieden kunt vinden die diep gepassioneerd zijn over innovatie. Onze op aanvraag, toegewijde en grondige softwaretalentoplossingen bieden een uitgebreide oplossing voor al uw softwarevereisten.
Bezoek onze website om te ontdekken hoe wij je kunnen helpen je perfecte team samen te stellen.
