ABOUT GEARJUNKIE
KI lernen sollte sich
machbar anfühlen.
gearjunkie ist ein Lernangebot von Marcel Piontek für Entwickler, die KI im Alltag nutzen wollen. Wir erklären eine Idee nach der anderen – ohne vorauszusetzen, dass du die KI-Welt schon kennst.
01 / UNDERSTAND
Ein Konzept, ein Beispiel.
Kurze Erklärungen mit einfachen technischen Beispielen. Neue Begriffe erklären wir im Text und im Glossar.
02 / TRY
Vom Lesen ins Machen.
Jedes Basic enthält eine kleine Übung. Der einminütige Short erklärt die Kernidee mit animierten Grafiken, Sprecherstimme und eingeblendeten Texten.
03 / CHECK
Quellen statt Versprechen.
Fakten müssen auf offizielle Dokumentation oder das jeweilige Originalprojekt zurückführbar sein. Community-Beiträge helfen bei der Themensuche, ersetzen aber keine Belege.
FOR LEADERS & BUILDERS
Warum das für CEOs und IT-Kollegen interessant ist
CEOs & Führungskräfte
Wer KI-Projekte beurteilen oder ein Team dafür aufstellen möchte, braucht eine Vorstellung davon, was hinter einer automatisierten Anwendung steckt. gearjunkie macht konkrete Fragen greifbar: Welche Aufgaben übernimmt das Modell? Welche Regeln prüft Software? Wo entstehen Kosten, und wann darf ein Ergebnis veröffentlicht werden?
Das Projekt zeigt, wie Verantwortlichkeiten, Nachvollziehbarkeit und Budgetgrenzen im Ablauf verankert werden können. Es ist ein Anschauungsbeispiel für die Bewertung eigener KI-Vorhaben. Einen wirtschaftlichen Nutzen für dein Unternehmen müsstest du anhand deiner eigenen Aufgaben und Qualitätskriterien prüfen.
Entwickler & andere IT-Kollegen
Du kannst mit den Basics einsteigen und am System dahinter sehen, wie KI in eine Anwendung eingebunden wird. Für Entwicklung, Architektur und Betrieb sind besonders geprüfte Datenübergaben, gespeicherte Laufprotokolle und klare Fehlerpfade interessant. Produkt- und Projektteams können nachvollziehen, wie aus einer technischen Fähigkeit ein verständliches Lernangebot wird.
Ein praktischer Einstieg: Wähle eine Lektion, probiere die Übung und überlege anschließend, welche Prüfungen du für denselben Einsatz in deinem Team bräuchtest. So verbinden sich Grundlagenwissen und technische Umsetzung.
THE WORKFLOW
Eine digitale Redaktion mit klaren Rollen
Mehrere spezialisierte KI-Rollen bearbeiten nacheinander einen begrenzten Auftrag. Die Übergaben bestehen aus strukturierten Daten. Zusätzliche Prüfungen im Programmcode entscheiden mit darüber, ob der Ablauf fortgesetzt werden darf.
Scout
Sucht geeignete Grundlagen und sammelt Quellen. Community-Diskussionen können Themen liefern; Fakten brauchen registrierte Primärquellen wie offizielle Dokumentation oder das Originalprojekt.
Concept Analyst
Erarbeitet ein Konzeptdossier mit belegten Aussagen und Quellen. Es bildet die Grundlage für die Erklärung.
Editor
Schreibt die englische Lektion, die deutsche Fassung, Beispiel, Übung, Glossar und die Szenen für beide Shorts.
Publisher
Prüft Lektion und Short gemeinsam und gibt Feedback. Konkrete Mängel werden in einer begrenzten Zahl von Überarbeitungen repariert. Bleiben Fehler bestehen, wird nicht veröffentlicht.
Vor der Veröffentlichung werden beide Sprachfassungen der Shorts erzeugt und geprüft. Die Sprechertexte stammen aus den freigegebenen Szenen; eine separate Transkription prüft die gesprochenen Inhalte. Erst wenn Text, Belege und beide Shorts die vorgesehenen Prüfungen bestehen, wird die neue Lektion geschrieben. Öffentliche Themenvorschläge starten keinen kostenpflichtigen Lauf: Das stößt ein Betreiber ausdrücklich an.
CONCEPTS IN PRACTICE
Welche Konzepte hier zum Einsatz kommen
Die folgenden KI- und Softwarekonzepte beschreiben die Umsetzung von gearjunkie. Die technischen Namen bleiben erhalten; die Erklärung zeigt jeweils, was damit in diesem Projekt gemeint ist.
Multi-Agent Architecture
Mehrere KI-Rollen teilen sich Recherche, Analyse, Schreiben und Prüfung. Jede Rolle erhält einen eigenen Auftrag. Diese Aufteilung macht einzelne Arbeitsschritte und ihr Feedback nachvollziehbar; auch ein prüfender Agent kann sich irren.
Grounded Generation
Die Redaktion erhält Aussagen mit zugeordneten Quellen. Fakten müssen auf registrierte, erreichbare Primärquellen zurückführbar sein. Das reduziert unbelegte Aussagen, garantiert aber weder eine richtige Interpretation noch fehlerfreie Texte.
Structured Outputs
Die Agenten übergeben Daten in einem festgelegten Format. Schemata prüfen zum Beispiel, ob erforderliche Felder und Quellen vorhanden sind. So kann der Programmcode Ergebnisse weiterverarbeiten und unvollständige Übergaben zurückweisen.
Deterministic Guardrails
Das sind feste Prüfregeln im Programmcode. Sie kontrollieren unter anderem Quellenvertrauen, sichere URLs, Glossarverknüpfungen und Veröffentlichungsbedingungen. Eine Modellfreigabe kann diese Regeln nicht außer Kraft setzen. Sprachliche Qualität wird zusätzlich durch KI geprüft.
Persistent State
SQLite speichert Veröffentlichungen, bearbeitete Konzepte, Laufdaten, Kosten und Feedback. Dateien bewahren Zwischenstände und Prüfberichte. Dieser gespeicherte Zustand hilft, Doppelveröffentlichungen zu vermeiden und einen Lauf später nachzuvollziehen; er trainiert nicht das Modell.
Model Routing & Budgetkontrolle
Die Modellzuordnung ist pro Rolle konfigurierbar. Kosten werden pro Lauf erfasst, und kostenpflichtige Schritte unterliegen einer monatlichen Budgetgrenze. Lokale Schätzungen sind keine Anbieterrechnung. Testläufe mit festen Beispieldaten bleiben ohne API-Kosten.
AI-as-a-Judge & Evaluation
KI bewertet Texte und vergleicht Verbesserungsvarianten. Im Blindvergleich werden A/B-Bezeichnungen zufällig zugeordnet, damit der Bewerter nicht weiß, welche Variante neu ist. Mehrere Fälle und feste Prüfregeln ergänzen das Modellurteil; es bleibt eine fehlbare Bewertung.
Controlled Self-Optimization
Ein separater Optimizer darf genau eine begrenzte Änderung vorschlagen: eine zusätzliche Editor-Anweisung oder ein erlaubtes Editor-Modell. Eine Aktivierung erfordert bestandene Qualitäts- und Kostentests. Die Konfiguration bleibt versioniert und rückrollbar. Code, Quellenregeln und Schutzprüfungen darf er nicht verändern.
CONTROLLED IMPROVEMENT
Verbessern mit einem überprüfbaren Ablauf
Der Optimizer betrachtet Laufresultate, Fehler, Kosten und Feedback. Eine vorgeschlagene Änderung muss sich anschließend auf mindestens drei repräsentativen Fällen gegen die bisherige Konfiguration bewähren. Der Blindvergleich und die festen Prüfungen müssen die vorgegebenen Qualitäts- und Kostenkriterien erfüllen. Ohne belegten Gewinn bleibt die bisherige Konfiguration bestehen. Das System erfindet keine eigenen Veröffentlichungsregeln.
UNDER THE HOOD
Was du dir technisch ansehen kannst
Die Website basiert auf Kirby und PHP. Ein separater Worker in TypeScript steuert die Redaktion, SQLite hält den Zustand, Docker bildet die Laufzeitumgebung und systemd plant die regelmäßigen Läufe. Die animierten Shorts entstehen mit SVG-Grafiken und FFmpeg; KI erzeugt und prüft die Stimmen. Im Repository sind Rollen, Schemata, Quellenregeln und der kontrollierte Optimierungsprozess dokumentiert. Damit lässt sich die Architektur bis zu den konkreten Prüfungen verfolgen.
Von KI erstellt – offen gekennzeichnet
Du kannst Themen vorschlagen und Fehler an marcel@gearjunkie.de. Die frühere technische Ausgabe bleibt im Archiv erhalten.
Zum Lernplan ↗