Codeeragenten kunnen binnen enkele minuten duizenden regels code genereren. Het probleem: het meeste ervan kan niet worden ingezet. Het schendt interne normen, faalt bij nalevingscontroles of creëert meer opruimwerk dan het bespaart.
“Je kunt heel veel code genereren, maar het betekent eigenlijk niets, toch? Het moet code zijn die integreerbaar is, die aan de regels voldoet, en je wilt niet meer werk aan de back-end creëren alleen maar omdat je het codegeneratieproces aan de voorkant hebt versneld”, zegt Stephen Newman, EY Global CTO Engineering Leader.
Het productontwikkelingsteam van EY heeft dit opgelost door codeeragenten te verbinden met hun technische standaarden, coderepository’s en compliance-frameworks. Het resultaat: 4x tot 5x productiviteitswinst bij de teams die bouwen aan de reeks audit-, belasting- en financiële platforms van EY.
Maar de winst kwam niet voort uit het simpelweg inschakelen van een tool. Het team van Newman heeft 18 tot 24 maanden besteed aan het bouwen van de culturele basis en technische integraties die semi-autonoom coderen op schaal mogelijk maakten.
De eerste stap was cultureel. EY begon met tools in GitHub Copilot-stijl, waardoor ingenieurs vertrouwd konden raken met snelle engineering en ondersteunende AI. Newman zei dat de belangrijkste leerervaring erin bestaat om de adoptie van AI organisch te maken, in plaats van gedwongen door het leiderschap. “Het is belangrijk om AI-mogelijkheden als organische adoptie van de grond af aan te bieden, in plaats van ze aan de gebruikers op te dringen”, zegt hij.
Ontwikkelaars wilden verder gaan dan het genereren van code naar het bouwen, implementeren en operationeel maken ervan. Maar de productiviteitswinst stagneerde zonder diepere integratie.
Newman realiseerde zich dat agenten toegang nodig hadden tot de coderepository’s, technische standaarden en broncatalogi van EY om bruikbare code te genereren. Zonder dat ‘contextuniversum’, zoals Newman het noemt, produceren agenten generieke output die uitgebreid herwerk vereist.
EY heeft meerdere agentplatforms geëvalueerd: Lovable, Replit en Factory’s IDE-gebaseerde Droids. In plaats van een tool verplicht te stellen, heeft het team van Newman de acceptatie, het gebruik en de productiviteit van alle drie de tools gemeten.
“We wilden als leiderschapsteam niet te prescriptief zijn om een instrument te identificeren en het te verdoezelen,” zei Newman. Ontwikkelaars werden “echt aangetrokken en genavigeerd” naar Factory, wat het signaal werd dat het echte waarde opleverde.
De adoptie van fabrieken ging ‘als een lopend vuurtje van start’ toen het eenmaal van evaluatie tot pilot werd verheven. EY moest het verkeer naar Factory en Droids beperken en beperken welke repo’s verbinding konden maken voordat de naleving en de beveiliging werden goedgekeurd.
Het werklastclassificatieraamwerk
Het enthousiasme van de ontwikkelaars maakte duidelijk dat EY discipline nodig had rond de werklast die aan agenten moest worden gedelegeerd. Het team van Newman verdeelde de taken in twee categorieën:
Taken met hoge autonomie agenten gaan goed om met:
-
Codebeoordeling
-
Documentatie
-
Defecte bevestiging
-
Greenfield-kenmerken
Complexe taken die nog steeds menselijk toezicht nodig hebben:
EY heeft ook de rollen van ontwikkelaars verschoven. In plaats van alle code zelf te schrijven, werden ingenieurs orkestrators die agenten naar de juiste databases en opslagplaatsen leidden.
Nu de beveiligingsrails aanwezig waren en de integratie in coderepository’s voltooid was, heeft EY de efficiëntiewinst gemeten variërend van 15% tot 60% voor verschillende persona’s in de vroege adoptiefase.
“Er is een sprong gemaakt die we hebben gemaakt met veel van onze producten, waarbij we zijn overgegaan op wat ik de ontwikkeling van horizonmodellen noem, waar we semi-autonome agentuitvoering op schaal hebben, een team van orkestrators in plaats van doeners en we de integraties hebben in het contextuniversum, “zei Newman.
Newman erkende dat het moeilijk is om de 4x tot 5x productiviteitswinst uitsluitend aan codeeragenten toe te schrijven. De verbeteringen kwamen voort uit vallen en opstaan, gecombineerd met culturele en gedragsveranderingen in ontwikkelaarsteams.
