# Building Software Factories (With No Slop)

> **Forrás:** https://archive.codenewsletter.ai/2090252351533973768 (eredetileg dzhng.substack.com)
> **Szerző:** David [@dzhng](https://x.com/dzhng)
> **Dátum:** 2026. augusztus 26.
> **Topic:** ai-automation.md (AI fejlesztés, software engineering)
> **Canonical mappa:** tanulmanyok

---

## Összegzés

David ([@dzhng](https://x.com/dzhng)) "Building Software Factories (with no slop)" című esszéje a modern AI-alapú kódgenerálás egyik legégetőbb problémáját, az "AI slop"-ot (gépi generálta, de ellenőrizetlen kódot) vizsgálja, és egy konkrét, működőképes keretrendszert javasol a megoldásra. Az esszé a TheCode newsletter-en jelent meg, és David saját, hónapok óta futó projektjein (köztük a [@duetchat](https://x.com/duetchat)) alapul.

A szerző kiindulópontja, hogy a kódgenerálás sebessége ma már nagyságrendekkel meghaladja az emberi review-kapacitást, és ez a szakadék nem fog bezárulni, a modellek egyre jobbak lesznek, a humán review-pedig fizikailag korlátos. A "slop" nem modellminőségi probléma (a SOTA modellek már jól kódolnak), hanem rendszer-architektúra probléma: amikor az output végtelen és az inspection szűk keresztmetszet, az inspection formálissá válik (LGTM), a minőség pedig a "skim" szintjére esik. Ez a degradáció már most látható a nagy kódbázisokban.

A cikk legfontosabb tézise, hogy a teljes jelenlegi SDLC (Software Development Life Cycle) azon az implicit feltételezésen nyugszik, hogy **az ember el tudja olvasni a kódot**. A pull request-ek, code review-k, linterek, style guide-ok, tabs vs. spaces viták mind ennek a feltételezésnek a következményei. Ha ez a feltételezés felborul (és fel fog, mert a kód egyre olvashatatlanabb lesz. Claude-speak, új AI-natív nyelvek, nyers gépi kód), akkor a teljes folyamatot újra kell tervezni.

David javaslata: kezeljük a kódbázist **fekete dobozként** (interpretability-probléma), ne kód-review problémaként. A kódbázist **domain-specifikus, jól definiált input/output határokkal** rendelkező darabokra kell szeletelni, és mindegyikre **szenzorokat** kell tenni: invariánsokat (minek kell mindig igaznak lennie), trace-eket (mi történt egy valódi futás során), attack surface-t (mihez fér hozzá, mit érinthet), és döntési naplót (milyen döntéseket hozott az agent, ahol a spec csendes volt). A review felszíne az interface, nem az implementáció.

A "decision ledger" (döntési napló) a másik kulcsfogalom. Amikor David futtat egy coding agent sessiont, kéri, hogy az agent egy külön skill-en keresztül adja át a **minden döntését, ahol a spec csendes volt**, sima nyelven, legkevésbé magabiztostól a legbiztosabbig rangsorolva. Egy kétnapos futás akár több tízezer sor kódot is generál, amiből talán harminc döntés számít, és David ezeket olvassa el, és négyre rákérdez vissza. Ez ugyanaz, amit egy jó senior code review csinál: az értéke sosem a sor-soronkénti nitpicking volt, hanem a rossz absztrakció, a kimaradt eset, a más problémát megoldó implementation felismerése.

Fontos technikai részlet, hogy az auditor **mindig külön pass** legyen a megvalósítótól (független sub-agent), mert egy modell, amelyik a saját munkáját review-zza, a saját intent-jével van elfogultan, és racionalizálni fog. Az audit soha ne blokkoljon, és ne tudjon kódot módosítani, mert amint tud, a tiszta jelentés fogja motiválni a tisztességes jelentés helyett.

A cikk kitér arra is, hogy a TypeScript/szintaxis vita végül lényegtelenné válik. Ahogy a fordítási célnyelv (TypeScript, Python, gépi kód) egyre kevésbé fontos, az interpretability felkerül egy magasabb szintre: az intent-be és a viselkedésbe. A kód csupán az a "compile output", ami kiesik a gyár végén, nem az artifactum.

A nehéz rész a **szeletelés** (slicing). Nem "bontsd fel a feladatot részfeladatokra", hanem **függetlenül verifikálható darabokra**: amiket külön lehet építeni, külön lehet instrumentálni, és külön lehet tévedni. Ugyanazok a határok, ahová a szenzorokat tesszük. A nehezebb probléma egy szinttel hátrébb van: annak ismerete, hogy **hol vannak egyáltalán a darabok**. Mielőtt szeletelhetnél egy feladatot, ismerned kell a formáját, és általában senki sem ismeri, sem te, sem az agent. Itt jön a "fog of war" megközelítés: scoutolás előzi meg a tervezést, quadrant-by-quadrant felderítés arról, mi ismert, mi ismeretlen, mi a holtfolt, majd a felderített területet függetlenül elfoglalható territóriumokra szeletelés.

A teljes hurok, amit David javasol: **Map the fog** (interjúd az ötletet quadrant-by-quadrant, amíg meg nem tudod, mit építesz) → **Codify** (írd meg a spec-et, nagyrészt átirat és adversarial planning, mert a döntések upstream, olcsón születtek) → **Build** (a harness loop módban, a spec vezérel; review-k szeletenként tüzelnek, a terv újraszeleteli magát, ha a build elavultnak bizonyul) → **Review the choices** (olvasd a ledger-t, legkevésbé magabiztostól kezdve, küldd vissza, hagyd újra-auditálni).

David szűkebb állítása (nem azt mondja, hogy a kódolvasás meghalt): ha a humán olvasást tesszük meg a verifikációs lépésnek, a slop garantált, és semmilyen review (AI-s vagy nem) nem javítja meg. A problémát interpretability-problémaként kezelni a megoldás. A két jelölt, ami David szerint működik: egy fekete doboz jól definiált seam-ekkel és szenzorokkal, valamint egy strukturált rekord arról, hogy az agent mit döntött és mennyire volt biztos.

A "software factory" David definíciója: nem egy coding agent. Egy gyártósor, ahol az intent és a viselkedés az inspected output, és a kód az, ami kiesik a végén. David saját skilljei a [github.com/dzhng/skills](https://github.com/dzhng/skills) repo-ban érhetők el.

## A beszélgetés főbb témái

- **AI slop mint rendszerprobléma**: nem modellminőségi, hanem review-kapacitás-korlát, a generálás sebessége meghaladja az inspection tempóját, ezért az inspection formálissá válik.
- **Az SDLC alapfeltevése, hogy az ember olvashatja a kódot**: pull request-ek, code review-k, linterek, stb. mind ennek a feltételezésnek a downstreamjai. Ha a feltevés eltörik, az egész folyamatot újra kell tervezni.
- **A kód olvashatatlansága exponenciálisan nő**: Claude-speak, új AI-natív nyelvek, nyers gépi kód, a review-t segítő AI-k az artifactumhoz vannak pinningelve, és pont az artifactum megy átlátszatlanná.
- **Fekete doboz + interpretability**: domain-specifikus, jól definiált input/output határokkal rendelkező darabokra szeletelés, szenzorokkal (invariánsok, trace-ek, attack surface, döntési napló).
- **Decision ledger (döntési napló)**: az agent külön skill-en keresztül átadja minden döntését, ahol a spec csendes volt, rangsorolva, legkevésbé magabiztostól a legbiztosabbig.
- **Auditor vs. implementer szétválasztása**: az auditor mindig független sub-agent legyen, mert a saját munkáját review-zó modell a saját intent-jével van elfogultan.
- **A TypeScript/szintaxis vita irrelevánssá válik**: az interpretability felkerül az intent és a viselkedés szintjére; a kód csupán a "compile output".
- **A szeletelés a nehéz rész**: nem részfeladatokra bontás, hanem függetlenül verifikálható, izoláltan építhető és izoláltan tévedhető darabokra bontás. A "fog of war" megközelítés: scoutolás előzi meg a tervezést.
- **A teljes hurok**: Map the fog → Codify → Build (harness loop mode, per-slice review-k, auto-reslice) → Review the choices.

## Kulcsmondatok

- "If the goal is still to read every line, we are bottlenecked by our own ability to review, and quality degrades toward zero.". David
- "Slop is what happens when generation is unbounded and verification is bottlenecked on a human reading the output.". David
- "The entire SDLC assumes you can read the code.". David
- "The thing that makes this work is the seams. A large monolith is too complex to be efficiently interrogated. Domain specific pieces with well defined inputs and outputs are what turn an unreadable system into an inspectable one.". David
- "Behavior tells you what. It doesn't tell you why.". David
- "Intent going in, behavior coming out, and the implementation free to be as unreadable as it wants in between.". David
- "Interpretability was never really living in the syntax, it was living in the intent, and source code was just the last place we bothered to write intent down.". David
- "There has always been a probabilistic step between intent and artifact. We just called it a programmer.". David
- "Not 'break the goal into tasks'. You need independently verifiable pieces: things you can build in isolation, instrument in isolation, and be wrong about in isolation.". David
- "A software factory is, to me. Not a coding agent. A production line where intent and behavior are the inspected outputs, and the code is what falls out the end.". David

## Személyek és projektek

- **David ([@dzhng](https://x.com/dzhng))**: a cikk szerzője, AI-first software engineering gondolkodó. Az elmúlt hónapokban a [@duetchat](https://x.com/duetchat) és más projektek során csiszolta a "software factory" megközelítést. Saját skilljei nyilvánosak a [github.com/dzhng/skills](https://github.com/dzhng/skills) repo-ban (még work in progress).

## Technikai részletek

- **Decision ledger**: a coding agent session végén az agent egy skill-en keresztül átadja a döntési naplót (minden döntés, ahol a spec csendes volt), sima nyelven, legkevésbé magabiztostól rangsorolva. Egy kétnapos futás több tízezer sor kódot generálhat, de csak ~30 döntés számít, és David ezeket olvassa el, és 4-re rákérdez vissza.
- **Audit sub-agent**: az auditor mindig független sub-agent (nem ugyanaz a modell, nem ugyanaz a session), soha nem blokkolhat, és nem módosíthat kódot, mert amint tud, a tiszta jelentés fogja motiválni a tisztességes jelentés helyett.
- **Domain-specific seams**: a kódbázis darabjainak input/output határai explicit, domain-specifikusak kell legyenek, hogy az inspectability (szenzorok + invariánsok) hatékony legyen.
- **Artifacts (4 fajta)**: invariánsok (mit kell mindig igaznak lennie), trace-ek (mi történt a seam-eken), attack surface (mihez fér hozzá, mit érinthet), decisions (minden választás, ahol a spec csendes volt).
- **Fog of war slicing**: a scoutolás quadrant-by-quadrant feltárja az ismert/ismeretlen/holtpontokat, majd a felderített területet független territóriumokra szeletelés, amelyeket külön lehet építeni, külön lehet verifikálni. Ha egy territórium több térképet rejt, újraszeletelés és újrascoutolás.
- **A teljes loop**: Map the fog (quadrant-by-quadrant interview) → Codify (spec, nagyrészt átirat és adversarial planning) → Build (harness loop mode, spec-vezérelt, per-slice review-k, auto-reslice) → Review the choices (ledger olvasása, push back, re-audit).

## Szakmai párhuzamok és kontextus

- **Hasonló megközelítések az iparban**: a "spec-driven development" és a "living documentation" koncepciók (pl. AWS Well-Architected Framework, Google SRE Book) hasonlóan kezelik a verifikációt: nem a kódot olvassa el az ember, hanem a viselkedést és az invariánsokat ellenőrzi. Az agent-specifikus döntési napló (decision ledger) egyedülállóbb, de párhuzamba állítható a "architecture decision records" (ADR) gyakorlatával.
- **Kapcsolódó magyar podcast/cikkelemzések**: a `_decouple`, `_open_markets_podcast`, `_practical_ai`, `_using_ai_at_work` mappákban több, az AI-alapú szoftverfejlesztés jövőjéről szóló anyag található. A GLM-5.3-Flash (2026-08-26) és a korábbi Meta-visszacsatolási hurkok is párhuzamba állíthatók.
- **Eltérések a magyar IT közösségben**: a magyar AI-tanulmányok jellemzően az alkalmazási lehetőségekre fókuszálnak, míg David esszéje a rendszer-architektúra és a verifikáció filozófiáját helyezi előtérbe.

## Forrás

- **Esszé URL**: https://archive.codenewsletter.ai/2090252351533973768
- **Eredeti szerző**: David ([@dzhng](https://x.com/dzhng)) a TheCode newsletter-en keresztül
- **Kapcsolódó skill repo**: https://github.com/dzhng/skills (még work in progress)
- **Feldolgozva:** 2026. augusztus 26.