MérésekBenchmarks

Hogyan mérünkHow we measure

A mérőrendszer rögzített feladatokon futtatja a teljes FRST-csapatot, pontosan úgy, ahogy egy felhasználó tenné. A feladat szövegében le van írva az interfész (útvonalak, mezőnevek, válaszformák). A futás végén egy rejtett teszt – amit a csapat nem lát és nem módosíthat – ugyanezt az interfészt ellenőrzi. Ha ugyanaz a csapat írná a kódot és a mércét is, a mérce mindig az implementációhoz igazodna.

The harness runs the full FRST team on fixed tasks, exactly as a user would. The task text describes the interface (routes, field names, response shapes). At the end of the run a hidden test – one the team can neither see nor change – checks that same interface. If the same team wrote the code and the yardstick, the yardstick would always bend to fit the implementation.

A modellek a mérésekben: munkások Gemini 3.8 Flash, kapuőr Gemini 3.6 Flash, a saját kulcson. A költség a modellszolgáltató által számolt tényleges költség.

Models in the measurements: workers on Gemini 3.8 Flash, gatekeeper on Gemini 3.6 Flash, on our own key. Cost is the actual cost as calculated from the provider's pricing.

A legutóbbi mérésekThe latest measurements

Egy nagyobb feladat: CMS motor (PHP)A bigger task: a CMS engine (PHP)

Saját tartalomkezelő PHP-ban: webes telepítő, belépés, CSRF-védelem, bejegyzések és oldalak, lapozás, két téma, médiafeltöltés szűréssel, törlés – 24 rejtett HTTP-teszt, négyfős csapat. Négy futás egymás után. Közöttük a kapukat, a PHP-konvenciót és a Tester promptját javítottuk (0.10.9); a feladat szövege nem változott. A rejtett teszt a 2. és a 3. futás között eggyel bővült (a feltöltött fájl linkjének pontos ellenőrzése) – szigorúbb lett, nem lazább.

A custom content management system in PHP: web installer, login, CSRF protection, posts and pages, pagination, two themes, media upload with filtering, deletion – 24 hidden HTTP tests, a team of four. Four runs in a row. Between them we fixed the gates, the PHP convention and the Tester's prompt (0.10.9); the task text did not change. The hidden test gained one check between runs 2 and 3 (the exact link of an uploaded file) – it got stricter, not looser.

Ez fejlesztési napló, nem statisztika: minden beállításból egyetlen futás. Amit a bukások megmutattak: egy sablonban nem létező változó 7 körön át csak a szerver naplójában állt, a kapu üzenetében nem; egy teszt a letöltött kép bájtjait írta a hibaüzenetbe, és ettől a kapu 7 körön át vak maradt; a saját fájlnév-jelölő levágásunk hibás PHP-t hagyott a sablonok elején; és a biztonsági kapu minden fájlfeltöltést súlyos hibának vett. A 4. futás eredménye kipróbálható a Demók között.

This is a development log, not statistics: one run per configuration. What the failures showed: a variable missing from a template sat in the server log for 7 rounds but never reached the gate's message; a test wrote the bytes of a downloaded image into its failure message, which blinded the gate for 7 rounds; our own filename-marker stripping left broken PHP at the top of templates; and the security gate treated every file upload as a severe issue. The result of run 4 can be tried in the Demos.

Alapmérés: 8 feladat × 2Baseline: 8 tasks × 2

Ugyanaz a nyolc feladat, mint a nap első alapmérésében, a szerződés-javítás után: 14 OK, 1 hamis zöld, 1 felesleges piros. A hamis zöld a bevásárlókosár 2. futása: az FRST késznek mondta, a rejtett teszt 11/12 – az okát még nem elemeztük. A felesleges piros a többfájlos Flask app 1. futása: a független teszt 15/15, mégis piros lett, mert a kapuőr csak a munkások aktuális fájllistáját látta, és a gazda nélküli fájlokat hiányzónak hitte. Ezt a 0.10.9 javítja – a teljes alapmérést a javítás után még nem ismételtük meg.

The same eight tasks as the day's first baseline, after the contract fix: 14 OK, 1 false green, 1 unnecessary red. The false green is the shopping cart's 2nd run: FRST said done, the hidden test gave 11/12 – we have not analysed why yet. The unnecessary red is the multi-file Flask app's 1st run: the independent test gave 15/15, yet it went red, because the gatekeeper only saw the workers' current file lists and took files without an owner for missing ones. 0.10.9 fixes this – we have not re-run the full baseline since.

Az összes mérésAll measurements

Időrendben, a közbülső – kevésbé hízelgő – mérésekkel együtt. A 2026-09-25-i sorok egy fejlesztési napot mutatnak: minden javítás előtt és után mértünk. A történetüket a cikkek mesélik el.

In chronological order, including the less flattering intermediate ones. The 25 Sep 2026 rows show one day of development: we measured before and after every fix. The articles tell their story.

Alapmérés több technológiánBaseline across technologies

Nyolc feladat Flask, Node/Express és React/Vite alapon, köztük két meglévő projekt bővítése, kétszer lefuttatva. A két jegyzet-app feladat ugyanaz: egyszer a backend és a frontend párhuzamosan, egyszer egymás után készül – ez méri, hogy a sorrend segít-e az összeillesztésben.

Eight tasks on Flask, Node/Express and React/Vite, including two extensions of existing projects, run twice. The two notes-app tasks are the same: once the backend and frontend are built in parallel, once one after the other – this measures whether ordering helps them fit together.

Amit nem mértünkWhat we have not measured

• Nagy kódbázisok. A mért projektek legfeljebb egy-két tucat fájlosak. Hogy ötven vagy ötszáz fájlnál mi történik, nem tudjuk.
• PHP és statikus oldalak. PHP-ból egyetlen feladat (a CMS motor) van rejtett tesztel mérve, négy futással – egy feladatból nem általánosítunk. Statikus oldalakról nincs rejtett tesztes mérés.
• Külső API-k, nem-SQLite adatbázis, üzenetsorok. Egyik sincs mérve.
• Homályos cél. A specifikációtól a működő alkalmazásig vezető út igazolt; az ötlettől az alkalmazásig nem.
• Szórás. Ugyanaz a feladat változatlan kóddal is adhat más eredményt – ezért ismétlünk, és ezért kevés futásból nem vonunk le nagy következtetést.

• Large codebases. The measured projects have at most a couple of dozen files. What happens at fifty or five hundred files, we don't know.
• PHP and static sites. For PHP only one task (the CMS engine) is measured with a hidden test, over four runs – we do not generalise from one task. Static sites have no hidden-test measurement.
• External APIs, non-SQLite databases, message queues. None of these are measured.
• A vague goal. The path from a spec to a working application is proven; from an idea to an application it is not.
• Variance. The same task can give a different result with unchanged code – that's why we repeat runs, and why we don't draw big conclusions from a few runs.