Annamme koodausagenteille oikeita tikettejä joka päivä, ja ne toimittavat lähes aina jotain, mikä toimii. Se ei koskaan ollut huolenaihe. Huolenaihe on miten ne työskentelevät: uusi apufunktio kolmen jo saman työn tekevän vieressä, tuore abstraktio yhdelle kutsujalle, korjaus joka paikkaa vain sen polun, jonka tiketti nimesi, ja jättää neljä sisarusta rikki, havainto joka on “luultavasti bugi” ilman todisteita puolesta tai vastaan. Jokainen muutos on paikallisesti järkevä. Kokonaisuutena ne ovat entropiaa.
TL;DR: Viidessä Tier-3-pull requestissa agenttien orkestrointimme ytimessä kolme yhdistettävää taitoa —
ponytail(vähennä),grain(kohdista) jareview-proof(todista) — poistivat 821 riviä samalla kun viisi ominaisuutta toimitettiin, nappasivat kiinni hiljaisesta sopimusrikosta, jonka pelkkä uskottavuus olisi mergetty läpi, ja pitivät jokaisen muutoksen olemassa olevan arkkitehtuurin syiden mukaisena. Tässä on, mitä kukin niistä tekee, oikeilla diffeillä todistettuna.
Ota suojakaiteet pois, ja koodausagentti on erittäin nopea uskottavan näköisten vastuiden tuottaja. Siksi nojaamme kolmeen pieneen taitoon, jotka työntävät toiseen suuntaan — yksi vaisto kussakin: vähennä, kohdista, todista.
ponytail— kirjoita laiskin asia, joka todella toimii. Poista ennen kuin lisäät. (Tätä emme kirjoittaneet itse — se on Dietrich Gebertin avoimen lähdekoodin taito , jonka sovitimme omaan stackiimme.)grain/grain-review— laita se sinne, minne koodikanta on jo päättänyt sen kuuluvan. Älä keksi toista tapaa.review-proof— älä usko havaintoa ennen kuin se toistuu epäonnistuvana testinä.
grain ja review-proof rakensimme samassa hengessä kuin ponytailin, omaan arkkitehtuuriimme viritettyinä. Jokainen alla olevasta viidestä PR:stä koskettaa agenttien orkestrointimme ydintä — kalleinta paikkaa repossa hutiloida — ja jokainen on luokiteltu Tier 3:ksi: ylimääräistä testikattavuutta ja ihmiskatselmointi automaattisen katselmoijan päälle, poikkeuksetta.
Kolme taitoa yhdellä silmäyksellä: ponytail vähentää, grain kohdistaa, review-proof todistaa.
Osa 1 · MITÄ — entropia on oletus
Tässä on se, mistä kukaan ei varoita, kun annat repon tekoälyagenteille: jokainen agentti optimoi paikallisesti eikä muista mitään. Se näkee tiketin, ei niitä kuukausia käytäntöjä, joihin tiimisi on konvergoitunut. Sillä ei ole mitään syytä suosia olemassa olevaa sähköpostipalveluanne tuoreen sijaan, ei muistikuvaa siitä, että uudelleenohjauksen tilajoukko on jo määritelty kolme tiedostoa sivummalla, ei vaistoa siitä, että “korjaus menee jaettuun funktioon, ei tähän yhteen kutsujaan”. Vapaana N agenttia tuottaa N hieman erilaista tapaa tehdä sama asia. Se ei ole koodinlaatuongelma, jonka voi lintata pois — se on rakenteellista ajautumista, joka kumuloituu.
Kolme taitoa kohdistuvat kukin yhteen tämän ajautumisen akseliin.
ponytail — laiskin asia, joka toimii
Ponytail on seniorikehittäjä, joka on herätetty kello 3 yöllä jonkun toisen nokkelan abstraktion takia ja kieltäytyy kirjoittamasta seuraavaa. Se kulkee tikkaiden läpi ja pysähtyy ensimmäiselle puulla, joka kestää: täytyykö tämän ylipäätään olla olemassa (YAGNI) → onko se jo tässä koodikannassa → tekeekö sen standardikirjasto → natiivi alustan ominaisuus → jo asennettu riippuvuus → voiko se olla yksi rivi → vasta sitten, minimikoodi joka toimii.
Agenteille tärkein puola on “onko se jo tässä koodikannassa?” Sen uudelleenimplementointi, mikä on muutaman tiedoston päässä, on yleisin agenttien tuottaman hutiloinnin muoto. Ja ponytailin bugikorjaussääntö pitää diffit rehellisinä: korjaa juurisyy, ei oiretta. Greppaa jokainen sen funktion kutsuja, jota aiot koskettaa; yksi vartija jaetussa funktiossa on pienempi diffi kuin vartija jokaisessa kutsujassa — eikä se jätä sisaruksia rikki.
grain / grain-review — mene syiden mukaisesti
Jos ponytail säätelee kuinka vähän kirjoitat, grain säätelee minne se menee ja minkä muodon se saa. Sen yksi sääntö: etsi lähin olemassa oleva esimerkki, kopioi sen muoto, nimeä mitä kopioit. Uuden koodin pitäisi lukeutua kuin myös sen tiedoston kirjoittaja, joka on vieressä, olisi kirjoittanut tämän.
Grain on myös paikka, jossa arkkitehtuuria valvotaan. Backendimme on melko tavanomainen vertical slice + heksagonaalinen rakenne — esityskerros kutsuu sovellusta, sovellus kutsuu domainia, infrastruktuuri riippuu sisäänpäin, eikä domain koskaan kurkota takaisin ulos. Havainto kuten “tämä reitti ohittaa kontrollerinsa ja vetää palvelun suoraan” ei ole saivartelua — se on ero sen välillä, navigoiko agentti koodikannassa ensi kuussa vai ei. grain-review metsästää juuri näitä: kopioidut apufunktiot, ylitetyt kerrosrajat, toisen ominaisuuden sisäisiin osiin kurkottaminen, toinen käytäntö jollekin, mikä on jo tehty yhdellä tavalla.
review-proof — ansaitse havaintosi
Tavallinen tekoälykoodikatselmointi tuottaa uskottavia havaintoja. Osa on todellisia; osa on itsevarmaa hölynpölyä; ulkopuolelta ne näyttävät identtisiltä. review-proof kieltäytyy luottamasta itseensä: se katselmoi ja sitten pakottaa jokaisen oikeellisuushavainnon toistumaan oikeana epäonnistuvana testinä tai ajettavana reproduktiona ja pudottaa kaiken, mikä ei siihen taivu. Se päättää grain-review-vaiheeseen rakenteellisen istuvuuden vuoksi. Tuloksena on katselmointi, jossa jokainen kohta tulee ajettavan todisteen kanssa — ei fiiliksen.
Mitä meidän pitäisi nähdä, jos tämä toimii
- H1 — Poistaminen näkyy ominaisuus-PR:issä. Jos ponytail + grain toimivat, ominaisuuden lisäämisen pitäisi usein poistaa nettorakennetta, ei vain lisätä sitä.
- H2 — Korjaukset laskeutuvat kerran, jaettuun paikkaan. Juurisyyn korjaukset tiivistävät monet kutsukohdat yhdeksi vartijaksi sen sijaan, että niitä ripoteltaisiin kutsujakohtaisesti.
- H3 — Katselmointi nappaa sopimusrikkoja, joiden ohi ihminen silmäilee. Todisteisiin nojaava katselmointi nostaa esiin bugeja, jotka “näyttää ihan hyvältä” -katselmointi ohittaa — erityisesti hiljaiset.
Osa 2 · ENTÄ SITTEN — viisi PR:ää, yksi vaisto kussakin
Viisi oikeaa muutosta agenttiytimeemme. Pidämme sisäiset yksityiskohdat tarkoituksella epämääräisinä — repo on yksityinen — mutta luvut on laskettu todellisista diffeistä ja opetukset ovat se siirrettävä osa.
Vähennä: yksi vartija tusinalle noutokohtaa
Yksi työnkulkujen vaiheryhmä nouti käyttäjän antamia URL-osoitteita ilman DNS-resoluution turvatarkistusta, joten isäntänimi, joka resolvoitui sisäiseen osoitteeseen, saattoi päästä käsiksi pilven metadataan backendistä käsin. Houkutteleva korjaus lisää tarkistuksen jokaiseen kymmeneen ja enempään noutokohtaan. Ponytailin vastaus oli päinvastainen: yksi jaettu, vartioitu noutoapuri, käytössä kaikkialla — ja poistimme käsin rakennetun yksityisverkkojen taulukon, jonka jokerimerkki-DNS-temppu käveli suoraan ohi, sekä kolme kopioitua uudelleenohjaussilmukkaa ja verkkotarkistuksen, joka oli kopioitu useaan tiedostoon.
Diffi lisäsi jaetun apurin ja poisti ~90 riviä päällekkäisyyttä 22 tiedostosta. Juuri tuo poistaminen on tarina: tämä on H2 lihassa — juurisyyn korjaus ohjasi jokaisen kutsujan yhden vartijan läpi sen sijaan, että olisi paikattu se yksi polku, jonka tiketti nimesi.
Juurisyyn korjaus: tusina ad hoc -noutokohtaa tiivistyy yhdeksi jaetuksi, vartioiduksi apuriksi. Laiska korjaus ja turvallinen korjaus ovat sama korjaus.
Vähennä + todista: yksi muotovartija, todistettuna oikealla ajonaikaisella ympäristöllä
Työntekijämme ajonaikainen ympäristö tallentaa ajon tuloksen sarjallistettuna merkkijonona, joskus yksialkioisen listan sisään käärittynä. Kuluttajat, jotka odottivat pelkkää oliota, kaatuivat siihen. Väärä korjaus ripottelee puolustavia tyyppitarkistuksia jokaiseen kuluttajaan. Sen sijaan: yksi pieni muotoa normalisoiva apuri, ja jokainen kuluttaja ohjattiin uudelleen sen kautta — lähes puhdas yhden vartijan lisäys, joka korvaa ne N ad hoc -vartijaa, jotka vähemmän kurinalainen agentti olisi kirjoittanut (+558 / −24, 7 tiedostoa).
Se osa, joka tekee tästä review-proof-tarinan, on testi. Sen sijaan, että olisimme väittäneet oletettua sarjallistamismuotoa vastaan, ajoimme oikean työnkulun todellisen ajonaikaisen ympäristön ja tallennuksen läpi — ei mockeja — ja todistimme sen muodon, jonka ajonaikainen ympäristö todella tallentaa. Tiketin avoin kysymys oli kirjaimellisesti mitä ajonaikainen ympäristö sarjallistaa tässä? — ja ainoa rehellinen vastaus on sellainen, jonka voi ajaa.
Todista: katselmointi nappasi hiljaisen sopimusrikon
Ominaisuus: solmukohtainen varamalli, jotta yhden palveluntarjoajan varaan kiinnitetty työnkulku heikkenee hallitusti katkoksen aikana. Ilmeisin ensimmäinen versio kääri mallin kehyksen sisäänrakennettuun varayhdistelijään.
Se toimi onnellisella polulla. Se myös kytki hiljaisesti pois kaksi palveluntarjoajan ominaisuutta, jotka portittuvat konkreettiseen mallityyppiin isinstance-kutsulla — kääritty olio ei ole enää sitä tyyppiä, joten natiivi jäsennelty tuloste ja kehotteen välimuistiin tallennus molemmat sammuivat hiljaa. Ei virhettä. Ei epäonnistuvaa onnellisen polun testiä. Juuri sellainen asia, jonka ihmiskatselmointi silmäilee ohi ja “näyttää ihan hyvältä” -agentti hyväksyy.
review-proof ei hyväksynyt sitä — se reproduktoi molemmat rikot epäonnistuvina testeinä, mikä pakotti uudelleensuunnitteluun: sovella varatoimintoa alempana, suoritusaikana, jotta jokainen malli pysyy konkreettisena tyyppinään ja tyyppiportitetut ominaisuudet toimivat edelleen. H3, vahvistettuna ratkaisevasti: todiste nappasi bugin, jonka uskottavuus olisi toimittanut tuotantoon.
Kohdista: yksi valitsin, ei kahta kopiota
Toisen ilmoituskanavan lisääminen tarkoitti, että kanavavalitsimen käyttöliittymällä oli nyt kaksi kotia — luontivelho ja asetusten modaali. Oletusagentin liike lisää uuden haaran molempiin, kasvattaen kaksi kopiota samasta tilakoneesta. grain sanoi: on jo olemassa yksi tapa, jolla tämän pitäisi olla muotoiltu — tee siitä jaettu. Erotimme yhden valitsinkoukun ja ajoimme molemmat näkymät sen kautta, sovitimme uuden kanavan olemassa olevaan konfiguraatioliittoon ja käytimme uudelleen olemassa olevaa sähköpostipalvelua uuden lähetyskoneiston lisäämisen sijaan.
+1 735 / −340, 24 tiedostoa. Tämän kokoinen ominaisuus, joka poistaa 340 riviä, on H1 näkyvänä: kahden valitsinkopion deduplikointi yhdeksi maksoi ison osan uudesta kanavasta.
Kohdista + todista: käytä uudelleen päätepistettä, peilaa polku
Tiedostojen liittäminen ongelman luonnissa olisi voinut tarkoittaa uutta latauspäätepistettä, uutta lähetysmekanismia, uutta kehotepolkua. grain ohjasi lähes kaiken olemassa oleville raiteille: olemassa olevan latauspäätepisteen, frontendin hyväksymislistan, joka peilaa backendin sallittujen listaa täsmälleen, ja lykätyn lähetyksen korjauksen, joka käytti uudelleen kelpoisuusmekanismia, jota ajastettu työ jo käytti. Se toimitettiin todisteisiin nojaavin korjauksin, mukaan lukien oikea transaktioeristyksen bugi, joka olisi kadottanut dataa rinnakkaisissa latauksissa. +1 776 / −218, 27 tiedostoa — iso ominaisuus, joka silti löysi 218 poistettavaa riviä liittymällä olemassa oleviin siivuihin uusien keksimisen sijaan.
Tulostaulu
Viisi Tier-3-PR:ää: mitä kukin lisäsi, mitä poisti ja mikä vaisto oli sen takana.
Viisi ominaisuus- ja korjaus-PR:ää agenttiytimessä poistivat 821 riviä — ei tekemällä vähemmän, vaan kieltäytymällä kopioimasta sitä, mikä oli jo olemassa, ja pitämällä oirepaikkaukset poissa, kun juurisyyn korjaus teki ne tarpeettomiksi.
Täysi avoimuus
- Nämä ovat taitoja, ei tutkimus. Tämä ei ole kontrolloitu koe vertailuhaaralla; nämä ovat viisi oikeaa PR:ää, joissa kurinalaisuutta sovellettiin. Vastafaktuaali — mitä sama agentti olisi toimittanut ilman näitä taitoja — on perusteltu arvio, ei mittaus. Hiljaisen sopimusrikon tarina on puhtain todiste, koska näimme katselmoinnin reproduktoivan bugin ennen uudelleensuunnittelua.
- Rivimäärät ovat sijaislukuja. −821 on todellinen luku diffeistä, mutta “poistetut rivit” edustaa “vältettyä päällekkäisyyttä ja kuollutta joustavuutta”. Taito, joka puhuu agentin pois kirjoittamasta 200 spekulatiivista riviä, ei jätä minkäänlaista jälkeä diffiin — suurimmat voitot ovat täällä näkymättömiä.
- Token-säästöt ovat suunnallisia. Pienemmät diffit, harvemmat kosketetut tiedostot ja uudelleenkäytetyt rakenteet tarkoittavat vähemmän tokeneita, jotka kuluvat tuottamiseen, katselmointiin ja uudelleenkatselmointiin — mutta emme esitä kovaa PR-kohtaista token-deltaa.
ponytailei ole meidän. Se on Dietrich Gebertin avoimen lähdekoodin taito ; sovitimme sen.grainjareview-proofovat meidän, rakennettu samassa hengessä. Kaikki kolme toimivat paikallisina projektitaitoina Claude Codessa — kehote ja menettelytapa, ei binääri, jonka asennat.
Valmis kasvattamaan liiketoimintaasi?
Aloita ilmainen kokeilujakso tänään ja näe tulokset muutamassa päivässä.
Osa 3 · MITÄ SEURAAVAKSI
Mitä toimitettiin. Kolme yhdistettävää taitoa. ponytail ja grain ajetaan kirjoittamisen aikana; ponytail-review, grain-review ja review-proof ajetaan diffille. review-proof ketjuttaa grain-review-vaiheen viimeisenä vaiheenaan, joten yksi todistettu katselmointi saa myös rakenteellisen tarkistuksen kaupan päälle.
Mitä voit tehdä maanantaina — et tarvitse juuri meidän taitojamme:
- Tee “käytä uudelleen” -puolasta toinen, ei kymmenes. Ennen kuin agentti kirjoittaa apurin, pane se greppaamaan olemassa oleva. “Onko se jo tässä koodikannassa?” kuuluu ylemmäs kuin “osaanko kirjoittaa sen siististi?”
- Korjaa juuresta, todista kutsujalistalla. Vaatikaan, että jokainen bugikorjaus nimeää jokaisen kosketetun funktion kutsujan. Yksi vartija jaetussa funktiossa voittaa vartijan kutsujaa kohti — ja se on pienempi diffi.
- Anna uudelle koodille lähisisarus kopioitavaksi. “Etsi lähin olemassa oleva esimerkki ja peilaa sen muoto” muuttaa arkkitehtuurin dokumentista, jota kukaan ei lue, oletukseksi, jota agentti noudattaa.
- Valvo kerrosrajoja CI:ssä, älä fiiliksellä. Ratchet, joka kaatuu vain uusiin kerrosten välisiin importteihin, antaa sinun pitää linjaa kiehuttamatta olemassa olevan velan valtamerta.
- Älä toimita havaintoa, jota et pysty reproduktoimaan. Pane agentti kirjoittamaan epäonnistuva testi ensin. Jos se ei saa bugia toistumaan, se ei ole bugi — se on mielipide. Pudota se.
- Anna katselmoinnin poistaa. Kohdista katselmointikierros nimenomaan yli-insinööröintiin — “mitä voimme karsia” — erillään oikeellisuudesta. Diffin paras lopputulos on, että siitä tulee lyhyempi.
Kokeile, varsinkin jos se epäonnistuu sinulla. Jos ajat koodausagentteja oikealla koodikannalla, entropia tapahtuu jo — et vain ole mitannut sitä. Muunna yksi näistä katselmointikierrokseksi seuraaville kymmenelle agentti-PR:lle ja laske poistot. Jos vähennä-kohdista-todista ei kutista diffejäsi tai nappaa hiljaista rikkoa, kuulemme siitä mielellämme. Korjaukset ja vastaesimerkit ovat erityisen tervetulleita.
Agentti lisää. Tehtävä on saada agentti ansaitsemaan jokainen rivi.
