A 2012. és 2020. közötti időszakban a Valeo-nál dolgoztam szoftverfejlesztő mérnökként, később SW projektmenedzserként. Ott megtanultam, mi a bürokrácia-túladagolás. 🦾 Meg kellett tanulnunk és be is kellett tartanunk az autóipari szoftverfejlesztési folyamatokat leíró szabványt, az ASPICE-t (Automotive SPICE). Ez lényegében az ún. V-modell (Németo., FOD, 1992) fejlesztési folyamatait vette alapul és ültette át az autóiparba. (De az V-modell és ASPICE kapcsolatáról többet majd egy másik posztban fogok írni.)

System engineering és verifikáció

Forrás: [Wikipédia]

A modellt két fő részre kell bontani. A V bal oldali (leszálló) szára az ún. specification stream , amelybe a költséghatékony(abb) követelményelemzés tartozik, ahol a specifikációhoz és designhoz kapcsolódó feladatokat hajtják végre.

A V jobb oldali (felszálló) szárát testing stream -nek nevezik, mert az a tesztelésről szól. Több szinten is, csak a legismertebbeket (és a minimumot) említve: unit, feature, integrációs, performance, user acceptance tesztelés.

A V csúcsában van maga az implementáció (a kód KÓD code írás 😎).

Ezeket csak azért írtam le, hogy egy rövid betekintést adjak arról, hogy ezek léteztek már korábban is (a ‘80-90-es években), és lásd, hogyan kezelték a kiszámítható, előre megtervezett, dokumentum-központú fejlesztési folyamatok a követelményeket és designokat.

Mi is akkor a fontos?

A tervezés (design). Gyakori kérdés és keveredésre okot adó, hogy: “Mi a különbség a követelmény és a specifikáció (részletezés) közt?” Ezt viszonylag egyszerű megválaszolni.

Amíg a követelmény arra fókuszál, hogy “Mit?” (What) kell elkészíteni, a specifikáció pedig már a “Hogyan?” -ra (How). Akár több szinten is: technikai részletek, high level design, low level design, integráció stb. Ha ennek a két szintnek a lényegét jól megérted, onnantól kezdve sok minden leegyszerűsödik. (Olyan ez, mint a víz feletti vagy víz alatti élet. Elég nehéz összekeverni őket, ha gyerekként próbáltál már levegőt venni a víz alatt.)

Hogy jön a képbe a mesterséges intelligencia?

Az AI-val (jól) előkészített és támogatott ún. Spec-Driven Development metódus is ezeket az absztrakciókat és logikai felbontásokat veszi alapul. Több megoldást is megvizsgáltam már (BMAD, Github SpecKit, Open Spec), és mindegyik ebből az alapvetésből indul ki. Másból nem is tudna, hiszen annyira logikus és célravezető, kár lenne eldobni elődeink jól bevált tudását.

Mi, szoftverfejlesztők utálunk dokumentációt készíteni. Igaz is: egy jól megírt kód magáért beszél. Még komment sem kell bele. Évtizedek óta tűzzel-vassal irtjuk a dokumentálást, és már-már szitkozódásnak számít, ha valaki kimondja: “Ezt le kéne írni egy doksiba” vagy “Van róla dokumentáció?” . Eeeeh… nem szoktuk szeretni.

Sajnos (vagy hála Istennek) ez a gondolkodás mostantól meg fog (meg kell) fordulni, mert az AI világában a dokumentáció az egyik legnagyobb érték. Miért is? Azért, mert az AI akkor van igazán elemében, amikor hatalmas mennyiségű dokumentációt habzsolhat, gyúrhat, elemezhet. Persze, hát ő ezen nevelkedett, ezt tanulta.

Egy Large Language Modelnek nem adhatsz oda egy kitépett könyvlapot, hogy: “Tessék, tanulj!” Neki lételeme a sok bemenő adat. Nem csak “gyerekkorában”, hanem akkor is, amikor azt mondod neki a promptodban: “Te most egy principal engineer vagy…”

A lényeg

Az elkövetkező időkben nem a kód lesz az üzleti érték (amúgy már most sem), hanem a jól megfogalmazott ötlet, specifikáció, dokumentáció. Miért? Mert erről lehet beszélni, meg lehet mutatni másoknak, el lehet adni egy vevőnek. Az emberi nyelven íródott, amit bárki képes megértetni, aki az adott domainben mozog (pl. egészség, lakásvásárlás, pszichológia).

Ne érts félre, én is szoftverfejlesztőként kezdtem a pályámat, de sokszor jött velem szemben a felismerés, hogy már a közvetlen főnököm sem értette, mit szeretnék a kóddal, ha nem írtam vagy rajzoltam le neki. Akkor egy három szinttel feljebb lévő vezető (tulajdonos) mennyire érti vajon? Érdekli ez egyáltalán? Nem.

Szóval eddig azért dokumentáltunk, mert a folyamat vagy a főnök kérte. Ezután már nem csak ezért fogunk, hanem a jól felfogott fejlesztői érdekünk , mert az AI-val így tudunk hatékonyan együttműködni. Jobban mondva: így tudjuk megfelelően utasítani, hogy mit készítsen el nekünk. Vagy valamelyik módosítás előtt készítsen egy kockázatelemzést, erőforrás- és költségbecslést.

Már az 5. generációs nyelvi absztrakciónál járunk, amit már természetes emberi nyelven írhatunk. Ez már intention-based tervezés. Leírjuk, hogy mit szeretnénk, plusz még a megkötéseinket. Ebből az AI már tud dolgozni (fejleszteni).

További előnyök

• Architekturális fejlődés: A fejlesztő architekturális gondolkodásmódot tanul a mesterséges intelligenciától. Nagyon magas szinten, mintha 0-24-ben egy principal engineerrel beszélgetne. Látnod kell: ha nem AI-val akarod megírni a kódodat, már akkor is hatalmas előnyt jelent a tervezési fázisban.
• Értelmes ügyféligények: A tulajdonosok és ügyfelek megtanulják végre értelmesen, átgondoltan megfogalmazni, mit is szeretnének, mielőtt egy fejlesztőhöz jönnek a ködös kéréseikkel. Sőt, lesznek néhányan annyira felkészültek is, hogy grafikai designnal (pl. Figma) érkeznek, amiről már lehet beszélgetni.
• Multimodális bemenetek: Az AI képességeinek köszönhetően az ügyfél már nemcsak szöveggel, hanem fotókkal, kézzel rajzolt vázlatokkal vagy akár egy gyorsan felvett hangüzenettel is átadhatja az elképzeléseit. A modern modellek ezeket a vegyes formátumokat is képesek egységes, strukturált specifikációvá gyúrni, így semmi nem vész el a fordítás során.

Az autóiparban megtanultam, hogy a mechanikai design (a fekete műanyag) vezérli a projektet, nem a szoftver. (Sok esetben arra is használták a projektmenedzserek, hogy megoldja a fejlesztési vagy gyártási pontatlanságokat.) Az autógyártó és a vásárló is csak a fekete műanyagot látja a végén, tehát a dizájn, az érzés mozgatja a piacot. Ettől eladható valami (vagy nem).

Egy jövőbeli posztban arra is kitérek majd, hogyan hajthatjuk az AI segítésvel még jobban a sajátg malmunkra a vizet. Ami véleményem szerint az egyetlen értékteremtő út marad majd a szoftverfejlesztők számára.