Was unsere Trainer:innen lehren, könnt ihr nachlesen.
Das Material hinter unseren KI-Schulungen, frei lesbar: was Agentic Engineering ist, wie Teams ihre Arbeit mit Coding-Agenten organisieren und was die Forschung dazu sagt.
- 116 Seiten
- 9 Themen
- frei lesbar, ohne Anmeldung
- Agentic Engineering
Der Einstieg ins Thema: was es von Vibe Coding unterscheidet, wie Teams es praktizieren, woran ihr erkennt, ob ein Team besser wird, und was sich im Enterprise-Maßstab ändert.
Aktualisiert:
- AEMM: Evidenz aus der Industrie
Die Evidenz aus der Industrie zeigt: Die meisten Unternehmen stagnieren bei moderaten Produktivitätsgewinnen durch KI. Größere Gewinne folgen aus Codequalität, umgebauten Teams und gemessenen Ergebnissen, nicht aus der Tool-Wahl. Externe Reifegradmodelle lassen sich den AEMM-Leveln zuordnen und prüfen ein Assessment gegen, ersetzen es aber nicht.
Aktualisiert:
- Architektur und Design
Architektur zählt mehr, wenn Agenten den Großteil des Codes schreiben. Der Beitrag der Engineers verlagert sich zu Struktur und Urteil, und die Artefakte, die Agenten steuern, etwa Specs, Tests, Dokumentation und Design-Systeme, werden Teil der Architektur.
Aktualisiert:
- Videos mit Coding-Agents erstellen
Video als Code: Der Agent schreibt eine Komposition in HTML oder React, Headless Chrome rendert sie Frame für Frame, FFmpeg kodiert das Ergebnis. Die Quelle lässt sich wie Code diffen und reviewen. Ob das Video gut ist, zeigt erst das angesehene Rendering.
Aktualisiert:
- Architektur agentischer Systeme
Ein agentisches System zerfällt in Agenten und Workflows statt in Services. MCP, Agent-to-Agent-Protokolle und Übergaben mit Kontext verbinden sie. Für die Produktion braucht es Durable Execution, Tracing, begrenzte Schleifen, eine Evaluation der Trajektorie und Zero Trust gegenüber jedem Agenten.
Aktualisiert:
- Architekturarbeit im agentischen Zeitalter
Wenn Agenten den Großteil des Codes schreiben, wandert die Arbeit von Engineers in die Architektur: Grenzen setzen, Intent und Randbedingungen benennen, Qualität beurteilen. Billige Implementierung macht Design wertvoller, denn ohne tragfähiges Designmodell richtet ein Agent nur schneller ein Chaos an.
Aktualisiert:
- Build versus Buy
Mit Agenten und Buildern, die aus Instruktionen auf Englisch Software bauen, kann jede:r Software bauen. Kaufen wird dadurch nicht überflüssig. Business-Software enthält Regeln, die die meisten Builder nie sehen. Also kaufen Unternehmen weiter Komponenten, die jetzt Menschen und Agenten gleichermaßen über Protokolle wie MCP steuern sollen.
Aktualisiert:
- Modernisierung und UI-Design
Agenten lesen undokumentierten Legacy-Code, ohne zu ermüden. Das macht Reverse Engineering zu einem starken Einsatzfeld, solange deterministische Parser und Tests begrenzen, was das Modell anfasst. Generierte UI braucht dieselbe Disziplin: Ohne klare Designvorgaben laufen Modelle auf einen generischen Look zu.
Aktualisiert:
- Specs, Tests und Kontext
Die Spec ist die Quelle der Wahrheit, ihre Tests prüfen den Code dagegen. Laufen beide auseinander, entscheidet, wer die Spec verantwortet, welche Seite sich ändert. Dokumentation hat jetzt einen zweiten Leser, den Agenten. Er braucht eine kleine, priorisierte und gepflegte Instruktionsschicht statt einer erschöpfenden.
Aktualisiert:
- Federated Context Platform für KI-Agenten im Unternehmen
Für Architekt:innen, die Agenten in ein großes Unternehmen bringen: wie Kontextschichten dem Organigramm folgen, was Gateway und Katalog leisten und wo ihr mit dem Lesen anfangt.
Aktualisiert:
- Context Products entwickeln
Wie aus Dokumenten, Gesprächen und Quellcode Context Products werden, Schritt für Schritt von der Ingestion bis zum Code-Wissensgraphen, für Plattform- und Datenteams.
Aktualisiert:
- Governance und Betrieb
Föderierter Kontext bleibt nur sicher und nützlich, wenn ihr ihn nach dem Start steuert. Ein Orchestrator stellt genau den Kontext zusammen, den eine Aufgabe braucht. Die Zugriffskontrolle filtert Daten an der Quelle, statt dem Modell zu vertrauen. Event-getriebenes Re-Indexing, Versionierung und benannte Owner verhindern, dass Kontext veraltet.
Aktualisiert:
- Die Plattformschicht
Die Plattformschicht ist der gemeinsame Teil einer Federated Context Platform: ein LLM-Gateway, das Modellzugriff, Kosten und Guardrails steuert, und ein Context Catalog, der jedes Context Product auffindbar macht. Agenten fragen den Katalog, was es gibt, und das Gateway nach dem Inhalt. So hängen sie nie davon ab, wo er gespeichert ist.
Aktualisiert:
- Speicher- und Retrieval-Architekturen
Kein einzelner Speicher deckt jeden Kontextbedarf. Hybride Enterprise Search findet relevante Dokumente, Knowledge Graphs beantworten Multi-Hop-Fragen über Beziehungen, und Repositories nach Git-Art geben lange laufenden Agenten prüfbares, verzweigbares Memory. Eine reife Plattform leitet jede Anfrage an den passenden Speicher.
Aktualisiert:
- Strategie und Architektur
Agenten im Unternehmen brauchen aktuellen, fachspezifischen Kontext, und ein zentraler Speicher kann ihn in dieser Größenordnung weder verantworten noch aktuell halten. Als Produkt behandelt, veröffentlicht jede Domäne eigenen, auffindbaren Kontext, und eine gemeinsame Plattform liefert Gateway, Katalog und gemeinsame Kontrollen.
Aktualisiert:
- Memory und Context Engineering
Context Engineering heißt, die Tokens zu kuratieren, die ein Modell in jedem Schritt sieht. Agenten-Memory trägt diesen Kontext über Sitzungen hinweg. Die meisten Fehler von Agenten sind Kontextfehler, darum ist diese Kuratierung der wichtigste Hebel von Engineers auf die Qualität ihrer Agenten.
Aktualisiert:
- Persistentes Agenten-Memory
Persistentes Agenten-Memory ist Zustand, den ein Agent außerhalb seines Kontextfensters schreibt und in einer späteren Sitzung zurückliest, als Notizen, Memory-Dateien oder Knowledge Graphs. Schwierig ist das Vergessen: Memory, das nur wächst, enthält am Ende nichts Nützliches mehr.
Aktualisiert:
- Just-in-time Retrieval
Bei Bedarf suchen oder vorab indexieren? Die Abwägungen für Coding-Agenten, Cognitions Messungen zu beiden Ansätzen und ein Katalog von Retrieval-Tools.
Aktualisiert:
- Kontext als versioniertes Artefakt
Für Teams mit Dutzenden Skills und Regeln: jedem eine Owner-Rolle geben, Kontext mit gestuften Evals testen und die Supply-Chain-Risiken beim Teilen kennen.
Aktualisiert:
- Methoden und Frameworks
Methoden des Agentic Engineering teilen die Arbeit zwischen Menschen und Agenten neu auf, seit Menschen nicht mehr jede Zeile selbst schreiben. Wer das Coding-Tool tauscht und das Betriebsmodell mit Sprints behält, holt nur einen Bruchteil des Gewinns.
Aktualisiert:
- Der Agent Loop
Woraus ein Agent besteht, wie ihr ihn in einfachem Code baut und wie ihr den gescheiterten Schritt debuggt, statt den ganzen Loop neu zu starten.
Aktualisiert:
- Disciplined Compounding Loop
Wie ihr jede Agentenaufgabe als Plan, testgetriebenen Build, Prüfung und Retrospektive fahrt und warum unstrukturierte Generierung Delivery-Stabilität kostet.
Aktualisiert:
- Menschliche Verantwortung
Was beim Engineer bleibt, wenn Agenten den Code schreiben: delegieren, prüfen und verantworten, der neue Middle Loop und drei Manifeste, die das festschreiben.
Aktualisiert:
- Spec-driven Development
Wie Spezifikationen Coding-Agents eine stabile Absicht und überprüfbare Arbeit geben.
Aktualisiert:
- Qualität und Verifikation
Verifikation ist der Engpass agentischer Delivery: Schreiben Agenten den Großteil des Codes, wird Generieren billig und Prüfen knapp. Ein Team liefert so schnell, wie es die Korrektheit des Outputs belegen kann, mit Tests, deterministischen Gates, Abnahmenachweisen und Evals, nicht so schnell, wie es Code erzeugt.
Aktualisiert:
- Agentic Continuous Delivery
Die Delivery-Regeln für Änderungen von Agenten und was jede Pipeline-Stufe prüft, für Teams, die Agenten in eine produktive Codebasis committen lassen.
Aktualisiert:
- Coding-Benchmarks
Coding-Benchmarks messen, ob ein Agent eine kleine Menge Unit-Tests bestehen lässt, meist in Python und oft für eine einzige Funktion. Die Teile der Arbeit mit dem größten Hebel lassen sie weg: aus einem unscharfen Problem eine gute Spec machen und eine Codebasis über viele Änderungen leicht änderbar halten.
Aktualisiert:
- Deterministische Quality Gates
Wie Feedback-Schleifen vom Language Server bis zur CI das Verhalten von Coding-Agents begrenzen.
Aktualisiert:
- Nicht-deterministische Systeme evaluieren
Wie ihr Output testet, der von Lauf zu Lauf schwankt, von Unit-Tests bis zu Baselines für Erfolgsquoten, und was ein öffentliches Eval-Leaderboard beweist und was nicht.
Aktualisiert:
- Qualitäts- und Produktivitätsmetriken
Mit Agentic Coding schaden Volumenmetriken wie Codezeilen oder Pull Requests, weil, wer Volumen belohnt, das Review mit ungeprüftem Output flutet. Tragfähig bleiben First-Pass-Akzeptanz, Rework-Rate und die DORA-Delivery-Metriken, für Agent-Änderungen gegen die menschliche Baseline gelesen.
Aktualisiert:
- Das Qualitätssystem rund um den Coding-Agenten
KI verstärkt die Engineering-Praktiken, die ein Team schon hat. Solide Versionskontrolle, Observability und kleine Batches werden zu Tempo. Ein Review-Bottleneck oder eine fragile Pipeline führen zu längeren Verzögerungen und mehr Ausfällen. Regeln, Reviews und harte Checks rund um den Agenten steuern, was er produziert.
Aktualisiert:
- Die Velocity-Falle
Warum Generierung die Verifikation überholen und den echten Delivery-Durchsatz senken kann.
Aktualisiert:
- Kuratierte Bücherliste
Die lesenswerten Bücher zum Aufbau von Technologieorganisationen, nach Relevanz bewertet von 10 (unverzichtbar) bis 1 (ergänzend). Fangt mit der kategorieübergreifenden Liste an: All Hands on Tech und The Art of Scalability bekommen für jede Engineering-Führungskraft eine 10.
Aktualisiert:
- Evidenz
Die Forschung zu KI-gestütztem Engineering zeigt: KI verstärkt die Praktiken, die ein Team schon hat. Starke Delivery-Systeme werden schneller, schwache liefern mehr Fehler aus. Die Zeitgewinne einzelner Entwickler:innen sind echt, aber ungleich verteilt. Im Unternehmen kommen sie nur an, wo sich Review, Testing und Operating Model mit ändern.
Aktualisiert:
- KI-Produktivitätsstudien: METR, Stanford, DORA, Multitudes
Keine einzelne Zahl zur KI-Produktivität hält. METR maß erfahrene Entwickler:innen in vertrauten Repositories 19% langsamer. Stanford fand einen Median-Gewinn nahe 10%, der mit wachsenden Aufgaben und Codebasen schrumpft. DORA sieht KI als Verstärker des bestehenden Systems, und Multitudes knüpft Gewinne an Lernzeit.
Aktualisiert:
- Amazon Cost to Serve Software (CTS-SW)
Amazons Zahlen zur Developer Experience: was Amazon gemessen hat, wie die Einsparungen einen Business Case ergeben, was die Kosten senkt und welche Kennzahlen Amazon ablehnt.
Aktualisiert:
- Der DORA-Report zu KI-gestützter Entwicklung
Der DORA-Report 2025 zeigt: KI verstärkt das Engineering-System, in dem sie landet. Starkes Review, starke Pipelines und kleine Batches gewinnen Tempo, schwache gewinnen Instabilität. Telemetrie von Faros AI bestreitet, dass ein starkes Fundament ein Team vor nachgelagerter Verschlechterung schützt.
Aktualisiert:
- DX AI Impact Report: KI-gestützte Entwicklung im Benchmark
Der DX-Benchmark für Q1 2026 über 400+ Unternehmen fand 92,7% KI-Adoption und 3,9 Stunden Ersparnis pro Entwickler:in und Woche. Die Qualität schwankte in beide Richtungen, und CI-Wartezeiten und Meetings kosten weiter mehr Zeit, als KI spart. Enablement und Messung entschieden über das Ergebnis, nicht die Toolwahl.
Aktualisiert:
- Abschied von Agile: McKinseys Studie zum KI-Operating-Model
McKinseys Umfrage unter etwa 300 Großunternehmen zeigt: KI hebt die Produktivität auf Unternehmensebene nur um 5 bis 15 Prozent, weil Teams Größen, Sprints und Rollen aus der Agile-Ära behalten. Bei Top-Performern waren KI-native Workflows 7-mal wahrscheinlicher und KI-native Rollen in kleineren Pods 6-mal wahrscheinlicher.
Aktualisiert:
- Vouch in Ghostty: Trust-Gating für Open-Source-Beiträge
Ghostty hat das Vouch-Modell im Februar 2026 gemergt: Nur Contributor:innen, für die jemand aus dem Maintainer-Team ausdrücklich gebürgt hat, dürfen Pull Requests öffnen, per denounce markierte Nutzer:innen werden gesperrt. Gegen Fluten KI-generierter Beiträge setzt das Modell auf ausdrückliches soziales Vertrauen statt auf einen angesammelten Reputationswert.
Aktualisiert:
- State of AI-Native Engineering Report
Augment Code hat 219 Engineering-Führungskräfte befragt: Rund die Hälfte ihres Codes generiert KI, doch nur 57 haben ihr Code-Review geändert, noch weniger Rollen, Onboarding oder Messung. 55% sorgen sich um das gemeinsame Verständnis der Codebase. Das ist die größte Sorge und die, gegen die am wenigsten passiert.
Aktualisiert:
- Einstieg
Der Einstieg in Agentic Engineering ändert eure Arbeitsweise und ist kein Tool-Upgrade: Ihr lernt zu spezifizieren, zu delegieren und zu prüfen, statt Code zu tippen. Rechnet anfangs damit, langsamer zu sein. Die Produktivitätsdaten zeigen erst eine Lernkurve, dann die Gewinne. Durch die Lernkurve kommen Teams, die Zeit zum Üben schützen.
Aktualisiert:
- Einstieg und Lernen
Der Einstieg in Agentic Engineering ist ein Lernproblem, keine Tool-Installation. Entwickler:innen sind in den ersten Stunden mit Coding-Agents langsamer und nach strukturierter Übung schneller. Wie das Lernen organisiert ist, entscheidet darüber stärker als das gekaufte Tool.
Aktualisiert:
- Effektive Praktiken für Einsteiger:innen
Einsteiger:innen werden gut mit Coding-Agents, wenn sie in einer Domäne üben, die sie beurteilen können, Aufgaben und Feedback-Schleifen klein halten und dem Agenten erst dann mehr Autonomie geben, wenn das Review jedes kleinen Schritts zum bloßen Durchwinken wird.
Aktualisiert:
- Deliberate Practice
Deliberate Practice schult euer Urteil im Umgang mit Coding-Agents: Fangt in einer Domäne an, die ihr prüfen könnt. Haltet Aufgaben und Feedback-Schleifen klein, übt täglich an echter Arbeit und baut Reibung dort wieder ein, wo das Tool Denken optional macht.
Aktualisiert:
- Engineering-Grundlagen
Engineering-Grundlagen zählen mehr, wenn Agents den Code schreiben. Übrig bleibt die Arbeit, ihn zu beurteilen: das Problem fassen, sehen, was der Agent übersehen hat, und Output prüfen, den ein Modell per Inferenz erzeugt statt kompiliert hat.
Aktualisiert:
- Der Lernpfad für Junior Engineers
KI übernimmt die kleinen, risikoarmen Aufgaben, an denen Juniors früher gelernt haben. Teams müssen Lernarbeit deshalb gezielt schaffen. Auch das Hiring verschiebt sich: Interviewer:innen prüfen jetzt, ob Kandidat:innen fehlerhaften KI-generierten Code hinterfragen und prüfen.
Aktualisiert:
- Verification Literacy
Was Engineers brauchen, um generierten Code gut zu reviewen, und warum dieser Code eine andere Art Review verlangt. Für alle, die Output von Agents prüfen.
Aktualisiert:
- Die Lernkurve
Mit Coding-Agents arbeiten Entwickler:innen in den ersten Wochen oft langsamer, und die Leistung des Teams sinkt, solange alle lernen. Erst danach zeigen sich Gewinne. Messungen aus diesem Zeitraum oder auf Basis von Selbstauskünften und Codemenge deuten die Tools in beide Richtungen falsch.
Aktualisiert:
- Organisationales Lernen
Individuelle KI-Nutzung wird erst dann zur Fähigkeit des Teams, wenn sich die Organisation mitverändert: Anreize, Verantwortung für Risiken und Vertrauen. Sonst gelingen Piloten technisch und stocken trotzdem, und die Nutzung wächst, während das Unternehmen nichts lernt.
Aktualisiert:
- Adoptionslücken und Widerstand
KI-Piloten stocken, wenn sich die Organisation nicht mit dem Tool verändert. Die Nutzung verteilt sich ungleich und bleibt flach, niemand trägt das Risiko für KI-generierten Output, und Engineers fürchten mehr um ihre Expertise als um ihren Job. Adoption braucht deshalb neben dem Rollout strukturelle und kulturelle Arbeit.
Aktualisiert:
- Produktivität und Workflow
Gemessene Effekte KI-gestützter Softwareentwicklung reichen von Verlangsamung bis zu großen Durchsatzgewinnen. Wo ein Team landet, entscheiden Enablement, disziplinierte Messung und der Workflow rund um den Code, weit mehr als Modell oder Tool.
Aktualisiert:
- Was KI-Adoption voranbringt
Dauerhafte Adoption folgt aus fester Lernzeit, klaren Richtlinien, Peer-Mechanismen wie Champions und Austauschkanälen und rollenspezifischen Workflows, die zur Wiederverwendung verpackt sind. Nutzungsziele von oben erzeugen Compliance-Theater, und Zugang allein erzeugt keine Nutzung.
Aktualisiert:
- KI-Produktivität: Evidenz und Qualität
Gemessene Produktivitätsgewinne durch KI beim Coden sind moderat und an Bedingungen geknüpft, eine randomisierte Studie fand sogar eine Verlangsamung. Sie hängen von Aufgabe, Codebase und Enablement ab, Selbstauskünfte übertreiben sie, und mehr Output treibt Churn, Fehler und Review-Last, solange die Quality Gates nicht mitwachsen.
Aktualisiert:
- Impact messen
Agentic Engineering messt ihr mit KI-Metriken wie Adoption, KI-gestütztem Anteil und Ausgaben, gepaart mit Delivery-Metriken von vor KI wie Throughput und Change Failure Rate. KI-Metriken zeigen, was passiert. Kernmetriken zeigen, ob es wirkt.
Aktualisiert:
- Coding-Agents in der Praxis
Stand Oktober 2026 übergeben Praktiker:innen Agents ganze Aufgaben samt den Tools, die den Delivery-Zyklus sichtbar machen, und verlangen Belege, statt jeden Schritt zu steuern: Der Plan kommt in eine committete Datei, gescheiterte Versuche werden verworfen statt geflickt, Fragen nennen das Ziel statt der Methode, und exakte, wiederkehrende Operationen kommen in Scripts.
Aktualisiert:
- Wo KI-Produktivität entsteht und verloren geht
KI beschleunigt das Schreiben von Code, und das war selten der Bottleneck. Der Engpass wandert in Review, Tests, Change-Freigabe und Betrieb. Gewinne auf Systemebene entstehen deshalb durch bessere Abstimmung und verbesserte Übergaben, nicht durch schnellere Codegenerierung.
Aktualisiert:
- Agent-Instruktionen (CLAUDE.md, AGENTS.md)
Was in CLAUDE.md oder AGENTS.md gehört und wer die Datei verantwortet, für Teams, die die Datei einrichten, die ihre Coding-Agenten in jeder Sitzung lesen.
Aktualisiert:
- Automationskatalog
Warum eine Software Factory ihre ständigen Automationen als Katalog aufschreibt und was der Auditor-Job in diesem Katalog prüft.
Aktualisiert:
- Kontextfenster
Warum ein größeres Kontextfenster die Qualität von Agents nicht rettet und wie Teams das Fenster jeder Sitzung klein halten.
Aktualisiert:
- Hooks
Wann ihr zu einem Hook statt zu einer Instruktionsdatei greift und welche Aufgaben Teams Hooks im Alltag mit Coding-Agents geben.
Aktualisiert:
- Quality Gates
Warum Quality Gates wichtiger werden, sobald Agenten den Code schreiben, und was ein Gate von einer Instruktion unterscheidet, die der Agent ignorieren kann.
Aktualisiert:
- Research, Plan, Implement (RPI)
Warum RPI jedem Schritt ein frisches Kontextfenster gibt und wo Menschen prüfen sollten, für Teams auf dem Weg vom Chat-Prompting zum geplanten Workflow.
Aktualisiert:
- Spec-driven Development
Was eine geschriebene Spec für einen Agenten ändert und wie ein Team die Spec aktuell und verbindlich hält, während Code und Tests sich weiterentwickeln.
Aktualisiert:
- Vibe Coding
Wo Vibe Coding passt, wo es zusammenbricht und worauf ein Team umsteigt, sobald es Software betreiben und warten muss.
Aktualisiert:
- Leadership
Engineering Leadership baut das Umfeld, in dem Teams selbst gut entscheiden: eine Strategie, die den Entscheidungsspielraum absteckt, ein Management passend zur Unsicherheit der Arbeit und Schnittstellen, die lokale Verantwortung möglich machen. Führt ein Team KI ein, hängen die Gewinne stärker von diesem Umfeld ab als vom Tool.
Aktualisiert:
- Dynamisch-robuste Organisation
Für Engineering-Führungskräfte: Strategie oder Plan, Management passend zum Problem, wo Verantwortung liegt und ob sich Kultur direkt ändern lässt.
Aktualisiert:
- KI-Einführung führen
Die Hebel, die eine Engineering-Führungskraft tatsächlich steuert, wenn ein Team Agents einführt, und die Messfalle, die aus einer guten Einführung eine schlechte macht.
Aktualisiert:
- Product Management
Wenn Agents bauen, wird eine andere Fähigkeit knapp: zu wissen, welches Feature sich lohnt, und genau zu sagen, was es leisten muss. Product Management wird wichtiger, denn Spec und Prototyp werden zur Grundlage, auf der die Agents arbeiten.
Aktualisiert:
- Software Engineering
Software Engineering ist das Handwerk, Systeme zu bauen, die ein Unternehmen sicher ändern kann. Werte entscheiden, wohin ein Team sein Gewicht legt. Prinzipien machen aus diesen Werten Entscheidungen, und Urteilsvermögen wendet sie an. Mit den Agents hat sich daran nichts geändert. Agents machen es wichtiger, weil sie die Praktiken verstärken, die ein Team schon hat.
Aktualisiert:
- Architekturprinzipien
Architekturprinzipien machen aus Engineering-Werten Entscheidungen, die ein Team prüfen kann: Systeme an Fachdomänen ausrichten, ohne Blockieren kommunizieren, Services klein halten, kontinuierlich ausliefern, über bewährte Low-Tech-Mittel koppeln, öffentlich entscheiden und mit Angriffen rechnen. Jedes Prinzip hat eine Aussage, eine Begründung, Konsequenzen und Fragen fürs Review.
Aktualisiert:
- Build-or-Buy-Framework
Build oder Buy entscheidet ihr entlang von vier Dimensionen: funktionale, technische und operative Komplexität sowie einzigartiger Geschäftswert. Danach zählt ihr die Kosten auf fünf Stufen, von Technologie und Personal bis zu verlorenem Geschäft und verpasster Chance. Baut selbst, was euer Geschäft unterscheidet und was euer Team versteht und betreiben kann.
Aktualisiert:
- Engineering Manifesto
Ein Engineering Manifesto benennt die Werte, an denen ein Team jede Entscheidung misst: Tech folgt Business, Move fast and fail fast, niedrige technische Hürden, Abdeckung nichtfunktionaler Aspekte und Full Ownership. Teams wenden sie mit gesundem Menschenverstand an und besprechen jede Abweichung offen mit den Teams, die sie betrifft.
Aktualisiert:
- Engineering-Philosophie
Engineering-Philosophie ist die Begründung hinter Engineering-Regeln: Arbeit fließt am besten, wenn ein Team seinen Teil eines Systems allein ändern kann, die Wirkung seiner Entscheidungen schnell sieht und weiter lernt. Wer diese Begründung verinnerlicht hat, braucht weniger Regeln, um danach zu handeln.
Aktualisiert:
- Die Five Ideals
Die Five Ideals sind die Bedingungen, unter denen schneller Flow im Arbeitsalltag real wird: Lokalität und Einfachheit, Fokus, Flow und Freude, Verbesserung der täglichen Arbeit, psychologische Sicherheit und Kundenfokus. Fehlt eines davon, verlieren Engineers Zeit an Abstimmung, Unterbrechungen, verborgene Defekte oder Arbeit, die niemand braucht.
Aktualisiert:
- Die drei Wege
Die drei Wege sind schneller Flow von der Entwicklung in den Betrieb, schnelles Feedback, das Qualitätsprobleme an ihrer Quelle behebt, und eine Kultur des kontinuierlichen Lernens. Zusammen beschreiben sie, wie Arbeit durch ein Software-Delivery-System fließen sollte, unabhängig von Stack, Teamgröße oder Jahrzehnt.
Aktualisiert:
- Senior Engineering Skills
Senior Engineers werden weniger an ihrem Code gemessen als an den Fähigkeiten drumherum: Meetings leiten, Design Docs schreiben, ohne Weisungsbefugnis führen, Kämpfe auswählen und Feedback annehmen. Agentisches Arbeiten erhöht den Einsatz, denn Design Docs und gemeinsame Konventionen werden zum Kontext, aus dem KI-Agenten bauen.
Aktualisiert:
- Software Factories
Eine Software Factory ist das Delivery-System, das die Absicht eines Teams in ausgelieferte Software verwandelt, der es vertrauen kann. Menschen bauen und justieren das System, statt das Produkt selbst zu schreiben. Wer eine baut, betreibt Harness Engineering: Umgebung, Orchestrierung, Isolation und Gates rund um die Agents entscheiden, was ausgeliefert wird.
Aktualisiert:
- Dark Factory Patterns
Ein Praxisbericht über Agenten ohne Freigabe für jeden Schritt: die Anti-Patterns, die funktionierenden Patterns, die Tools und wie weit die Aussagen tragen.
Aktualisiert:
- Federated Factory im Enterprise-Maßstab
Eine föderierte Factory-Plattform bedient viele Software Factories in einem Enterprise und teilt die Verantwortung auf drei Ebenen auf. Die zentrale Plattform-Ebene besitzt Blueprints, Tool-Routing, Identität und Audit. Die Domänen-Ebene hält Kontext, den mehrere Teams teilen, und auf der Team-Ebene laufen die Agents. So vermeidet sie eine Factory für alle und eine Factory pro Team.
Aktualisiert:
- Multi-Agent und Orchestrierung
Multi-Agent-Orchestrierung gestaltet das System, das die Arbeit vieler Coding-Agents verteilt, isoliert, prüft und zusammenführt. Gut gebaut vervielfachen parallele Agents den Output. Schlecht gebaut vervielfachen sie die Nacharbeit.
Aktualisiert:
- Creator- und Verifier-Rollen
Patterns, die Bauen und Prüfen trennen: warum Self-Grading scheitert und wie ihr einen Verifier in den Loop einbaut, für Teams mit mehr als einem Agenten.
Aktualisiert:
- Sicherheit und Runtime-Isolation
Eine agentische Software Factory abzusichern heißt zu begrenzen, was von Agenten erzeugte Arbeit dem System antun kann, das sie ausführt. Agenten umgehen Prompts und Berechtigungen. Deshalb halten nur Kontrollen unterhalb des Agenten: isolierte Runtimes, durchgesetzte Datengrenzen, minimale Befugnisse und risikobasierte Freigaben.
Aktualisiert:
- Contributor Trust und Dual Use
KI macht plausible Beiträge von geringer Qualität billig. Projekte ersetzen deshalb das Grundvertrauen in Contributor:innen durch ausdrückliches Vouching und den Nachweis, dass ein Mensch den Code gelesen hat. Dieselben Modelle lassen jede:n Engineer ein Security-Review durchführen und Angreifer:innen Exploits schneller finden, als die Branche patcht.
Aktualisiert:
- Software Factories und Harness Engineering
Der Hub für Software Factories: warum der Harness mehr zählt als das Modell, Factory-Modelle von Ticket-to-PR bis Dark Factory und ein Katalog an Ressourcen.
Aktualisiert:
- Agent Observability
Was ihr bei jedem Agentenlauf aufzeichnen solltet und wie ihr einen Commit auf den Agenten dahinter zurückführt, für Teams mit Agents in Produktion.
Aktualisiert:
- Das Enabling Environment
Was ein Agent braucht, bevor eine Factory ihm Arbeit zuteilt, wer diese Umgebung baut, warum die Laufzeitumgebung Security verantwortet und wie das Repo Feedback verkürzt.
Aktualisiert:
- Factory-Rollen und Pipeline
Wie Orchestratoren, Worker und Validatoren Arbeit durch eine gestufte Produktions-Pipeline bewegen.
Aktualisiert:
- Harness-Grundlagen
Die Komponenten und Kontrollschichten, die aus einem Modell einen verlässlichen Engineering-Agenten machen.
Aktualisiert:
- Harness-Pflege
Wie ihr Konfigurationsverfall verhindert, veraltete Maschinerie entfernt und Anti-Patterns im Harness erkennt.
Aktualisiert:
- Das Software-Factory-Pattern
Wie ihr eine Software Factory messt, was Teams mit einer laufenden Factory berichten und wo ihr mit dem Lesen anfangt, für Engineering-Führungskräfte, die das Modell abwägen.
Aktualisiert:
- Software Factories in Produktion: Belege
Berichtete Software Factories erreichen hohen autonomen Durchsatz dort, wo Spezifikationen, Tests und Umgebungen schon vor den Agenten stark waren. Die meisten Zahlen sind Selbstauskünfte von Anbietern oder Frontier Labs. Kosten, Review-Kapazität und langfristige Wartbarkeit bleiben die harten Grenzen.
Aktualisiert:
- Rollen und Wirtschaftlichkeit der Software Factory
In einer Software Factory bauen Engineers das System, das das Produkt baut. Erfolg misst der Anteil der Änderungen, die automatisch und zu bekannten Kosten live gehen. Softwareproduktion wandert so vom F&E-Aufwand in die Herstellungskosten, und jeder Dollar für Token muss einen Renditetest bestehen.
Aktualisiert:
- Arbeit und Orchestrierung
Wie Factories Arbeit abbilden, Agenten koordinieren, deterministische Gates setzen und ihren eigenen Harness verbessern.
Aktualisiert:
- Tools
Agentische Coding-Tools sind die CLIs, Editoren und autonomen Agents, die ein Modell auf eure Codebasis ansetzen, dazu die Protokolle und Modelle darunter. Mit jeder Modellgeneration gleichen sie sich weiter an. Dauerhaft lohnt sich deshalb der Harness, den ihr um ein Tool baut, nicht das Tool, das ihr lizenziert.
Aktualisiert:
- KI-Coding-Tools
KI-Coding-Tools gibt es in vier Bauformen: Terminal-CLIs, KI-native Editoren, autonome Agents und Enterprise-Plattformen. Wichtiger als die Marke ist, welche Generation von Tool ihr einführt, was die Evidenz über ihren Produktivitätseffekt sagt und wie sich ihr Pricing unter agentischen Workloads verhält.
Aktualisiert:
- Kontext und Produktivität
KI-Coding-Tools bremst weniger ihr Harness als der Kontext, den sie bekommen, und die gemessenen Produktivitätsgewinne liegen weit unter den Angaben der Anbieter. Kontrollierte Studien und Langzeit-Benchmarks zeigen moderate Gewinne beim Durchsatz, und KI verstärkt die vorhandene Engineering-Qualität eines Teams, statt sie zu ersetzen.
Aktualisiert:
- Preise für Agentic Coding
Agentic Coding wird nach Nutzung abgerechnet, nicht pro Seat. Ein Agent liest bei jedem Turn seinen wachsenden Kontext neu, deshalb skalieren die Kosten mit der Länge der Session statt mit der Zahl der Requests. Hersteller messen Agentenarbeit inzwischen in Compute Units oder Credits und lassen Autocomplete pauschal. Abrechnung pro Token über die API kann weit mehr kosten als ein Abo mit inkludierter Nutzung.
Aktualisiert:
- Sicherheit autonomer Coding-Agents
Ein Coding-Agent, der Dateien schreibt, Befehle ausführt und das Netzwerk erreicht, lässt sich gegen seine Nutzer:innen wenden. Schaltet eine Prompt Injection die Freigabe-Einstellungen des Agents um, wird daraus Remote Code Execution. Instruktionen im System-Prompt sind keine Sicherheitsgrenze, konkrete Opt-in-Kontrollen und eine Sandbox um den ganzen Prozess sind es.
Aktualisiert:
- Supervision und Drift
Wer Coding-Agents beaufsichtigt, braucht Kapazität für Verifikation und Review, und der Bedarf an dieser Kapazität wächst mit dem Output der Agents. Die dafür nötigen Coding-Skills verkümmern, wenn sich Entwickler:innen auf KI stützen. Teams halten die Qualität mit deterministischen Checks in CI, inferenziellen Reviews außerhalb davon, benannten Reviewer:innen mit Verantwortung für den Merge und weiterer Übung im Handwerk.
Aktualisiert:
- KI-Modelle und Inferenz
Welches Modell einen Agenten antreibt, wo es läuft und was jedes Token kostet, entscheidet, ob sich ein agentischer Workflow lohnt. Das Ergebnis hängt stärker am Harness um das Modell, an Context Management, Tool-Auswahl und Validierung, als daran, welches Frontier-Modell darunter sitzt.
Aktualisiert:
- Inference-Kosten und Infrastruktur
Agentische Workloads machen Inference-Kosten nutzungsabhängig: Parallele Agents und wachsender Kontext treiben den Token-Verbrauch. Die Rechnung hängt deshalb mehr an den Tokens pro abgeschlossenem Workflow als am Listenpreis pro Token. Einfache Aufgaben gehen an kleine Modelle, Frontier-Modelle bleiben der Arbeit vorbehalten, die sie braucht. So bleiben die Kosten im Rahmen.
Aktualisiert:
- Modellauswahl
Wählt ein Modell nach einem Test auf eurem eigenen Stack und euren Aufgaben, nicht nach seinem Leaderboard-Score. Coding-Benchmarks messen enge, Python-lastige, gut spezifizierte Issues, und die Fähigkeiten schwanken stark nach Sprache und Aufgabe. Mehr Hebel als die Jagd nach dem Top-Modell bringen Routing jeder Rolle an ein passendes Modell und Investitionen in Kontext und Validierung.
Aktualisiert:
- Structured Output
Structured Output heißt: Ein Modell antwortet in einer typisierten Form, die Code validieren kann, statt in Freitext, den Code parsen muss. Eine Schema-first-Schicht deklariert die Form als typisiertes Modell, prüft jede Antwort dagegen und fragt das Modell erneut, wenn die Validierung scheitert.
Aktualisiert:
- Claude Code
Claude Code ist ein Coding-Agent, gebaut als eine einfache Schleife über wenige Tools. Dadurch liegt der größte Hebel bei euch: wie ihr seinen Kontext steuert, wie ihr ihn promptet und wie ihr ihn mit Hooks, Skills, Subagents und MCP erweitert.
Aktualisiert:
- Claude-Code-Ökosystem
Claude Code kommt als dünner Harness über dem Modell. Den größten praktischen Hebel liefert deshalb das Ökosystem um seine Erweiterungspunkte: Plugins, Skills, Hooks, MCP-Server, Usage-Tracker, Routing-Proxies und Token-Optimierer. Dieselbe Offenheit macht dieses Ökosystem groß und unübersichtlich.
Aktualisiert:
- Skills und Subagenten schreiben
Unsere Position zum Schreiben von Skills und Subagenten für Claude Code: Auswahl zuerst, Evals vor Instruktionen, wenige gepflegte Skills und beide Leitfäden.
Aktualisiert:
- Skills schreiben
Wie ihr einen Skill schreibt, der zuverlässig auslöst und funktioniert, wie ihr ihn vor dem Ausliefern evaluiert und ob ein Agent ihn unbeaufsichtigt optimieren kann. Für Teams, die Claude Code erweitern.
Aktualisiert:
- Kontext- und Output-Schnittstellen
Der Kontextdruck sinkt, wenn jeder Turn weniger mitträgt und delegierte Arbeit in einem eigenen Fenster läuft: MCP-Server pro Session laden, CLAUDE.md kurz halten und das Fenster leeren, bevor es vernebelt. Auf der Output-Seite ist HTML zum praktischen Standard für Specs und Reports geworden, die Menschen lesen sollen.
Aktualisiert:
- Ökosystem und Erweiterungsmodell
Claude Code hält den Kern seines Harness schlank: ein einziger Loop, der die Planung dem Modell überlässt. Spezialisierung wandert in Plugins, MCP-Server, SDKs und Language Server. Native Features übernehmen laufend beliebte Erweiterungen, deshalb gehört jede Wahl einer Erweiterung regelmäßig auf den Prüfstand.
Aktualisiert:
- Thin Harness
Warum Claude Code seinen Kern-Loop klein hält und was das für alle bedeutet, die Plugins, MCP-Server oder andere Erweiterungen darauf bauen.
Aktualisiert:
- Evaluation und Wirtschaftlichkeit
Die Berichte darüber, was Claude Code leisten kann, eilen der Realität in Produktion voraus, und Evals auf euren eigenen historischen Aufgaben korrigieren das. Token-Kosten erklären viel vom Tool-Markt drumherum: Tracker, Routing-Proxys und Kompressoren gibt es, weil agentisches Coding anfragebasierte Preise gesprengt hat.
Aktualisiert:
- Context Engineering
Techniken für eine schlanke Claude-Code-Sitzung: was MCP-Server an Kontext kosten, Priming statt wachsender CLAUDE.md, Übergabe an frische Agenten, Compact oder Clear.
Aktualisiert:
- Prompt Engineering
Für alle, die Prompts für Claude Code schreiben: Formatstufen, ein Aufbau für agentische Prompts Abschnitt für Abschnitt und die Techniken, die Anthropic empfiehlt.
Aktualisiert:
- Effiziente Agent-Interfaces gestalten
Ein effizientes Agent-Interface hält Tool-Definitionen und Zwischendaten aus dem Kontext des Modells. Agents arbeiten besser, wenn sie Code gegen wenige aufgabenbezogene Tools schreiben oder eine bekannte CLI aufrufen, als wenn sie aus Dutzenden Tools wählen, die jeden API-Endpunkt kapseln.
Aktualisiert:
- MCP: Protokoll und Kontextkosten
Was MCP standardisiert, wer es nutzt und wie viel vom Kontextfenster seine Tool-Schemas belegen. Dazu Wege, Tools erst zu laden, wenn eine Aufgabe sie braucht.
Aktualisiert:
Nichts passt. Versuch ein kürzeres Wort oder ein anderes Thema.
Hier anfangen
-
Für Engineering-Leitungen
-
Für Entwickler:innen
-
Für Produktleute
Themen
-
Einstieg
Die ersten Wochen mit Coding-Agenten.
Alle 16 Seiten SchulungenAgentic Engineering for Developers and QA
-
Agentic Engineering
Wie Teams mit Agenten arbeiten, wenn Vibe Coding nicht mehr reicht.
- Architektur und Design
- Federated Context Platform für KI-Agenten im Unternehmen
- Memory und Context Engineering
Alle 32 Seiten SchulungenAgentic Engineering for Developers and QA
-
Belege
Was Studien über KI in der Softwareauslieferung herausfinden.
- KI-Produktivitätsstudien: METR, Stanford, DORA, Multitudes
- Amazon Cost to Serve Software (CTS-SW)
- Der DORA-Report zu KI-gestützter Entwicklung
Alle 8 Seiten SchulungenAgentic Engineering for Engineering and Product Leaders
-
Software Engineering
Werte und Prinzipien, die Agenten verstärken.
Alle 8 Seiten SchulungenAgentic Engineering for Developers and QA
-
Software Factories
Agenten liefern den Code, Menschen bauen das System drumherum.
Alle 17 Seiten SchulungenAgentic Software Factory: Advanced Team Training
-
Tools
Coding-Agenten, Modelle und der Harness, in dem sie laufen.
Alle 22 Seiten SchulungenAgentic Engineering for Developers and QA
-
Glossar
Jeder Begriff in ein paar Sätzen erklärt.
-
Weitere Themen
Produkt, Führung und Bücher, die wir empfehlen.