Vi anställer människor som vill bygga med agenter — inte bara använda dem. Vi arbetar som ett vanligt, väl skött utvecklingsteam, men övervakade AI-agenter gör det mesta av arbetet i varje steg. Människor äger prioritering, kvalitet och det som når kunderna. Hemtjänst är det svåra, verkliga området där flödet måste hålla.
Bygg först betyder: plan före kod, små vertikala leveranser, spårbarhet och mänskligt ansvar före automatisering — samma kontinuerliga lärandeloop som produkten själv.
Vi skriver ner mål, risker och användarvärde innan vi låter agentflöden implementera.
AI kan producera mycket, men kod, design, innehåll och dataflöden granskas som produktarbete.
Hemtjänst är platsen där flödet måste fungera i verkligheten: planerare, vårdgivare, klienter och anhöriga — inte en demosandlåda.
Vi föredrar användbara förbättringar som går att testa, mäta och förbättra framför stora, svårgranskade språng.
Leveransmandat
Produktägare beskriver förändringen med mål, icke-mål och acceptanskriterier. Kodagenter planerar, implementerar och verifierar i en isolerad arbetskopia, bakom samma kvalitetsgrindar som all annan kod. Människor äger prioritering, arkitektur och release till produktion.
Det vi mäter
Vi mäter som vilket leveransteam som helst: ledtid till huvudgrenen, andel rätt första gången och andel ändringar som orsakar fel — plus modellkostnad per ändring. Poängen är inte att ersätta produktbedömning — det är att ta bort onödiga överlämningar i arbete som redan är specificerat.
Arbetsflöde
Varje steg är ett välkänt mönster från mjukvaruutveckling med en grind, och nästa steg börjar inte förrän grinden är passerad. Det som ändras är vem som utför det: agenter gör arbetet, människor fattar besluten.
| # | Steg | Utförs av | Människans roll |
|---|---|---|---|
| 0 | Krav | Människa, ofta med en agent som skriver utkastet: mål, icke-mål, acceptanskriterier | Bestämmer vad, varför och när |
| 1 | Plan | Kodagent, mot regler och dokumentation; en liten, vertikal ändring | Leder större arkitekturbeslut |
| 2 | Branch | Kodagent i en isolerad arbetskopia med egen testdata | — |
| 3 | Bygg | Kodagent: kod, tester och dokumentation i samma ändring | — |
| 4 | Kontinuerlig integration | Automatiska kontroller vid commit, push och merge | Äger reglerna som kontrollerna upprätthåller |
| 5 | Kodgranskning | Granskningsagenter; varje kommentar får en rättning eller en skriftlig motivering | Avgör tvister och undantag |
| 6 | Merge och test | Merge-kö, sedan automatiska kundresor i en produktionslik spegel | Beslutar om fulla testkörningar |
| 7 | Release | Automatisk release bakom en deploy-grind | Startar releasen |
| 8 | Drift och underhåll | Larm startar en agent som föreslår en rättning; schemalagda agenter letar buggar, refaktorerar och håller dokumentationen aktuell | Granskar förslag och prioriterar |
Fördjupning
Varje del av arbetsflödet visas som en bit av samma modell, så kandidater och partners ser hur strategi, implementation, verifiering och granskning hänger ihop.
Uppgiften är att korta vägen från produktavsikt till verifierad förändring — utan att ta bort ansvar. Människor äger prioritering, kvalitet och beslut.
Arbetet delas mellan samma roller som i ett vanligt team: planera, bygga, granska, verifiera och ha jour. Varje roll använder den modell som passar uppgiften, kostnaden och risken.
Processen beskriver roller och grindar, inte verktyg. Vi byter kodverktyg eller modell när ett bättre finns, utan att ändra hur arbetet granskas och släpps.
Krav skrivs med testbara acceptanskriterier och tydliga icke-mål. Då vet en agent när den är klar, och en granskare kan se om ändringen gör det som var tänkt.
Automatiska kontroller vid commit, push och merge håller arkitektur, typer, format och kontrakt. Det som måste hålla ligger i grindar, inte i instruktioner.
Granskningsagenter läser varje ändring som en kollega. Varje kommentar får en rättning eller en skriftlig motivering, och granskningen har ett slut: krymper fynden inte byter vi metod.
Ändringar prövas i flera lager: tester, låsta kontrakt, automatiska kundresor i en produktionslik miljö och, för synliga ändringar, bevis från en riktig webbläsare.
En människa släpper till produktion efter test i en spegel av produktionen. Övervakningen larmar vid fel, och en agent utreder och föreslår en rättning som en människa granskar.
Schemalagda agenter letar buggar, refaktorerar och mäter prestanda. Dokumentationen pekar på koden den beskriver och läses om när koden ändras.
Vi mäter ledtid, kostnad per ändring, andel rätt första gången och andel ändringar som orsakar fel. Fart räknas bara om kvaliteten håller.
Vi påstår inte att vårt flöde är den enda rätta vägen. Det följer etablerad praxis för effektiva agenter, mänsklig översikt och kontinuerlig leverans. Här är källor att läsa själv:
Relaterade sidor i produkt- och plattformsberättelsen — med fungerande länkar.
Fördjupningen nedan går igenom mönstren, grindarna, granskningen, releasen och driften.
Produkten vi bygger och sättet vi bygger på delar samma filosofi: spåra vad som ändras, lär av utfall och låt människor vara ansvariga för viktiga beslut.
Fördjupning
Vi bygger mjukvara som ett vanligt, väl skött utvecklingsteam: krav, plan, branch, kod och tester, kontinuerlig integration, kodgranskning, merge, test i en produktionslik miljö, release, övervakning och underhåll. Skillnaden är att övervakade AI-agenter gör det mesta av arbetet i varje steg. Människor äger prioritering, bedömning och det som når kunderna.
En loop, inte en rak linje. Människan äger början och slutet: vad som byggs och vad som når produktion. Ett fel i drift blir ett förslag till rättning som en människa granskar.
Agenterna är inte ett stöd vid sidan av utvecklingen. De är sättet vi bygger på. Fyra åtaganden håller det ansvarsfullt, oavsett vilka verktyg och modeller vi använder just nu.
Människor sätter prioritet och arkitektur, äger undantagen och släpper till produktion. Agenterna planerar, implementerar, verifierar och tar ändringen hela vägen till huvudgrenen.
Alla kodagenter läser samma regler och samma dokumentation och möter samma grindar. Byter vi verktyg eller modell ändras inte processen.
Varje viktig regel har en enda implementation, och automatiska kontroller stoppar en andra väg runt den. Så bygger inte många agenter parallella sanningar.
Det som påverkar drift kräver en människa. En agent som reagerar på ett produktionsfel lämnar ett förslag till rättning. Den släpper aldrig själv och ändrar aldrig produktionen.
Varje steg är ett etablerat mönster från modern mjukvaruutveckling. Det som ändras är vem som utför det. Grindarna blir tyngre ju närmare produktionen en ändring kommer.
Kontroller och granskning skickar tillbaka ändringen tills allt är löst. Releasen till produktion startas av en människa.
Vi mäter som vilket leveransteam som helst, med ett tillägg för kostnaden. Fart som ger fler fel räknas inte som fart.
Tiden från att en ändring beskrivs till att den ligger i huvudgrenen.
Modell- och beräkningskostnad per ändring som landar. Svåra steg får starkare modeller, mekaniska steg billigare.
Andelen ändringar som går igenom kontroller och granskning utan en ny omgång.
Hur ofta en release behöver rättas eller rullas tillbaka.
Agenterna tar över det mesta av skrivandet. Människorna flyttar uppåt: till prioritering, bedömning och ansvar för det som når kunderna.
Bestämmer vad och när Formulerar mål, icke-mål och acceptanskriterier. Äger undantag och beslutar om fulla testkörningar. Släpper till produktion. 🤖
Bygger och tar ändringen till huvudgrenen Planerar mot regler och dokumentation och arbetar isolerat. Skriver kod, tester och dokumentation i samma ändring. Bemöter varje granskningskommentar innan ändringen landar. 🔍
Granskar som en kollega Läser hela ändringen och letar efter fel. Specialiserade granskare tittar på prestanda, säkerhet och arkitektur. Håller agenters och människors kod till samma krav. 🛠️
Äger själva arbetssättet Utvecklar grindar, agentinstruktioner och budgetar per typ av arbete. Väljer verktyg och modeller utan att processen behöver ändras. Mäts på ledtid, kostnad per ändring, rätt första gången och andel ändringar som orsakar fel. 📡
Har jouren Startas av ett allvarligt larm från produktionen. Utreder orsaken och lämnar ett förslag till rättning. Släpper aldrig själv och ändrar aldrig produktionen. 🗓️
Hittar arbete innan någon ber om det Letar buggar och kodlukter på fasta tider. Granskar prestanda och dokumentationens aktualitet. Lämnar fynden som vanliga ändringar bakom samma grindar.
Många agenter som arbetar samtidigt behöver skydd som inte beror på att någon minns en regel. Kodagenten är omgiven av mekanismer som kan stoppa den.
Åtta oberoende skyddsräcken. Inget av dem räcker ensamt. Tillsammans låter de många agenter arbeta samtidigt utan att huvudgrenen eller produktionen tar skada.
En ändring i kärnflöden måste beskriva vad den påverkar, och ett låst förväntat värde får inte ändras bredvid koden det vaktar. "Uppdatera testet så att det går igenom" fastnar.
Rättningar samlas per granskningsomgång. Ett fynd kan besvaras med en motivering i stället för en ny ändring. Krymper fynden inte byter vi metod i stället för att fortsätta lappa.
Filer får inte växa obegränsat, och nya genvägar förbi typsystemet stoppas. Kod som är lätt att läsa är lätt att granska, för både människor och agenter.
En release prövas först i en produktionslik miljö där inga meddelanden når kunderna. Först därefter släpps den till produktion.
Människor och agenter använder samma dokumentation. Den hålls ihop med koden av automatik, inte av goda föresatser.
En agent läser reglerna och sedan bara den dokumentation uppgiften behöver. Koden avgör hur systemet beter sig; dokumentationen beskriver avsikt, ordförråd och arkitektur.
En sida som beskriver kod pekar på den koden. När koden ändras flaggas sidan, och en agent läser om den innan ändringen landar.
En plan som en agent ska genomföra har testbara acceptanskriterier och en tydlig avgränsning. När arbetet är klart tas planen bort ur kön i samma ändring.
Inget här är unikt. Det är etablerad praxis för leverans, tillämpad konsekvent på agenter.
Varje agent har egen arbetskopia, egen branch och egen testdata. Därför kan många agenter arbeta samtidigt utan att skriva över varandras arbete.
Gränssnitt, API, logik, tester och dokumentation flyttar i samma ändring. En ändring som går att testa från början till slut är lättare för både agent och granskare att bedöma.
Regler som måste hålla ligger i automatiska kontroller. Instruktioner ger vägledning, och grindarna ser till att den följs.
Människor äger releasen och undantagen. Agenterna gör resten, och det de gör syns i ändringshistorik, granskningar och revisionsspår.
| Mönster | Vem utför det | Människans roll |
|---|---|---|
| Krav och prioritering | Människa, ofta med en agent som skriver utkastet | Bestämmer vad, varför och i vilken ordning |
| Design och plan | Kodagent, mot regler och dokumentation | Leder större arkitekturbeslut |
| Feature-branch | Kodagent i en isolerad arbetskopia med egen testdata | — |
| Implementation och tester | Kodagent | — |
| Kontinuerlig integration | Automatiska kontroller vid commit, push och merge | Äger reglerna som kontrollerna upprätthåller |
| Kodgranskning | Granskningsagenter, lokalt och på pull requesten | Avgör tvister och undantag |
| Merge | Merge-kö när kontroller är gröna och granskningen är löst | — |
| Test i produktionslik miljö | Automatiska kundresor i en spegel av produktionen | Beslutar om fulla testkörningar |
| Release | Automatisk release bakom en deploy-grind | Startar releasen |
| Övervakning och jour | Larm startar en agent som utreder och föreslår en rättning | Granskar förslaget och beslutar |
| Underhåll och teknisk skuld | Schemalagda agenter som letar buggar, refaktorerar och mäter prestanda | Prioriterar det de hittar |
| Dokumentation | Agenter som håller dokumentationen i takt med koden | Avgör vad som är sant |