Det var en vanlig tisdag. En av våra utvecklare skulle implementera en ny feature. Förut hade det tagit en halv dag att skriva boilerplate-koden, sätta upp repository-lagret och få grundstrukturen på plats - innan man ens börjat på det som faktiskt skapar affärsvärde.
Den dagen tog det 40 minuter. Claude Code byggde grunden. Utvecklaren granskade, justerade och lade hela sitt fokus på servicelagret - logiken som faktiskt löser kundens problem. Och innan koden mergades in? Testerna var skrivna.
Det är inte ett undantag. Det är hur vi jobbar varje dag.
Men vi ska vara tydliga med en sak: det är inte AI som gör jobbet. Det är AI som gör jobbet snabbare - under förutsättning att vi vet exakt vad vi granskar, varför vi testar och hur vi håller verktyget uppdaterat med rätt kontext. Den distinktionen är viktig, och den är precis vad den här artikeln handlar om.
Rubber ducking med Claude: arkitekturbeslut utan att skriva kod
Innan vi skriver en enda rad kod händer något viktigt: vi tänker igenom problemet.
Klassisk rubber ducking - att förklara ett problem högt för att själv förstå det bättre - har länge varit ett underskattat verktyg i mjukvaruutveckling. Claude Code har gjort den praktiken skarpare.
Konkret: när vi står inför ett arkitekturbeslut, säg hur vi ska strukturera ett event-drivet flöde eller om vi ska lösa ett beroende med dependency injection eller en service locator, bollar vi det med Claude. Vi beskriver kontexten, begränsningarna och de alternativ vi överväger. Claude svarar inte alltid med det rätta svaret - men det tvingar oss att formulera frågan ordentligt, och det lyfter ofta aspekter vi inte tänkt på.
Det handlar inte om att delegera beslutet. Det handlar om att ha en kvalificerad samtalspartner tillgänglig dygnet runt, utan att boka ett möte.
För en IT-chef eller CTO innebär det att arkitekturdiskussioner inte längre fastnar i väntan på att rätt person ska ha tid. Beslut kan tas snabbare, och de är bättre underbyggda.
Enhetstester på minuter: från förslag till täckt funktionalitet
Enhetstester är det som skiljer kod som fungerar idag från kod som fortfarande fungerar om sex månader när någon annan rör i systemet.
Problemet har aldrig varit att utvecklare inte förstår värdet av tester. Problemet har varit att det tar tid - tid som ofta prioriteras bort när deadline närmar sig.
Det är här AI-assisterad testning förändrar vardagen på riktigt.
När en ny funktion är implementerad ber vi Claude generera förslag på enhetstester. Claude läser koden, identifierar edge cases och producerar ett första utkast. Det är inte perfekt - det behöver granskas, justeras och kompletteras. Men det är 70–80% klart på minuter istället för timmar.
Resultatet: testtäckning som faktiskt hänger med i utvecklingstakten. Inte tester som skrivs retroaktivt tre sprintar senare, om de ens skrivs.
Vi har sett det här mönstret upprepas gång på gång: när kostnaden för att skriva tester sjunker, skrivs fler tester. Det låter självklart. Men konsekvensen är att kodkvaliteten höjs - inte som ett separat QA-steg, utan inbyggt i varje leverans.
Playwright E2E-tester: Claude bygger, vi granskar, tester säkrar
End-to-end-testning med Playwright täcker det enhetstester inte kan: hela användarflöden, från inloggning till slutförd transaktion, över riktiga gränssnitt.
Det är också den typ av testning som traditionellt kräver mest tid att sätta upp. Playwright-tester för ett komplext flöde kan ta en dag att skriva - om man gör det manuellt.
Vårt Claude Code workflow för E2E-tester ser ut ungefär så här:
Vi beskriver flödet vi vill testa i naturligt språk. Claude genererar ett komplett Playwright-testskript. Vi granskar det - kontrollerar att selektorer är stabila, att assertions faktiskt testar rätt sak, och att testet inte är bräckligt på ett sätt som gör det värdelöst i CI/CD-pipelinen. Sedan kör vi det, justerar och mergar.
Det som tog en dag tar nu två till tre timmar. Och viktigare: vi skriver fler E2E-tester eftersom tröskeln är lägre.
Men - och det är ett viktigt men - ett AI-genererat Playwright-test som ingen granskat är inte ett test. Det är en illusion av säkerhet. Claude kan generera ett test som ser korrekt ut men som aldrig faktiskt misslyckas, för att assertionen är fel formulerad. Det är ett scenario som är värre än inget test alls, för det ger ett falskt kvitto på att allt är okej.
Det är precis därför granskning inte är valfritt i vårt workflow. Det är kärnan i det.
Varför tester är viktigare än någonsin när AI skriver kod
Här är en sanning som sällan sägs rakt ut i AI-hypen: när AI hjälper till att skriva kod snabbare, ökar risken om ni inte testar mer.
Logiken är enkel. AI producerar kod i ett högt tempo. Varje rad kod som inte täcks av tester är en potentiell felkälla som lever i systemet tills den hittas - antingen i en kontrollerad testmiljö eller av en slutanvändare i produktion. Fler otestade kodrader innebär fler potentiella felkällor.
Vibe coding - det vill säga att låta AI skriva stora mängder kod utan systematisk granskning och testning - är inte ett effektivitetsproblem. Det är ett kvalitetsproblem. Och för ett medelstort bolag med ett affärskritiskt system är det ett affärsproblem.
Vår princip är enkel: kod utan tester är inte klar. Det spelar ingen roll om det var en senior utvecklare eller Claude som skrev den.
Det innebär att tester skrivs parallellt med ny funktionalitet - inte efteråt. Det innebär att inget mergas in utan att testtäckning finns. Och det innebär att AI-assisterad testning inte är ett tillägg till vårt kvalitetsarbete. Det är en del av det.
För en beslutsfattare som ansvarar för systemleveranser handlar det om en konkret fråga: vill ni ha snabb leverans, eller vill ni ha snabb och tillförlitlig leverans? Med rätt AI-workflow behöver det inte vara ett val.
Håll Claude uppdaterad: kontexthantering som gör skillnad
Det finns ett misstag vi ser ofta när bolag börjar experimentera med AI-verktyg i sin utveckling: de behandlar AI som ett stateless verktyg. Fråga, få svar, gå vidare. Det fungerar för enkla uppgifter, men för ett komplext systemutvecklingsprojekt är det ett recept på inkonsekventa resultat.
Ett annat, mer subtilt misstag är att köra det inbyggda kommandot claude code init, godkänna den standardiserade CLAUDE.md-filen som skapas, och tro att kontexten därmed är löst. Den vanliga init-filen är helt okej som en inledande grundplåt – men den måste uppdateras och justeras löpande.
Claude Code är som en ny, mycket kompetent utvecklare. Om du inte onboardar och fortsätter att vägleda den med uppdaterad information om projektets arkitektur, konventioner och beslut, så kommer den att börja gissa. Och gissningar i kod kostar tid att rätta till.
Vår lösning är att behandla CLAUDE.md som repots viktigaste levande dokument. Vi uppdaterar den ständigt med:
- Arkitekturella beslut och varför de togs.
- Namnkonventioner och kodstandarder (som kan utvecklas över tid).
- Beroenden och externa integrationer.
- Anti-patterns: saker vi explicit inte gör i just den här kodbasen, och varför.
Det tar tid att underhålla detta. Men det är en investering som betalar sig direkt varje gång Claude genererar kod eller tester som faktiskt passar in i systemet - istället för kod vi måste skriva om för att den inte följer hur vi byggt allt annat.
Tänk på det som teknisk dokumentation som faktiskt används. Av ett verktyg som läser den varje gång.
Det handlar om disciplin, inte teknik
Vi använder Claude Code för att vi är övertygade om att AI-assisterad testning och AI code review höjer kvaliteten i våra leveranser. Men det är inte verktyget som gör det - det är hur vi använder det.
80/20-regeln stämmer: Claude bygger 80% av grunden. Vi lägger 100% av fokus på de sista 20% och på att allt testas.
Det är inte vibe coding. Det är professionell systemutveckling med AI som kvalitetspartner.
Och det syns i slutprodukten. Färre buggar i produktion. Bättre testtäckning. Snabbare leveranser som inte kompromissar med stabilitet. Utvecklare som lägger sin tid på det som faktiskt skapar affärsvärde - inte på att skriva repository-lager för tionde gången.
För ett medelstort bolag som är beroende av att deras system fungerar, skalas och kan underhållas över tid är det inte en teknisk detalj. Det är en affärsfråga.
Vill du veta hur det här hade sett ut för ert bolag?