Hoe ziet technische uitmuntendheid eruit in het tijdperk van AI?

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typfouten, want de bot is niet altijd 100% correct.

Hannah Clark: Het is een grap geworden dat het tijdperk van AI heeft geleid tot de ondergang van elke baan in de technologiesector. Er zijn dit jaar zelfs zoveel banen verdwenen dat ik verbaasd ben dat ik niet voor meer begrafenissen ben uitgenodigd. Productmanagement is dood, gebruikersonderzoek is dood en het meest schrijnende van alles: software-engineering is dood. Ik preek hier waarschijnlijk voor eigen parochie, maar iedereen die echt gelooft dat software-engineering dood is omdat je vriendelijke buurt-LLM code kan schrijven, is zelf absoluut geen engineer.

Mijn gast van vandaag, Cortex.io-oprichter Anish Dhar, zou zelfs beweren dat engineering absoluut niet dood is. Het wordt gewoon volwassen. Anish was eerder engineer bij Uber en richtte Cortex op om het voor engineers gemakkelijker te maken complexe codebases te begrijpen. Als engineer en als iemand wiens gebruikers engineers zijn, ziet hij in deze sector daadwerkelijk een evolutie in technische uitmuntendheid en een kloof tussen nieuwe en oude manieren om die te meten. We bespraken toekomstgerichte manieren om technische uitmuntendheid te meten en te evalueren, evenals een scherpe visie op de manier waarop de rage rond ‘vibe coding’ in dit gesprek past. Laten we beginnen.

O ja, we voeren dit soort gesprekken elke week, dus als dit je interessant lijkt, waarom schrijf je je dan niet in? Goed, laten we beginnen.

Welkom terug bij de podcast van The CPO Club. Ik ben hier vandaag met Anish Dhar. Hij is de oprichter van Cortex.io.

Anish, bedankt dat je vandaag tijd voor me hebt gemaakt.

Anish Dhar: Heel erg bedankt voor de uitnodiging.

Hannah Clark: Kun je ons iets vertellen over je achtergrond en hoe je bij je huidige rol bent beland?

Anish Dhar: Zeker. Ik ben medeoprichter en CEO van Cortex.io. We zijn ongeveer zes jaar geleden met het bedrijf begonnen, maar daarvoor werkte ik als engineer bij Uber. Daar ben ik mijn carrière begonnen en veel van de problemen die ik als engineer bij Uber tegenkwam, vormden de inspiratie voor alle redenen waarom we Cortex zijn gestart.

Ik had twee zeer goede vrienden. Uber heeft een enorme interne servicearchitectuur. Als engineer was het voor mij erg moeilijk om verschillende onderdelen van de codebase te begrijpen, vooral toen ik net begon. Er werden zoveel verschillende services gebouwd. Dat zorgde voor een enorme complexiteit. Ik sprak hierover met een goede vriend van me die engineer was bij een zeer kleine startup genaamd Lend.

Zij hadden slechts honderd engineers, terwijl Uber er meer dan duizend had. Toch liepen we allebei tegen vergelijkbare uitdagingen aan rond het organiseren en begrijpen van onze servicearchitectuur. Dat deed alarmbellen rinkelen. Als Uber aan het ene uiteinde van de schaal zat en dit andere bedrijf, dat nog maar net aan zijn microservices-reis begon, dezelfde problemen had, was het duidelijk dat dit een groot probleem in de sector was.

Daarom zijn we uiteindelijk het bedrijf gestart. We gingen door de Winter 20 Y Combinator-batch. En ja, snel vooruit naar vandaag: we hebben zojuist onze Series C-ronde afgerond en ik werk met enkele honderden verschillende ondernemingen die Cortex gebruiken om hun complexiteit te beheren.

Hannah Clark: Geweldig. Dat is een indrukwekkende reis en het is altijd mooi om te horen wanneer een bedrijf voortkomt uit een probleem dat je van binnenuit kent.

Daarover gesproken: in deze aflevering gaan we het hebben over technische uitmuntendheid en hoe die eruitziet in het huidige technologielandschap. Dit is dus natuurlijk een onderwerp dat gedurende je hele carrière dicht bij je heeft gestaan. Om te beginnen: hoe definieer je technische uitmuntendheid in 2025, en waarom wordt dit nu zo’n belangrijk aandachtspunt voor CTO’s en VP’s Engineering?

Anish Dhar: Absoluut, een goede vraag. Wat we bij Cortex ontdekten, is dat het gesprek lange tijd vooral draaide om de ontwikkelaarservaring. En de ontwikkelaarservaring is natuurlijk een zeer belangrijk onderdeel van elke engineeringorganisatie. Het gaat om eenvoudige dingen, zoals ervoor zorgen dat ontwikkelaars, wanneer ze bij een bedrijf komen, gemakkelijk hun interne systemen kunnen instellen en verbinding kunnen maken met GitHub en de verschillende tools die ze gebruiken. Of wanneer ze een service implementeren, moet de infrastructuur op de juiste manier zijn ingericht, zodat er niet veel probleemoplossing of extra stappen nodig zijn om dat voor elkaar te krijgen.

Wat we de afgelopen jaren echter vooral hebben gezien, is dat het gesprek is verschoven van alleen ontwikkelaarservaring naar wat wij technische uitmuntendheid noemen. Het grote verschil tussen beide is naar mijn mening dat technische uitmuntendheid echt draait om de focus van verschillende teams binnen je organisatie.

Je kunt denken aan SRE, beveiliging, ontwikkelaarsproductiviteit en zelfs ontwikkelaarservaring. Maar het brengt die teams echt in lijn met concrete bedrijfsresultaten. Dat is volgens mij het belangrijkste verschil: bij technische uitmuntendheid draait het om de vraag hoe het werk dat ik doe daadwerkelijk invloed heeft op het bedrijf en hoe het bedrijf ermee vooruitgaat.

De doelen lopen daarbij van de organisatie van de CEO helemaal door tot de specifieke SRE die eraan werkt. Een goed voorbeeld is dat we als organisatie sterk gericht zijn op het verbeteren van de klantervaring. Wanneer klanten ons product gebruiken, willen we dat het betrouwbaar is, omdat een betere klantervaring leidt tot meer omzet doordat mensen ons product vaker gebruiken.

Vanuit een initiatief rond technische uitmuntendheid kan je SRE-team dan bijvoorbeeld een checklist voor productiegereedheid proberen te implementeren. Voordat services worden geïmplementeerd, willen ze er zeker van zijn dat alle services aan de standaarden van de organisatie voldoen. Zo zie je hoe een initiatief dat bij het SRE-team begint, terugleidt naar een concreet bedrijfsresultaat dat voor de organisatie belangrijk is.

Ik denk dat het voor teams heel belangrijk is om op deze manier naar hun initiatieven te kijken, omdat het de waarde ervan bevestigt en de technische initiatieven afstemt op iets waar het bedrijf om geeft. Dat is volgens mij waar technische uitmuntendheid uiteindelijk om draait.

Hannah Clark: Interessant. En dit is, zoals je waarschijnlijk al vaak hebt beschreven, een soort eindeloze reis waarbij veel disciplines samenwerken.

Vertel eens over het raamwerk dat je hebt ontwikkeld. Hoe zien de belangrijkste pijlers eruit? Hoe bekijk je dit vanuit je eigen organisatie?

Anish Dhar: Je hebt helemaal gelijk. Het is echt een eindeloze reis. Veel bedrijven waarmee we werken, vooral grotere ondernemingen, hebben veel legacy-infrastructuur. Dat verschilt misschien van een nieuw bedrijf dat op nieuwere technologieën en mogelijk zelfs op AI als uitgangspunt is gebouwd.

Er zijn nog steeds verschillende initiatieven rond technische uitmuntendheid. Daarvoor is volgens mij een zeer doordachte aanpak nodig bij al deze verschillende teams: welk werk doen we en welke invloed heeft het uiteindelijk op de doelen rond bedrijfsmatige uitmuntendheid? Vanuit het perspectief van een raamwerk hebben we daarom sterk gewerkt aan de vraag: hoe definieer je technische uitmuntendheid voor jouw organisatie?

Wij denken dat het begint met bedrijfsmatige uitmuntendheid. Als leiderschapsteam heb je verschillende doelen. Die kunnen bijvoorbeeld te maken hebben met het ontsluiten van innovatie en het verkorten van de time-to-market. Misschien wil je kosten verlagen en efficiëntie verhogen. Het derde doel dat we meestal zien, en dat ik al noemde, is het verbeteren van kwaliteit en klantervaring.

Daaronder bevinden zich de pijlers van technische uitmuntendheid. Dat zijn de verschillende teams en professionals die de initiatieven vormen waarmee je deze uiteindelijke doelen bereikt. Denk aan snelheid, efficiëntie, beveiliging en betrouwbaarheid. Zelfs binnen die subcategorieën heb je initiatieven, zoals een beveiligingsmigratie of een checklist voor productiegereedheid.

Misschien probeer je een proces voor incidentbeheer te implementeren. Of je wilt iets eenvoudigs doen, zoals DORA-metrics bijhouden om vanuit productiviteitsperspectief te begrijpen hoe je engineeringteam presteert. De basis van elk initiatief rond technische uitmuntendheid bestaat uit wat wij graag de vier C’s noemen.

Dat zijn in wezen volledige zichtbaarheid, voortdurende verbetering, een consistente ontwikkelaarservaring en natuurlijk duidelijk eigenaarschap. Zonder eigenaarschap en inzicht in de verschillende onderdelen van je codebase en alle services is het erg moeilijk om deze initiatieven daadwerkelijk vooruit te helpen. Daarom merken we doorgaans dat het zonder die basis erg moeilijk is om initiatieven te realiseren.

We zien ook vaak dat interne ontwikkelaarsplatforms of interne portals een zeer sterke manier zijn om die basis te leggen. Het kan ook via interne tools, maar je hebt een soort systeem nodig waarmee je kunt begrijpen wat mensen bouwen, zodat je deze engineeringinitiatieven kunt stimuleren.

Hannah Clark: Ik wil even dieper ingaan op wat je zei over het meten van prestaties, want ik weet dat er enige spanning bestaat rond het meten van ontwikkelaarsproductiviteit en metrics zoals regels code.

Dat kan onder engineers nogal controversieel zijn. Hoe zouden engineeringleiders productiviteit op een meer holistische manier moeten meten, waarbij al deze C’s en dergelijke worden meegenomen?

Anish Dhar: Het interessante is dat ontwikkelaarsproductiviteit de afgelopen jaren vaak werd gekoppeld aan regels code of DORA-metrics. Er zijn allerlei verschillende raamwerken die volgens mij zijn bedacht om productiviteit eenvoudiger te maken, en er zit enige waarheid in de manier waarop die metrics worden berekend.

Regels code zijn geen goede indicatie van de vraag of iemand productief is. Maar als je kwartaal na kwartaal consequent nul regels code oplevert, is er duidelijk iets mis met de output. Ook bij het vergelijken van teams kan het soms interessant zijn om die gegevens te bekijken. Ik denk echter dat het gesprek is verschoven van “ik heb deze gegevens” naar “hoe zorg ik er daadwerkelijk voor dat engineers over die gegevens nadenken of ze verbeteren?”

Als je het echt ontleedt, is dat een heel ander probleem. Een veel moeilijker probleem zelfs. Iedereen kan je GitHub-API aanroepen, deze metrics ophalen en een momentopname maken van hoe je team ervoor staat. Maar alleen omdat ik een engineer een reeks metrics laat zien en probeer uit te leggen dat we die metric moeten verbeteren, betekent dat nog niet echt iets voor die engineer.

Ik ben gericht op het bouwen van software voor het bedrijf en ik wil dat meestal zo efficiënt mogelijk doen. Het gesprek met de CTO’s met wie wij werken, is echter sterk verschoven naar de vraag: ik heb nu deze metrics, maar hoe vertaal ik die naar iets waar een engineer om geeft?

Ik denk dat technische uitmuntendheid daar zo’n cruciale rol speelt. Engineers, vooral degenen die bij snelgroeiende bedrijven werken, willen dat het bedrijf groeit. Ze bouwen producten omdat ze de impact van hun werk op klanten willen zien.

Ontwikkelaarsproductiviteit is volgens mij verschoven van “hier is een verzameling metrics” naar “dit zijn als bedrijf de zaken die voor ons belangrijk zijn”. Deze metrics vertellen daar als onderdeel van een groter verhaal iets over. Voor een engineer gaat het er echter om hoe je dat vertaalt naar het eigenlijke werk dat ik doe, zodat het betekenis krijgt.

Dat is volgens mij de belangrijkste verschuiving die we zien.

Hannah Clark: Heb je gemerkt dat er verouderde evaluatiemethoden of KPI’s zijn waarvan mensen beginnen af te stappen? Wat zou je de nieuwe manier van evalueren noemen? Heb je specifieke voorbeelden?

Anish Dhar: Ik zou productiviteit zien als een combinatie van input- en outputmetrics. Outputmetrics zijn alle klassieke raamwerken die je tegenwoordig ziet om ontwikkelaarsproductiviteit te volgen. Een van de bekendste en populairste voorbeelden zijn DORA-metrics. Dat is een reeks metrics die een holistisch beeld zouden moeten geven van hoe je engineeringteam presteert.

De meeste engineeringorganisaties willen deze outputmetrics zien en vastleggen. Dat brengt ons terug bij wat ik eerder zei: hoe beïnvloed ik die metrics daadwerkelijk en zorg ik ervoor dat ze bewegen? Wat we vooral bij onze klanten zien, is het belang van inputmetrics die outputmetrics beïnvloeden.

Neem bijvoorbeeld de implementatiefrequentie. Dat is een goede metric, omdat de snelheid waarmee je engineers software implementeren waarschijnlijk een goede voorspeller is van hoe snel je product evolueert. Uiteindelijk bepaalt dat hoe je de concurrentie voorblijft en hoe je als bedrijf sneller beweegt.

Misschien heb je als organisatie besloten dat implementatiefrequentie de belangrijkste metric is die je wilt volgen. Je hebt een dashboard met die frequentie en je haalt het tijdens je OKR-bespreking tevoorschijn om het hele engineeringteam te laten zien: “Kijk, we implementeren nu twee keer per week. Dat willen we naar vier keer brengen.”

Maar hoe moet ik daar als engineer over nadenken in relatie tot mijn werk, mijn onderdeel van het bedrijf of de services waarvoor ik verantwoordelijk ben? Sneller implementeren betekent misschien dat je meer moet opleveren, maar leidt dat tot meer bugs? Gaat de betrouwbaarheid omlaag omdat ik meer oplever?

Er zijn zoveel variabelen. Daar worden inputmetrics belangrijk, omdat ze uiteindelijk de outputmetrics beïnvloeden. Voor implementatiefrequentie kun je bijvoorbeeld een proces invoeren om ervoor te zorgen dat die frequentie daadwerkelijk omhooggaat.

Ik kan een voorbeeld geven. Een van onze klanten, O’Reilly, had een vergelijkbaar initiatief. Ze volgden de implementatiefrequentie met behulp van een van onze dashboards voor engineering intelligence. Ze ontdekten dat ze wilden dat engineers sneller implementeerden, maar dat ze dit wilden bereiken door belangrijke waarborgen in het implementatieproces te plaatsen en engineers duidelijke richtlijnen te geven voor wat een goede implementatie is in relatie tot hun betrouwbaarheidsrichtlijnen.

Wat er gebeurde, was dat engineers sneller probeerden te implementeren, maar dat leidde tot bugs of storingen. Daardoor ontstond terughoudendheid om zo snel mogelijk te bewegen, omdat er zoveel impact op klanten was. Teruggrijpend op die inputmetrics ontwikkelden ze daarom een checklist voor productiegereedheid. Die bestond uit acht of negen verschillende inputmetrics die samen een goed beeld gaven van de vraag of hun implementatieproces gezond was.

Dat waren metrics zoals: is onze bereikbaarheidsdienst correct ingesteld? Slaagt ons bouwproces? Hebben we tests die slagen voor onze services? Door deze inputmetrics in te voeren, kregen engineers duidelijke richtlijnen. “Ik ben eigenaar van deze tien services. Dit is het proces en dit zijn inputmetrics die voor mij betekenis hebben, omdat ze mijn services en de werking ervan vertegenwoordigen.”

Ze zagen een geleidelijke stijging van de implementatiefrequentie: van twee keer per week naar drie en vervolgens vier keer. Vooral bij kritieke services zagen ze daarnaast een afname van incidenten en soortgelijke problemen.

Terugkomend op je oorspronkelijke vraag: veel ondernemingen denken na over het feit dat ze die outputmetrics hebben, maar vragen zich vervolgens af hoe ze die kunnen vertalen naar iets waar engineers om geven. Ontwikkelaarsproductiviteit en metrics in het algemeen moeten volgens mij worden gezien als één compleet verhaal waarin die twee onderdelen elkaar aanvullen.

Hannah Clark: Dat maakt het inderdaad veel holistischer. We schakelen een beetje over, maar blijven bij hetzelfde onderwerp: vaker en sneller implementeren. We kunnen in 2025 geen gesprek over engineering voeren zonder het over vibe coding te hebben.

Laten we praten over de AI-tools die de codeerworkflow momenteel veranderen. Ik heb je eerder horen zeggen dat je niet via vibe coding naar een miljoen dagelijkse gebruikers kunt groeien. Misschien een scherpe uitspraak, misschien ook niet. Wat is volgens jou de realiteit tegenover de hype als het gaat om AI gebruiken voor productieomgevingen op schaal?

Anish Dhar: Het is zeker een zeer actueel onderwerp. Elke engineeringorganisatie denkt na over AI of heeft al een AI-codeerassistent ingevoerd. Er zijn verschillende zeer populaire tools op de markt, waaronder Cursor. Ook bijna het hele engineeringteam van Cortex gebruikt een AI-codeerassistent om hen te helpen bij hun dagelijkse werk.

Wat we hebben ontdekt door met engineers in ons team te praten en samen te werken met de meeste klanten met wie we werken, is dat AI-codeerassistenten geweldig zijn wanneer je een eerste idee hebt en snel iets wilt valideren. Ook als je front-end engineer bent en snel een eerste versie wilt maken om te laten zien hoe iets eruit kan zien en aanvoelen, zijn ze nuttig.

Vanuit het perspectief van het ontwikkelproces zijn ze daar perfect voor. Je wilt iets snels en eenvoudigs waarmee je mensen kunt laten zien hoe iets kan werken. Of je hebt als ondernemer een idee dat je snel wilt valideren. Daar zie je inderdaad een enorme groei.

De realiteit van codeerassistenten en vibe coding is echter dat je code die via vibe coding is gemaakt nooit volledig kunt vertrouwen om een productiesysteem aan te sturen dat door miljoenen gebruikers wordt gebruikt. Dat is simpelweg de ervaring die wij hebben opgedaan.

Vibe coding is op zijn best te vergelijken met een junior engineer die net heeft geleerd hoe hij moet coderen. Senior en staff engineers begrijpen systeemontwerp en weten hoe infrastructuur op schaal wordt uitgerold. Daar zijn we nog lang niet. Ik zeg niet dat we daar nooit komen.

De snelheid waarmee AI zich ontwikkelt is ongelooflijk. Het zou dom zijn om te zeggen dat er nooit een wereld kan ontstaan waarin AI-systemen echte productieomgevingen begrijpen. Maar vandaag de dag is er geen onderneming die op vibe coding vertrouwt om een productiesysteem met miljoenen of miljarden gebruikers aan te sturen.

Daarvoor is simpelweg een niveau van technische expertise nodig om die systemen op te zetten, te diagnosticeren en ervoor te zorgen dat ze kunnen schalen. Daar komen we nog lang niet bij in de buurt. Als geheel zou ik wel zeggen dat productiviteit door codeerassistenten is verbeterd. Alleen gebeurt dat op andere gebieden dan waar de markt graag over praat of waar het spannend klinkt om over vibe coding te praten.

De realiteit is dat het nog niet klaar is voor productiesystemen van ondernemingen.

Hannah Clark: Dat zal voor veel professionals herkenbaar zijn. Mensen buiten hun vakgebied raken enthousiast over hoe toegankelijk hun beroep wordt dankzij AI-tools. Dat betekent echter niet dat AI hen meteen kan vervangen.

Dit is wel belangrijk om te bespreken. Er luisteren leiders naar deze show. Wat moeten engineeringleiders volgens jou overwegen wanneer ze de investering in AI-tools willen afwegen tegen hun personeelsbestand? Hoe evalueer je de daadwerkelijke impact van AI op de productiviteit van een team, en hoe neem je dat mee in je budget?

Anish Dhar: Een goede vraag. Er zijn veel verschillende aspecten. Als je engineering vanuit een zeer breed perspectief bekijkt, denk ik dat engineeringteams of -leiders die hun teams verhinderen deze tools te bekijken of toegang te krijgen tot bijvoorbeeld Cursor of GitHub Copilot, hun team op de lange termijn ernstig tekortdoen.

In de komende tien jaar zal een groot deel van de systemen, of in elk geval de eerste code die mensen schrijven, met hulp van AI tot stand komen. Als je een bedrijf start, een idee ontwikkelt of snel wilt itereren en testen, is het nu eenmaal tien keer sneller om iets als Cursor te gebruiken. Je kunt je ideeën snel uitwerken zonder meteen over schaalbaarheid of de volledige werking van alles te hoeven nadenken.

Zelfs als je het op lange termijn bekijkt, hebben engineeringteams die deze AI-tools invoeren en leren gebruiken in verschillende fasen van hun ontwikkelcyclus een voordeel. Dat geldt ook voor de grootste ondernemingen waar productiesystemen op schaal nodig zijn. Engineers die als geheel met deze tools leren werken, lopen voor op mensen die zeggen dat het slechts hype is.

Het is daarom belangrijk dat engineeringleiders hun teams toestaan met dit soort tools te experimenteren. Geef ook niet-technische gebruikers toegang. Dat is waarschijnlijk de interessantste innovatie die ik bij onze klanten heb gezien: productmanagers, technische productmanagers en data scientists die technische concepten begrijpen, maar misschien niet de expertise hadden om te coderen.

Zij kunnen ideeën op een veel krachtigere manier met het engineeringteam delen, omdat ze daadwerkelijk code kunnen opstarten en dergelijke. Vanuit dat perspectief zou het onverstandig zijn om geen budget vrij te maken om engineers toegang tot deze tools te geven.

De vraag van een miljoen dollar is natuurlijk hoeveel productiviteit we hier daadwerkelijk mee winnen. Volgens mij probeert elke onderneming daar nu antwoord op te geven. We zien dat voortdurend. Klanten kopen vaak ons product in combinatie met iets als GitHub Copilot.

De eerste vraag die ze ons dan stellen is: “We hebben een tool die de output van ons engineeringteam met drie of vier keer zou moeten vermenigvuldigen. Hoe kunnen we vaststellen of dat daadwerkelijk gebeurt?” Dat sluit weer aan bij het eerdere systeem van input- en outputmetrics.

Het is niet genoeg om alleen de implementatiefrequentie te bekijken en te zeggen: “Heeft GitHub Copilot daar invloed op?” Misschien zorgt GitHub Copilot ervoor dat je sneller oplevert, maar is de code heel slecht. Dat leidt dan weer tot betrouwbaarheidsproblemen. Je moet dus bijna een 360-gradenbeeld hanteren en naar verschillende metrics kijken.

Uiteindelijk komt het terug bij technische toegang. Vergeet vibe coding en al het andere. Waar richten we ons als bedrijf nu op? Wat houdt ons tegen om onze volgende groeifase te bereiken? Je moet nagaan of de introductie van de codeerassistent of AI-tool vanuit dat perspectief echt verschil of impact maakt.

Misschien zie je die impact een tijdje niet. Het kost tijd om te begrijpen waar dit soort tools invloed hebben op je bedrijf. De fout die ik veel ondernemingen zie maken, is dat ze onmiddellijk meegaan met de hype. Ze kopen vijfduizend licenties van een interessante tool en vragen zich zes maanden later af of er eigenlijk wel impact is.

Zonder een doordachte strategie over waarom je dit soort tools invoert, kan dat tot een zeer negatieve reactie leiden. Misschien is je strategie simpelweg dat je niet achter wilt blijven en wilt dat engineers het gevoel blijven houden dat dit een vooruitstrevende plek is om te werken.

Misschien denk je dat het voordelig is om AI-ondersteunde tools in je engineeringteam te hebben. Zelfs als het zo eenvoudig is, weet je in elk geval waarom je de tool aanschaft. Dat is volgens mij waar het vaak misgaat: begrijp eerst je intenties en controleer onderweg of de tool daadwerkelijk doet wat je had verwacht.

Hannah Clark: Daar ben ik het mee eens. Er is momenteel zoveel druk om deze tools te beheersen en uit te zoeken waar ze in de workflow passen. Tegelijkertijd zien we in veel afdelingen een enorm verschil tussen de hoeveelheid output en de kwaliteit van de resultaten.

We moeten dus heel bewust te werk gaan, niet alleen binnen engineeringafdelingen. Gebruiken we deze tools in de juiste context om het beste uit ons personeel te halen en hen te versterken, in plaats van blind te proberen te voorspellen dat het personeelsbestand volgend jaar kleiner zal zijn omdat AI-tools mensen kunnen vervangen?

Het is interessant om te zien hoe iedereen dit op verschillende manieren probeert uit te zoeken. Het is een desoriënterende tijd om in de technologiesector te werken. Nu AI-tools steeds vaker onderdeel worden van ontwikkelworkflows, komen we ook bij de kwestie van kwaliteit. Hoe vinden we de balans tussen het handhaven van codekwaliteit, beveiligingsstandaarden en betrouwbaarheid, terwijl we ook een vooruitstrevende werkplek willen zijn en deze tools zo goed mogelijk willen benutten?

Hoe pakken jullie dat bijvoorbeeld binnen je eigen organisatie aan?

Anish Dhar: Dat is inderdaad een goede vraag. Heel kort gezegd: het idee dat AI engineers vervangt, is zo vergezocht en onzinnig. Wat wel klopt, is dat je in de beginfase misschien minder engineers hoeft aan te nemen. In plaats van vijftien engineers kun je er misschien een paar minder aannemen, omdat je in de eerste dagen, waarin je iteraties uitvoert en product-market fit probeert te vinden, met een tool als Cursor veel meer kunt doen dan vroeger.

Je kunt heel snel tien verschillende ideeën uitproberen. De snelheid van iteratie is echt krachtig. Maar zodra je productiesystemen implementeert, proberen ondernemingen die zeggen dat ze dankzij AI minder engineers hoeven aan te nemen gewoon media-aandacht te krijgen met een provocerende uitspraak. Dat is niet realistisch. Dat weet ik zeker.

Hannah Clark: Zonder namen te noemen.

Anish Dhar: Ja. Ze zullen allemaal engineers blijven aannemen. Engineers zullen altijd gewild blijven. Terugkomend op je vraag over de invloed van AI-tools en AI-codeersystemen op belangrijke pijlers zoals betrouwbaarheid en beveiliging: dat is momenteel eerlijk gezegd de grote open vraag.

Het is waarschijnlijk het belangrijkste punt waar deze teams, en teams zoals SRE, beveiliging en operationele uitmuntendheid, zich zorgen over maken. De introductie van deze tools zorgt uiteindelijk voor een groter aanvals- en beheeroppervlak, omdat mensen simpelweg meer code opleveren.

Hoe meer van je systeem met AI wordt gebouwd, hoe groter de kans dat je niet volledig begrijpt hoe alles intern werkt. Dat betekent dat je bij een onvermijdelijk betrouwbaarheidsprobleem in een veel moeilijkere situatie terechtkomt. Dat blijft altijd gebeuren, hoe goed je je ook voorbereidt.

Of het nu gaat om een onverwachte toestroom van gebruikers of een onderdeel van je codebase dat je niet volledig begrijpt en dat uitvalt: hoe meer AI-ondersteunde code je systeem bevat, hoe moeilijker het wordt. Als engineer moet je dan immers door alle verschillende onderdelen van je codebase kunnen navigeren zonder dat je ze volledig begrijpt.

Dat is misschien wel het grootste nadeel dat ik nu zie. Daarom wordt die fundamentele laag van technische uitmuntendheid belangrijker dan ooit. Volledige zichtbaarheid en duidelijk eigenaarschap zijn cruciale pijlers van elk initiatief rond technische uitmuntendheid.

Hoe meer van je systemen via AI worden gecreëerd, hoe minder grip je eerlijk gezegd op die zaken hebt. Wie is er eigenaar van? Wie begrijpt het daadwerkelijk? Hoe behoud je die zichtbaarheid? Dat zijn de punten die veel beveiligings- en betrouwbaarheidsteams zorgen baren.

We zien dat bij sommige klanten en ook binnen ons eigen engineeringteam. Wanneer we code publiceren die met AI is gemaakt, zijn engineers heel zorgvuldig in het vermelden daarvan. Ze zeggen bijvoorbeeld: “Een deel hiervan is volledig met Cursor gegenereerd.” Vervolgens besteden we extra aandacht aan die systemen.

Ik zie een enorme trend rond testen met AI-ondersteuning. Er zijn momenteel veel bedrijven die een AI-engineer creëren die je tests beoordeelt. Soms vind ik dat wat twijfelachtig. AI-systemen zijn buitengewoon krachtig en leveren vandaag de dag binnen engineeringteams meer voordeel dan nadeel op.

Maar het is beangstigend om te denken aan een wereld waarin 80% van mijn systeem via AI is opgebouwd. Dat kan leiden tot betrouwbaarheidsproblemen en systemen die langer nodig hebben om problemen op te lossen. Het aantal beveiligingsincidenten kan toenemen omdat je simpelweg minder zichtbaarheid hebt. Daar moet je dus voor oppassen.

Hannah Clark: Daar ben ik het mee eens. Dat is het minder besproken logistieke probleem waar veel teams mee te maken krijgen bij een hogere output: er is dan ook meer toezicht nodig.

Vorige week spraken we met de SVP Productmanagement van Mastercard Gateway. Hij vertelde dat veel AI-tools het invullen van formulieren versnellen om nieuwe markten te betreden. Je moet enorm veel papierwerk doen om een nieuwe markt binnen te komen en aan alle regelgeving te voldoen.

AI zorgt ervoor dat veel daarvan veel sneller kan worden afgerond. Tegelijkertijd moet er voldoende toezicht zijn om te waarborgen dat iemand verantwoordelijkheid draagt voor die inzendingen. Er ontstaat dus een soort wisselwerking: je kunt het sneller afronden, maar je moet in hetzelfde tempo verantwoording kunnen afleggen.

Dat lijkt een enorme logistieke bottleneck te zijn voor veel engineeringteams en andere professionals die deze tools gebruiken om sneller te werken. Dat is een laag die extra nadruk verdient: we kunnen wel snel opleveren, maar kunnen we in hetzelfde tempo ook zeggen dat we verantwoordelijk zijn voor dat werk?

Dit is erg interessant om te bespreken. We hebben inmiddels gesproken met leiders uit allerlei afdelingen en disciplines. Het is fascinerend om te zien hoe veel van deze zorgen parallel aan elkaar lopen, ondanks het feit dat de disciplines zelf sterk verschillen.

Ik waardeer alle inzichten die je vandaag hebt gedeeld enorm. Dat was onze aflevering. Waar kunnen mensen je online volgen, Anish?

Anish Dhar: Je kunt me volgen op LinkedIn of Twitter. Als je mijn naam zoekt, vind je me wel. Je kunt Cortex ook vinden op LinkedIn.

We plaatsen regelmatig berichten en organiseren overal ter wereld Android Access Summits. Als er een in een stad bij jou in de buurt plaatsvindt, kom dan zeker langs. We willen graag een gemeenschap opbouwen van mensen die over dit soort onderwerpen nadenken. Elk bedrijf houdt zich ermee bezig, dus het is geweldig om te zien dat daar zo’n mooie gemeenschap uit voortkomt.

Daarnaast organiseren we onze conferentie IDPCON, die volledig draait om technische uitmuntendheid. Daar komen leiders van verschillende soorten ondernemingen en ontwikkelaars die contact willen leggen met andere ontwikkelaars rond technische uitmuntendheid.

Er zijn veel interessante presentaties. De conferentie vindt in oktober plaats in New York City, dus hopelijk zien we je daar ook.

Hannah Clark: Dat klinkt geweldig. Bedankt voor de informatie. We zullen er zeker naar verwijzen in het beschrijvingsvak. En heel erg bedankt dat je tijd hebt gemaakt om bij ons te zijn.

Anish Dhar: Bedankt voor de uitnodiging. Het was geweldig.

Hannah Clark: Bedankt voor het luisteren. Voor meer geweldige inzichten, handleidingen en beoordelingen van tools kun je je inschrijven voor onze nieuwsbrief via theproductmanager.com/subscribe. Je kunt meer gesprekken zoals dit beluisteren door je te abonneren op The CPO Club, waar je ook je podcasts beluistert.