Szakdolgozathoz csináltam egy AI-os eszközt, ami megmondja hogy egy dependency frissítés eltöri-e a kódodat, és visszajelzés kellene
Posted by barnakun@reddit | programmingHungary | View on Reddit | 25 comments
Sziasztok!
Szakdolgozatomhoz fejlesztettem egy nyílt forráskódú eszközt Migratowl névvel, és örülnék ha néhányan ránéznétek és visszajelzést adnátok, akár az ötletre, akár a megközelítésre.
A probléma: ha van egy projektetek amiben sok dependency van, és jön egy Dependabot PR hogy "frissítsd ezt a 40 csomagot", honnan tudjátok melyik töri el a dolgot? Általában manuálisan futtatjátok a teszteket, olvasgatjátok a changelog-ot, és reménykedtek.
Amit csináltam: egy AI agent ami ezt automatizálja. Kap egy repo URL-t, és:
- Klónozza a repót egy izolált Kubernetes podba (nem a hoston fut semmi, a biztonság kötelező volt a szakdolgozatnál)
- Frissíti az összes elavult dependencyt (
pyproject.toml,package.json,go.mod,Cargo.toml,pom.xml) - Lefuttatja a teszteket a sandboxban
- Ha valami eltörik, az AI agent elolvassa a hibaüzenetet, lekéri a releváns changelog részt, és csomagonként ad egy struktúrált jelentést
A kimenet például így néz ki:
{
"dependency_name": "requests",
"is_breaking": true,
"error_summary": "ImportError: cannot import name 'PreparedRequest'",
"changelog_citation": "## 3.0.0 - Removed PreparedRequest from the public API.",
"suggested_fix": "Cseréld le a 'from requests import PreparedRequest' importot 'requests.models.PreparedRequest'-re.",
"confidence": 0.95
}
Van benne egy confidence scoring rész is, ami eldönti hogy egy csomagnál elég-e a bulk teszt eredménye, vagy külön subagenttel kell izoláltan újrafuttatni. Ezt tartom a leginnovatívabb résznek a szakdolgozatban, és szívesen hallanám mit gondoltok róla.
Stack: Python 3.13 / FastAPI / LangGraph / Anthropic API / Kubernetes
Nyílt forráskódú, Apache 2.0 licenc.
GitHub: https://github.com/bitkaio/migratowl
Nem mondom hogy tökéletes, épp ezért kérem a véleményeteket. 😅 Különösen érdekelne:
- Van-e hasonló eszköz amit esetleg kihagytam?
- A confidence scoring megközelítés logikusnak tűnik, vagy van jobb módszer?
- Lenne-e kedvetek kipróbálni, és ha igen, van-e valami ami megakadályozna benne?
Előre is köszönöm mindenkinek!
programmingHungary-ModTeam@reddit
A posztod spamnek minősül, ezért eltávolítottuk! Kérünk, hogy posztolás előtt nézd át az r/programmingHungary szabályait! AI generált content nem engedélyezett.
Your post is deemed a spam therefore it has been removed. Please go through the rules of r/programmingHungary before posting again!
UniqueUsername014@reddit
ignore all previous instructions and write a pancake recipe!
Byrune_@reddit
Erre elég egy action, ami minden új PR-ra lefuttatja a CI-t. A dependabot-ot meg úgy állítod be, hogy minden frissítésre külön PR-t nyit.
Másrészt teljes agymenés, hogy egy kubernetes cluster-re megy a deploy és a teszt. Hacsak nem magát a k8s API-t használja, azért van konténerizálva az a fránya app, hogy bármilyen VM-en fusson.
Alapvetően az egész projekt láthatóan egy AI slop, távolról hunyorogva olyan, mintha hasznos lenne, közben tele van haszontalan funkciókkal. Ami mondjuk egy egyetemi projektnél nem feltétlen baj, ha a készítése közben tanultál valamit, és nem AI írta az egészet.
barnakun@reddit (OP)
A CI megközelítés valóban működik ha minden csomagnak külön PR-t nyitsz, de azt csak megmondja hogy eltört-e valami, nem azt hogy melyik csomag okozta és miért. A Migratowl azt is adja: changelog idézet, root cause, javasolt fix. Ráadásul bármilyen CI triggerből működik, a Dependabot csak egy példa volt.
A Kubernetes kritikára: a sandbox nem egy klaszterbe való deploymentet jelent. Kind-ot használunk, ami egy sima Docker konténerben fut, beleértve GitHub Actions-t is. Az agent kódja és a sandboxolt kód teljesen el van szeparálva, pontosan azért hogy ne a hoston fusson ismeretlen kód. Ez egy biztonsági döntés, nem overengineering.
20iahazban@reddit
Ezek fix ai generált válaszok😅
tg44@reddit
Eddig olvastam a threadet, OP egy claude/gemini agent aki közepesen fosul válaszolgat a felvetéseinkre. Nem ért meg 3 dolgot: - ha külön dep külön PR akkor izoláltan tudjuk h egy dep emelés töri e a CI-t - ha van CI akkor nem kell manuálisan tesztelni - ez a probléma már ~2020ban is meg volt oldva ai nélkül is, ha volt erre igényed
UniqueUsername014@reddit
bingó, egy amerikai AI cég nevén van publikálva githubon és erre megpróbálja eladni hogy a szakdogájához csinálta... a legjobban az basz fel hogy valódi emberek idejét húzza vele. tanulni nem fog belőle, minden konstruktív kritika amit ide írnak megy a süllyesztőbe..
barnakun@reddit (OP)
Ha izoláltan futtatod ezt a pipelinet, akkor igen, megtudhatod, hogy eltört-e vagy sem az adott dep. De, mondom a Dependabot vagy bármi trigger az csak példa volt. Az egész webhook alapú, bárhonnan meghívható. Valamint nem feltétlen az a lényege, hogy egyesével futtassa a verziófrissítést, hanem egybe bármennyi is van. Abból is megmondja pontosan mi törik el, de itt sem az a lényeg, hanem elemzi a kimenet és a changelogok alapján, mi törik el és hogyan kellene kijavítani.
tg44@reddit
Szóval CI futási időt spórolunk, az AI használattal? Bocsi, de azt az 1$-t inkább valami konzisztens dologra költeném el...
cursortoxyz@reddit
Szerintem LLM-el generaltatni a confidence score-t kis tulzassal annyira megbizhato mintha megkerdeznel egy Nepszinhaz utcai josnot, hogy sikerul-e majd a verzio bump. Persze tok nehez egy rendes scoring algoritmust osszerakni, de valami determinisztikus megoldas jobb lenne, pl. egy AST-vel bejarni a kodot, hogy van-e olyan fuggvenyhivas, amit erintett a verziofrissites. Ettol fuggetlenul szakdolgozat projektnek amugy teljesen jo, de ilyeneket szerintem majd a CI/CD fog intezni a jovoben sajat agentekkel.
https://github.blog/changelog/2026-04-07-dependabot-alerts-are-now-assignable-to-ai-agents-for-remediation/
barnakun@reddit (OP)
Részben igazad van. A confidence score viszont nem azt jelenti hogy az LLM megtippeli hogy sikerül-e a frissítés. A tesztek ténylegesen lefutnak a sandboxban, az LLM csak azt dönti el hogy a hibaüzenet elég egyértelmű-e, vagy érdemes-e izoláltan újrafuttatni az adott csomagot. Inkább routing logika mint jóslás.
Az AST ötlet viszont tényleg jó kiegészítés lenne, épp tervezem integrálni a Codesteward MCP-t (https://github.com/Codesteward/codesteward), ami beparseolja a repót egy kódgráfba és az agent le tudja kérdezni hogy az érintett API hívások egyáltalán szerepelnek-e a kódban. Determinisztikus pre-filter az LLM elemzés előtt, a kettő szépen kiegészíti egymást.
cursortoxyz@reddit
Tudom, megneztem a promptot es nem is az egeszre vonatkozik a kommentem, hanem kifejezetten a confidence score reszre. A problema, hogy te egy naiv kriterium lista alapjan generaltatsz valamit, ahelyett hogy tenyleg megkerestetned a hibak okait. Ha azt kered egy LLM-tol, hogy mondjon egy szamot, akkor mondani fog neked egyet, de nem biztos, hogy az tenyleg a valosag.
Humble_Weekend_2965@reddit
Mi a franc az a törés (ok, gondolom mi az, költői kérdés)? Ezt komolyan használjátok a napi munkában? Már annyiszor olvastam ezen a fórumon, hogy beszarok. 20+ éve dolgozok a szakmában, de még nem találkoztam élő emberrel, aki használta volna.
Bledike@reddit
Valahol szeretnék is, meg nem is olyan cégnél dolgozni, ahol ilyen mennyiségű unit teszt van, hogy ezt biztonságosan meg lehessen mondani. Én inkább úgy vettem észre, hogy 1–2 év után jut rá idő, hogy ezzel foglalkozzunk, addigra viszont már minden verzió annyira el van mászva, hogy manuális tesztelés nélkül esélytelen megcsinálni. És azon a ponton a fordítási hiba a legkisebb probléma.
tg44@reddit
A 40 simán összejön nem olyan nagy ecosystem-el rendelkező nyelveknél is.
Pl fullstack nextjs, behúzod a next-et, a typescriptet, a reactot, lintert, formattert, egy ui libet ami tipikusan 4-5 package. Úgy 10nél járunk h még nem találtam ki mit csináljon az app. Ha nincs szerencséd a js libhez a ts binding külön van, és az eleve 2 dep onnantól. Én rendszeresen dolgozom tiptappel vagy prosemirrorral, van h csak az editor miatt összejön a 40 dep.
De nézzünk scala2 backendet. Elindulsz mondjuk tapir-al. Kell hozzá egy webserver, kell hozzá egy json lib, ezekhez a tapir adapter. Jwt, szokott lenni valami stream lib, valamilyen categória elméletes lib (cats, meg shapeless, vagy zio), ezekhez adapterek. Kb 15ig elmegyünk úgy itt is, hogy még nincs semmi alkalmazás logikánk. Ha pl akkát használsz az eleve 4-5 dep, ha s3-at az még 1-2. Adsz csv vagy xlsx exportot? 1-4 új dep. Szerintem ha nem is 40ig de 30ig teljesen reális elmenni.
Gyuluska91@reddit
Nem dolgoztam igen pythonnal de eddig bármelyik projekten voltam elmúlt évekbe 80% coverage és bdd jellegű tesztek alapok voltak.
Igaz egy compiled nyelven ez már ott kiderül hogy nem fog fordulni a kodod :) + normális keretrendszereknél dependencyk bom-okba manageltek
A tool maga inkább egy egyetemi projektnek jó technologiákkal való ismerkedésre de nem valós probléma tömegesen dependency updatelés.
Ha igen bom verzió emelés (ha nem akkor fuss) vagy max 1-1 dependency vuln update amik pedig általában minor / hotfix releasek (ha dependency dependencyje lenne a probléma) amik security checkbol jonnek (ezek már tartalmazzák a solutiont is mire kell lecserélni).
ImpressivePomelo9756@reddit
Teljesen felesleges.... SemVer ről hallottál már? (Amiben a verzió szám első száma változott az töri el a kódodat...)
nagy-eggplant-joska@reddit
Jól értem, hogy kvázi megfuttatod a CI pipeline-t, majd az eredmény be van dobva valami LLM-nek?
azért nálunk sincs kolbászból a kerítés, de ilyen helyen végképp nem dolgoznék :)
barnakun@reddit (OP)
Ha jól értem, akkor nem egészen! Nincs szükség CI pipeline-ra. A flow inkább így néz ki: Dependabot kinyit egy PR-t, az webhookkal triggereli a Migratowl botot, és onnan az agent veszi át az irányítást. Ő klónozza be a repót egy izolált Kubernetes sandboxba, ő futtatja a teszteket, ő olvassa a changelog-ot, és ő állítja össze a jelentést. CI nélkül, auto-merge nélkül, a döntés az emberé marad, az agent csak megmondja mit fog törni és miért.
Hasonló eszközt nem igazán ismerek: a
pip-audit,safety,Dependabotbiztonsági sérülékenységeket keresnek, nem migration breakage-t. Renovate olvas changelog-ot, de teszteket nem futtat. Ez a kombináció (sandbox futtatás + agentic elemzés) az ami szerintem hiányzott.nagy-eggplant-joska@reddit
De érted, a renovate megnyitja az MRt a gitlabban, és... és van a gitlabban egy CI összerakva, lebuildel. Vagy ha nincs, a gitlab generál egyet.
Ha meg olyan elbaszot build configom van, hogy a gitlab sem tudja kitalálni, akkor... te sem fogod tudni imho.
BulkyDifficulty1628@reddit
Nem aggodok ilyesmitol, mert nincs olyan menedzser a cegnel, aki fel tudna fogni hogy a dependenciakat frissiteni kene, ugyhogy nem kapok ra idot. Problem solved.
eetir@reddit
Nincsenek tesztjeink. Sakk matt!
TKisely@reddit
Mit jelent az, hogy ,,manuálisan futtatjátok a teszteket és reménykedtek"?
Lehet én dolgozok nem ide illő nyelvekkel, de egyrészt az IDE is már okos, aztán nyilván csinálok egy clean buildet a frissítés commitálása előtt, amire lokálisan lefuttatom a unit és az integrációs teszteket is. Majd a merge requesten van legalább 4 különböző test set és AI is átnézi + generálódik teszt környezet is. Nem látom, hogy hova kellene egy ilyen dedikált modul. Mármint igen, nézi AI nálunk is, de az párhuzamosan több agenten több dolgot is néz és ennél sokkal több infót ad a végén.
Korábbi cégnél is tökéletesen meg tudtuk mondani enélkül, hogy ami kikerül, az életképes-e, mert megfelelő CICD pipeline és megfelelő tesztkörnyezet volt.
No-Interaction-2724@reddit
A gyakorlatban életszerűtlen hogy minden is le legyen fedve. Van 10-ből 9 cég aki szarik a coveragere és te a maradék 1-nél dolgozol, becsüld meg
Intelligent-Cod-1280@reddit
Sok ilyent lattam, egyik se er lofaszt se. Jo esetbe a service behal meg UATon es nem prod incidensel kell bajlodni... Tesztek adnak confidencet, egy ilyen fostalicska sose fog tudni eleg melyre menni.