Az alkalmazott AI-cég Tenex alapítói, Alex Lieberman és CJ Hess a közelmúltban New Yorkban arról beszéltek, hogyan alakítják át a fejlesztési szervezetek jutalmazását és munkafolyamatait, ha a modellek jelentősen megnövelik az egyes mérnökök teljesítményét.
A modell: fizetés a teljesítményért, nem az óráért
Tenex korábban is azzal kísérletezett, hogy a fejlesztőket a leadott munkáért (story pointokért) fizessék, nem az eltöltött időért. Az indok: ha egy mérnök gyorsabban befejezi ugyanazt a feladatot AI segítségével, az órabéres elszámolás csökkentheti a bevételét. Tenex célja, hogy a ösztönzők a hatékonyság növelését díjazzák.
A gyakorlatban Tenex továbbra is story pointokat használ kompenzációs alkotóelemként, de megtanultak finomítani a rendszeren: a tipikus kockázatok — a becslések manipulálása vagy rossz minőségű szállítások a pontgyűjtés érdekében — nem váltak domináns problémává, mivel a cég AI-stratégái (technical consultants) a megtartásért és növekedésért felelnek, így érdekük, hogy valódi értéket hozzanak az ügyfélnek.
Ugyanakkor nehezebb díjazni azt a munkát, ami nem illeszkedik egy jegyhez: ügyféligény megértése, architektúra-tervezés vagy az, hogy mit érdemes egyáltalán megépíteni. Ahogy a modellek jobbá válnak, a közvetlen kódolás ideje csökken, és nő az az idő, amit a csapat az ügyfél kontextusának modellek számára történő előkészítésére fordít.
Méretek és ügyfélstruktúra
Alex Lieberman elmondása szerint a Tenex mostanra 75 fősre nőtt; ügyfeleik fele Fortune 2000 vállalat, a másik fele pedig középvállalat, jellemzően évi 100–500 millió dolláros árbevételű cégek. A csapat mintegy 90%-a mérnök vagy AI-stratéga.
A cég eredetileg AI-vezérelt fejlesztőműhelyként indult; mára egyre több ügyfél kér teljes vállalati AI-transzformációs támogatást.
Kompenzációs tanulságok
Tenexnél a legnagyobb kihívás az, hogyan lehet jutalmazni a nem-kódoló munkát: tervezést, ügyfélbeszélgetéseket és architektúrákat. A story point alapú rendszer továbbra is meghatározó, de szükség van rá, hogy a kompenzáció helyet adjon az ilyen hosszabb távú, nem könnyen ticketszámba foglalható feladatoknak is.
A cég szerint egy mérnökök közötti kereseti szórás körülbelül 4x — a legjobban kereső és a legkevésbé kereső mérnökök között. A modellek fejlődése az egyéni outputot is növelte: a Tenex csapata idén belül körülbelül kétszeres növekedést látott az átlagos story pointok havi mennyiségében egy mérnökre vetítve.
MetaHarness: a projekt a repo része
CJ Hess bemutatta a Tenex MetaHarness-át: egy közös képesség- és projektdokumentum-készletet és egy parancssori eszközt, amely köré a munka szerveződik. A tervdokumentumok, döntések és elfogadási kritériumok a Git repositoryban landolnak a kóddal együtt. Ez lehetővé teszi, hogy egy ügynök (agent), vagy egy későbbi csapattag ne csak azt lássa, mi lett megépítve, hanem azt is, miért döntöttek így.
Tenex saját írása az „AI-native SDLC”-ről azt a nézetet képviseli, hogy az emberi és ügynökalapú munkának ugyanazon projektfeljegyzés ellen kell dolgoznia, integrálva nézeteket a Linear-ból, GitHubból és ügyfélfrissítésekből. A struktúra növeli a munkafolyamat átláthatóságát, de túldizájn is lehet egy kis csapatnál vagy egyetlen projektnél.
Kill My SaaS: a saját szoftver birtoklásának költsége
A Kill My SaaS kísérletben a szerkesztőség megvizsgálta, hogy egy éves 43 000 dolláros speaker-management SaaS-t hogyan lehetne AI ügynökökkel helyettesíteni; a csere költsége nagyjából 1 000 dollár volt. A verseny győztese az emberi zsűri szerint erős volt, de az AI-zsűri rangsorában csak a 19. helyen végzett — emlékeztetve, hogy a funkcionális megfelelés és a felhasználói elfogadottság különböző értékmérők.
Alex felhívta a figyelmet: minél feljebb megy egy vállalatnál a skála, annál drágább és kockázatosabb egy bejáratott rendszer kiváltása. Még egy kisebb eszköznél is valakinek karban kell tartania azt — tehát a megtakarításokat a folyamatos fenntartási igényekkel és a kockázatokkal kell összevetni.
A cikk szerzője viszont kiemelte az ellenérvet: a saját eszköz birtoklása lehetőséget ad a munkafolyamat gyorsabb iterálására és a közvetlen felhasználói élmény javítására, amit a csapat gyorsabban alakíthat saját igényeire.
Vertikális AI és a termékek tartóssága
Alex általánosságban szkeptikus a kizárólag iparágspecifikus (vertikális) AI-termékekkel kapcsolatban: ha minden vállalat egyedi, "one-of-one" megoldást vár, hogyan tartható fenntartható módon szoftvermarginalitással? Emellett a frontier modellek javulásával sok alapfeladatot átvehetnek a horizontális, általános eszközök.
CJ különbséget tett egy olyan vertikális termék és egy olyan eszköz között, amely ténylegesen javítja a munkafolyamatot a feladat körül. A fontosabb kérdés szerinte az, mely termékek válnak tartós munkakörnyezetté, és melyek csak egy ügynök funkciójává olvadnak be.
Infrastruktúra, modellek és költségek
A Tenexnél a csapatok jelentős része Opus 5.5-öt és más modelleket használnak. A beszélgetésben említették, hogy a tokenköltségek esése és a verseny (mind zárt, mind nyílt forrású oldalon) lefelé nyomta az egységköltségeket. Tenex becslése szerint a nyers tokenköltség/alkalmazotti költség arányuk nagyjából 1:1 és 2:1 között mozog.
A cégnél fontos mutató a story pointok időbeli trendje; a csapatoknál az output körülbelül kétszeresére nőtt az elmúlt évben, részben az Opus modellek előretörésének köszönhetően.
Munkaerő és átképzés
A Tenex vezetői úgy látják, hogy az AI meg fogja változtatni, átalakítja, részben el is vesz majd bizonyos munkákat, de ez nem feltétlenül pusztán leépítést jelent. A javaslat inkább az újrafelosztás és a munkakörök felemelése: az ismétlődő, drudgery jellegű feladatok automatizálása után a munkavállalók stratégiaiabb, magasabb szintű problémákon dolgozhatnak. Mind munkáltatói, mind munkavállalói felelősség a készségfejlesztés.
Záró gondolatok és felvétel
Tenex jelenleg 75 fős, New York központú csapatával továbbra is mérnököket és AI-stratégákat keres. A cég hangsúlyozza, hogy az AI-transzformációban nemcsak a technológia bevezetése, hanem a folyamatok szabványosítása, a jogosultságkezelés és a permissioning megoldása is kritikus.
A Tenex megközelítése: fizessenek a szervezetek a kimenetért, rögzítsék a döntéseket és terveket a repóban, és mérlegeljék a saját szoftver építésének valós költségeit és előnyeit, különösen nagyvállalati környezetben.
