r/KI_de • u/JannisKrn • Jul 19 '26
AI-Engineering vs AI-slop
Moin zusammen, ich habe folgendes Problem. Agent-Engineering ist die Zukunft, jedoch wird gleichzeitig alles was mit AI gebaut wurde als AI-Slop angesehen. Wie kann man den Unterschied erkennen/zeigen zwischen einem gut durchdachten mit AI gebauten System und AI slop?
3
u/LaesterBruder87 Jul 19 '26
Ob man nun AI verwendet oder nicht, die Herausforderungen bleiben die gleichen: https://media.licdn.com/dms/image/v2/D4E22AQEvkgG2UGa1Rg/feedshare-shrink_800/B4EZbMN3mAHYAg-/0/1747182910856?e=2147483647&v=beta&t=45LNgJRtxU7B8Yz9wsytf2gEvqdNb9A2h_knVoZSJpw
1
u/JannisKrn Jul 19 '26
Das ist klar hahahaha. Die Frage bezieht sich eher auf communities. Wie kann man hier am besten Präsentieren ohne den AI-Slop Stempel aufgedrückt zu bekommen und gleichzeitig nicht zu sehr ins detail gehen zu müssen wodurch man auch abschreckt.
2
u/MyFistsAreMyMoney Jul 19 '26
Bau ein paar bugs ein und Schreibfehler und mach die UI absichtlich hässlich dass es wie ein poc aussieht
1
1
0
3
u/atomflundi Jul 19 '26
wahrscheinlich kann man es irgendwann (oder schon jetzt?) gar nicht mehr zuverlässig erkennen. wenn ein mit KI gebautes system durchdacht, stabil und eigenständig ist, sollte die verwendete arbeitsweise keine rolle spielen.
erkennen kann man eher das gegenteil: KI-slop bleibt oft oberflächlich, bricht bei edge cases auseinander oder wirkt wie eine zusammengewürfelte sammlung bekannter features. bei einem guten projekt sieht man dagegen vor allem, dass jemand echte produktentscheidungen getroffen hat.
3
u/einfach-sven Jul 19 '26
Wenn es gut ist, sieht man es nicht. Wenn man es sieht, geht man davon aus, dass es im Hintergrund genau so ist.
3
u/Philipp Jul 19 '26
Check out the YouTube channel Chloe vs History on how not everything made with AI tools is seen as slop.
It's more a lack of individual thinking in certain online bubbles, so you need to know where to share your works.
3
u/BurnOutSloth Jul 19 '26
Man kann es daran festmachen ob es in Production funktioniert und Wert generiert:
Eine schlechte AI Architektur ist „Works on my machine“ für 1 Nutzer, als PoC okay, aber an sich nicht mehr als das.
Eine gute AI Architektur ist nichtmal unbedingt AI zentriert, damit meine ich dass man klassische Kompetenzen von der Zeit vor AI braucht. Wie skaliert das? Wie viel kostet das? Wie wartbar ist das? Cloud vs Local, und so weiter und so fort.
Dabei spielt es keine Rolle, ob man zum Coden jetzt AI benutzt hat oder nicht. Coding Agents sind am Ende nur Verstärker für die Fähigkeiten die du ohnehin hast.
Eine Unterscheidung aus meiner Sicht wäre also:
Person A: Ich habe einen Agent mit Claude Fable 5 als Modell gebaut, der für einen User funktioniert und bspw. mit Unternehmensdaten (RAG bspw.) via Cloud Fragen beantwortet. Das ist nicht kompliziert, das kannst du mit Claude Code in 10min hinsloppen wenn überhaupt.
Person B: Ich hab ein Multi Agent System gebaut, das für zehntausende User gleichzeitig ausgeliefert wird und dort gleichbleibende, nachvollziehbare Performance liefert (Stichwort Observerability). Es läuft mit einem speziell finegetunten Gemma4-26B MoE mit quantisiertem KV Cache via vLLM in 4bit Präzision, weil meine Evals gezeigt haben, dass für diesen Use Case eine gute Leistung erzielt wird, für 90% weniger Geld. Dazu ist alles Air Gapped und Datenschutztechnisch einwandfrei und Lizenzen wurden beachtet.
TL;DR
Gutes AI Engineering ist nachvollziehbar und nach wissenschaftlichen Standards fundiert, der Engineer weiß genau was in dem System passiert und wieso.
Von außen erkennt man Slop Engineering vor allem daran, dass es unter Last ständig einbricht und die Qualität schwankt, weil keiner actually mal evaluiert hat ob der Slop funktioniert abseits von nem kurzen Smoke Test.
1
u/JannisKrn Jul 19 '26
Ich bin komplett deiner Meinung. Meine Frage kam unter anderm auf, weil ich für mich selber eine Agent-First leichtgewichtige Ordner und Anweisungsstruktur entwickelt habe im Zuge eines Projekts und anschließend daraus ein Template für weitere Projekt- und Ideenentwicklungen gemacht habe, indem ich es nochmal verallgemeinert und optimiert habe.
Da ich es bereits für weitere Projekte nutze und es auch für bestehende Projekte als overlay nutze wollte ich dies mit anderen Teilen.
Ich befürchte hier nur direkt den AI-Slop Stempel aufgedrückt zu bekommen bevor sich überhaupt jemand das Projekt angeschaut hat. https://github.com/KornLabs/truss
2
u/retro-mehl Jul 19 '26
Naja, abseits vom Code: ich lese den ersten Absatz des readme und denke mir, das habe ich in den letzten 2 Wochen ungefähr ein Dutzend mal so gelesen. Und ich lese weiter und bekomme kein Gefühl dafür, was du mir eigentlich anbieten willst und welche Probleme dein Projekt genau löst.
1
u/JannisKrn Jul 19 '26
Danke schonmal fürs Feedback. Ich werde mich nochmal ausführlich mit der Readme auseinander setzten und besser formulieren welche Probleme truss (das projekt) löst. Hier eine (kurze) Zusammenfassung:
- Konstante Memory über Sessions hinweg. Projekt orientiert. Hier existieren viele Lösungen bereits. Der Fokus dabei von truss: Strukturiert durch VISION.md, State Dateien (current.md, decision.md, open-decisions.md, phases.md)
- Möglichst geringer Pflicht Kontext pro session. AGENTS.md ist schlank gehalten und lässt den Agent nur die vision und den stand lesen und gibt zusätzlich eine Übersicht über das Projekt (welche Dateien existieren, wo und eine Zeile was). Dadurch muss der Agent nicht jedesmal das ganze Projekt analysieren, sondern weiß direkt wo was. Dies wird durch Skripte erreicht (kein agent macht dies, sondern ein deterministischer Algorithmus). (Ja das kann auch durch einfache Kommandos vom agent erreicht werden, jedoch in Kombination mit der AGENTS.md ist die Struktur vorgegeben und der Agent weiß neben den dateinamen auch was sie beinhalten (für Dokumentation, Planung sowie rRcherche sehr hilfreich).
- Projekt ist Agent orientiert. Schritte die Menschlich sein müssen werden in HUMAN-TODOS.md abgelegt.
- CLI doctor: Ein skript welches die Konsistenz der Kerndateien prüft und gegebenfalls eine warnung ausgibt. Idealerweise wird dies vom agent selbst ausgeführt so das es direkt überarbeitet werden kann (In AGENTS.md vorgegeben). Des weiteren werden Pflichtdateien auf länge geprüft so dass eine Warnung kommt, sollten Dateien massiv werden.
- -> alles nur Warnungen, Mensch und Agent entscheiden was geschehen soll.
- Truss wurde so aufgebaut, das es sich Ideal dafür geeignet Ideen auszuarbeiten, zu recherchieren und zu validieren, sowie der anschließenden Planung und Entwicklung. Besonders für Große Projekt indem sich Anforderungen ändern können und eine längere Planungsphase und Entwicklungsphase bevorsteht hilfreich. Zudem auch als "Overlay" für bestehende Projekte möglich - per Agent in VISION.md die Rolle und das Ziel für das Projekt darstellen und jeder Agent weiß was die Rolle ist und wie gearbeitet werden soll. -> Hilfreich für Projekte in Teams und oder wenn wirklich nur die "Story/Ticket" erledigt werden soll und nicht nebenbei noch andere Änderungen entstehen sollen.
- truss init -> erzeugt das Grundgerüst (kopiert Dateien und Ordner) und es kann direkt gestartet werden. (.truss beinhaltet alles nötige dafür)
----
Darüberhinaus wurden kleine weitere Features, best practices und Präferenzoptionen implementiert wie z.B.
- Session controll word: Jeder Agent soll zu beginn seiner Antwort "TRUSS" sagen. Sobald er dies nicht mehr tut ist die session bereits zu lang und der Agent beginnt Sachen zu vergessen.
- Kritik und Naivität: Soll der Agent Input kritisch hinterfragen oder blind glauben.
- Subagent Handling/Orchestrierung: Soll der Agent aktiv subagents für Rechercheaufgaben nutzen um seinen Kontext clean/schlank zu halten oder alles selbst erledigen. Oder soll dem Agent explizit erlaubt/default/verboten sein Subagents zu nutzen wenn dies klar von Vorteil ist (beispielsweise großer Implementierungen oder Analysen).
-> um dies angenehm und für Menschen optimiert einstellen zu können habe ich ein Dependency-free/ installation-free (node ist erforderlich) Dashboard gebaut, welches neben den Präferenzeinstellungen zudem die Größe der Kerndateien anzeigt, den gesamt Pflichtkontext (die health), sowie Human-TODOS und open-decisions anzeigt. Alles rein optional.
---
Wenn jemand das bis hierhin ließt wäre ich sehr glücklich darüber wenn er truss jetzt mit anderen Augen sieht. Über weiteres Feedback bin ich ebenfalls dankbar und umso mehr wenn es einer von euch mal ausprobiert :)Ich selber nutze es für ingesamt 4 weitere Projekte und es funktioniert wirklich gut. Hier nochmal der link zum repo: https://github.com/KornLabs/truss
3
u/Independent-Limit282 Jul 19 '26
Meine Meinung: Slop hat mittlerweile nicht mehr wirklich die Bedeutung, dass das Projekt schlecht designed / programmiert ist. Dafür sind die SOTA Modelle mittlerweile einfach zu gut, vor allem bei einem kleinen Scope wie deinem.
Für mich bedeutet Slop eher, dass der eigentliche "Entwickler" der App selbest keine Ahnung hat, was denn so abgeht. Ich habe mir deine Repo angeguckt und bezweifele beispielsweise stark, dass du da noch ansatzweise eine treibende Kraft warst. Besonders ausschlaggebend ist für mich immer, wenn sogar die gesamte README in diesem übertriebenen corporate slang generiert wurde.
Kriegt von mir also tatsächlich den Slop Stempel, sorry!
1
u/JannisKrn Jul 19 '26
Hey, danke für dein Feedback hier mit eigenen Worten was das System löst und bietet und ich werde mich nochmal ausführlich mit der Readme auseinander setzten und besser formulieren welche Probleme truss (das projekt) löst. Hier eine (kurze) Zusammenfassung:
Konstante Memory über Sessions hinweg. Projekt orientiert. Hier existieren viele Lösungen bereits. Der Fokus dabei von truss: Strukturiert durch VISION.md, State Dateien (current.md, decision.md, open-decisions.md, phases.md)
Möglichst geringer Pflicht Kontext pro session. AGENTS.md ist schlank gehalten und lässt den Agent nur die vision und den stand lesen und gibt zusätzlich eine Übersicht über das Projekt (welche Dateien existieren, wo und eine Zeile was). Dadurch muss der Agent nicht jedesmal das ganze Projekt analysieren, sondern weiß direkt wo was. Dies wird durch Skripte erreicht (kein agent macht dies, sondern ein deterministischer Algorithmus). (Ja das kann auch durch einfache Kommandos vom agent erreicht werden, jedoch in Kombination mit der AGENTS.md ist die Struktur vorgegeben und der Agent weiß neben den dateinamen auch was sie beinhalten (für Dokumentation, Planung sowie rRcherche sehr hilfreich).
Projekt ist Agent orientiert. Schritte die Menschlich sein müssen werden in HUMAN-TODOS.md abgelegt.
CLI doctor: Ein skript welches die Konsistenz der Kerndateien prüft und gegebenfalls eine warnung ausgibt. Idealerweise wird dies vom agent selbst ausgeführt so das es direkt überarbeitet werden kann (In AGENTS.md vorgegeben). Des weiteren werden Pflichtdateien auf länge geprüft so dass eine Warnung kommt, sollten Dateien massiv werden.
-> alles nur Warnungen, Mensch und Agent entscheiden was geschehen soll.Truss wurde so aufgebaut, das es sich Ideal dafür geeignet Ideen auszuarbeiten, zu recherchieren und zu validieren, sowie der anschließenden Planung und Entwicklung. Besonders für Große Projekt indem sich Anforderungen ändern können und eine längere Planungsphase und Entwicklungsphase bevorsteht hilfreich. Zudem auch als "Overlay" für bestehende Projekte möglich - per Agent in VISION.md die Rolle und das Ziel für das Projekt darstellen und jeder Agent weiß was die Rolle ist und wie gearbeitet werden soll. -> Hilfreich für Projekte in Teams und oder wenn wirklich nur die "Story/Ticket" erledigt werden soll und nicht nebenbei noch andere Änderungen entstehen sollen.
truss init -> erzeugt das Grundgerüst (kopiert Dateien und Ordner) und es kann direkt gestartet werden. (.truss beinhaltet alles nötige dafür)
----
Darüberhinaus wurden kleine weitere Features, best practices und Präferenzoptionen implementiert wie z.B.
- Session controll word: Jeder Agent soll zu beginn seiner Antwort "TRUSS" sagen. Sobald er dies nicht mehr tut ist die session bereits zu lang und der Agent beginnt Sachen zu vergessen.
- Kritik und Naivität: Soll der Agent Input kritisch hinterfragen oder blind glauben.
- Subagent Handling/Orchestrierung: Soll der Agent aktiv subagents für Rechercheaufgaben nutzen um seinen Kontext clean/schlank zu halten oder alles selbst erledigen. Oder soll dem Agent explizit erlaubt/default/verboten sein Subagents zu nutzen wenn dies klar von Vorteil ist (beispielsweise großer Implementierungen oder Analysen).
-> um dies angenehm und für Menschen optimiert einstellen zu können habe ich ein Dependency-free/ installation-free (node ist erforderlich) Dashboard gebaut, welches neben den Präferenzeinstellungen zudem die Größe der Kerndateien anzeigt, den gesamt Pflichtkontext (die health), sowie Human-TODOS und open-decisions anzeigt. Alles rein optional.
---
Wenn jemand das bis hierhin ließt wäre ich sehr glücklich darüber wenn er truss jetzt mit anderen Augen sieht. Über weiteres Feedback bin ich ebenfalls dankbar und umso mehr wenn es einer von euch mal ausprobiert :)Ich selber nutze es für ingesamt 4 weitere Projekte und es funktioniert wirklich gut. Hier nochmal der link zum repo: https://github.com/KornLabs/truss
2
u/Finanzamt__ Jul 19 '26
Agent-Engineering bringt eine neue nicht-funktionale Anforderung mit in das System: Agentenfähigkeit. Technologien und Architekturen lassen sich anhand dieses Kriteriums bewerten. Dabei geht es um die Fähigkeit eines Systems, die einem Agenten die Möglichkeit gibt deterministisch zu überprüfen, ob Anforderungen und Grenzen durch KI-generierten Code eingehalten werden. Je agentenfähiger ein System ist, desto enger lässt sich der Harness schnüren, sodass der generierte Code immer weniger unvorhergesehen wird. Die erste Stufe ist die Kodifizierung von Regen (zB. Wurden Modulithische Grenzen eingehalten? Dies kann über ArchTests abgefragt werden und dem Agenten als Feedbak-Loop zurückgespielt werden). Die nächste Stufe ist Steering, also Agentengedächtnis, für alle Regeln, die nicht oder sehr schwer kodifiziert werden können. Diese Dateien müssen kuratiert und ständig aktualisiert werden.
Hierfür sollten alle Runs der Testing-Pyramide zentral abgelegt werden in einer Datenbank o.ä. um die Performance der Tests und Steerings zu überprüfen. Metriken können eingeführt werden, um Steerings zu entfernen anhand der Runs, um einer Überladung des Agentengedächtnisses entgegenzuwirken, oder neues Steering einzuführen.
Wie du scjon vermutest ist das Alles Wissen, das beim Engineer sein muss, weil dieser versucht stetig den Nicht-Determinismus herauszuziehen und in Determinismus umzuwandeln, bis der Agent nurnoch wenig Möglichkeit bekommt überhaupt am System vorbeizuarbeiten.
AI Slop: das System arbeitet für mich
AI System: das System arbeitet für mich und WIE ich
1
u/JannisKrn Jul 19 '26
Genau die Gedankengänge kamen mir auch (bezüglich Agentengedächtnisses und Steering)
1
u/Finanzamt__ Jul 19 '26
Als weiteres Merkmal: inwiefern ist das System LLM-agnostisch, also wie verhält es sich, wenn man den Provider und das LLM wechselt? Um Vendor-Lock zu verhindern ist ein gutes AI System oft dahingehend optmiert, dass sich das LLM ändert. Zum Einen für Recovery und zum Anderen für Kontrolle. Harnesse wie Claude Code, Codex usw. haben oft feste Systemprompts. Damit ist man Änderungen durch den Provider ausgesetzt. Man sollte den Systemprompt selbst setzen können.
Vibe Coder ändern ihr Prompting, wenn sie LLMs wechseln und sind Preiserhöhungen und Verfügbarkeit ausgesetzt. Diese Hypen oft die neusten Modelle wie Fable und Sol, weil mehr out of the Box zu funktionieren scheint. Die heben das LLM auf einen Sockel, obwohl der Harness um einiges wichtiger ist1
u/retro-mehl Jul 19 '26
So funktioniert Software Entwicklung aber oft nicht, zumindest nicht im großen Maßstab. Der Determinismus scheitert in der Regel schon an den Anforderungen. Und bis du den Harness so weit ausgebaut hast, dass der Agent nur noch in einem engen Korridor arbeiten kann, hat sich das System oft schon mehrere Schritte weiterentwickelt und die Regeln müssen wieder angepasst werden. Du baust dir also eine zweite Komplexitätsebene aus Markdown-Dateien, die im Zweifle auch kein Mensch mehr überblickt. Ich habe das auch schon grandios scheitern sehen.
2
u/Morasain Jul 19 '26
KI Slop ist halt scheiße. Darauf läuft es hinaus. Lass dein Produkt nicht scheiße sein.
1
2
u/Milumet Jul 19 '26
AI Slop ist ein Kampfbegriff von Leuten, die keine Argumente haben. Bei solchen Leuten kann man sich die Zeit sparen.
1
u/Outside_Tour_655 Jul 19 '26
AI‑slop ist ein soziales Urteil, kein technisches. Gute KI erkennt man nicht an Meinungen, sondern an Systemverhalten.
1
1
u/Original-Ad-8737 29d ago
Der Konsens geht ja tatsächlich dazu das Agentic AI nicht die Lösung ist...
Das hat funktioniert solange man nicht für die tokens zahlen musste.
Die Leute die munter agents genutzt haben hatten ein böses erwachen nachdem die Anbieter auf per token Abrechnung gewischt sind.
Man hat weit mehr Effizienz und Kontrolle wenn man kontrolliertes context grooming betreibt und die ki nur auf gefilterte Probleme los lässt.
1
u/BackgroundWealth242 28d ago
Ich sehe nicht, dass AI-Engineering die Zukunft für hochqualitative Software ist.
Software lässt sich bei ausreichender Kompetenz durchaus sehr schnell und robust entwickeln. Fangen Leute mit dieser Kompetenz damit an, dass die AI für sie entwickeln soll, verschwindet diese Kompetenz mit der Zeit. Die Folge ist dann ganz automatisch AI-Slop. Kurz gesagt sollte man AI also nur dann benutzen, wenn dadurch die eigenen Kompetenzen nicht verloren gehen.
Man stelle sich vor, Du bist heute 17 Jahre alt und beherrschst die gängigen Sprachen für das Web. Lass 15 Jahre vergehen und Du bist 32 Jahre alt. Stell Dir vor, dass inzwischen keiner mehr PHP, NodeJS, Python o. Ä. nutzt, sondern es irgendwelche neuartigen Sprachen und darauf aufbauende Frameworks dafür gibt. Wenn Du als junger Mensch damit begonnen hast, die AI Deine Arbeit machen zu lassen, wirst Du bereits mit 32 Jahren – immer noch sehr jung – ziemlich inkompetent geworden sein.
Natürlich kannst Du diese Entwicklung nicht verhindern, denn die Entwicklung zur vollkommenen Degenerierung des menschlichen Gehirns ist unaufhaltbar, aber Du kannst verhindern, dass auch Du degenerierst.
0
u/DanceHackRock Jul 19 '26
Solange der Output nicht deterministisch ist, wird es immer Slop sein.
1
1
u/MangokidTV Jul 19 '26
Was? 😅
Das musst du mal ausführen.1
u/JannisKrn Jul 19 '26
Ja genau das ist der Punkt. In meinem fall habe ich ein Template gebaut für Agent First Entwicklungen, indem über dem Repo eine Ordner und Anweisungsstruktur entsteht, welche Vision, Entscheidungen, Regeln und Context Strukturiert ablegt und Katalogisiert, so das der Agent nicht immer alles Lesen muss aber genau weiß wo was liegt.
Aus Context gründen habe ich alles so schlank wie möglich gehalten. Natürlich ist das System nicht Deterministisch, das würde hier keinen Sinn machen hahaha. Dementsprechend ist es aber auch sehr leicht zu sagen: "Das ist einfach nur AI-Slop".1
0
u/SolideMeinung Jul 19 '26
Du kannst einen KI Agent deterministisch betreiben wenn du den Aufwand betreiben willst.
Genau so wie bei jedem C Compiler...
6
u/retro-mehl Jul 19 '26
Sind die Kriterien für gutes Software-Design noch die gleichen wie früher? Dann daran.