27 testfynd från en konsultgranskning, avverkade
Studions relation till kunden
Byrån är en fristående part som utvärderade planeringsduken i Changemkr, en plattform Torn Studio äger en del av och hade produktrollen i. Studion tog emot byråns underlag och gjorde arbetet som följde.
Om namnet
Byrån har inte gått med på att namnges, så sidan beskriver den och lämnar företagsnamnet utanför. Beskrivningen är sann och tillräcklig för att placera vem underlaget kom från.
Kort svar
En nordisk konsultbyrå testade en AI-driven planeringsduk och rapporterade den som opålitlig. Torn Studio gjorde om rapporten till 27 spårbara ärenden, analyserade rotorsakerna före första kodrad, åtgärdade och verifierade mot en körande stack. Vid verifieringen den 25 juni 2026 var 22 åtgärdade, 3 delvis och 2 uppskjutna.
Uppdraget
En konsult hos byrån hade testat planeringsduken och dess AI-assistent i skarpt läge och sammanfattat resultatet i en presentation. Uppdraget var att göra den berättelsen till något som gick att arbeta av, och att kunna visa vad som faktiskt blev åtgärdat.
Det som gjorde det svårt
- Underlaget var en berättelse om en session i den ordning saker gick fel, med 27 klagomål som kunde vara färre fel eller fler — vilket det var gick inte att se på listan.
- Det allvarligaste fyndet var att assistenten skrev att den hade utfört ändringar som aldrig gjordes, vilket gör resten av verktyget oanvändbart oavsett hur många layoutfel som rättas.
- Flera ärenden berodde på modellsvar som varierar mellan körningar, så de gick inte att verifiera med ett vanligt test som förväntar sig samma utdata varje gång.
Siffror som går att räkna efter
- 27ärenden ur ett testunderlag
- TP-01 till TP-27 i åtgärdsplanen i repot, var och en med testarens egen formulering och en kopplad rotorsak.
- 22 / 3 / 2åtgärdade, delvis, uppskjutna
- Räknebart i statustabellen i åtgärdsplanen, daterad 25 juni 2026. Två rader täcker flera ärenden var, vilket är varför 24 rader bär 27 ärenden.
- 11 / 1test som passerade och hoppades över
- Verifieringsrapporten i repot anger de sju specifikationsfiler som kördes mot stacken och kommandot som kör om dem.
- 4ärenden som var produktbeslut
- Lyfta ur ärendelistan och avgjorda som beslut i planen, med valet och dess konsekvens utskrivna. De har ingen kodrättning alls.
- 1bugg utöver rapporten
- Ärende TP-15: en ogiltig omkoppling raderade den befintliga kopplingen. Hittad under åtgärdsarbetet och beskriven i statustabellen.
Så gjordes det
Berättelsen blev spårbara ärenden
Presentationens klagomål översattes till 27 numrerade ärenden, TP-01 till TP-27. Varje ärende bär den formulering testaren använde, så att det går att gå tillbaka och läsa vad personen faktiskt såg. Det är den delen som avgör om ett testvarv leder någonstans.
Analys före första kodrad
Ett helt pass gjordes där koden lämnades orörd. Varje ärende kopplades till en bekräftad eller antagen rotorsak, ärenden med gemensam orsak grupperades, och fyra som visade sig vara produktbeslut lyftes ur och avgjordes som beslut. Att gruppera först gör att en rättning stänger flera symtom.
Det farligaste ärendet först
Att assistenten påstod utförda ändringar togs före allt annat, eftersom en användare som blivit lurad en gång slutar lita på nästa svar. Prompten förbjuder numera formuleringen, och gränssnittet visar förslaget som ogenomfört tills en människa trycker på knappen.
Verifiering mot en körande stack
Åtgärderna kördes mot hela stacken i containrar, med Playwright mot webben, affärs-API:et och AI-tjänsten samtidigt. Elva test passerade och ett hoppades över, det sista på grund av en gest som inte går att driva i en huvudlös webbläsare. Rapporten säger vilket och varför.
Kvarstående brister skrevs ut per ärende
Varje rad i rapporten har en kolumn för vad som fortfarande inte är löst. Ett ärende där testarens fall är åtgärdat men en kant kvarstår är märkt delvis, med kanten beskriven. Ett testvarv som redovisas som helt grönt går inte att lita på nästa gång.
Teknik
- Next.js
- React Flow
- FastAPI
- LangGraph
- Playwright
- Podman
- PostgreSQL
Vad beviset räcker till
Det här visar att ett spretigt testunderlag går att göra till en plan som går att följa upp per rad. Det visar ingenting om att produkten blev lyckad: två ärenden sköts upp med skäl, tre är delvis åtgärdade med kanten kvar, och de tre stora skapandeflödena kördes aldrig igenom från början till slut eftersom de bygger på modellsvar som varierar.
Underlag
Vad den här artikeln vilar på — en mätning vi gjort, en daterad källa eller ett beslut vi tagit och vad det kostade.
- Mätning
Hur många av de 27 ärendena som var åtgärdade vid verifieringen
Mätobjekt: Statustabellen i åtgärdsplanen för AI-planeraren
Metod: Räkna statusmarkeringarna i tabellen och lös upp de rader som täcker flera ärenden.
Resultat: 22 åtgärdade, 3 delvis, 2 uppskjutna
- Beslut
Gör en analyspass över hela ärendelistan innan någon kod ändras, och gruppera ärendena efter rotorsak.
Vad det kostade: Passet kostade tid innan något syntes åtgärdat, vilket är svårt att försvara för en beställare som väntar på rättningar.
- Beslut
Låt assistenten redovisa förslag som ogenomförda tills en människa trycker på knappen.
Vad det kostade: Varje ändring kräver nu ett extra klick, och objektet måste vara markerat först, vilket gör flödet långsammare än att låta modellen skriva direkt.
Vanliga frågor
- Varför namnges inte byrån?
- Företaget har inte gått med på att namnges, och då står namnet inte här. Beskrivningen — en nordisk konsultbyrå inom digital transformation — är sann och tillräcklig för att läsaren ska förstå vem underlaget kom från. Den dag ett företag går med på att namnges står namnet där.
- Varför gjordes en analyspass med koden orörd?
- För att 27 symtom sällan är 27 fel. Gruppering efter rotorsak visar var samma orsak ger flera symtom, så att en rättning stänger flera rader. Passet lyfte också ut fyra ärenden som visade sig vara produktbeslut, och de har ingen kodrättning alls.
- Vad var det allvarligaste fyndet?
- Att assistenten skrev att den hade utfört ändringar som aldrig gjordes. Ett layoutfel syns och går att arbeta runt, medan ett falskt kvitto får användaren att sluta lita på hela verktyget. Det ärendet togs först, och lösningen är både en promptregel och en synlig märkning i gränssnittet.
- Vad betyder delvis åtgärdad i rapporten?
- Att fallet testaren rapporterade fungerar, medan en angränsande kant kvarstår. Rapporten beskriver kanten på raden. Märkningen finns för att ett testvarv som redovisas som helt grönt gör nästa varv värdelöst — den som läser rapporten måste kunna se var gränsen går.
- Hur lång tid tog varvet?
- Mottagande, analys, åtgärd och verifiering låg inom juni 2026, med verifieringsrapporten daterad den 25 juni. Det är takten en person med AI-verktyg håller på ett avgränsat underlag där ärendena redan är beskrivna av någon som använt produkten.
- Går ett sådant här varv att köpa?
- Ja. Det ligger under Product Management när underlaget är användarrapporter som ska bli en prioriterad plan, och under AI och automation när felen sitter i ett AI-lager. Studion sätter fast pris på varvet efter att ha läst underlaget.
Berätta vad du vill bygga
Trettio minuter, kostnadsfritt, och ett rakt besked om vi är rätt studio för uppdraget.
Svar inom ett dygn, skriftligt förslag med fast pris inom tre dagar, och du bestämmer i lugn och ro.
Nöjdhetsgaranti