Jag använder LLM:er till mycket i vardagen - när jag reser, för praktiska saker hemma och för att prata igenom och bolla idéer. Jag började experimentera med AI-stödd programmering omkring 2023, när de första riktigt användbara stora språkmodellerna började kännas mindre som kuriositeter och mer som praktiska verktyg.

Då använde jag dem fortfarande ganska begränsat. Jag byggde inga seriösa produktionssystem med dem, och jag litade inte på dem i särskilt komplexa sammanhang. Det de däremot var bra på var att hjälpa mig skapa "toy scripts".

Det var den typ av skript man skriver för att automatisera en återkommande uppgift, transformera en fil, städa upp data eller snabbt testa en idé utan att lägga för mycket struktur eller formalitet på processen.

Resultatet kunde vara hjälpsamt, men det fanns också en viss skörhet i det. Man kunde få något att fungera snabbt, men inte nödvändigtvis något man ville lita på som en del av ett större ingenjörsarbete. Min relation till AI-assisterad kodning under den perioden var därför mer utforskande än grundläggande. Jag lärde mig var det hjälpte, var det inte räckte till och var nyttan faktiskt tog slut.

Det började förändras mot slutet av 2024. Då märkte jag att jag använde modellerna på ett mer genomtänkt och strukturerat sätt. I stället för att bara be dem generera isolerade kodsnuttar började jag ställa en mer intressant fråga: hur kan AI passa in i det sätt jag redan tänker kring system?

Eftersom jag bryr mig mycket om arkitektur, avvägningar, gränser och långsiktig underhållbarhet började jag sätta AI-genererat material bredvid mitt eget arkitektoniska omdöme, inte under det och inte i stället för det. I praktiken innebar det att jag allt oftare använde AI i samband med arkitekturbeslut. Inte för att låta den fatta besluten åt mig, utan för att reagera på dem, testa dem, utmana dem och ibland hjälpa mig att gå från ett konceptuellt beslut till en första implementation snabbare.

Därifrån kändes nästa steg nästan oundvikligt. Under 2025 började jag programmera inte bara med modeller, utan med agenter. Det var ett större skifte än det kanske låter som vid första anblicken.

Det handlade inte längre bara om att öppna ett chattfönster och be om kod. I stället började jag tänka i termer av roller, delegering, arbetsflöden och strukturerat samarbete mellan flera AI-komponenter. Interaktionen blev mer medveten. Jag använde inte längre AI bara för att få fram output på begäran. Jag började bygga ett arbetssätt där AI kunde delta i olika steg av mjukvaruutvecklingen, medan jag fortfarande hade ett fast grepp om riktning, arkitektur och kvalitet.

Den utvecklingen spelar roll eftersom den speglar hur förtroende byggs i ingenjörsarbete: inte genom hype, utan genom upprepad kontakt med verkligheten. Jag behövde se vad de här systemen faktiskt kunde göra, var de skapade värde och var de fortfarande krävde tydlig mänsklig styrning.

Låt oss börja med det nuvarande arbetsflödet.

Nuvarande arbetsflöde

Allt börjar med en ny branch.

För mig står OpenCode i centrum för hela upplevelsen. Det är där jag interagerar med systemet som ingenjör. Det är ytan jag faktiskt använder. Det är där arbetet börjar.

Det viktigaste är att jag egentligen inte "pratar med modellerna" direkt i någon abstrakt mening. I praktiken pratar jag med agenter, där var och en har en roll i ett större arbetsflöde. Ganska ofta är det dessutom olika modeller från olika leverantörer.

Ur mitt perspektiv som användare är relationen till arkitektagenten den viktigaste. Det är den enda agent jag interagerar med direkt. Jag beskriver vad jag vill bygga, vad jag vill ändra, vilka begränsningar jag bryr mig om, vilka avvägningar som spelar roll och vilken typ av resultat jag är ute efter. Samtalet börjar där, och det stannar där tills arbetets form faktiskt är ordentligt förstådd.

Arkitektagenten måste vara väldigt stark, och den får gärna vara långsam. Det är fortfarande rimligt och ger bra värde för pengarna, eftersom det här steget mest består av diskussion. Vi behöver inte utbyta särskilt många tokens.

Den skillnaden är viktig, eftersom arkitekten inte finns där för att rusa in i implementation. Dess roll är att tänka tillsammans med mig. Den hjälper till att rama in problemet, inspektera kodbasen, resonera kring alternativ och gradvis förvandla en idé till en konkret plan. Jag använder den mycket mer som en designpartner än som en kodgenerator. Om något känns för brett, för riskabelt eller för vagt är det här det förfinas. Målet är att implementationen ska börja först när intentionen faktiskt är tydlig.

En av de mest användbara skyddsrälsarna i det här arbetsflödet är att inget går vidare till implementation förrän jag uttryckligen skriver "approved". Jag gillar den regeln eftersom den skapar en medveten paus mellan att tänka och att göra. Den hindrar systemet från att ivrigt springa i väg på halvfärdiga antaganden. Det är annars ett av de enklaste sätten att få imponerande men felriktade resultat. Tills det godkännandet finns kvarstår arbetet på arkitekturnivå: diskussion, förtydligande, avvägningar, gränser, omfattning och intention.

När jag har godkänt planen går systemet in i ett annat läge. Under ytan skriver arkitekten en Markdown-plan som fångar arbetet i en mer operativ form. Den planen är inte bara en grov anteckning. Den fungerar som ett arbetskontrakt för nästa steg. Vanligtvis innehåller den målet med förändringen, de viktigaste designbesluten, vilka filer eller komponenter som sannolikt påverkas, implementationsstegen och den förväntade valideringsvägen, inklusive tester eller andra kontroller. Den förvandlar en designprocess i samtalsform till något uttryckligt, granskningsbart och beständigt. Den använder också min mall för sådana planer, så att jag kan lägga in de accenter jag själv vill ha.

Den planen blir sedan grunden för att delegera arbetet till utvecklaragenten. Där används en billigare modell för att producera mycket implementationsoutput, men fortfarande en vettig sådan. Jag mikrostyr inte den överlämningen. Från mitt perspektiv stannar jag kvar hos arkitekten, medan arkitekten delegerar implementationen till en separat utvecklaragent. Den uppdelningen är en av de saker jag värdesätter mest i upplägget. Den gör att systemet inte blandar ihop design, implementation och utvärdering till en enda suddig aktivitet. Utvecklarens uppgift är att verkställa den godkända planen, inte att uppfinna arkitekturen i stunden.

Under implementationen granskar utvecklaren också planen och de tekniska detaljerna. Ibland går den tillbaka till arkitektagenten med observationer, edge cases eller ett annat perspektiv, och då diskuterar de fram en bättre lösning. Ibland eskalerar arkitekten ett beslut till mig när den inte känner sig helt trygg med nästa steg.

Efter implementationen går arbetet vidare till granskning med några olika modeller, både billiga och dyrare. Det är inte heller något jag hanterar manuellt som en separat ritual utanför flödet. Systemet skickar resultatet vidare till granskande agenter som tittar på utfallet både mot planen och mot de faktiska ändringarna. Det ger processen en rytm som känns bekant från riktigt ingenjörsarbete: först förstå problemet, sedan planera förändringen, därefter implementera den och till sist granska den. Att de här stegen hanteras av olika agenter är ingen gimmick. Det är en del av det som gör arbetsflödet disciplinerat.

Granskningen görs ibland av mer än en agent, så att de kan diskutera utfallet med utvecklaren och, när ett beslut behövs, eskalera det till arkitekten. Arkitekten eskalerar det i sin tur till mig om det känns viktigt.

Vid sidan av planfilerna har jag också en AGENTS.md-fil i repot. Den ger agenterna ett slags operativ kontext: hur repot är strukturerat, vilka konventioner som gäller, hur förändringar bör angripas, vilka mönster som föredras, hur testning förväntas fungera och vilka generella spelregler som gäller. Jag ser den som en stående projektbrief, något som hjälper agenterna att hålla sig i linje med kodbasens karaktär i stället för att varje uppgift börjar från noll. Det är, på sätt och vis, en form av kontextöverföring mellan olika steg i projektets utveckling.

Jag har också en fil med fel och lösningar, så att mina agenter kan lära sig projektets egna egenheter, oavsett om de kommer från konfiguration, infrastruktur, en molnleverantör eller något annat.

I praktiken betyder det att Markdown-filerna i arbetsflödet fyller olika roller. Plan-Markdown fångar den godkända formen för en viss uppgift. AGENTS.md fångar den bredare och mer stabila kontexten för repot, tillsammans med förväntningarna på hur arbetet ska göras. Tillsammans gör de systemet mycket mindre flyktigt. I stället för att allt lever i en tillfällig konversation skrivs viktig intention ner och förs vidare i filer som blir en del av projektet.

I slutet av processen granskar jag fortfarande koden, men jag kan inte fokusera på varje enskild rad. I stället fokuserar jag på arkitekturen, avvägningarna och hur klasser och metoder hänger ihop.

Hur är det med de tråkiga delarna?

En annan del av upplevelsen som jag tycker är särskilt värdefull är att den omgivande verktygskedjan tar hand om mycket av det mer "mekaniska" ingenjörsarbetet åt mig. Den bredare toolchainen hanterar rutinmässiga men nödvändiga steg som att skapa och hantera brancher, göra commits, pusha ändringar och öppna en pull request. Det kan låta som en detalj, men det gör stor skillnad för hur helheten känns. Jag kan hålla fokus på riktning, omdöme och kvalitet, medan den repetitiva leveransstrukturen hanteras konsekvent.

Samma sak gäller validering. Systemet kan köra tester, uppdatera dem när det behövs och använda dem som en naturlig del av implementationsloopen.

Jag är fortfarande ansvarig för de viktiga besluten, men jag gör inte längre varje mekaniskt och tråkigt steg för hand.

Det jag gillar mest med det här arbetssättet är att det bevarar den del av mjukvaruingenjörskapet som jag bryr mig mest om: intention, arkitektur, avvägningar och sammanhang. Jag är fortfarande djupt involverad, men på en annan nivå.

Teknisk stack

Några punkter:

• den huvudsakliga ytan är OpenCode. Det är där jag arbetar när jag bygger mjukvara med LLM:er, och det är där hela arbetsflödet börjar. I stället för att jonglera separata chattar och verktyg för varje steg använder jag det som den centrala miljön för planering, delegering, implementationsflöde och granskningsorkestrering;
• modellen jag använder för arkitektoniskt resonemang är Opus. Jag använder den när jag vill ha den starkaste förmågan att tänka kring struktur, gränser, avvägningar och implementationsriktning. Dess roll är inte att skynda in i kodskrivande, utan att hjälpa till att förvandla en idé till en medveten och välformad plan;
• godkännandegrinden är ordet "approved". Ingenting går vidare till implementation förrän jag uttryckligen skriver det. Det är en av de viktigaste skyddsrälsarna i hela upplägget eftersom det tvingar fram en tydlig separation mellan design och exekvering och hindrar arbetsflödet från att glida in i för tidig kodning innan problemet verkligen har förståtts;
• arkitekten skriver ner planen i Markdown när jag har godkänt en riktning. De här planfilerna fångar uppgiftens omfattning, de viktigaste designbesluten, de förväntade implementationsstegen och valideringsvägen. De utgör bron mellan samtal och genomförande och gör arbetsflödet mer uttryckligt, granskningsbart och beständigt;
• utvecklaragenten tar över när den arkitektoniska planen har godkänts. Dess roll är att implementera arbetet, inte att uppfinna designen i stunden. Den uppdelningen hjälper till att hålla processen disciplinerad: arkitekten tänker, utvecklaren bygger;
• modellen jag använder för implementationsarbete är Sonnet. Den passar bra i exekveringsfasen, där uppgiften redan är strukturerad och de viktigaste arkitekturbesluten redan är fattade. I den rollen blir den motorn som förvandlar en godkänd plan till faktiska kodändringar;
• efter implementation skickas arbetet vidare till granskningsagenter. Deras uppgift är att undersöka resultatet både mot den skrivna planen och mot den faktiska diffen, i stället för att bara fortsätta implementationen. Det ger arbetsflödet ett riktigt granskningssteg som ligger mycket närmare verklig ingenjörspraxis;
• standardmodellen för granskning är Codex. Jag använder den för att kritiskt granska resultatet, identifiera problem och fånga sådant som implementationen kan ha missat. Jag gillar att ha en separat granskningsmodell eftersom granskning blir mer värdefull när den kommer från ett annat perspektiv än det som producerade koden;
• den extra granskare jag ibland använder är Gemini. Jag tar in den när jag vill ha en annan vinkel, andra instinkter eller helt enkelt mer variation i granskningsprocessen. Olika modeller upptäcker olika saker, och den variationen gör helheten starkare;
• modellen jag ibland tar tillbaka som granskare är Opus. För särskilt viktiga, känsliga eller högpåverkande ändringar använder jag den mindre som planerare och mer som en senior second opinion. Den är särskilt användbar när jag vill ha ett slutligt omdöme om huruvida lösningens övergripande form faktiskt håller;
• den sista manuella granskningen sker i min IDE. När agenterna har gjort klart sitt arbete och arkitekten kommer tillbaka till mig med en sammanfattning går jag över till min IDE för att läsa diffen, inspektera förändringens slutliga form och avgöra om jag är nöjd med att den committas. Jag ser fortfarande den mänskliga genomgången som nödvändig, även i ett starkt agentdrivet arbetsflöde. Men om ändringen är väldigt liten granskar jag den via git diff eller OpenCode.

Hur man sätter upp det

Min setup är baserad på macOS.

Det blir enklast om du redan har:

• terminal eller iTerm2;
• Homebrew;
• Git;
• ett konto hos modellleverantörerna, eller tillgång via en aggregator eller proxy;
• repot du vill arbeta i.

Skapa kataloger för din arbetskonfiguration

Exempel:

mkdir -p ~/code
mkdir -p ~/.config/opencode/agents

Installera OpenCode

brew install anomalyco/tap/opencode

Verifiera installationen:

opencode --version

Anslut dina modellleverantörer

Starta OpenCode var som helst:

cd ~/code
opencode

I OpenCode-gränssnittet lägger du till leverantörer genom att skriva:

/connect

Lägg till minst:

• Anthropic - för Opus och Sonnet;
• OpenAI - Codex;
• Google - Gemini.

För att se listan över tillgängliga modeller i OpenCode skriver du:

/models

Varning: leverantörerna kanske inte fungerar första gången. Om det händer, försök igen eller använd en annan metod, till exempel att ange API-nycklarna manuellt.

Sätt upp projektet

Gå till ditt repo:

cd ~/code/your-project
opencode

Kör initieringskommandot:

/init

Det här "berättar" för OpenCode att analysera projektet och skapa en AGENTS.md-fil i repots katalog. Det här bör vara en rutin för att återinitiera projektet. Jag gör det precis före varje uppgift.

Definiera agentstrukturen

OpenCode stöder:

• primary agents - de huvudsakliga agenterna som du kan växla mellan;
• subagents - agenter som anropas av andra agenter, eller manuellt med @.

Jag rekommenderar att sätta upp det så här. Så här har jag det konfigurerat:

• architect = primary;
• developer = subagent;
• reviewers = subagent.

OpenCode har en uttrycklig permission.task-mekanism för att styra vilka subagents som får startas av en annan agent.

Skapa den globala OpenCode-konfigurationsfilen

Skapa filen:

mkdir -p ~/.config/opencode
vim ~/.config/opencode/opencode.json

Min fil ser ut så här:

{
  "$schema": "https://opencode.ai/config.json",

  "model": "anthropic/claude-opus-4.6",

  "permission": {
    "edit": "ask",
    "webfetch": "ask",
    "bash": {
      "*": "ask",
      "git status*": "allow",
      "git diff*": "allow",
      "git log*": "allow",
      "grep *": "allow",
      "rg *": "allow",
      "find *": "allow",
      "ls *": "allow",
      "pwd": "allow"
    }
  },

  "agent": {
    "architect": {
      "mode": "primary",
      "description": "Plans features and bugfixes, writes plan files, and orchestrates developer and reviewers.",
      "model": "anthropic/claude-opus-4-6",
      "permission": {
        "edit": "ask",
        "webfetch": "ask",
        "bash": {
          "*": "ask",
          "git status*": "allow",
          "git diff*": "allow",
          "git log*": "allow",
          "grep *": "allow",
          "rg *": "allow",
          "find *": "allow",
          "ls *": "allow",
          "pwd": "allow"
        },
        "task": {
          "*": "deny",
          "developer": "allow",
          "reviewer-codex": "allow",
          "reviewer-gemini": "allow",
          "reviewer-opus": "allow"
        }
      }
    },

    "developer": {
      "mode": "subagent",
      "description": "Implements only the approved plan, then asks reviewers to review the diff.",
      "model": "anthropic/claude-sonnet-4-6",
      "permission": {
        "edit": "ask",
        "webfetch": "deny",
        "bash": {
          "*": "ask",
          "git status*": "allow",
          "git diff*": "allow",
          "grep *": "allow",
          "rg *": "allow",
          "find *": "allow",
          "ls *": "allow",
          "pwd": "allow",
          "npm test*": "allow",
          "pnpm test*": "allow",
          "pytest*": "allow",
          "go test*": "allow",
          "cargo test*": "allow"
        },
        "task": {
          "*": "deny",
          "reviewer-codex": "allow",
          "reviewer-gemini": "allow",
          "reviewer-opus": "allow"
        }
      }
    },

    "reviewer-codex": {
      "mode": "subagent",
      "description": "Reviews only the approved plan and the resulting diff. No edits.",
      "model": "openai/gpt-5.3-codex",
      "permission": {
        "edit": "deny",
        "webfetch": "deny",
        "bash": {
          "*": "ask",
          "git diff*": "allow",
          "git log*": "allow",
          "git status*": "allow",
          "grep *": "allow",
          "rg *": "allow",
          "find *": "allow",
          "ls *": "allow",
          "pwd": "allow"
        }
      }
    },

    "reviewer-gemini": {
      "mode": "subagent",
      "description": "Independent code reviewer focused on alternate solutions and blind spots.",
      "model": "google/gemini-flash-latest",
      "permission": {
        "edit": "deny",
        "webfetch": "deny",
        "bash": {
          "*": "ask",
          "git diff*": "allow",
          "git log*": "allow",
          "git status*": "allow",
          "grep *": "allow",
          "rg *": "allow",
          "find *": "allow",
          "ls *": "allow",
          "pwd": "allow"
        }
      }
    },

    "reviewer-opus": {
      "mode": "subagent",
      "description": "Senior reviewer used for important work or for resolving reviewer disagreements.",
      "model": "anthropic/claude-opus-4-6",
      "permission": {
        "edit": "deny",
        "webfetch": "deny",
        "bash": {
          "*": "ask",
          "git diff*": "allow",
          "git log*": "allow",
          "git status*": "allow",
          "grep *": "allow",
          "rg *": "allow",
          "find *": "allow",
          "ls *": "allow",
          "pwd": "allow"
        }
      }
    }
  }
}

Varning: i din /models-lista kan de exakta ID:na skilja sig lite. Justera modellidentifierarna därefter, annars är risken stor att det inte fungerar. Du behöver bara kontrollera modell-ID:n i OpenCode och ange eller rätta dem i JSON-konfigurationen.

Lägg till instruktioner för agenterna

Arkitekt

vim ~/.config/opencode/agents/architect.md

Filinnehåll:

---
description: Senior architect and orchestrator
mode: primary
---
You are the architect.
Your job is to:
- talk to the user until the feature or bugfix is fully understood
- clarify goals, scope, constraints, edge cases, limitations, and trade-offs
- shape the implementation plan together with the user
- keep all high-level architectural choices under tight control
- avoid implementation until the user explicitly writes: approved
Rules:
- Do not start coding before the exact word "approved" appears in the conversation from the user.
- Before approval, only analyse, ask questions, inspect the codebase, and propose architecture.
- Once approved, write a concrete low-level plan into a plan file inside the repository.
- The plan must mention the files to change, the components involved, and the expected tests.
- Then delegate implementation to @developer.
- After implementation, require independent review from reviewers.
- If reviewers disagree, you are the final arbiter.
- Prefer solutions already present in the codebase over introducing novel patterns.
- Optimise for maintainability and coherence with the existing codebase, not theoretical elegance.

Developer

vim ~/.config/opencode/agents/developer.md

Filinnehåll:

---
description: Implements only approved plans
mode: subagent
---
You are the developer.
Your job is to:
- implement only what is in the approved plan file
- avoid making new architectural decisions unless absolutely necessary
- stay consistent with existing project patterns
- run relevant tests or checks where possible
- once implementation is complete, ask the reviewers to review the plan and the diff
Rules:
- Do not widen scope.
- Do not redesign the architecture.
- If the plan is unclear or conflicts with the codebase, escalate to the architect instead of improvising.
- If reviewers agree on improvements, implement them.
- If reviewers disagree, escalate to the architect with a concise summary of the conflict.

Granskare: Codex

vim ~/.config/opencode/agents/reviewer-codex.md

Filinnehåll:

---
description: Strict diff reviewer
mode: subagent
permission:
 edit: deny
 webfetch: deny
---
You are a strict code reviewer.
Review only:
- the approved plan
- the resulting diff
- relevant nearby code if needed
Your review must:
- identify correctness issues
- identify missing edge cases
- identify regressions
- identify places where the implementation diverges from the approved plan
- distinguish clearly between:
 - must fix
 - should fix
 - optional / pedantic
Do not rewrite the code yourself.
Do not praise for the sake of praise.
Prefer concise, concrete review points.

Granskare: Gemini

vim ~/.config/opencode/agents/reviewer-gemini.md

Filinnehåll:

---
description: Alternative-perspective reviewer
mode: subagent
permission:
 edit: deny
 webfetch: deny
---
You are an independent reviewer.
Focus on:
- blind spots
- alternative approaches
- surprising edge cases
- places where the chosen solution is locally correct but globally awkward
Be concise and concrete.
Mark each point as:
- must fix
- should fix
- optional

Granskare: Opus

vim ~/.config/opencode/agents/reviewer-opus.md

Filinnehåll:

---
description: Senior reviewer for important work
mode: subagent
permission:
 edit: deny
 webfetch: deny
---
You are a senior reviewer.
Review the approved plan and the diff with emphasis on:
- architecture consistency
- maintainability
- hidden risks
- correctness vs implementation effort trade-offs
Your role is especially important when reviewers disagree.
Be decisive and practical.

Sätt standardinnehållet i AGENTS.md-filen

vim ~/code/your-project/AGENTS.md

Filinnehåll, bara som exempel. Du vill troligen göra det mer projektspecifikt:

# AGENTS.md
## Project conventions
- Prefer existing patterns over introducing new abstractions.
- Keep changes minimal and local.
- Avoid speculative refactors.
- Add tests for behaviour changes when practical.
- Do not change public interfaces unless required by the task.
## Workflow
- The architect is the only agent that talks directly to the user.
- No implementation starts until the user writes "approved".
- Every non-trivial change must have an approved plan file.
- The developer implements only the approved plan.
- Reviewers review the plan and the diff.
- Reviewer disagreements go back to the architect.
## Review expectations
- Separate must-fix issues from optional suggestions.
- Optimise for correctness and maintainability.
- Avoid pedantry unless the issue is likely to matter in practice.

Sätt en konvention för planfiler

Skapa en katalog för planer i repot:

mkdir -p plans

Template mall:

# Plan: <feature name>

## Goal
What we are adding or fixing.

## Constraints
Technical and product constraints.

## Decisions
High-level choices that have already been approved.

## Files to change
- path/file1;
- path/file2.

## Planned changes
1. ...
2. ...
3. ...

## Tests / validation
- unit tests;
- integration tests;
- manual checks.

## Out of scope
- ...

Hur man arbetar från dag till dag

Den operativa rutinen är enkel.

Öppna repot och starta OpenCode

cd ~/code/your-project
opencode

Växla till arkitekten

Om den inte redan är aktiv som standard använder du agentväxling ([tab]). OpenCode stöder primary agents som du kan växla mellan.

Prata bara om målet

Det är precis andan i det här arbetsflödet. Berätta bara för arkitekten vad du vill uppnå och förfina det sedan i samtal, ibland i en timme, tills ni tillsammans har arbetat fram arkitekturen och avvägningarna.

Godkänn med ett enda ord

När planen känns rätt skriver du:

"approved"

Arkitekten sparar planen

Det sker automatiskt, så du behöver inte göra något mer.

Utvecklaren implementerar den

Utvecklaren finns inte där för att uppfinna arkitekturen. Deras uppgift är att verkställa planen, köra rimliga tester och lämna över diffen för granskning.

Granskning

Efter implementationen sker granskningen automatiskt.

Integrera feedback

Regeln är:

• om granskarna är överens gör utvecklaren ändringarna;
• om deras feedback krockar går det tillbaka till arkitekten.

Standardregler för säkerhet

Eftersom du arbetar i ditt eget repo bör du inte lägga allt på full autopilot.

Jag har satt upp mitt så här:

• edit: ask for architect/developer;
• edit: deny for reviewers;
• webfetch: deny for reviewers;
• bash only for safe commands such as git diff, git status, rg, grep, and tests.

Vanliga misstag med den här setupen

Det här är sådant som med störst sannolikhet får arbetsflödet att spåra ur.

För lite kontroll över arkitekturen

Om du inte förstår tekniken tillräckligt väl kommer modellen att fatta dåliga beslut som du inte fångar i tid. Sedan fortsätter den bygga vidare på de misstagen och lägger till fler lager av röra.

Att granska med samma modell

Det undergräver hela poängen med granskning, eftersom en modell tenderar att hålla med sig själv. Man kan komma lite längre genom att ge den en bättre prompt, till exempel "try to disagree with this code and look for problems", men i mitt fall räckte inte heller det.

Vad händer härnäst

Så här tänker jag utveckla det här arbetssättet framöver:

• hantering och automatisering av Markdown-filer för fel;
• automatisk insamling av issues från GitHub;
• flera OpenCode-sessioner över olika maskiner;
• mer petiga granskningar och refaktoreringar - att förenkla saker, upptäcka överkonstruerade lösningar och proaktivt leta efter bättre arbetssätt genom arkitektmodellen, kanske då och då via någon scheduler eller enkel cronjob som proof of concept;
• project manager as a service.