A probléma: a megértés csökken, a mutatók mégis zöldek
A kód lefordul, a tesztek zöldek, a pull requesteket jóváhagyják, a DORA-mutatók stabilak, miközben a csapat által élesített kód egyre kisebb részét érti bárki a csapatból.
Olyan kód mindig is került élesbe, amelyet senki nem értett teljesen: bemásolt kódrészletek vagy egy távozott kolléga modulja. Amíg kézzel írták a kódot, legalább a szerzője értette. Az AI-alapú kódolóeszközök ezt a biztosítékot is elveszik, így a rés aközött, amit egy csapat élesít, és amit ért, most gyorsan, de észrevétlenül nő.
Az árát később fizetjük meg: egy hibában, amelyet senki nem tud kinyomozni, vagy egy változtatásban, amelyhez senki nem mer hozzányúlni. A DORA-mutatók nem arra épülnek, hogy ezt előre jelezzék.
Az Anthropic 2026 januárjában publikált randomizált kísérlete meg is mérte a hatást: 52, többségében junior fejlesztő tanult meg egy új Python-könyvtárat (Trio), a felük AI segítségével. Az utána következő, megértést mérő teszten az AI-t használó csoport átlagosan 50%-ot ért el, a kézzel kódoló csoport 67%-ot. Többet számított, hogyan használták az AI-t, mint az, hogy használták-e: akik magyarázatot kértek és ellenőrizték a saját megértésüket, jól teljesítettek, akik mindent rábíztak, gyengén (forrás).
A CODA azzal a céllal készül, hogy ezt a rést láthatóvá tegye egy csapatban, mielőtt egy éles hiba tenné meg.
Gyorsaság kontra alaposság, felelősség kontra ellenőrzés
| Feszültség | Dimenzió | A kérdés |
|---|---|---|
| Speed vs. Depth (gyorsaság és alaposság) | Decision Velocity | Milyen gyorsan jut el a csapat az architekturális döntésekig? |
| Decision Confidence | Mennyire állják ki a döntések az idő próbáját? | |
| Ownership vs. Oversight (a szerző érti-e a kódot, és a reviewer ellenőrzi-e) | Comprehension Ratio | El tudják-e magyarázni és módosítani a kódot, amit élesítenek? |
| Review Depth | Mennyire alaposan nézik át a kódot merge előtt? |
Minden jel a csapat munkájából származik
Decision Velocity (a döntések sebessége). Mennyi idő telik el attól, hogy felmerül egy architekturális kérdés, addig, hogy a döntés írásban is megszületik: egy architekturális döntési rekordban (ADR), egy pull requestben vagy egy ticketben. Egy kiforrott ítélőképességű csapat nem hagyja hetekig lebegni a döntést, és nem is temeti el egy chatbeszélgetésben.
Decision Confidence (a döntések tartóssága). Mennyire tartósak az írásban rögzített döntések, a kísérletként megjelölteket nem számítva. Amik csökkentik: a visszavont döntések, a felülírt döntési rekordok és a visszagörgetett architekturális változtatások.
Comprehension Ratio (a kód megértése). El tudja-e magyarázni egy merge-elt változtatás szerzője, mit csinál a kód, miért így készült, és milyen határeseteket kezel, és hetekkel később is tudja-e módosítani. A bizonyíték egy beszélgetés egy véletlenszerűen kiválasztott pull requestről, vagy egy kisebb módosítás egy korábban élesített kódon.
Review Depth (a code review alapossága). Mennyire alaposan nézik át a kódot merge előtt, akár ember, akár AI írta: érdemi review-megjegyzések puszta jóváhagyás helyett, és tesztek a változtatás mellé. Ahol AI-t használnak, ott az is, milyen gyakran módosítják a fejlesztők az AI javaslatait ahelyett, hogy változtatás nélkül elfogadnák őket.
Miért párban
A DORA-mutatókat azért nehéz kijátszani, mert párokat alkotnak: aki mindenáron növeli az élesítések gyakoriságát, annál nő a hibás változtatások aránya. A CODA ugyanerre az elvre épül.
- Aki gondolkodás nélkül, gyorsan dönt, annak a döntéseit visszavonják: ugyan a Decision Velocity nő, a Decision Confidence csökken.
- Aki minden döntéssel addig vár, amíg biztosra nem megy, annak a csapata leáll: a Decision Confidence nő, a Decision Velocity viszont csökken.
- Ha a code review lesz a biztonsági háló, amely mindent kiszűr, a szerzők egy idő után a saját változtatásaikat sem értik: a Review Depth nő, a Comprehension Ratio csökken.
Egy kiforrott ítélőképességű csapat mindkét pár mindkét oldalán jól teljesít. Ha valaki az egyik dimenziót mesterségesen javítja, az a párján látszik.
A CODA, a DORA és a SPACE
A DORA azt méri, milyen gyakran és milyen megbízhatóan jutnak élesbe a változtatások. A SPACE a fejlesztői termelékenységet: elégedettség, teljesítmény, aktivitás, kommunikáció, hatékonyság. A CODA pedig a kettő mögött álló mérnöki ítélőképességet, így mindkettőt kiegészíti.
A Comprehension Ratiónak nincs megfelelője a SPACE-ben, amelyet még az AI-alapú kódolóeszközök elterjedése előtt terveztek, amikor a fejlesztők többnyire értették a kódot, amit írtak.
Mi maradt ki a CODA-ból
Két jelölt nem került be a négy közé. A tudás megtartását, vagyis azt, hogy a fejlesztők megőrzik-e a tudásukat, miközben a rutinmunkát az AI végzi, jobb a CODA mellett, korai jelzőként követni. A technikai adósságra pedig már vannak bevett mutatók, ezeket a CODA-nak nem kell megismételnie.
Hogyan teszteljük
- Szakmai kritika. Fejlesztési vezetők stressztesztelik: mi hiányzik, mi fedi át egymást, és hogyan játszanák ki.
- Pilot. Mind a négy dimenziót egy csapatnál mérjük több héten át, hogy kiderüljön, egyáltalán összegyűjthetők-e a jelek, és mennyi terhet rónak a csapatra.
- Korreláció. Elég sok csapat adataiból kiderül, hogy a jó csapatok mind a négy dimenzióban jól teljesítenek-e, az egyik dimenzió kijátszása látszik-e a párján, és a négy valóban különböző dolgot mér-e.
Mi cáfolná
Ha a párok a valódi csapatokban nem hatnak egymás ellen, vagy két dimenzióról kiderül, hogy ugyanazt méri, a modell változik.