Így fejlesztek AI-val: eszközök, költségek, minőség

AI segítségével fejlesztem a saját programjaimat. Hamarabb jutok el egy kipróbálható változatig, gyorsabban tudok javítani, és több szempontból tudom átnézni az elkészült megoldást. A fejlesztésre fordított pénzem közben nem lett kevesebb.

A munkámhoz több AI-rendszer, fejlesztési és feladatkezelő eszköz, saját szerverkörnyezet, valamint megvásárolt dizájn is kell. A ChatGPT, a Claude, a Grok, a GitHub és a Linear mind más feladatot kap ebben a folyamatban. Az eredményhez hozzátartozik a tervezésre, az ellenőrzésre és az üzemeltetésre fordított időm is.

Nálam tehát a gyorsabb fejlesztés és a jobb végeredmény a cél. Ehhez egy egész munkafolyamatot építek az AI köré, az első ötlettől az éles program frissítéséig.

Miből áll a saját fejlesztési rendszerem?

Az egyes eszközök szerepét érdemes külön látni. A kód elkészítése, a feladatok követése, a változtatások értékelése és az átadás eltérő munkát jelent.

A DG Ads Connector és az iSzinonima fejlesztési előzményeiben is megjelenik ez a munkamód: több AI-tól származó visszajelzésekből készülnek javítások, ezekhez feladatok és kiadási feljegyzések kapcsolódnak. Később is vissza tudom nézni, mi változott, miért nyúltunk hozzá, és melyik kiadásba került bele.

Az üzleti feladatot nekem kell meghatároznom

A fejlesztés elején azt tisztázom, hogy kinek és milyen helyzetben fog segíteni a program. Mit szeretne elvégezni a felhasználó? Milyen adatból dolgozunk? Mi legyen az eredmény? Hol kell emberi döntés vagy jóváhagyás?

Marketingesként és vállalkozóként ezt a részt különösen fontosnak tartom. Már itt eldőlhet, hogy a fejlesztés hasznos segítség lesz-e a napi munkában. Egy fölösleges funkciót gyorsan elkészíteni is fölösleges munka.

Az AI segít kérdéseket összegyűjteni, lehetőségeket összevetni és a követelményeket pontosítani. A célt, a sorrendet és az elfogadható működést viszont nekem kell meghatároznom. Ehhez értenem kell azt a folyamatot, amelyen változtatni szeretnék.

A DG Ads Connectornál például a kézi jóváhagyás a működés lényeges része. Az elemzési lehetőségek mellett azt is meg kellett határozni, melyik döntés marad nálam. Erről a DG Ads Connector működését bemutató cikkben írtam részletesebben.

Egy kalkulátornál az eredmény értelmezését is meg kell tervezni. Egy szótárnál a találatnak használható választ kell adnia. Egy adminisztrációs felületnél pedig érthetővé kell tenni, hogy egy művelet mit fog megváltoztatni. Ezekből a konkrét elvárásokból áll össze a fejlesztési feladat.

Így követem a fejlesztést és a javításokat

A nagyobb munkát kezelhető feladatokra bontom. A Linearban rögzítem, mit kell elkészíteni vagy javítani, és milyen eredményt várunk tőle. A kiadási feljegyzésekben az elvégzett ellenőrzések és a fennmaradó korlátok is helyet kapnak. Így egy későbbi folytatásnál van mire támaszkodni.

A kódot külön privát GitHub-projektekben követem. Egy fejlesztési ág az adott módosítás elkülönített munkaváltozata. A pull requestben áttekinthető, melyik kódrész változott, és ott kapcsolódhat hozzá értékelés is. Ha később előkerül egy hiba, ez segít megkeresni az érintett változtatást.

Amikor később új funkciót kérsz vagy jelzel egy hibát, ezekből az előzményekből tudunk tovább dolgozni. Látszik, mi készült el, mi változott, és melyik kérdés maradt nyitva. Ebből akkor is előnyöd van, ha te magad nem használod a GitHubot vagy a Lineart.

Az elkészült változatot több szempontból átnézem, és az AI-k visszajelzéseiből új javítási feladatok is keletkezhetnek. Ezeknek ugyanúgy követhető helyük van a fejlesztésben, mint az eredetileg kért funkcióknak.

A munka állapotát pontosan kell megnevezni. Az elkészült kód, a lefutott teszt, az átadható csomag és az élesben ellenőrzött változat eltérő készültséget jelent. Ha egy vizsgálat technikai okból el sem indult, akkor annak az eredménye továbbra is hiányzik. Ezt a nyilvántartásban is így kell kezelni.

Mit ad hozzá a több AI-val végzett ellenőrzés?

A több eszközt azért használom, hogy többféle visszajelzést kapjak ugyanarról a megoldásról. Külön meg lehet vizsgálni a működési hibákat, a hozzáférések kezelését, a teljesítményt és a későbbi módosíthatóságot. A saját projektjeimben a Claude és a Grok értékeléseiből is készültek javítások, a GitHubon pedig a Codex kódellenőrzése és biztonsági ellenőrzése is ad visszajelzést.

Az AI visszajelzésének feldolgozása további munkát igényel. Először megvizsgálom, hogy a jelzett probléma valóban fennáll-e az adott programban. Ha igen, tisztázni kell a javítás módját, majd ellenőrizni, hogy a változtatás megoldotta-e a problémát, és hogyan érinti a kapcsolódó működést.

Három hasonló vélemény önmagában még nem bizonyítja a helyes működést. A tényleges használatot és a hibás állapotokat is meg kell vizsgálni. Egy üres űrlap, egy hiányzó adat vagy egy megszakadó külső kapcsolat például más helyzetet teremt, mint a megfelelő adatokkal végzett próba.

Nálam a gyorsaság előnyének egy része itt hasznosul: több idő és figyelem jut a visszajelzések feldolgozására és az újabb javítási körökre. Ettől várok jobb végeredményt. A több előfizetés akkor éri meg, ha az eszközökkel elvégzett munka a programban is látszik.

A saját ChatGPT-költségem 500 dollár, és ez egyetlen tétel

A cikk írásakor, 2026. október 27-én a saját ChatGPT-költségem 500 amerikai dollár. Ehhez a munkakörnyezethez tartozik még a Claude, a Grok, a GitHub és a Linear használata, a szerver, valamint a megvásárolt dizájnok és az adott projekthez szükséges licencek.

A teljes ráfordításhoz a saját munkaidőmet is hozzá kell számolnom. A feladat megfogalmazása, a hibás javaslatok felismerése, az ellenőrzés és az átadás mind időt igényel. Az előfizetések és a szerver számlája mellett ezekkel is foglalkoznom kell.

A fejlesztés árának megítéléséhez ugyanígy a teljes feladatot érdemes megnézni. Milyen folyamatot kell megoldani? Hány rendszerrel kell kapcsolatot teremteni? Mit kell ellenőrizni? Hogyan lehet majd frissíteni és karbantartani a programot? Ezek a kérdések akkor is megmaradnak, ha a kód egy része gyorsabban elkészül.

Az én esetemben az AI-val támogatott fejlesztés összköltsége nem lett alacsonyabb. A ráfordítást a gyorsabb haladás, az alaposabb ellenőrzés és a jobb eredmény miatt vállalom.

A dizájnokat továbbra is megveszem

A megjelenésnek is megvan a maga költsége. Vásárolok dizájnokat és sablonokat, amikor azok megfelelő alapot adnak a projekthez. Ezek kiválasztásával és megvásárlásával a felület kialakításának egy részét tudom előkészíteni.

Ezután a sablont hozzá kell igazítani a programhoz. Be kell illeszteni a tényleges tartalmat, kialakítani az űrlapokat, az eredményeket és a hibaüzeneteket, majd átnézni a mobilos használatot. Egy adminisztrációs felületnél külön figyelmet érdemel, hogy a felhasználó értse a műveletek következményét.

A saját elvárásaimhoz a visszafogott betűméret, az áttekinthető elrendezés és a működő favicon is hozzátartozik. A felső menüt alapértelmezetten úgy kérem, hogy a tartalommal együtt görgessen. Ezekhez a megvásárolt sablont is hozzáigazítom.

A dizájn vételára mellett tehát az átalakításnak és az ellenőrzésnek is van költsége. Az AI segíthet a megvalósításban, miközben a felület használhatóságát végig szem előtt kell tartani.

Az átadás és a későbbi működés is számít

A telepíthető kiadásnál teljes csomagot kérek, azonosítható verzióval és követhető átadással. A Google Drive-on megőrzött ZIP-et össze kell tudni kapcsolni a GitHubon nyilvántartott forrásváltozattal. Ez egy későbbi javításnál vagy frissítésnél is segít eligazodni.

Ahol a program saját kezelő API-ja támogatja, azon keresztül kérem az állapotlekérdezést és a frissítést. Az API-n keresztül meghatározott műveleteket lehet elvégezni a programban. A változtatás után ellenőrizni kell, hogy az elvárt verzió fut-e, és a szükséges működés elérhető-e.

Ezért kérem a verziószám feltüntetését a láblécben is. Az új fejlesztéseknél elvárásom az erőforrás-figyelés, valamint az egyszerű telepítés, frissítés és adminisztráció. A szerverterhelés és a karbantarthatóság a használat során folyamatosan számít.

Számomra a jobb programhoz ezek a részletek is hozzátartoznak. A felhasználó értse, mit kell tennie, hiba esetén kapjon használható visszajelzést, a program pedig később is fejleszthető maradjon. Az AI-val támogatott munkám eredményét ezek alapján is megítélem.

Négy kérdés, mielőtt egyedi programot kérsz

Ezek a kérdések segítenek abban, hogy az ötletedből egyeztethető fejlesztési feladat legyen. Mindegyikre konkrét választ keress.

1. Le tudsz írni egy valós munkafolyamatot, amelyben a programot használni fogod, a bemenő adatokkal és a kívánt eredménnyel együtt?
2. Meg tudod mondani, mi történjen hiányos adat, hibás bevitel vagy sikertelen művelet esetén?
3. Van olyan próba, amellyel egyértelműen eldönthető, hogy az elkészült funkció megfelelően működik?
4. Tisztázott, ki kezeli a hozzáféréseket, a frissítéseket és a később felmerülő hibákat?

Ha az első kérdésre nincs válaszod, írj le egyetlen konkrét feladatot a jelenlegi munkádból. Ha a másodiknál akadsz el, gyűjts össze néhány hibás helyzetet és a kívánt visszajelzést. Ha a harmadik hiányzik, határozz meg egy kipróbálható elfogadási feltételt. Ha a negyedik bizonytalan, egyeztess az üzemeltetés felelőséről és feladatairól. Több hiányzó válasznál kövesd ezt a sorrendet.

Ha mind a négyre tudsz válaszolni, már van használható kiindulópontod a fejlesztési egyeztetéshez. A megvalósítás részleteit, a vállalt feladatokat és az árat erre lehet felépíteni.

Én is ebből indulok ki. Meghatározom, mire van szükség, kiválasztom a munkához az eszközöket, feldolgozom a visszajelzéseket, és ellenőrzöm az eredményt. Ez a folyamat komoly ráfordítást igényel. Az AI abban segít, hogy gyorsabban tudjak haladni, és több lehetőségem legyen javítani az elkészült programon.

Ha van olyan visszatérő kézi feladat a vállalkozásodban, amelyre egyedi megoldást szeretnél, nézd meg az egyedi automatizálási szolgáltatásomat. Az egyeztetéshez írd le, mit csinálsz most, hol akad el a folyamat, és milyen eredményt vársz a programtól.

Szerző: Dajka Gábor, marketingszakértő és -menedzser, business coach, befektető.
A cikk írásának dátuma: 2026. október 27.

A bemutatott munkafolyamat a saját projektjeimen alapul. Az eszközök általános működéséről: GitHub: pull requestek értékelése; Linear: projektek kezelése.

A bevezető kép forrása: Pexels / Pixabay.