meatproxy

En tvådagars workshop för hela ert utvecklingsteam, på plats hos er, med uppföljning efteråt.

Ni har Copilot. En i teamet har fått fart. Han visar det inte.

Det är rationellt: visar han flödet förväntas han leverera dubbelt för samma lön, eller lära upp alla andra. Resten av teamet körde Copilot utan regler och utan tester, såg den gissa fel och slutade. Ni betalar för kapaciteten men får inte ut den. Efter två dagar tillsammans vet alla att alla vet.

Problemet

Företaget betalar för AI-verktyg men ser ingen skillnad

Det har två orsaker, och ingen av dem är modellen.

De som kan, håller det för sig själva.

Den som visar sitt flöde får en av två saker: dubbla förväntningar för samma lön, eller uppdraget att lära upp alla andra. Så länge var och en tror sig vara ensam om flödet lönar det sig att inte visa det.

De som inte kan, provar på fel sätt.

De kör agenten utan skills och utan tester. AI:n har inga ögon: utan skills vet den inte vad ni menar, utan tester ser den inte vad den har haft sönder. Så gissar den fel, och slutsatsen blir att AI inte klarar er kodbas. En rimlig slutsats av ett felaktigt experiment.

Kapaciteten finns alltså redan. Ni betalar för den i löner och AI-licenser. Ni får bara inte ut den.

Vad workshopen gör

Efter två dagar behöver ingen gömma sitt flöde

Workshopen lär inte ut ett nytt verktyg. Hela teamet sitter i samma rum och ser varandra köra flödet, på en kodbas som är svår på riktigt. Efteråt vet alla vad alla kan. Den som haft ett eget flöde har ingen anledning att hålla det för sig själv längre, och de som provat på fel sätt har sett att det fungerar när man gör rätt.

Det är att hela teamet gör det tillsammans som ger effekten, inte innehållet i sig.

Vad teamet kan efteråt

  • Domänkunskap som skills

    Det en senior förklarar om och om igen i review skrivs ner en gång, som en skill. På workshopen är det till exempel: ”Leverantör B kapar referenser över 35 tecken utan att säga till. Validera längden innan filen skickas.” Sedan följer det med i varje ticket, oavsett vem eller vilken agent som tar den.

  • Ingen rättar sina egna fel

    Agenter med avgränsat ansvar: en läser ticketen, en skriver koden, en testar. Den som skrev koden testar den inte.

  • AI-kod som går att reviewa

    Ett säkerhetsnät av tester som agenten kör själv och som fångar att inget annat gått sönder. Vid review räcker det att se att inget är trasigt.

  • Flera tickets i taget

    Tickets körs parallellt, i rätt ordning och utan att krocka. Det är det som gör kapaciteten till något ni kan planera med.

Upplägget

Två dagar på plats, åtta pass

För hela teamet, 5 till 10 utvecklare passar bäst. Vi kör på vårt demo-repo: en integrationsplattform för betalningar av det slag många stora bolag har, med många regler och flera leverantörer som alla gör på sitt sätt. Varje pass börjar med ett misstag. Sedan lägger vi på det som gör det bättre, tillsammans med er, och förklarar varför.

Dag 1 En agent, en ticket

  1. 1 Kör utan något

    Misstaget

    Agenten tar en ticket utan kontext. Koden ser rimlig ut men bryter mot teamets regler och missar hur just den leverantören gör.

    Vi lägger på

    Inget. Vi reviewar tillsammans och säger högt vad som är fel.

    Insikten

    ”Den förstod inte alls vad vi menar.”

  2. 2 Skriv ner det ni sa

    Misstaget

    Samma ticket. Vi har just förklarat för varandra vad som är fel.

    Vi lägger på

    Det vi sa i reviewen blir en skill. Kör igen.

    Insikten

    Det som förklaras om och om igen är en skill.

  3. 3 Varför vågar ni inte merga?

    Misstaget

    Koden ser rätt ut, men ingen vågar merga. Ingen vet om något annat gått sönder.

    Vi lägger på

    Tester som fångar att inget annat gått sönder, till exempel golden files. Kör igen.

    Insikten

    Vid review räcker det att se att inget är trasigt.

  4. 4 Ny leverantör, nya fel

    Misstaget

    En ticket för en annan leverantör. Agenten gör fel på det som är nytt.

    Vi lägger på

    Deltagarna hittar nästa två eller tre skills och skriver dem själva.

    Insikten

    De ser mönstret själva. Rollskiftet börjar.

Dag 2 Flera agenter, flera tickets

  1. 5 En agent gör allt

    Misstaget

    En agent läser specen, skriver koden och testerna. Testerna bekräftar dess egna fel.

    Vi lägger på

    Agenter med roller: en läser ticketen, en skriver koden, en testar.

    Insikten

    Den som skrev koden ska inte testa den.

  2. 6 Flera tickets samtidigt

    Misstaget

    Flera tickets körs i samma kopia av repot. De krockar, och en ticket körs före den som den beror på.

    Vi lägger på

    Beroenden mellan tickets, i vågor. En egen kopia av repot per agent.

    Insikten

    Många tickets kan köras parallellt när arbetet är isolerat.

  3. 7 En riktig Jira-ticket

    Misstaget

    Agenten hämtar en ticket skriven för en människa: ”som vanligt för Leverantör B”. Den gissar.

    Vi lägger på

    Kopplingen mot Jira. En agent läser ticketen och kravspecen och gör dem entydiga.

    Insikten

    En ticket ska kunna tas av en agent utan att den behöver fråga.

  4. 8 Hela flödet

    Misstaget

    Inget nytt misstag. Nu körs allt.

    Vi lägger på

    Från Jira-ticket till merge, flera tickets parallellt.

    Insikten

    Hela teamet har sett flödet fungera.

Uppföljning efter 1, 3 och 6 veckor

Hemläxa till första uppföljningen: varje deltagare skriver tre skills för ert eget repo. De gör det själva, vi behöver ingen access.

Skillsen ligger i ert repo

Ni äger dem och är inte beroende av oss.

Fast pris per team

Ett team på åtta utvecklare kostar runt 600–700 tusen i månaden. Workshopen kostar en bråkdel av det. Priset får ni på mötet.

En sak att bestämma först

Vad ska kapaciteten gå till?

Flödet blir bara synligt om det inte straffar den som visar det. Utvecklarna är inte emot AI, de är emot att bli mätta. Bestäm före workshopen vad den frigjorda kapaciteten ska gå till, och säg det till teamet. Då får de verktyg, inte en måttstock.

Vad vi hoppar över

Det här lär vi inte ut

  • Vad en LLM är.
  • Hur man promptar.
  • En leksaksapp.

Kurserna på marknaden är orienteringskurser där var och en sitter ensam med en liten övningsapp och lär sig prata med verktyget. Vi kör i ett demo-repo som är stort och krångligt nog att en agent utan kontext gör fel, precis som i er kodbas. Vi säljer inte innehåll per dag. Vi säljer var teamet är efter sex veckor.

Frågor

Det en CTO brukar fråga

”Vi har redan Copilot och Cursor.”
Bra, då har ni verktyget. Vad har det gett i throughput sedan utrullningen? Svaret är nästan alltid ”svårt att säga”. Licensen är ett verktyg. Vi säljer arbetssättet.
”15 minuter låter som en säljsiffra.”
Det är det, tills ni ser flödet. På dag 2 kör hela teamet det, från Jira-ticket till merge. Vi är öppna med att det tog månader att bygga skillsen bakom.
”Vår kodbas är för speciell.”
Det är argumentet för oss. Skills är där er domänkunskap hamnar. Ju konstigare regler, desto mer lönar det sig.
”Måste ni in i vår kod?”
Nej. Workshopen körs på vårt demo-repo, så ni behöver inte ge oss access eller ta oss genom en säkerhetsgranskning. Teamet för över arbetssättet till ert repo själva, med hemläxan och uppföljningarna.
”Mina utvecklare kommer inte gilla det.”
Rätt reaktion, vi var skeptiska själva. De är emot att bli mätta, inte emot AI. Workshopen ger verktyg, inte en måttstock.
”Vad händer efter sex veckor?”
Teamet äger sina skills. De ligger i ert repo. Ni är inte beroende av oss.

Vilka vi är

Vi jobbar redan så här

Vi är utvecklare, inte AI-säljare. I vårt eget team gick en integration från två till tre veckor till 15 minuter, och det är det flödet vi lär ut.

Nästa steg

Ge oss 30 minuter

Vi pratar om hur ert team jobbar med AI i dag och går igenom upplägget. Ni avgör själva om det passar er.