Arkitektinn ég

Hvernig ég vinn með Claude Code

Síðast skrifaði ég um hönnun með sjálfvirka fulltrúa í huga (agent-first design) – þá hugmynd að hanna REST þjónustur þannig að bæði fólk og gervigreindarfulltrúar (agents) skilji þjónustuna. Sú grein varð til í sveitinni hjá tengdaforeldrum mínum, á milli mjalta.

Þessi grein fæddist á sama stað í lok janúar þegar kindurnar voru hólfaðar niður og hrútunum hleypt á þær til að fá fram sem arðbærustu lömbin í vor.

Hún snýst hins vegar ekki um aðferðafræðina sjálfa, heldur tækin og tólin.

Nánar tiltekið: hvernig ég vinn í raun og veru með Claude Code.

Arkitektúr umfram samræður

Flestar umræður um hugbúnaðarþróun með hjálp gervigreindar snúast um skipanir eða „prompt“.

Hugsunin er: „Skrifaðu góða skipun og þú færð góðan kóða.“

Þetta er svipað og að segja: „Gefðu góða lýsingu í verksamningi og þú færð gott hús.“

Enginn byggir hús með þeim hætti.

Vandinn er sá að stór mállíkön (LLM) eru ekki fyrirsjáanleg (deterministic). Sama aðgerðin getur skilað mismunandi niðurstöðu í hvert skipti. Ef þú byggir vinnuflæðið þitt á spjalli, í þeirri von að fulltrúinn „skilji“ hvað þú átt við, þá ertu bara að spila í Lottó.

Við sjáum hvernig verkfæri á borð við Cursor, Windsurf og Kiro, hafa nálgast þetta frá upphafi. Þau byggja á því að láta arkitektúrinn og samhengið stýra vinnunni frekar en óformlegar samræður í spjallglugga. Við getum beitt nákvæmlega sömu hugsun í Claude Code. Með því að færa okkur frá hreinum samtölum yfir í skýrt skipulag, hættum við að treysta á heppni og byrjum að hanna.

Kjarni málsins er þessi:

Ef þú sleppir öllum hrútunum lausum án eftirlits færðu vissulega afkvæmi, en þú hefur enga stjórn á útkomunni. Kröfustýrða flæðið (e. spec-driven flow) snýst um að reisa stíur utan um gervigreindina. Við setjum upp skýrar girðingar í formi krafna og reglna, ekki til að hefta skepnuna, heldur til að tryggja að krafturinn fari í réttan farveg og að afurðin, þ.e. kóðinn, verði sá sem við pöntuðum, en ekki eitthvað handahófskennt sem rekur á fjörurnar.

Stoðirnar fjórar

Verklagið sem hefur virkað vel fyrir mig byggir á kröfudrifinni þróun (spec-driven development) þar sem ég nýti m.a. SpecKit frá GitHub til að halda utan um ferlið. Til að gera þessa nálgun hnitmiðaðri á íslensku má kalla hana SKAL-aðferðina, (sbr. fulltrúinn SKAL fylgja fyrirmælum).

Hún samanstendur af fjórum meginstoðum sem mynda órjúfanlega keðju frá hugmynd að fullbúnum kóða:

• S – Sáttmáli (Constitution): Stjórnarskrá verkefnisins. Þetta eru ófrávíkjanlegar reglur um kóðunarstíl, öryggi og hönnun sem fulltrúinn verður að fylgja í hvívetna.

• K – Kröfur (Specs): Hér nota ég Spec Kit til að búa til skipulagðan samning. Við skilgreinum hvaða vanda á að leysa, hvaða endapunkta á að nota og hvernig á að bregðast við jaðartilvikum áður en fyrsta línan er skrifuð.

• A – Aðgerðaáætlun (Plan): Tæknileg útfærsla þar sem við veljum verkfæri, pakka og grunnvirki. Þetta er teikningin að lausninni.

• L – Lausnir (Tasks): Atómísk og afmörkuð verk sem eru svo skýr að fulltrúinn getur afgreitt þau án þess að þurfa að giska á hvað ég mögulega vil.

• 
  

Með því að fylgja þessu stigveldi – Sáttmáli → Kröfur → Aðgerðaáætlun → Lausnir – fær fulltrúinn ekkert svigrúm til að villast af leið. Hann fær ramma, og innan þess ramma er hann skilvirkur.

Samhæfing margra fulltrúa

Einn fulltrúi dugar sjaldnast þegar verkefnin stækka. Þar kemur Claude Flow til sögunnar. Það er verkefnastjórinn (orchestrator) sem stjórnar mörgum Claude Code fulltrúum í samhliða keyrslu.

Claude Flow geymir stöðu og samhengi í SQLite-gagnagrunni. Þannig geta fulltrúarnir deilt minni, greint mynstur og haldið samhengi á milli vinnulota. Einn rannsakar, annar kóðar og sá þriðji prófar, allt á sama tíma. Þegar verkefnið krefst þess að margar hendur vinni saman, tryggir verkefnastjórinn að þær flækist ekki hver fyrir annarri.

Viðbótatorgið

Claude Code er í dag orðið að stækkanlegu vistkerfi verkfæra. Viðbætur (plugins) eru pakkar sem binda saman færni, reglur, fulltrúa og skipanir í eina heild.

Með því að búa til eigið viðbótatorg, þ.e. safn af einingum sem fulltrúarnir geta sótt í eftir þörfum hvers verkefnis, er hver viðbót einangruð, skipulögð og endurnýtanleg.

Fyrir nokkru síðan bjó ég til auto-pr plugin sem hefur hjálpað mér að staðla útgáfuferla og halda skjölun uppfærðri í samræmi við kóðabreytingar. Hún er gott dæmi um hvernig hægt er að nýta marga sérhæfða fulltrúa til að leysa flókin verk.

Hún býr til Git commits, ýtir kóða upp og stofnar breytingabeiðnir (PR) með stöðluðum skilaboðum. Í stað þess að einn fulltrúi reyni að gera allt, skiptir hún verkinu á milli heillar „sveitar“ af fulltrúum:

• Orchestrator & Git-automator: Stýra flæðinu og samskiptum við GitHub.

• Security-scanner & Code-reviewer: Tryggja gæði og öryggi áður en nokkuð er sent inn.

• Conflict-resolver & Diff-analyzer: Leysa úr flækjum í kóðanum.

• PR-writer, Readme-updater & Changelog-generator: Uppfæra README.md og skrifa skýrar lýsingar byggðar á raunverulegum breytingum.

Með skipunum eins og analyze og pr get ég látið kerfið fara yfir breytingarnar, uppfæra titla og lýsingar samkvæmt sniðmátum verkefnisins og ganga frá öllu án handavinnu.

Hver fulltrúi notar svo ákveðið LLM sem hentar fyrir verkefnið sem um ræðir. Það er t.d. allgjör óþarfi að eyða verðmætum Claude Opus 4.6 tókenum í að skoða diff niðurstöðurnar á breytingunum.

Frá vinnumanni í arkitekt

Þegar þessir þættir smella saman, SKAL-aðferðin, og sérhæfðir fulltrúar, verður ferlið nánast fyrirsjáanlegt. Við erum ekki lengur að elta dynti gervigreindarinnar heldur að virkja hana af nákvæmni. Markmiðið er nefnilega ekki að útrýma sköpunargáfunni, heldur að hólfa hana niður, þ.e. að iðka sköpun innan girðingar.

Þegar fólk spyr mig hvernig ég vinni með gervigreind, þá sýni ég þeim ekki spjallglugga. Ég sýni þeim kerfi. Ég sýni þeim sáttmála, forskriftir og heila hljómsveit fulltrúa sem vinna í samhljómi undir skýrri stjórn.

Ég forrita minna en áður, og ég hanna meira. Ég er hættur á skóflunni neðst í skurðinum og farinn að teikna bygginguna. Þetta er stærsta breytingin sem hefur orðið á mínu starfi: Forritarinn er ekki lengur vinnumaður dagsins, hann er orðinn arkitekt síns eigin hugbúnaðar.

Og rétt eins og með hrútana í janúar, þá ræðst árangurinn í maí ekki af heppni, heldur af því hversu vel við skipuleggjum hólfin í upphafi