Ken je deze Quora-opmerking nog (die ook een meme werd)?
(Bron: Quora)
In de pre-grote taalmodel (LLM) In het Stack Overflow-tijdperk was de uitdaging groot welke codefragmenten om effectief over te nemen en aan te passen. Hoewel het genereren van code triviaal eenvoudig is geworden, ligt de grotere uitdaging in het betrouwbaar identificeren en integreren van hoogwaardige, bedrijfscode in productieomgevingen.
Dit artikel onderzoekt de praktische valkuilen en beperkingen die worden waargenomen wanneer ingenieurs moderne codeermiddelen gebruiken voor echt ondernemingswerk, waarbij de meer complexe problemen worden aangepakt rond integratie, schaalbaarheid, toegankelijkheid, evoluerende beveiligingspraktijken, gegevensprivacy en onderhoudbaarheid in live operationele instellingen. We hopen de hype in evenwicht te brengen en een meer technisch gefundeerd beeld te geven van de mogelijkheden van AI-codeermiddelen.
Beperkt domeinbegrip en servicelimieten
AI-agenten worstelen aanzienlijk met het ontwerpen van schaalbare systemen vanwege de enorme explosie aan keuzes en een cruciaal gebrek aan bedrijfsspecifieke context. Om het probleem in grote lijnen te beschrijven: de codebases en monorepo’s van grote ondernemingen zijn vaak te groot voor agenten om er rechtstreeks van te leren, en cruciale kennis kan vaak gefragmenteerd zijn over interne documentatie en individuele expertise.
Meer specifiek worden veel populaire codeermiddelen geconfronteerd met servicelimieten die hun effectiviteit in grootschalige omgevingen belemmeren. Indexeringsfuncties kunnen mislukken of in kwaliteit afnemen voor opslagplaatsen met meer dan 2.500 bestanden, of als gevolg van geheugenbeperkingen. Bovendien worden bestanden groter dan 500 KB vaak uitgesloten van indexeren/zoeken, wat gevolgen heeft voor gevestigde producten met tientallen jaren oude, grotere codebestanden (hoewel nieuwere projecten hier weliswaar minder vaak mee te maken kunnen krijgen).
Voor complexe taken die uitgebreide bestandscontexten of refactoring met zich meebrengen, wordt van ontwikkelaars verwacht dat ze de relevante bestanden aanleveren en daarbij ook expliciet de refactoringprocedure en de omliggende build-/opdrachtsequenties definiëren om de implementatie te valideren zonder feature-regressies te introduceren.
Gebrek aan hardwarecontext en -gebruik
AI-agenten hebben een kritisch gebrek aan bewustzijn aangetoond met betrekking tot OS-machine-, opdrachtregel- en omgevingsinstallaties (conda/venv). Deze tekortkoming kan leiden tot frustrerende ervaringen, zoals de agent die probeert Linux-opdrachten uit te voeren op PowerShell, wat consequent kan resulteren in ‘niet-herkende opdracht’-fouten. Bovendien vertonen agenten vaak een inconsistente ‘wachttolerantie’ bij het lezen van commando-uitvoer, waardoor voortijdig wordt verklaard dat ze de resultaten niet kunnen lezen (en overgaan tot opnieuw proberen/overslaan) voordat een commando zelfs maar is voltooid, vooral op langzamere machines.
Dit gaat niet alleen over muggenziften functies; de duivel zit eerder in deze praktische details. Deze hiaten in de ervaring manifesteren zich als echte wrijvingspunten en vereisen constante menselijke waakzaamheid om de activiteit van de agent in realtime te volgen. Anders negeert de agent de initiële informatie over de tooloproep en stopt hij voortijdig, of gaat hij door met een halfbakken oplossing waarbij sommige/alle wijzigingen ongedaan moeten worden gemaakt, aanwijzingen opnieuw moeten worden geactiveerd en tokens moeten worden verspild. Het is niet gegarandeerd dat u op vrijdagavond een prompt indient en bij de controle op maandagochtend verwacht dat de code-updates zullen worden uitgevoerd.
Hallucinaties voorbij herhaald acties
Het werken met AI-codeermiddelen brengt vaak een langdurige uitdaging van hallucinaties met zich mee, of onjuiste of onvolledige stukjes informatie (zoals kleine codefragmenten) binnen een grotere reeks veranderingen die naar verwachting door een ontwikkelaar met triviale tot lage inspanning kunnen worden opgelost. Wat echter bijzonder problematisch wordt, is wanneer er sprake is van onjuist gedrag herhaald binnen één enkele thread, waardoor gebruikers gedwongen worden een nieuwe thread te starten en alle context opnieuw aan te bieden, of handmatig in te grijpen om de agent te ‘deblokkeren’.
Tijdens het instellen van een Python-functiecode kwam een agent die belast was met het implementeren van complexe wijzigingen in de productiegereedheid bijvoorbeeld een bestand tegen (zie hieronder) met speciale tekens (haakjes, punt, ster). Deze karakters zijn in de informatica heel gebruikelijk om aan te duiden softwareversies.
(Afbeelding handmatig gemaakt met standaardcode. Bron: Microsoft Leer En Toepassingshostbestand (host.json) bewerken in Azure Portal)
De agent markeerde dit ten onrechte als een onveilige of schadelijke waarde, waardoor het hele generatieproces werd stopgezet. Deze verkeerde identificatie van een vijandige aanval deed zich vier tot vijf keer voor, ondanks verschillende pogingen om de wijziging opnieuw te starten of voort te zetten. Dit versieformaat is in feite standaard en aanwezig in een Python HTTP-triggercodesjabloon. De enige succesvolle oplossing was het instrueren van de agent niet lees het bestand en vraag het in plaats daarvan om eenvoudigweg de gewenste configuratie op te geven en verzeker het dat de ontwikkelaar het handmatig aan dat bestand zal toevoegen, bevestigen en vragen om door te gaan met de resterende codewijzigingen.
Het onvermogen om een herhaaldelijk defecte agent-uitvoerlus binnen dezelfde thread te verlaten, benadrukt een praktische beperking die de ontwikkeltijd aanzienlijk verspilt. In wezen besteden ontwikkelaars nu de neiging om tijd te besteden aan het debuggen/verfijnen van door AI gegenereerde code in plaats van aan Stack Overflow-codefragmenten of hun eigen codefragmenten.
Gebrek aan codeerpraktijken op bedrijfsniveau
Best practices voor beveiliging: Codeeragenten maken vaak gebruik van minder veilige authenticatiemethoden zoals sleutelgebaseerde authenticatie (clientgeheimen) in plaats van moderne op identiteit gebaseerde oplossingen (zoals Entra ID of federatieve inloggegevens). Dit toezicht kan aanzienlijke kwetsbaarheden introduceren en de onderhoudsoverhead vergroten, aangezien sleutelbeheer en -rotatie complexe taken zijn die steeds vaker beperkt worden in bedrijfsomgevingen.
Verouderde SDK’s en het wiel opnieuw uitvinden: Agents maken mogelijk niet consequent gebruik van de nieuwste SDK-methoden, maar genereren in plaats daarvan uitgebreidere en moeilijker te onderhouden implementaties. Als voorbeeld van het Azure Function-voorbeeld hebben agenten code uitgevoerd met behulp van de reeds bestaande v1 SDK voor lees-/schrijfbewerkingen, in plaats van de veel schonere en beter onderhoudbare v2 SDK-code. Ontwikkelaars moeten de nieuwste best practices online onderzoeken om een mentale kaart te krijgen van de afhankelijkheden en de verwachte implementatie die onderhoud op de lange termijn garandeert en de komende inspanningen op het gebied van technologiemigratie vermindert.
Beperkte intentieherkenning en repetitieve code: Zelfs voor kleinere, modulaire taken (die doorgaans worden aangemoedigd om hallucinaties of het opsporen van downtime te minimaliseren), zoals het uitbreiden van een bestaande functiedefinitie, kunnen agenten de instructie volgen letterlijk en logica produceren die vrijwel repetitief blijkt te zijn, zonder te anticiperen op de aanstaande of niet gearticuleerd behoeften van de ontwikkelaar. Dat wil zeggen dat de agent bij deze modulaire taken mogelijk niet automatisch vergelijkbare logica identificeert en herstructureert in gedeelde functies of klassendefinities verbetert, wat leidt tot technische schulden en moeilijker te beheren codebases, vooral bij vibe-codering of luie ontwikkelaars.
Simpel gezegd slagen die virale YouTube-filmpjes die de snelle nul-op-één-app-ontwikkeling laten zien vanuit een prompt van één zin eenvoudigweg niet in het weergeven van de genuanceerde uitdagingen van productiesoftware, waarbij beveiliging, schaalbaarheid, onderhoudbaarheid en toekomstbestendige ontwerparchitecturen van het grootste belang zijn.
Bevestiging bias uitlijning
Voorkeur voor bevestiging is een groot probleem, omdat LLM’s vaak de premissen van gebruikers bevestigen, zelfs als de gebruiker twijfel uit en de agent vraagt om zijn begrip te verfijnen of alternatieve ideeën voor te stellen. Deze tendens, waarbij modellen aansluiten bij wat zij denken dat de gebruiker wil horen, leidt tot een verminderde algehele uitvoerkwaliteit, vooral voor meer objectieve/technische taken zoals coderen.
Er is ruime literatuur om te suggereren dat als een model begint met het uitvoeren van een claim als “Je hebt absoluut gelijk!”, de rest van de uitvoertokens de neiging heeft deze claim te rechtvaardigen.
Constante behoefte om te babysitten
Ondanks de aantrekkingskracht van autonome codering, vereist de realiteit van AI-agenten in de ontwikkeling van ondernemingen vaak constante menselijke waakzaamheid. Voorvallen zoals een agent die probeert Linux-opdrachten uit te voeren op PowerShell, vals-positieve veiligheidsvlaggen of het introduceren van onnauwkeurigheden vanwege domeinspecifieke redenen benadrukken kritieke hiaten; ontwikkelaars kunnen eenvoudigweg niet wegstappen. In plaats daarvan moeten ze voortdurend het redeneringsproces in de gaten houden en codetoevoegingen uit meerdere bestanden begrijpen om te voorkomen dat ze tijd verspillen met ondermaatse antwoorden.
De slechtst mogelijke ervaring met agents is dat een ontwikkelaar code-updates van meerdere bestanden vol met bugs accepteert, en vervolgens tijd verdampt bij het debuggen vanwege hoe ‘mooi’ de code er schijnbaar uitziet. Dit kan zelfs aanleiding geven tot de verzonken kostenmisvatting van de hoop dat de code na slechts een paar reparaties zal werken, vooral wanneer de updates betrekking hebben op meerdere bestanden in een complexe/onbekende codebase met verbindingen met meerdere onafhankelijke services.
Het lijkt op samenwerken met een 10-jarig wonderkind dat voldoende kennis uit zijn hoofd heeft geleerd en zelfs elk stukje gebruikersintentie aanpakt, maar prioriteit geeft aan het tonen van die kennis boven het oplossen van het daadwerkelijke probleem, en de vooruitziende blik mist die nodig is voor succes in praktijksituaties.
Deze ‘babysit’-vereiste, in combinatie met de frustrerende herhaling van hallucinaties, betekent dat de tijd die wordt besteed aan het debuggen van door AI gegenereerde code de tijdsbesparing die wordt verwacht bij het gebruik van agenten kan overschaduwen. Het is onnodig om te zeggen dat ontwikkelaars in grote bedrijven zeer doelgericht en strategisch moeten zijn bij het navigeren door moderne agentische tools en gebruiksscenario’s.
Conclusie
Het lijdt geen twijfel dat AI-codeermiddelen niets minder dan revolutionair zijn geweest, de prototyping hebben versneld, standaardcodering hebben geautomatiseerd en de manier waarop ontwikkelaars bouwen hebben getransformeerd. De echte uitdaging is nu niet het genereren van code, maar het weten wat er moet worden verzonden, hoe het moet worden beveiligd en waar het kan worden geschaald. Slimme teams leren de hype te filteren, agenten strategisch in te zetten en hun technische oordeel te verdubbelen.
Als CEO van GitHub Thomas Dohmke merkte dit onlangs op: De meest geavanceerde ontwikkelaars zijn “overgestapt van het schrijven van code naar het ontwerpen en verifiëren van het implementatiewerk dat wordt uitgevoerd door AI-agenten.” In het agententijdperk behoort het succes niet toe aan degenen die kunnen coderen, maar aan degenen die systemen kunnen ontwerpen die lang meegaan.
Rahul Raja is software-ingenieur bij LinkedIn.
Advitya Gemawat is machine learning (ML)-ingenieur bij Microsoft.
Noot van de redactie: de meningen in dit artikel zijn de persoonlijke meningen van de auteurs en weerspiegelen niet de mening van hun werkgevers.
