VM0-kehitystyönkulku: AI-agenttien hallinta kuin tiimiä

VM0-kehitystiimissä jokainen kehittäjä työskentelee usean Claude Code -instanssin kanssa samanaikaisesti. Yleensä yli kahdeksan.

Kohtelemme Claude Codea samalla tavalla kuin oikeaa kehittäjää. (Kyllä, yrityksemme nimi on puoliksi vitsillä AI Colleagues Co!)

Tämän vuoksi VM0-kehitystyönkulun suunnittelufilosofia heijastelee klassisia ohjelmistokehityksen tiimijohtamisen käytäntöjä.

Käytämme GitHub Issueita työn seurantaan, Pull Requesteja koodin tarkasteluun ja yhdistämiseen sekä GitHub Actionsia automaatioon. Kahden kuukauden aikana tämä järjestely auttoi meitä julkaisemaan 404 versiota ja kirjoittamaan yli 230 000 riviä koodia.

Tässä kirjoituksessa selitämme, miten saimme tämän toimimaan ja miksi avainongelma ei koskaan ollut AI:n kyvykkyys, vaan ihmisten koordinointi.

AI-vetoinen kehitystyönkulku käytännössä

Kun koordinoit useita AI-agentteja rinnakkain, pullonkaula ei ole siinä, osaako malli kirjoittaa koodia. Todellinen pullonkaula on ihmisen kognitiivinen kuormitus.

Tämä työnkulku koostuu 14 slash-komennosta, jotka on järjestetty kolmeen kerrokseen: Deep Dive, Issue Management ja PR Management.

Katsotaan ensin, miltä työnkulku näyttää ja miten ominaisuus yleensä rakennetaan.

1. Vaatimusten yhtenäistäminen

   Ihminen avaa Claude-istunnon ja aloittaa /deep-research:llä. Claude kerää tietoja koodipohjasta, dokumentaatiosta ja olennaisesta kontekstista. Keskustelemme löydöksistä ja sovimme, mikä ongelma oikeasti ratkaistaan.

2. Ratkaisujen kartoittaminen

   Käyttäen /deep-innovate:ta Claude ehdottaa useita mahdollisia suuntia ja niiden kompromisseja. Keskustelemme, rajaamme vaihtoehtoja ja valitsemme suunnan.

3. Issuen luonti

   Luomme GitHub-issuen käyttäen /issue-create:aa. Ihminen tarkistaa, että vaatimukset on kirjattu selkeästi.

4. Suunnittelu ja hyväksyntä

   Käytä /issue-plan:ta, jotta Claude voi jatkaa työtä. Claude suorittaa automaattisesti koko deep-dive-työnkulun ja julkaisee tulokset issueen, mukaan lukien:

   1. löydökset /deep-research:sta
   2. vertailut /deep-innovate:sta
   3. konkreettinen toteutussuunnitelma /deep-plan:sta

5. Toteutus

   Hyväksynnän jälkeen /issue-action antaa Claudelle luvan toteuttaa suunnitelman, kirjoittaa testit, avata PR:n ja varmistaa CI:n läpäisyn.

6. Tarkastus ja yhdistäminen

   Käytämme /pr-review:ta rakenteelliseen tarkasteluun ja teemme lopullisen ihmisen tarkastuksen ennen yhdistämistä.

   Ihminen puuttuu prosessiin kolmessa tarkistuspisteessä: vaatimukset, suunta ja hyväksyntä. Kaikki muu tapahtuu itsenäisesti.

Ajattelutavan muutos: johdat AI-kehittäjätiimiä

Hetki, jolloin tajusin tarvitsevani jäsennellyn työnkulun, oli kun lisäsin lisää Claude-istuntoja ja asiat menivät vain vaikeammiksi. Mitä useampia instansseja pyöritin rinnakkain, sitä vaikeampaa oli seurata, mitä kukin teki, missä vaiheessa työ oli ja mitä oli jo päätetty.

Ilman ulkoisia työkaluja en yksinkertaisesti pystynyt hallitsemaan niin montaa Claude-instanssia kerralla. Silloin ymmärsin: kyse ei ollut AI-ongelmasta, vaan johtamisongelmasta.

GitHub on jo valmiiksi ohjelmistokehityksen yhteistyöalusta, joten uuden keksimisen sijaan aloin kohdella Claudea kuten ihmiskollegaa. Kun tein näin, johtamiskapasiteettini kasvoi heti.

Kymmenen vuoden projekti- ja tiimijohtamiskokemus sai vihdoin uuden merkityksen tässä kontekstissa. Kun Claudea kohtelee tiimin jäsenenä ja GitHubia yhteisenä viestintä- ja hallintatilana, koko järjestelmä muuttuu jälleen hallittavaksi.

Hyvä tiiminvetäjä tietää, milloin osallistua ja milloin antaa tilaa:

Tarkistuspiste	Mitä teen	Mitä AI tekee
Vaatimukset	Yhtenäistää ongelma, rajaa laajuus	Tutkii koodipohjan, kerää kontekstin
Suunta	Tarkistaa löydökset, hyväksyy lähestymistavan	Ehdottaa 2-3 lähestymistapoja, arvioi kompromissit
Hyväksyntä	Tarkistaa PR:n, varmistaa laadun	Toteuttaa, testaa, korjaa CI

Tämä heijastelee tehokkaiden ohjelmistotiimien toimintaa. En mikromanageeraa kehittäjiä, vaan asetan selkeät vaatimukset, tarkistan keskeiset päätökset ja varmistan lopputuloksen. Sama periaate pätee AI-agenttien hallinnassa.

Deep dive -työnkulku pakottaa jäsenneltyyn, harkittuun ajatteluun

Deep dive -työnkulku pakottaa harkitsemaan ennen toteutusta. Joskus Claude ajautuu umpikujaan. Silloin pakotamme Clauden pysähtymään ja miettimään, ja käymme asian yhdessä läpi. Siinä on kolme vaihetta:

Vaihe	Komento	Tarkoitus	Tuotos
Tutkimus	/deep-research	Kerää tietoja, ymmärrä konteksti	research.md
Innovointi	/deep-innovation	Kartoita useita lähestymistapoja	innovate.md
Suunnittelu	/deep-plan	Määrittele konkreettiset askeleet	plan.md

Jokaisella vaiheella on tiukat rajat.

• Tutkimus: ei ehdotuksia
• Innovointi: ei yksityiskohtia
• Suunnittelu: ei toteutusta

Nämä rajoitteet pakottavat Clauden hitaaseen, harkittuun päättelyyn sen sijaan, että hypättäisiin suoraan koodiin. Ilman niitä reunatapaukset ja arkkitehtuurikysymykset jäävät usein huomaamatta!

Käyttöesimerkki

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude researches, analyzes 12 related files, finds 3 similar patterns]

/deep-innovate what are our options for fixing this?

[Claude presents 3 approaches with trade-offs, you pick one]

/issue-create let's track this fix

Yksinkertaisissa tehtävissä voit ohittaa deep dive -vaiheet ja siirtyä suoraan /issue-create:een.

Monimutkaisissa, teknisesti epävarmoissa tehtävissä deep dive -vaiheet varmistavat, että sinä ja Claude olette samalla sivulla ennen toteutuksen alkua.

Käytä GitHubia jaettuna muistina

Useimmat AI-työkalut käsittelevät kontekstia tilapäisenä. Kun istunto päättyy, muisti katoaa.

VM0 käyttää GitHubia pysyvänä muistina:

GitHub-ominaisuus	Mitä tallentaa
Issue body	Vaatimukset ja päätökset
Issue-kommentit	Tutkimus, vaihtoehdot, suunnitelmat
PR-kommentit	Arviot ja yhteenvedot
Labelit	Työnkulun tila

Tämä ratkaisee myös ihmisen ongelman: kontekstin palautus.

Kun hallitsen 8+ Claude-instanssia, saan ilmoituksia työn valmistumisesta. Mutta en pysty Clauden keskustelusta päättelemään, mitä se teki, mitä päätöksiä tehtiin tai mikä on nykytila.

GitHub-issue ratkaisee tämän. Jokainen issue näyttää:

• Alkuperäiset vaatimukset
• Tutkimuksen löydökset (mitä havaittiin)
• Innovointivaihe (mitä vaihtoehtoja harkittiin)
• Hyväksytty suunnitelma (mitä toteutetaan)

Tämä jäsennelty muoto tekee tarkastelusta tehokasta. Voin nopeasti selata vaiheet, ymmärtää lähestymistavan ja hyväksyä tai pyytää muutoksia ilman, että muistan alkuperäistä keskustelua.

Kun työ valmistuu, minun ei tarvitse muistaa, mitä chatissa tapahtui. Voin avata issuen ja nähdä koko tarinan, jäsenneltynä ja kirjattuna.

Työn siirto agenttien välillä

Koska kaikki konteksti on GitHubissa, työ siirtyy agenttien välillä saumattomasti:

• Yksi agentti luo issuen tai PR:n
• Toinen jatkaa myöhemmin käyttäen /deep-research issue 123:ta, /issue-plan 123:ta tai /deep-research PR 124:ta

Pitkissä keskusteluissa /issue-compact kokoaa kaiken siistiksi issue-kuvaukseksi. Tämä helpottaa työn siirtoa sekä ihmisille että AI:lle.

Tiivistetään työnkulun mallit

Kaiken tämän jälkeen tiivistän muutaman käytännön vinkin.

Yksinkertaiset tehtävät

/issue-create → /issue-plan → /issue-action → /pr-check-and-merge

Käytä tätä, kun vaatimukset ovat selkeät ja työ suoraviivaista.

Monimutkaiset tehtävät

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check

Tämä estää turhan työn väärän lähestymistavan parissa.

Rinnakkainen työ

Useat agentit voivat työskennellä samanaikaisesti, kun ihminen tarkistaa valmistuneet vaiheet. Tässä työnkulku skaalautuu parhaiten.

Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements

Komentoviite

Deep dive -komennot

Komento	Tarkoitus
/deep-research	Kerää tietoa, ymmärrä koodipohja. Ei ehdotuksia sallittu.
/deep-innovate	Kartoita 2-3 lähestymistapoja, arvioi kompromissit. Ei koodia sallittu.
/deep-plan	Luo konkreettiset toteutusaskeleet. Ei toteutusta sallittu.

Issue-komennot

Komento	Tarkoitus
/issue-create	Luo issue keskustelun kontekstista
/issue-bug	Luo bugiraportti toistovaiheineen
/issue-feature	Luo vaatimuslähtöinen ominaisuuspyyntö
/issue-plan	Suorita koko deep-dive-työnkulku, julkaise tulokset issueen
/issue-action	Jatka toteutusta ihmisen hyväksynnän jälkeen
/issue-compact	Yhdistä issue-kuvaus + kommentit työn siirtoa varten

PR-komennot

Komento	Tarkoitus
/pr-check	Seuraa CI-putkea, korjaa automaattisesti, yritä uudelleen enintään 3x
/pr-review	Tarkista PR commit kerrallaan projektin standardeihin nähden
/pr-comment	Yhteenveto keskustelusta PR-kommenttiin

Aloita näin

1. Aloita yksinkertaisesti: Käytä /issue-create → /issue-plan → /issue-action ensimmäisessä tehtävässäsi
2. Lisää deep dive monimutkaisiin tehtäviin: Kun vaatimukset ovat epäselvät tai teknisesti haastavat, aloita /deep-research:lla
3. Skaalaa vähitellen: Lisää Claude-instansseja, kun totut tarkastelurytmiin
4. Luota prosessiin: Anna Clauden työskennellä itsenäisesti tarkistuspisteiden välillä

Työnkulku on suunniteltu otettavaksi käyttöön vaiheittain. Sinun ei tarvitse käyttää kaikkia 14 komentoa heti alussa. Aloita perus-issue-työnkululla ja lisää deep dive -vaiheet ja rinnakkainen työ, kun varmuus kasvaa.

Skaalaus: Mitä tehdä, kun agentteja on enemmän

Työnkulku on testattu 10+ rinnakkaisella Claude-instanssilla. Suosituksemme:

• Enintään 10 agenttia: Mukava syvään yhteistyöhön jokaisen kanssa
• Yli 10: Ei suositella

Rajoittava tekijä ei ole työnkulku, vaan ihmisen huomio ja päätösten laatu. Kun hallitset yli 10 agenttia, riskinä on muodostua pullonkaulaksi tarkistuspisteissä ja päätösten laatu heikkenee.

Klassinen "kahden pizzan tiimi" -periaate pätee myös täällä. Samat rajoitteet, jotka rajoittavat ihmistiimin kokoa, rajoittavat myös sitä, kuinka monta AI-agenttia yksi henkilö voi tehokkaasti hallita.

Tutkin parhaillaan 8×8 kaksitasoista tiimirakennetta skaalaamiseen yli 10 agentin, mutta en ole vielä kehittänyt toimivia käytäntöjä. Kerron lisää, kun tuloksia on…

VM0-kehitystyönkulku muuttaa ajatteluamme ohjelmistokehityksestä, kun AI on osa tiimiä.

Kun kohtelet AI-agentteja tiimin jäseninä työkalujen sijaan, kaikki loksahtaa paikoilleen. GitHubista tulee tiimin yhteinen muisti. Issueista tulee työtehtäviä. PR:stä tulee toimituksia. Ja sinusta tulee tiiminvetäjä, joka keskittyy arkkitehtuuriin, suuntaan ja laatuun, kun AI-tiimi hoitaa toteutuksen.

Näin toimitimme 404 julkaisua 2 kuukaudessa. Ja näin voit skaalata omaa kehitystäsi AI:n avulla.