Problem
Markedet for kodningsagenter har skubbet en meget bekvem narrativ frem: hver ingeniør bliver hurtigere.
Det er sandt til en vis grad. Men en organisation skalerer ikke kun ved at accelerere mennesker. Den skalerer ved at koordinere kontekst, validering, test, sikkerhed, overdragelser, miljøer, hukommelse og afslutningskriterier.
Hvis hver agent forbedrer isolerede opgaver, men organisationen ikke har et fælles system, stiger aktiviteten, men det reelle throughput gør det ikke nødvendigvis.
Tese
Factory 2.0 er vigtig, fordi den flytter samtalen fra “agenter der programmerer” til “softwarefabrikker”, der observerer og forbedrer hele systemet.
Den operationelle tese er mere krævende:
- det individuelle output er ikke længere hovedenheden
- det samlede workflow bliver produktet
- ingeniører holder op med kun at skalere kode og begynder at skalere produktionstopologier
Det er ikke et UX-skift. Det er et skift i driftsmodel.
Rammeværk
En agent-native softwarefabrik har brug for fem lag:
- Delt kontekst: kode, dokumentation, tickets og konventioner.
- Specialiserede agenter: planlægning, implementering, test, review og QA.
- Systemobservation: spor, fejl, retries og outputkvalitet.
- Verifikationskriterier: hvornår tæller en ændring som afsluttet.
- Flow-læring: hvordan systemet korrigerer dårlige mønstre og bevarer de gode.
Mini-case: et team bruger agenter til at implementere features. Hvis hvert run ender i en isoleret diff, lever flaskehalsen videre i review, QA og validering. Hvis systemet forener udvikling, test, visuel evidens og operationel feedback, holder outputtet op med at være en sum af patches og begynder at ligne en produktionslinje.
Målbar indikator: andel af ændringer, der gennemfører plan, implementering, test og evidens uden at genskabe kontekst mellem faser.
Hvorfor det er vigtigt nu
Factory annoncerede Factory 2.0 den 15. juni 2026 og opsummerede det med en vigtig sætning: at forbedre individuel produktivitet er ikke længere nok; der kræves et sammenhængende, agent-native og end-to-end system, der forbedrer sig selv ved at observere sig selv.
Deres egen dokumentation og produkt insisterer på ideen om en komplet cyklus: end-to-end udvikling, automatiseret QA med visuel evidens og Droid Computers som vedvarende maskiner til at orkestrere agenter. Det understøtter en bredere læsning end “den bedste coding copilot”.
Konsekvensen er operationel: den senioringeniørs arbejde flytter sig mod styring af fabrikken. Mindre punktlig heltemod. Mere design af kontekst, verifikation, perimeter og stopkriterier.
Anti-eksempel
“Vi sætter flere kodningsagenter ind og ser, hvordan de passer sammen.”
Denne vej producerer normalt flere artefakter, ikke mere system. Uden en fælles topologi accelererer hver agent en del og externaliserer omkostningen til en anden.
Protokol (3 trin)
- Kortlæg den reelle SDLC. Ikke den ideelle. Hvor sidder arbejdet fast i dag mellem idé og merge.
- Instrumentér kæden, ikke kun agenten. Forbedring skal måles i det fulde flow.
- Tildel owners pr. fase. En fabrik uden ownership bliver automatiseret støj.
| Lag | Spørgsmål | Risiko hvis det mangler |
|---|---|---|
| kontekst | hvad ved systemet | kortsynet arbejde |
| specialisering | hvem gør hvilken del | dyr generalist-agent |
| observation | hvordan lærer flowet | gentagelse af fejl |
| verifikation | hvad beviser afslutning | output uden tillid |
| ownership | hvem korrigerer systemet | distribueret gæld |
Relateret
- Claude Dynamic Workflows: når agenten begynder at designe sin egen operation
- ACI: det lag der manglede mellem agenter og mennesker
- AI Traces: det lag der gør agenter til auditerbare systemer
Konsulterede kilder
Næste skridt
Spørg ikke først, hvilken agent der skriver den bedste kode. Spørg, hvilken del af din softwarefabrik stadig afhænger af manuelle overdragelser, rework og kontekst, der går tabt i hvert spring.
Oversat fra den spanske original med AI-hjælp og gennemset for nøjagtighed. Læs originalen på spansk.