Agentty vs Claude Code

Når et værktøj kalder sig drop in kompatibelt, lover det, at du kan udskifte det ene system med det andet uden friktion. Ingen omskrivning af scripts, ingen nye kommandoer at lære, ingen justering af de integrationer, du allerede har bygget. Det er et attraktivt løfte, fordi det fjerner den friktion, der normalt følger med at skifte leverandør.

Problemet er, at løftet ofte bliver bevist ud fra de forkerte målepunkter. Agentty markedsføres blandt andet på, at den fylder mindre på disken og starter hurtigere end originalen. Det er reelle egenskaber, men de siger stort set intet om, hvorvidt værktøjet håndterer de samme opgaver korrekt, når arbejdet bliver komplekst.

En mindre binary og en hurtigere opstart er lette at måle og lette at fremhæve i en salgstekst. De er samtidig et dårligt mål for kompatibilitet, fordi de intet siger om, hvordan værktøjet fortolker instrukser, håndterer fejl eller genskaber konteksten i en samtale, der strækker sig over mange trin.

Et kodeværktøj, der klarer en simpel opgave hurtigt, kan stadig fejle, når opgaven bliver mere sammensat: flere filer, afhængigheder mellem trin, eller instrukser, der kræver, at værktøjet husker en beslutning fra tidligere i forløbet. Det er netop her, forskellene mellem en original og en klon typisk viser sig, og det er også her, de fleste brugere først opdager problemet, nemlig midt i et rigtigt stykke arbejde.

Disse situationer optræder sjældent i en hurtig demo, men de optræder ofte i den daglige drift hos en virksomhed, der bruger et værktøj til reelt arbejde. En klon kan sagtens ramme de samme resultater i ni ud af ti tilfælde og stadig være uegnet til produktion, hvis det tiende tilfælde er dét, der koster en kunde eller en deadline. Se en sammenligning af AI-kodningsmodellers pass rate for et konkret eksempel på, hvordan sådanne forskelle måles.

Jeg arbejder selvstændigt med små og mellemstore virksomheder og hjælper dem i gang med AI gennem workshops, oplæring og konkrete løsninger, der passer til deres hverdag. I det arbejde støder jeg jævnligt på forskellen mellem et værktøj, der ligner originalen, og et værktøj, der faktisk opfører sig som den.

Det mønster, der går igen, er, at reimplementeringer typisk rammer de brede, velkendte use cases fint. De knækker først, når opgaven kræver en beslutning, som originalen har indbygget efter lang tids finjustering, og som ikke er dokumenteret noget sted. Det er ikke nødvendigvis et tegn på dårligt håndværk hos dem, der bygger klonen. Det er et tegn på, at kompatibilitet med et modent værktøj er en meget højere bar, end filstørrelse og opstartstid kan vise.

For en dansk virksomhed, der overvejer at skifte kodeassistent eller agent runtime, er den praktiske lære enkel: mål aldrig et værktøj på, hvor hurtigt det starter, eller hvor lille det er at installere. Test det på den type opgaver, hvor det faktisk skal arbejde for jer, gerne dem der er lidt besværlige, med flere trin og lidt uklare instrukser.

Et godt tegn er, om leverandøren selv er ærlig om, hvor værktøjet endnu ikke matcher originalen. Et dårligt tegn er, når hele argumentationen for at skifte handler om ressourceforbrug og hastighed, uden at der er dokumentation for, at de faktiske resultater er de samme. Kompatibilitet handler i sidste ende om tillid til, at værktøjet gør det samme som det, du erstatter, ikke om det ligner det på papiret. Det kan derfor være klogt at forberede en plan B ved værktøjsskift, inden man tester nye kandidater i produktion.