Új hozzászólás Aktív témák

• #11 BeZol őstag

  Új Válasz 2026-03-05 00:04:12 #11

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  BeZol

  őstag

  Én még nem használom, sőt, a melóhelyen csak nekem nincs github copilotom, mert nekem még mindig nem adtak... Mikor utoljára privátban copilotoztam, akkor még csak beépített chatként volt használható vscode-ban, de ugye azóta van agent mód is.

  Most éppen konferencián (Basta) vagyok Frankfurt am Main-ban, és több AI-al kapcsolatos előadás is volt, így gondoltam leírom, mit tapasztaltam (2ezer € volt a jegy).

  Többször az volt az érzésem, hogy előadnak vmit, ami szinte semmire sem jó, vagy csak becsomagolnak dolgokat vmibe, elnevezik máshogy, de a végeredmény ugyanott hibázik, éspedig a context mennyiségén és az LLM minőségén, na meg hogy mennyi az annyi a végén... (utóbbiról 0 duma persze)

  Aminek értelmét láttam, az a Spec Driven Development:
  Specify, Plan, Tasks, Implement.

  Specify
  Előre, szépen részletesen leírod mit mivel hogyan szeretnél. Minél részletesebb, annál jobb lesz az eredmény. Gyakorlatilag produkt manager és architect ha összeülne, hogy miről van szó és azt hogyan kellene megvalósítani (tech stack, mit várunk eredménynek, ezt hogyan teszteljük), akkor jobb helyeken egy ilyesmi dokksit állítanának össze.

  Plan
  Ezután az LLM megtervezi az egészet, és ahol bizonytalan, ott egyeztetsz vele mi legyen pontosan.

  Tasks
  Az LLM létrehoz feladatokat (mintha Jira ticketek lennének).
  Szerintem ide tartozik az is, hogy létrehoz olyan Agent-eket, amik frontend, backend, test, stb. specializációra vannak konfigurálva. (mint ahogy a valóságban is szétosztanánk)

  Implement
  Az Agent-ek beindulnak (párhuzamosan akár nagyon sokan), mert a fentebbi dolgokból sok-sok pici feladat készült, ami nem igényel óriási context-et, és mindegyik esélyesen jól is fog elkészülni.
  Nekem ez olyan feeling, mint amikor sima kérdezz/felelek esetben kérdezek a kódommal kapcsolatosan valamit, akkor ha csak 2-3 dolog függ össze, az még oké, ha már 4-5 dolog is, akkor esélyesen nem tudja megoldani a problémát, és a vége az, hogy jobban szét kell darabolnom. Gyakorlatilag itt ugyanez a cél, ezért így kicsi falatokkal zajlik a megvalósítás.

  Az egész mögé természetesen lehet MCP servereket bekötni, hogy ha nem lenne up to date a tudás, akkor legyen honnan legújabb dokksihoz nyúlniuk.
  A context7-et ajánlották, merth ingyenes.

  Több előadás is szólt arról, hogyan hozhatunk létre saját MCP servert, ami végeredményben (sztem) csak annyi, hogy előre definiált specifikációkat/promptokat pakolunk beléjük, és x/y esetben a megfelelő MCP serverről ezt elő is hívjuk.
  A legjobb, hogy több esetben még konkrét kérésre sem voltak hajlandók az LLM-ek használni a háttérben futó MCP servert Úgyh nekem ez eléggé béta állapot.

  Egyik előadó az meg a backend kódba kvázi mint .json bepakolta a promt-jait, aztán az LLM által meghívta az xy függvényt, amihez az xy.json tartozott, és pakolta be magának az LLM az extra context-et a feladathoz.
  Ez egyébként egy CQRS Event Source patternes témakör volt.

  A Spec Driver Developmentes előadó szerint 256k context is kevéske, fél misi kell h rendesen tudjon működni egy zöld projekt esetén, DE ez a zöld demo projekt sem volt egy nagy durranás...
  Barnamezős eset passz.

  Youtube videók alapján pedig úgy lehet ügyeskedni, hogy a spec-eket a legjobb modellekkel iratod, de a végrehajtásokra már az olcsóbb modellek is esélyesen elegek, ha meg vhol mégis elhasalnának, vissza rápakolod arra a részre az okosabbat.
  A legegyszerűbb részekre meg akár lokális modellek is jók lehetnek.

  Valami ügyeskedés is van ilyen nagyobb Agentic development esetén a context-tel és a tokenekkel, de pl. MCP témakörök esetén a kód, amin csináltattak valamit, az kb. 500 token volt, az MCP által hozzápakolt context miatt pedig jött további 4500 token...

  Spec Driven Development esetén (meg esélyesen a teljesen agentic mód témakörben) nem tetszik, hogy teli lesz pakolva a projekt .md fájlokkal amikben a specifikációk pihennek ugye, ÉS a specifikáció a source of truth... Nem a kód

  Szerintem pár év, és ez lesz az új standard.
  A kérdés az, hogy amikor ezek az LLM Agent-ek elakadnak, és muszáj egy programozót ráállítani, akkor a kód mennyire lesz emberileg emészthető struktúrában.

Új hozzászólás Aktív témák