Ken je deze Quora-opmerking nog (die ook een meme werd)?
(Bron: Quora)
In pre-groot taalmodel (LLM) In het Stack Overflow-tijdperk was de uitdaging kieskeurig welke codefragmenten om efficiënt 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 bedrijfswerk, en behandelt de meer complexe kwesties van integratie, schaalbaarheid, beschikbaarheid, evoluerende beveiligingspraktijken, gegevensbescherming en onderhoud in live operationele instellingen. We hopen de hype in evenwicht te brengen en een meer technisch gefundeerd overzicht te bieden van de mogelijkheden van AI-codeermiddelen.
Beperkt domeinbegrip en servicelimieten
AI-agenten worstelen aanzienlijk met het ontwerpen van schaalbare systemen vanwege de explosie aan keuzes en een cruciaal gebrek aan bedrijfsspecifieke context. Om het probleem in brede zin te beschrijven: codebases en monorepo’s van grote ondernemingen zijn vaak te groot voor agenten om van te leren, en cruciale kennis kan vaak gefragmenteerd zijn over interne documentatie en individuele expertise.
Meer specifiek worden veel populaire coderingsmiddelen geconfronteerd met servicelimieten die hun effectiviteit in grote omgevingen belemmeren. Indexeringsfuncties kunnen mislukken of slechter worden voor opslagplaatsen met meer dan 2.500 bestanden of als gevolg van geheugenbeperkingen. Bovendien worden bestanden die groter zijn dan 500 KB vaak uitgesloten van indexeren/zoeken, wat gevolgen heeft voor gevestigde producten met tientallen jaren oude, grotere codebestanden (hoewel nieuwere projecten dit mogelijk minder vaak ervaren).
Voor complexe taken die uitgebreide bestandscontexten of refactoring met zich meebrengen, wordt van ontwikkelaars verwacht dat ze de relevante bestanden aanleveren, terwijl ze expliciet de refactoringprocedure en de omliggende build-/opdrachtreeksen definiëren om de implementatie te valideren zonder feature-regressie te introduceren.
Gebrek aan hardwarecontext en -gebruik
AI-agenten heeft blijk gegeven van een kritisch gebrek aan bewustzijn met betrekking tot OS-machine-, opdrachtregel- en omgevingsinstallaties (conda/venv). Deze tekortkoming kan leiden tot frustrerende ervaringen, zoals de agent die Linux-opdrachten probeert uit te voeren op PowerShell, wat consequent kan resulteren in ‘opdracht niet herkend’-fouten. Ook vertonen agenten vaak een inconsistente ‘wachttolerantie’ voor het lezen van opdrachtuitvoer, waarbij ze voortijdig verklaren dat ze de resultaten niet kunnen lezen (en overgaan tot opnieuw proberen/overslaan) voordat een opdracht 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 agenten in realtime te volgen. Anders kan de agent de initiële informatie over de tooloproep negeren en voortijdig stoppen of doorgaan 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 verzendt en verwacht dat de code-updates op maandagochtend worden uitgevoerd.
Hallucinaties voorbij herhaald acties
Het werken met AI-codeermiddelen biedt vaak een langdurige uitdaging met hallucinaties of onjuiste of onvolledige informatie (zoals kleine stukjes code) binnen een grotere reeks veranderingen die naar verwachting door een ontwikkelaar met triviale tot weinig inspanning zullen worden opgelost. Wat echter vooral problematisch wordt, is wanneer er sprake is van verkeerd gedrag herhaald binnen een enkele thread, waardoor gebruikers gedwongen worden ofwel een nieuwe thread te starten en alle context weer te geven, ofwel handmatig in te grijpen om de agent “ongedaan te maken”.
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, punten, sterretjes). Deze karakters zijn in de informatica heel gebruikelijk om aan te duiden softwareversies.
(Afbeelding handmatig gemaakt met standaardcode. Bron: Microsoft Leer En Hostbestand van toepassing (host.json) bewerken in Azure Portal)
De agent heeft dit ten onrechte gemarkeerd als een onveilige of schadelijke waarde, waardoor het hele generatieproces werd stopgezet. Deze verkeerde identificatie van een vijandige aanval werd vier tot vijf keer herhaald, ondanks verschillende berichten waarin werd geprobeerd de wijziging opnieuw op te starten of voort te zetten. Dit versieformaat is eigenlijk 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 u ervan 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 Stack Overflow-codefragmenten of hun eigen codefragmenten.
Gebrek aan codeerpraktijken op bedrijfsniveau
Beste praktijken voor beveiliging: Codeeragenten gebruiken vaak minder veilige authenticatiemethoden zoals op sleutels gebaseerde authenticatie (clientgeheimen) in plaats van moderne op identiteit gebaseerde oplossingen (zoals Entra ID of federatieve inloggegevens). Dit toezicht kan aanzienlijke kwetsbaarheden introduceren en de onderhoudskosten verhogen, omdat sleutelbeheer en -rotatie complexe taken zijn die in bedrijfsomgevingen steeds meer aan beperkingen onderhevig zijn.
Verouderde SDK’s en het wiel opnieuw uitvinden: Agenten gebruiken mogelijk niet consequent de nieuwste SDK-methoden, maar genereren in plaats daarvan complexere en moeilijker te onderhouden implementaties. Als voorbeeld van het Azure Function-voorbeeld hebben agenten code geïmplementeerd 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 toekomstige inspanningen voor technologiemigratie vermindert.
Beperkte intentieherkenning en herhaalde code: Zelfs voor kleinere, modulaire taken (die doorgaans worden aangemoedigd om hallucinaties of het oplossen van downtime te minimaliseren) als uitbreiding van een bestaande functiedefinitie, kunnen agenten de instructie volgen letterlijk en logica produceren die bijna repetitief blijkt te zijn zonder te anticiperen op de komst of onduidelijk de behoeften van de ontwikkelaar. Dat wil zeggen dat de agent in deze modulaire taken mogelijk niet automatisch vergelijkbare logica identificeert en refactort in gedeelde functies of klassendefinities verbetert, wat leidt tot technologische schulden en moeilijker te beheren codebases, vooral bij vibe-codering of luie ontwikkelaars.
Simpel gezegd: de virale YouTube-filmpjes die de snelle nul-op-één app-ontwikkeling laten zien vanaf één enkele zin, kunnen eenvoudigweg niet de genuanceerde uitdagingen van software van productiekwaliteit weergeven, 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 hun begrip te verfijnen of alternatieve ideeën voor te stellen. Deze neiging van modellen om overeen te komen met wat de gebruiker volgens hen wil horen, leidt tot een verminderde algehele uitvoerkwaliteit, vooral voor meer objectieve/technische taken zoals coderen.
Er is overvloedige 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 om die claim te rechtvaardigen.
Constante behoefte om te babysitten
Ondanks de aantrekkingskracht van autonome codering vereist de realiteit van AI-agenten in bedrijfsontwikkeling vaak constante menselijke waakzaamheid. Instanties zoals een agent die probeert Linux-opdrachten uit te voeren op PowerShell, vals-positieve beveiligingsvlaggen of het introduceren van onnauwkeurigheden vanwege domeinspecifieke redenen benadrukken kritieke gaten; ontwikkelaars kunnen simpelweg niet wegstappen. Integendeel, ze moeten het redeneerproces voortdurend in de gaten houden en codetoevoegingen uit meerdere bestanden begrijpen om te voorkomen dat ze tijd verspillen met inferieure antwoorden.
De slechtst mogelijke ervaring met agents is een ontwikkelaar die code-updates accepteert met meerdere bestanden vol bugs en vervolgens tijd verspilt aan het debuggen vanwege hoe ‘mooi’ de code er blijkbaar uitziet. Dit kan zelfs aanleiding geven foutieve kostenfout te hopen 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 is alsof je werkt met een tienjarig wonderkind dat voldoende kennis uit zijn hoofd heeft geleerd en zelfs alle gebruikersintenties heeft aangepakt, maar die prioriteit geeft aan het tonen van die kennis boven het oplossen van het daadwerkelijke probleem, en die de vooruitziende blik mist die nodig is om te slagen in praktijksituaties.
Deze ‘babysit’-vereiste, gecombineerd met de frustrerende herhaling van hallucinaties, betekent dat de tijd die wordt besteed aan het debuggen van door AI gegenereerde code de verwachte tijdbesparing bij het gebruik van agenten in het niet kan doen vallen. Het is onnodig om te zeggen dat ontwikkelaars in grote ondernemingen zeer doelbewust en strategisch moeten zijn bij het navigeren door moderne agenttools 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 technisch 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 door AI-agenten wordt uitgevoerd.” In het agententijdperk behoort succes niet toe aan degenen die snel kunnen coderen, maar aan degenen die systemen kunnen bouwen 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.
