27 testfunn fra en konsulentgjennomgang, arbeidet av
Studioets forhold til kunden
Selskapet er en uavhengig part som vurderte planleggingslerretet i Changemkr, en plattform Torn Studio eier en del av og hadde produktrollen i. Studioet tok imot grunnlaget deres og gjorde arbeidet som fulgte.
Om navnet
Selskapet har ikke gått med på å bli navngitt, så siden beskriver det og lar firmanavnet stå utenfor. Beskrivelsen er sann og tilstrekkelig til å plassere hvor grunnlaget kom fra.
Kort svar
Et nordisk konsulentselskap testet et AI-drevet planleggingslerret og meldte det som upålitelig. Torn Studio gjorde rapporten om til 27 sporbare saker, fant rotårsakene før første kodelinje, rettet og verifiserte mot en kjørende stack. Ved verifiseringen den 25. juni 2026 var 22 rettet, 3 delvis og 2 utsatt.
Oppdraget
En konsulent hos selskapet hadde testet planleggingslerretet og AI-assistenten i skarp modus og oppsummert resultatet i en presentasjon. Oppdraget var å gjøre den fortellingen til noe som lot seg arbeide av, og å kunne vise hva som faktisk ble rettet.
Det som gjorde det vanskelig
- Grunnlaget var en fortelling om én økt i den rekkefølgen ting gikk galt, med 27 klager som kunne være færre feil eller flere — hvilket det var, lot seg ikke lese av listen.
- Det alvorligste funnet var at assistenten skrev at den hadde utført endringer som aldri skjedde, noe som gjør resten av verktøyet ubrukelig uansett hvor mange layoutfeil som rettes.
- Flere saker hvilte på modellsvar som varierer mellom kjøringer, så de lot seg ikke verifisere med en vanlig test som venter samme utdata hver gang.
Tall som lar seg telle
- 27saker fra ett testgrunnlag
- TP-01 til TP-27 i tiltaksplanen i repoet, hver med testerens egen formulering og en koblet rotårsak.
- 22 / 3 / 2rettet, delvis, utsatt
- Tellbart i statustabellen i tiltaksplanen, datert 25. juni 2026. To rader dekker flere saker hver, og derfor bærer 24 rader 27 saker.
- 11 / 1tester som passerte og ble hoppet over
- Verifiseringsrapporten i repoet navngir de sju spesifikasjonsfilene som kjørte mot stacken og kommandoen som kjører dem igjen.
- 4saker som var produktbeslutninger
- Løftet ut av sakslisten og avgjort som beslutninger i planen, med valget og konsekvensen skrevet ut. De har ingen kodretting i det hele tatt.
Slik ble det gjort
Fortellingen ble sporbare saker
Klagene i presentasjonen ble oversatt til 27 nummererte saker, TP-01 til TP-27. Hver sak bærer formuleringen testeren brukte, slik at det går an å gå tilbake og lese hva personen faktisk så. Det er den delen som avgjør om en testrunde fører noe sted.
Analyse før første kodelinje
En hel runde gikk med koden urørt. Hver sak ble koblet til en bekreftet eller antatt rotårsak, saker med felles årsak ble gruppert, og fire som viste seg å være produktbeslutninger ble løftet ut og avgjort som beslutninger. Å gruppere først er det som lar én retting lukke flere symptomer.
Den farligste saken først
At assistenten påsto utførte endringer ble tatt før alt annet, fordi en bruker som er lurt én gang slutter å stole på neste svar. Prompten forbyr nå formuleringen, og grensesnittet viser forslaget som uutført til et menneske trykker på knappen.
Verifisering mot en kjørende stack
Rettingene ble kjørt mot hele stacken i containere, med Playwright mot nettappen, forretnings-API-et og AI-tjenesten samtidig. Elleve tester passerte og én ble hoppet over, den siste på grunn av en gest ingen hodeløs nettleser kan drive. Rapporten sier hvilken og hvorfor.
Gjenstående mangler skrevet ut per sak
Hver rad i rapporten har en kolonne for hva som fortsatt er uløst. En sak der testerens tilfelle er rettet mens en kant står igjen, er merket delvis, med kanten beskrevet. En testrunde som meldes helt grønn lar seg ikke stole på neste gang.
Teknologi
- Next.js
- React Flow
- FastAPI
- LangGraph
- Playwright
- Podman
- PostgreSQL
Hva beviset rekker til
Dette viser at et sprikende testgrunnlag lar seg gjøre om til en plan som kan følges opp rad for rad. Det viser ingenting om at produktet ble vellykket: to saker ble utsatt med begrunnelse, tre er delvis rettet med kanten igjen, og de tre store skapingsflytene ble aldri kjørt fra ende til ende fordi de hviler på modellsvar som varierer.
Grunnlag
Hva denne artikkelen hviler på — en måling vi gjorde, en datert kilde eller en beslutning vi tok og hva den kostet.
- Måling
Hvor mange av de 27 sakene som var rettet ved verifiseringen
Måleobjekt: Statustabellen i tiltaksplanen for AI-planleggeren
Metode: Tell statusmerkene i tabellen og løs opp radene som dekker flere saker.
Resultat: 22 rettet, 3 delvis, 2 utsatt
- Beslutning
Kjør en analyserunde over hele sakslisten før noen kode endres, og grupper sakene etter rotårsak.
Hva det kostet: Runden kostet tid før noe så rettet ut, noe som er vanskelig å forsvare overfor en oppdragsgiver som venter på rettinger.
- Beslutning
La assistenten melde forslag som uutførte til et menneske trykker på knappen.
Hva det kostet: Hver endring krever nå et ekstra klikk, og objektet må være markert først, noe som gjør flyten tregere enn å la modellen skrive rett gjennom.
Vanlige spørsmål
- Hvorfor navngis ikke selskapet?
- Selskapet har ikke gått med på å bli navngitt, og da står navnet ikke her. Beskrivelsen — et nordisk konsulentselskap innen digital transformasjon — er sann og tilstrekkelig til at leseren forstår hvor grunnlaget kom fra. Den dagen et selskap går med på å bli navngitt, står navnet der.
- Hvorfor ble analysen gjort med koden urørt?
- Fordi 27 symptomer sjelden er 27 feil. Gruppering etter rotårsak viser hvor samme årsak gir flere symptomer, slik at én retting lukker flere rader. Runden løftet også ut fire saker som viste seg å være produktbeslutninger, og de har ingen kodretting i det hele tatt.
- Hva var det alvorligste funnet?
- At assistenten skrev at den hadde utført endringer som aldri skjedde. En layoutfeil er synlig og lar seg arbeide rundt, mens en falsk kvittering får brukeren til å slutte å stole på hele verktøyet. Den saken ble tatt først, og løsningen er både en promptregel og en synlig merking i grensesnittet.
- Hva betyr delvis rettet i rapporten?
- At tilfellet testeren meldte fungerer, mens en tilstøtende kant står igjen. Rapporten beskriver kanten på raden. Merkingen finnes fordi en runde som meldes helt grønn gjør neste runde verdiløs — den som leser rapporten må kunne se hvor grensen går.
- Hvor lang tid tok runden?
- Mottak, analyse, retting og verifisering lå innenfor juni 2026, med verifiseringsrapporten datert den 25. Det er takten én person med AI-verktøy holder på et avgrenset grunnlag der sakene allerede er beskrevet av noen som har brukt produktet.
Fortell hva du vil bygge
Tretti minutter, kostnadsfritt, og et ærlig svar på om vi er riktig studio for oppdraget.
Svar innen et døgn, et skriftlig forslag med fast pris innen tre dager, og du bestemmer deg i ro og mak.
Fornøydgaranti