# 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:**

1. **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.
2. **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:

1. **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
2. **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
3. **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
4. **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
5. **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