How to become an applied AI engineer — Eyad Khrais¶

Típus: Cikk / Útmutató Szerző: Eyad Khrais (@eyad_khrais, Varick Agents) Dátum: 2026-07-07 Forrás: https://x.com/eyad_khrais/article/2074233166118756352 Nitter: https://nitter.net/i/article/2074519552277336571

Áttekintés¶

Eyad Khrais, a Varick Agents mérnöke megírta azt az útmutatót, amit ő maga szeretett volna elolvasni, mielőtt átállt az alkalmazott AI mérnöki munkára. A cikk három fő pillérre épül: eval-ek, harness engineering, és multi-agent rendszerek mint elosztott rendszerek.

1. Szoftvermérnök vs. AI mérnök¶

A legnagyobb különbség: a hagyományos szoftvermérnök determinisztikusan gondolkodik (strukturált bemenet → strukturált kimenet), míg az AI mérnök valószínűségileg. Egy LLM API hívás nem-determinisztikus — ugyanaz a bemenet más kimenetet adhat. A munka ezért nem csak a szoftver megépítése, hanem annak mérése, hogy a rendszer valóban úgy viselkedik-e, ahogy kell.

"The job stops being just building the software, and instead becomes measuring whether the system actually behaves the way it should."

2. Eval-ek (Értékelés)¶

Az eval a folyamat, amikor egy feladatot adsz az ágensnek, hagyod futni, és osztályozod, amit csinált. Két dolgot kell bizonyítani: (a) az ágens helyesen végezte el a munkát, (b) az ágens a megadott határokon belül maradt.

Kétlépcsős értékelés:

Outcome grading (eredmény osztályozása): A végeredmény összehasonlítása az elvárttal. Pl. a számla a megfelelő helyre került-e.
Trajectory grading (útvonal osztályozása): Az út, amin az ágens eljutott az eredményig — milyen tool-okat hívott, milyen mezőket érintett, milyen argumentumokat adott át. Egy ágens elérheti a helyes végeredményt úgy, hogy közben veszélyes dolgot csinál (pl. bankszámlaszámot változtat).

Kétféle ellenőrzés: - Determinisztikus: send_payment soha ne jelenjen meg jóváhagyás előtt; csak engedélyezett mezőkhöz nyúljon - Judgment (ítélet): Egy második modell pontozza rubrikával — indokolt volt-e az eszkaláció, a döntés logikája helyes-e

"Deterministic checks generally catch the safety violations, whereas the judge model scores the quality."

A két osztályzatot külön kell jelenteni — egy blended score elrejtheti, hogy az ágens 4%-ban tiltott mezőhöz nyúl.

Ajánlott források: Anthropic eval course, Lenny's complete guide to evals, Hamel's FAQ on evals

3. Harness Engineering¶

A modell önmagában nem ágens. A harness minden, ami a modell körül van, és API hívásból működő ágenst csinál:

Tool execution: A modell csak szöveget olvas/ír — a harness fogadja a strukturált kérést (JSON), validálja, végrehajtja a valós műveletet, és visszaküldi az eredményt
Context management: Minden instrukció, tool menü, tool eredmény és előző üzenet helyet foglal a context window-ban. A harness dönti el, mit kell látnia a modellnek, mit kell összefoglalni, mit kell eldobni
State és memory: A modellek stateless-ek a hívások között — minden, amit az ágensnek emlékeznie kell, a modellen kívül él (adatbázis, fájl, task record). Context = amit a modell épp néz. State = amit az ágens tud, de épp nem néz
Guardrails: A modell ugyanolyan magabiztossággal kérhet rossz action-t, mint jót — a harness ellenőrzi a jogosultságokat, validálja a bemeneteket, blokkolja a nem biztonságos műveleteket, és magas kockázatú lépéseket emberhez irányít
Agent loop: Context építés → modell hívás → válasz ellenőrzés → tool végrehajtás (ha engedélyezett) → eredmény tárolás → context frissítés → ismétlés a feladat végéig

"Your whole job is to build the operating environment that lets a probabilistic system do work inside deterministic software."

Ajánlott források: Arize talk a context management-ről, OpenAI context management article, Anthropic context engineering guide

4. Multi-Agent Rendszerek = Elosztott Rendszerek¶

Amikor egy ágens működik, a természetes ösztön a munka szétosztása több ágens között. De a második ágens megváltoztatja a tervezési egységet: az ágensről a rendszerre. Több loop hat ugyanabban a környezetben — az egyik frissíti a customer statust, miközben a másik a régi status alapján tervez. Mindkettő ésszerű döntést hozott, de a rendszer rossz sorrendben engedte interakcióba lépni őket.

Elosztott rendszerekből átvett megoldások:

Elv	Leírás
Single-writer	Minden fontos state-hez pontosan egy ágens írhat — a többi csak olvas vagy change request-et küld. Tool szinten kényszerítve
Idempotency keys	Minden mutating tool call kap egy egyedi kulcsot. Ha ugyanaz a kulcs újra megjelenik, az eredeti eredményt adja vissza ahelyett, hogy kétszer futna (Stripe API mintája)
Preconditions on writes	Mutating tool-ok feltételt kérnek a változtatás előtt: pl. "állítsd Approved-ra csak ha még Pending". Ha a státusz már változott, a tool egyértelműen hibázzon
Explicit hand-offs	A munka átadása definiált sémájú üzenetekkel, orchestrator által sorrendezve. Az ágens kapja a feladatot, ne fedezze fel

"Distributed systems engineers solved these failures decades ago. Your job is to apply them to loops that happen to contain an LLM."

TLDR¶

A modell adja az intelligenciát, de minden, ami megbízhatóvá teszi — a mérési réteg, a működési környezet, a koordinációs szabályok — a mérnök által van megépítve. A szoftvermérnökből AI mérnökké válás nem ugrás, hanem a meglévő készségek kiterjesztése.

Varick Agents: varickagents.com — folyamatosan keresnek AI mérnököket, $20K referral bonus