← Vissza a bloghoz
Fejlesztés

A kódolás egyre olcsóbb. A szoftverfejlesztés nem.

Írta: Roland Nagy 6 perc olvasás

Nemrég láttam egy körbejáró árlistát, olyan fajtát, amit azért osztanak meg, mert vicces, és egy kicsit túlságosan is találó. A fejlesztői opciókat egy étlaphoz hasonlóan hasonlította össze:

  • Macska a billentyűzeten $5/óra
  • Vibe coder $20/óra
Egy tréfás CheckoutLabs árlista, amely három fejlesztői opciót hasonlít össze: egy macskát a billentyűzeten $5/óráért, egy vibe codert $20/óráért, és egy szoftvermérnököt $100/óráért, mindegyikhez előny- és hátránylistával.

Nyilvánvalóan vicc. De az ilyen viccek általában azért működnek, mert egy valódi megfigyelés rejlik bennük, és ez most megér egy percnyi komoly gondolkodást.

Az AI drámaian olcsóbbá és gyorsabbá tette a kód írását. Ez a rész igaz, és ez jó dolog. Amit viszont nem gondolok igaznak, az az ebből következő állítás: hogy maga a szoftverfejlesztés kevésbé lett volna értékes, vagy hogy a $100/órás oszlop mostanra túlárazott nosztalgia.

Mindjárt az elején tisztázom, hol állok ebben, mert ez befolyásolja, hogyan érdemes olvasnod a folytatást. Folyamatosan használok AI kódolóeszközöket. Szinte minden munkámban gyorsabbá tettek. Ez nem egy „az én időmben még assemblyben írtunk" típusú panasz. Ennél specifikusabb a lényeg: a kód generálása és egy rendszer megtervezése nem ugyanaz a képesség, és az AI nem szünteti meg annak a szükségességét, hogy valaki rendelkezzen azzal az ítélőképességgel, ami a kettőt elválasztja.

Miben tényleg jó az AI

Kérj meg egy AI eszközt, hogy írjon egy termékszűrőt, egy checkout validációs scriptet, vagy egy Liquid szekciót, ami egy visszaszámlálót jelenít meg, és nagy valószínűséggel egy percen belül tisztességes munkát fog végezni. Egy prototípusnál, egy egyszerű funkciónál, vagy egy egyszeri belső eszköznél ez tényleg remek. Néhány évvel ezelőtt ezeknek a feladatoknak a nagy része azt jelentette, hogy az implementáció nagy részét kézzel kellett megírni és debugolni. Most gyakran egy kávészünet alatt eljutsz egy szilárd első verzióig. Nem fogok úgy tenni, mintha ez bármi más lenne, mint egy valódi fejlődés.

De a szintaxis megírása sosem volt ennek a szakmának a nehéz része. Tanuláskor annak tűnt, mert bármit is futtatni valódi erőfeszítést igényelt. Miután egy ideje csinálod ezt, rájössz, hogy a valódi nehézség végig valahol máshol volt: annak megértésében, hogy a rendszernek mit kell csinálnia, hogyan lép kapcsolatba mindennel a környezetében, mi történik, ha egy vásárló olyat csinál, amit nem vártál, és mi törik el hat hónappal később, amikor valaki más nyúl a kódhoz.

Az AI nagyon jó abban, hogy olyasmit hozzon létre, ami helyesnek tűnik. Sokkal kevésbé megbízható abban, hogy tudja, helyes-e a te konkrét rendszeredre, konkrét adataidra és konkrét szélsőértékeidre nézve. Magabiztosan megír egy kedvezményszámítást, ami finoman hibás egy adott pénznemnél, vagy egy webhook handlert, ami feltételezi, hogy egy rendelésnek mindig csak egy teljesítése van. A kód lefut. Egy code review-ban is elfogadhatónak tűnik, ha senki nem figyel oda igazán. Ez a veszélyes rész.

Hol jelentkezik ez Shopify projekteknél

Itt töltöm a munkaidőm nagy részét, szóval legyen ez inkább konkrét, mint elvont.

Az AI meg tud írni egy Liquid szekciót, egy JavaScript interakciót egy termékoldalon, egy API hívást a készlet szinkronizálásához, vagy egy alap Shopify app funkciót, mindezt gyorsan és elég jól. Ha ez az egész projekt, tényleg nincs szükséged sokkal többre ennél.

De a legtöbb valódi Shopify munka nem egy elszigetelt darab. Ez a Shopify Markets, ami több pénznemmel és nyelvvel párhuzamosan fut. Ez a checkout testreszabás azokon a korlátokon belül, amiket a Shopify valójában enged érinteni. Ez a készlet helyes szinkronizálása egy olyan rendszerben, ami metamezőktől, néhány harmadik féltől származó apptól, egy egyedi API-tól és néhány senki által teljesen nem dokumentált örökölt logikától is függ. Ezek azok a webhookok, amiknek helyesen kell viselkedniük, ha rossz sorrendben érkeznek, vagy kétszer, vagy egyáltalán nem. Ez az a vásárlói adat, aminek konzisztensnek kell maradnia öt olyan rendszer között, amiket sosem terveztek úgy, hogy egymással kommunikáljanak.

Ebből semmi sem kódgenerálási probléma. Ez egy „hogyan lépnek ezek a darabok ténylegesen kölcsönhatásba egymással, és mi a helyes viselkedés, amikor ütköznek" probléma. Az AI tud segíteni megírni a puzzle bármelyik egyes darabját, és megfelelő kontextussal a teljes puzzle-ről is tud segíteni gondolkodni. De valakinek még mindig biztosítania kell azt a kontextust, meg kell kérdőjeleznie a feltételezéseit, meg kell értenie a platform és üzleti korlátokat, meg kell hoznia a kompromisszumokat, és el kell döntenie, hogy melyik megoldás valójában biztonságos éles környezetbe kerülni.

A rész, ahol még mindig kell valaki, aki felelős

Van egy verziója az árazási érvnek, ami így hangzik: miért fizess $100/órát, amikor valaki AI-jal $20/óráért is megcsinálja?

Szerintem nem az az őszinte válasz, hogy „mert a drága fejlesztők automatikusan jobbak." Rengeteg drága fejlesztő nem az. Az őszinte válasz az, hogy az óradíj rossz közelítése a költségnek. A valódi költség inkább valami ilyesmi: díj × idő × hibák × jövőbeli karbantartás. Egy olcsóbb build lehet abszolút az összességében olcsóbb opció, főleg egy prototípusnál, egy belső eszköznél, egy kísérletnél, vagy valami valóban alacsony kockázatú dolognál. Sosem mondanám senkinek, hogy ne vibe-code-oljon egy landing page tesztet vagy egy gyors belső dashboardot. Ez gyakran pontosan a helyes döntés.

Ott kezd drágulni, amikor egy gyors, meggyőzőnek tűnő megoldás éles környezetbe kerül úgy, hogy olyan üzleti logikát hordoz, amit senki nem ellenőrzött teljesen, és a hiba három hónappal később bukkan fel egy árazási hibaként, egy elromlott checkout szélsőértékként, vagy egy adatszinkronizálási problémaként, ami csendben hetekig hibás rendeléseket okozott. Ezen a ponton a $20/órás build nem spórolt pénzt. Csak elhalasztotta a költséget és nagyobbá tette, és most valakinek meg kell értenie egy rendszert, amit nem ő épített elég jól ahhoz, hogy nyomás alatt kijavítsa.

Ez az igazi különbségtétel, amit tennék, és ez nem az, hogy „az AI írta-e ezt." Inkább az, hogy: valaki elég jól érti-e ezt a rendszert ahhoz, hogy felelős legyen érte? Egy kódbázis, ami kilencven százalékban AI által generált, még mindig lehet jól megtervezve, ha valaki tapasztalt megtervezte a megközelítést, átnézte az eredményt, tesztelte a szélsőértékeket, megértette a kompromisszumokat, és hajlandó kiállni mögötte éles környezetben. Fordítva is igaz. Egy teljesen kézzel írt kód, AI részvétele nélkül, még mindig lehet rosszul megtervezve, ha senki nem végezte el ezt a munkát. Sosem igazán az számított, hogy melyik eszközzel készült a kód.

Egy junior fejlesztő AI-jal gyakran lenyűgözően gyorsan tud egy működő első verziót létrehozni. A gyorsaság az első működő verzióig nem ugyanaz, mint a gyorsaság odáig, hogy biztonságosan futtathass rajta egy üzletet. Egy senior mérnök értéke ritkán arról szólt, hogy gyorsabban gépel-e kódot mindenki másnál. Inkább arról szól, hogy eleve ne a rossz dolgot építse, vegyen észre egy problémát a követelményekben, mielőtt az éles környezetben problémává válik, és a két megoldás közül az egyszerűbbet válassza a látványosabb helyett. Két óra ilyen gondolkodás olyan projekteket mentett meg, amiken dolgoztam, tíz-húsz óra rossz irányba építéstől. Az AI ebben a gondolkodásban is tud segíteni. De nem szünteti meg annak szükségességét, hogy valaki meghozza a döntést és vállalja az eredményt.

Hol tartunk most

Nem gondolom, hogy a válasz az lenne, hogy gyanakodjunk az AI-asszisztált fejlesztésre, és képmutató lennék, ha ezt állítanám, mivel én magam is nap mint nap használom. Azok a fejlesztők, akik nem hajlandók hozzányúlni ezekhez az eszközökhöz, egyszerűen le fognak maradni. De azok a fejlesztők, akik anélkül támaszkodnak az AI kimenetére, hogy megértenék, mit is állított elő, csendben kockázatot építenek a rendszereikbe, és ez a kockázat nem az első napon mutatkozik meg.

A legerősebb kombináció, amit láttam, nem az „AI a mérnöki tapasztalat helyett." Hanem a mérnöki tapasztalat, amit az AI mint erőforrás egészít ki: valaki, aki már tudja, hogyan néz ki egy jó megoldás, és az AI-t használja, hogy gyorsabban jusson el oda, és eleget tud ahhoz, hogy észrevegye, amikor a generált válasz hibás.

Az AI gyorsabbá teszi a fejlesztőket. Nem szünteti meg annak szükségességét, hogy tudd, mit csinálsz, és bármi esetében, ami egy valódi üzletet működtet, ez a rész egyáltalán nem lett olcsóbb.