Från individuell AI till organisatorisk AI: repo-regler som det saknade lagret

Varje utvecklingsteam ställer samma fråga 2026: vilket AI-kodningsverktyg bör vi använda?

Det är fel fråga.

Verktyget är flyktigt

Roo Code — ett populärt VS Code-tillägg forkat från Cline, använt av tusentals utvecklare — stängde ned den 15 maj 2026. Två veckors varsel. Teamet pivotade till en molnbaserad produkt och övergav tillägget.

Varje utvecklare som använde Roo Code var tvungen att migrera över en natt. Deras promptningsvanor, deras muskelminne, deras arbetsflöde — allt knutet till ett verktyg som inte längre existerar.

Det här är ingen anomali. Det är mönstret. AI-kodningsverktyg 2026 är en snabbrörlig marknad där förvärv, pivotar och nedstängningar sker kvartalsvis. Cursor kan ändra sin prismodell. GitHub Copilot kommer att omstrukturera sina nivåer. Ett nytt verktyg kommer att dyka upp som gör dagens favorit obsolet.

Om din AI-förmåga lever inuti verktyget, dör den med verktyget.

Vad som överlever ett verktygsbyte

En sak överlevde Roo Code-nedstängningen utan modifiering: regelfilerna i repositoryt.

Varje seriöst AI-kodningsverktyg 2026 läser projektnivåkonfiguration från filer committade till git:

Verktyg	Regelfil	Scope
Claude Code	CLAUDE.md + .claude/rules/	Projekt + workspace + användare
Kilo Code	.kilocode/rules/	Projekt
Cline	.clinerules/	Projekt
Cursor	.cursorrules + AGENTS.md	Projekt
Codex CLI	AGENTS.md	Projekt
GitHub Copilot	.github/copilot-instructions.md	Org + repo

Dessa filer är ren text, versionshanterade och granskade som kod. De följer med repositoryt, inte med verktyget. När en utvecklare byter från Roo Code till Kilo Code — eller från Cursor till Claude Code — stannar reglerna kvar.

Det här är inte en teknisk detalj. Det är den arkitektoniska insikten som skiljer organisationer med bestående AI-förmåga från organisationer med individer som råkar använda AI.

Vad som ingår i reglerna

Regelfiler är inte promptbibliotek. De är inte "tips för bättre AI-output." De kodar hur din organisation arbetar:

Arkitekturstandarder. "Det här projektet använder modulär monolit-arkitektur med fem lager: presentation, service, repository, modell, data. All ny kod måste följa denna struktur."

Teknologibegränsningar. "Vi använder Laravel 11 med PHP 8.3. Föreslå inte lösningar i andra frameworks. Introducera inte nya beroenden utan godkännande."

Kvalitetskrav. "Alla databasfrågor måste använda repository-lagret. Ingen råSQL i controllers. Alla publika metoder kräver PHPDoc."

Namnkonventioner. "Databastabeller använder snake_case plural. Modeller använder PascalCase singular. API-endpoints använder kebab-case."

Domänterminologi. "En 'journey' är en schemalagd rutt. En 'trip' är ett enskilt genomförande av en journey. Blanda inte ihop dessa termer."

Dessa regler är inte förslag. De är begränsningar som hindrar AI från att generera kod som kompilerar men bryter mot dina standarder — den typ av kod som skapar teknisk skuld osynligt.

Beviset: 90 % av problemen

En CTO vi arbetar med granskade varje commit i sitt teams CI/CD-pipeline under åtta månader. Hans slutsats: 90 % av den problematiska koden var AI-genererad.

Inte för att verktygen var dåliga. Utan för att utvecklarna använde AI utan gemensamma standarder. Varje utvecklare promptade på sitt eget sätt, med sina egna antaganden, och producerade kod som såg korrekt ut men bröt mot arkitektoniska mönster, ignorerade lageruppdelning eller introducerade inkonsekvenser som bara dök upp vid integration.

CTOn hade byggt omfattande utvecklingsriktlinjer — arkitekturstandarder, use case-mallar, lagerdefinitioner. Han distribuerade dem till teamet. Nästan ingen följde dem.

Inte för att riktlinjerna var fel. Utan för att det saknades en mekanism för att tillämpa dem vid tidpunkten för kodgenerering. Riktlinjerna levde i ett dokument. Kodgenereringen skedde i ett verktyg som aldrig hade läst det dokumentet.

Regelfiler löser detta. När arkitekturstandarden finns i CLAUDE.md eller .kilocode/rules/ läser AI:n den innan den genererar en enda rad. Standarden är inte ett dokument som utvecklaren borde ha läst — det är en begränsning som verktyget inte kan ignorera.

AGENTS.md: den framväxande cross-tool-standarden

Under 2026 håller en de facto-standard på att växa fram: AGENTS.md. Flera verktyg — Codex CLI, Cursor och alltfler andra — läser den här filen för projektnivåinstruktioner.

Konvergensen är logisk. Utvecklare byter verktyg. Team använder olika verktyg för olika uppgifter. Ett projekt kan använda Cursor för frontendarbete och Claude Code för backend-refaktorering. Om reglerna lever i ett verktygsspecifikt format måste de dupliceras och underhållas separat.

AGENTS.md är inte universell ännu, men riktningen är tydlig: projektregler kommer att konvergera på ett fåtal format som fungerar tvärs över verktyg. Organisationer som börjar koda sina standarder nu — i vilket format deras nuvarande verktyg än stöder — är positionerade att migrera dessa regler framåt i takt med att ekosystemet mognar.

Individuell AI vs organisatorisk AI

Det här är distinktionen som spelar roll:

Individuell AI är en utvecklare som använder ett verktyg med personliga promptningsvanor. Outputkvaliteten beror helt på den personens skicklighet, kontextmedvetenhet och disciplin. När de lämnar teamet tar de sin AI-förmåga med sig. När verktyget förändras bryter deras arbetsflöde.

Organisatorisk AI är ett team som använder verktyg begränsade av delade regler committade till repositoryt. Outputkvaliteten har ett golv — ingen AI-genererad kod kan bryta mot de kodade standarderna, oavsett vilken utvecklare som promptade. När någon slutar stannar reglerna kvar. När verktyget förändras migrerar reglerna med.

Skillnaden mellan dessa två tillstånd är inte ett träningsproblem. Det är ett styrningsproblem. Och lösningen är inte fler workshops om promptning — det är regelfiler i git.

Dokumentationsfällan

Det finns en variant av detta som misslyckas.

Ett team körde sitt första AI-hanterade projekt med strikta dokumentationskrav och obligatoriska kodgranskningar. Varje pull request skickades tillbaka tre eller fyra gånger. Varje arkitektoniskt beslut dokumenterades formellt. På papperet var det det mest disciplinerade projekt de någonsin hade kört.

Det gick inte snabbare. Kvaliteten var sämre.

Samtidigt levererade projekt drivna av en annan ledare — verbal, målorienterad, beslut fattade i samtal snarare än i dokument — i tid.

Skillnaden var inte dokumentation kontra ingen dokumentation. Det var vad dokumentationen kodade. Den strikta processen dokumenterade compliance: följde du stegen, passerade du grindarna, godkände granskningen? Det verbala förhållningssättet kodade förståelse: vad försöker vi uppnå, vad behöver kunden, hur ser "klart" ut?

Regler som kodar förståelse skapar förmåga. Regler som verkställer compliance skapar friktion. De tre filerna i avsnittet "Kom igång" nedan handlar inte om att lägga till grinder — de handlar om att få AI:n att förstå vad ditt team redan vet. Arkitekturstandarder, domänterminologi, granskningskriterier. Inte sign-off-checklistor.

Om dina repo-regler läses som en byråkratisk process kommer de att producera byråkratisk kod. Om de läses som en senior utvecklare som förklarar systemet för en ny kollega kommer de att producera kod som hör hemma i systemet.

Det styrningslager ingen byggde

De flesta organisationer 2026 har investerat i AI-verktyg. Licenser köpta. Konton provisionerade. Kanske en workshop eller två. Vissa har mätt adoption genom token-förbrukning eller användningsdashboards.

Nästan ingen har byggt styrningslagret: regelfilerna, granskade och underhållna som kod, som kodar hur AI bör bete sig i deras specifika kontext.

Det här är det saknade lagret. Utan det: - Varje utvecklare återuppfinner standarder i varje prompt - Arkitektoniska beslut fattas av modellen, inte av teamet - Kodgranskningar fångar AI-genererade brott mot standarder i efterhand istället för att förebygga dem - Verktygbyten nollställer teamet - Nyanställda har inget kodat sammanhang att arbeta med

Med det: - Standarder tillämpas automatiskt vid genereringstillfället - Arkitektoniska mönster verkställs innan kodgranskning - Verktygbyten bevarar organisatorisk kunskap - Nya utvecklare ärver teamets ackumulerade AI-styrning från dag ett - CTOn granskar regler istället för varje enskild commit

Kom igång: tre filer, en vecka

Att bygga organisatorisk AI-styrning kräver inte ett transformationsprogram. Det kräver tre filer och en veckas uppmärksamhet:

Dag 1–2: Skriv arkitekturfilen. Dokumentera din projektstruktur, lagerdefinitioner, teknologibegränsningar och namnkonventioner. Lägg den i vilket regelformat ditt nuvarande verktyg läser. Använder du Claude Code, skriv CLAUDE.md. Använder du Kilo Code, skapa .kilocode/rules/architecture.md. Använder du flera verktyg, skriv AGENTS.md.

Dag 3–4: Lägg till domänterminologi. Definiera de termer som är specifika för din verksamhet. AI-modeller är tränade på generellt språk — de kommer att använda "user" när du menar "passenger," "order" när du menar "booking," "message" när du menar "notification." En terminologifil förebygger detta.

Dag 5: Granska veckans output. Med regler på plats, granska den AI-genererade koden från veckan. Var hjälpte reglerna? Var misslyckades de? Vad saknas? Uppdatera filerna.

Det här är inte en engångsinställning. Regelfiler är levande dokument — de utvecklas med varje kodgranskning som avslöjar en lucka. Men investeringen är liten: några timmars skrivande, committat till git, granskat som vilken annan kodändring som helst.

Avkastningen är organisatorisk AI-förmåga som består tvärs över verktygbyten, teambyten och den obönhörliga omsättningen på AI-verktygsmarknaden.

Frågan att ställa

Sluta fråga "vilket AI-verktyg bör vi använda?" Varje verktyg 2026 är tillräckligt kapabelt. Skillnaderna ligger i prissättning, modellåtkomst och gränssnittspreferenser — viktigt, men inte strategiskt.

Börja fråga: "Vilka regler innehåller vårt repository?"

Om svaret är inga har du inte organisatorisk AI-förmåga. Du har individer som råkar använda AI-verktyg. Outputen är lika inkonsekvent som individerna, kunskapen lika skör som deras anställningstid, och förmågan lika hållbar som det nuvarande verktygets roadmap.

Verktyget är råvaran. Reglerna är tillgången.

---

Tomas Andre reflekterar över varför verktygsfrågan alltid är fel — tomasandre.se/insights.