Hoppa till innehåll
September 16, 2026

Vad är en mjukvarufabrik för AI-kodningsagenter

En mjukvarufabrik, i den mening Ivy Tendril använder begreppet, är en fast sekvens av steg med kontrollpunkter som omvandlar ärenden till granskade pull requests. Ett ärende eller en idé kommer in. En agent formulerar en plan. En människa granskar och godkänner planen. Agenter verkställer den i isolerade Git-worktrees. Automatiserad verifiering kör tester, linter och diff-inspektion. En människa granskar den resulterande diffen. En pull request öppnas. Sekvensen är exakt densamma för varje uppgift, medan agent och modell kan anpassas per uppgift. Det finns precis två mänskliga kontrollpunkter – vid planen och vid diffen – och ingenting slås samman utan godkännande.

De olika stegen

Skapa plan

Indatan är en instruktion inskriven i Tendril, ett GitHub-issue eller en jam.dev-felrapport mottagen via webhook, en röstanteckning transkriberad med Whisper eller filer som släppts i prompten. CreatePlan-promptware läser kodbasen och sammanställer en plan: vad som ska ändras, var ändringarna sker och hur de ska verifieras.

Utkast

Planen sparas i utkast. Ingenting har ännu körts. Den väntar där tills en utvecklare läser den.

Plangranskning

Detta är den första kontrollpunkten. Granskaren läser planen och väljer en av fem åtgärder: godkänner den, kör ExpandPlan för mer detaljer, kör SplitPlan för att dela upp en stor plan i flera mindre, kör UpdatePlan för att justera, eller kommenterar direkt i utkastet varpå planen skrivs om. En plan som inte ska genomföras nu flyttas till Icebox.

Verkställ i worktrees

Vid godkännande startar ExecutePlan-promptware den valda agenten – Claude Code, Codex CLI, Copilot CLI, Gemini CLI, OpenCode eller någon annan CLI-agent – i ett eget Git-worktree på en egen branch. Guiden Git worktrees för parallella AI-agenter förklarar varför denna isolering gör det säkert att köra många planer samtidigt. Många planer körs parallellt. Jobs-vyn strömmar varje agents utdata. Huvudgrenen (main) förblir helt orörd.

Verifiera

Tester, linter och diff-granskning körs mot worktreet och resultaten kopplas direkt till planen. Detta är kontinuerlig integration tillämpad per plan istället för per gren. Vilka kontroller som bör ingå beskrivs i verifieringsgrindar för AI-genererad kod. I Pro och Enterprise kan verifieringsresultat även hämtas från GitHub Actions eller externa CI-system.

Diffgranskning

Detta är den andra kontrollpunkten. Review-vyn visar diffen i en flik och verifieringsresultaten i en annan. Granskaren godkänner, eller uppdaterar planen och kör den igen.

Pull request

CreatePr-promptware öppnar en pull request på GitHub med en tydlig sammanfattning av ändringen. Merging sker i GitHub som vanligt. Token-användning och kostnad för planen loggas i översikten (Dashboard).

Varför två mänskliga kontrollpunkter och inte noll eller tio

Noll kontrollpunkter innebär att en agent gör commits direkt till main. Fel upptäcks först efter att de drabbat andra utvecklare eller användare, och att rulla tillbaka en sammanslagen ändring kostar mer än att granska den i förväg. Det innebär också att den som är ansvarig för koden aldrig faktiskt har läst den.

Tio kontrollpunkter innebär godkännande av varje enskild filändring eller verktygsanrop. Människan blir flaskhalsen, agenter står stilla i väntan på klick, parallell exekvering tappar sitt värde och granskare slutar läsa och börjar godkänna av ren vana.

Två kontrollpunkter placerar människan exakt där omdömet gör störst skillnad: Planen är platsen där missförstånd är billigast att rätta till – ingen kod har skrivits ännu. Diffen är platsen där korrekthet bekräftas: verifieringen är klar, ändringen är komplett och en människa fattar beslutet om sammanslagning. Allt däremellan är automatiserat. Livscykeldokumentationen beskriver varje övergång.

Vad förändras för ett utvecklingsteam

Genomströmning. Eftersom planer körs parallellt och människan endast deltar vid två punkter, begränsas teamets kapacitet av granskningsförmåga snarare än av skrivhastighet. Ivy rapporterar att det egna teamet ökade från cirka 10 till över 100 pull requests per dag efter att ha infört arbetsflödet.

Förutsägbarhet. Varje uppgift passerar samma steg, vilket innebär att status betyder samma sak för varje ärende. Dashboarden visar hur många planer som befinner sig i varje skede, kostnad per plan, kostnadstrender och Git-aktivitet.

Kunskap som ackumuleras. Varje fas styrs av en promptware-enhet: en Program.md med instruktioner, en Memory/-katalog med lärdomar, Tools/ med avgränsade behörigheter och Logs/ över varje körning. Efter en körning skriver agenterna sina insikter om kodbasen tillbaka till minnet och uppdaterar sitt eget program. Den tionde planen drar nytta av kunskapen från den första. Läs mer i promptware: agenter som förbättrar sina egna instruktioner.

Vad en mjukvarufabrik inte är

  • Det är inte autokomplettering. Autokomplettering föreslår nästa rad medan du skriver; en fabrik tar emot ett ärende och levererar en färdiggranskad pull request.
  • Det är inte ett chattfönster. En chatt saknar köhantering, isolering, verifieringssteg och beständigt minne bortom konversationen.
  • Det är inte en obevakad agent som committar direkt till main. Ingenting slås samman utan mänskligt godkännande av plan och diff.
  • Det ersätter inte kodgranskning. Det strukturerar granskningen till de två punkter där den betyder mest.
  • Det är inte en molntjänst som lagrar din kod. Tendril är lokalt först: kod, planer, minne och loggar stannar på din dator.
  • Det är inte bundet till en specifik agent eller modell.

De åtta nivåerna

Steve Yegges ”8 Levels of AI-Assisted Development” (2025) är en träffsäker referens för var ett team befinner sig. De flesta team är på nivå 2 till 3: en assistent i editorn och en enskild chatt. Orkestrering med parallella agenter, minne och kontrollgrindar motsvarar nivå 8.

Nivå Vad teamet faktiskt kör i vardagen
1 Ingen AI. Utvecklare skriver och granskar all kod manuellt.
2 Autokomplettering i editorn. Förslag accepteras rad för rad.
3 En chattassistent i editorn. En konversation, en utvecklare, en funktion i taget.
4 En agent i editorn som redigerar flera filer utifrån en förfrågan.
5 En CLI-agent i terminalen som tilldelas en uppgift och kör självständigt.
6 Flera CLI-agenter i flera terminaler med manuell samordning.
7 Agenter med definierat arbetsflöde och granskningsgrindar, oftast i egenbyggda verktyg.
8 Orkestrering: parallella agenter i isolerade worktrees, beständigt minne, två kontrollgrindar och en plankö. Detta är vad Ivy Tendril erbjuder.

Kom igång

Installera Tendril på macOS eller Linux:

curl -sSf https://cdn.ivy.app/install-tendril.sh | sh

Eller på Windows:

irm https://cdn.ivy.app/install-tendril.ps1 | iex

Anslut sedan ett GitHub-arkiv, lägg till en API-nyckel för en modell och välj agent. Skapa en plan från ett litet ärende, läs utkastet, godkänn det och granska diffen när verifieringen är klar. Installationsguiden beskriver varje steg.

Vanliga frågor

Ersätter en mjukvarufabrik kodgranskning?

Nej. Den fokuserar granskningen till två definierade kontrollpunkter (plan och diff) och placerar verifieringsresultat intill diffen så att granskaren har underlag, inte bara kodändringar.

Vilka agenter stöds?

Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode och alla andra CLI-agenter. Du kan byta agent eller modell per plan.

Är Ivy Tendril gratis?

Ja. Applikationen är gratis och källkodsöppen under FSL-1.1-ALv2. Pro för 59 USD per användare och månad lägger till teamfunktioner, lokal hosting, SSO och import av CI-verifiering. Se priser.

Kom igång med Ivy

Är du redo att ta steget från traditionella UI-ramverk till moderna, agentförberedda fullstack-applikationer?

Written by

Ivy Team