Ongelma, jota emme osanneet odottaa

Olet varmaan nähnyt tämän: kaksi pull requestia menee läpi testeistä erikseen. Kumpikin muutos näyttää järkevältä ja siistiltä. Koodiarvostajat hyväksyvät. Yhdistät ne main-haaraan, ja sovellus kaatuu tavalla, jota yksikään muutos ei selitä.

Nyt kuvittele sama juttu toistuvan jatkuvasti. Ei siksi, että tiimi koordinoi huonosti, vaan koska yhden devaajan AI-koodaaja synnyttää kymmeniä päällekkäisiä brancheja sillä aikaa, kun ihminen kirjoittaa yhden funktion.

Tämä on agenttiohjaisen kehityksen uusi arki. Se paljastaa aukkoja workflow'ssa, joka on toiminut kymmenen vuotta.

Paikallinen ok ei takaa kokonaisuutta

Tässä piilee salakavala juttu: koodi voi olla paikallisesti täydellinen mutta globaalisti ristiriitainen.

Oletetaan, että agentti luo kolme branchia web-renderöinnin parantamiseksi:

• Branch A siirtää viestien layoutin uuteen mittauskehykseen. Nopeampi, siistimpi, testit vihreät.
• Branch B laajentaa markdown-renderöintiä vanhalla mittauksella. Toimii eristyksissä moitteetta.
• Branch C lisää testejä skrollaukselle. Kaikki ok.

Jokainen branch on itsessään kunnossa. Diff näyttää fiksulta. Koodireview ei nosta punaisia lippuja, koska mikään yksittäinen muutos ei ole pielessä.

Kun ne pinotaan mainiin? Mittaussuunnat menevät ristiin. Järjestelmä on ristiriidassa itsensä kanssa. Ongelma näkyy vasta, kun yhdistät muutokset kohdehaaraan.

Tämä ei ole koodin laadun ongelma. Tämä on integraatio-ongelma.

CI/CD ei pärjää agenttien vauhdille

Perinteiset CI/CD-putket – merge queuet mukaan lukien – on suunniteltu ihmisrytmille: useita devaajia, jaettuja brancheja, keskitettyjä testejä ja review'tä, kun duuni on "riittävän hyvä".

Siellä on luonnollinen hidastus. Ihminen kirjoittaa featuren, puskee PR:n, odottaa arvostelua ja jatkaa. Integraatiopaine (monet ihmiset, yksi haara) osuu tiimirajalla, CI nappaa sen.

Agentit eivät noudata tätä.

Yksi devaaja agentin kanssa pyörittää viittä, kymmentä tai kahtakymmentä paikallista worktreeä rinnakkain. Jotkut pinottuina, jotkut umpikujia, jotkut vanhentuneilla oletuksilla. Ne syntyvät halvalla, häviävät helposti ja tulevat nopeammin kuin review-prosessi ehtii perässä.

Integraatiopaine iskee paikallisesti, ennen kuin mitään päätyy remotelle.

Kun GitHubin CI näkee brancet, olet jo kuluttanut tuntikausia reviewiin, rebasetukseen ja ristiriitojen setvimiseen. Merge queue ei auta – homma on jo pilalla.

Rebasing on laastari, ei strategia

Helppo ratkaisu: "Eikö agentti voi vaan rebasettaa konflikteja?"

Kyllä, ja se auttaa. Mutta vain osittain.

Rebasing tasaa tekstiä. Git osaa siirtää rivin 42 riville 49. Mitä Git ei osaa, on sanoa, onko muutoshistoria arkkitehtuurisesti järkevä.

Aikeiden konflikti ei ole sama kuin tekstikonflikti.

Yksi branch refaktoroi authin kohti OAuth2:ta. Toinen laajentaa vanhaa session-authia pienen featuren takia. Ei merge-konflikteja. Testit vihreät. Yhdessä ne jättävät koodin kahden auth-mallin väliin.

Rebasing menee läpi. Testit ok. Koodi menee tuotantoon rikki.

Tarvitset prosessin, ei vain työkaluja

Tärkeä ero:

Rebaseava agentti on työkalu. Prosessi, joka ohjaa rinnakkaisia agentti-muutoksia, on workflow.

Merge queue ei ole pelkkää odottelua. Se on:

• Järjestystä: mikä muutos integroituu ensin
• Tarkistusta: kombinoitu tulos kohdehaaraan
• Validointia: arkkitehtuuri ok, ei vain teksti

Agenttikehityksessä tarvitset jotain aikaisempaa. Paikallinen integraatiojono, joka:

1. Seuraa lennossa olevia agentti-brancheja
2. Tunnistaa päällekkäisyyksiä ja riippuvuuksia
3. Ehdottaa turvallista järjestystä
4. Ajaa kombinaatiotestit ennen puskausta
5. Napaa arkkitehtuuriristiriidat, joita yksittäiset testit missaa

Nopeatempoisen kehityksen piilokulut

Harva puhuu tästä: valvonta skaalautuu eri tavalla nopeuden kanssa.

Ihmisvauhdissa yksi reviwer pärjää. Review itsessään hillitsee virtaa.

Kun agentit tuottavat koodia nopeammin kuin ihmiset ehtivät tarkistaa, valvonta tukkeutuu – mutta ei siksi, että reviwerit olisivat hitaita. Tarvitset fiksumpaa integraatio-ohjausta. Napaa konfliktit ennen kuin ne menevät ihmisreviewiin.

Tässä NameOceanin Vibe Hosting kokeilee uutta. Hosting-infra sulautuu kehitykseen – pilvi ymmärtää deployment-tahtia ja antaa palautetta aikaisin. Kuvittele, jos hosting nappaa arkkitehtuuriongelmat paikallisessa agenttityössä, ennen GitHub-puskuja. Tällainen cross-stack-ajattelu on agenttien vaatimaa.

Mitä tämä tarkoittaa sinun workflow'llesi

Jos käytät AI-agentteja tosissasi (tai aiot), tarkista integraatiosi:

1. Pärjäätkö yhden devaajan päällekkäisillä muutoksilla? Jos merge queue olettaa ihmisvauhtia ja peräkkäisyyttä, olet haavoittuvainen.

2. Tarkistatko ennen vai jälkeen mergen? Agentti-brancet tarvitsevat jonotarkistuksen, ei jälkikäteen.

3. Tarkistatko arkkitehtuuria vai vain tekstiä? Testit ja linttaus eivät riitä. Validointi kombinaatioille designin mukaan.

4. Onko review pullonkaula? Jos ihmiset ruuhkautuvat, et ole ratkaissut agentti-ohjausta – olet luonut tukoksen.

Hyvä uutinen: tämä on korjattavissa. Ei tarvitse hidastaa agenteja. Tee integraatiosta fiksumpaa.

Huono uutinen: nykytyökalut eivät ole optimoituja. Mutta juuri siksi tämä on hauska haaste. Kun agenttikehitys vakiintuu, tiimit, jotka osaavat paikallisen integraation, saavat vauhtiedun 2010-lukujen merge queue -ajatteluun verrattuna.

Tulevaisuus ei ole nopeammista devaajista tai agenteista. Se on workflow'sta, joka ohjaa agenttien luomaa nopeutta.