La agentene jobbe i skift: Hvordan Elyra Swarm gjør én prompt til en hel pipeline
Problemet er ikke at agenten er dårlig til å kode. Problemet er at du ber én agent være arkitekt, utvikler, tester og reviewer på samme tid. Mennesker fungerer ikke sånn. En utvikler som skriver kode og gjennomgår sin egen kode i samme åndedrag, fanger færre feil enn et par friske øyne ville gjort. Det samme gjelder LLM-er.
Elyra Swarm deler arbeidet inn i etapper. I stedet for at én agent gjør alt, kjører en pipeline av fokuserte agenter etter hverandre — hver med et tydelig mandat, spesifikke instruksjoner og klare begrensninger på hva de kan og ikke kan gjøre.
Installasjon
elyra install npm:@elyracode/swarm
Bygg-pipelinen
Den vanligste pipelinen. Du beskriver hva du vil ha, og fem agenter bytter på å gjøre jobben:
/swarm build legg til brukerregistrering med e-postbekreftelse
Slik ser det ut:
Steg 1 — Planlegger (kun lesetilgang). Leser kodebasen, kartlegger arkitekturen og lager en konkret plan. Filstier, funksjonssignaturer, migreringssteg, teststrategi. Planleggeren får ikke redigere filer — den kan bare lese og tenke. Den begrensningen tvinger den til å lage en plan som er tydelig nok til at noen andre kan følge den.
Steg 2 — Koder. Tar planen og implementerer den. Redigerer filer, lager nye, skriver selve koden. Følger planen steg for steg. Skriver ikke tester — det er neste agents jobb.
Steg 3 — Tester. Leser det koderen bygde, og skriver tester. Følger eksisterende testmønstre i prosjektet. Dekker happy paths, edge cases og feilscenarier. Kjører testene hvis mulig.
Steg 4 — Reviewer (kun lesetilgang). Gjennomgår alt koderen og testeren har produsert. Sjekker korrekthet, sikkerhet, edge cases og testkvalitet. Kategoriserer funn som kritiske, advarsler eller forslag. Får ikke «bare fikse det» — må formulere problemet tydelig.
Steg 5 — Fikser. Tar revieweren sine funn og adresserer dem. Fikser kritiske problemer først, bruker advarsel-fiksene når det åpenbart er fornuftig, hopper over rene stilnitter. Kjører tester etterpå.
Resultatet: en funksjon bygd med arbeidsdeling, testet av noen som ikke skrev koden, gjennomgått av noen som ikke implementerte eller testet, og fikset basert på konkret tilbakemelding.
Review-pipelinen
For når du vil ha en grundig gjennomgang av eksisterende kode:
/swarm review betalingsmodulen
Fem etapper, alle kun lesetilgang bortsett fra den siste oppsummeringen:
Analyser — Kartlegger kodestruktur, dataflyt og entry points
Korrekthet — Logikkfeil, null-håndtering, off-by-one, feilhåndtering. Ingenting annet.
Sikkerhet — SQL-injection, XSS, auth-bypasser, datalekkasjer. Ingenting annet.
Tester — Dekningshull, kvalitet på assertions, manglende edge cases. Ingenting annet.
Syntetiser — Slår sammen alle tre rapportene til en prioritert, handlingsbar liste.
Poenget: hver reviewer ser bare etter én type problem. En korrekthets-reviewer som ignorerer sikkerhet, blir ikke distrahert av en XSS-sårbarhet når den egentlig skal sjekke null-håndtering. En sikkerhets-reviewer som ignorerer testkvalitet, foreslår ikke «legg til en test her» når den egentlig skal flagge en auth-bypass.
Dette fanger konsekvent flere problemer enn en enkelt «review denne koden»-prompt, fordi fokus slår bredde.
Refaktor-pipelinen
For å restrukturere kode uten å endre oppførsel:
/swarm refactor varslingssystemet
Fire etapper:
Analyser (kun lesetilgang) — Forstår nåværende struktur, identifiserer smertepunkter og kobling
Planlegg (kun lesetilgang) — Lager en refaktoreringsplan som eksplisitt bevarer oppførselen
Implementer — Utfører planen, oppdaterer tester for strukturelle endringer
Verifiser (kun lesetilgang) — Bekrefter at oppførselen er bevart, ingen regresjoner, ingen død kode igjen
Lesetilgang-etappene er kritiske her. En refaktoreringsplan som kommer fra en agent som ikke kan begynne å redigere på impuls, blir rett og slett mer forsiktig og fullstendig.
Hvorfor etappene betyr noe
Begrensningen er funksjonen. En agent som ikke kan redigere filer, produserer bedre analyse. En agent som kun ser etter sikkerhetsfeil, fanger flere sårbarheter. En agent som implementerer fra en ferdigskrevet plan, gjør færre arkitekturbommerter.
Dette speiler noe ethvert erfarent utviklingsteam vet: den som designer systemet, bør ikke være den eneste som gjennomgår det. Den som skriver koden, skriver bedre kode når hen vet at en reviewer kommer etterpå. Og revieweren gir bedre tilbakemelding når hen ikke bare kan fikse det selv.
Hver etappe i Swarm får:
En spesifikk rolle og et navn (PLANLEGGER, KODER, TESTER, REVIEWER, FIKSER)
Fokuserte instruksjoner for nøyaktig hva som skal gjøres
En lesetilgang-begrensning (der det passer) som hindrer snarveier
Output fra alle tidligere etapper som kontekst
Ingen etappe ser den opprinnelige prompten isolert. Koderen ser planleggerens output. Revieweren ser både planen og implementeringen. Fikseren ser review-funnene i sin sammenheng.
Praktiske tips
Vær spesifikk i oppgavebeskrivelsen. «Bygg brukerregistrering» er greit. «Bygg brukerregistrering med e-postbekreftelse, rate limiting og magic link-mulighet» er bedre. Planleggeren bruker beskrivelsen din til å avgrense arbeidet.
Bruk review på de mest kritiske modulene dine. Kjør /swarm review på autentisering, betalingshåndtering, eller hva som helst der bugs får uforholdsmessige konsekvenser. Multi-pass review-en er tregere enn én enkelt review-prompt, men den fanger ting du ellers ville oversett.
Bruk refactor når du er redd for å røre noe. Analyser–planlegg–implementer–verifiser-syklusen er designet nettopp for kode som er skummel å endre. Verifiseringsetappen sjekker spesifikt at oppførselen er bevart.
Du kan fortsatt gripe inn. Swarm kjører innenfor din vanlige Elyra-økt. Hvis en etappe produserer noe galt, kan du korrigere før neste etappe plukker det opp. Pipelinen er ingen svart boks — det er en strukturert samtale.
Kom i gang
elyra install npm:@elyracode/swarm
Prøv på noe lite først:
/swarm build legg til et health check-endepunkt som returnerer app-versjon og oppetid
Se etappene flyte forbi. Legg merke til hvordan planleggerens output former koderens arbeid, hvordan testeren fanger edge cases koderen overså, og hvordan revieweren finner problemer som ellers ville gått rett i produksjon.
Prøv deretter /swarm review på en modul du ikke har sett på på en stund. Multi-pass-analysen pleier å finne noe — og det er som regel ikke det du forventet.
All dokumentasjon ligger på elyracode.com — der finner du oppskrifter, eksempler og oversikt over de andre pluginene i økosystemet.
