A Tenex – Alex Lieberman és csapata – azzal a nem szokványos feltételezéssel indult, hogy a mérnököket a befejezett munkáért kell fizetni, nem az eltöltött órákért. Az elképzelés lényege: ha a mesterséges intelligencia felgyorsítja a munkát, az óradíjas elszámolás aránytalanul bünteti a gyorsabb, hatékonyabb mérnököt. Tenex inkább arra épít, hogy az ösztönzők az eredmény irányába hassanak.
A vállalat 18 hónap alatt egy AI-támogatott fejlesztőcégből olyan szolgáltatóvá nőtt, amelyet ma már a megbízói között Fortune 2000 vállalatok és középvállalatok is megtalálhatók; Lieberman szerint az ügyfelek megoszlása nagyjából fél/fél. A szervezet jelenleg körülbelül 75 főt foglalkoztat, és a dolgozók 90%-a mérnök vagy „AI strategist” (technikai konzultáns), akik ügyfélmegtartásért és növekedésért is felelősek.
Kimenetalapú kompenzáció: előnyök és buktatók
Tenex továbbra is story pointokat használ a mérnöki teljesítmény mérésére. A gyakorlatban a leggyakoribb félelmek – a becslések manipulálása vagy a rossz minőségben történő gyors leszállítás – nem váltak domináns problémává, részben mert az AI stratégiákért felelős csapatok ösztönzése eltér a mérnökökétől: nekik az ügyfélnövekedés és megtartás számít, ezért visszafoghatják a nem értékteremtő munkát.
Nehézséget okoz azonban, hogy sok értékes tevékenység nem esik szépen ticketekbe: ügyféligények feltárása, architektúra-tervezés, vagy a termékprioritások meghatározása. Ahogy a modellek jobbak lesznek, a mérnökök kevesebb sor kódot írnak közvetlenül, és több időt töltenek az ügyfélkontekstus modellnek való átadásával — ezt a nem-kódolási munkát be kell építeni a kompenzációs rendszerbe.
Lieberman említése szerint a fizetések szélsőértékei között nagy eltérések vannak: a legjobban fizetett és a legkevésbé fizetett mérnök díjazása között jelenleg körülbelül négyszeres szórás figyelhető meg, ami alátámasztja a teljesítményalapú megközelítés volatilitását.
MetaHarness: a projekt irányelveinek a repo-ban tartása
CJ Hess bemutatta a Tenex MetaHarness nevű megközelítését: ez egy közös készségkészletből, projekt-dokumentációból és parancssori eszközökből álló rendszer, ahol a tervek, döntések és elfogadási kritériumok a Git tárban vannak tárolva a kóddal együtt. Így amikor egy ügynök (vagy később egy másik ember) visszatér egy feladathoz, nem csak azt látja, mi lett megépítve, hanem azt is, hogy miért.
Tenex „AI-native SDLC” leírása szerint ez a projektrekord emberek és ügynökök számára egyaránt használható felületként működik, amelyből lineáris nézetek, GitHub-állapotok és kliensfrissítések is láthatók. A megközelítés különbséget tesz a „ügy hogy az ügynök gyorsabban írjon kódot” és a „környezetet olvashatóvá tegyük (terv, döntések, bizonyítékok)” megközelítések között. Ugyanakkor több strukturáltság kisebb csapatoknál túlzás lehet.
Kill My SaaS — az „építsük meg magunknak” költségei
A Kill My SaaS kísérletben a csapat 72 pályázatot kapott egy konferenciaspeaker-kezelő szoftver kiváltására; a szolgáltatásról korábban 43 000 dolláros éves díjat idéztek. A közönség- és szakértői értékelés alapján a győztes megoldás nem azonos volt az AI-s rangsor első helyezettjével, ami rávilágított arra, hogy a funkcionális megfelelés és a felhasználói igények mérése különböző eljárásokat igényel.
Lieberman szerint minél magasabb szegmensbe lépünk az ügyféloldalon, annál költségesebb és kockázatosabb egy meglévő, beágyazott rendszert kiváltani. Még egy kisebb eszköz esetén is gondolni kell a folyamatos karbantartásra: az egyszeri megtakarítás önmagában nem biztos, hogy ellensúlyozza a fenntartási terheket. A szerkesztői csapat viszont arra hívta fel a figyelmet, hogy a saját megoldás előnye lehet a gyors iterációs ciklus: a rossz terméket használó csapatoknak az a nyereségük, hogy a saját munkafolyamatukat percek alatt javíthatják.
Vertikális AI: hol érdemes specializálódni?
A Tenex vezetése óvatos a teljesen vertikális, egyedi megoldások hosszú távú skálázhatóságát illetően: ha minden ügyfél teljesen egyedi megoldást vár, hogyan lehet azt fenntartható szoftvermarginnal szolgáltatni? Ezzel szemben vannak példák — például Harvey (jog) vagy OpenEvidence (egészségügy) —, amelyek a szakmai adat, testreszabott felületek és integrációk miatt értéket hoznak.
CJ megkülönbözteti azokat a termékeket, amelyek fő értéke egy ügynök által végzett feladat, és azokat a megoldásokat, amelyek valóban a munkafolyamatot javítják és tartósan a felhasználó munkavégzésének helyévé válnak. A kérdés nem feltétlenül az, hogy a „vertikális AI” nyer vagy veszít, hanem hogy mely termékek válnak e munka végzésének fő helyszínévé, és melyek csupán egy ügynök funkciójává integrálódnak.
Műszaki trendek, költségek és modellek
A Tenexnél említett modellek közül az Opus 5.5-öt többen preferálják a csapatban a gyorsaság és költséghatékonyság miatt; korábban drágább modelleket is használtak, de a tokenköltségek mérsékelődtek. Lieberman és Hess arról beszéltek, hogy a token-spend/employee-spend arány cégenként eltérő lehet; Tenex jelenleg durván 1:1 és 2:1 között látja ezt a nyers tokenfelhasználás alapú számítást.
Összegzés: mikor érdemes építeni és miért számít a kontextus
Tenex sikere azt mutatja, hogy az eredményalapú kompenzáció működhet nagyobb szervezetben is, de finomhangolást igényel a nem-kódolási munkák, az ügyfélkommunikáció és a hosszabb távú építési/karbantartási kötelezettségek elismerésére. A MetaHarness és az AI-native SDLC eszközei segítenek abban, hogy a döntések és a kontextus durable módon a repo-ban maradjanak, ami különösen fontos a hosszú futamidejű feladatoknál.
A Tenex példája rávilágít a vállalati AI-adoptáció gyakorlati lépcsőire — általános LLM-kihelyezéstől az engedélyezésen és tréningen át a kódrendező ügynökökig —, és arra, hogy az „építsünk-e saját megoldást” kérdése mindig az üzleti kockázat, a fenntartási költség és a potenciális működési előny mérlegelése.
Keressük a bővülést: Tenex jelenleg is készít felvételeket "forward deployed engineers" és "AI strategists" pozíciókra, és New Yorkot tartja otthonának.
