AI a SonarQube-ban: mit jelentenek az új agentic funkciók a fejlesztők számára?

2026.10.02

Az AI-alapú fejlesztőeszközök rövid idő alatt a napi fejlesztési munka részévé váltak. A GitHub Copilot, a Claude Code vagy a Codex ma már nemcsak néhány sort egészít ki, hanem komplett funkciókat ír, refaktorál, teszteket készít, hibát keres és egyre több esetben több lépésből álló fejlesztési feladatokat is végigvisz.

Ezzel együtt egyre fontosabb kérdés lett, hogy mi történik az AI által előállított kóddal azután, hogy elkészült.

A gyorsabb kódgenerálás önmagában nem oldja meg a minőségi, biztonsági vagy karbantarthatósági problémákat. Sőt, nagyobb fejlesztési sebesség mellett ezek könnyebben fel is halmozódhatnak, ha nincs megfelelő ellenőrzési réteg a folyamatban.

A SonarQube új AI- és agentic funkciói alapvetően erre a problémára próbálnak választ adni. A Sonar nem saját kódoló AI-t akar építeni a Copilot vagy a Claude Code helyett. Inkább azt a réteget erősíti, amely eldönti, hogy az elkészült kód megfelel-e a projekt minőségi és biztonsági követelményeinek.

AI CodeFix: a hiba mellé már javítási javaslat is érkezik

A SonarQube klasszikus működése egyszerű: lefut az elemzés, a rendszer megtalálja az issue-t, megmutatja, hol van a probléma, és leírja, miért kellene javítani.

Az AI CodeFix ezt egészíti ki azzal, hogy az adott issue-hoz konkrét kódmódosítást is tud javasolni.

Ez nem ugyanaz, mint amikor egy általános AI-asszisztensnek bemásolunk egy hibaüzenetet. A kiindulópont itt maga a SonarQube által azonosított probléma, vagyis a javítás mögött már ott van egy statikus elemzési eredmény és a hozzá tartozó szabály.

Ez főleg az ismétlődő vagy viszonylag jól körülhatárolható problémáknál lehet hasznos. Ha például több száz hasonló maintainability issue található egy nagyobb rendszerben, a fejlesztőnek nem feltétlenül kell mindegyiket nulláról értelmeznie és kézzel átírnia.

A SonarQube Server 2026.5-ben a vállalati AI-kapcsolatok központilag is kezelhetők, és a szervezet saját modell-szolgáltatóját is használhatja. Ez különösen olyan környezetben érdekes, ahol nem mindegy, hogy a forráskód milyen külső szolgáltatáshoz jut el.

MCP: amikor az AI agent nem csak a repository-t látja

Az MCP-integráció ennél valamivel fontosabb változás.

A Model Context Protocol segítségével egy AI coding agent közvetlenül hozzáférhet a SonarQube bizonyos információihoz. Ez azt jelenti, hogy például egy Claude Code- vagy Cursor-alapú agent nemcsak a forráskódot látja, hanem a SonarQube által feltárt issue-kat és más elemzési eredményeket is fel tudja használni.

A különbség a gyakorlatban jelentős.

A hagyományos folyamatban az AI megírja a kódot, a fejlesztő commitol, majd később a CI pipeline-ban derül ki, hogy a SonarQube mit talált.

MCP-vel az elemzés eredménye közvetlenebbül visszakerülhet az agenthez, amely már a fejlesztési folyamat közben reagálhat rá.

Ez csökkentheti azt a felesleges kört, amikor az agent elkészít egy megoldást, a CI elutasítja, majd a fejlesztő manuálisan visszaadja ugyanazt a problémát az AI-nak.

Vortex: több kontextus a coding agentnek

A nagyobb kódbázisoknál az AI coding agentek egyik legnagyobb problémája nem feltétlenül maga a kódgenerálás, hanem a megfelelő kontextus megtalálása.

Egy nagy monolitban vagy több tucat szolgáltatásból álló rendszerben nem triviális kérdés, hogy egy adott osztályt mi használ, hol található egy interfész implementációja, melyik komponenssel kell együttműködni, vagy milyen projekt-specifikus szabályok vannak érvényben.

A Sonar Vortex erre a problémára épül.

A célja, hogy a coding agent jobban tudjon navigálni a kódbázisban, és olyan információkat kapjon, amelyek alapján kevésbé „vakon” próbál meg változtatásokat végrehajtani.

Ez fejlesztői szempontból valószínűleg fontosabb, mint elsőre hangzik.

Az LLM-ek sokszor nem azért készítenek rossz megoldást, mert nem tudják megírni a szükséges kódot, hanem azért, mert nem látják jól a teljes rendszer összefüggéseit. Egy technikailag helyes megoldás könnyen lehet architekturálisan rossz vagy egyszerűen nem illeszkedik a projekt meglévő mintáihoz.

A Vortex ezt a problémát próbálja csökkenteni azzal, hogy az agent számára relevánsabb projektkontextust biztosít.

Remediation Agent: a Sonar issue javítása is automatizálható

Az AI CodeFix és a Remediation Agent között lényeges különbség van.

Az AI CodeFix javítási javaslatot ad. A Remediation Agent ezzel szemben már egy teljesebb javítási folyamatot hajthat végre.

A kiindulópont itt is egy SonarQube issue. Az agent elkészíti a módosítást, majd a módosított kód újra átesik a SonarQube ellenőrzésén.

Ez azért fontos, mert az AI által generált javítás önmagában még nem bizonyítja, hogy a probléma valóban megszűnt.

A fejlesztési folyamat szempontjából a hasznos rész éppen az, hogy a javítás után ismét lefut az ellenőrzés.

Nagyobb technikai adósság esetén ez különösen érdekes lehet. Egy rendszerben sokszor nem a problémák bonyolultsága jelenti a legnagyobb költséget, hanem az, hogy több száz vagy több ezer kisebb issue-t kell egyenként kezelni.

Az ilyen feladatok egy része jó jelölt lehet automatizált remediationre.

Hunter Agent: más típusú security problémák keresése

A Hunter Agent már más területet céloz.

A klasszikus statikus kódelemzés nagyon hatékony ott, ahol egy sérülékenység meghatározott kódmintákból vagy adatfolyamokból felismerhető. Sok biztonsági probléma viszont nem ilyen.

Egy hibás jogosultságkezelés például nem feltétlenül abból adódik, hogy egy adott függvény rosszul van megírva. Lehet, hogy külön-külön minden komponens helyes, de a teljes folyamatból kimarad egy ellenőrzés.

Ugyanez igaz bizonyos authentication hibákra vagy business logic sérülékenységekre.

A Hunter Agentet a Sonar éppen ezekre az összetettebb problémákra pozicionálja.

Itt az AI szerepe az, hogy nagyobb kontextust vizsgáljon, és olyan összefüggéseket keressen, amelyeket egy hagyományos szabályalapú elemzés nehezebben találna meg.

Fontos, hogy a Hunter nem váltja ki a hagyományos SAST-ot. Inkább egy további elemzési rétegként jelenik meg mellette.

Hol kapcsolódik mindehhez az Advanced Security?

Az Advanced Securityt érdemes külön kezelni az AI-funkcióktól.

A SonarQube Advanced Security elsősorban nem generatív AI-termék, hanem a security elemzés kiterjesztése.

Az egyik fontos eleme az SCA, amely a projekt külső és open source függőségeit vizsgálja. Ide tartozik többek között az ismert sérülékenységek, transitive dependency-k, licencproblémák és az SBOM kezelése.

A másik fontos terület az Advanced SAST, amely mélyebb elemzést végezhet a saját kód és a külső könyvtárak közötti adatfolyamokon.

Ez más problémát old meg, mint a Hunter Agent vagy a Remediation Agent.

Az Advanced Security célja az, hogy minél pontosabban feltérképezze a tényleges biztonsági kockázatokat. Az AI-agentek ezzel szemben további kontextust értelmezhetnek, javításokat készíthetnek vagy olyan problémákat kereshetnek, amelyeknél a klasszikus statikus elemzés önmagában nem elég.

A két irány ezért inkább kiegészíti egymást.

Hogyan változhat ettől a fejlesztési folyamat?

A változás valószínűleg nem egyik napról a másikra történik majd.

A SonarQube eddig sok csapatnál főként a CI/CD pipeline egyik ellenőrzési pontja volt:

commit, build, SonarQube analysis, Quality Gate.

Az agentic fejlesztésben viszont az ellenőrzés közelebb kerülhet magához a fejlesztési folyamathoz.

Egy coding agent például elkészít egy módosítást, lekéri vagy megkapja a SonarQube visszajelzését, kijavít bizonyos problémákat, majd ismét ellenőrzi az eredményt. A fejlesztő ehhez képest már egy jóval előrébb tartó állapotot kap review-ra.

Ez nem jelenti azt, hogy a human code review eltűnik.

Inkább arról van szó, hogy érdemes elkülöníteni azokat a feladatokat, amelyekhez valóban fejlesztői döntés kell, azoktól, amelyeket a gép megbízhatóan képes felismerni vagy akár javítani.

A review idejét jobb architekturális, üzleti logikai vagy biztonsági kérdésekre fordítani, mint például több tucat egyforma code smell kézi javítására.