Így támogatja az AI a fejlesztési munkafolyamatunkat

Az AI akkor hasznos, ha egy jól megtervezett fejlesztési rendszerben működik. Átvehet megvalósítási, elemzési, dokumentációs és rutinszerű tesztelési feladatokat, de nem ő felel az architektúráért, a termékkompromisszumokért vagy a kiadási döntésekért.

A munkafolyamatunk elegendő kontextust és mozgásteret ad az ügynököknek ahhoz, hogy érdemi munkát végezzenek, miközben minden fontos döntés ellenőrizhető marad. A cél nem az, hogy több kód szülessen. Hanem az, hogy rövidebb legyen az út egy világosan megfogalmazott igénytől a karbantartható szoftverig, amelyért egy mérnök kész felelősséget vállalni.

A backlogtól az éles rendszerig

1. A munka strukturált backlogból indul. Minden kezdésre kész feladat leírja az elvárt viselkedést, a szükséges kontextust, a korlátokat és azt, mit jelent a kész állapot. Az ütemezetten futó ügynökök átnézik ezt a sort, és felveszik az elvégezhető munkát anélkül, hogy valakinek minden feladatot külön be kellene másolnia egy beszélgetésbe.
2. Az ügynök a kódbázisból dolgozik, nem egy elszigetelt promptból. Mielőtt bármit módosítana, elolvassa a repository utasításait, a meglévő architektúrát és a közeli megvalósítási mintákat. Ezután célzott változtatást készít, és lefuttatja a projekthez előírt ellenőrzéseket.
3. Az elvárt viselkedésből bizonyíték lesz. Az új működést példák és automatizált tesztek írják le. Egy igazolt hiba reprodukálható esettel, és ahol ez megoldható, a javítás előtt elbukó regressziós teszttel indul.
4. Egy másik modell megpróbálja megcáfolni az eredményt. A külön review-lépés hibás feltételezéseket, szélső eseteket, biztonsági kockázatokat, karbantarthatósági problémákat és hiányzó teszteket keres. Ez az ellenőrzés korán találhat hibákat, de a mérnöki review számára ad bizonyítékot, nem jóváhagyást.
5. A változat automatikusan tesztkörnyezetbe kerül. A folyamatos szállítás felépíti az ügynök munkágát, és elkülönített teszt- vagy előnézeti környezetbe telepíti. A változtatás még az összevonás előtt működő szoftverként próbálható ki.
6. Egy mérnök a teljes változtatást ellenőrzi. Elolvassa a diffet, a teszteket és a modellreview megállapításait, majd kipróbálja a telepített működést. Módosítást kérhet, elutasíthatja a megközelítést vagy jóváhagyhatja azt. Egyetlen ügynök sem hagyja jóvá a saját munkáját.
7. Csak a jóváhagyott munka halad tovább. Az emberi kapu után ugyanaz az automatizált folyamat készíti el a kiadható artifactot, és juttatja el a megállapodott élesítési folyamatba.

A kódbázis egyben használati útmutató

A hasznos ügynökutasításokat a kóddal együtt verziókezeljük. Leírják az architekturális határokat, a név- és importálási szabályokat, a komponensmintákat, az akadálymentességi elvárásokat, az adatkezelési szabályokat, a tesztparancsokat és az elfogadási feltételeket. A projektspecifikus döntések így a projekt mellett maradnak, nem valakinek a korábbi promptjaiban.

Ez azért fontos, mert a gyorsan elkészült kód fenntartása még lehet drága. Az ügynököktől ugyanazt várjuk el, mint egy tapasztalt közreműködőtől: használják a meglévő absztrakciókat, magyarázzák el a nem magától értetődő döntéseket, kerüljék a szükségtelen függőségeket, és mások számára olvasható, módosítható kódot hagyjanak maguk után. Ha egy feladat ellentmond az architektúrának, vagy termék-, biztonsági vagy adatvédelmi döntést igényel, az ügynöknek jeleznie kell ezt, nem rögtönöznie.

A világos utasítások a review-t is tárgyilagosabbá teszik. Nem az a kérdés, hogy tetszik-e a review-t végzőnek a generált kód. Az számít, hogy a változtatás követi-e a dokumentált rendszert, és teljesíti-e a feladathoz elfogadott viselkedést.

A review többrétegű, nem kiszervezett

Az automatizált ellenőrzések egyértelmű kérdésekre válaszolnak: helyesek-e a típusok, átmennek-e a tesztek, elkészül-e a build, és megfelel-e a változtatás a repository szabályainak? Ezután egy második modell más nézőpontból ellenőrizheti a megvalósítást, és megjelölheti a gyanús logikát vagy a bizonyíték hiányosságait.

A végső review-t ezek után a mérnök végzi. Ő ítéli meg, hogy a megoldás illeszkedik-e az architektúrába, megfelelőek-e a termék szempontjából kötött kompromisszumok, és valóban a fontos működést bizonyítják-e a tesztek. Az architektúra, a biztonságérzékeny döntések és a kiadás jóváhagyása akkor is emberi felelősség marad, ha az előkészítés nagy része automatizált.

A környezetek szabják meg az automatizálás határait

Fejlesztés

Az ügynökök saját munkágukon vizsgálhatják a repositoryt, megvalósíthatják a körülhatárolt változtatást és futtathatják a projekt ellenőrzéseit. A munka formálódás közben eldobható és a felhasználóktól elkülönített marad.

Teszt és előnézet

A tesztkörnyezetben válik automatikussá a visszacsatolási kör. Egy hibajelentés a környezet adataival, a naplókkal és a reprodukciós kontextussal együtt kerülhet a backlogba. Egy ügynök osztályozhatja és reprodukálhatja a hibát, regressziós tesztet adhat hozzá, elkészítheti a javítást, lefuttathatja az ellenőrzéseket, majd a változatát visszatelepítheti egy elkülönített előnézeti környezetbe. A javított működés így ellenőrizhető anélkül, hogy az ügynök utat kapna az éles rendszerhez.

Éles rendszer

Az éles környezet külön jogosultsági határ. Az ügynökök nem végeznek közvetlen éles módosítást, és nem léptetik tovább a saját munkájukat. Ellenőrzött összevonásra és kifejezett mérnöki kiadási jóváhagyásra van szükség ahhoz, hogy a szállítási folyamat telepítse a letesztelt artifactot.

A viselkedés vezérli a teszteket

A viselkedésvezérelt fejlesztés (BDD) közös sikerkritériumot ad az embereknek és az ügynököknek. Konkrét forgatókönyvek írják le a felhasználó vagy a rendszer nézőpontjából, minek kell történnie, mielőtt a megvalósítás részletei átvennék a főszerepet. Ezekből elfogadási feltételek és ahol hasznos, futtatható tesztek lesznek.

Mellettük széles automatizált tesztkészlet működik: célzott unit tesztek az üzleti szabályokhoz, integrációs tesztek a rendszerek közötti határokhoz, valamint end-to-end tesztek a kritikus folyamatokhoz. Minden igazolt hiba egy regressziós esettel erősíti ezt a védőhálót. A teszt nem lefedettségi előadás, hanem a termék vállalt működésének futtatható dokumentációja.

Ez a dokumentáció teszi biztonságosan ismételhetővé az AI-támogatott változtatásokat. Az ügynök gyorsabban haladhat, mert a hibák láthatók, a review bizonyítékokra támaszkodhat, a későbbi közreműködők pedig anélkül módosíthatják a rendszert, hogy minden korábbi döntést újra fel kellene fejteniük.

Folyamatos szállítás folyamatos kockázat nélkül

A folyamatos szállítás kicsiben, ellenőrizhetően és kiadásra készen tartja a változtatásokat. Minden változat ugyanazon a build-, teszt- és előnézeti folyamaton megy keresztül, így nem az éles rendszer az első hely, ahol a részek találkoznak.

Az automatizálás megszünteti a várakozást és az ismétlődő átadásokat. A felelősséget azonban nem szünteti meg. Az ügynökök mozgásban tartják a feladatsort, a modellek szélesítik a review-t, a tesztek védik az elfogadott viselkedést, a mérnökök pedig továbbra is felelnek azért, mi kerül a kódba és mi jut el a felhasználókhoz.