Új hozzászólás Aktív témák
-
É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.Kaptam melóban végre valahára GitHub Copilot licenszet.
Mint kiderült, egyik kollega már rakott össze belső Agent-eket, amik tudják a belső configokat, ergo bármit kérdezel, azonnal 100ezres context körül vagy... Kicsit kellemetlen a havi limittel kapcsolatosan, szóval sima liba pár egymáshoz nem köthető kérdéssel napi 10%-ot összehozni a havi 20€--s csomag keretéből...A válaszok annyira jók, amennyire a mintapéldák + mintakódok meg vannak írva. Mindig van vmilyen eset, ami miatt finomhangolni kell, de idővel egyre tökéletesebbek lesznek.
A "10x developer" több esetben is többre kijött.
A senior kollegákat eddig sem kellett gyakran kérdezgetnem, de most már végképp szinte semmi.
Volt, hogy 30perc alatt megoldottam egy kb. 1,5-2 napos melót.Szóval brutális, és ez csak a Claude Sonnet 4.6 modell volt.
Egyszerűen ég és föld a különbség amiatt, hogy Agent módban használja az ember ezeket.
Ezen felbuzdulva otthon előfizettem a Claude Pro-ra, legeneráltattam egy egyszerű 3 sornyi prompttal egy weboldalt, majd 2 finomhangolás után elfogyott az 5 órás limit, illetve a heti limit 20%-a talán
Mondom akkor jöhet a Max, úgyhogy előfizettem a 200€-sra...Első benyomás: lehetetlen kimaxolni.
Aztán challenge accepted alapon a heti limitet most 3nap alatt elértem és elvonási tünetem van még asszony szerint is (kedd 12:00kor resetel)3 sornyi prompttal olyan weboldalt rakott össze 6perc alatt, ami nekem 2-3 hét lenne 8 órás munkával.
Egy másik weboldal esetén jobban specifikálva a dolgokat és pár környi tervezést lenyomva már 2-2,5 óra volt egy másfajta weboldal legenerálása, de ennél már konkrétan azt éreztem, hogy ez akár 2-3 hónapnyi 8órás munka lehetett volna...És kvázi pikk-pakk ott van egy kattingatható weboldal (backend, adatbázis és server nélkül), amit miután teljesen az ízlésedre finomhangoltál, esélyesen pikk-pakk hozzápakolja a hiányzó részeket a komplett csomag érdekében.
Csak ízlésbeli dolgokba tudtam a kódon belül belekötni, egyébként jó volt minden...
Ha meg esetleg nem működne vmi rendesen, ott a playwright mcp, és önellenőrzi magát
Figma mcp is van, ha vki design-okat importálna.Szóval nagyon komoly.
A Max terv miatt végig Opus 4.7 (Max)-ot használtam az 1M context-el.Régen forexeztem vmennyire, jártam tőzsdetanfolyamokra, és akkoriban az volt az érzésem, hogy le kellene automatizálni a stratégiákat, fene sem akar egész nap chartokat bámulni.
Volt is erre akkoriban MetaTrader4-ben megoldás, de nem tudtam akkoriban programozni, ezért volt h 1-2 ötletet leprogramoztattam vkikkel, az persze a végén sosem csinálta pontosan azt amit leírtam (ugye speciális esetekre nem gondoltam, meg ők sem), amik a tesztek során kijöttek és kvázi használhatatlan volt amiért fizettem. Másik probléma volt, hogy a tesztek során a valós költségek sosem voltak figyelembe véve, és kaptál egy szép eredményt, ami kamu volt...Erre most tessék, mondom akkor hadd szóljon.
Pythonban megírt egy komplett backtest rendszert, a tapasztalataimat és a saját tudását belerakta, kellett pár önellenőrzés, meg még utólag is jött rá hibákra, de mostanra van egy komplett rendszer amire csak rá kell dobni a stratégiát és kiteszteli mizu. A 9800X3D-met úgy beterheli, hogy ami Cinebench R23-ban 84fokos maximum volt, az itt 92fok (lejjebb is vettem azóta procit 1.18V @5.3GHz-ről -> 1.15V 5.2GHz-re)Leírtam Claude-nak mit szeretnék (évi 100% hozam
), leírta h na persze, legjobbak tudnak talán +30%-ot , de több napnyi küzdés után most:
Éles brókerre bekötést már megcsináltattam vele (5féle eurusd projektet kezdtem el), ha lesz újra keretem, bekötöm a mostanit is és majd megint visszaellenőriztetem még1xer, hogy biztos jók-e a számok.Ami pedig most lezabálta a tokeneket, az egy counter-strike és battlefield keverék játék egy dust2 szerű pályára
Nem értek a játékfejlesztéshez, de a webfejlesztéses tapasztalatokból ítélve talán itt is megoldható utólag pár további finomhangolási körrel, ha valami mégsem úgy megy ahogy elgondoltam.
Rust-ban írja, olyan dolgokra gondolt már a tervezés során, amik bennem fel sem merültek, viszont a changelist alapján (jelenleg 54ezer soros!) ennél sokkal nagyobb mélységig lement... Most már nem akarom veszni hagyni, mert érdekel mi lesz ebből ingyenes textúrákat és modelleket használva (azóta érkezett blender mcp is, szóval nem izgulok emiatt sem). A lényeg, hogy most az MVP (Minimum Viable Product) készül.Claude szerint: **MVP**: ~11–14 months solo full-time.
Nem tudom milyen solo dev az, aki ért a komplett játékmotorfejlesztéshez (semmi unity, unreal engine nincs, egyedit ír, és Vulkan alapú lesz elvileg), az audio-hoz, a grafikákhoz, animációkhoz, hálózatokhoz, stb.
Ja és úgy csináltatom vele, hogy a végén legyen egy installer, ami egy launcher-t rak fel (mint a steam pl.), a launcherben tudod felrakni a játékot, és automatikusan kapja a frissítéseket. Ergo miután baráti körnek körbeadogatom és leteszteljük h mizu, ha tolok ki bármilyen fejlesztést, megkapja mindenki automatikusan a jövőben is
Hát iszonyat kíváncsi leszek mi sül ki ebből, egyébként ha nem működik, és nagyon rossz, akkor úgyis megy a levesbe, és akkor kövi játékprojektnek egy mobilos játékot célzok majd be, csak előtte körbekérdezem ismerősöket milyenre lenne igény.
Ugye esélyesen semelyik játék nem lenne piacképes, ergo legalább baráti körben szórakozzunk egy jót
A slusszpoén így a végére, hogy a fenti dolgokat mind párhuzamosan egymás mellett csináltattam a Claude-al
Annyi, hogy a játékgenerálásnál a ralph-loop plugint használom, egyébként 5-15percenként csinálni kellett volna valamit, így pedig a "COMPLETE" fázisig megy.Ez a 2-2,5 órás weboldalgenerálás eredménye, ha valakit érdekel:
Kód: [link]
Kattingatható weboldal: [link]
(csak "nyers" weboldal, tehát bármit csinálsz rajta, csak lokálisan a te böngésződben mentődik el addig, amíg újra nem indítod a böngésződet, semmilyen online kommunikáció nem történik benne)Úgyhogy én ámulok és bámulok, és ötletem sincs mi lesz így a programozók jövője, mert a feladatok ellenőrzésére és manuálisabb tesztelésére biztosan nem kell annyi ember mint most.
-
Sziasztok!
Hobbi projektként összeraktam egy interaktív zongora gyakorló webappot, Claude és Gemini segítségével. Ez egy MIDI billentyűzettel is működő, webes aplikáció.
Hat modul van benne (kottaolvasás, hallásfejlesztő, akkordok, skálák, Hanon gyakorlat, ritmusfejlesztés).
Fejlesztési ötleteket és kritikát szívesen fogadok!
Ha érdekel valakit a téma, létrehoztam egy külön topikot.Pont ilyet akartam múltkor csinálni. Fain.
Elmentem későbbre, amúgy is lenne itthon egy MIDI keyboard amit még valami ilyesmire vettem a covid idején. -
kardkovacsi
senior tag
-
Harmadik: AI MSC szak. Miért ne? Ha attól tartunk, hogy az AI modellek elveszik a fehérgalléros munkákat, akkor elég egyszerű következtetés, hogy ilyen modellek előállítása és trainelése lesz az egyik legjövedelmezőbb, legkeresettebb dolog. De én simán mérnökinfo/proginfo MSC-re is tovább mennék talán. Bár az ott tanultakat munka közben/mellett is össze lehet szedni. Vagy legalábbis amíg az ember a kódot javarészt magának írta, addig össze lehetett. Illetve MSC és munka egymás mellett igen gyakori, bele lehet vágni.
-
Ma merult fel gyereknel. Van ertelme a mai mernokinf/proginf BSc hallgatoknak MSc-re menni, ha eredetileg ugy volt tervezve? Ket erv: 1.) MSc absztrakcio resz lesz az erdemi, ami maradhat a prog. szakmabol, a technologiai kodirast meg tuti atveszi az AI 2.) mindegy mit tanul most, a szakma mire kijon megvaltozik es devalvalodik egy ilyen datumu diploma, probaljon meg mielobb elhelyezkedni (es kozben tanulni nem iskolarendszerben)
Azok velemenye erdekel, akik 3 eve kapasbol MSc-t mondtak volna; akik az AI-tol fuggetlenul idohuzasnak/pazarlasnak tartjak azok velemenye nem ehhez a jelenseghez tartozna. -
Ma merult fel gyereknel. Van ertelme a mai mernokinf/proginf BSc hallgatoknak MSc-re menni, ha eredetileg ugy volt tervezve? Ket erv: 1.) MSc absztrakcio resz lesz az erdemi, ami maradhat a prog. szakmabol, a technologiai kodirast meg tuti atveszi az AI 2.) mindegy mit tanul most, a szakma mire kijon megvaltozik es devalvalodik egy ilyen datumu diploma, probaljon meg mielobb elhelyezkedni (es kozben tanulni nem iskolarendszerben)
Azok velemenye erdekel, akik 3 eve kapasbol MSc-t mondtak volna; akik az AI-tol fuggetlenul idohuzasnak/pazarlasnak tartjak azok velemenye nem ehhez a jelenseghez tartozna. -
Ma merult fel gyereknel. Van ertelme a mai mernokinf/proginf BSc hallgatoknak MSc-re menni, ha eredetileg ugy volt tervezve? Ket erv: 1.) MSc absztrakcio resz lesz az erdemi, ami maradhat a prog. szakmabol, a technologiai kodirast meg tuti atveszi az AI 2.) mindegy mit tanul most, a szakma mire kijon megvaltozik es devalvalodik egy ilyen datumu diploma, probaljon meg mielobb elhelyezkedni (es kozben tanulni nem iskolarendszerben)
Azok velemenye erdekel, akik 3 eve kapasbol MSc-t mondtak volna; akik az AI-tol fuggetlenul idohuzasnak/pazarlasnak tartjak azok velemenye nem ehhez a jelenseghez tartozna. -
axioma
veterán
En megmondom oszinten elvesztettem a fonalat akkor.
Eddig is specko alapjan ment a fejlesztes mindenhol (normalis helyeken). A specko milyensege mar mas kerdes, jellemzoen iterativan fejlodott az is a koddal egyutt jobb helyeken (agile) mashol elore probaltak mindent specifikalni (waterfall, el is bukott altalaban).
En nem latok ehhez kepest semmi valtozast.
”arrol volt szo, hogy az ipar igenye”
ez meg meg nagyobb homaly szamomra, ki definialta es mikor hogy mi az ipar igenye? (Egyaltalan milyen ipar?)Az en javaslatom hogy probaljunk meg gyakorlat orientaltak lenni, ilyen homalyos elmeleti dolgokkal viszonylag nehez vitatkozni.
Konkretan amik eddig itt felmerultek ez kapcsan annak zero koze van az AI-hoz. -
kardkovacsi
senior tag
Ezt orommel hallom, kivancsi leszek a hosszutavu tapasztalataidra. Probald ki azt is hogy tobb peldanyt inditasz belole es parhuzamosan dolgoztatod oket (ha olyan a feladat, csak arra figyelj hogy ne egy folderben dolgozzanak mert akkor egymas labara lepnek).
A tobbirol en is hasonlokat gondolok, de leginkabb hogy teljesen at fog alakulni ez a szakma.
-
forumpista
aktív tag
Tegnap előtt előfizettem egy Claude-ra a privát projektemen is. Eddig csak bent a cégnél volt.
Eddig gondolkodtam, hogy a gyorsabb befejezés érdekében fogadok egy programozót aki segít nekem munka mellett, akinek oda lehet adni nagyobb taszkokat. Most így azt látom nem kell. Tényleg olyan lett az egész mintha lenne egy medior programozóm, aki néha kicsit másnapos, de alapvetően működik. Az ilyen refaktor cuccokra a legjobb, ezt rakd át ide, onnan vedd azt ki, kezeld a cache-t stb. és csinálja mint a katonatiszt.Azt gondolom akik meg fognak maradni a mi szakmánkban azok az architekt gondolkodású senior emberek akik mellette hajlandóak részben PO irányba is mozdulni. Tehát értsd a businesshez, érts az architektúrához és jól tudd az agentet paraméterezni. Szerintem a klasszik BA/PO emberek akik nem értenek a technológiához legalább annyira veszélyben vannak mint a medior programozók.
-
forumpista
aktív tag
senki nem mondta, hogy az ember vagy az AI legyen determinisztikus
arrol volt szo, hogy az ipar igenye az a specko mint single source of truth-szal szemben, hogy determinisztikusan keszuljon belole a kod... nem kerjuk a nem optimalisakat
ez a vegcel, hogy ezt mivel ered el, az mindegy
(gyakorlatilag ujabb fordito szint - ott is lehet nemdef, forditofuggo, arra nem tamaszkodsz, ennyi) -
axioma
veterán
Ezt szerintem feladat valogatja. Nezzuk sorban:
- Mar most is van olyan feladat amit az AI jobban kodol le mint a legtobb programozo, tehat teljesul az allitasod.
- Egy feladatnak azonban sokszor nem csak egy jo megoldasa van altalaban, tehat az “egy tuti” maximum nagyon pici funkcio vagy kodreszlet eseteben teljesulhet csak
- barmilyen feladat eseteben pedig a legtutibb megoldast akkor varhatjuk az AI-tol ha mar legalabb olyan okos (vagy okosabb) mint a legseniorabb programozo. Ez meg (szerencsere) nem teljesul.De tovabbra sem ertem a determinisztikussag vonatkozasat ennek a specifikacioval kapcsolatban.
Mert valami akkor determinisztikus ha egy adott specifikaciobol 1000bol 1000szer pontosan ugyanazt a vegeredmenyt adja.Es ahogy irtam, ez emberi programozok eseteben sem teljesul (sot, technikailag egy paradoxon, mert ahhoz olyan reszletes specifikacio kell amit ugy hivunk hogy programkod. De ha meg megvan a programkod, akkor minek az egesz feladat
).Szoval az AI soha nem lesz determinisztikus, es nem is kell neki, mert akkor semmi kulonbseg nem lenne kozte meg egy fix programkod kozott, es el is vesztene az “I” jelleget. Ugy hivnank hogy algoritmus.
-
kardkovacsi
senior tag
-
forumpista
aktív tag
Persze, 10 megoldast kapsz. De azok kozul (vagy azok keverekebol, mind1) lesz egy szerinted - vagy mas erre felkent szemely szerint - leginkabb odaillo. En az AI-tol baromira nem a 9 (vagy 10) szuboprimalisat varnam, hanem azt az egy tutit. Nem?
Ezt szerintem feladat valogatja. Nezzuk sorban:
- Mar most is van olyan feladat amit az AI jobban kodol le mint a legtobb programozo, tehat teljesul az allitasod.
- Egy feladatnak azonban sokszor nem csak egy jo megoldasa van altalaban, tehat az “egy tuti” maximum nagyon pici funkcio vagy kodreszlet eseteben teljesulhet csak
- barmilyen feladat eseteben pedig a legtutibb megoldast akkor varhatjuk az AI-tol ha mar legalabb olyan okos (vagy okosabb) mint a legseniorabb programozo. Ez meg (szerencsere) nem teljesul.De tovabbra sem ertem a determinisztikussag vonatkozasat ennek a specifikacioval kapcsolatban.
Mert valami akkor determinisztikus ha egy adott specifikaciobol 1000bol 1000szer pontosan ugyanazt a vegeredmenyt adja.Es ahogy irtam, ez emberi programozok eseteben sem teljesul (sot, technikailag egy paradoxon, mert ahhoz olyan reszletes specifikacio kell amit ugy hivunk hogy programkod. De ha meg megvan a programkod, akkor minek az egesz feladat
).Szoval az AI soha nem lesz determinisztikus, es nem is kell neki, mert akkor semmi kulonbseg nem lenne kozte meg egy fix programkod kozott, es el is vesztene az “I” jelleget. Ugy hivnank hogy algoritmus.
-
axioma
veterán
Hogy erted azt hogy minimalis szabadsag van?
Ha fogsz pl. 10 random emberi fejlesztot, odaadod nekik ugyanazt a speckot, akkor 10, bitre azonos megoldassal fognak eloallni?En 20 eve vagyok a szakmaban, a tapasztalatom szerint meg csak az algoritmusok sem lesznek azonosak a megoldasokban, nemhogy a tobbi sallang. Ami azonos lesz, hogy mindben lesznek bugok dogivel.
Ezert nem ertem ezt a determinisztikussag vonalat. Az elkeszult kodnak kell determinisztikusnak lennie, nem a speckobol a kodig utnak.
-
forumpista
aktív tag
Mondok egy (hulye) peldat:
Ki van rakva egy szoftver prodra, Gizika hasznalja. Gizike messze van a projekttol csak end user, viszont valami edge case eseten amit meg akart oldani rajott, hogyha bal kezzel fogja a lapat elet es kozben 3x elkantalja a himnuszt, akkor az tortenik amit o szeretne.
Ker valaki crban egy modositast, ami esetleg egy minimalisat belenyul oda is ami Gizikenek lehetove tette amit eddig csinalt eltorjon (amugy meg semmi koze annak a modositasnak ahhoz a reszhez), Gizike ott fog szenvedni.
Masik oldalrol persze tok jo, h minden elvart es specifikalt mukodes mukodni fog, de lesznek ilyen nem vart problemak, h az end user agya eldurran, mert minden egyes releasenel megvaltozhat amit eddig megszokott. Persze ez megtortenhet igy is, de kisebb az eselye, hiszen kodban tortenik modosulas es nem speci szinten, amibol egy tok mas kod is eloallhat. -
tomazin
veterán
Hogy erted azt hogy minimalis szabadsag van?
Ha fogsz pl. 10 random emberi fejlesztot, odaadod nekik ugyanazt a speckot, akkor 10, bitre azonos megoldassal fognak eloallni?En 20 eve vagyok a szakmaban, a tapasztalatom szerint meg csak az algoritmusok sem lesznek azonosak a megoldasokban, nemhogy a tobbi sallang. Ami azonos lesz, hogy mindben lesznek bugok dogivel.
Ezert nem ertem ezt a determinisztikussag vonalat. Az elkeszult kodnak kell determinisztikusnak lennie, nem a speckobol a kodig utnak.
-
kardkovacsi
senior tag
Hogy erted azt hogy minimalis szabadsag van?
Ha fogsz pl. 10 random emberi fejlesztot, odaadod nekik ugyanazt a speckot, akkor 10, bitre azonos megoldassal fognak eloallni?En 20 eve vagyok a szakmaban, a tapasztalatom szerint meg csak az algoritmusok sem lesznek azonosak a megoldasokban, nemhogy a tobbi sallang. Ami azonos lesz, hogy mindben lesznek bugok dogivel.
Ezert nem ertem ezt a determinisztikussag vonalat. Az elkeszult kodnak kell determinisztikusnak lennie, nem a speckobol a kodig utnak.
Igen ebben igazad van, csak egy embernél valahogy determinisztikus a bugok szórása is. Nem fog neked teljesen random kitörölni dolgokat. Bár ha jobban belegondolok volt már olyan hülye kolléga aki de
persze nem ez a jellemző. -
forumpista
aktív tag
Hat, azert en azzal egyetertek, hogy minimalis szabadsag van az adott helyzetre optimalis megoldasra (a tobbit miert kernenk hogy az AI gyartson?). Nyilvan ez a (magas szintu) specifikaciobol kod irasa, plane meglevo termekbe belefejleszteskor.
A speckoig eljutas meg a tudomanyos algo-kutatas az mas teszta, most ipari kornyezetrol beszelunk. -
axioma
veterán
Miert kellene determinisztikusnak lennie?
A determinisztikus mukodes pont a halaluk lenne.Az AI nem a szamitogepet valtja ki, hanem az embert. Es az ember sem determinisztikus.
-
forumpista
aktív tag
El tudom képzelni, hogy van olyan terület, ahol nem okoz problémát a nem determinisztikus működés, pl. a fingó appok piaca... De ennél komolyabb felhasználás esetén ez szerintem no-go. Lásd az utóbbi időkben a windows update problémák. Kritikus infrastruktúrákról meg ne is beszéljünk. Szóval szerintem amíg nem megoldott a determinisztikus működés, addig komolyabb feladatokra nem lesz alkalmas az AI.
-
Ha formalizált nyelven le tudsz írni egy alkalmazást, akkor azt algoritmikusan és determinisztikusan le tudod generálni, mindenféle AI nélkül. Viszont az összes ilyen próbálkozás kérész életű volt, vagy legalábbis széles körben nem lett népszerű soha. Nem véletlenül, nem szeretnek az emberek formalizáltan írni és gondolkodni. Pont ezt küszöböli ki az LLM. Cserébe viszont a nemdeterminizmus megkerülhetetlen.
-
Ha formalizált nyelven le tudsz írni egy alkalmazást, akkor azt algoritmikusan és determinisztikusan le tudod generálni, mindenféle AI nélkül. Viszont az összes ilyen próbálkozás kérész életű volt, vagy legalábbis széles körben nem lett népszerű soha. Nem véletlenül, nem szeretnek az emberek formalizáltan írni és gondolkodni. Pont ezt küszöböli ki az LLM. Cserébe viszont a nemdeterminizmus megkerülhetetlen.
-
Nekem sem tetszik ez az irány, de simán el tudom képzelni, hogy ugyanezt érezték, amikor gépi kód és assembly után megjelentek a magasabb szintű nyelvek. Tulajdonképpen most az AI is egy magasabb szintű fordítóként viselkedik. Az is lehet, hogy idővel megjelennek majd formalizáltabb nyelvek (kifejezés gyűjtemények, amiket az AI egyértelműbben tud értelmezni), amikkel pontosabb specifikációt lehet majd létrehozni.
-
-
Nekem sem tetszik ez az irány, de simán el tudom képzelni, hogy ugyanezt érezték, amikor gépi kód és assembly után megjelentek a magasabb szintű nyelvek. Tulajdonképpen most az AI is egy magasabb szintű fordítóként viselkedik. Az is lehet, hogy idővel megjelennek majd formalizáltabb nyelvek (kifejezés gyűjtemények, amiket az AI egyértelműbben tud értelmezni), amikkel pontosabb specifikációt lehet majd létrehozni.
-
-
Vannak mar tükkök a context méret problémára, pl. Recursive Language Model.
Jó ideig én is nagyon szkeptikus voltam. De pár hete kaptunk Cursor előfizetést, elkezdtem intenzívebben használni, és azt kell mondanom, hogy elég meggyőző. (Még) nem jó mindenre, de pl. komplex kódbázisból információkat kinyerni, unit teszteket írni, stb. nagyon jó.
Valaki a másik topiban belinkelt a múltkor egy interjút, asszem Grady Booch-al, és neki az volt a véleménye, hogy az AI egy következő absztrakciós szint lesz a szofverfejlesztésben. Szóval simán benne van, hogy ezután a spec lesz a single source of truth, és nem a kód...
-
Annyira azert nem nagy, hogy fel kene darabolni normal ugymenet mellett. Jo 10 SQL tabla, par fajlnyi "ORM", max. 100 kod fajl, 100 sor felett szinte semmi fajlonkent. Azert ez alapvetoen meg elegge torpe meret. A program reszei elegge elkulonultek egymastol igy is, ugy terveztem. Viszont a "komponensek" kozotti interface-ek is eleg keplekenyek, mert kb. 2 naponta kell fundamentalisan mas requirementeknek teljesulni. Ez nagyon zold mezo. Es azert az llm is elegge darabonkent halad, tehat igyekszik csak azt tolteni a contextbe, ami eppen kell a kovetkezo lepeshez. A fent leirt meretnel kezdem azt erezni most, hogy kuszkodik picit a modell, ha valami nagyobb atstrukturalast akarok. Nyilvan nem az ilyen kene meg egy Rest api jellegu dolgokra gondolok, az tovabbra is megy neki konnyen, bar pont a tervezes miatt nincs eppen ebben nehezebb dolga. Viszont ha mar azt mondom, hogy valami relacio megis tobb-tobb, nem tobb-egy, akkor ennel a meretnel mar csokken a minoseg. Kissebb meretnel ezek mentek lazabban.
Akkor viszont az egyszerre elvégzett feladat terjedelmét kell kisebb, kevesebb buktatót rejtő lépések sorozatára felbontani amivel ugyanahhoz a célhoz el lehet jutni. És mindegyik lépésnél review-zni hogy mit akar csinálni.
Refaktorálgatásnál nekem is az a tapasztalatom hogy néha közbe kell avatkozni és meglökni a jó irányba mert képes elveszni dolgokban és onnan nem kimozdulni és csak égeti a token-t a semmire.
Egyébként az hogy kezdetektől fogva ráveszed írjon és futasson teszteket az sokat segít. Csak ott meg arra kell figyelni hogy nehogy olyan teszteket kezdjen írni amelyek a fals gondolatmenetét támasztják alá de valójában nem az eredeti követelményt tesztelik
-
Feldarabolnám a projektet több kisebb modulra. Mindegyikhez high level struktúrális leírást generáltatni hogy melyikben mi van, osztályok, metódusok paraméter listája és funkciója, de a kódtörzs nélkül.
Célirányosan csak egy adott modult fejleszteni vele és csak a high level doksikat odaadni neki, hogy az alapján dolgozzon.
Én valahogy így próbálnám.
A való életben is ha növekszik egy projekt ezt szokták csinálni hogy több fejlesztő között párhuzamosan szét lehessen bontani a feladatokat, illetve hogy az egyszerre kezelendő domain komplexitása ne nőjjön a végtelenségig és a többi modult blackbox-ként lehessen kezelni és jól lehessen függetlenül tesztelni. -
Én csinálom tovább a kísérletemet, hogy 2 hete igyekszem mindent codign agenttel megcsináltatni elsőre, aztán addig pofozni, míg jó nem lesz. Ezen a héten csak codex-5.3-at használtam. Alapvetően azt tapasztalom, hogy egy bizonyos komplexitásig elképesztően jól működött a dolog, de pont mára érte el a projekt azt a komplexitási szintet, ahol már a 300K context window be tud telni elég simán, illetve elég furcsa eredmények születnek. Pl. meglevő fájl esetén úgy dönt, hogy inkább nulláról újraír, de kihagy belőle dolgokat. (Persze úgy, hogy szintaktikailag helyes marad, csak épp nem működik, nem csinál semmit.) Illetve képes alapból elég ésszerűtlen absztrakciók irányába elmenni, de ez is inkább a bizonyos méret felett, még elég specifikus iránymutatás mellett is.
Az tény, hogy ez jobb élmény, mint a korábbi modellek, de a szoftverfejlesztők kiváltása még mindig fényévekre érződik. Viszont a hatékonyságnövelő hatása az ennek a modellnek jobban érezhető, mint a gpt-4.1-nek, vagy akár korábbi codexeknek.
-
kardkovacsi
senior tag
Én csinálom tovább a kísérletemet, hogy 2 hete igyekszem mindent codign agenttel megcsináltatni elsőre, aztán addig pofozni, míg jó nem lesz. Ezen a héten csak codex-5.3-at használtam. Alapvetően azt tapasztalom, hogy egy bizonyos komplexitásig elképesztően jól működött a dolog, de pont mára érte el a projekt azt a komplexitási szintet, ahol már a 300K context window be tud telni elég simán, illetve elég furcsa eredmények születnek. Pl. meglevő fájl esetén úgy dönt, hogy inkább nulláról újraír, de kihagy belőle dolgokat. (Persze úgy, hogy szintaktikailag helyes marad, csak épp nem működik, nem csinál semmit.) Illetve képes alapból elég ésszerűtlen absztrakciók irányába elmenni, de ez is inkább a bizonyos méret felett, még elég specifikus iránymutatás mellett is.
Az tény, hogy ez jobb élmény, mint a korábbi modellek, de a szoftverfejlesztők kiváltása még mindig fényévekre érződik. Viszont a hatékonyságnövelő hatása az ennek a modellnek jobban érezhető, mint a gpt-4.1-nek, vagy akár korábbi codexeknek.
-
kardkovacsi
senior tag
Kapsz az elofizeteshez egy csomo tokent, van egy 4 oras limit (4 oranket resetelodik) meg egy heti, ezt mutatja a webes feluleten (settings/usage).
Altalanos hasznalatra siman jo (inkabb a 4 oras limital mint sem a heti).
En most mar a pro-t hasznalom, az 100 euro, az meg sosem fogyott el nekem. De szabadon lehet fel/le valtani a csomagok kozott, szoval erdemes a kicsivel inditani aztan kiderul hogy eleg-e vagy nem.Konkret token szamokat nem tudok, oszinten szolva azt en amugy sem tudom ertelmezni.
-
forumpista
aktív tag
Claude pricing. Gondolkodom, hogy a személyes projektjeimhez előfizetek Claudera. A kérdés, tudja valaki, hogy működik az előfizetés? Van ez a kb 20 dolláros előfizetés amivel lesz Claude-od egyáltalán. Ebben van valamennyi token beleértve? Mert ezen kívül van a 5/25 1M token ár Opusra, Sonnet valamennyivel olcsóbb.
-
kardkovacsi
senior tag
Claude pricing. Gondolkodom, hogy a személyes projektjeimhez előfizetek Claudera. A kérdés, tudja valaki, hogy működik az előfizetés? Van ez a kb 20 dolláros előfizetés amivel lesz Claude-od egyáltalán. Ebben van valamennyi token beleértve? Mert ezen kívül van a 5/25 1M token ár Opusra, Sonnet valamennyivel olcsóbb.
-
É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.Ja igen, még erre akartam reagálni: "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."
Annyira lesz jó a kód, amennyire a prompt-ban megköveteled. Pl. ha csak annyit írsz bele, hogy "Respect clean code principles and try to keep methods at most 10-20 lines long", már sokkal átláthatóbb kódot fog irni, mint sok ember. -
Vannak mar tükkök a context méret problémára, pl. Recursive Language Model.
Jó ideig én is nagyon szkeptikus voltam. De pár hete kaptunk Cursor előfizetést, elkezdtem intenzívebben használni, és azt kell mondanom, hogy elég meggyőző. (Még) nem jó mindenre, de pl. komplex kódbázisból információkat kinyerni, unit teszteket írni, stb. nagyon jó.
Valaki a másik topiban belinkelt a múltkor egy interjút, asszem Grady Booch-al, és neki az volt a véleménye, hogy az AI egy következő absztrakciós szint lesz a szofverfejlesztésben. Szóval simán benne van, hogy ezután a spec lesz a single source of truth, és nem a kód...
-
Catman
aktív tag
Nekünk van Azure Devops-hoz (ha esetleg nem ismered, ez git, ticket kezelő mindennel együtt) MCP szerverünk és a Claude gyönyörűen létrehozza benne a pull requestet, lehet vele reviewztatni. Már előtte megnézetem vele a kódom mielőtt feladom a kollégáknak a PR-t, úgyis ezt csinálnák ők is
Fog is benne bugokat, tegnap valami apró logikai hibát is megtalált. -
kardkovacsi
senior tag
É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.Nekünk van Azure Devops-hoz (ha esetleg nem ismered, ez git, ticket kezelő mindennel együtt) MCP szerverünk és a Claude gyönyörűen létrehozza benne a pull requestet, lehet vele reviewztatni. Már előtte megnézetem vele a kódom mielőtt feladom a kollégáknak a PR-t, úgyis ezt csinálnák ők is
Fog is benne bugokat, tegnap valami apró logikai hibát is megtalált. -
kardkovacsi
senior tag
Vannak mar tükkök a context méret problémára, pl. Recursive Language Model.
Jó ideig én is nagyon szkeptikus voltam. De pár hete kaptunk Cursor előfizetést, elkezdtem intenzívebben használni, és azt kell mondanom, hogy elég meggyőző. (Még) nem jó mindenre, de pl. komplex kódbázisból információkat kinyerni, unit teszteket írni, stb. nagyon jó.
Valaki a másik topiban belinkelt a múltkor egy interjút, asszem Grady Booch-al, és neki az volt a véleménye, hogy az AI egy következő absztrakciós szint lesz a szofverfejlesztésben. Szóval simán benne van, hogy ezután a spec lesz a single source of truth, és nem a kód...
-
É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. -
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. -
kardkovacsi
senior tag
-
forumpista
aktív tag
A Contextet könnyen lehet azért felejti el, mert túl nagy lesz a context window és elkezdi vágni. Elvileg 200e token a window mérete ezért ha azon túlcsordul a régebbi elemeket kidobja belőle.
Ezért érdemes egyrészt mindig új "lapot" nyitni. A VS kód talán meg is mutatja mekkora az aktuális context mérete pl. egy Copilot esetén. -
kardkovacsi
senior tag
-
Begi
senior tag
Claude how to, használd saját felelősségre:
1, csinálj egy claude.md fájlt, írd le benne nagy vonalakban hogy mit vársz általánosságban, hogyan viselkedjen, mi legyen.
2, első lépésként mindig térképeztesd fel vele a projektet amin dolgoznia kell (vagy azt a részét a projektnek) és ezt mentesd is el vele a "memóriába" (egy fájlt fog írni). Ez azért kell hogy ne fogalmatlanul vágjon bele a feladatba és másnap is tudja folytatni
3, A feladatot mindig terveztesd meg vele először, majd reviewztasd is meg a terved vele. Ha szerinte már oké, reviewzd meg te is.
Ha a feladat nagyobb, mindig utasítsd hogy bontsa kisebb, áttekinthetőbb, logikai implementációs fázisokra. A tervet ki is irathatod pl. md fájlba, és akár másik agentnek is oda lehet adni.
4, ha a terv kész, elindíthatod vele az implementálást a terv alapján. Explicit mond neki hogy fázisonként hajtsa végre, és minden fázis végén álljon meg és várjon a jóváhagyásodra.
5, amikor egy fázis elkészült, reviewztasd meg magával. Mindig írass vele unit teszteket is.
Ha szerinte már jó, reviewzd meg te is (ide jöhet még dev test stb is akár)
6, Ha nem jó, akkor pontosítsd a promptot, vagy amennyiben komolyabb terv hiba derül ki, goto 3.
7, commitoltass vele logikai egységeket (célszerű fázisonként legalább)
8, mentesd el vele az aktuális munka összesítését a memóriába (így másnap tudni fogja hol tartott, mi történt korábban)Claude.md példa részlet:
- **Modern Syntax:** Always use the latest stable versions (e.g., Python 3.10+, Java 17 patterns).
- **Efficiency:** Propose the most stable, performant, and cost-effective solutions.
- **Validation:** If a task is ambiguous or information is missing, ask for clarification instead of guessing.
- **Anti-Monolith:** Do not dump large amounts of code into single files. Maintain a clean, modular file structure.
- **Clean Code:** Adhere to SOLID principles and DRY (Don't Repeat Yourself).
- **Naming:** Use descriptive, English names for all identifiers.
- **File Size Limit:** Keep individual code files under 1000 lines. Split larger files into smaller, focused modules.
- **Code Optimization:** Always optimize code for performance and readability when possible (reduce complexity, eliminate redundancy, improve algorithms).
## Testing Requirements
- **Coverage Target:** Aim for minimum 80% code coverage on business logic.
- **Mandatory Tests:** New features must include unit tests. Bug fixes must include regression tests.
A fentiek csak egy példák egy adott felhasználásra, nyilván van még egy csomó más is, én is még csak tanulom, meg a modellek is folyamatosan fejlődnek, az a használat ami ma jó, lehet hogy fél év múlva már elavult lesz.
Valami hasonlóval dolgozok én is. Másnál is produkál olyat, hogy néha emlékeztetni kell rá, hogy ehhez tartsa magát, mintha elfelejtené a context-et. -
kardkovacsi
senior tag
Van egyébként már Mestereséges intelligencia topik. Bár az tény hogy az elég általános a tematikája és nem ennyire kódolásra kihegyezett szakmai.
Én egyébként Antigravity-zek, és olyami módon megyek neki mint forumpista írja. (skill-ek, workflow-ban megfogalmazott gyakori fejlesztési feladatok, coding_rules.md-ben szigorú kódolási irányelvek, megtámogatva szinkronban tartott linter ellenőrzésekkel és tesztekkel, illetve van egy guidelines-t a projek madártávlati struktúrájáról, legtöbb workflow-ban építek ezekre a megfogalmazott alapokra).
-
forumpista
aktív tag
-
tomazin
veterán
Claude how to, használd saját felelősségre:
1, csinálj egy claude.md fájlt, írd le benne nagy vonalakban hogy mit vársz általánosságban, hogyan viselkedjen, mi legyen.
2, első lépésként mindig térképeztesd fel vele a projektet amin dolgoznia kell (vagy azt a részét a projektnek) és ezt mentesd is el vele a "memóriába" (egy fájlt fog írni). Ez azért kell hogy ne fogalmatlanul vágjon bele a feladatba és másnap is tudja folytatni
3, A feladatot mindig terveztesd meg vele először, majd reviewztasd is meg a terved vele. Ha szerinte már oké, reviewzd meg te is.
Ha a feladat nagyobb, mindig utasítsd hogy bontsa kisebb, áttekinthetőbb, logikai implementációs fázisokra. A tervet ki is irathatod pl. md fájlba, és akár másik agentnek is oda lehet adni.
4, ha a terv kész, elindíthatod vele az implementálást a terv alapján. Explicit mond neki hogy fázisonként hajtsa végre, és minden fázis végén álljon meg és várjon a jóváhagyásodra.
5, amikor egy fázis elkészült, reviewztasd meg magával. Mindig írass vele unit teszteket is.
Ha szerinte már jó, reviewzd meg te is (ide jöhet még dev test stb is akár)
6, Ha nem jó, akkor pontosítsd a promptot, vagy amennyiben komolyabb terv hiba derül ki, goto 3.
7, commitoltass vele logikai egységeket (célszerű fázisonként legalább)
8, mentesd el vele az aktuális munka összesítését a memóriába (így másnap tudni fogja hol tartott, mi történt korábban)Claude.md példa részlet:
- **Modern Syntax:** Always use the latest stable versions (e.g., Python 3.10+, Java 17 patterns).
- **Efficiency:** Propose the most stable, performant, and cost-effective solutions.
- **Validation:** If a task is ambiguous or information is missing, ask for clarification instead of guessing.
- **Anti-Monolith:** Do not dump large amounts of code into single files. Maintain a clean, modular file structure.
- **Clean Code:** Adhere to SOLID principles and DRY (Don't Repeat Yourself).
- **Naming:** Use descriptive, English names for all identifiers.
- **File Size Limit:** Keep individual code files under 1000 lines. Split larger files into smaller, focused modules.
- **Code Optimization:** Always optimize code for performance and readability when possible (reduce complexity, eliminate redundancy, improve algorithms).
## Testing Requirements
- **Coverage Target:** Aim for minimum 80% code coverage on business logic.
- **Mandatory Tests:** New features must include unit tests. Bug fixes must include regression tests.
A fentiek csak egy példák egy adott felhasználásra, nyilván van még egy csomó más is, én is még csak tanulom, meg a modellek is folyamatosan fejlődnek, az a használat ami ma jó, lehet hogy fél év múlva már elavult lesz.
-
forumpista
aktív tag
-
kardkovacsi
senior tag
Úgyh nekem ez eléggé béta állapot.
Mondom akkor jöhet a Max, úgyhogy előfizettem a 200€-sra...
), leírta h na persze, legjobbak tudnak talán +30%-ot 
Új hozzászólás Aktív témák
- GARANCIÁLIS LEMEZES PLAYSTATION 5 SLIM CFI-2116
- NAGYKER ÁR!Sosemhasznált! HP OmniBook 5 Flip i5-1334U 8GB 512GB 14" FHD+ áthajtós-érintős Gar.: 1 év
- Macbook Pro 14" A2442 2021 M1 Pro 32/1TB Silver
- Dell Latitude 9420 i5-1145G7 14" FHD+ 16GB 512GB 1 év garancia
- Macbook Pro 14" A2442 2021 M1 MAX 32/512 Astro
- Keresünk iPhone 14/14 Plus/14 Pro/14 Pro Max
- Fotó állvány eladó
- HP Zbook 15u G3 - 15,6" FHD kijelző, i7 6500U, 16GB RAM, 256GB SSD, FirePro W4190M 2GB, számla
- Kingston 32GB DDR4 3200MHz KSM29ED8/32ME ECC Szerver RAM
- BESZÁMÍTÁS! LG Ultrawide 34UM69G-B IPS 75Hz 5ms monitor garanciával hibátlan működéssel
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest