GPT 5.5 vs Claude Opus 4.7: melyik talál meg több hibát a kódbázisomban?

Szerettem volna letesztelni, hogy mit is tud az új GPT 5.5, viszont be kell vallanom, hogy annyira jók már a modellek, hogy nem érzem jelenleg, hogy mi lenne az a szűk keresztmetszet ami annyira szorít a mindennapi munkában, hogy alig várom, hogy megjelenjen egy új model, hátha az már meg tudja oldani ezt a bizonyos problémát. Így azt tettem amit mindenki tenne egy ilyen helyzetben: tanácsot kértem a konkurenciától. "Szeretném letesztelni, hogy mire is képes az új GPT 5.5! Mondj nekem 3 olyan felhasználási területet és nagyon konkrét feladatot amivel jól lehet szemléltetni a határait és képességeit. Fontos, hogy ne olyan nehezet mondj amit egészen biztosan semmilyen AI nem tud megoldani, és ne is olyan egyszerűt amit biztos, hogy elvégez. Olyan feladatokat szeretnék amin jól ki tudom próbálni a technológia jelenlegi állapotát."

A Claude javaslatára fogom az új GPT 5.5-öt és ráengedem az egyik hobby projektem repójára, és ott keressen hibákat és suboptimálisan kialakított dolgokat. Ehhez a Codex appot használom, hogy teljesen autentikusak legyünk.

Próbaképpen megteszem ugyanezt az Opus 4.7-tel is, Claude Code-on keresztül. A teszt alanya

A projekt a Gymlio, egy edző-kliens kapcsolatra épülő fitness app. Expo SDK 54 + React Native, Supabase háttérrel. A projekt abszolút kezdeti fázisban van, az első pár fontosabb funkció működget benne, nincs kész, nincsenek valódi felhasználók vagy tesztelők. Ha számszerűsíteni akarnánk azt mondanám hogy kb 60%-on van jelenleg. Pont az a fajta kódbázis tehát, ahol az ember szeretné tudni, hogy mi az amit eddig figyelmen kívül hagyott, hiszen a fejlesztés első felében különösen egy hobby projekt esetében inkább a tempó és a kísérletezésé a főszerep.

Így ez egy tökéletes projekt a modelek tesztelésére, mert arra számítok, hogy számtalan hiba, biztonsági rés és befejezetlen gondolat lesz még a forráskódban.

Mindkét modellnek pontosan ugyanazt a feladatot adtam: nézze át a teljes repót, és listázza a hibákat, biztonsági problémákat, suboptimális megoldásokat.

"Nézd át alaposan a rendszert, az egész kódot és keress benne hibákat, hiányosságokat, fejlesztendő dolgokat. Fontos, hogy mindent összefüggésében értelmezz, egyben kell látnod az appot, a backendet, az adatbázist az esetleges 3rd party integrációkat, így egyben kell értelmezni a problémákat. Minden találatot amid van (legyen minél több!) rendezd kategóriákba sürgősség szerint, mindegyikre tegyél időkalkulációt hogy szerinted melyiket mennyi idő megoldani. Az egész eredményről egy nagyon egyszerű nagyon jól átlátható eredményt készíts amit le lehet tenni egy vezető asztalára és ő is érteni fogja hogy mik a next step-ek és miért!" Az eredmények első ránézésre A GPT 5.5 egy elegáns, vezetői összefoglaló stílusú dokumentumot adott vissza. Kategorizált táblázatok, P0-P3 prioritások, óra/nap becslések (időbecslésekben még mindig borzalmasak ezek a modelek, érthető okokból), kockázati területek, konkrét cselekvési terv. Összesen 30 körüli tételt sorolt fel.

Az Opus 4.7 ezzel szemben egy 13 oldalas, részletes technikai auditot készített. Pedig kifejezetten kértem, hogy egyszerű vezetői összefoglaló legyen a végeredmény. Konkrét fájlok, sorszámok, kódrészletek, javítási javaslatok kódszinten. Architekturális megfigyelések. Külön becslések minden tételhez, és összesített költség-becslés euróban. Itt 39 tételt találtam.

Nyilvánvaló, hogy a két output jellege más, és az is várható volt, hogy lesz átfedés. De engem az érdekelt, hogy melyik talál olyan dolgokat amit a másik nem. Amit csak a GPT 5.5 talált meg Itt jött az első meglepetés: a GPT 5.5 erőssége nem ott volt ahol elsőre vártam. A konfigurációs és deployment-szintű kockázatokra sokkal érzékenyebb volt, mint az Opus.

Konkrétan:

P1 szinten említette az auth hardening hiányát: nincs email confirm, nincsenek jelszókövetelmények, nincs captcha. Ezt az Opus auditja meg sem említette, pedig nyilvánvaló kockázat éles használatra. Hasonlóan kiszúrta, hogy az OAuth deep link konfiguráció rossz: a Supabase config localhost URL-eket használ.

A program és nutrition insert ellenőrzéseinél is volt egy érdekes észrevétele: az edző bármely client_id-ra írhat, ha a DB policy nem ellenőrzi a kapcsolatot. Az Opus az üzenetekre észrevette ezt (amit a GPT is megemlített), de a programokra és táplálkozási tervekre csak a GPT figyelt.

Az npm audit is csak nála jelent meg: 1 high és 18 moderate sérülékenység a dependency fában.

P2 szinten olyan dolgok jöttek, amik szintén a deployment és infrastruktúra rendrakásáról szólnak: migrációk idempotenciája, seed és test adatok elkülönítése a production migrációkból, route guard a layoutban (UI szinten sincs trainer/client szerepkör-védelem)

Termékoldalon is volt néhány hasznos felvetés: a QR scan flow hiánya (van QR generálás, de a kliens nem tudja beolvasni), advanced plan feature teljesség (RPE/RIR/EMOM kapcsolók részben implementáltak), és az Android permission tisztítás (duplikált kamera, felesleges record audio engedély, ami store review kockázat).

Összesen 15 olyan tétel volt, amit kizárólag a GPT 5.5 emelt ki.

Amit csak az Opus 4.7 talált meg Itt viszont más képlet rajzolódott ki: az Opus 4.7 a kódszintű mélységben jóval erősebb volt, és néhány komolyan kritikus dolgot szúrt ki, amiket a GPT teljesen elmulasztott.

A legdurvább pont egyértelműen a stall-detect riasztások ügye. Az audit szerint ez egy hirdetett fő funkciója a terméknek: amikor egy kliens stagnál egy gyakorlatban, az edző értesítést kap. Az Opus észrevette, hogy a useStallDetection hook sehol sincs használva a kódban, és a progress_alerts táblába semmi nem ír termelési kódból, csak a seed migrationben. Tehát a feature gyakorlatilag nem működik, miközben a marketingben benne van. Ez a GPT-nek teljesen elsiklott a figyelme felett. Üzletileg ez egy elképesztően fontos megfigyelés, mert nem bug, hanem egy hamis ígéret.

P0 szinten talált három olyan konkrét bugot, amik csak fájl- és sorszintű olvasással derülnek ki:

Az Apple Sign-In rossz nonce paramétert használ (authorizationCode helyett nonce van átadva, hash-elés nélkül). Ez egy konkrét hiba. A meghívó kód generálás Math.random()-mal készül, ami nem kriptográfiailag biztonságos, miközben az expo-crypto már fent van mint dependency. És van egy role-select bypass hiba is: a handle_new_user trigger profilt hoz létre role = null-lal, de az app/index.tsx csak akkor küld a role-select képernyőre, ha a profil egyáltalán nem létezik. Tehát minden új edző automatikusan a kliens oldalra fut regisztráció után.

P1 szinten az adatbázis index hiánya is csak nála jelent meg, méghozzá egy teljes, kész index-listával: 18 darab konkrét create index parancs, ami a P1-be tartozó skálázódási problémákat orvosolja. Ezt simán be lehet másolni egy migrációba. A GPT ezt sehol sem említette, pedig minden kliensoldali listázás ezen fog elhasalni az első néhány száz felhasználó után.

További Opus-only tételek: nincs offline retry policy (edzőteremben hálózati hiba esetén a szettek elvesznek), nincs hiba-monitorozás (Sentry vagy Crashlytics), trainer chat tab hiányzik a layoutból (href: null), és számos kódszintű bug: a pihenő-timer drift-elhet háttérben (1Hz setInterval probléma), a reps érték előkitöltése hibás (parseInt("8-12") mindig 8-at ad vissza), az olvasott állapot frissítés újra-fut minden üzenet érkezésekor, a kép-kompresszió hiányzik feltöltés előtt, és így tovább.

Az iOS store-előfeltételeket is csak az Opus szúrta ki: T&C linkek hiánya, NSPhotoLibraryUsageDescription általános leírás hiánya, Privacy manifest, és az Apple által 2022 óta kötelező account-deletion flow hiánya. A GPT csak az Android oldali permission tisztítást említette, az iOS oldalra nem figyelt.

Összesen 28 olyan tétel volt, amit kizárólag az Opus emelt ki. Mi a tanulság? Két dolog tisztult le bennem ezek után.

Az Opus 4.7 jobb kódolvasó és bug-vadász. Ha azt akarod, hogy egy modell mélyen átolvassa a kódbázisodat és megtalálja a tényleges, sorszintű hibákat (race conditionöket, rosszul implementált auth flow-kat, nem működő funkciókat, hiányzó indexeket), akkor egyértelműen az Opust kell választanod.

A GPT 5.5 jobb senior konzulens szemmel. Ha azt akarod, hogy egy modell egy executive-szintű összegzést adjon, ami a deployment, infrastruktúra, konfigurációs és termék-érettség oldalról vizsgálja a projektedet, akkor a GPT komolyabb értéket ad. Az auth hardening, az npm audit, az OAuth config, a migráció-rendrakás és a store review szempontok mind olyanok, amiket egy DevOps vagy lead developer első körben nézne meg. Ez egy másfajta gondolkodás, és valódi értéke van.

A gyakorlatban viszont a kettő uniója adja a teljes képet. Mindkettőben volt olyan tétel, amit a másik nem talált meg, és ezek nem véletlenül oszlanak meg a két modell között: ez nem a szerencsén múlik, hanem a két modell eltérő gondolkodásmódján.