Varför färdiga AI-lösningar frustrerar team – och vad man kan göra åt det

Med de flesta teknologier är det så att ju längre man använder dem, desto mer kan man lita på dem. Men när det gäller AI-verktyg har det motsatta varit sant: i sin årliga undersökning av mer än 49 000 utvecklare, konstaterade Stack Overflow att användningen ökade till 84 % samtidigt som förtroendet för verktygens noggrannhet minskade från 40 % till 29 % under loppet av ett år.

Den effekten är bekant för mig. Vår egen första erfarenhet av AI-verktyg i utvecklingen hade inte mycket gemensamt med den positiva effekten av snabbare arbete och mindre tråkighet som tech-pressen skrev om. Våra utvecklare blev besvikna: AI producerade medelmåttig kod som tog lång tid att granska och som till slut måste skrivas om. Teamet förväntade sig att AI skulle spara tid, men istället fick de extra arbete. Så inte långt efter de första försöken att integrera AI-verktyg i den dagliga arbetsflödet, gick teamet tillbaka till att arbeta som de alltid hade gjort.

Idag accelererar samma verktyg både kodskrivning och granskning för våra utvecklare — inte för att vi hittade en bättre modell, utan för att vi ändrade hur vi arbetar med den. Här är vad som hjälpte oss att komma dit.

Varför AI-genererad kod frustrerar utvecklare

AI bygger på en enorm mängd offentlig kod från hela internet, och den koden är sällan exemplarisk: dess kvalitet är genomsnittlig, och modellen reproducerar den genomsnittliga kvaliteten.

Men “genomsnittlig” är inte taket för vad som är möjligt — det är bara vad modellen producerar tills den känner till ditt projekt: dess konventioner, kodstruktur, arkitektbeslut. I en undersökning av 600 utvecklare, fann Qodo att bland de som var missnöjda med AI-kodens kvalitet, tillskrev 44 % det specifikt bristen på kontext. Det är vad som håller utmatningen på en medelmåttig nivå.

Den goda nyheten är att kontexten som AI får är den enda variabeln som ett team kontrollerar fullständigt. Hur väl verktyget förstår projektet beror inte på modellen, utan på vad du matar in i den.

Den andra anledningen är mental — själva arbetets natur förändras. När AI skriver mest av koden, är utvecklarens huvudsakliga uppgift inte längre att skriva, utan att granska vad som genererats: läsa någon annans lösning, väga alternativen, bestämma vad som är klart att skicka. Det är en annan färdighet än att skriva kod själv, och för alla som älskade att skriva kod, kommer det inte lätt.

I sin 2025 Octoverse-rapport, beskriver GitHub exakt denna förändring: utvecklare som har kommit längst med AI kallar sig inte längre “kodförfattare” och blir mer som “kreativa direktörer”, där den viktigaste färdigheten är att styra och verifiera. Men vägen till den rollen går genom misstag och frustration, tills en person ser nyttan i sitt eget arbete.

Vad som förvandlar AI från en källa till frustration till ett fungerande verktyg

När vårt team först började använda AI, arbetade vissa utvecklare med Claude Code, medan andra försökte med OpenAI Codex, GitHub Copilot eller Gemini CLI, och varje verktyg gav ett annat resultat. Så när vi satte oss för att bringa ordning i hur teamet arbetade med AI, var det första vi gjorde att fastställa ett enda verktyg.

Detta är inte bara vår praxis. Ta historien om teamet på Linear: till och med början av 2026 följde de principen “låt alla arbeta på det sätt som passar dem”, och i januari övergav ledningen den strategin och flyttade alla utvecklare till ett enda sätt att arbeta — att begränsa valet till två AI-verktyg och be utvecklare att skriva kod endast med dem, snarare än för hand. Enligt företaget ökade den genomsnittliga produktiviteten redan nästa månad med 30 % i sammanfogade PR och med 33 % i uppgifter som stängdes per ingenjör.

Det sagda, förbättrar inte ett delat verktyg koden i sig — det måste konfigureras: ställa in regler, något som liknar en regel.md, som beskriver hur man skriver kod — vilka metoder som ska följas, vad som ska undvikas. Sedan kommer anpassade färdigheter för de uppgifter som är typiska för ditt projekt, så att du inte behöver förklara samma sak om och om igen. Och slutligen är det värt att peka agenten mot din befintliga kodbas: den analyserar hur projektet är skrivet och producerar ny kod i samma stil, snarare än en generisk sådan. Ju mer kontext verktyget får, desto mindre behöver du skriva om för hand efteråt.

Men den svåraste delen är inte teknisk. Övergången från kodförfattare till utvärderare sker inte av sig själv — den övergången behöver hjälp. Den mest direkta vägen är utbildning och certifiering. I vårt fall, till exempel, går tio utvecklare igenom ett partnerprogram med verktygets leverantör, medan en person som ansvarar för införandet arbetar bredvid dem, förklarar varför verktyget producerade ett visst resultat och hur man kan åtgärda det.

När teamet arbetar på ett samordnat sätt, återstår en flaskhals — granskning — och det är värt att förstärka med AI. Agenten går igenom varje pull request först och tar hand om det uppenbara: rutinmässiga fel, stil, upprepning, säkerhetsluckor. Den mänskliga granskaren behöver sedan inte titta på allt ostrukturerat, utan endast på arkitekturen och de kritiska besluten. Effekten är märkbar, till och med inom de företag som bygger dessa verktyg: på Anthropic, efter att ha infört en sådan agent, ökade andelen pull requests som fick substantiell granskning från 16 % till 54 %, och ingenjörerna var oense med mindre än 1 % av dess kommentarer.

För oss, förkortade detta en granskningscykel som tidigare sträckte sig över två eller tre dagar och flera omgångar, och det lyfte rutinen från våra seniora ingenjörer, lämnade dem de riktigt svåra delarna. När verktyget till slut började producera resultat som inte behövde skrivas om, uppkom förtroendet för det också.

Där förtroende för AI-verktyg ger utdelning

Först och främst — i kodskrivning: när verktyget känner till projektet och agenten hanterar den första granskningen, skriver teamet mer och bättre på samma tid. I vårt fall accelererade AI-verktygen arbetet med cirka 30–40 %.

Utöver det har AI gjort onboarding enklare. När en ny person ansluter till ett projekt, måste vanligtvis någon erfaren person besvara dussintals frågor om hur projektets kod är sammansatt. Nu tar agenten på sig den rollen: om projektet är väl dokumenterat, riktar nykomlingen upp till 95 % av dessa frågor till den, snarare än till kollegor.

Det är en liknande historia med dokumentation: en grov arkitekturutkast som tidigare åt upp timmar, skrivs nu till stor del av agenten själv — enligt våra beräkningar, cirka 80 % av utkastet, om du ger det tillräcklig kontext. Vad som återstår för människan är det som inte finns i repositoryt — besluten, avvägningarna, expertisen.

Det är lika viktigt att vara ärlig om gränserna för vad AI kan göra, eftersom det är överdrivna förväntningar som skapar besvikelse från början. AI tar inte på sig regelefterlevnad — en människa undertecknar medicinska eller finansiella data, och företaget, inte modellen, bär ansvaret för en läcka. Det accelererar inte heller integrationer med partners, där dussintals timmar går åt till samtal och samordning.

Färdiga AI-lösningar är verkligen irriterande — men bara när de används som en färdig lösning. Hela skillnaden mellan frustration och utdelning ligger i vad du bygger runt den: en gemensam standard, projektets kontext och utvecklarens nya roll.