{"version":"https://jsonfeed.org/version/1","title":"INNOQ","home_page_url":"https://www.innoq.com/","feed_url":"https://www.innoq.com/en/feed.json","icon":"https://res.cloudinary.com/innoq/image/asset/favicon-1b518c5b5495aeba34b46ed6a1764b40.svg?_a=BACJ3SAE","favicon":"https://res.cloudinary.com/innoq/image/asset/favicon-1b518c5b5495aeba34b46ed6a1764b40.svg?_a=BACJ3SAE","items":[{"id":"https://www.innoq.com/en/talks/2026/10/ai-systems-architecture-2026/","url":"https://www.innoq.com/en/talks/2026/10/ai-systems-architecture-2026/","date_published":"2026-04-21T00:00:00.000+00:00","date_modified":"2026-04-21T16:38:34.754+02:00","author":[{"name":"Michael Seel","url":"https://www.innoq.com/en/staff/michael-seel/"},{"name":"Ruben Vitt","url":"https://www.innoq.com/en/staff/ruben-vitt/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eEin AI-Feature als Demo zum Laufen zu bringen ist nicht schwer. Ob es auch in Produktion funktioniert, entscheidet nicht der Prompt allein, sondern seine Einbettung ins System. Wer definiert den Vertrag zwischen Modell und Anwendung? Wer merkt, wenn die Qualität einbricht? Und welche Architekturentscheidungen machen den Unterschied zwischen Demo und Produktion?\u003c/p\u003e\n\n\u003cp\u003eIn diesem Workshop betrachten wir AI-Features auf drei Ebenen: als Feature, als Teil eines Systems und als Architekturthema. Wir zeigen, wie diese Ebenen zusammenwirken und worauf es ankommt, damit aus einer Demo ein tragfähiger Baustein in Produktion wird:\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003e1. Contract-first Design\u003c/strong\u003e - Die Schnittstelle zwischen Feature und System. Am Anfang steht der Vertrag, nicht der Prompt: Welche Daten muss das Modell strukturiert liefern, damit der Rest der Anwendung damit arbeiten kann?\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003e2. Prompt Engineering \u0026amp; Evaluation\u003c/strong\u003e - Die Qualitätssicherung des Features. Wer ohne Evals baut, testet am Nutzer. Wir zeigen, wie Evaluations als Quality Gate in die Pipeline integriert werden.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003e3. Control - Die Absicherung im System.\u003c/strong\u003e Tool-Security, Policy-Gates, Human-in-the-Loop und Approval-Mechanismen. Wer darf was auslösen, und wer muss freigeben?\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003e4. Observability \u0026amp; Betrieb\u003c/strong\u003e - Die Architekturperspektive. Nichtdeterministische Systeme brauchen Transparenz. Latenz, Kosten, Token-Verbrauch und Qualität sichtbar machen.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/07/wir-haben-doch-keine-zeit-oder-dwx-2026/","url":"https://www.innoq.com/en/talks/2026/07/wir-haben-doch-keine-zeit-oder-dwx-2026/","date_published":"2026-03-18T00:00:00.000+00:00","date_modified":"2026-03-18T12:11:56.533+01:00","author":[{"name":"Markus Harrer","url":"https://www.innoq.com/en/staff/markus-harrer/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eIn vielen Unternehmen herrscht permanenter Feature-Druck: immer mehr Funktionen, immer schneller, immer sofort. Doch während vermeintlich Zeit gespart wird, dauert es paradoxerweise immer länger, bis etwas fertig wird. Ständige Prioritätswechsel reißen Teams aus dem Tritt, Planungen verlieren jede Verbindlichkeit, und wertvolles Potenzial bleibt ungenutzt. Besonders die Softwarearchitektur leidet: Unter Zeitdruck wird an ihr gespart, langfristige Entscheidungen werden vertagt, und technische Schulden häufen sich an. Was kurzfristig „schnell” wirkt, macht die Entwicklung auf Dauer immer langsamer. Denn jede neue Änderung wird durch Komplexität, Workarounds und fehlende Klarheit ausgebremst.\u003c/p\u003e\n\n\u003cp\u003eIn diesem Vortrag wollen wir euch zeigen, warum hektisches Reagieren langfristig bremst und was ihr und euer Team dagegen tun könnt. Ihr nehmt Impulse mit, wie ihr Feature-Druck hinterfragen, Prioritäten bewusst setzen und durch Klarheit, Architekturarbeit und Fokussierung echte Geschwindigkeit erreichen könnt. Wir geben euch verschiedene Methoden mit, mit welchen ihr Euren Arbeitsalltag besser strukturieren und Zeit für die wichtigen Dinge schaffen könnt: Architekturarbeit, den Abbau von technischen Schulden und das Einbauen der richtigen Features.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/07/data-contracts-standards-und-tools-fuer-bessere-datenqualitaet-dwx-2026/","url":"https://www.innoq.com/en/talks/2026/07/data-contracts-standards-und-tools-fuer-bessere-datenqualitaet-dwx-2026/","date_published":"2026-03-18T00:00:00.000+00:00","date_modified":"2026-03-18T12:10:11.348+01:00","author":[{"name":"Jochen Christ","url":"https://www.innoq.com/en/staff/jochen-christ/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eEin Data Contract ist ein Dokument, das die Struktur, die Semantik, die Qualität und die Nutzungsbedingungen für den Austausch von Daten zwischen einem Datenanbieter und seinen Konsumenten spezifiziert. Mit dem Open Data Contract Standard gibt es nun auch einen einheitlichen Standard. Man kann ihn sich wie eine API vorstellen, nur eben für Daten.\u003c/p\u003e\n\n\u003cp\u003eData Contracts dienen auch der Kommunikation, um ein gemeinsames Verständnis darüber auszudrücken, wie Daten strukturiert sind und welche fachliche Bedeutung sie haben. Sie machen implizites Domänenwissen der Datenproduzenten und die Erwartungen der Datenkonsumenten explizit.\u003c/p\u003e\n\n\u003cp\u003eIn Produktion können Datenprodukte mithilfe von Data Contracts automatisiert getestet werden, um eine hohe Datenqualität für Datenkonsumenten sicherzustellen und so Vertrauen in Daten aufzubauen. Wir schauen uns an, wie das geht.\u003c/p\u003e\n\n\u003cp\u003eIn diesem Vortrag stellt Jochen Christ, TSC-Mitglied bei Bitol, den Open Data Contract Standard vor und zeigt, wie Data Contracts zur Sicherstellung hochwertiger Datenprodukte eingesetzt werden können.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/07/statische-codeanalyse-stolz-und-vorurteil-und-zombies-dwx-2026/","url":"https://www.innoq.com/en/talks/2026/07/statische-codeanalyse-stolz-und-vorurteil-und-zombies-dwx-2026/","date_published":"2026-03-18T00:00:00.000+00:00","date_modified":"2026-03-18T12:06:19.762+01:00","author":[{"name":"Benjamin Wolf","url":"https://www.innoq.com/en/staff/benjamin-wolf/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eStatische Codeanalyse soll dazu dienen, die Codequalität zu bewerten, damit wir sie kontinuierlich verbessern. Klingt in der Theorie hervorragend, jedoch sieht die Realität oft anders aus: Entwickler:innen fürchten die Bewertung, das Management interpretiert Zahlen falsch, und trotz des Mehraufwands gibt es immer wieder Programmierfehler im Code.\u003c/p\u003e\n\n\u003cp\u003eIn meinem Vortrag möchte ich euch die häufigsten Fehler bei der Verwendung statischer Codeanalyse zeigen, die mir regelmäßig in Projekten begegnen. Gemeinsam werden wir Lösungen und Tipps erarbeiten, um diese Fehler künftig zu vermeiden. Und wer weiß, vielleicht begegnen uns auch Zombies auf unserem Weg zur besseren Codequalität.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/06/cognitive-biases-im-software-engineering-warum-gute-architekt-innen-schlechte-entscheidungen-treffen-dwx-2026/","url":"https://www.innoq.com/en/talks/2026/06/cognitive-biases-im-software-engineering-warum-gute-architekt-innen-schlechte-entscheidungen-treffen-dwx-2026/","date_published":"2026-03-18T00:00:00.000+00:00","date_modified":"2026-03-18T12:12:46.839+01:00","author":[{"name":"Dr. Gernot Starke","url":"https://www.innoq.com/en/staff/gernot-starke/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eSoftwarearchitektur gilt als rationale Disziplin. In der Praxis entstehen zentrale Architekturentscheidungen jedoch selten rein logisch, sondern unter dem Einfluss systematischer Denkfehler. Kognitive Verzerrungen wie \u003cstrong\u003eConfirmation Bias\u003c/strong\u003e, \u003cstrong\u003eOptimism Bias\u003c/strong\u003e oder die \u003cstrong\u003eSunk Cost Fallacy\u003c/strong\u003e prägen Technologieauswahl, Aufwandsschätzungen, Migrationsentscheidungen und Teamdynamiken oft stärker, als uns bewusst ist.\u003c/p\u003e\n\n\u003cp\u003eDer Vortrag zeigt anhand realer Projektsituationen, wie solche Biases Entscheidungsprozesse unbemerkt lenken: Wir verteidigen vertraute Lösungen, unterschätzen Risiken, folgen Trends oder halten an Strukturen fest, weil bereits zu viel investiert wurde. Die Folgen reichen von technischer Verschuldung über gescheiterte Transformationen bis zu schwer wartbaren Architekturen.\u003c/p\u003e\n\n\u003cp\u003eStatt abstrakter Psychologie geht es um \u003cstrong\u003ekonkrete Muster aus dem Engineering-Alltag\u003c/strong\u003e und um \u003cstrong\u003epraktische Gegenmaßnahmen\u003c/strong\u003e, die sich im Architekturkontext bewährt haben. Dazu zählen strukturierte Entscheidungsformate, Pre-Mortem-Analysen, gezieltes Debiasing in Teams sowie einfache Interventionen, die Denkfehler früh sichtbar machen.\u003c/p\u003e\n\n\u003cp\u003eAlle Konzepte basieren auf etablierter Forschung aus Kognitionspsychologie und Neurowissenschaften und werden mit praxisnahen Beispielen verknüpft. Ziel sind bewusstere Entscheidungen im Team, Vermeidung von Denkfehlern, und damit insgesamt bessere Architekturen.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/06/agentic-software-modernization-2026/","url":"https://www.innoq.com/en/talks/2026/06/agentic-software-modernization-2026/","date_published":"2026-02-26T00:00:00.000+00:00","date_modified":"2026-02-26T15:46:29.081+01:00","author":[{"name":"Markus Harrer","url":"https://www.innoq.com/en/staff/markus-harrer/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eSoftwaremodernisierung auf Knopfdruck ist im Zeitalter von AI Agents der Traum vieler ITler. Ja, ein Agent kann heute schon eine Legacy Codebase über Nacht komplett neu strukturieren. Aber wer übernimmt ab dem nächsten Morgen die Verantwortung dafür?\u003c/p\u003e\n\n\u003cp\u003eIn diesem Vortrag zeigt Markus, wo agentische Ansätze in der Modernisierung von Softwaresystemen großen Nutzen stiften, aber auch, was ihnen für den nachhaltigen Erfolg fehlt: Techniken, welche AI Agents an die Leine nehmen. Dazu greifen wir auf bewährte Klassiker der Legacy-Code-Modernisierung zurück, welche agentische Workflows mehr verantwortbar machen wie etwa Seams zur Begrenzung des „Agent Blast Radius“, Characterization Testing zum Absichern des aktuellen Verhaltens und Fitness Functions zum messbaren Nachweis von Qualitätsverbesserungen. Dadurch liefern AI Agents weiterhin ein hohes Tempo, doch sie bleiben dank unserer Leitplanken auf der Spur. Denn am Ende zählt nicht, wie viel sich im Code bewegt, sondern ob das Legacy System wirklich vorankommt.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/06/das-kleine-1-1-der-sicherheitsarchitektur-2026/","url":"https://www.innoq.com/en/talks/2026/06/das-kleine-1-1-der-sicherheitsarchitektur-2026/","date_published":"2026-02-26T00:00:00.000+00:00","date_modified":"2026-02-26T15:45:05.222+01:00","author":[{"name":"Christoph Iserlohn","url":"https://www.innoq.com/en/staff/ci/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWebanwendungen sind einer ständigen Bedrohung ausgesetzt – sowohl durch altbekannte Sicherheitslücken, wie in den OWASP Top 10 beschrieben, als auch durch ständig neu entdeckte Angriffsvektoren. Um sich nicht im Klein-Klein der Implementierung von Abwehrmaßnahmen zu verheddern, ist es nötig, Websecurity als Architekturthema zu begreifen. Denn nachhaltig sicher kann ein System nur sein, wenn schon auf der Architekturebene die richtigen Entscheidungen getroffen werden.\u003c/p\u003e\n\n\u003cp\u003eWorauf dabei zu achten ist, erfahrt ihr in dieser Session.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/06/cloud-migration-entwicklung-einer-strategie-2026/","url":"https://www.innoq.com/en/talks/2026/06/cloud-migration-entwicklung-einer-strategie-2026/","date_published":"2026-02-26T00:00:00.000+00:00","date_modified":"2026-02-26T15:43:51.327+01:00","author":[{"name":"Anja Kammer","url":"https://www.innoq.com/en/staff/anja-kammer/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eDie Cloud-Migration ist oftmals eine notwendige Evolution und stellt Unternehmen vor essenzielle Entscheidungen: Optimierung bestehender Systeme, Neuentwicklung von Cloud-Native Architekturen und strukturelle Anpassungen im Unternehmen selbst. In dieser praxisorientierten Session werden die zentralen Eckpfeiler der Cloud-Migration beleuchtet: Organisation, Infrastruktur und Architektur.\u003c/p\u003e\n\n\u003cp\u003eIm Mittelpunkt steht die Planungsphase: Wie strukturiert man diese, dass daraus ein belastbarer Migrationsplan entsteht (Risiken, Voraussetzungen, Prioritäten, Migrationswellen). Bekannte Muster wie 6 R’s bieten einen strukturierten Rahmen, um zu evaluieren, welche Anwendungen fast unverändert migriert werden können und welche neu entwickelt oder komplett ersetzt werden müssen.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/06/garbage-in-ist-kein-schicksal-2026/","url":"https://www.innoq.com/en/talks/2026/06/garbage-in-ist-kein-schicksal-2026/","date_published":"2026-02-26T00:00:00.000+00:00","date_modified":"2026-02-26T15:40:00.137+01:00","author":[{"name":"Dr. Gernot Starke","url":"https://www.innoq.com/en/staff/gernot-starke/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWir haben alle schon mal unter „schlechten Anforderungen“ gelitten: Unklare Begriffe, wechselnde Prioritäten und wachsende Backlogs führen dazu, dass technische Entscheidungen auf falschen oder impliziten Annahmen beruhen. Die Folgen zeigen sich oft spät – als teure Refactorings, fragile Architekturen oder Produkte am Bedarf vorbei.\u003c/p\u003e\n\n\u003cp\u003eStatt zu klagen, zeigt euch REQ4ARC einen Perspektivwechsel auf: Ihr könnt als Entwicklungsteam einiges selbst tun, um Anforderungen systematisch zu verbessern und damit bessere Grundlagen für Architekturentscheidungen zu schaffen:\u003c/p\u003e\n\n\u003cp\u003eIch stelle euch diesen pragmatischen, entwicklungsnahen Ansatz für bessere Anforderungen vor, ohne Overhead, ohne Buzzwords, ohne neue Rollen.\u003c/p\u003e\n\n\u003cp\u003eWir greifen etablierte Modelle wie Twin Peaks und Three Amigos auf und reduzieren sie auf ein leichtgewichtiges, konsistentes Vorgehen rund um Kontext, Stakeholder, funktionale und Qualitätsanforderungen.\u003c/p\u003e\n\n\u003cp\u003eIhr bekommt konkrete Werkzeuge für bessere Gespräche, fundiertere Entscheidungen und langfristig robustere Systeme.\u003c/p\u003e\n\n\u003cp\u003eOhne Schuldzuweisungen, dafür aber mehr Klarheit, gemeinsame Sprache und wirksame Zusammenarbeit.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/06/code-wird-billig-architektur-entscheidend-2026/","url":"https://www.innoq.com/en/talks/2026/06/code-wird-billig-architektur-entscheidend-2026/","date_published":"2026-02-26T00:00:00.000+00:00","date_modified":"2026-02-26T15:32:52.541+01:00","author":[{"name":"Dr. Gernot Starke","url":"https://www.innoq.com/en/staff/gernot-starke/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWir produzieren Code heute schneller, als wir ihn lesen können – dank GenAI und agentischer Entwicklung. Doch genau hier droht eine Falle: KI-Agents haben das Erstellen von Code optimiert, ignorieren aber systemische Zusammenhänge. Die Folge: Komplexität, Abhängigkeiten und Betriebsrisiken steigen rasant.\u003c/p\u003e\n\n\u003cp\u003eDiese Keynote ist ein Impuls für unsere Profession. Wenn Code zur billigen Massenware wird, wird Denken im Gesamtkontext zur wertvollsten Währung. Architektur muss noch mehr das “lange gut bleiben” adressieren, das “schnell bauen” tritt in den Hintergrund.\u003c/p\u003e\n\n\u003cp\u003eLange Zeit hat es genügt, Anforderungen in brauchbare Technik zu übersetzen. Damit ist Schluss: Zukünftig gewinnt, wer Anforderungen schneller und präziser versteht, Systeme konsequent entkoppelt, Trade-offs transparent macht und als Übersetzer zwischen Maschinenraum und Management wirkt. Wer das ignoriert, baut künftig nur noch schneller Dinge, die niemand mehr warten kann.\u003c/p\u003e\n\n\u003cp\u003eIm Vortrag adressiere ich die Skills, die KI uns (noch) nicht abnehmen kann: ganzheitliches Denken, geschickte Domänenschnitte und die soziale Struktur von Teams. Ohne dieses solide methodische Fundament bauen wir technische Schulden mittlerweile schneller auf, als wir prompten können.\u003c/p\u003e\n\n\u003cp\u003eGenau deshalb wird Architekturarbeit zum Rückgrat moderner Software- und Systementwicklung. Lasst uns diese Konferenztage nutzen, um dieses Fundament gemeinsam zu schärfen.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/06/souveraenitaet-integration-und-foederation-2026/","url":"https://www.innoq.com/en/talks/2026/06/souveraenitaet-integration-und-foederation-2026/","date_published":"2026-02-26T00:00:00.000+00:00","date_modified":"2026-02-26T15:41:44.786+01:00","author":[{"name":"Phillip Ghadir","url":"https://www.innoq.com/en/staff/phillip-ghadir/"},{"name":"Till Schulte-Coerne","url":"https://www.innoq.com/en/staff/till-schulte-coerne/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eEine große Stärke des World Wide Webs liegt in dessen Dezentralisierung und Technologie-Agnostik bei gleichzeitiger Fülle von belastbaren Standard insbesondere für Browser. Das Web ermöglicht eine Integration auf dem Application-Layer, wie wenig andere Architekturstile. Der Hypermedia-Constraint kommt dabei auch der Integration von und mit\nKI-Systemen zugute.\u003c/p\u003e\n\n\u003cp\u003eDiese Session liefert sowohl erprobte Architektur-Präferenzen für gelungene Web-Anwendungen, als auch einen Ausblick, wie wir KI-Systemen kommunizieren können, wie sie Web-Ressourcen nutzen dürfen.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/06/slop-oder-top-von-vibe-coding-zu-ai-aided-software-engineering-2026/","url":"https://www.innoq.com/en/talks/2026/06/slop-oder-top-von-vibe-coding-zu-ai-aided-software-engineering-2026/","date_published":"2026-03-19T00:00:00.000+00:00","date_modified":"2026-03-19T15:41:59.351+01:00","author":[{"name":"Dominik Guhr","url":"https://www.innoq.com/en/staff/dominik-guhr/"},{"name":"Johannes Seitz","url":"https://www.innoq.com/en/staff/johannes-seitz/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003e“Schreib mir ein ERP-System. Mach keine Fehler.” Sieht so die Zukunft der Softwareentwicklung aus? Wir denken nicht. Moderne LLMs leisten Beachtliches, wenn sie agentisch Code generieren. Ein wichtiger Aspekt der Softwareentwicklung ist jedoch nicht das Schreiben des Codes, sondern die Entwicklung und Pflege eines (mentalen) Modells, das dem Softwaresystem zugrunde liegt.\u003c/p\u003e\n\n\u003cp\u003eDem “Slop” fehlt dieses Modell. Man möchte beim Review die Maschine packen, schütteln und schreien “WARUM?!?”. In diesem Talk möchten wir euch mit der alten Idee von “Programming as Theory Building” von Peter Nauer bekannt machen, denn eine solche Theorie trennt Slop von einer sauberen Codebasis.\u003c/p\u003e\n\n\u003cp\u003eWir zeigen euch in diesem Talk, wie diese Theorie reines Vibe Coding von AI Aided Software Engineering unterscheidet. Außerdem lernt ihr, welche Techniken vom kollaborativen Domain Modelling zum Architekturmodell ihr nutzen könnt, um eine Theorie gemeinsam mit Fachbereich und Softwareentwicklungsteam zu formulieren, und wie ihr einen Coding Agent prompten könnt, um eine Theorie – eure Theorie – in den Code zu integrieren.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/05/datenarchitektur-das-neue-rueckgrat-moderner-software/","url":"https://www.innoq.com/en/talks/2026/05/datenarchitektur-das-neue-rueckgrat-moderner-software/","date_published":"2026-03-20T00:00:00.000+00:00","date_modified":"2026-03-20T12:31:22.436+01:00","author":[{"name":"Dr. Gernot Starke","url":"https://www.innoq.com/en/staff/gernot-starke/"},{"name":"Dr. Simon Harrer","url":"https://www.innoq.com/en/staff/dr-simon-harrer/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eDaten sind das neue Gold” – dieser Satz war einmal das Mantra einer ganzen Generation von Softwareentwickler:innen. Doch während wir ihn heute noch zitieren, hat sich die Bedeutung von Daten fundamental verändert. In diesem Talk werfen wir einen Blick zurück und nach vorn: von den ersten datengetriebenen Systemen der 1960er über die Ära von Data Warehouses und NoSQL bis hin zu den heutigen Herausforderungen durch LLMs, Data Contracts und KI-gestützte Systeme. Wir diskutieren, warum Daten heute nicht mehr nur gesammelt, sondern verstanden, verknüpft und vertraglich definiert werden müssen – und wie sich dadurch Rollen, Verantwortung und Architekturprinzipien verändern. Takeaway für Teilnehmende:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eWie sich unser Verständnis von „Datenqualität” und „Ownership” im Zeitalter von KI wandelt\u003c/li\u003e\n\u003cli\u003eWarum Data Contracts und Semantik wichtiger werden als schiere Datenmenge\u003c/li\u003e\n\u003cli\u003eWelche Muster helfen, Datenarchitekturen robust und vertrauenswürdig zu gestalten Dieser Vortrag richtet sich an erfahrene Software Engineers, Data Architects und alle, die Systeme entwerfen, in denen Daten mehr sind als ein Nebenprodukt – sondern das Herz moderner Software.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/05/agentic-coding-in-the-wild-jug-ch-luzern-2026/","url":"https://www.innoq.com/en/talks/2026/05/agentic-coding-in-the-wild-jug-ch-luzern-2026/","date_published":"2026-03-12T00:00:00.000+00:00","date_modified":"2026-03-12T11:20:02.868+01:00","author":[{"name":"Ole Wendland","url":"https://www.innoq.com/en/staff/ole-wendland/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWie schlägt sich Agentic Coding in der Praxis? Welche Vorteile sind realistisch, aber auch welche neuen Probleme und Herausforderungen entstehen für das Team und die Organisation, wenn man erfolgreich sein will?\u003c/p\u003e\n\n\u003cp\u003eIn diesem Talk werfen wir einen ehrlichen Blick auf die Realität von Agentic Coding. Denn AI ist eben nicht perfekt: Geschwindigkeit, Massendatenverarbeitung, transaktionale Sicherheit und Zuverlässigkeit bleiben Domänen, in denen klassischer Code seine Stärken ausspielt. Gleichzeitig bietet Agentic Coding Hebel, die Performance zu steigern und Teams produktiver zu machen.\u003c/p\u003e\n\n\u003cp\u003eWir schauen uns an, wie der Agentic Loop funktioniert, warum Context Engineering so entscheidend ist und welche Features zur Verfügung stehen.\nIm Hauptteil geht es um Best Practices: Wie behalte ich als Entwickler die Kontrolle? Wie briefe ich einen Agenten richtig? Und warum gilt „Trust, but Verify” mehr denn je? Abschliessend beleuchten wir die Herausforderungen für Seniors, Juniors, Teams und die gesamte Organisation und werfen einen Blick auf strategische Investitionen, die sich auch dann noch lohnen, wenn sich die Technologie weiterentwickelt (oder Agents doch nur ein Hype ist :P).\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/05/agentic-coding-in-the-wild-jug-ch-2026/","url":"https://www.innoq.com/en/talks/2026/05/agentic-coding-in-the-wild-jug-ch-2026/","date_published":"2026-03-12T00:00:00.000+00:00","date_modified":"2026-03-12T11:18:00.987+01:00","author":[{"name":"Ole Wendland","url":"https://www.innoq.com/en/staff/ole-wendland/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWie schlägt sich Agentic Coding in der Praxis? Welche Vorteile sind realistisch, aber auch welche neuen Probleme und Herausforderungen entstehen für das Team und die Organisation, wenn man erfolgreich sein will?\u003c/p\u003e\n\n\u003cp\u003eIn diesem Talk werfen wir einen ehrlichen Blick auf die Realität von Agentic Coding. Denn AI ist eben nicht perfekt: Geschwindigkeit, Massendatenverarbeitung, transaktionale Sicherheit und Zuverlässigkeit bleiben Domänen, in denen klassischer Code seine Stärken ausspielt. Gleichzeitig bietet Agentic Coding Hebel, die Performance zu steigern und Teams produktiver zu machen.\u003c/p\u003e\n\n\u003cp\u003eWir schauen uns an, wie der Agentic Loop funktioniert, warum Context Engineering so entscheidend ist und welche Features zur Verfügung stehen.\nIm Hauptteil geht es um Best Practices: Wie behalte ich als Entwickler die Kontrolle? Wie briefe ich einen Agenten richtig? Und warum gilt „Trust, but Verify” mehr denn je? Abschliessend beleuchten wir die Herausforderungen für Seniors, Juniors, Teams und die gesamte Organisation und werfen einen Blick auf strategische Investitionen, die sich auch dann noch lohnen, wenn sich die Technologie weiterentwickelt (oder Agents doch nur ein Hype ist :P).\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/05/garbage-in-ist-kein-schicksal-dev-day-2026/","url":"https://www.innoq.com/en/talks/2026/05/garbage-in-ist-kein-schicksal-dev-day-2026/","date_published":"2026-02-26T00:00:00.000+00:00","date_modified":"2026-03-17T19:20:13.538+01:00","author":[{"name":"Dr. Gernot Starke","url":"https://www.innoq.com/en/staff/gernot-starke/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eUnklare Anforderungen führen zu technischen Entscheidungen durch falsche Annahmen – mit teuren Folgen für Architektur und Produkt.\u003c/p\u003e\n\n\u003cp\u003eDieser Vortrag zeigt einen pragmatischen Ansatz, mit dem Teams Anforderungen selbst systematisch klären und verbessern können, ohne Overhead oder Rollenverschiebung. Außerdem: pragmatische Hilfsmittel, die sich vielfach praktisch bewährt haben.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/04/innoq-fragezeit/","url":"https://www.innoq.com/en/talks/2026/04/innoq-fragezeit/","date_published":"2026-03-18T00:00:00.000+00:00","date_modified":"2026-03-18T12:16:34.769+01:00","author":[{"name":"Daniel Bornkessel","url":"https://www.innoq.com/en/staff/daniel-bornkessel/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eIn dieser Fragezeit geht es um Erfahrungen mit dynamischen Secrets, HashiCorp Vault als Platzhirsch, Kubernetes und bewährte Muster — also darum, was gut funktioniert, wo es hakt und was man besser lässt. Darüber möchte Daniel am 28. April mit Euch diskutieren.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/de/news/2026/04/digitale-souveraenitaet-beginnt-mit-resilienter-softwarearchitektur/","url":"https://www.innoq.com/de/news/2026/04/digitale-souveraenitaet-beginnt-mit-resilienter-softwarearchitektur/","date_published":"2026-04-22T00:00:00.000+00:00","date_modified":"2026-04-21T19:47:09.039+02:00","content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWie können Unternehmen ihre digitale Handlungsfähigkeit sichern – politisch, rechtlich und wirtschaftlich? Wir zeigen, warum Softwarearchitektur der entscheidende Hebel für digitale Souveränität ist, und liefern sieben konkrete Handlungsempfehlungen für IT-Entscheider:innen und Architekturteams.\u003c/p\u003e\n\u003cp\u003eDigitale Souveränität heißt nicht, alles selbst zu machen. Sie heißt, handlungsfähig zu bleiben – auch wenn sich politische, rechtliche oder wirtschaftliche Rahmenbedingungen plötzlich ändern. Das gelingt, wenn Sie Abhängigkeiten nicht zufällig, sondern bewusst eingehen. Der entscheidende Hebel dafür ist die Softwarearchitektur.\u003c/p\u003e\n\n\u003cp\u003eAuf unserer neuen \u003ca href=\"https://www.souveraen-durch-architektur.de\"\u003eWebsite\u003c/a\u003e zeigen wir in sieben konkreten Handlungsfeldern, wie Sie mit der richtigen Architektur die strategische Handlungsfähigkeit Ihres Unternehmens sichern.\u003c/p\u003e\n\n\u003ch3 id=\"sieben-handlungsfelder-fur-mehr-souveranitat\"\u003eSieben Handlungsfelder für mehr Souveränität\u003c/h3\u003e\n\n\u003cp\u003eWir zeigen, wo Architekturentscheidungen Souveränität ermöglichen:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eSoftwarearchitektur robust gestalten:\u003c/strong\u003e Systeme so aufbauen, dass Sie einzelne Teile unabhängig voneinander austauschen können.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eTransparenz schaffen:\u003c/strong\u003e Abhängigkeiten sichtbar machen, bevor Sie sie gezielt reduzieren.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eVendor Lock-in vermeiden:\u003c/strong\u003e Anbieter bewusst auswählen, sodass Sie, wenn nötig, wechseln können.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eTechnische Handlungsoptionen schaffen:\u003c/strong\u003e Abhängigkeiten nicht vermeiden, sondern isolieren und Wahlfreiheit sichern.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eKI souverän einsetzen:\u003c/strong\u003e Verstehen, welche Abhängigkeiten mit welchem KI-Modell einhergehen.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eTeam-Kompetenz aufbauen:\u003c/strong\u003e Menschen befähigen, Architekturentscheidungen eigenständig umzusetzen.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eCompliance und Resilienz sicherstellen:\u003c/strong\u003e Regulatorische Anforderungen von Anfang an in der Architektur verankern.\u003c/li\u003e\n\u003c/ul\u003e\n\n\r\n\n\u003cfigure\u003e\r\n\u003ca href=\"https://www.souveraen-durch-architektur.de\"\u003e\r\n\u003cimg alt=\"„Digitale Souveränität beginnt mit resilienter Softwarearchitektur“. Unterzeile zur Handlungsfähigkeit; INNOQ-Logo.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/fnddv18zueastv56c9tp7natdq7p?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/fnddv18zueastv56c9tp7natdq7p?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/fnddv18zueastv56c9tp7natdq7p?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/fnddv18zueastv56c9tp7natdq7p?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/fnddv18zueastv56c9tp7natdq7p?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/fnddv18zueastv56c9tp7natdq7p?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/fnddv18zueastv56c9tp7natdq7p?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/fnddv18zueastv56c9tp7natdq7p?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/fnddv18zueastv56c9tp7natdq7p?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003c/a\u003e\u003c/figure\u003e\r\n\n\u003ch3 id=\"fur-wen-ist-das-relevant\"\u003eFür wen ist das relevant?\u003c/h3\u003e\n\n\u003cp\u003eDie Inhalte richten sich an:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eStrategische Entscheider:innen\u003c/strong\u003e wie CTOs und CIOs, die Cloud-Strategie und Compliance verantworten\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eEnterprise-Architekt:innen und Architekturteams\u003c/strong\u003e, die den entscheidenden Hebel für Datensouveränität und Resilienz in der Hand halten\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eUmsetzungs-Verantwortliche\u003c/strong\u003e in Engineering und IT-Betrieb, die Team-Kompetenz aufbauen und pragmatische Veränderung gestalten\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch3 id=\"tiefer-einsteigen\"\u003eTiefer einsteigen\u003c/h3\u003e\n\n\u003cp\u003eNeben den sieben Handlungsempfehlungen bietet die Seite vertiefende Fachartikel unserer Kolleg:innen. Die Themen im Überblick:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eData \u0026amp; AI:\u003c/strong\u003e On-Premise-LLMs als Alternative zu US-Diensten, Europas Rückstand bei KI-Infrastruktur, europäische Datenschätze mit KI nutzbar machen, der EU Data Act und das Ende der Cloud-Monokultur\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eSoftwarearchitektur:\u003c/strong\u003e Warum die Architektur zählt, mit Enterprise-Architektur geopolitische Risiken meistern, Souveränität durch Standardsoftware\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eOrganisation \u0026amp; Governance:\u003c/strong\u003e Digitale Souveränität als Selbstverständnis in Teams, Governance-Methodik für Souveränität\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003ePlattformen \u0026amp; Infrastruktur:\u003c/strong\u003e Der Weg zur heterogenen Cloud-Plattform, Dateninventare im EU Data Act\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003clong-quote person=\"Gil Breth\" role=\"Senior Consultant, INNOQ \" avatar=\"https://res.cloudinary.com/innoq/image/upload/v1/uploads-production/v14agek8b97fdbdkudhvu7eo233o?_a=BACJ3SAE\"\u003e\r\n\n\u003cblockquote class=\"longquote\"\u003e\n\u003cspan class=\"longquote__zigzag\"\u003e\u003c/span\u003e\u003cp\u003eJede digitale Abhängigkeit ist eine Entscheidung. Die Frage ist nur, ob sie bewusst getroffen wurde.\u003c/p\u003e\n\u003cdiv class=\"longquote__avatar avatar avatar--sm\"\u003e\u003cimg class=\"avatar__image\" src=\"https://res.cloudinary.com/innoq/image/upload/v1/uploads-production/v14agek8b97fdbdkudhvu7eo233o?_a=BACJ3SAE\" alt=\"\"\u003e\u003c/div\u003e\n\u003ccite class=\"longquote__author\" itemprop=\"name\"\u003eGil Breth\u003c/cite\u003e\u003cspan class=\"longquote__role\" itemprop=\"jobTitle\"\u003eSenior Consultant, INNOQ \u003c/span\u003e\n\u003c/blockquote\u003e\n\n\u003c/long-quote\u003e\r\n\n\u003ch3 id=\"monatliche-souveranitatsrezepte\"\u003eMonatliche Souveränitätsrezepte\u003c/h3\u003e\n\n\u003cp\u003eInspiriert vom \u003ca href=\"https://di.day/de\"\u003eDigital Independence Day\u003c/a\u003e, der zu Rezepten für digitale Souveränität aufruft, teilen wir regelmäßig eigene Lösungsansätze zu Themen, die unsere Kunden bewegen – ab sofort jeden ersten Sonntag im Monat. Beim ersten Rezept unserer Reihe geht es um \u003ca href=\"https://www.souveraen-durch-architektur.de/artikel/ki-features-fur-jira-data-center-ohne-atlassian-cloud\"\u003e\u003cstrong\u003eKI-Features für Jira Data Center – ohne Atlassian Cloud\u003c/strong\u003e\u003c/a\u003e.\u003c/p\u003e\n\n\u003ch3 id=\"unser-angebot\"\u003eUnser Angebot\u003c/h3\u003e\n\n\u003cp\u003eWir begleiten Sie auf Ihrem Weg zur digitalen Souveränität – unabhängig davon, an welchem Punkt Sie stehen:\u003c/p\u003e\n\n\u003col\u003e\n\u003cli\u003eSouveränitäts-Check: In wenigen Tagen bewerten wir bestehende Abhängigkeiten, zeigen konkrete Alternativen auf und identifizieren Sofortmaßnahmen.\u003c/li\u003e\n\u003cli\u003eSie möchten tiefer einsteigen? Wir liefern Ihnen ein belastbares Zielbild und einen priorisierten Maßnahmenplan.\u003c/li\u003e\n\u003cli\u003eWir unterstützen Sie bei der konkreten Umsetzung – von der Technologieauswahl über die architektonische Integration bis zur Befähigung Ihrer Teams.\u003c/li\u003e\n\u003c/ol\u003e\n\n\u003cp\u003eJede Stufe ist einzeln buchbar.\u003c/p\u003e\n\n\u003cp\u003e\u003ca href=\"https://www.souveraen-durch-architektur.de/#angebot\"\u003e\u003cstrong\u003eMehr erfahren\u003c/strong\u003e\u003c/a\u003e\u003c/p\u003e\n\n\u003cdiv class=\"cta-section m-t-lg\"\u003e\r\n    \u003ch2\u003eDigitale Souveränit beginnt mit resilienter Softwarearchitektur\u003c/h2\u003e\r\n    \u003cp class=\"standalone\"\u003eWir zeigen Ihnen wie!\u003c/p\u003e\r\n    \u003ca class=\"btn btn--cta\" data-label=\"Zur Website\" href=\"https://www.souveraen-durch-architektur.de\"\u003eZur Website\u003c/a\u003e\r\n\u003c/div\u003e\r\n\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/04/no-constrain-no-gain-sibb-2026/","url":"https://www.innoq.com/en/talks/2026/04/no-constrain-no-gain-sibb-2026/","date_published":"2026-04-21T00:00:00.000+00:00","date_modified":"2026-04-21T09:37:37.636+02:00","author":[{"name":"Johannes Rave","url":"https://www.innoq.com/en/staff/johannes-rave/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eKI-Codierungsagenten sind bemerkenswert gut darin, Code zu erstellen. Ob dieser Code jedoch die tatsächlichen Anforderungen des Unternehmens widerspiegelt – und ob er auch sechs Monate später noch sinnvoll ist –, ist eine ganz andere Frage. Die Versuchung ist groß, dies als ein Problem der Eingabeaufforderung zu betrachten – dem Agenten mehr Kontext, bessere Anweisungen und klarere Ziele zu geben. Ein oft übersehener Hebel ist die Beachtung der Architektur.\u003c/p\u003e\n\n\u003cp\u003eWenn die Domänenlogik ihren eigenen, klar abgegrenzten Platz hat, getrennt von der technischen Infrastruktur um sie herum, geschieht etwas Interessantes: Der Agent bleibt fokussiert, der Mensch kann tatsächlich prüfen, was wichtig ist, und das Ganze bleibt offen für Änderungen, ohne dass eine Neuprogrammierung erforderlich ist.\u003c/p\u003e\n\n\u003cp\u003eDieser Vortrag stellt einen Ansatz vor, wie man dorthin gelangt – und wie einige gut platzierte Einschränkungen Ihnen Freiheit verschaffen können.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/de/podcast/189-ai-news-mythos-unter-verschluss/","url":"https://www.innoq.com/de/podcast/189-ai-news-mythos-unter-verschluss/","date_published":"2026-04-20T00:00:00.000+00:00","date_modified":"2026-04-20T12:15:18.554+02:00","author":[{"name":"Fabian Walther","url":"https://www.innoq.com/en/staff/fabian-walther/"},{"name":"Ole Wendland","url":"https://www.innoq.com/en/staff/ole-wendland/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\u003cp\u003eAnthropic hält sein „Mythos“-Modell zurück: Es soll Zero-Day-Lücken in kritischer Software wie OpenBSD und FFmpeg finden können, ist aber zu rechenintensiv für den Massenmarkt. Fabian Walther und Ole Wendland schauen in dieser Folge außerdem auf GLM 5.1, das chinesische Open-Weights-Modell, das zeigt, wie der US-Chip-Ban chinesische Hersteller zum Aufbau eigener Hardware-Kompetenz zwingt. Googles AI Edge Gallery demonstriert derweil, wie gut lokale Modelle heute schon auf dem Smartphone laufen und was das für den Datenschutz bedeutet. Außerdem: Warum gute Benchmark-Scores wenig über die tatsächliche Leistung von KI-Modellen im Alltag aussagen.\u003c/p\u003e\u003c/body\u003e\u003c/html\u003e\n","image":"https://hotshot.innoq.io/shoot?path=%2Fen%2Fpodcast%2F189-ai-news-mythos-unter-verschluss%2Fcover%2F%3Fheader%3D1\u0026selector=.cover\u0026padding=0"},{"id":"https://www.innoq.com/de/blog/2026/04/ai-cognitive-lens-domain-knowledge/","url":"https://www.innoq.com/de/blog/2026/04/ai-cognitive-lens-domain-knowledge/","date_published":"2026-04-20T00:00:00.000+00:00","date_modified":"2026-04-20T16:58:10.488+02:00","author":[{"name":"Daniel Westheide","url":"https://www.innoq.com/en/staff/daniel-westheide/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003e\u003cem\u003eDies ist der vierte Beitrag der Reihe „Developing with AI Through the Cognitive Lens“. Sie untersucht, wie KI-Werkzeuge beeinflussen, wie Entwickler:innen und Teams lernen, arbeiten und Expertise aufbauen. Auf Basis kognitionspsychologischer Forschung geht es darum, was passiert, wenn wir geistige Arbeit an KI delegieren. In diesem Beitrag weitet sich der Blick über das Programmieren hinaus auf das Requirements Engineering. Ziel der Reihe ist kein vorgefasstes Urteil über KI, sondern den kognitionswissenschaftlichen Befunden zu folgen, wohin sie führen. In diesem Fall führt das zu grundsätzlicher Skepsis gegenüber einer ganzen Klasse von Werkzeugen.\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eIn den bisherigen Beiträgen ging es darum, was die Kognitionspsychologie über hilfreiche und problematische Einsatzweisen von KI beim Programmieren sagt. Programmieren ist jedoch nur ein Teil der Softwareentwicklung. Zunehmend werden KI-Agenten auch für die Erhebung von Anforderungen eingesetzt. Marketingversprechen für Tools wie BMAD sprechen davon, dass statt Wochen nur noch Stunden für Requirements Engineering nötig sind. Können BMAD und andere Werkzeuge für spezifikationsgetriebene Entwicklung etablierte Methoden zur Anforderungserhebung tatsächlich ersetzen? Die Kognitionspsychologie hat dazu einiges zu sagen.\u003c/p\u003e\n\n\u003ch3 id=\"wie-bmad-und-andere-sdd-tools-funktionieren\"\u003eWie BMAD und andere SDD-Tools funktionieren\u003c/h3\u003e\n\n\u003cp\u003eTools wie BMAD versprechen, den Prozess des Requirements Engineering drastisch zu beschleunigen. Statt Wochen mit Workshops, Interviews und iterativer Verfeinerung führt ein KI-Agent Stakeholder durch einen strukturierten Erhebungsprozess und erstellt innerhalb weniger Stunden ein umfassendes Spezifikationsdokument. Buildmode.dev, einer der prominentesten Vertreter dieses Ansatzes, \u003ca href=\"https://buildmode.dev/blog/mastering-bmad-method-2025/\"\u003ebehauptet, die Anforderungserhebung zu reduzieren\u003c/a\u003e von „2–3 Wochen auf 6 Stunden“.\u003c/p\u003e\n\n\u003cp\u003eDer Ablauf beginnt meist mit einer Produktidee oder einer groben Vision. Ein KI-Agent, der die Rolle eines Business Analysts übernimmt (bei BMAD heißt er Mary), interviewt dann den Stakeholder oder die Domänenexpertin und stellt Fragen zu Nutzer:innen, Zielen, Randbedingungen und technischen Anforderungen. Aus den Antworten erzeugt er ein Spezifikationsdokument, das als Blaupause für die Implementierung dient. In ambitionierteren Setups wie BMAD zerlegen zusätzliche Agenten diese Spezifikation in Epics, Stories und Tasks, die wiederum eine weitere Schicht von Agenten umsetzt. Der Mensch wechselt vom Ausführen der Arbeit hin zum Liefern von Domänenwissen und zum Reviewen der Ergebnisse.\u003c/p\u003e\n\n\u003cp\u003eDas wirkt auf den ersten Blick attraktiv, insbesondere für alle, die schon in langwierigen Requirements-Workshops gesessen haben, deren Ergebnis vor allem aus Annahmen bestand, die als Entscheidungen formuliert wurden. Wenn ein Agent denselben Job schneller und strukturierter erledigt, warum sollte man ihn nicht einsetzen?\u003c/p\u003e\n\n\u003ch3 id=\"das-extraktionsparadigma\"\u003eDas Extraktionsparadigma\u003c/h3\u003e\n\n\u003cp\u003eAllen diesen Tools liegt eine implizite Annahme über die Natur von Domänenwissen zugrunde: Es befindet sich in den Köpfen von Stakeholdern und Expert und muss nur abgerufen werden. Die richtigen Fragen, in der richtigen Reihenfolge gestellt, bringen es ans Licht. Der Agent in der Rolle des Business Analysts agiert dabei wie ein besonders systematischer, geduldiger und konsequenter Interviewer. In dieser Logik folgt alles dem Paradigma der Extraktion: Wissen ist eine Ressource, die gefördert wird, der Mensch ist das Vorkommen.\u003c/p\u003e\n\n\u003cp\u003eDiese Annahme ist so tief im Workflow verankert, dass sie selten explizit gemacht wird. Gelegentlich passiert es doch. Der oben erwähnte Beitrag von Buildmode.dev beschreibt den eigenen Ansatz als Ersatz für „iterative discovery“. Dieser Begriff impliziert, dass Anforderungen sich über Zeit entwickeln, durch Feedback, Umsetzung und Lernen. Wer das ersetzen will, geht davon aus, dass das Wissen bereits vollständig vorhanden ist und nur effizient abgerufen werden muss.\u003c/p\u003e\n\n\u003cp\u003eDie meisten Tools bleiben an dieser Stelle stehen und behandeln den Menschen als unvollkommene, aber akzeptable Quelle. Einige gehen weiter. \u003ca href=\"https://github.com/Q00/ouroboros\"\u003eOuroboros\u003c/a\u003e, ein Agent-Framework, dessen \u003ca href=\"https://github.com/Q00/ouroboros/blob/625dec9499e812c62579334773c59b799200f195/README.md\"\u003ealtes README\u003c/a\u003e unverblümt feststellte, dass „HUMANS ARE NOT RATIONAL“, zieht die nächste Konsequenz: Wenn Menschen nicht zuverlässig ausdrücken können, was sie wissen, liegt das Problem nicht an der Methode der Extraktion, sondern am Menschen.\u003c/p\u003e\n\n\u003ch3 id=\"was-die-kognitionswissenschaft-dazu-sagt\"\u003eWas die Kognitionswissenschaft dazu sagt\u003c/h3\u003e\n\n\u003cp\u003eMichael Polanyis Feststellung, dass „wir mehr wissen, als wir sagen können“, bringt das Problem prägnant auf den Punkt. In „The Tacit Dimension“ (1966) argumentiert er, dass ein großer Teil dessen, was Expert wissen, nicht bewusst zugänglich ist und daher nicht artikuliert werden kann. Dieses implizite oder stille Wissen steht im Gegensatz zu explizitem Wissen.\u003c/p\u003e\n\n\u003cp\u003eWenn eine erfahrene Domänenexpertin ihren Arbeitsprozess beschreibt, lässt sie zwangsläufig Dinge aus, weil sie sich ihres Wissens nicht bewusst ist. Dazu gehören etwa Schritte, die sie bei bestimmten Sonderfällen immer ausführt, oder implizite Prüfungen, die sie vornimmt, bevor sie ein Problem eskaliert. Solche Aspekte tauchen in strukturierten Interviews oft nicht auf, weil sie längst unterhalb der Schwelle bewusster Reflexion verankert sind.\u003c/p\u003e\n\n\u003cp\u003eDas SECI-Modell von Nonaka fügt eine weitere Dimension hinzu. Implizites Wissen ist nicht nur schwer zu formulieren, sondern grundsätzlich sozial. Wissen entsteht in Organisationen durch Zyklen aus Sozialisation, Externalisierung, Kombination und Internalisierung. Diese Prozesse benötigen gemeinsamen Kontext, Vertrauen und Zeit.\u003c/p\u003e\n\n\u003cp\u003eEntscheidend ist: Die Methoden, mit denen implizites Wissen tatsächlich sichtbar wird, basieren nicht primär auf Interviews. Sie setzen auf gemeinsame Praxis und direkte Beobachtung. Wenn jemand über die Schulter schaut und fragt: „Warum hast du das gerade so gemacht?“, werden implizite Annahmen deutlich, die in keinem Fragebogen auftauchen würden. Ein KI-Agent, der ein textbasiertes Interview führt, ist per Definition nicht Teil dieses sozialen Gefüges.\u003c/p\u003e\n\n\u003cp\u003eEine dritte Dimension, die im Requirements Engineering selten berücksichtigt wird, ist Zeit. Graham Wallas beschreibt in seinem Modell kreativen Denkens die Inkubationsphase als zentral. Das bedeutet, dass das Gehirn auch außerhalb bewusster Aufmerksamkeit an Problemen weiterarbeitet. Studien zeigen, dass etwa REM-Schlaf die Fähigkeit verbessert, Informationen zu verknüpfen und nicht offensichtliche Zusammenhänge zu erkennen.\u003c/p\u003e\n\n\u003cp\u003eFür die Anforderungserhebung heißt das: Einige der wertvollsten Einsichten lassen sich nicht planen. Sie entstehen unter der Dusche oder mitten in der Nacht. Ein sechsstündiges Interview mit einem KI-Agenten bietet keinen Raum für solche Prozesse. Es verkürzt diese Phase nicht, es streicht sie vollständig.\u003c/p\u003e\n\n\u003cp\u003eDiese drei Perspektiven führen zu derselben Schlussfolgerung: Das Extraktionsparadigma missversteht die Natur dessen, was es zu gewinnen versucht. Domänenwissen ist keine statische Ressource. Es ist implizit, sozial eingebettet und über die Zeit verteilt. Methoden, die diese Eigenschaften ignorieren, verfehlen genau das Wissen, auf das es ankommt.\u003c/p\u003e\n\n\u003ch3 id=\"wie-implizites-wissen-explizit-wird\"\u003eWie implizites Wissen explizit wird\u003c/h3\u003e\n\n\u003cp\u003eDas Problem ist nicht neu, und in der Softwareentwicklung gibt es etablierte Ansätze, die damit umgehen. Domain Storytelling etwa nutzt gemeinsame Erzählformate, in denen Domänenexpert ihre Arbeit schildern, während eine Moderation die Inhalte visuell festhält. So werden Sprache, Rollen und Abläufe sichtbar, die tatsächlich relevant sind. Der Ansatz funktioniert, weil er eine gemeinsame Situation schafft: Alle Beteiligten arbeiten gleichzeitig am selben Verständnis, Missverständnisse werden sofort sichtbar.\u003c/p\u003e\n\n\u003cp\u003eÄhnlich funktioniert Event Storming. Hier kommen Entwickler und Domänenexpert rund um eine gemeinsame Zeitleiste von Domänenereignissen zusammen. Unterschiedliche Perspektiven treffen aufeinander, Reibung entsteht, und genau daraus ergeben sich Erkenntnisse, die keine einzelne Person allein hätte formulieren können.\u003c/p\u003e\n\n\u003cp\u003eBeiden Ansätzen liegt eine Annahme zugrunde, die dem Extraktionsparadigma widerspricht: Domänenwissen existiert, wird aber erst im Austausch, durch Iteration und gemeinsame Arbeit explizit.\u003c/p\u003e\n\n\u003cp\u003eDomain-Driven Design wird gelegentlich so interpretiert, als plädiere es für eine umfassende Modellierung der Domäne im Vorfeld. Martin Fowler widerspricht dem in seinem Vorwort zu Eric Evans’ Buch ausdrücklich. Starke Domänenmodelle entstehen über Zeit, und selbst erfahrene Modellierer entwickeln ihre besten Ideen oft erst nach den ersten Releases. Domain-Driven Design war nie als Rechtfertigung für Big Design Up Front gedacht, sondern als Ansatz für eine kontinuierliche, iterative Auseinandersetzung mit der Domäne über den gesamten Lebenszyklus eines Systems hinweg. Ein großer Teil des relevanten Wissens entsteht spät und wird durch die Erfahrung im Bau und Betrieb des Systems erarbeitet.\u003c/p\u003e\n\n\u003cp\u003eGenau das lässt sich in einer sechsstündigen Erhebung nicht abbilden.\u003c/p\u003e\n\n\u003ch3 id=\"fazit\"\u003eFazit\u003c/h3\u003e\n\n\u003cp\u003eDie Logik des Extraktionsparadigmas, zu Ende gedacht, bleibt nicht bei besseren Interviews stehen. Ouroboros, das Agent-Framework, das ich oben erwähnt habe, macht den nächsten Schritt explizit. Das Problem ist nicht die Methode, sondern der Mensch. Die vorgeschlagene Lösung besteht darin, den Menschen zu „reparieren“, damit er klarer, konsistenter und vollständiger kommuniziert, kurz: leichter von Maschinen verarbeitet werden kann.\u003c/p\u003e\n\n\u003cp\u003eHier zeigt sich der sogenannte \u003ca href=\"https://pluralistic.net/2025/12/05/pop-that-bubble/#u-washington\"\u003eReverse Centaur\u003c/a\u003e in der Praxis. Während beim klassischen Centaur der Mensch die Maschine steuert, hat sich das Verhältnis umgekehrt. Die Maschine setzt den Rahmen, definiert Kategorien und stellt die Fragen. Die Aufgabe des Menschen besteht darin, sich in diese Struktur einzufügen. BMAD erreicht das nicht durch Zwang, sondern durch den Eindruck von Unterstützung: ein geführter Prozess, strukturierte Fragen, ein klares Ergebnis. Gefordert wird keine andere Denkweise, sondern die Anpassung an einen Ablauf, der maschinenlesbare Antworten belohnt und keinen Raum für Unschärfe, Vorläufigkeit oder implizites Wissen lässt.\u003c/p\u003e\n\n\u003cp\u003eDiese Verschiebung ist kein Zufall, sondern die konsequente Folge eines Paradigmas, das Wissen als extrahierbare Ressource betrachtet, statt als Fähigkeit, die sich entwickelt. Dieses Paradigma beginnt nicht bei BMAD oder Ouroboros. Große Sprachmodelle sind selbst Ausdruck davon: trainiert auf dem akkumulierten, verschriftlichten Wissen der Menschheit, verdichtet in einem statistischen Modell, ohne Zustimmung oder Vergütung derjenigen, die dieses Wissen hervorgebracht haben. BMAD und Ouroboros führen diese Logik lediglich weiter, von der Extraktion menschlichen Wissens in Modelle hin zur Extraktion von Domänenwissen in Spezifikationen und schließlich zur schrittweisen Anpassung des Menschen an die Anforderungen der Maschine.\u003c/p\u003e\n\n\u003cp\u003eDie zentrale Frage ist daher keine technische, sondern eine der Richtung. Technologie hat schon immer verändert, wie Menschen arbeiten und denken. Neu ist das nicht. Entscheidend ist, ob diese Anpassung einseitig verläuft: wenn vom Menschen erwartet wird, für die Maschine lesbarer zu werden, während die Maschine nicht in gleichem Maß lernt, sich am Menschen auszurichten.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/u6bu8ao4f1zwve0uj4gaeq0ymji7?_a=BACJ3SAE"},{"id":"https://www.innoq.com/en/blog/2026/04/ai-cognitive-lens-domain-knowledge/","url":"https://www.innoq.com/en/blog/2026/04/ai-cognitive-lens-domain-knowledge/","date_published":"2026-04-20T00:00:00.000+00:00","date_modified":"2026-04-20T16:59:20.813+02:00","author":[{"name":"Daniel Westheide","url":"https://www.innoq.com/en/staff/daniel-westheide/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003e\u003cem\u003eThis is the fourth post in “Developing with AI Through the Cognitive Lens,” a series exploring how AI tools affect the way programmers and development teams learn, work, and build expertise. Drawing on cognitive psychology research, this series examines what happens when we delegate cognitive work to AI. In this post, the lens widens beyond coding to requirements engineering. The goal of the series isn’t to arrive at a predetermined verdict on AI, but to follow the cognitive evidence wherever it leads. Sometimes, as in this post, it leads to fundamental skepticism about a whole class of tools.\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eIn the previous posts of this series, we focused on what cognitive psychology can tell us about beneficial and harmful ways to use AI for coding. But coding is only a small part of software development. Increasingly, AI agents are being put to use for eliciting requirements. Marketing claims for tools like BMAD speak of hours instead of weeks spent on requirements engineering. Can BMAD and other tools for spec-driven development really replace established methods of learning about requirements? Cognitive psychology, it turns out, has quite a lot to say about this.\u003c/p\u003e\n\n\u003ch3 id=\"how-bmad-and-other-sdd-tools-work\"\u003eHow BMAD and other SDD tools work\u003c/h3\u003e\n\n\u003cp\u003eTools like BMAD promise to drastically speed up the requirements engineering process. Instead of weeks of workshops, interviews, and iterative refinement, an AI agent guides stakeholders through a structured elicitation process and produces a comprehensive specification document in a matter of hours. Buildmode.dev, one of the more prominent advocates of this approach, \u003ca href=\"https://buildmode.dev/blog/mastering-bmad-method-2025/\"\u003eclaims to reduce requirements discovery\u003c/a\u003e from “2–3 weeks to 6 hours.”\u003c/p\u003e\n\n\u003cp\u003eThe workflow usually starts with a product idea or a rough vision. Acting in the role of a business analyst, an AI agent, called Mary in the case of BMAD, then interviews the stakeholder or domain expert, asking questions about users, goals, constraints, and technical requirement. It turns the answers into a specification document that serves as the blueprint for implementation. In more ambitious setups like BMAD, additional agents decompose this specification into epics, stories, and tasks, which yet another layer of agents implements. The human moves from doing the work to providing domain knowledge and reviewing the output.\u003c/p\u003e\n\n\u003cp\u003eAll this can sound very appealing, especially to anyone who has sat through lengthy requirements workshops that seemed to produce little more than a long list of assumptions dressed up as decisions. If an agent can do the same job faster and more systematically, why wouldn’t you use it?\u003c/p\u003e\n\n\u003ch3 id=\"the-extraction-paradigm\"\u003eThe extraction paradigm\u003c/h3\u003e\n\n\u003cp\u003eWhat these tools have in common is an implicit assumption about the nature of domain knowledge: that it exists in the heads of stakeholders and domain experts, waiting to be retrieved. The right questions, asked in the right order, will bring it to the surface. The business analyst agent has the role of a skilled interviewer, it is systematic, thorough, patient, and, in a way, relentless. With this assumption, the tools follow a paradigm of extraction. Knowledge is seen as a resource to be mined, the human as the deposit.\u003c/p\u003e\n\n\u003cp\u003eThis assumption is so deeply embedded in the workflow that it rarely gets stated explicitly. But occasionally it does. The Buildmode.dev post mentioned above describes their approach as replacing “iterative discovery”. Iterative discovery implies that requirements emerge over time, through feedback, building and learning. Replacing it means believing that the knowledge is already there, fully formed, and only needs to be drawn out efficiently.\u003c/p\u003e\n\n\u003cp\u003eMost tools stop here and leave the human as an imperfect but tolerable source. Some go further. \u003ca href=\"https://github.com/Q00/ouroboros\"\u003eOuroboros\u003c/a\u003e, an agent framework whose \u003ca href=\"https://github.com/Q00/ouroboros/blob/625dec9499e812c62579334773c59b799200f195/README.md\"\u003eold README\u003c/a\u003e stated bluntly that “HUMANS ARE NOT RATIONAL,” takes the logical next step: if humans cannot reliably articulate what they know, the problem is not the extraction technique. The problem is the human.\u003c/p\u003e\n\n\u003ch3 id=\"what-cognitive-science-tells-us\"\u003eWhat cognitive science tells us\u003c/h3\u003e\n\n\u003cp\u003eMichael Polanyi’s observation that “we can know more than we can tell” is probably the most concise summary of the problem. In \u003ca href=\"https://www.innoq.com/en/blog/2026/04/ai-cognitive-lens-domain-knowledge/#fn:1\" id=\"fnref:1\" title=\"see footnote\" class=\"footnote\"\u003e[1]\u003c/a\u003e: The Tacit Dimension (1966), Polanyi argues that much of what experts know is not consciously accessible and can thus not be articulated. This is implicit or tacit knowledge, in contract to explicit knowledge.\u003c/p\u003e\n\n\u003cp\u003eWhen an experienced domain expert describes her process to an interviewer, she will inevitably leave things out because she does not know she knows them. Some good candidates for this are the steps she always takes when dealing with a particular edge case, or the implicit check she runs before escalating an issue. There is a good chance that neither of these will surface in a structured interview, because they have long since been internalised below the threshold of conscious reflection.\u003c/p\u003e\n\n\u003cp\u003eThe SECI model described by \u003ca href=\"https://www.innoq.com/en/blog/2026/04/ai-cognitive-lens-domain-knowledge/#fn:2\" id=\"fnref:2\" title=\"see footnote\" class=\"footnote\"\u003e[2]\u003c/a\u003e: Nonaka (1991) adds another dimension. Tacit knowledge is not merely hard to articulate, it’s fundamentally social. Knowledge creation in organisations happens through cycles of socialisation, externalisation, combination, and internalisation. These processes require a shared context, trust, and time.\u003c/p\u003e\n\n\u003cp\u003eThe important point is that the techniques that actually work for making tacit knowledge explicit are not interview-based. They rely on shared practice and direct observation. For instance, a co-worker who watches over someone’s shoulder and asks “why did you do that just now?” is far more likely to surface implicit knowledge than any structured questioning. An AI agent conducting a text-based interview is, by definition, outside this social fabric.\u003c/p\u003e\n\n\u003cp\u003eThere is a third dimension that rarely enters the requirements engineering discussion: time. Graham Wallas’s classic model of creative cognition \u003ca href=\"https://www.innoq.com/en/blog/2026/04/ai-cognitive-lens-domain-knowledge/#fn:3\" id=\"fnref:3\" title=\"see footnote\" class=\"footnote\"\u003e[3]\u003c/a\u003e identified incubation as essential to insight. Incubation refers to the fact that the mind continues working on problems below the threshold of conscious attention. \u003ca href=\"https://www.innoq.com/en/blog/2026/04/ai-cognitive-lens-domain-knowledge/#fn:4\" id=\"fnref:4\" title=\"see footnote\" class=\"footnote\"\u003e[4]\u003c/a\u003e: Cai et al. (2009) provided empirical support for this in a study showing that REM sleep enhances the ability to integrate information and recognise non-obvious connections.\u003c/p\u003e\n\n\u003cp\u003eWhat does this mean for requirements work? First and foremost, we need to accept that some of the most valuable domain insights cannot be scheduled. They arrive when an expert is in the shower, or wakes up at 3am with sudden clarity about why the current process is broken. A six-hour interview session with an AI agent has no room for incubation. It does not compress this phase, it eliminates it.\u003c/p\u003e\n\n\u003cp\u003eTaken together, these three dimensions of evidence point to the same conclusion: the extraction paradigm misunderstands the nature of what it is trying to extract. Domain knowledge is not a static deposit waiting to be mined. It’s tacit, social, and temporally distributed. Any elicitation method that ignores these properties will miss the knowledge that matters most.\u003c/p\u003e\n\n\u003ch3 id=\"how-to-make-tacit-knowledge-explicit\"\u003eHow to make tacit knowledge explicit\u003c/h3\u003e\n\n\u003cp\u003eThis is not a new problem, and the software development community has developed methods that take it seriously. Domain Storytelling, for instance, uses collaborative narrative sessions where domain experts tell stories about their work while a facilitator captures them in a visual notation to surface the language, the actors, and the workflows that actually matter. The method works because it creates a shared situation: experts and developers are in the same room, the story unfolds in real time, and misunderstandings become visible immediately. Similarly, Event Storming brings together developers and domain experts around a shared timeline of domain events, relying on the productive friction of different perspectives colliding to reveal what no single participant could have articulated alone.\u003c/p\u003e\n\n\u003cp\u003eThese methods share a common assumption that stands in direct contrast to the extraction paradigm: domain knowledge exists — but it becomes explicit through multiple conversations and iterations, not in advance of them.\u003c/p\u003e\n\n\u003cp\u003eDomain-Driven Design is sometimes misread as an argument for thorough upfront domain modelling before implementation begins. Martin Fowler’s foreword to Eric Evans’s original book \u003ca href=\"https://www.innoq.com/en/blog/2026/04/ai-cognitive-lens-domain-knowledge/#fn:5\" id=\"fnref:5\" title=\"see footnote\" class=\"footnote\"\u003e[5]\u003c/a\u003e corrects this directly. Fowler writes that powerful domain models evolve over time, and that even the most experienced modellers find their best ideas emerge after the initial releases of a system. Domain-driven design was never a license for big upfront design. It has always been meant as a method of sustained, iterative engagement with the domain throughout the life of a project. A lot of important knowledge arrives late, earned through the experience of building and using the system.\u003c/p\u003e\n\n\u003cp\u003eThis is precisely what a six-hour elicitation session cannot buy.\u003c/p\u003e\n\n\u003ch3 id=\"conclusion\"\u003eConclusion\u003c/h3\u003e\n\n\u003cp\u003eThe logic of the extraction paradigm, followed to its conclusion, does not stop at better interviews. Ouroboros, the agent framework I mentioned earlier, makes the next step explicit. The problem, it concludes, is not the extraction technique, it is the human. Its proposed solution is that it “fixes the human, not the machine.” The improved human is one who communicates more clearly, more consistently, more completely. One who, in short, is easier for a machine to process.\u003c/p\u003e\n\n\u003cp\u003eThis is what the \u003ca href=\"https://pluralistic.net/2025/12/05/pop-that-bubble/#u-washington\"\u003eReverse Centaur\u003c/a\u003e looks like in practice. The classical centaur (human judgment directing machine capability) has quietly inverted. The machine sets the agenda, defines the categories, asks the questions. The human’s job is to fit into the structure the machine provides. BMAD does not do this through coercion. It does it through the appearance of helpfulness: a guided process, structured questions, a clear output. You aren’t asked to think differently. You’re simply led through a workflow that rewards machine-readable answers and has no place for the ambiguous, the half-formed, or the tacit that cannot be articulated yet.\u003c/p\u003e\n\n\u003cp\u003eThis inversion is not an accident. It’s the natural endpoint of a paradigm that treats knowledge as a resource to be extracted rather than a capability to be developed. And that paradigm did not begin with BMAD or Ouroboros. Large language models are themselves its most ambitious expression: trained on the accumulated written knowledge and culture of humanity, compressed into a statistical model, without the consent or compensation of those who produced it. BMAD and Ouroboros are not outliers. They are the same logic applied one step further, from extracting human knowledge into a model, to extracting domain knowledge into a specification, to gradually reshaping the human who provides it into something the model can more readily use.\u003c/p\u003e\n\n\u003cp\u003eThe question this raises is not primarily technical. It is about the direction of adaptation. Technology has always changed how people work and think. That’s old news. What is worth noticing is when the adaptation runs in one direction only: when the human is expected to become more legible to the machine, while the machine is not expected to become more capable of meeting the human where she is.\u003c/p\u003e\n\n\u003cfoot-notes class=\"footnotes\"\u003e\n\n\u003col class=\"footnotes__list\"\u003e\n\n\u003cli id=\"fn:1\"\u003e\n\u003cp\u003ePolanyi, M. (1966). The Tacit Dimension. Doubleday. \u003ca href=\"https://www.innoq.com/en/blog/2026/04/ai-cognitive-lens-domain-knowledge/#fnref:1\" title=\"return to body\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003cli id=\"fn:2\"\u003e\n\u003cp\u003eNonaka, I. (1991). The knowledge-creating company. Harvard Business Review, 69(6), 96–104. \u003ca href=\"https://www.innoq.com/en/blog/2026/04/ai-cognitive-lens-domain-knowledge/#fnref:2\" title=\"return to body\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003cli id=\"fn:3\"\u003e\n\u003cp\u003eWallas, G. (1926). The Art of Thought. Harcourt Brace. \u003ca href=\"https://www.innoq.com/en/blog/2026/04/ai-cognitive-lens-domain-knowledge/#fnref:3\" title=\"return to body\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003cli id=\"fn:4\"\u003e\n\u003cp\u003eCai, D. J., Mednick, S. A., Harrison, E. M., Kanady, J. C., \u0026amp; Mednick, S. C. (2009). REM, not incubation, improves creativity by priming associative networks. Proceedings of the National Academy of Sciences, 106(25), 10130–10134. \u003ca href=\"https://www.innoq.com/en/blog/2026/04/ai-cognitive-lens-domain-knowledge/#fnref:4\" title=\"return to body\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003cli id=\"fn:5\"\u003e\n\u003cp\u003eEvans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley. (Foreword by Martin Fowler) \u003ca href=\"https://www.innoq.com/en/blog/2026/04/ai-cognitive-lens-domain-knowledge/#fnref:5\" title=\"return to body\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003c/ol\u003e\n\u003c/foot-notes\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/g3lvp67thwweayhs73nn9y5dcugu?_a=BACJ3SAE"},{"id":"https://www.innoq.com/en/blog/2026/04/vom-vibe-coder-zum-agentic-engineer/","url":"https://www.innoq.com/en/blog/2026/04/vom-vibe-coder-zum-agentic-engineer/","date_published":"2026-04-20T00:00:00.000+00:00","date_modified":"2026-04-20T11:21:17.717+02:00","author":[{"name":"Torben Keller","url":"https://www.innoq.com/en/staff/torben-keller/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eIf you let agents work without tests, linting, or architecture constraints, you’ll quickly see where that leads. The code compiles, maybe even works, but nobody can say what happens when you change something. Structure erodes, boundaries blur, and after a few weeks you have a classic Big Ball of Mud, except this time it was created in record time.\u003c/p\u003e\n\n\u003cp\u003eThe real problem isn’t that agents write bad code. They write the code you allow them to write, and without guardrails, everything is allowed. That doesn’t scale, especially not at the speed agents bring to the table. Vibe Coding, generating code on demand without systematic control, feels like a huge productivity boost at first. But without direction, you’re mainly producing technical debt faster.\u003c/p\u003e\n\n\u003cp\u003eThe question is actually simple: If I’m no longer reading every line, how do I still take ownership of the code? The answer is closer than you might think, because we’ve solved this problem before.\u003c/p\u003e\n\n\u003ch3 id=\"this-problem-isn-t-new\"\u003eThis Problem Isn’t New\u003c/h3\u003e\n\n\u003cp\u003eImagine you’re joining an existing project. The team has changed, the original developers are long gone, and you inherit 200,000+ lines of code. You don’t understand every line, not even every module. Yet you still ship features, fix bugs, and take responsibility. That’s normal brownfield work, and every one of us has done it.\u003c/p\u003e\n\n\u003cp\u003eNobody would expect you to read and understand every line in a brownfield project before you’re allowed to open a pull request. Instead, you rely on systems: tests tell you if you broke something, linters enforce conventions, CI pipelines catch errors before they reach production. You understand the part you’re working on and trust that the rest is covered.\u003c/p\u003e\n\n\u003cp\u003eAnd that’s the key insight: \u003cstrong\u003eI don’t need to know every line for ownership. I need to be confident that my change works and doesn’t break anything.\u003c/strong\u003e\u003c/p\u003e\n\n\u003cp\u003eAI-generated code is essentially code from a colleague who’s no longer in the room, except this colleague produces significantly faster and significantly more. What makes brownfield possible in the first place is good modularization: loose coupling, high cohesion. Well-defined modules let you understand a small part and change it safely without keeping the entire system in your head. Agents benefit from this just as much, because the better the module boundaries, the more focused and error-free they work.\u003c/p\u003e\n\n\u003cp\u003eThe knowledge of how to own code you didn’t write is already in us. The question is just how we transfer it to working with agents.\u003c/p\u003e\n\n\u003ch2 id=\"fromspreadsheettolintrule\"\u003eFrom Spreadsheet to Lint Rule\u003c/h2\u003e\n\n\u003cp\u003eBoris Cherny, known today as the creator of Claude Code, provides a good example in \u003ca href=\"https://newsletter.pragmaticengineer.com/p/building-claude-code-with-boris-cherny\"\u003ethe the pragmatic engineers podcast\u003c/a\u003e. At Meta, he was one of the most prolific code reviewers, and his method was surprisingly analog: a spreadsheet. Every time he left the same comment in a review, like “no \u003ccode\u003eany\u003c/code\u003e here please” or “error handling missing”, he added it to the list. When the same feedback appeared three or four times, he wrote a lint rule for it.\u003c/p\u003e\n\n\u003cp\u003eThe principle behind it: repetitive human feedback becomes automated enforcement. Instead of saying the same thing in code reviews over and over, you build a system that says it for you. The reviewer becomes a system designer.\u003c/p\u003e\n\n\u003cp\u003eThat this effort pays off is also measurable. An \u003ca href=\"https://newsletter.pragmaticengineer.com/p/building-claude-code-with-boris-cherny\"\u003einternal study at Meta\u003c/a\u003e showed that clean codebases have a double-digit percentage impact on engineering productivity. Half-finished migrations, inconsistent patterns, and outdated conventions don’t just slow down human developers, they confuse AI models just as much. An agent working in a codebase with three different error-handling patterns will reproduce all three. Consistency is the foundation for both humans and agents to work effectively.\u003c/p\u003e\n\n\u003cp\u003eCherny’s spreadsheet method sounds almost trivial, but it contains a principle that takes on an entirely new dimension in the context of AI agents. More on that shortly.\u003c/p\u003e\n\n\u003ch3 id=\"the-agent-harness-more-than-just-the-tool\"\u003eThe Agent Harness — More Than Just the Tool\u003c/h3\u003e\n\n\u003cp\u003eIf we take the principle of “turning recurring feedback into tooling” seriously, the question is: where does this tooling actually live? In which system do lint rules, tests, architecture checks, and prompts come together?\u003c/p\u003e\n\n\u003cp\u003eThe answer is the agent harness. At its core, this is the agent program itself: Claude Code, Codex, or Cursor with its agentic loop. Through hooks, we can integrate directly and give the agent feedback on every action. But the harness also includes the agent workflow around it: the environment the agent works in. Through Git hooks and CI/CD pipelines, we can also intervene there and give the agent feedback before code is even merged.\u003c/p\u003e\n\n\u003cp\u003eThe central question is: when I want to enforce a new constraint, at which integration point do I build it in? Two pyramids help with this decision, both inspired by the test pyramid.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg src=\"https://res.cloudinary.com/innoq/image/upload/v1/uploads-production/qy2qd2a7ee3vrawewhykt5fbbr15?_a=BACJ3SAE\" alt=\"Pyramid of hooks: Agent Hooks (fast, frequent), Git Hooks, CI/CD (slow, rare).\" loading=\"lazy\"\u003e\r\n\r\n\u003cfigcaption\u003eThe Tooling Pyramid\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003e\u003cstrong\u003eThe Tooling Pyramid\u003c/strong\u003e covers the deterministic side. At the foundation are agent hooks, which run before or after tool calls. Because they execute on nearly every agent action, the integrated functions need to be extremely fast. Anything that takes longer slows the agent down on every single step. Above that are Git hooks (pre-commit, pre-push), which run less frequently and can therefore take a bit more time. Formatters, linters, or fast tests fit well here. At the top is CI/CD. That’s where checks go that take so long you wouldn’t want to run them locally as well, like comprehensive test suites or security scans. The principle is the same as with the test pyramid: what should always run must be fast. What’s slower belongs higher up.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg src=\"https://res.cloudinary.com/innoq/image/upload/v1/uploads-production/xolju6082ant1bkfti02k2o9f7v9?_a=BACJ3SAE\" alt=\"Three-level pyramid: “AGENTS.md \u0026amp; Global Rules”, “Scoped Rules \u0026amp; Skills”, “Docs Specs”; general→specific and always→on demand.\" loading=\"lazy\"\u003e\r\n\r\n\u003cfigcaption\u003eThe Prompt Pyramid\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003e\u003cstrong\u003eThe Prompt Pyramid\u003c/strong\u003e addresses through prompts everything that can’t be checked deterministically. The sorting criterion here is the degree of specialization: the more general a piece of information, the lower it belongs, because it’s relevant for every task. The more specific, the higher up, because it’s only needed in certain situations. At the base are CLAUDE.md and global rules, which are always loaded in the agent’s context. In the middle are conditional rules, which apply when the agent works in specific areas of the codebase, and skills, which are loaded when the agent performs a specific type of task. At the top are docs, specs, and ADRs, available only on-demand when the agent actively needs them. At its core, this is context engineering: the right information at the right time in context, without blowing the token budget.\u003c/p\u003e\n\n\u003cp\u003eThe decision rule between the two pyramids: \u003cstrong\u003eIf you can tool it, tool it. If you can’t, prompt it.\u003c/strong\u003e What can be checked deterministically belongs in the tooling pyramid. Architecture decisions, domain conventions, or style questions are too loose for that and belong in the prompt pyramid. Deterministic enforcement is generally preferable to prompts.\u003c/p\u003e\n\n\u003ch3 id=\"the-harness-is-never-done\"\u003eThe Harness Is Never Done\u003c/h3\u003e\n\n\u003cp\u003eAn agent harness isn’t something you set up once and then forget. It grows with every PR you review.\u003c/p\u003e\n\n\u003cp\u003eThe cycle starts unremarkably: the agent produces a pull request, and in the review a problem comes up, for example an import from a layer that shouldn’t have access, or a test without assertions. Up to this point, normal developer life. But now comes the crucial question: \u003cem\u003eIs there tooling that could detect this problem automatically?\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eIf yes, it gets integrated: maybe a new lint rule or an ArchUnit test. From then on, the agent runs against this new tooling next time and gets feedback not in the review, but immediately. If the check fails, it fixes the problem itself, before a human ever sees it.\u003c/p\u003e\n\n\u003cp\u003eThis is an incremental process, but the effect is cumulative: every problem that’s codified as tooling once never appears again. After weeks, the harness has dozens of such checks. After months, it’s a dense safety net that reflects exactly the quality requirements of the project.\u003c/p\u003e\n\n\u003cp\u003eThis is where the circle closes back to Boris Cherny. He tracked recurring review comments in a spreadsheet and turned them into lint rules — exactly the same principle. Except that with agents it takes on a new quality, because the agent doesn’t just produce the code, it also helps build the tooling. The spreadsheet was manual, the feedback loop with agents is a self-reinforcing cycle. With enough feedback and time, agents converge on the right solution, not through magic, but through systematic feedback, consistently applied.\u003c/p\u003e\n\n\u003ch2 id=\"whathumansstillneedtoown\"\u003eWhat Humans Still Need to Own\u003c/h2\u003e\n\n\u003cp\u003eTooling makes code correct, but it doesn’t check whether the code does the right thing. Linters catch style problems, type checks prevent runtime errors, architecture tests secure boundaries. But whether the business logic is correct, no hook can answer.\u003c/p\u003e\n\n\u003cp\u003eThis is also the most subtle danger with agent-generated code: tests verify the agent’s assumptions. If the assumptions are wrong, the tests are still green. A concrete example: the agent implements a discount calculation and writes tests for it, but both are based on the same misunderstanding of the business requirement. The feedback loop doesn’t help here because there’s nothing to check against.\u003c/p\u003e\n\n\u003cp\u003eThat’s why business logic stays with humans. Not every line and not every file, but the places where domain decisions are made. This has consequences for architecture: if you want this review to work efficiently, you have to design for it. Isolate the domain layer, separate business logic from infrastructure. Not because it’s theoretically elegant, but because it focuses human review on what only a human can check. The rest is covered by tooling.\u003c/p\u003e\n\n\u003ch3 id=\"the-mindset-shift-from-vibe-coder-to-agentic-engineer\"\u003eThe Mindset Shift — From Vibe Coder to Agentic Engineer\u003c/h3\u003e\n\n\u003cp\u003eVibe coders generate code on demand, without any quality assurance, and hope the result works out. Agentic engineers work just as fast with agents, but they invest in their harness: constraints, feedback systems, deterministic checks. They can focus on domain logic because their systems cover the rest. What separates the two isn’t speed, but control. And whoever has that control can ultimately take ownership of their systems.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/9yplw8xhcqvrcv12q2s4plahva8m?_a=BACJ3SAE"},{"id":"https://www.innoq.com/de/blog/2026/04/vom-vibe-coder-zum-agentic-engineer/","url":"https://www.innoq.com/de/blog/2026/04/vom-vibe-coder-zum-agentic-engineer/","date_published":"2026-04-20T00:00:00.000+00:00","date_modified":"2026-04-20T11:19:19.125+02:00","author":[{"name":"Torben Keller","url":"https://www.innoq.com/en/staff/torben-keller/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWer Agenten ohne Tests, Linting oder Architektur-Constraints arbeiten lässt, merkt schnell, wohin das führt. Der Code kompiliert, funktioniert vielleicht sogar, aber niemand kann mehr sagen, was passiert, wenn man an einer Stelle etwas ändert. Die Struktur erodiert, Boundaries verschwimmen, und nach ein paar Wochen hat man einen klassischen Big Ball of Mud, nur dass er diesmal in Rekordzeit entstanden ist.\u003c/p\u003e\n\n\u003cp\u003eDas eigentliche Problem ist dabei nicht, dass Agenten schlechten Code schreiben. Sie schreiben den Code, den man ihnen erlaubt zu schreiben, und ohne Guardrails ist alles erlaubt. Das skaliert nicht — schon gar nicht mit der Geschwindigkeit, die Agenten mitbringen. Vibe Coding, das Generieren von Code auf Zuruf ohne systematische Kontrolle, fühlt sich anfangs wie ein enormer Produktivitätssprung an. Aber ohne Richtung produziert man vor allem schneller technische Schulden.\u003c/p\u003e\n\n\u003cp\u003eDie Frage ist eigentlich simpel: Wenn ich nicht mehr jede Zeile lese, wie übernehme ich trotzdem Ownership über den Code? Die Antwort darauf liegt näher als gedacht, denn wir haben dieses Problem schon einmal gelöst.\u003c/p\u003e\n\n\u003ch3 id=\"das-problem-ist-nicht-neu\"\u003eDas Problem ist nicht neu\u003c/h3\u003e\n\n\u003cp\u003eStell dir vor, du steigst in ein bestehendes Projekt ein. Das Team hat gewechselt, die ursprünglichen Entwickler sind längst weg, und du erbst 200.000+ Zeilen Code. Du verstehst nicht jede Zeile, nicht mal jedes Modul. Trotzdem shipst du Features, fixt Bugs und übernimmst Verantwortung. Das ist normaler Brownfield-Alltag, und jeder von uns hat das schon gemacht.\u003c/p\u003e\n\n\u003cp\u003eNiemand würde erwarten, dass du in einem Brownfield-Projekt erst jede Zeile gelesen und verstanden haben musst, bevor du einen Pull Request öffnen darfst. Stattdessen verlässt du dich auf Systeme: Tests sagen dir, ob du etwas kaputt gemacht hast, Linter setzen Konventionen durch, CI-Pipelines fangen Fehler ab, bevor sie es in die Produktion schaffen. Du verstehst den Teil, den du anfasst, und vertraust darauf, dass der Rest abgesichert ist.\u003c/p\u003e\n\n\u003cp\u003eUnd genau das ist die Erkenntnis, auf die es ankommt: \u003cstrong\u003eFür Ownership muss ich nicht jede Zeile kennen. Für Ownership muss ich sicher sein, dass meine Änderung funktioniert und nichts kaputt macht.\u003c/strong\u003e\u003c/p\u003e\n\n\u003cp\u003eKI-generierter Code ist im Grunde nichts anderes als Code von einem Kollegen, der nicht mehr im Raum sitzt, nur dass dieser Kollege deutlich schneller und deutlich mehr produziert. Was Brownfield überhaupt erst möglich macht, ist gute Modularisierung: Lose Kopplung, Hohe Kohäsion. Gut geschnittene Module erlauben es dir, einen kleinen Teil zu verstehen und sicher zu verändern, ohne das Gesamtsystem im Kopf haben zu müssen. Agenten profitieren davon genauso, denn je besser die Modulschnitte, desto fokussierter und fehlerfreier arbeiten sie.\u003c/p\u003e\n\n\u003cp\u003eDas Wissen, wie man Code besitzt, den man nicht geschrieben hat, steckt also schon in uns. Die Frage ist nur, wie wir es auf die Arbeit mit Agenten übertragen.\u003c/p\u003e\n\n\u003ch3 id=\"von-der-spreadsheet-zur-lint-rule\"\u003eVon der Spreadsheet zur Lint Rule\u003c/h3\u003e\n\n\u003cp\u003eBoris Cherny, heute bekannt als Creator von Claude Code, liefert dafür ein gutes Beispiel im \u003ca href=\"https://newsletter.pragmaticengineer.com/p/building-claude-code-with-boris-cherny\"\u003ePodcast von The Pragmatic Engineer\u003c/a\u003e. Bei Meta war er einer der produktivsten Code Reviewer, und seine Methode war überraschend analog: ein Spreadsheet. Jedes Mal, wenn er in einem Review denselben Kommentar hinterließ, etwa “Bitte kein \u003ccode\u003eany\u003c/code\u003e hier” oder “Fehlerbehandlung fehlt”, trug er ihn in die Liste ein. Tauchte dasselbe Feedback drei- bis viermal auf, schrieb er eine Lint Rule dafür.\u003c/p\u003e\n\n\u003cp\u003eDas Prinzip dahinter: Repetitives menschliches Feedback wird zu automatisierter Durchsetzung. Statt immer wieder dasselbe in Code Reviews zu sagen, baut man ein System, das es für einen sagt. Der Reviewer wird zum Systemdesigner.\u003c/p\u003e\n\n\u003cp\u003eDass sich dieser Aufwand lohnt, ist auch messbar. Eine \u003ca href=\"https://newsletter.pragmaticengineer.com/p/building-claude-code-with-boris-cherny\"\u003einterne Studie bei Meta\u003c/a\u003e hat gezeigt, dass saubere Codebases einen zweistelligen Prozent-Impact auf die Engineering Productivity haben. Halbfertige Migrationen, inkonsistente Patterns und veraltete Konventionen verlangsamen nicht nur menschliche Entwickler, sondern verwirren KI-Modelle genauso. Ein Agent, der in einer Codebase mit drei verschiedenen Fehlerbehandlungs-Patterns arbeitet, wird alle drei reproduzieren. Konsistenz ist die Grundlage dafür, dass sowohl Menschen als auch Agenten effektiv arbeiten können.\u003c/p\u003e\n\n\u003cp\u003eChernys Spreadsheet-Methode klingt fast banal, aber sie enthält ein Prinzip, das im Kontext von KI-Agenten eine ganz neue Dimension bekommt. Dazu gleich mehr.\u003c/p\u003e\n\n\u003ch3 id=\"der-agent-harness-mehr-als-nur-das-tool\"\u003eDer Agent Harness — mehr als nur das Tool\u003c/h3\u003e\n\n\u003cp\u003eWenn wir das Prinzip “wiederkehrendes Feedback in Tooling umwandeln” ernst nehmen, stellt sich die Frage: Wo lebt dieses Tooling eigentlich? In welchem System greifen Lint Rules, Tests, Architektur-Checks und Prompts ineinander?\u003c/p\u003e\n\n\u003cp\u003eDie Antwort ist der Agent Harness. Im Kern ist das zunächst das Agent-Programm selbst, also Claude Code, Codex oder Cursor mit seiner Agentic Loop. Über Hooks können wir dort direkt integrieren und dem Agenten bei jeder Aktion Feedback geben. Aber zum Harness gehört auch der Agent Workflow drumherum: die Umgebung, in der der Agent arbeitet. Über Git Hooks und CI/CD-Pipelines können wir auch dort ansetzen und dem Agenten Feedback geben, bevor Code überhaupt gemergt wird.\u003c/p\u003e\n\n\u003cp\u003eDie zentrale Frage ist: Wenn ich einen neuen Constraint durchsetzen will, an welchem Integrationspunkt baue ich ihn ein? Zwei Pyramiden helfen bei dieser Entscheidung, beide inspiriert von der Testpyramide.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg src=\"https://res.cloudinary.com/innoq/image/upload/v1/uploads-production/a7lrzk86smmcect7joiavda66rl5?_a=BACJ3SAE\" alt=\"Pyramid diagram: Agent Hooks (fast, frequent), Git Hooks, and CI/CD (slow, rare) with side arrows.\" loading=\"lazy\"\u003e\r\n\r\n\u003cfigcaption\u003eDie Tooling Pyramid\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003e\u003cstrong\u003eDie Tooling Pyramid\u003c/strong\u003e deckt die deterministische Seite ab. Am Fundament stehen Agent Hooks, die vor oder nach Tool Calls ausgeführt werden. Weil sie bei fast jeder Aktion des Agenten laufen, müssen die integrierten Funktionen extrem schnell sein. Alles was länger dauert, bremst den Agenten bei jedem einzelnen Schritt aus. Darüber liegen Git Hooks (Pre-Commit, Pre-Push), die seltener laufen und deshalb auch etwas mehr Zeit kosten dürfen. Hier passen Formatter, Linter oder schnelle Tests gut rein. An der Spitze steht CI/CD. Dort landen Checks, die so lange dauern, dass man sie nicht zusätzlich lokal laufen lassen will, etwa umfangreiche Testsuiten oder Security Scans. Das Prinzip ist dasselbe wie bei der Testpyramide: Was immer laufen soll, muss schnell sein. Was langsamer ist, gehört weiter nach oben.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg src=\"https://res.cloudinary.com/innoq/image/upload/v1/uploads-production/k45objkicrwk7w0wl0jnkjmp8e1g?_a=BACJ3SAE\" alt=\"Three-level pyramid: “AGENTS.md \u0026amp; Global Rules”, “Scoped Rules \u0026amp; Skills”, “Docs Specs”; from general/always to specific/on demand.\" loading=\"lazy\"\u003e\r\n\r\n\u003cfigcaption\u003eDie Prompt Pyramid\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003e\u003cstrong\u003eDie Prompt Pyramid\u003c/strong\u003e adressiert durch Prompts alles, was sich nicht deterministisch prüfen lässt. Das Sortierkriterium hier ist der Grad der Spezialisierung: Je allgemeiner eine Information ist, desto weiter unten gehört sie, weil sie bei jeder Aufgabe relevant ist. Je spezifischer, desto weiter oben, weil sie nur in bestimmten Situationen gebraucht wird. An der Basis stehen CLAUDE.md und Global Rules, die immer im Kontext des Agenten geladen sind. In der Mitte stehen Conditional Rules, die gelten wenn der Agent in bestimmten Bereichen der Codebase arbeitet, und Skills, die geladen werden wenn der Agent eine bestimmte Art von Aufgabe erledigt. An der Spitze stehen Docs, Specs und ADRs, die nur on-demand verfügbar sind wenn der Agent sie aktiv braucht. Im Kern ist das Context Engineering: die richtige Information zur richtigen Zeit im Kontext, ohne das Token-Budget zu sprengen.\u003c/p\u003e\n\n\u003cp\u003eDie Entscheidungsregel zwischen den beiden Pyramiden: \u003cstrong\u003eIf you can tool it, tool it. If you can’t, prompt it.\u003c/strong\u003e Was sich deterministisch prüfen lässt, gehört in die Tooling Pyramid. Architekturentscheidungen, Domain-Konventionen oder Stilfragen sind dafür zu lose und gehören in die Prompt Pyramid. Deterministische Durchsetzung ist Prompts gegenüber grundsätzlich vorzuziehen.\u003c/p\u003e\n\n\u003ch3 id=\"der-harness-ist-nie-fertig\"\u003eDer Harness ist nie fertig\u003c/h3\u003e\n\n\u003cp\u003eEin Agent Harness ist nichts, das man einmal aufsetzt und dann vergisst. Er wächst mit jedem PR, den man reviewt.\u003c/p\u003e\n\n\u003cp\u003eDer Zyklus beginnt unspektakulär: Der Agent produziert einen Pull Request, und im Review fällt ein Problem auf, zum Beispiel ein Import aus einer Schicht, die nicht zugreifen darf, oder ein Test ohne Assertions. Bis hierhin normaler Entwickleralltag. Aber jetzt kommt die entscheidende Frage: \u003cem\u003eGibt es Tooling, das dieses Problem automatisch erkennen könnte?\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eWenn ja, wird es integriert: vielleicht eine neue Lint Rule oder ein ArchUnit-Test. Ab sofort läuft der Agent beim nächsten Mal gegen dieses neue Tooling und bekommt das Feedback nicht erst im Review, sondern sofort. Wenn der Check fehlschlägt, fixt er das Problem selbst, bevor ein Mensch es je sieht.\u003c/p\u003e\n\n\u003cp\u003eDas ist ein inkrementeller Prozess, aber die Wirkung ist kumulativ: Jedes Problem, das einmal als Tooling kodifiziert wird, taucht nie wieder auf. Nach Wochen hat der Harness dutzende solcher Checks. Nach Monaten ist er ein dichtes Sicherheitsnetz, das genau die Qualitätsanforderungen des Projekts widerspiegelt.\u003c/p\u003e\n\n\u003cp\u003eHier schließt sich der Kreis zu Boris Cherny. Er trackte wiederkehrende Review-Kommentare in einer Spreadsheet und machte daraus Lint Rules — genau dasselbe Prinzip. Nur dass es mit Agenten eine neue Qualität bekommt, denn der Agent produziert nicht nur den Code, er hilft auch beim Bauen des Toolings. Die Spreadsheet war manuell, der Feedback Loop mit Agenten ist ein sich selbst verstärkender Kreislauf. Mit genug Feedback und Zeit konvergieren Agenten auf die richtige Lösung, nicht durch Magie, sondern durch systematisches Feedback, konsequent angewendet.\u003c/p\u003e\n\n\u003ch3 id=\"was-der-mensch-noch-ownen-muss\"\u003eWas der Mensch noch ownen muss\u003c/h3\u003e\n\n\u003cp\u003eTooling macht Code korrekt, aber es prüft nicht, ob der Code das Richtige tut. Linter fangen Style-Probleme ab, Typ-Checks verhindern Laufzeitfehler, Architektur-Tests sichern Boundaries. Ob die Geschäftslogik stimmt, kann aber kein Hook beantworten.\u003c/p\u003e\n\n\u003cp\u003eDas ist auch die subtilste Gefahr bei Agent-generiertem Code: Tests verifizieren die Annahmen des Agents. Wenn die Annahmen falsch sind, sind die Tests trotzdem grün. Ein konkretes Beispiel: Der Agent implementiert eine Rabattberechnung und schreibt Tests dafür, aber beides basiert auf demselben Missverständnis der fachlichen Anforderung. Der Feedback Loop greift hier nicht, weil es nichts gibt, wogegen er prüfen könnte.\u003c/p\u003e\n\n\u003cp\u003eDeshalb bleibt die Business Logic beim Menschen. Nicht jede Zeile und nicht jede Datei, aber die Stellen, an denen fachliche Entscheidungen getroffen werden. Das hat Konsequenzen für die Architektur: Wer will, dass dieser Review effizient funktioniert, muss dafür designen. Domain Layer isolieren, Fachlogik von Infrastruktur trennen. Nicht weil es theoretisch schön ist, sondern weil es den menschlichen Review auf das fokussiert, was nur ein Mensch prüfen kann. Den Rest sichert das Tooling ab.\u003c/p\u003e\n\n\u003ch3 id=\"der-mindset-shift-vom-vibe-coder-zum-agentic-engineer\"\u003eDer Mindset Shift — vom Vibe Coder zum Agentic Engineer\u003c/h3\u003e\n\n\u003cp\u003eVibe Coder generieren Code auf Zuruf, ohne jegliche Qualitätssicherung, und hoffen, dass das Ergebnis passt. Agentic Engineers arbeiten genauso schnell mit Agenten, aber sie investieren in ihren Harness: Constraints, Feedback-Systeme, deterministische Checks. Sie können sich auf die Fachlichkeit konzentrieren, weil ihre Systeme den Rest absichern. Was die beiden unterscheidet, ist nicht Geschwindigkeit, sondern Kontrolle. Und wer diese Kontrolle hat, kann am Ende auch Ownership für seine Systeme übernehmen.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/o0ax3f5ogwookjyrncieuggwsybf?_a=BACJ3SAE"},{"id":"https://www.innoq.com/en/talks/2026/04/no-constrain-no-gain-04-2026/","url":"https://www.innoq.com/en/talks/2026/04/no-constrain-no-gain-04-2026/","date_published":"2026-03-24T00:00:00.000+00:00","date_modified":"2026-04-15T08:24:57.665+02:00","author":[{"name":"Johannes Rave","url":"https://www.innoq.com/en/staff/johannes-rave/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eAI coding agents are remarkably good at producing code. Whether that code reflects what the business actually needs — and whether it still makes sense to work with six months later — is a rather different question. The temptation is to treat this as a prompting problem — give the agent more context, better instructions, clearer goals. An overlooked lever is paying attention to architecture.\u003c/p\u003e\n\n\u003cp\u003eWhen domain logic has its own clearly bounded home, separated from the technical plumbing around it, something interesting happens: the agent stays focused, the human can actually review what matters, and the whole thing remains open to change without requiring a rewrite.\u003c/p\u003e\n\n\u003cp\u003eThis talk shares one approach to getting there — and how some well-placed constraints might set you free.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/04/from-vibe-coder-to-code-owner-ase-night-04-26/","url":"https://www.innoq.com/en/talks/2026/04/from-vibe-coder-to-code-owner-ase-night-04-26/","date_published":"2026-03-19T00:00:00.000+00:00","date_modified":"2026-04-14T18:09:50.642+02:00","author":[{"name":"Torben Keller","url":"https://www.innoq.com/en/staff/torben-keller/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eAn AI agent can generate thousands of lines of code in a few minutes. That’s powerful – and overwhelming. You can’t read and fully understand every line anymore when you want to take advantage of agents. But if you’re shipping to production, you own that code. So, how do you take responsibility for something you didn’t write and can’t fully review?\u003c/p\u003e\n\n\u003cp\u003eThis isn’t a new problem. Developers working on brownfield projects face it every day. You join a team and inherit a codebase with hundreds of thousands of lines written by people who left years ago. You don’t know every line – yet you ship features, fix bugs, and take ownership. But how?\u003c/p\u003e\n\n\u003cp\u003eThe same principles apply to AI-generated code. What we’ve learned from decades of working with legacy systems and inherited codebases translates directly to the age of vibe coding.\u003c/p\u003e\n\n\u003cp\u003eIn this talk, you’ll learn:\u003c/p\u003e\n\n\u003cp\u003eWhat brownfield development teaches us about owning code we didn’t write\nHow to build an “Agent Harness” that integrates these practices into your AI workflow, ensuring agents follow your rules and standards\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/de/podcast/188-facilitating-software-architecture/","url":"https://www.innoq.com/de/podcast/188-facilitating-software-architecture/","date_published":"2026-04-13T00:00:00.000+00:00","date_modified":"2026-04-13T09:12:04.865+02:00","author":[{"name":"Sven Johann","url":"https://www.innoq.com/en/staff/sven-johann/"},{"name":"Holger Kraus","url":"https://www.innoq.com/en/staff/holger-kraus/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\u003cp\u003eWas bedeutet es, Softwarearchitekt:in zu sein? Holger Kraus, Senior Consultant bei INNOQ, und Sven Johann sprechen darüber, wie die Architektenrolle aussieht, wenn man sie nicht als Alleinentscheider:in, sondern als Facilitator begreift: jemand, der erkennt, wann Klärungsbedarf besteht, die richtigen Stakeholder zusammenbringt und dafür sorgt, dass gute Entscheidungen im Team entstehen können. Es geht um Architecture Decision Records, Mikro- und Makroarchitektur und die Frage, welche innere Haltung gute Entscheidungskultur im Team erst möglich macht.\u003c/p\u003e\u003c/body\u003e\u003c/html\u003e\n","image":"https://hotshot.innoq.io/shoot?path=%2Fen%2Fpodcast%2F188-facilitating-software-architecture%2Fcover%2F%3Fheader%3D1\u0026selector=.cover\u0026padding=0"},{"id":"https://www.innoq.com/en/talks/2026/04/ki-und-mcp-security-hh/","url":"https://www.innoq.com/en/talks/2026/04/ki-und-mcp-security-hh/","date_published":"2026-03-18T00:00:00.000+00:00","date_modified":"2026-04-09T15:34:16.678+02:00","author":[{"name":"Dominik Guhr","url":"https://www.innoq.com/en/staff/dominik-guhr/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eAlle sprechen über KI. Und natürlich soll sie auch sicher sein. Aber wie möglich oder unmöglich ist das derzeit? In diesem Vortrag diskutieren wir den aktuellen Stand der Technik – insbesondere im Kontext von MCP und agentischen KI-Systemen, von Angriffsvektoren bis IAM.\u003c/p\u003e\n\n\u003cp\u003eWenn Ihr euch fragt: “Wie ist die Bedrohungslage? Welche Möglichkeiten gibt es für Authentifizierung, Autorisierung und generell für Laufzeit-Sicherheit? Ist OAuth wirklich der Weisheit letzter Schluss? Und wie sicher ist, dass das alles so bleibt?” – dann seid ihr genau richtig.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/04/der-job-veraendert-sich-ich-auch-und-das-ist-okay/","url":"https://www.innoq.com/en/talks/2026/04/der-job-veraendert-sich-ich-auch-und-das-ist-okay/","date_published":"2026-03-18T00:00:00.000+00:00","date_modified":"2026-04-09T16:13:02.250+02:00","author":[{"name":"Philip Stapelfeldt","url":"https://www.innoq.com/en/staff/philip-stapelfeldt/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eKI verändert gerade, was es bedeutet, Softwareentwickler:in zu sein - schneller als die meisten erwartet haben. Philip, Senior Consultant bei innoQ, teilt ehrliche Einblicke aus seinem Arbeitsalltag: Was KI übernimmt, was sie nicht kann, wo sie einem den Antrieb kosten kann - und warum Stehen bleiben trotzdem keine Option ist.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/de/blog/2026/04/versteckte-kosten-spec-driven-development/","url":"https://www.innoq.com/de/blog/2026/04/versteckte-kosten-spec-driven-development/","date_published":"2026-04-03T00:00:00.000+00:00","date_modified":"2026-04-08T10:09:46.926+02:00","author":[{"name":"Roman Stranghöner","url":"https://www.innoq.com/en/staff/roman-stranghoener/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eMit Spec-driven Development habe ich in den letzten Monaten oft mehr und besseren AI-generierten Output produziert als vorher. Gleichzeitig war ich nach vielen Sessions auch deutlich erschöpfter.\u003c/p\u003e\n\n\u003cp\u003eNicht trotz der Struktur, sondern oft \u003cem\u003ewegen\u003c/em\u003e ihr.\u003c/p\u003e\n\n\u003cp\u003eDas hat mich erst irritiert. Denn Spec-driven Development verspricht ja erstmal genau das Richtige: weniger Chaos, mehr Klarheit, bessere Ergebnisse mit Agenten. Und das stimmt auch. Nur nicht durchgängig.\u003c/p\u003e\n\n\u003cp\u003eMein Eindruck ist inzwischen ziemlich klar: Dieselbe Struktur, die mir in der Denkphase hilft, kann mich in der Bauphase ausbremsen. Dann baue ich nicht mehr. Ich manage, formuliere und dokumentiere. Und genau da entstehen für mich die versteckten Kosten von Spec-driven Development. Mich interessiert dabei weniger die Grundsatzfrage, ob SDD nun gut oder schlecht ist. Mich interessiert die praktischere Frage: \u003cstrong\u003eWann schafft diese Arbeitsweise echte Klarheit, und wann verschiebt sie Denkarbeit an die falsche Stelle?\u003c/strong\u003e\u003c/p\u003e\n\n\u003ch3 id=\"gute-last-schlechte-last\"\u003eGute Last, schlechte Last\u003c/h3\u003e\n\n\u003cp\u003eNicht jede Last ist automatisch schlecht. Ein Teil von Entwicklungsarbeit ist anstrengend, weil das Problem an sich anstrengend ist. Ein anderer Teil ist anstrengend, weil die Arbeitsweise unnötige Reibung erzeugt.\u003c/p\u003e\n\n\u003cp\u003eGenau dieser Unterschied ist für mich bei Spec-driven Development spannend geworden. Ich kann mit einem Framework wie \u003ca href=\"https://docs.bmad-method.org/\"\u003eBMAD\u003c/a\u003e ein Vorhaben sauberer durchdenken als früher. Ich werde gezwungen, unscharfe Anforderungen explizit zu machen. Ich muss Randbedingungen benennen. Ich muss schneiden. Ich muss Lücken sehen, bevor ich sie mit generiertem Code überdecke. Das ist erstmal hilfreich.\u003c/p\u003e\n\n\u003cp\u003eGleichzeitig merke ich aber: Diese Struktur fühlt sich nicht in jeder Phase gleich sinnvoll an. Manchmal reduziert sie Komplexität. Manchmal verlagert sie sie nur. Und der Unterschied ist für mich nicht theoretisch. Ich merke ihn sehr konkret in Fokus, Tempo und Energie.\u003c/p\u003e\n\n\u003cp\u003eDarum würde ich SDD inzwischen nicht mehr pauschal bewerten. Die entscheidende Frage ist für mich eher, welche Art von Last es gerade erzeugt.\nHilft mir die Struktur beim Verstehen? Oder zwingt sie mich, Dinge auszuformulieren, die ich beim Bauen viel leichter direkt am \u003cem\u003elebenden Objekt\u003c/em\u003e klären würde?\u003c/p\u003e\n\n\u003ch3 id=\"warum-sdd-in-der-denkphase-helfen-kann\"\u003eWarum SDD in der Denkphase helfen kann\u003c/h3\u003e\n\n\u003cp\u003eSpec-driven Development löst auf der grünen Wiese ein echtes Problem. Wer mit Agenten arbeitet, merkt schnell, dass guter Kontext kein Nice-to-have ist.\nGut strukturierter Kontext trägt maßgeblich zur Lösung bei.\u003c/p\u003e\n\n\u003cp\u003eWenn ich Anforderungen, grobe Architektur, UX-Leitplanken und erste Story-Schnitte sauber festhalte, wird später vieles leichter. Diffuse Gedanken landen in klareren Schubladen. Das Problem wird kleiner, weil ich es vorher schon einmal sortiert habe. Und der Agent hat später etwas, woran er sich festhalten kann, statt bei jeder Aufgabe wieder bei null anzufangen.\u003c/p\u003e\n\n\u003cp\u003eGerade in frühen Projektphasen hilft mir das sehr. Nicht, weil ich vorher nie nachgedacht hätte. Sondern weil mich das Framework dazu zwingt, lose Gedanken wirklich sauber auszuarbeiten und festzuhalten.\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003eWas soll dieses und jenes Feature eigentlich für wen leisten? Welche Randbedingungen sind relevant? Wo will ich bewusst noch nichts entscheiden?\u003c/em\u003e Für diese Art von Denkarbeit ist etwas Struktur nützlich.\u003c/p\u003e\n\n\u003cp\u003eWenn ich das mit \u003ca href=\"https://www.innoq.com/en/blog/2026/03/ai-cognitive-lens-cognitive-load-theory/\"\u003eDaniel Westheides Cognitive-Load-Linse\u003c/a\u003e beschreiben würde, dann so: In dieser Phase reduziert das Framework Komplexität. Es zerlegt ein großes Problem in kleinere, bearbeitbare Teile.\u003c/p\u003e\n\n\u003cp\u003eDas ist \u003cstrong\u003egute Last\u003c/strong\u003e. Oder zumindest Last, die sich für mich sinnvoll anfühlt.\u003c/p\u003e\n\n\u003ch3 id=\"wenn-bauen-zu-dokumentationsarbeit-verkommt\"\u003eWenn Bauen zu Dokumentationsarbeit verkommt\u003c/h3\u003e\n\n\u003cp\u003eDas Problem beginnt bei mir oft genau dort, wo es eigentlich produktiv werden sollte: bei der \u003cstrong\u003eImplementierung\u003c/strong\u003e.\u003c/p\u003e\n\n\u003cp\u003eDann sitze ich nicht mehr vor dem eigentlichen Problem. Ich sitze vor einer Story-Spec und formuliere Akzeptanzkriterien für Dinge, die vielleicht nie eintreten. Ich beschreibe Verhalten für Sonderfälle, die ich beim direkten Bauen wahrscheinlich in zwei Iterationen mit dem Agenten geklärt hätte.\nIch versuche, Intuition vorab in Text zu pressen.\u003c/p\u003e\n\n\u003cp\u003eBesonders deutlich merke ich das beim Erzeugen einer Story aus einem Epic. Vorher habe ich noch über Functional Requirements, Non-Functional Requirements und grobe Story-Rümpfe gesprochen. Also für wen bauen wir das, was soll passieren, woran merken wir, dass es reicht. Stattdessen rutschen dann ganz schnell technische Details und Code-Beispiele hinein.\u003c/p\u003e\n\n\u003cp\u003eEin konkretes Beispiel hat mir das sehr deutlich gemacht. Aus einer eigentlich simplen Story wie „Create User Profile\" wurde bei mir ein riesiges Paket aus 19 Acceptance Criteria, Datenbankfeldern, Komponenten-Mapping, Dependency-Hinweisen, File-Lists, Test-Checklisten und später sogar Review-Follow-ups. 1070 Zeilen Markdown.\u003c/p\u003e\n\n\u003cp\u003eFormal hieß das Ding immer noch Story. Praktisch war es schon halb Spezifikation, halb Implementierungsplan und halb QA-Backlog. Ja genau, das sind drei Hälften.\u003c/p\u003e\n\n\u003cp\u003eDamit verschiebt sich der ganze Modus. Ich diskutiere nicht mehr über eine verständliche Geschichte für Menschen, sondern über eine vorweggenommene Umsetzung. Der Feedback-Loop wird länger, weil plötzlich Dinge auf dem Tisch liegen, die an dieser Stelle noch gar nicht entschieden werden müssten. Noch problematischer wird es dadurch, dass diese Code-Schnipsel nicht neutral sind. Sie primen das Modell, das die Story später umsetzt. Wenn ich den Code irgendwann umbauen oder mit einem besseren Modell neu generieren will, steckt in der Story schon ein technischer Bias aus einem früheren Planungsschritt.\nDer Vorgriff sitzt dann längst im Material.\u003c/p\u003e\n\n\u003ch3 id=\"warum-sich-nicht-alles-explizit-machen-lasst\"\u003eWarum sich nicht alles explizit machen lässt\u003c/h3\u003e\n\n\u003cp\u003eEin Teil meines Unbehagens hat mit etwas anderem zu tun: Ein Teil guter Entwicklungsarbeit lässt sich nicht sauber vorab in Sprache übersetzen.\u003c/p\u003e\n\n\u003cp\u003eAm besten beschreiben kann ich das über ein Bild aus dem Autofahren: Wenn du lange fährst, entwickelst du ein Gefühl dafür, was gleich passiert. Du siehst drei Autos weiter vorne schon Bremslichter aufflackern. Du gehst vom Gas, ordnest dich links ein, überholst, reagierst vorausschauend. Das läuft schnell und fast beiläufig. Beim Coden geht mir das ähnlich. Mit etwas Erfahrung spürst du oft früh, welche Entscheidung in drei Schritten vielleicht Probleme machen wird. Du passt etwas an, bevor es kracht. Nicht, weil du schon alles formulieren könntest. Sondern weil du in der Sache drin bist.\u003c/p\u003e\n\n\u003cp\u003eSpec-driven Frameworks versuchen, eine Lücke mit Dokumenten zu schließen. Das ist nachvollziehbar. Aber ein Teil dieser Lücke ist nicht einfach ein Dokumentationsproblem. Es ist ein Problem von implizitem Wissen. Wir wissen beim Bauen oft mehr, als wir im Voraus sauber sagen können. Wir erkennen Muster. Wir merken, dass etwas schief aussieht, bevor wir erklären könnten, warum.\u003c/p\u003e\n\n\u003cp\u003eDer Versuch, genau diese Erfahrung vollständig in Specs zu pressen, kostet viel Energie. Und das ist für mich der eigentliche Verlust: Ich muss aus einem Modus des Erkennens in einen Modus des Erklärens wechseln, bevor ich angefangen habe, irgendetwas zu bauen.\u003c/p\u003e\n\n\u003ch3 id=\"warum-dicke-specs-kein-gemeinsames-verstandnis-erzeugen\"\u003eWarum dicke Specs kein gemeinsames Verständnis erzeugen\u003c/h3\u003e\n\n\u003cp\u003eAus einer Product-Owner-Schulung von 2017 mit Jeff Patton und Jeff Gothelf ist mir ein Gedanke hängen geblieben: Eine Story ist kein Dokument. Sie ist ein Token für ein Gespräch.\u003c/p\u003e\n\n\u003cp\u003eErst Card, dann Conversation, dann Confirmation. Nicht andersrum.\u003c/p\u003e\n\n\u003cp\u003eAkzeptanzkriterien sollten bestätigen, dass man sich verstanden hat. Sie sollten das Verständnis nicht durch immer mehr Vorab-Details ersetzen. Genau da kippt es für mich in der Bauphase von SDD. Ich schreibe ein Dokument. Der Agent konsumiert es. Es gibt keine echte Konversation, sondern nur eine Übergabe.\u003c/p\u003e\n\n\u003cp\u003eUnd damit fällt etwas weg, was Stories ursprünglich leisten sollten.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Vier Bilder: Ein Team glaubt sich einig zu sein, erkennt dann unterschiedliche Vorstellungen, arbeitet das Problem gemeinsam durch und erreicht erst danach echtes Verständnis.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eErst wenn sich alle am selben Problem abarbeiten, entsteht echtes Verständnis. Frei nach Jeff Patton.\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eIn einem Kundenprojekt im letzten Jahr habe ich genau das erlebt. Ich habe im Team viel Aufwand in detaillierte User Stories (Specs) gesteckt. Ganz ohne BMAD und mit eigentlich guter Intention: ein solider erster Wurf, inklusive vieler Akzeptanzkriterien mit dem das Team ins Rennen gehen konnte und nicht bei null anfangen musste. Aber das Team hat die Specs ganz anders gelesen. Für sie war das kein Diskussionsentwurf, sondern schon ein fertiges Übergabedokument. Da steht doch schon alles. Also wurde viel diskutiert, aber nicht über die Sache, die es zu bauen galt, sondern über den Umfang und die Form der Stories.\u003c/p\u003e\n\n\u003cp\u003eDas Ergebnis: Auf der einen Seite jemand, der sich wundert, warum es nur negatives Feedback gibt. Auf der anderen Seite ein Team, das sich fragt, warum es noch mitreden soll, wenn ohnehin schon alles entschieden scheint.\u003c/p\u003e\n\n\u003cp\u003eDie Stories blieben eine ganze Weile so dick. Und die Review-Last wuchs mit. Denn aus einer dicken Story fabriziert ein Agent schnell einen riesigen Implementierungsplan inkl. Datenbankschema, Komponentenstruktur, usw. Und irgendwann liest niemand mehr richtig. Das ist menschlich. Aber es untergräbt genau das, was die Stories eigentlich sicherstellen sollten.\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e„Shared documents are not shared understanding\"\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003ePatton trifft das für mich ziemlich genau. Die Story wird dicker. Ich fühle mich kurz sicherer. Aber daraus folgt noch nicht, dass später auch etwas Besseres gebaut wird. Das Dokument wächst, aber \u003ca href=\"https://margaretstorey.com/blog/2026/02/09/cognitive-debt/\"\u003edas Verständnis nicht automatisch mit\u003c/a\u003e.\u003c/p\u003e\n\n\u003cp\u003eIm schlimmsten Fall passiert das Gegenteil: Ich habe viel Text produziert und bilde mir ein, das Problem sei gründlich durchdrungen, obwohl ich vor allem ein sauberes Übergabedokument erzeugt habe.\u003c/p\u003e\n\n\u003cp\u003eDas sieht nach Klarheit aus. Ist aber manchmal nur gut organisierte Scheinsicherheit.\u003c/p\u003e\n\n\u003cp\u003eBei BMAD gibt es einen sogenannten Party-Modus, in dem verschiedene KI-Experten mit unterschiedlichen Perspektiven eine Story diskutieren. Das simuliert ein Teamgespräch und bringt manchmal auch überraschende Einsichten. Aber es bleibt eine Simulation. Und die Insights verbleiben in der KI-Session. Ein Team, das später mit der Spec und dem Code leben muss, lernt davon nichts. Kein geteiltes Verständnis fließt zurück in die Köpfe.\u003c/p\u003e\n\n\u003ch3 id=\"warum-billige-iteration-die-rechnung-verandert\"\u003eWarum billige Iteration die Rechnung verändert\u003c/h3\u003e\n\n\u003cp\u003eViele SDD-Frameworks investieren in der Planungsphase so, als \u003ca href=\"https://www.robert-glaser.de/what-if-iteration-is-all-we-need/\"\u003ewäre Iteration immer noch teuer\u003c/a\u003e. Aber das ist sie mit Agenten oft gar nicht mehr. Ein paar schnelle Runden aus „bau mal so\", „nein, jetzt eher so\", „ja, jetzt passt’s\" sind in vielen Situationen billiger als stundenlang eine perfekte Vorab-Spec zu schleifen.\u003c/p\u003e\n\n\u003cp\u003eManchmal ist die bessere Antwort vielleicht: früher ins Machen gehen und bessere Sicherheitsnetze einziehen. Das heißt nicht, dass Planung überflüssig wird. Es heißt nur, dass sich die Rechnung verschiebt. Wenn der nächste testbare Prototyp nicht mehr Tage, sondern Minuten entfernt ist, dann verliert ein Teil der Vorab-Bürokratie seinen wirtschaftlichen Vorteil.\u003c/p\u003e\n\n\u003cp\u003eMehr Spec ist nicht automatisch die vernünftigere Form von Risikomanagement. Manchmal ist es in mehrfacher Hinsicht teurerer Denkaufwand.\u003c/p\u003e\n\n\u003ch3 id=\"was-fur-mich-besser-funktioniert\"\u003eWas für mich besser funktioniert\u003c/h3\u003e\n\n\u003cp\u003eIch bin deshalb nicht bei „Framework weg, einfach vibecoden\" gelandet. Das wäre die falsche Gegenreaktion. Den Planning-Modus eines Agenten finde ich beispielsweise total sinnvoll. Ich will nur nicht, dass alles, was in diesem Denkraum kurzfristig hilfreich ist, dauerhaft in einer Story-Datei landet.\u003c/p\u003e\n\n\u003cp\u003eWas ich stattdessen mache und was nicht (mehr):\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eIn der Denkphase\u003c/strong\u003e bemühe ich mich, zuerst das gemeinsame Verständnis im Team zu sichern, und erst dann die daraus relevanten Informationen in einer Spec festzuhalten. Nicht andersrum. Ich nutze dafür weiterhin eine feste Struktur, entweder durch BMAD oder einen Eigenbau. Und ich schreibe aber nur so viel Spec, wie sie mir oder meinem Team auch echte Klarheit verschafft. Die Story bleibt kurz und beschreibt, was für wen passieren soll und woran wir merken, dass es reicht. Ergänzt um ein paar Links zu mehr Kontext, falls nötig. Sozusagen \u003ca href=\"https://www.nngroup.com/articles/progressive-disclosure/\"\u003eProgressive Disclosure\u003c/a\u003e für gegebenenfalls relevante Zusatzinfos wie das zugehörige Epic, Personas, Requirements, etc.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eIn der Bauphase\u003c/strong\u003e arbeite ich in kurzen Loops eng am Code. Nach Möglichkeit im Flow-State. Ich lasse den Agenten auf Basis der Specs planen, aber dieser konkrete Plan darf flüchtig sein. Er ist ein Arbeitsdokument, kein Artefakt. Was ich nicht mehr mache: den Plan inklusive Code-Beispielen, Datenbankfelder oder File-Listen mit in die Story stopfen.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eEntscheidungen\u003c/strong\u003e trenne ich bewusst von der Spec. Wenn während der Planung oder der Implementierung architekturrelevante Entscheidungen fallen, schreibe ich ein ADR. Wenn es eine Produktentscheidung ist, fließt sie zurück ins Refinement oder in eine angepasste Story. Wenn es eine technische Abwägung ist, landet sie als Kommentar im Code oder in einer Architekturdokumentation. Entscheidungen brauchen einen sichtbaren Ort, nicht eine Zeile in einem 1000-Zeilen-Markdown.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eAbsicherung\u003c/strong\u003e verlagere ich schrittweise vom Dokument in den \u003ca href=\"https://www.innoq.com/en/blog/2026/02/from-vibe-coder-to-code-owner/\"\u003eHarness\u003c/a\u003e: Tests, Linter, Architekturregeln, Reviews und alles, was immer wiederkehrende Probleme zuverlässig und bestenfalls deterministisch für einen Agenten sichtbar macht. Relevante Learnings daraus gehören ins Harness-spezifische Projekt-Memory. Der Harness-Gedanke gefällt mir deshalb so gut, weil er den Schwerpunkt verschiebt. \u003ca href=\"https://www.hlyr.dev/blog/skill-issue-harness-engineering-for-coding-agents\"\u003eSystematisch absichern, was wiederholt schiefgeht\u003c/a\u003e, statt alles vorher ausformulieren. Weniger Vorab-Bürokratie. Mehr belastbare Leitplanken.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch3 id=\"so-viel-wie-notig-so-wenig-wie-moglich\"\u003eSo viel wie nötig, so wenig wie möglich\u003c/h3\u003e\n\n\u003cp\u003eIch halte Spec-driven Development nicht für einen Irrweg. BMAD hat für mich einen klaren Platz: beim Denken, Sortieren, Schneiden und Klären. Das hilft mir nicht nur im Solo-Modus, sondern kann auch im Team unterstützen, besonders wenn dieser Schritt zu kurz kommt oder unter den Tisch fällt.\u003c/p\u003e\n\n\u003cp\u003eAber bei der Implementierungsarbeit schreibe ich schnell mehr über Arbeit, als ich Arbeit habe. Und dann ist die Story kein Gesprächsanlass mehr, sondern ein Übergabedokument, das im stillen Kämmerlein entstanden ist.\u003c/p\u003e\n\n\u003cp\u003eSDD-Frameworks erhöhen in jeder Phase spürbar den Output. Aber Output ist nicht Outcome. Oder wie Patton in der Product-Ownership-Schulung sagte:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e„Minimize Output, Maximize Outcome \u0026amp; Impact.\"\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eWas ich über Umwege daraus gelernt habe: Die dickere Spec war nie das Ziel. Sie war ein Symptom dafür, dass ich Sicherheit im Dokument gesucht habe statt im Prozess.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/fh0ao6r7ro3x2v5if0yjeke3qsy5?_a=BACJ3SAE"},{"id":"https://www.innoq.com/en/blog/2026/04/versteckte-kosten-spec-driven-development/","url":"https://www.innoq.com/en/blog/2026/04/versteckte-kosten-spec-driven-development/","date_published":"2026-04-08T00:00:00.000+00:00","date_modified":"2026-04-08T20:37:47.722+02:00","author":[{"name":"Roman Stranghöner","url":"https://www.innoq.com/en/staff/roman-stranghoener/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eOver the past few months, spec-driven development has often helped me produce more – and better – AI-generated output than before. At the same time, I’ve also been noticeably more exhausted after many sessions.\u003c/p\u003e\n\n\u003cp\u003eNot despite the structure, but often \u003cem\u003ebecause\u003c/em\u003e of it.\u003c/p\u003e\n\n\u003cp\u003eAt first, that threw me off. Spec-driven development initially promises exactly the right thing: less chaos, more clarity, better results with agents. And that’s true, too – just not consistently.\u003c/p\u003e\n\n\u003cp\u003eBy now, my takeaway is pretty clear: the same structure that helps me during the thinking phase can slow me down during the build phase. Then I’m no longer building. I’m managing, phrasing, and documenting. And that’s exactly where the hidden costs of spec-driven development come from for me. I’m less interested in the big, abstract question of whether SDD is good or bad. I’m more interested in the practical one: \u003cstrong\u003eWhen does this way of working create real clarity – and when does it push thinking to the wrong place?\u003c/strong\u003e\u003c/p\u003e\n\n\u003ch3 id=\"the-right-kind-of-hard\"\u003eThe right kind of hard\u003c/h3\u003e\n\n\u003cp\u003eNot everything that’s hard is automatically bad. Some development work is hard because the problem itself is hard. Another part is hard because the way we work creates unnecessary friction.\u003c/p\u003e\n\n\u003cp\u003eThat difference is what has made spec-driven development interesting to me. With a framework like \u003ca href=\"https://docs.bmad-method.org/\"\u003eBMAD\u003c/a\u003e, I can think through an initiative more cleanly than I used to. It forces me to make fuzzy requirements explicit. I have to name constraints. I have to cut scope. I have to see gaps before I cover them up with generated code. That’s helpful.\u003c/p\u003e\n\n\u003cp\u003eBut at the same time, I’m noticing: this structure doesn’t feel equally useful in every phase. Sometimes it reduces complexity. Sometimes it just relocates it. And that difference isn’t theoretical for me – I feel it very concretely in my focus, my pace, and my energy.\u003c/p\u003e\n\n\u003cp\u003eThat’s why I no longer want to judge SDD in a blanket way. The real question, for me, is whether it’s the right kind of hard right now.\nDoes the structure help me understand? Or does it force me to spell out things that I could clarify much more easily while building, directly on the \u003cem\u003eliving thing\u003c/em\u003e?\u003c/p\u003e\n\n\u003ch3 id=\"why-sdd-can-help-during-the-thinking-phase\"\u003eWhy SDD can help during the thinking phase\u003c/h3\u003e\n\n\u003cp\u003eSpec-driven development solves a real problem when you’re starting from scratch. Anyone working with agents quickly learns that good context isn’t a nice-to-have.\nWell-structured context contributes massively to the solution.\u003c/p\u003e\n\n\u003cp\u003eIf I capture requirements, rough architecture, UX guardrails, and initial story cuts cleanly, a lot becomes easier later. Diffuse thoughts end up in clearer buckets. The problem gets smaller because I’ve already sorted it once. And later, the agent has something to hold on to—instead of starting from zero for every task.\u003c/p\u003e\n\n\u003cp\u003eThis helps me a lot, especially early in a project. Not because I never thought things through before, but because the framework forces me to really work out loose thoughts and write them down properly.\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003eWhat is this or that feature actually supposed to do, and for whom? Which constraints matter? Where do I deliberately want to decide nothing yet?\u003c/em\u003e For that kind of thinking, some structure is useful.\u003c/p\u003e\n\n\u003cp\u003eIf I described this using \u003ca href=\"https://www.innoq.com/en/blog/2026/03/ai-cognitive-lens-cognitive-load-theory/\"\u003eDaniel Westheide’s cognitive-load lens\u003c/a\u003e, it would be like this: in this phase, the framework reduces complexity. It breaks a big problem into smaller, workable parts.\u003c/p\u003e\n\n\u003cp\u003eThat’s \u003cstrong\u003ethe right kind of hard\u003c/strong\u003e. Or at least effort that feels meaningful to me.\u003c/p\u003e\n\n\u003ch3 id=\"when-building-devolves-into-documentation-work\"\u003eWhen building devolves into documentation work\u003c/h3\u003e\n\n\u003cp\u003eFor me, the problem often starts exactly where things should become productive: \u003cstrong\u003eimplementation\u003c/strong\u003e.\u003c/p\u003e\n\n\u003cp\u003eThen I’m no longer sitting in front of the actual problem. I’m sitting in front of a story spec, writing acceptance criteria for things that might never happen. I’m describing behavior for edge cases that I probably would have clarified in two iterations with the agent if I were building directly.\nI’m trying to press intuition into text upfront.\u003c/p\u003e\n\n\u003cp\u003eI notice this most clearly when generating a story from an epic. Before that, I’m still talking about functional requirements, non-functional requirements, and rough story skeletons – who are we building this for, what should happen, how will we know it’s enough. Instead, technical details and code examples creep in very quickly.\u003c/p\u003e\n\n\u003cp\u003eOne concrete example made this very clear. A story that was actually pretty simple – “Create User Profile” – turned into a massive package: 19 acceptance criteria, database fields, component mapping, dependency notes, file lists, test checklists, and later even review follow-ups. 1,070 lines of Markdown.\u003c/p\u003e\n\n\u003cp\u003eFormally, it was still called a story. In practice, it was half specification, half implementation plan, and half QA backlog. Yes, exactly – that’s three halves.\u003c/p\u003e\n\n\u003cp\u003eThat shifts the whole mode of thinking. I’m no longer talking about a story that makes sense to humans; I’m discussing a pre-decided implementation. The feedback loop gets longer because suddenly there are things on the table that didn’t need to be decided at that point. It gets even more problematic because those code snippets aren’t neutral. They prime the model that later implements the story. If I ever want to refactor the code or regenerate it with a better model, the story already contains a technical bias from an earlier planning step. That pre-commitment has long since seeped into the material.\u003c/p\u003e\n\n\u003ch3 id=\"why-not-everything-can-be-made-explicit\"\u003eWhy not everything can be made explicit\u003c/h3\u003e\n\n\u003cp\u003ePart of my discomfort has to do with something else: some of what makes development work good can’t be cleanly translated into language upfront.\u003c/p\u003e\n\n\u003cp\u003eThe best way I can describe it is through driving: when you’ve been driving for a while, you develop a sense for what will happen next. You see brake lights flicker three cars ahead. You ease off the gas, move into the left lane, pass, react proactively. It happens fast, almost without thinking. Coding feels similar to me. With some experience, you often sense early that a decision will cause problems three steps down the road. You adjust something before it breaks. Not because you could already articulate everything, but because you’re immersed in the thing itself.\u003c/p\u003e\n\n\u003cp\u003eSpec-driven frameworks try to close a gap with documents. That’s understandable. But part of that gap isn’t simply a documentation problem. It’s a problem of tacit knowledge. While building, we often know more than we can precisely say in advance. We recognize patterns. We notice something looks off before we can explain why.\u003c/p\u003e\n\n\u003cp\u003eTrying to press that experience fully into specs costs a lot of energy. And that’s the real loss for me: I have to switch from a mode of recognizing to a mode of explaining before I’ve even started building anything.\u003c/p\u003e\n\n\u003ch3 id=\"why-thick-specs-don-t-create-shared-understanding\"\u003eWhy thick specs don’t create shared understanding\u003c/h3\u003e\n\n\u003cp\u003eOne thought has stuck with me since a product owner training in 2017 with Jeff Patton and Jeff Gothelf: a story is not a document. It’s a token for a conversation.\u003c/p\u003e\n\n\u003cp\u003eFirst Card, then Conversation, then Confirmation. Not the other way around.\u003c/p\u003e\n\n\u003cp\u003eAcceptance criteria should confirm that you understood each other. They shouldn’t replace understanding with more and more upfront detail. That’s exactly where, for me, SDD tips over during the build phase. I write a document. The agent consumes it. There’s no real conversation – just a handoff.\u003c/p\u003e\n\n\u003cp\u003eAnd that removes something stories were originally meant to provide.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Four images: A team believes they agree, then realizes they have different mental models, works through the problem together, and only then reaches real understanding.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eReal understanding only emerges once everyone grapples with the same problem. Inspired by Jeff Patton.\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eI experienced exactly that in a client project last year. Within the team, I invested a lot of effort into detailed user stories (specs). No BMAD involved, and with genuinely good intentions: a solid first draft, including lots of acceptance criteria, so the team could hit the ground running instead of starting from scratch. But the team read the specs very differently. To them, it wasn’t a draft for discussion – it was already a finished handoff document. Everything’s in there already, right? So there was a lot of discussion, but not about the thing we needed to build; it was about the scope and shape of the stories.\u003c/p\u003e\n\n\u003cp\u003eThe result: on one side, someone wondering why they’re getting only negative feedback. On the other side, a team wondering why they should still have a say if everything already seems decided.\u003c/p\u003e\n\n\u003cp\u003eThe stories stayed that thick for quite a while. And the review load grew with them. Because from a thick story, an agent quickly produces a huge implementation plan including database schema, component structure, and so on. And at some point, nobody reads it properly anymore. That’s human. But it undermines exactly what the stories were supposed to ensure.\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e“Shared documents are not shared understanding”\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003ePatton nails it for me. The story gets thicker. I feel briefly safer. But that doesn’t mean something better will be built later. The document grows, but \u003ca href=\"https://margaretstorey.com/blog/2026/02/09/cognitive-debt/\"\u003eunderstanding doesn’t automatically grow with it\u003c/a\u003e.\u003c/p\u003e\n\n\u003cp\u003eIn the worst case, the opposite happens: I’ve produced a lot of text and convince myself I’ve thoroughly understood the problem – when what I’ve really produced is a clean handoff document.\u003c/p\u003e\n\n\u003cp\u003eIt looks like clarity. But sometimes it’s just a well-organized illusion of safety.\u003c/p\u003e\n\n\u003cp\u003eBMAD has a so-called party mode where different AI experts, each with a different perspective, discuss a story. It simulates a team conversation and sometimes brings surprising insights. But it remains a simulation. And the insights remain inside the AI session. A team that later has to live with the spec and the code learns nothing from it. No shared understanding flows back into people’s heads.\u003c/p\u003e\n\n\u003ch3 id=\"why-cheap-iteration-changes-the-equation\"\u003eWhy cheap iteration changes the equation\u003c/h3\u003e\n\n\u003cp\u003eMany SDD frameworks invest during planning as if \u003ca href=\"https://www.robert-glaser.de/what-if-iteration-is-all-we-need/\"\u003eiteration were still expensive\u003c/a\u003e. But with agents, it often isn’t anymore. A few quick rounds of “build it like this,” “no, more like that,” “yes, that’s it” are, in many situations, cheaper than spending hours polishing a perfect spec upfront.\u003c/p\u003e\n\n\u003cp\u003eSometimes the better answer is perhaps: start doing sooner and put better safety nets in place. That doesn’t mean planning becomes pointless. It just means the equation shifts. If the next testable prototype is minutes away instead of days, some of the upfront bureaucracy loses its economic advantage.\u003c/p\u003e\n\n\u003cp\u003eMore spec isn’t automatically the more reasonable form of risk management. Sometimes it’s more expensive thinking work – in more than one sense.\u003c/p\u003e\n\n\u003ch3 id=\"what-works-better-for-me\"\u003eWhat works better for me\u003c/h3\u003e\n\n\u003cp\u003eThat’s why I didn’t end up at “ditch the framework, just vibe-code.” That would be the wrong overcorrection. For example, I find an agent’s planning mode extremely useful. I just don’t want everything that is temporarily helpful in that thinking space to end up permanently in a story file.\u003c/p\u003e\n\n\u003cp\u003eWhat I do instead – and what I no longer do:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eIn the thinking phase\u003c/strong\u003e, I try to secure shared understanding in the team first, and only then capture the relevant information from that in a spec. Not the other way around. I still use a fixed structure for this – either BMAD or something homegrown. But I only write as much spec as actually creates real clarity for me or my team. The story stays short and describes what should happen for whom and how we’ll know it’s enough. Plus a few links to more context if needed. Essentially, \u003ca href=\"https://www.nngroup.com/articles/progressive-disclosure/\"\u003eprogressive disclosure\u003c/a\u003e for potentially relevant additional information such as the associated epic, personas, requirements, etc.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eIn the build phase\u003c/strong\u003e, I work in short loops close to the code. Ideally in a flow state. I let the agent plan based on the specs, but that specific plan can be ephemeral. It’s a working document, not an artifact. What I no longer do: stuffing the plan—including code examples, database fields, or file lists—into the story.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eDecisions\u003c/strong\u003e are something I deliberately separate from the spec. If architecture-relevant decisions come up during planning or implementation, I write an ADR. If it’s a product decision, it goes back into refinement or an updated story. If it’s a technical trade-off, it lands as a comment in the code or in architecture documentation. Decisions need a visible home, not a line in a 1,000-line Markdown file.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eSafeguards\u003c/strong\u003e I gradually shift from the document into the \u003ca href=\"https://www.innoq.com/en/blog/2026/02/from-vibe-coder-to-code-owner/\"\u003eharness\u003c/a\u003e: tests, linters, architecture rules, reviews, and anything that makes recurring problems reliably—and ideally deterministically—visible to an agent. Relevant learnings from that belong in the harness-specific project memory. I like the harness idea so much because it shifts the emphasis: \u003ca href=\"https://www.hlyr.dev/blog/skill-issue-harness-engineering-for-coding-agents\"\u003esystematically safeguard what repeatedly goes wrong\u003c/a\u003e instead of spelling everything out upfront. Less upfront bureaucracy. More robust guardrails.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch3 id=\"as-much-as-needed-as-little-as-possible\"\u003eAs much as needed, as little as possible\u003c/h3\u003e\n\n\u003cp\u003eI don’t think spec-driven development is a dead end. BMAD has a clear place for me: thinking, sorting, slicing, and clarifying. That doesn’t just help me solo; it can also support teams—especially when this step gets shortchanged or quietly skipped.\u003c/p\u003e\n\n\u003cp\u003eBut when it comes to implementation work, I quickly end up writing more about work than I actually do. And then the story is no longer a prompt for conversation, but a handoff document written behind closed doors.\u003c/p\u003e\n\n\u003cp\u003eSDD frameworks noticeably increase output in every phase. But output is not outcome. Or as Patton put it in that product ownership training:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e“Minimize Output, Maximize Outcome \u0026amp; Impact.”\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eWhat I learned the long way around: the thicker spec was never the goal. It was a symptom that I was looking for safety in the document instead of in the process.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/0xl4vmkc672ncqa5cv97fh54645b?_a=BACJ3SAE"},{"id":"https://www.innoq.com/de/blog/2026/04/jira-ki-ohne-cloud/","url":"https://www.innoq.com/de/blog/2026/04/jira-ki-ohne-cloud/","date_published":"2026-04-05T00:00:00.000+00:00","date_modified":"2026-04-10T14:42:49.099+02:00","author":[{"name":"Nicolas Inden","url":"https://www.innoq.com/en/staff/nicolas-inden/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003e\u003cem\u003eInspiriert vom \u003ca href=\"https://di.day/de\"\u003eDigital Independence Day\u003c/a\u003e, der zu Rezepten für digitale Souveränität aufruft, teilen wir hier regelmäßig eigene Lösungsansätze zu Themen, die unsere Kunden bewegen – ab sofort jeden ersten Sonntag im Monat.\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eFachlichkeiten zu besprechen funktioniert am besten im Dialog im Team und mit dem Kunden. Nicht selten ist es dabei so, dass für die Umsetzung wichtige Informationen in Nebensätzen erwähnt werden oder zwischen den Zeilen fallen. Das ist alles weit weg von den Eingabemasken, die uns Jira bietet, um Issues anzulegen. In meinem Alltag hat sich ein Workflow als echter Gamechanger herausgestellt: Notizen und Mitschriften aus Calls oder Chat-Diskussionen direkt an eine KI übergeben, die daraus sauber formulierte Jira-Issues erstellt – inklusive sinnvoller Felder, Beschreibungen und Struktur.\u003c/p\u003e\n\n\u003cp\u003eDas hat auch Atlassian erkannt, und der Jira Cloud einige KI-Features spendiert, die dabei unterstützen:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eIssues mit natürlicher Sprache zu suchen, z.B. “Welche Epics wurden im letzten Release umgesetzt?”, oder “Welche Tickets hatten wir schon zum Thema XYZ?”\u003c/li\u003e\n\u003cli\u003eInformationen sinnvoll zusammenzufassen, z.B. Kernpunkte aus Kommentaren an Issues herauskristallisieren, oder fachliche Zusammenfassungen eines Epics samt zugehöriger Issues erstellen.\u003c/li\u003e\n\u003cli\u003eIssue-Beschreibungen und Stories aus Gesprächsnotizen zu formulieren\u003c/li\u003e\n\u003cli\u003eIssues sinnvoll in Sub-Tasks zu unterteilen\u003c/li\u003e\n\u003cli\u003euvm.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eGerade die Möglichkeit, aus einer unstrukturierten Diskussion direkt strukturierte Issues zu erzeugen, spart enorm viel Zeit.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eInfo:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eAuch wenn für Atlassian der Weg eindeutig in Richtung Cloud zeigt - das on-premise Produkt Jira Data Center wird nur noch bis März 2029 supportet - so möchte nicht jeder die Atlassian Cloud verwenden, und damit sind sowohl Jira, als auch die in der Atlassian Cloud bereitgestellten KI-Features gemeint. Doch noch gibt es die Möglichkeit bestehende on-premise Installationen bis zum offiziellen Ende des Supports im März 2029 weiterzubetreiben. Und genau diesen Instanzen wollen wir mit diesem Artikel helfen, von ähnlichen KI-Hilfen zu profitieren.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eUnser Ziel ist eine DSGVO-konforme und Cloud-Act-sichere Nutzung von Jira inklusive der erwähnten KI-Features.\u003c/p\u003e\n\n\u003ch3 id=\"zutaten\"\u003eZutaten\u003c/h3\u003e\n\n\u003cp\u003eDazu brauchen wir:\u003c/p\u003e\n\n\u003col\u003e\n\u003cli\u003eEine selbst-betriebene Instanz von Jira Server oder Jira Data Center\u003c/li\u003e\n\u003cli\u003eZugang zu einer KI\u003c/li\u003e\n\u003cli\u003eEinen MCP-Server (mcp-atlassian), um die KI mit Jira Server zu verbinden\u003c/li\u003e\n\u003cli\u003eEin Tool, in dem die “Diskussion” zwischen User und KI stattfinden kann\u003c/li\u003e\n\u003c/ol\u003e\n\n\u003ch4 id=\"die-jira-instanz\"\u003eDie Jira Instanz\u003c/h4\u003e\n\n\u003cp\u003eWir gehen für \u003cstrong\u003ePunkt 1\u003c/strong\u003e davon aus, dass eine funktionsfähige, lizenzierte Instanz von Jira Server oder Jira Data Center in der aktuellen Version 11 vorhanden ist. Die Möglichkeit, neue Lizenzen für die beiden Produkte zu bekommen, gibt es seit 30.03.2026 leider nicht mehr. Wir gehen aber davon aus, dass es einige Projekte geben wird, die den on-premise Betrieb noch bis zum Ende des Supports im März 2029 aufrecht erhalten wollen.\u003c/p\u003e\n\n\u003ch4 id=\"die-richtige-ki\"\u003eDie richtige KI\u003c/h4\u003e\n\n\u003cp\u003eInteressanter wird es bei \u003cstrong\u003ePunkt 2\u003c/strong\u003e. Atlassian Cloud verwendet einen \u003ca href=\"https://support.atlassian.com/rovo/docs/rovo-data-privacy-and-usage-guidelines/\"\u003eMix an Open-Weights-Modellen und auch Frontier-Modelle von OpenAI und Anthropic\u003c/a\u003e. Eine Konformität mit der DSGVO mag hier noch gegeben sein. Das eigentliche Problem ist der Cloud Act: Durch die interne \u003ca href=\"https://www.atlassian.com/trust/reliability/cloud-architecture-and-operational-practices#cloud-infrastructure\"\u003eNutzung von AWS\u003c/a\u003e – und bei OpenAI und Anthropic sowieso – unterliegen sämtliche Daten dem Cloud Act. Es ist uns also daran gelegen, eine Alternative zu finden.\u003c/p\u003e\n\n\u003cp\u003eGrundsätzlich bieten sich zwei Möglichkeiten: Die Nutzung einer durch einen europäischen Anbieter betriebenen Inferenz-API, oder lokale Inferenz auf dem eigenen Computer. Europäische Anbieter wie StackIt, IONOS oder Scaleway bieten zwar pay-as-you-go Inferenz-APIs an, allerdings ist die Auswahl an aktuellen, leistungsfähigen Modellen dort teilweise begrenzt.\u003c/p\u003e\n\n\u003cp\u003eFür dieses Rezept konzentrieren wir uns daher auf die Verwendung von lokalen Modellen. Wir setzen dafür \u003ca href=\"https://lmstudio.ai/\"\u003eLM Studio\u003c/a\u003e als Inferenz-Engine und Chat-Tool ein. LM Studio ist für macOS, Linux und Windows verfügbar und kann auf der verlinkten Seite heruntergeladen werden.\nSobald es erfolgreich installiert ist, gilt es noch das passende Modell auszusuchen.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eInfo:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eLokale Inferenz benötigt Hardware mit viel und schnellem Speicher. Das kann entweder eine GPU mit entsprechendem VRAM sein, oder Systeme mit starker integrierter GPU und ausreichend gemeinsamen RAM, z.B. Apple Silicon oder AMD Strix Halo Systeme.\u003c/p\u003e\n\n\u003cp\u003eMit der Anzahl der Parameter des gewählten Modells skalieren auch die Hardware-Anforderungen. Eine ganz grobe Daumenregel ist: Pro einer Milliarde Parameter werden 1GB RAM benötigt. Ein \u003ccode\u003egpt-oss:20b\u003c/code\u003e sollte also 20GB (V)RAM zur Verfügung haben, meist reicht auch ein bisschen weniger.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eFür unseren Fall benötigen wir ein Modell, welches auf Tool Use ausgelegt ist. Als guten Kompromiss zwischen Fähigkeit für unseren Anwendungszweck, Geschwindigkeit und Hardware-Anforderungen hat sich \u003ccode\u003egpt-oss:20b\u003c/code\u003e herausgestellt – ein Open-Source-Modell mit starker Tool-Use-Unterstützung. Wer ein bisschen mehr RAM zur Verfügung hat, startet mit \u003ccode\u003eqwen3.5:35b-a3b\u003c/code\u003e. Diese Modelle können in LM Studio im Bereich \u003cstrong\u003eModel Search\u003c/strong\u003e gesucht und heruntergeladen werden.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"LM Studio screenshot showing “GPT-OSS 20B” selected and details for “openai/gpt-oss-20b” in the model library.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eAuswahl des gewünschten Large Language Models\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eEs bietet sich definitiv an, hier ein wenig experimentierfreudig zu sein. Es gibt mittlerweile eine Hülle und Fülle an Modellen, die alle ihre Stärken und Schwächen haben. Aber die beiden genannten sind auf jeden Fall ein guter Startpunkt.\u003c/p\u003e\n\n\u003ch4 id=\"der-ki-das-sprechen-mit-jira-beibringen-mcp\"\u003eDer KI das Sprechen mit Jira beibringen (MCP)\u003c/h4\u003e\n\n\u003cp\u003eAn dieser Stelle angekommen ist es möglich, mit der lokalen KI innerhalb von LM Studio zu chatten. Sämtliches Wissen der KI ist dabei in ihren trainierten Parametern (den sogenannten “Weights”) enthalten. Es gibt noch keine Verbindung zur “Außenwelt”. Für unser gestecktes Ziel fehlt der KI also noch die Fähigkeit, mit unserer Anwendung – dem Jira – zu sprechen. Darum kümmern wir uns hier in \u003cstrong\u003ePunkt 3\u003c/strong\u003e.\u003c/p\u003e\n\n\u003cp\u003eDafür nutzen wir einen passenden \u003ca href=\"https://modelcontextprotocol.io/docs/learn/server-concepts\"\u003eMCP-Server\u003c/a\u003e. Wir entscheiden uns für \u003ca href=\"https://github.com/sooperset/mcp-atlassian\"\u003emcp-atlassian\u003c/a\u003e. \u003ccode\u003emcp-atlassian\u003c/code\u003e ist ein Open-Source-Projekt, wird aktiv weiterentwickelt und erfreut sich auf GitHub schon vieler Sterne. Auch unsere persönlichen Tests mit \u003ccode\u003emcp-atlassian\u003c/code\u003e liefen erfolgreich.\u003c/p\u003e\n\n\u003cp\u003eDamit wir \u003ccode\u003emcp-atlassian\u003c/code\u003e benutzen können, ohne uns großartig mit Python und VirtualEnv auseinandersetzen zu müssen, installieren wir ein Tool namens \u003ccode\u003euv\u003c/code\u003e. Dieses nimmt uns das Beziehen und Installieren der aktuellen Version von \u003ccode\u003emcp-atlassian\u003c/code\u003e ab. Alle Informationen dazu finden sich \u003ca href=\"https://docs.astral.sh/uv/getting-started/installation/\"\u003ehier\u003c/a\u003e.\u003c/p\u003e\n\n\u003cp\u003eDamit LM Studio \u003ccode\u003emcp-atlassian\u003c/code\u003e benutzen kann, müssen wir es dort in die Konfiguration der MCP-Server aufnehmen, das geht hier:\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Developer UI showing “Local Server” and “Loaded Models” (READY, openai/gpt-oss-20b); red arrow points to “mcp.json”.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eEinbinden des MCP-Servers\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eSo sieht dann eine \u003ccode\u003emcp.json\u003c/code\u003e aus, mit der ihr einen mit der oben gezeigten \u003ccode\u003ecompose.yml\u003c/code\u003e lokal gestarteten Jira Server ansprechen könnt:\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n  \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"mcpServers\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n    \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"mcp-atlassian\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"command\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s2\"\u003e\"uvx\"\u003c/span\u003e\u003cspan class=\"p\"\u003e,\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"args\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"p\"\u003e[\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n        \u003c/span\u003e\u003cspan class=\"s2\"\u003e\"mcp-atlassian\"\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"p\"\u003e],\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"env\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n        \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"JIRA_URL\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s2\"\u003e\"https://meine-jira-instanz.org\"\u003c/span\u003e\u003cspan class=\"p\"\u003e,\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n        \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"JIRA_PERSONAL_TOKEN\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s2\"\u003e\"\u0026lt;dein-jira-personal-access-token\u0026gt;\"\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n    \u003c/span\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n  \u003c/span\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n\u003c/span\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eWir konfigurieren LM Studio so, dass es den MCP-Server mit \u003ccode\u003euvx mcp-atlassian\u003c/code\u003e aufrufen kann, und geben im Environment die benötigten Variablen zur URL und dem Personal Access Token (PAT) mit.\u003c/p\u003e\n\n\u003cp\u003eDas PAT bekommt ihr in Jira in eurem Profil. Dort kann ein PAT erstellt werden, welches ihr im MCP-Server verwenden könnt. Das bedeutet natürlich implizit, dass alle Aktionen, die ihr per MCP im Jira vornehmt, mit eurem User verbunden sind.\u003c/p\u003e\n\n\u003cp\u003eAls letzten Schritt starten wir einen neuen Chat und wählen \u003ccode\u003emcp-atlassian\u003c/code\u003e aus. Ab jetzt kann die KI die Werkzeuge, die \u003ccode\u003emcp-atlassian\u003c/code\u003e zur Verfügung stellt, benutzen und damit auf unser Jira zugreifen.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Integrations panel listing plugins; “mcp/mcp-atlassian” enabled, others off; search field “Type to filter plugins…”\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eAktivieren des MCP Servers\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eDamit ist der schwierigste Teil geschafft – Jetzt geht es ans Fine-Tuning.\u003c/p\u003e\n\n\u003ch4 id=\"der-chat\"\u003eDer Chat\u003c/h4\u003e\n\n\u003cp\u003eAb hier - in \u003cstrong\u003ePunkt 4\u003c/strong\u003e - fängt es an, richtig Spaß zu machen! LM Studio ist nicht nur unsere KI-Inferenz-Engine, sondern auch unser Chat-Tool, in dem unsere Nutzerinteraktion stattfindet. In einem LM Studio-Chat mit aktiviertem \u003ccode\u003emcp-atlassian\u003c/code\u003e können wir uns über alles unterhalten, was in unserem Jira-Projekt enthalten ist. Die KI nutzt selbstständig Werkzeuge, um Issues zu bestimmten Themen, aus bestimmten Zeiträumen oder von bestimmten Nutzern zu finden. Außerdem können auch Issues erstellt werden. Hier ein paar Prompts zur Inspiration:\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eBeispiel-Prompts:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cul\u003e\n\u003cli\u003eWelche Epics wurden im letzten Release behandelt?\u003c/li\u003e\n\u003cli\u003eErstelle mir aus diesen Informationen fachliche Release-Notes\u003c/li\u003e\n\u003cli\u003eWelche offenen Bugs sind mir zugewiesen?\u003c/li\u003e\n\u003cli\u003e…\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eUm das \u003cem\u003eErstellen\u003c/em\u003e von Issues zu testen, sind auch Prompts hilfreich wie\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eBeispiel-Prompt:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cul\u003e\n\u003cli\u003eDenke dir ein Feature aus und erstelle dazu ein Epic mit drei zugehörigen Stories\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eWer hier schon weiterdenkt: Über zusätzliche MCP-Server lassen sich auch andere Systeme wie GitLab oder GitHub anbinden – dazu mehr im Fazit.\u003c/p\u003e\n\n\u003cp\u003eDabei fallen aber direkt ein paar Kleinigkeiten auf – zumindest bei mir:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003ees gibt hin und wieder Probleme mit Umlauten in Beschreibungstexten\u003c/li\u003e\n\u003cli\u003edie KI verwendet gerne Markdown in Issue-Beschreibungen, was allerdings Jira nicht gerne mag\u003c/li\u003e\n\u003cli\u003e…\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eAber auch dafür gibt es zum Glück eine (nicht deterministische) Lösung: Die Anpassung des System-Prompts. Hier können solche Verhaltensweisen der KI effektiv angepasst werden – z.B. auch, dass die KI jedes Mal samt Vorschau fragen soll, bevor sie ein Issue wirklich im Jira anlegt.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"UI screenshot showing preset “Product Issue Assistant” and a “System Prompt” field with German text for Jira issue drafting.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eFine-Tuning im System Prompt\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003e\u003cstrong\u003eMein aktueller System-Prompt sieht so aus:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eDu bist kompetenter Product Owner und hast fundiertes Wissen im Formulieren und Schneiden von Aufgaben. Du unterstützt den Nutzer bei der Erstellung von Jira Issues indem du ihm hilfst Beschreibungen zu formulieren und Issue Felder korrekt zu setzen.\u003c/p\u003e\n\n\u003cp\u003eWenn es aus dem Input ersichtlich ist, schlägst du sinnvolle Werte für diese Felder vor:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eType\u003c/li\u003e\n\u003cli\u003eComponents\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eAntworte bitte auf Deutsch.\u003c/p\u003e\n\n\u003cp\u003eWenn du Issues erstellst, zeige eine Vorschau und frage nach einer Bestätigung bevor du das Issue wirklich per Tool anlegst.\u003c/p\u003e\n\n\u003cp\u003eVerwende Umlaute direkt (ä, ö, ü, ß) und normale Anführungszeichen (\" oder '').\u003c/p\u003e\n\n\u003cp\u003eDu arbeitest mit Jira. Verwende, wenn du per Tool Issues erstellst oder bearbeitest in Jira-Beschreibungen ausschließlich das Jira Wiki Markup mit der Syntax: h1. für Überschriften Ebene 1, h2. für Überschriften Ebene 2, h3. für Überschriften Ebene 3. Verwende niemals Markdown (#, ##) oder andere Syntax wie =Text= oder ====. Liste mit - verwenden.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003ch3 id=\"fazit\"\u003eFazit\u003c/h3\u003e\n\n\u003cp\u003eEine ganze Menge der von Atlassian Intelligence angebotenen Features lassen sich erfolgreich mit rein lokaler KI umsetzen. Das geschilderte Szenario ließe sich sogar noch weiter in die Breite denken: Binden wir nicht nur Jira, sondern auch das im Projekt verwendete Version-Control-System wie GitLab, GitHub \u0026amp; Co. per MCP ein, so stehen alle notwendigen Informationen der KI bereit, um feingranulare Release Notes automatisch zu erstellen. Freilich ist das mit Einrichtungsaufwand verbunden und nicht “out of the box” wie die Herstellerlösung, allerdings ist es durchaus praktikabel und ermöglicht die Nutzung von KI bei datenschutztechnisch hochsensiblen Themen. Außerdem sind wir mit dieser Lösung etwas mehr geschützt vor willkürlicher Preisanpassung von Cloud-Abo-Modellen.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/1jnxoai8h3l3pi5zlgbsnlcle8cg?_a=BACJ3SAE"},{"id":"https://www.innoq.com/en/blog/2026/04/jira-ki-ohne-cloud/","url":"https://www.innoq.com/en/blog/2026/04/jira-ki-ohne-cloud/","date_published":"2026-04-05T00:00:00.000+00:00","date_modified":"2026-04-10T14:43:03.734+02:00","author":[{"name":"Nicolas Inden","url":"https://www.innoq.com/en/staff/nicolas-inden/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003e\u003cem\u003eInspired by the \u003ca href=\"https://di.day/de\"\u003eDigital Independence Day\u003c/a\u003e and its call for “recipes” for digital sovereignty, we share our own approaches to topics that matter to our customers – every first Sunday of the month.\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eThe best way to discuss business requirements is still through direct conversation with your team and your customer. Important implementation details often come up in side comments or are only implied between the lines. That is a long way from the structured input forms Jira gives us for creating issues. In my day-to-day work, one workflow has been a real game changer: take notes and transcripts from calls or chat discussions, hand them to an AI, and let it turn them into well-written Jira issues – with sensible fields, descriptions, and structure.\u003c/p\u003e\n\n\u003cp\u003eAtlassian has recognized the same need and added several AI features to Jira Cloud to support exactly this:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eSearch issues in natural language, for example: “Which epics were delivered in the last release?” or “Which tickets have we already had on topic XYZ?”\u003c/li\u003e\n\u003cli\u003eSummarize information in useful ways, for example by distilling the key points from issue comments or creating a business-level summary of an epic and its related issues\u003c/li\u003e\n\u003cli\u003eDraft issue descriptions and stories from meeting notes\u003c/li\u003e\n\u003cli\u003eBreak issues down into meaningful subtasks\u003c/li\u003e\n\u003cli\u003eand more\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eThe ability to turn an unstructured discussion directly into structured issues saves a significant amount of time.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eNote:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eAtlassian is clearly moving toward the cloud – support for the on-premises product Jira Data Center only runs through March 2029. Still, not everyone wants to use Atlassian Cloud, and that includes both Jira itself and the AI features Atlassian provides in the cloud. Existing on-premises installations can continue running until official support ends in March 2029. This article is for exactly those environments and shows how they can benefit from similar AI capabilities.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eOur goal is to use Jira in a way that is GDPR-compliant and protected from the Cloud Act, including the AI features mentioned above.\u003c/p\u003e\n\n\u003ch3 id=\"what-you-need\"\u003eWhat you need\u003c/h3\u003e\n\n\u003cp\u003eHere is what we need:\u003c/p\u003e\n\n\u003col\u003e\n\u003cli\u003eA self-hosted Jira Server or Jira Data Center instance\u003c/li\u003e\n\u003cli\u003eAccess to an AI\u003c/li\u003e\n\u003cli\u003eAn MCP server (\u003ccode\u003emcp-atlassian\u003c/code\u003e) to connect the AI to Jira Server\u003c/li\u003e\n\u003cli\u003eA tool where the “discussion” between the user and the AI can happen\u003c/li\u003e\n\u003c/ol\u003e\n\n\u003ch4 id=\"the-jira-instance\"\u003eThe Jira instance\u003c/h4\u003e\n\n\u003cp\u003eFor \u003cstrong\u003eitem 1\u003c/strong\u003e, we assume you already have a working, licensed Jira Server or Jira Data Center instance running the current version 11. As of March 30, 2026, it is unfortunately no longer possible to obtain new licenses for either product. Even so, we expect that many projects will continue running on-premises until support ends in March 2029.\u003c/p\u003e\n\n\u003ch4 id=\"choosing-the-right-ai\"\u003eChoosing the right AI\u003c/h4\u003e\n\n\u003cp\u003eThings get more interesting with \u003cstrong\u003eitem 2\u003c/strong\u003e. Atlassian Cloud uses a \u003ca href=\"https://support.atlassian.com/rovo/docs/rovo-data-privacy-and-usage-guidelines/\"\u003emix of open-weight models and frontier models from OpenAI and Anthropic\u003c/a\u003e. That may still be GDPR-compliant. The real issue is the Cloud Act: because Atlassian internally \u003ca href=\"https://www.atlassian.com/trust/reliability/cloud-architecture-and-operational-practices#cloud-infrastructure\"\u003euses AWS\u003c/a\u003e – and because OpenAI and Anthropic do as well – all data is subject to Cloud Act exposure. So we need an alternative.\u003c/p\u003e\n\n\u003cp\u003eIn principle, there are two options: use an inference API operated by a European provider, or run inference locally on your own machine. European providers such as StackIt, IONOS, and Scaleway do offer pay-as-you-go inference APIs, but in some cases their selection of current high-performance models is still limited.\u003c/p\u003e\n\n\u003cp\u003eFor this recipe, we focus on local models. We use \u003ca href=\"https://lmstudio.ai/\"\u003eLM Studio\u003c/a\u003e as both the inference engine and the chat tool. LM Studio is available for macOS, Linux, and Windows and can be downloaded from the linked site. Once it is installed successfully, the next step is to choose the right model. Once it’s installed successfully, the next step is choosing the right model.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eNote:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eLocal inference requires hardware with a large amount of fast memory. That can mean a GPU with enough VRAM, or a system with a strong integrated GPU and enough shared RAM, such as Apple Silicon or AMD Strix Halo systems.\u003c/p\u003e\n\n\u003cp\u003eHardware requirements scale with the number of parameters in the model you choose. A very rough rule of thumb is 1 GB of RAM per 1 billion parameters. So \u003ccode\u003egpt-oss:20b\u003c/code\u003e should have 20 GB of (V)RAM available, although in practice a bit less is often enough.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eFor our use case, we need a model that is designed for tool use. In practice, \u003ccode\u003egpt-oss:20b\u003c/code\u003e has proven to be a good compromise between capability, speed, and hardware requirements – an open-source model with strong tool-use support. If you have a bit more RAM available, start with \u003ccode\u003eqwen3.5:35b-a3b\u003c/code\u003e. You can search for and download both models in LM Studio under \u003cstrong\u003eModel Search\u003c/strong\u003e.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"LM Studio screenshot showing “GPT-OSS 20B” selected and details for “openai/gpt-oss-20b” in the model library.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eSelecting the desired large language model\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eIt is definitely worth experimenting here. There is now a huge range of models available, and each comes with its own strengths and weaknesses. But the two models mentioned above are a solid place to start.\u003c/p\u003e\n\n\u003ch4 id=\"teaching-the-ai-to-talk-to-jira-mcp\"\u003eTeaching the AI to talk to Jira (MCP)\u003c/h4\u003e\n\n\u003cp\u003eAt this point, you can already chat with the local AI inside LM Studio. All of the AI’s knowledge is contained in its trained parameters—the so-called “weights.” There is still no connection to the outside world, though. To achieve our goal, the AI still needs the ability to talk to our application: Jira. That is what we address here in \u003cstrong\u003eitem 3\u003c/strong\u003e.\u003c/p\u003e\n\n\u003cp\u003eTo do that, we use a suitable \u003ca href=\"https://modelcontextprotocol.io/docs/learn/server-concepts\"\u003eMCP server\u003c/a\u003e. We chose \u003ca href=\"https://github.com/sooperset/mcp-atlassian\"\u003emcp-atlassian\u003c/a\u003e. \u003ccode\u003emcp-atlassian\u003c/code\u003e is an open-source project, it is actively maintained, and it has already collected plenty of stars on GitHub. Our own tests with \u003ccode\u003emcp-atlassian\u003c/code\u003e were successful as well.\u003c/p\u003e\n\n\u003cp\u003eTo use \u003ccode\u003emcp-atlassian\u003c/code\u003e without getting into the details of Python and virtual environments, we install a tool called \u003ccode\u003euv\u003c/code\u003e. It handles fetching and installing the current version of \u003ccode\u003emcp-atlassian\u003c/code\u003e for us. You can find all the details \u003ca href=\"https://docs.astral.sh/uv/getting-started/installation/\"\u003ehere\u003c/a\u003e.\u003c/p\u003e\n\n\u003cp\u003eTo let LM Studio use \u003ccode\u003emcp-atlassian\u003c/code\u003e, we need to add it to the MCP server configuration. You can do that here:\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Developer UI showing “Local Server” and “Loaded Models” (READY, openai/gpt-oss-20b); red arrow points to “mcp.json”.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eAdding the MCP server\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eA \u003ccode\u003emcp.json\u003c/code\u003e file that can connect to a Jira Server started locally with the \u003ccode\u003ecompose.yml\u003c/code\u003e shown above looks like this:\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n  \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"mcpServers\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n    \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"mcp-atlassian\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"command\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s2\"\u003e\"uvx\"\u003c/span\u003e\u003cspan class=\"p\"\u003e,\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"args\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"p\"\u003e[\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n        \u003c/span\u003e\u003cspan class=\"s2\"\u003e\"mcp-atlassian\"\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"p\"\u003e],\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"env\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n        \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"JIRA_URL\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s2\"\u003e\"https://meine-jira-instanz.org\"\u003c/span\u003e\u003cspan class=\"p\"\u003e,\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n        \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"JIRA_PERSONAL_TOKEN\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s2\"\u003e\"\u0026lt;dein-jira-personal-access-token\u0026gt;\"\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n    \u003c/span\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n  \u003c/span\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n\u003c/span\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eWe configure LM Studio so it can launch the MCP server with \u003ccode\u003euvx mcp-atlassian\u003c/code\u003e, and we pass the required environment variables for the URL and the personal access token (PAT).\u003c/p\u003e\n\n\u003cp\u003eYou can get the PAT in your Jira profile. There, you can create a PAT for the MCP server to use. Of course, that also means that any action you perform in Jira through MCP will be associated with your user account.\u003c/p\u003e\n\n\u003cp\u003eAs a final step, start a new chat and select \u003ccode\u003emcp-atlassian\u003c/code\u003e. From that point on, the AI can use the tools provided by \u003ccode\u003emcp-atlassian\u003c/code\u003e and access your Jira instance.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Integrations panel listing plugins; “mcp/mcp-atlassian” enabled, others off; search field “Type to filter plugins…\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eEnabling the MCP server\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eThat’s the hardest part done – now it’s time for fine-tuning.\u003c/p\u003e\n\n\u003ch4 id=\"the-chat\"\u003eThe chat\u003c/h4\u003e\n\n\u003cp\u003eThis is where \u003cstrong\u003eitem 4\u003c/strong\u003e gets really fun. LM Studio is not just our AI inference engine, but also our chat tool – the place where user interaction happens. In an LM Studio chat with \u003ccode\u003emcp-atlassian\u003c/code\u003e enabled, we can talk about anything that exists in our Jira project. The AI uses tools on its own to find issues on specific topics, from certain time periods, or created by particular users. It can also create issues. Here are a few prompts for inspiration:\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eExample prompts:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cul\u003e\n\u003cli\u003eWhich epics were addressed in the last release?\u003c/li\u003e\n\u003cli\u003eCreate business-facing release notes from this information\u003c/li\u003e\n\u003cli\u003eWhich open bugs are assigned to me?\u003c/li\u003e\n\u003cli\u003e…\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eTo test \u003cem\u003ecreating\u003c/em\u003e issues, prompts like the following are also useful:\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eExample prompt:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cul\u003e\n\u003cli\u003eMake up a feature and create an epic for it along with three related stories\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eIf you are already thinking one step ahead: with additional MCP servers, you can also connect other systems such as GitLab or GitHub. More on that in the conclusion.\u003c/p\u003e\n\n\u003cp\u003eThat said, a few minor issues become obvious pretty quickly – at least in my experience:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eevery now and then there are problems with umlauts in description texts\u003c/li\u003e\n\u003cli\u003ethe AI likes to use Markdown in issue descriptions, which Jira does not handle well\u003c/li\u003e\n\u003cli\u003e…\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eFortunately, there is a (non-deterministic) fix for that too: adjust the system prompt. This is where you can shape the AI’s behavior effectively—for example, by telling it to always show a preview and ask for confirmation before it actually creates an issue in Jira.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"UI screenshot showing preset “Product Issue Assistant” and a “System Prompt” field with German text for Jira issue drafting.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eFine-tuning via the system prompt\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003e\u003cstrong\u003eMy current system prompt looks like this:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eYou are a skilled product owner with strong expertise in writing and slicing work items. You support the user in creating Jira issues by helping formulate descriptions and set issue fields correctly.\u003c/p\u003e\n\n\u003cp\u003eWhen the input makes it possible, suggest sensible values for these fields:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eType\u003c/li\u003e\n\u003cli\u003eComponents\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003ePlease answer in German.\u003c/p\u003e\n\n\u003cp\u003eWhen you create issues, show a preview and ask for confirmation before you actually create the issue with a tool.\u003c/p\u003e\n\n\u003cp\u003eUse umlauts directly (ä, ö, ü, ß) and standard quotation marks (\" or '').\u003c/p\u003e\n\n\u003cp\u003eYou work with Jira. When you create or edit issues in Jira using tools, use only Jira Wiki Markup in Jira descriptions with the following syntax: \u003ccode\u003eh1.\u003c/code\u003e for level-1 headings, \u003ccode\u003eh2.\u003c/code\u003e for level-2 headings, \u003ccode\u003eh3.\u003c/code\u003e for level-3 headings. Never use Markdown (\u003ccode\u003e#\u003c/code\u003e, \u003ccode\u003e##\u003c/code\u003e) or other syntax such as \u003ccode\u003e=Text=\u003c/code\u003e or \u003ccode\u003e====\u003c/code\u003e. Use \u003ccode\u003e-\u003c/code\u003e for lists.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003ch3 id=\"conclusion\"\u003eConclusion\u003c/h3\u003e\n\n\u003cp\u003eA large share of the features offered by Atlassian Intelligence can be implemented successfully using only local AI. The scenario described here can even be taken further: if we connect not only Jira, but also the version control system used in the project – GitLab, GitHub, and others – through MCP, then the AI has all the information it needs to generate fine-grained release notes automatically. Of course, this requires some setup work and is not as out-of-the-box as the vendor solution. But it is absolutely practical and makes it possible to use AI even in highly privacy-sensitive environments. On top of that, this approach gives us a bit more protection from arbitrary price increases in cloud subscription models.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/9y5afqdak96j3c6lse9jntixd8z2?_a=BACJ3SAE"},{"id":"https://www.innoq.com/de/podcast/187-ai-news-3-bit-muessen-reichen/","url":"https://www.innoq.com/de/podcast/187-ai-news-3-bit-muessen-reichen/","date_published":"2026-04-02T00:00:00.000+00:00","date_modified":"2026-04-02T14:31:43.211+02:00","author":[{"name":"Fabian Walther","url":"https://www.innoq.com/en/staff/fabian-walther/"},{"name":"Ole Wendland","url":"https://www.innoq.com/en/staff/ole-wendland/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\u003cp\u003eIn dieser AI News-Ausgabe geht es vor allem um eine knappe Ressource: Speicher. Googles TurboQuant verspricht Abhilfe, hilft aber vor allem den Hyperscalern. Gleichzeitig werden CLIs zum neuen Lieblingstool für AI Agents – und die Sicherheitsfragen, die das aufwirft, kommen dabei zu kurz. Einen Fail der Woche haben Fabian und Ole auch im Gepäck: Anthropic leakt versehentlich den Quellcode von Claude Code.\r\n\u003c/p\u003e\u003c/body\u003e\u003c/html\u003e\n","image":"https://hotshot.innoq.io/shoot?path=%2Fen%2Fpodcast%2F187-ai-news-3-bit-muessen-reichen%2Fcover%2F%3Fheader%3D1\u0026selector=.cover\u0026padding=0"},{"id":"https://www.innoq.com/en/talks/2026/04/agentic-software-and-security-wer-kontrolliert-eigentlich-wen/","url":"https://www.innoq.com/en/talks/2026/04/agentic-software-and-security-wer-kontrolliert-eigentlich-wen/","date_published":"2026-03-03T00:00:00.000+00:00","date_modified":"2026-03-03T13:45:43.022+01:00","author":[{"name":"Dominik Guhr","url":"https://www.innoq.com/en/staff/dominik-guhr/"},{"name":"Felix Schumacher","url":"https://www.innoq.com/en/staff/felix-schumacher/"},{"name":"Dimitrij Drus","url":"https://www.innoq.com/en/staff/dimitrij-drus/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eKI-Systeme entwickeln sich rasant weiter: von reaktiven Modellen hin zu agentischer Software, die eigenständig Ziele verfolgt, Entscheidungen trifft und Aktionen ausführt. Damit verschiebt sich auch das Sicherheitsparadigma. Wenn Software nicht nur antwortet, sondern handelt – wie verändern sich dann Bedrohungsmodelle, Verantwortlichkeiten und Kontrollmechanismen?\u003c/p\u003e\n\n\u003cp\u003eIn diesem Panel sprechen Dominik Guhr, Felix Schumacher und Dimitrij Drus über die Security-mplikationen agentischer KI-Systeme: neue Angriffsflächen, Prompt- und Tool-Injection, Supply-Chain-Risiken, Governance-Fragen und die Herausforderung, Autonomie technisch und organisatorisch beherrschbar zu machen. Gemeinsam mit den Teilnehmenden wollen wir diskutieren, wie Security-by-Design für agentische Systeme aussehen kann – und wo aktuelle Konzepte an ihre Grenzen stoßen.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/de/podcast/012-produktdenken-fuer-plattformteams/","url":"https://www.innoq.com/de/podcast/012-produktdenken-fuer-plattformteams/","date_published":"2026-04-01T00:00:00.000+00:00","date_modified":"2026-04-01T15:04:57.938+02:00","author":[{"name":"Jörg Müller","url":"https://www.innoq.com/en/staff/joerg-mueller/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\u003cp\u003eIn dieser Folge von „CTO Need to Know“ sprechen Christoph Steinlehner und Jörg Müller darüber, warum Plattformteams nicht als Cost Center, sondern als Produktorganisation gedacht werden sollten. Sie zeigen, wie sich Prinzipien aus dem Produktmanagement auf interne Plattformen übertragen lassen: Von klar definierten Nutzergruppen über echte Mehrwertargumentation bis hin zu Developer Experience. Außerdem geht es darum, wie Plattformteams mit komplexen Stakeholder-Strukturen umgehen, wann Standards sinnvoll sind und welche Rolle KI künftig für Plattformstrategie und interne Toollandschaften spielt.\u003c/p\u003e\u003c/body\u003e\u003c/html\u003e\n","image":"https://hotshot.innoq.io/shoot?path=%2Fen%2Fpodcast%2F012-produktdenken-fuer-plattformteams%2Fcover%2F%3Fheader%3D1\u0026selector=.cover\u0026padding=0"},{"id":"https://www.innoq.com/en/blog/2026/03/ueber-ai-einsatz-in-verschiedenen-coding-situationen/","url":"https://www.innoq.com/en/blog/2026/03/ueber-ai-einsatz-in-verschiedenen-coding-situationen/","date_published":"2026-03-31T00:00:00.000+00:00","date_modified":"2026-03-31T13:29:44.941+02:00","author":[{"name":"Markus Harrer","url":"https://www.innoq.com/en/staff/markus-harrer/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWhere do I even start when trying to measure productivity gains from using Large Language Models (LLMs) in software development? In this short analysis, I simply draw on data from Yegor Denisov-Blanch’s talk \u003ca href=\"https://www.youtube.com/watch?v=tbDDYKRFjhk\"\u003eDoes AI Actually Boost Developer Productivity? (Stanford 100k Devs Study)\u003c/a\u003e. In it, 136 teams from 27 countries were surveyed on whether they see productivity improvements from using AI (more precisely: LLM-assisted software development).\u003c/p\u003e\n\n\u003cp\u003eThe following charts are relevant for my take on the “what really matters” factor; I’m repeating them here and adding my interpretation.\u003c/p\u003e\n\n\u003ch3 id=\"chart-i-context-is-the-brake\"\u003eChart I: Context Is the Brake\u003c/h3\u003e\n\n\u003cp\u003eOne of the most interesting insights from the talk, for me, is a 2x2 matrix that shows in which situations AI support actually adds productivity value for software developers. Instead of making blanket statements about AI productivity, the matrix breaks the question down along two dimensions: how mature the codebase is and how complex the task is. The results are more nuanced than the usual promises in glossy brochures (or on websites) from various AI tool vendors would have you believe.\u003c/p\u003e\n\n\u003cfigure style=\"margin: 2rem 2rem;\"\u003e\r\n\u003cimg alt=\"2x2 matrix; explanation and conclusions in the text below\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eProductivity gains from AI usage by project maturity and task complexity\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003ch4 id=\"my-interpretation\"\u003eMy interpretation\u003c/h4\u003e\n\n\u003cp\u003eThe matrix shows that productivity gains from AI are highest in greenfield projects with low task complexity—study participants report an uplift of 35–40% there. To me, the reason is obvious: low-complexity tasks are often repetitive and clearly defined, so AI can reliably generate boilerplate-heavy code with minimal risk of errors. Also, I suspect we’re in the realm of to-do list apps here: written a thousand times, and nothing new happens the thousand-and-first time.\u003c/p\u003e\n\n\u003cp\u003eHowever, the gains drop sharply as project maturity increases and/or task complexity rises (i.e., as soon as things get serious):\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eIn brownfield and legacy projects, the gains fall to 15–20% even for simple maintenance tasks, because outdated code and complex dependencies limit what AI can contribute safely.\u003c/li\u003e\n\u003cli\u003eFor highly complex tasks in systems that already resemble a Big Ball of Mud, the gains shrink to just 0–10%, because the AI struggles to cut through tangled architectures, poorly implemented ideas, and deeply nested logic.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eThis doesn’t surprise me: the underlying training data largely comes from public code repositories. There’s a clear bias in what gets shared—code you don’t have to be embarrassed about in public (at least that’s true for me). The real bulk of code that deviates from those idealized images sits inside companies’ closed software systems. An LLM’s first encounter with that kind of code can be jarring, which makes it harder to adapt known patterns from the training data to the existing codebase. Or, as Ludwig Wittgenstein put it more than a hundred years ago:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eThe limits of my language mean the limits of my world.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eEven in ideal greenfield environments, highly complex work caps AI’s impact at 10–15%, because those tasks require deeper human judgment that mechanical automation can’t replace. AI can assist, but it still can’t replace architectural thinking and contextual judgment—both of which complex engineering and domain knowledge demand. That also ties back to the limited amount of available context capacity (see my assessment in \u003ca href=\"https://markusharrer.de/blog/2026/02/17/agentic-software-modernization-chances-and-traps/\"\u003e“Agentic Software Modernization: Chances and Traps”\u003c/a\u003e).\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eTL;DR:\u003c/strong\u003e AI delivers the most when the problem is tightly scoped and the codebase is clean. High task complexity and legacy code are the two main productivity killers for AI—especially in combination (which is likely the reality for most of us).\u003c/p\u003e\n\n\u003ch3 id=\"chart-ii-the-niche-penalty\"\u003eChart II: The Niche Penalty\u003c/h3\u003e\n\n\u003cp\u003eThe second chart shifts the perspective from project maturity to the choice of programming language. It turns out that the popularity of the language has a significant impact on how much an LLM can actually help—mainly driven by how much training data exists for that language.\u003c/p\u003e\n\n\u003cfigure style=\"margin: 2rem 2rem;\"\u003e\r\n\u003cimg alt=\"2x2 matrix; explanation and conclusions in the text below\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eImpact of the programming language on AI-driven productivity gains\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003ch4 id=\"my-interpretation\"\u003eMy interpretation\u003c/h4\u003e\n\n\u003cp\u003eWith widely used languages (e.g., Python, Java), LLMs provide the most benefit: for simple tasks, they boost productivity by 20–25% thanks to extensive training data (e.g., via reinforcement learning on thousands of simple question–answer pairs); for complex tasks, by 10–15%. In popular languages, LLMs can still provide solid support because they’ve seen huge amounts of diverse training data. But even in the best case, complex tasks still require human judgment—so AI acts more as an accelerator than a replacement.\u003c/p\u003e\n\n\u003cp\u003eWith niche languages (e.g., COBOL—though to me that’s already mainstream), the gains for simple tasks are negligible at 0–5% (due to limited training data). For highly complex tasks, things get even worse: productivity can drop to as low as -5%, because the AI enters a hallucination-prone zone where it confidently produces plausible-sounding but incorrect output. This highlights that AI tools without sufficient training data can become a liability rather than an advantage in complex development work. Personally, I don’t see this changing for the better anytime soon. It’s also becoming clear that even \u003ca href=\"https://github.com/IBM/rpg-genai-data\"\u003eactively asking for code in niche programming languages\u003c/a\u003e doesn’t lead to enough high-quality training data (and honestly: what insurance company wants to put its COBOL-written computational core on GitHub?).\u003c/p\u003e\n\n\u003cp\u003eThe underlying driver in all four quadrants is the same: the more training data exists for a given language and task type, the more reliably AI can contribute. Language popularity is therefore not just a matter of personal preference—it’s a direct indicator of how productively you can use LLM-assisted software development.\u003c/p\u003e\n\n\u003ch3 id=\"chart-iii-heaven-or-hell\"\u003eChart III: Heaven or Hell\u003c/h3\u003e\n\n\u003cp\u003eFor the third chart, I rather pragmatically combine the average productivity gains from the two previous 2x2 charts into a third perspective. It shows productivity gains split by programming language popularity and project maturity. I’m particularly interested in this view for a concrete reason: I sometimes work in projects that use programming languages that don’t even make it into the top 50 most popular languages in the TIOBE Index (https://www.tiobe.com/tiobe-index/)—and languages that will never show up there because they exist only within a single company. And of course, it’s worth mentioning: these are decades-old, massive software systems that are now slowly due for modernization.\u003c/p\u003e\n\n\u003cfigure style=\"margin: 2rem 2rem;\"\u003e\r\n\u003cimg alt=\"2x2 matrix; explanation and conclusions in the text below\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eAI assistance productivity gain matrix\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003e\u003cem\u003eNote: This combined view is not a formally validated model. It’s a pragmatic thought experiment that connects two independent data sources by simply averaging them. It’s meant to provide orientation—not a precise prediction.\u003c/em\u003e\u003c/p\u003e\n\n\u003ch4 id=\"my-interpretation\"\u003eMy interpretation\u003c/h4\u003e\n\n\u003cp\u003eWhen you combine both dimensions—project maturity (greenfield vs. brownfield) and programming language popularity—you get four interesting quadrants. The best-case scenario, “AI Heaven,” happens when you’re working on a greenfield project in a widely used language: that’s where you can expect the highest productivity gains. It’s the ideal state: ample training data meets a clean, unburdened codebase. AI can reach its full potential. That’s why vibe coding and prototyping with languages like TypeScript and friends works so well.\u003c/p\u003e\n\n\u003cp\u003eIn brownfield projects written in popular languages, gains drop noticeably. Now you’re paying the price for letting code hygiene best practices slide (Yegor Denisov-Blanch also has an excellent talk on this: \u003ca href=\"https://www.youtube.com/watch?v=JvosMkuNxF8\"\u003e“Can you prove AI ROI in Software Eng?”\u003c/a\u003e). A Large Language Model still understands the well-known programming language just fine, but the complexity and technical debt in the existing codebase limit what it can contribute.\u003c/p\u003e\n\n\u003cp\u003eInterestingly, niche languages in greenfield projects still deliver noticeable gains—only slightly worse than the legacy-code scenario in popular languages. That suggests a clean codebase can partly compensate for weaker training data, although the language barrier still sets a meaningful ceiling. My bias here is that it’s simply always easier to start on a blank slate, no matter which language you use (I still remember the time when people kept saying “we’re just faster with Scala / F#,” which left me unimpressed even back then. It gets interesting once you have a mountain of code that goes beyond a to-do list).\u003c/p\u003e\n\n\u003cp\u003eThe worst-case scenario is “AI Hell”: a niche language combined with a brownfield codebase yields only minimal productivity gains. Here, both obstacles amplify each other. The AI has neither sufficient training data for the language nor the ability to meaningfully penetrate a tangled legacy codebase—the result is unreliable output and a high risk of doing more harm than good.\u003c/p\u003e\n\n\u003cp\u003eThe key takeaway: language popularity and project maturity both matter in their own right. And their negative effects add up. In other words, each dimension already reduces AI productivity on its own; together, they push AI-driven productivity gains down to the lowest level. Teams working with niche languages in legacy systems should be especially cautious about relying too heavily on AI tools (see, for example, my article \u003ca href=\"https://www.innoq.com/en/blog/2025/09/software-analytics-going-craizy/\"\u003e\"Software Analytics going crAIzy!\n\"\u003c/a\u003e).\u003c/p\u003e\n\n\u003cp\u003ePS: Did I mention I’m a fan of the \u003ca href=\"https://www.tqdev.com/2018-the-boring-software-manifesto/\"\u003eBoring Software Manifesto\u003c/a\u003e and have been preaching for years that people should join it? I believe that in the age of agentic software modernization, the manifesto is more relevant than ever. 😉\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003eIf you’re interested in the charts: the accompanying \u003ca href=\"https://github.com/feststelltaste/software-analytics/blob/master/notebooks/AI%20Productivity%20Gains%20in%20different%20Situations.ipynb\"\u003eJupyter Notebook\u003c/a\u003e, which generated the images based on the talk’s data, is available here.\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003eHeader image sourced from \u003ca href=\"https://commons.wikimedia.org/wiki/File:2011-365-314_Social_Media_Cootie_Catcher_(6333021221).jpg\"\u003eWikipedia\u003c/a\u003e, Creative Commons CC0 1.0 Universal Public Domain Dedication.\u003c/em\u003e\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/eftvwu6n9w445b1gpazsq716r60r?_a=BACJ3SAE"},{"id":"https://www.innoq.com/de/blog/2026/03/ueber-ai-einsatz-in-verschiedenen-coding-situationen/","url":"https://www.innoq.com/de/blog/2026/03/ueber-ai-einsatz-in-verschiedenen-coding-situationen/","date_published":"2026-03-31T00:00:00.000+00:00","date_modified":"2026-03-31T13:27:44.808+02:00","author":[{"name":"Markus Harrer","url":"https://www.innoq.com/en/staff/markus-harrer/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWo fange ich an, Produktivitätsgewinne beim Einsatz von Large Language Models (LLMs) für die Softwareentwicklung zu messen? Ich greife in dieser kurzen Analyse einfach auf Daten aus dem Vortrag \u003ca href=\"https://www.youtube.com/watch?v=tbDDYKRFjhk\"\u003eDoes AI Actually Boost Developer Productivity? (Stanford 100k Devs Study)\u003c/a\u003e von Yegor Denisov-Blanch zurück. Hier wurden 136 Teams aus 27 Ländern befragt, ob sie durch den Einsatz von KI (eigentlich: von LLM-unterstützter Softwareentwicklung) eine Produktivitätssteigerung sehen.\u003c/p\u003e\n\n\u003cp\u003eFolgende Diagramme sind für meine Betrachtung des “Worauf kommt es an”-Faktors relevant und werden hier noch einmal von mir wiederholt sowie interpretiert.\u003c/p\u003e\n\n\u003ch3 id=\"chart-i-die-context-bremse\"\u003eChart I: Die Context-Bremse\u003c/h3\u003e\n\n\u003cp\u003eEine der für mich interessantesten Erkenntnisse aus dem Vortrag ist eine 2x2-Matrix, die aufzeigt, in welchen Situationen KI-Unterstützung für Softwareentwickler:innen tatsächlich einen Produktivitätsmehrwert bringt. Anstatt pauschale Aussagen über KI-Produktivität zu treffen, schlüsselt die Matrix die Frage entlang zweier Dimensionen auf: wie ausgereift die Codebasis ist und wie komplex die jeweilige Aufgabe ist. Die Ergebnisse sind differenzierter, als es die üblichen Versprechen auf den Hochglanzbroschüren (oder Websites) diverser AI-Tool-Hersteller vermuten lassen.\u003c/p\u003e\n\n\u003cfigure style=\"margin: 2rem 2rem;\"\u003e\r\n\u003cimg alt=\"2x2 Matrix; Erklärung und Folgerungen im nachfolgenden Text\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eProduktivitätssteigerungen durch KI-Einsatz nach Projektreife und Aufgabenkomplexität\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003ch4 id=\"meine-interpretation\"\u003eMeine Interpretation\u003c/h4\u003e\n\n\u003cp\u003eDie Matrix zeigt, dass die Produktivitätsgewinne durch KI bei Greenfield-Projekten mit geringer Aufgabenkomplexität am höchsten ausfallen und dort laut den Studienteilnehmenden eine Steigerung von 35–40 % erzielen. Der Grund liegt für mich auf der Hand: Aufgaben mit geringer Komplexität sind häufig repetitiv und klar definiert, sodass KI zuverlässig Boilerplate-lastigen Code mit minimalem Fehlerrisiko erzeugen kann. Zudem denke ich, dass wir uns hier in der Liga von Todo-Listen-Apps befinden: Tausend Mal programmiert, tausend Mal ist damit nichts weiter passiert.\u003c/p\u003e\n\n\u003cp\u003eDie Produktivitätsgewinne nehmen jedoch deutlich ab, sobald die Projektreife zunimmt und/oder die Aufgabenkomplexität steigt (also sobald es ernster wird):\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eBei Brownfield- und Legacy-Projekten sinken die Gewinne selbst bei einfachen Wartungsaufgaben auf 15–20 %, da veralteter Code und komplexe Abhängigkeiten einschränken, was KI sicher beitragen kann.\u003c/li\u003e\n\u003cli\u003eBei hochkomplexen Aufgaben in Systemen, die bereits einem Big Ball of Mud gleichen, schrumpfen die Produktivitätsgewinne auf lediglich 0–10 %, weil die KI hier Schwierigkeiten hat, verworrene Architekturen, unklare umgesetzte Ideen und tief verschachtelte Logik zu durchdringen.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eFür mich an dieser Stelle nicht weiter verwunderlich: Die zugrundeliegenden Trainingsdaten stammen haufenweise aus öffentlich zugänglichen Code-Repositorien. Hier gibt es einen klaren Bias bezüglich dessen, was geteilt wird: Code, für den man sich nicht in der Öffentlichkeit schämen muss (also ist zumindest bei mir so). Die eigentliche Masse an Code, die anderen Idealbildern entspricht, bleibt in den geschlossenen Softwaresystemen der Unternehmen. Der erste Kontakt mit dieser Art von Code kann daher für ein LLM irritierend sein, wodurch bekannte Muster aus den Trainingsdaten schlechter auf die vorhandene Codebasis adaptiert werden können. Oder wie Ludwig Wittgenstein schon vor über hundert Jahren zu sagen pflegte:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eDie Grenzen meiner Sprache bedeuten die Grenzen meiner Welt.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eDoch selbst in idealen Greenfield-Umgebungen begrenzt hochkomplexe Arbeit den Einfluss der KI auf 10–15 %, da solche Aufgaben ein tieferes menschliches Urteilsvermögen erfordern, das mechanische Automatisierung nicht ersetzen kann. KI kann unterstützen, aber das architektonische Denkvermögen und das kontextuelle Urteil, das komplexes Engineering sowie Hintergrundwissen abverlangt, kann sie noch nicht ersetzen. Dies hat dann auch mit der begrenzten Menge an verfügbaren Context-Kapazitäten zu tun (siehe auch meine Einschätzung dazu in \u003ca href=\"https://markusharrer.de/blog/2026/02/17/agentic-software-modernization-chances-and-traps/\"\u003e“Agentic Software Modernization: Chances and Traps”\u003c/a\u003e).\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eTL;DR:\u003c/strong\u003e KI leistet am meisten, wenn das Problem klar eingegrenzt ist und die Codebasis sauber ist. Hohe Aufgabenkomplexität und Legacy-Code sind die zwei hauptsächlichen Produktivitätskiller beim Einsatz von KI, insbesondere im Zusammenspiel (was für die meisten unter uns die Realität sein dürfte).\u003c/p\u003e\n\n\u003ch3 id=\"chart-ii-die-nischen-strafe\"\u003eChart II: Die Nischen-Strafe\u003c/h3\u003e\n\n\u003cp\u003eDas zweite Diagramm verlagert den Blickwinkel von der Projektreife auf die Wahl der Programmiersprache. Es stellt sich heraus, dass die Popularität der verwendete Sprache einen erheblichen Einfluss darauf hat, wie viel ein LLM tatsächlich helfen kann, was hauptsächlich durch die Menge an verfügbaren Trainingsdaten für die jeweilige Sprache bedingt ist.\u003c/p\u003e\n\n\u003cfigure style=\"margin: 2rem 2rem;\"\u003e\r\n\u003cimg alt=\"2x2 Matrix; Erklärung und Folgerungen im nachfolgenden Text\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eEinfluss der Programmiersprache auf KI-Produktivitätsgewinne\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003ch4 id=\"meine-interpretation\"\u003eMeine Interpretation\u003c/h4\u003e\n\n\u003cp\u003eBei verbreiteten Sprachen (z. B. Python, Java) entfalten LLMs ihren größten Nutzen: Bei einfachen Aufgaben steigert sie die Produktivität um 20–25 % dank umfangreicher Trainingsdaten (z. B. durch Reinforcement Learning auf Tausenden einfachen Frage-Antwort-Paaren), bei komplexen Aufgaben um 10–15 %. LLMs können hier dann wohl dank Unmengen an vielfältigen Trainingsdaten in der jeweiligen, populären Programmiersprache noch gut unterstützen. Aber auch im besten Fall erfordern komplexe Aufgaben weiterhin menschliches Urteilsvermögen, sodass KI eher als Beschleuniger denn als Ersatz wirkt.\u003c/p\u003e\n\n\u003cp\u003eBei Nischensprachen (z. B. COBOL; wobei das für mich persönlich schon Mainstream ist) hingegen sind die Gewinne bei einfachen Aufgaben mit 0–5 % vernachlässigbar (bedingt durch begrenzte Trainingsdaten. Bei hochkomplexen Aufgaben verschlechtert sich die Situation weiter: Die Produktivität kann auf bis zu -5 % sinken, da die KI in eine halluzinationsanfällige Zone gerät, in der sie selbstsicher plausibel klingende, aber fehlerhafte Ausgaben produziert. Dies verdeutlicht, dass KI-Werkzeuge ohne ausreichende Trainingsdaten bei komplexer Entwicklungsarbeit eher zur Belastung als zum Vorteil werden können. Ich persönlich sehe hier auch in naher Zukunft keine positive Veränderung. Es zeichnet sich auch ab, dass selbst \u003ca href=\"https://github.com/IBM/rpg-genai-data\"\u003edas aktive Bitten um Code in Nischenprogrammiersprachen\u003c/a\u003e nicht dazu führt, ordentlich Trainingsdaten hierzu zu bekommen (und ganz ehrlich: Welche Versicherung will schon ihren in COBOL-geschriebenen Rechenkern auf GitHub stellen?).\u003c/p\u003e\n\n\u003cp\u003eDer zugrundeliegende Treiber in allen vier Quadranten ist derselbe: Je mehr Trainingsdaten für eine bestimmte Sprache und einen bestimmten Aufgabentyp vorliegen, desto zuverlässiger kann KI einen Beitrag leisten. Die Popularität einer Sprache ist daher nicht nur eine Frage persönlicher Vorlieben, sondern ein direkter Indikator für den produktiveren Einsatz von LLM-gestützter Softwareentwicklung.\u003c/p\u003e\n\n\u003ch3 id=\"chart-iii-himmel-oder-holle\"\u003eChart III: Himmel oder Hölle\u003c/h3\u003e\n\n\u003cp\u003eBeim dritten Diagramm kombiniere ich hemdsärmlig die Mittelwerte der Produktivitätsgewinne aus den beiden vorherigen 2x2-Diagrammen zu einer dritten Perspektive. Diese zeigt die Produktivitätsgewinne aufgeteilt nach Popularität der Programmiersprache und Reife des Projekts. Mich interessiert diese Perspektive besonders, weil ich einen konkreten Anlass dafür habe: Ich bin teils in Projekten unterwegs, in denen Programmiersprachen eingesetzt werden, die es nicht einmal in die Top 50 der populärsten Programmiersprachen des TIOBE Index (https://www.tiobe.com/tiobe-index/) schaffen, sowie Programmiersprachen, die dort auch nie und nimmer auftauchen werden, da es sie nur innerhalb eines Unternehmens gibt. Unerwähnt darf hier natürlich nicht bleiben, dass es sich um jahrzehntealte, riesige Softwaresysteme handelt, die nun doch langsam modernisiert werden wollen.\u003c/p\u003e\n\n\u003cfigure style=\"margin: 2rem 2rem;\"\u003e\r\n\u003cimg alt=\"2x2 Matrix; Erklärung und Folgerungen im nachfolgenden Text\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACJ3SAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eKI-Assistenz-Produktivitätsgewinn-Matrix\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003e\u003cem\u003eHinweis: Diese kombinierte Ansicht ist kein formal validiertes Modell, sondern ein pragmatisches Gedankenexperiment, das zwei unabhängige Datenquellen durch einfache Mittelwertbildung verbindet. Sie soll Orientierung geben, nicht als präzise Vorhersage dienen.\u003c/em\u003e\u003c/p\u003e\n\n\u003ch4 id=\"meine-interpretation\"\u003eMeine Interpretation\u003c/h4\u003e\n\n\u003cp\u003eWerden beide Dimensionen, Projektreife (Greenfield vs. Brownfield) und Popularität der Programmiersprache, kombiniert, ergeben sich vier interessante Quadranten. Das beste Szenario, “AI Heaven”, tritt auf, wenn in einer verbreiteten Sprache an einem Greenfield-Projekt gearbeitet wird: Dort sind die höchsten Produktivitätsgewinne zu erwarten. Dies ist der Idealzustand: Umfangreiche Trainingsdaten treffen auf eine saubere, unbelastete Codebasis. KI kann ihr volles Potenzial entfalten. Deshalb funktioniert auch Vibe Coding bzw. Prototyping mit Sprachen wie TypeScript und Co. so hervorragend.\u003c/p\u003e\n\n\u003cp\u003eBei Brownfield-Projekten in verbreiteten Sprachen sinken die Gewinne spürbar. Man zahlt nun die Zeche für das Schleifen-Lassen von Best Practices bezüglich der Codehygiene (hierzu gibt es auch einen hervorragenden weiteren Talk von Yegor Denisov-Blanch: \u003ca href=\"https://www.youtube.com/watch?v=JvosMkuNxF8\"\u003e“Can you prove AI ROI in Software Eng?”\u003c/a\u003e). Ein Large Language Model versteht die bekanntgemachte Programmiersprache nach wie vor gut, doch die Komplexität und die technischen Schulden der bestehenden Codebasis begrenzen seinen Beitrag.\u003c/p\u003e\n\n\u003cp\u003eInteressanterweise erzielen Nischensprachen bei Greenfield-Projekten immer noch merkliche Gewinne, was nur geringfügig schlechter ist als im Legacy-Code-Szenario mit verbreiteten Sprachen. Dies deutet darauf hin, dass eine saubere Codebasis schwächere Trainingsdaten teilweise kompensieren kann, die Sprachbarriere aber dennoch eine bedeutsame Obergrenze setzt. Mein Vorurteil hierzu ist, dass es eben immer einfacher ist, auf einer grünen Wiese zu starten, egal welche Programmiersprache zum Einsatz kommt (ich erinnere mich noch an die Zeit, als immer gesagt wurde “mit Scala / F# sind wir einfach schneller”, was mich damals schon kalt gelassen hatte. Interessant wird es, wenn man einen Berg an Code hat, der über eine Todo-Liste hinausgeht).\u003c/p\u003e\n\n\u003cp\u003eDas schlechteste Szenario ist “AI Hell”: Eine Nischensprache kombiniert mit einer Brownfield-Codebasis ergibt lediglich minimale Produktivitätsgewinne. Hier verstärken sich beide Hindernisse gegenseitig. Die KI verfügt weder über ausreichende Trainingsdaten für die Sprache noch ist sie in der Lage, eine verworrene Legacy-Codebasis sinnvoll zu durchdringen – das Ergebnis sind unzuverlässige Ausgaben und ein hohes Risiko, mehr Schaden als Nutzen anzurichten.\u003c/p\u003e\n\n\u003cp\u003eDie zentrale Erkenntnis lautet: Sprachpopularität und Projektreife sind beide eigenständig bedeutsam. Und: ihre negativen Effekte addieren sich. Bedeutet: Jede Dimension reduziert die KI-Produktivität für sich genommen bereits. Beide Dimensionen zusammen drücken die Produktivitätsgewinne durch den Einsatz von KI auf das unterste Niveau. Teams, die mit Nischensprachen in Legacy-Systemen arbeiten, sollten besonders vorsichtig sein, wenn es darum geht, sich zu stark rein auf KI-Werkzeuge zu verlassen (siehe hier z. B. meinen Artikel \u003ca href=\"https://www.innoq.com/en/blog/2025/09/software-analytics-going-craizy/\"\u003e\"Software Analytics going crAIzy!\n\"\u003c/a\u003e).\u003c/p\u003e\n\n\u003cp\u003ePS: Hatte ich schon erwähnt, dass ich Anhänger des \u003ca href=\"https://www.tqdev.com/2018-the-boring-software-manifesto/\"\u003eBoring Software Manifests\u003c/a\u003e bin und seit Jahren predige, sich diesem Manifest anzuschließen? Ich glaube, im Zeitalter agentischer Softwaremodernisierung wird das Manifest relevanter denn je zuvor. 😉\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003eWer sich für die Diagramme interessiert: Das zugehörige \u003ca href=\"https://github.com/feststelltaste/software-analytics/blob/master/notebooks/AI%20Productivity%20Gains%20in%20different%20Situations.ipynb\"\u003eJupyter Notebook\u003c/a\u003e, das die Bilder auf Basis der Daten aus dem Vortrag erstellt hat, ist hier verfügbar.\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003eHeader-Bild stamm von \u003ca href=\"https://commons.wikimedia.org/wiki/File:2011-365-314_Social_Media_Cootie_Catcher_(6333021221).jpg\"\u003eWikipedia\u003c/a\u003e, Creative Commons CC0 1.0 Universal Public Domain Dedication.\u003c/em\u003e\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/aufk4pdhj2wugdcb7qajuf5y8plg?_a=BACJ3SAE"},{"id":"https://www.innoq.com/en/talks/2026/03/why-iam-remains-a-challenge-and-what-we-can-do-about-it/","url":"https://www.innoq.com/en/talks/2026/03/why-iam-remains-a-challenge-and-what-we-can-do-about-it/","date_published":"2026-02-16T00:00:00.000+00:00","date_modified":"2026-02-16T14:13:31.637+01:00","author":[{"name":"Dimitrij Drus","url":"https://www.innoq.com/en/staff/dimitrij-drus/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eEveryone expects Identity \u0026amp; Access Management to be a “set it and forget it” problem. But the reality looks quite different: the same challenges keep resurfacing, they are technically demanding, time-consuming, and frequently create friction between teams, ultimately resulting in significant costs. And the rise of AI agents makes it even worse.\u003c/p\u003e\n\n\u003cp\u003eOver the years, Dimitrij explored these recurring issues, which led to a \u003ca href=\"https://www.innoq.com/en/blog/2025/07/whats-wrong-with-the-current-owasp-microservice-security-cheat-sheet/\"\u003emulti part blog series\u003c/a\u003e published in 2025, initially aimed at updating the OWASP Microservice Security Cheat Sheet. His goal was to show how well known IAM building blocks can be combined into pragmatic, coherent, and operationally realistic solutions. That work eventually grew beyond the original scope and is extending to multiple new OWASP Cheat Sheets plus an entirely new architectural-level cheat sheet format.\u003c/p\u003e\n\n\u003cp\u003eIn this talk Dimitrij will share the essence of the patterns and the strategies he identified and documented, show how to avoid the usual traps, and how to reduce IAM complexity in distributed systems to create the space to focus on what is actually being built - the product.\u003c/p\u003e\n\n\u003cp\u003eThis talk is aimed at developers, architects, and security practitioners working with distributed systems. It provides an overview of actually known IAM patterns that are however often unfamiliar in real-world projects.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/03/voxxed-days-zuerich-2026-spring-boot-test/","url":"https://www.innoq.com/en/talks/2026/03/voxxed-days-zuerich-2026-spring-boot-test/","date_published":"2025-12-17T00:00:00.000+00:00","date_modified":"2025-12-17T16:11:37.803+01:00","author":[{"name":"Michael Vitz","url":"https://www.innoq.com/en/staff/michael-vitz/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003e“Testing in Spring Boot applications is easy, just use @SpringBootTest and you’re done.” What sounds so simple in theory, often looks like magic and sometimes causes problems later on.\u003c/p\u003e\n\n\u003cp\u003eTherefore, in this session, we will take a look behind the curtain to gain better insight into how all of this actually works. Besides that, we will touch on topics such as unit or slice testing.\u003c/p\u003e\n\n\u003cp\u003eI assure you that after this session, you will have a more in-depth understanding of how the Spring Boot Test magic works.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/03/garbage-in-ist-kein-schicksal-bessere-anforderungen-fuer-entwicklungsteams/","url":"https://www.innoq.com/en/talks/2026/03/garbage-in-ist-kein-schicksal-bessere-anforderungen-fuer-entwicklungsteams/","date_published":"2026-02-16T00:00:00.000+00:00","date_modified":"2026-02-16T14:14:34.961+01:00","author":[{"name":"Dr. Gernot Starke","url":"https://www.innoq.com/en/staff/gernot-starke/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eUnklare Anforderungen führen zu technischen Entscheidungen durch falsche Annahmen – mit teuren Folgen für Architektur und Produkt.\u003c/p\u003e\n\n\u003cp\u003eDieser Vortrag zeigt einen pragmatischen Ansatz, mit dem Teams Anforderungen selbst systematisch klären und verbessern können, ohne Overhead oder Rollenverschiebung. Außerdem: pragmatische Hilfsmittel, die sich vielfach praktisch bewährt haben.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/de/podcast/186-ki-agenten-einsperren/","url":"https://www.innoq.com/de/podcast/186-ki-agenten-einsperren/","date_published":"2026-03-23T00:00:00.000+00:00","date_modified":"2026-03-20T12:20:41.430+01:00","author":[{"name":"Anja Kammer","url":"https://www.innoq.com/en/staff/anja-kammer/"},{"name":"Joy Heron","url":"https://www.innoq.com/en/staff/joy-heron/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\u003cp\u003eKI-Agenten können alles tun, was wir auch tun, inklusive Zugriff auf sensible Daten. Doch wie verhindert man, dass durch Prompt Injection oder unkontrollierte Zugriffe ein Sicherheitsrisiko entsteht? Joy Heron und Anja Kammer sprechen darüber, warum klassische Berechtigungsabfragen nicht ausreichen, wie Sandboxen das Risiko deutlich reduzieren und was ein praxistaugliches Setup für den sicheren Einsatz von KI-Agenten in der Softwareentwicklung ausmacht.\u003c/p\u003e\u003c/body\u003e\u003c/html\u003e\n","image":"https://hotshot.innoq.io/shoot?path=%2Fen%2Fpodcast%2F186-ki-agenten-einsperren%2Fcover%2F%3Fheader%3D1\u0026selector=.cover\u0026padding=0"},{"id":"https://www.innoq.com/en/talks/2026/03/agentic-coding-in-the-wild-jug-ch-zuerich-2026/","url":"https://www.innoq.com/en/talks/2026/03/agentic-coding-in-the-wild-jug-ch-zuerich-2026/","date_published":"2026-03-12T00:00:00.000+00:00","date_modified":"2026-03-12T11:15:26.105+01:00","author":[{"name":"Ole Wendland","url":"https://www.innoq.com/en/staff/ole-wendland/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWie schlägt sich Agentic Coding in der Praxis? Welche Vorteile sind realistisch, aber auch welche neuen Probleme und Herausforderungen entstehen für das Team und die Organisation, wenn man erfolgreich sein will?\u003c/p\u003e\n\n\u003cp\u003eIn diesem Talk werfen wir einen ehrlichen Blick auf die Realität von Agentic Coding. Denn AI ist eben nicht perfekt: Geschwindigkeit, Massendatenverarbeitung, transaktionale Sicherheit und Zuverlässigkeit bleiben Domänen, in denen klassischer Code seine Stärken ausspielt. Gleichzeitig bietet Agentic Coding Hebel, die Performance zu steigern und Teams produktiver zu machen.\u003c/p\u003e\n\n\u003cp\u003eWir schauen uns an, wie der Agentic Loop funktioniert, warum Context Engineering so entscheidend ist und welche Features zur Verfügung stehen.\nIm Hauptteil geht es um Best Practices: Wie behalte ich als Entwickler die Kontrolle? Wie briefe ich einen Agenten richtig? Und warum gilt „Trust, but Verify” mehr denn je? Abschliessend beleuchten wir die Herausforderungen für Seniors, Juniors, Teams und die gesamte Organisation und werfen einen Blick auf strategische Investitionen, die sich auch dann noch lohnen, wenn sich die Technologie weiterentwickelt (oder Agents doch nur ein Hype ist :P).\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/talks/2026/03/kontinuierliche-architektur-und-codemodernisierung-mit-team-habits-und-der-1-methode/","url":"https://www.innoq.com/en/talks/2026/03/kontinuierliche-architektur-und-codemodernisierung-mit-team-habits-und-der-1-methode/","date_published":"2026-02-16T00:00:00.000+00:00","date_modified":"2026-02-16T14:06:45.414+01:00","author":[{"name":"Michael Plöd","url":"https://www.innoq.com/en/staff/michael-ploed/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eDieser Vortrag soll mit Hilfe von zwei Ideen dazu motivieren, die Modernisierung von Architekturen und Codebases in kleinen und kontinuierlichen Schritten zu betrachten. Diese Ideen sind: Team-Habits und die 1%-Methode. Die Kombination aus beiden wird Euch und Eure Teams dazu befähigen, mit sehr kleinen Schritten, die sich aber kontinuierlich kumulieren, eine nachhaltige Praxis der laufenden Modernisierung zu etablieren, so dass schlussendlich bessere Architekturen und wartbarere Codebases entstehen ohne aber viel Unruhe, Risiko oder gar große Budgets samt der einhergehenden Politik zu riskieren.\u003c/p\u003e\n\n\u003cp\u003eDie grundlegenden Ideen dieser Vorgehensweise entsprangen dem Buch “Atomic Habits” von James Clear, der diese im Kontext persönlicher Abläufe im Privat- und Geschäftsleben vorgestellt hat. Allerdings lassen sich viele dieser Ansätze auch auf Software-Engineering-Teams übertragen und darum geht es in diesem Vortrag.\u003c/p\u003e\n\n\u003cp\u003eZiel ist es, im Team regelmäßig, idealerweise täglich, in kleinsten Schritten Verbesserungen zu etablieren. Diese Schritte sollten so klein sein, dass sie keinen nennenswerten Einfluss auf das Tagesgeschäft haben und dass jeder dieser Schritte für sich isoliert betrachtet keine nennenswerte/maßgebliche Verbesserung ist. Kumulieren sich diese Micro- oder Nano-Verbesserungen jedoch im gesamten Team über einen längeren Zeitraum, wird man sehen, dass sie ihre Wirkung exponentiell entfalten. Dieser Vortrag stellt die Idee vor, motiviert für selbige und hilft Euch dabei, sie praktisch in Euren Teams zu etablieren.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/blog/2026/03/rest-ist-das-bessere-mcp/","url":"https://www.innoq.com/en/blog/2026/03/rest-ist-das-bessere-mcp/","date_published":"2026-03-24T00:00:00.000+00:00","date_modified":"2026-03-24T13:17:23.211+01:00","author":[{"name":"Martin Otten","url":"https://www.innoq.com/en/staff/martin-otten/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eThere are always tasks we’d love to automate—but don’t. Often we don’t have the time, it’s not important enough, or we do it too infrequently. Or the tasks are context-dependent and can only be standardized with significant effort. So far, humans have handled them—even when they’re mind-numbingly boring.\u003c/p\u003e\n\n\u003cp\u003eFor me, one such task is regularly submitting travel expenses. In theory, we already have a decent tool that takes a lot of work off my plate. But there are many factors—travel times, locations, and different invoice formats—that mean I still have to create per-diem entries, assign cost centers, and attach receipts myself.\u003c/p\u003e\n\n\u003cp\u003eManual work like this adds unnecessary process cost. For me, it means context switching to a non-value-adding activity. And it causes waiting time elsewhere in the company. Waiting time is both the biggest problem—and the biggest lever—in process optimization. And since this is neither something that generates revenue nor something I enjoy, I keep postponing my expense report until the last minute—until accounting sends me a reminder. None of that would be necessary if someone else could just do it for me …\u003c/p\u003e\n\n\u003cp\u003eLuckily, an AI agent can do it for me today. That requires combining information from different data sources and entering it into the application. Appointments and travel times come from my calendar, invoices from my emails, and the expense report is created in a web application. There are different ways to access this data. MCP servers are the obvious approach—but they come with real drawbacks. They always load their entire instruction set into context, and you have to carefully review and choose the server implementations. At their core, MCP servers are just RPC—the caller has to know in advance which functions exist. A web app, on the other hand, shows you exactly what you can do in the current context. That’s why I chose different approaches for two of the integrations.\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eCalendar: Instead of an MCP server, I use a shared calendar that can be fetched as an iCal feed over HTTP—a standardized format that works everywhere without additional implementation.\u003c/li\u003e\n\u003cli\u003eMail: Access is handled via a command-line client (Himalaya), which provides a robust implementation and API. This is close to the idea of MCP, but works without the extra context overhead.\u003c/li\u003e\n\u003cli\u003eTravel-expense web application: There is no travel-expense MCP server here. Instead, we use the browser via an MCP for Playwright.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eBut can an AI agent work well with websites? When we think of browser automation, we probably think of tools like Selenium and brittle automated UI tests. That’s the wrong mental model. In fact, AI agents are very good at operating browsers interactively. Because they adapt, they can handle errors—and recover.\u003c/p\u003e\n\n\u003cp\u003eUsing web applications as interfaces for AI agents has clear advantages over an MCP server:\u003c/p\u003e\n\n\u003col\u003e\n\u003cli\u003eThe web app already exists—no need to build anything new.\u003c/li\u003e\n\u003cli\u003eWeb apps are the most mature form of hypermedia we have: via HTML and JavaScript we get context. Content, navigation structures, and available commands are already defined. They even change depending on context, instead of offering a static set of functions like MCP.\u003c/li\u003e\n\u003cli\u003eWeb apps are built for humans and humans make mistakes We already validate inputs in web applications and check whether actions are allowed or would lead to inconsistent states. It’s normal for people to make at least careless mistakes. That’s a big advantage for AI agents: they can make incorrect inputs, get feedback, and adjust their behavior to solve the problem.\u003c/li\u003e\n\u003cli\u003eWeb apps already come with roles and permissions. An agent can be given the minimum required privileges—without having to implement new security infrastructure.\u003c/li\u003e\n\u003c/ol\u003e\n\n\u003cp\u003eSo AI agents operate within a concrete set of possibilities, rather than solving a problem from scratch in a vacuum. There is a fixed context the agent can move within.\u003c/p\u003e\n\n\u003cp\u003eThere’s no split between the interface for humans and machines—it’s the same interface with the same capabilities, security guarantees, and problems.\u003c/p\u003e\n\n\u003cp\u003eWith JSON APIs, you typically get raw data, but no semantics.\u003c/p\u003e\n\n\u003cp\u003eSo far, hypermedia\u003ca href=\"https://www.innoq.com/en/blog/2026/03/rest-ist-das-bessere-mcp/#fn:1\" id=\"fnref:1\" title=\"see footnote\" class=\"footnote\"\u003e[1]\u003c/a\u003e has really only become established for “human” browser users. AI agents are the first non-human users that can actually take full advantage of these interfaces.\u003c/p\u003e\n\n\u003cp\u003eTo make this work, we only need an MCP server for browser usage. Like a web browser itself, it has no domain-specific functionality. It enables access to additional domain “tools” in the form of web applications. As a result, tool selection and tool specification become contextual and dynamic.\u003c/p\u003e\n\n\u003cp\u003eThat fits well with the fact that we also “program” AI agents dynamically through prompts. We give an instruction in natural language, and the language model is trained to develop a problem-solving strategy from it. Of course, the idea of declarative programming isn’t new. The most successful example is SQL, where I describe what I want without prescribing the solution path. But that’s a much narrower use case in which this approach has been feasible so far.\u003c/p\u003e\n\n\u003ch3 id=\"practical-example\"\u003ePractical example\u003c/h3\u003e\n\n\u003cp\u003eAn example of filing an expense report with an AI agent. We start with a naive prompt.\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eFor my “Event Storming workshop” at Capitol Versicherung in January, I need to file a travel expense report. We use https://reisekosten.example for that. You can find the travel details in my calendar. The hotel and train invoices are in my emails. Please create a folder for the trip. Use Playwright MCP to access the website. For each travel day, create a per-diem entry. Ask me if anything is unclear.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eThis prompt is far from being perfect instructions. Still, the agent had hardly any follow-up questions.\u003c/p\u003e\n\n\u003cp\u003eA quick confirmation:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cul\u003e\n\u003cli\u003eOn \u003cstrong\u003e2026–01–09\u003c/strong\u003e, were there really \u003cstrong\u003eno\u003c/strong\u003e meals provided?\u003c/li\u003e\n\u003cli\u003eWas breakfast provided by the hotel on 2026–01–10, 2026–01–11, and 2026–01–12?\u003c/li\u003e\n\u003cli\u003eI couldn’t find the project “Capitol Versicherung Event Storming workshop”, so I only set the \u003cstrong\u003ereason\u003c/strong\u003e. Should I leave it like that, or is there a different project name you use that I should select?\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eThe agent missed several contextual factors: that with an arrival time of 10 pm I probably don’t want to eat anything, that the breakfast information is already in the hotel invoice, and that it didn’t try to use the customer name to find an existing project.\u003c/p\u003e\n\n\u003cp\u003eAfter I provided the missing information, my expense report was actually already done. And that was with very little contextual detail. Before submitting, I review the folder myself in the web application.\u003c/p\u003e\n\n\u003cp\u003eNow I want the next expense report to run without follow-up questions if possible. So I ask the agent to write its own instructions. At first, the instructions consist of a process description and heuristics you could also give a human to complete this task. In addition, the agent made notes about technical issues when operating the website:\u003c/p\u003e\n\n\u003ch3 id=\"ui-workarounds-playwright-mcp\"\u003eUI workarounds (Playwright MCP)\u003c/h3\u003e\n\n\u003cp\u003eWhen date picker blocks checkboxes:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cul\u003e\n\u003cli\u003eClose the date picker first.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eIf the UI click is still blocked:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eSet the state in a controlled way via \u003ccode\u003eevaluate\u003c/code\u003e (\u003ccode\u003echecked\u003c/code\u003e) and trigger a \u003ccode\u003echange\u003c/code\u003e event.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eIf the project dropdown returns no results:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eClear the field, type slowly, wait for the listbox.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eWe can use these instructions as a skill and now have the agent review and update them after each run. This way, we can also document technical aspects that would otherwise be invisible to the user.\u003c/p\u003e\n\n\u003cp\u003eThat gives us a self-improving system that learns with each task, becomes more efficient, and makes fewer mistakes.\u003c/p\u003e\n\n\u003cp\u003eEven with a final review, the agent already removes a lot of tedious busywork. The agent is not yet fully autonomous: it is triggered manually, observed, and the result is checked. To truly eliminate waiting time, the agent would need to detect trips on its own and submit them as well.\u003c/p\u003e\n\n\u003cp\u003eTo make such a decision, we need to know not only whether the agent makes errors, but also the type and frequency of those errors. Fortunately, the process was designed for humans, who also make mistakes. This is where classic risk analysis comes in: What types of errors are possible, how likely are they, and what would the consequences be? In the end, you can decide whether the benefits from optimizing the process outweigh the risks overall.\u003c/p\u003e\n\n\u003cp\u003eIf we want to implement this for a higher-volume process—for example, all travel expense reports for all employees—we’ll also see more variance. One strategy is to run both processes in parallel and initially compare only the agent’s results with the manual expense reports. Only when the numbers match can you gradually switch over. Once this approach is established, it can also be used for auditing by automating only a portion of the tasks, or by having samples processed by humans and AI agents.\u003c/p\u003e\n\n\u003cp\u003eThere are many processes like this that could benefit from such automation. We probably haven’t paid attention to them so far because they weren’t relevant to software development. But now systems can be integrated automatically via web interfaces. We build on an existing system that provides context and security guarantees. The challenge is to identify the workflows that can be supported by agents and have the biggest impact on business operations.\u003c/p\u003e\n\n\u003cfoot-notes class=\"footnotes\"\u003e\n\n\u003col class=\"footnotes__list\"\u003e\n\n\u003cli id=\"fn:1\"\u003e\n\u003cp\u003eREST Level 3 (HATEOAS) \u003ca href=\"https://www.innoq.com/en/blog/2026/03/rest-ist-das-bessere-mcp/#fnref:1\" title=\"return to body\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003c/ol\u003e\n\u003c/foot-notes\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/ebrv3xkuqf6ncnpax39vjasbkudk?_a=BACJ3SAE"},{"id":"https://www.innoq.com/de/blog/2026/03/sdd-ddd-why-bmad-wont-save-you/","url":"https://www.innoq.com/de/blog/2026/03/sdd-ddd-why-bmad-wont-save-you/","date_published":"2026-03-18T00:00:00.000+00:00","date_modified":"2026-03-16T11:29:33.939+01:00","author":[{"name":"Daniel Westheide","url":"https://www.innoq.com/en/staff/daniel-westheide/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eIn meinem Beitrag \u003ca href=\"https://www.innoq.com/de/blog/2025/07/erst-agil-dann-agentisch/\"\u003eErst agil, dann agentisch\u003c/a\u003e habe ich argumentiert, dass Agentic Engineering auf organisationaler Ebene nur dann Vorteile bringt, wenn Organisationen bestimmte Fähigkeiten aus der Agile- und DevOps-Bewegung mitbringen. Denn wenn du die Entwicklungsarbeit nur beschleunigst, ohne deine Organisation entsprechend anzupassen, werden diese lokalen Vorteile nicht zu Verbesserungen auf Systemebene führen.\u003c/p\u003e\n\n\u003cp\u003eSpec-Driven Development Tools wie BMAD bekommen gerade viel Aufmerksamkeit – und das aus gutem Grund. Sie zielen darauf ab, ein reales Problem zu lösen, das ich in diesem Beitrag beschrieben habe: Requirements Engineering kann mit KI-unterstützten Entwicklungsteams nicht mithalten. Wenn Agenten eine sauber spezifizierte Story in Minuten implementieren können, wird der vorgelagerte Prozess zum Engpass. BMAD verspricht, das zu lösen, indem es über strukturierte KI-Interviews schnell gehaltvolle Spezifikationen erzeugt. Das Ergebnis: kein Warten mehr auf den Product Owner!\u003c/p\u003e\n\n\u003cp\u003eSind BMAD und andere Spec-driven Development Tools also das fehlende Puzzlestück, damit Agentic Engineering richtig durchstartet? Vielleicht. Unter bestimmten Bedingungen. Das Problem ist die Annahme, die sich hinter den großen Versprechen versteckt.\u003c/p\u003e\n\n\u003ch3 id=\"was-bmad-tatsachlich-macht\"\u003eWas BMAD tatsächlich macht\u003c/h3\u003e\n\n\u003cp\u003eBMAD stellt mehrere Agenten bereit, die jeweils eine klar abgegrenzte Rolle in einem Software-Produktentwicklungsteam abdecken. Einer davon ist Mary, der Analysten-Agent. Mary führt strukturierte Discovery-Interviews, macht Wettbewerbsanalysen, bewertet Geschäftsmodelle und erstellt umfassende Product-Requirements-Dokumente. Für jemanden, der bisher per Vibe-Coding eigene ad-hoc Anforderungen “irgendwie” entstehen ließ, ist das ein deutlicher Schritt nach vorn.\u003c/p\u003e\n\n\u003ch3 id=\"die-spezifikation-ist-nur-so-gut-wie-das-domanenwissen-im-team\"\u003eDie Spezifikation ist nur so gut wie das Domänenwissen im Team\u003c/h3\u003e\n\n\u003cp\u003eAber hier ist der Punkt: Die Spezifikationsschicht hängt vollständig von der Qualität des Domänenwissens ab, das der Mensch ins Interview mitbringt. Der Agent stellt präzise Fragen und kann dabei ziemlich hartnäckig sein. Er lässt dich nicht mit vagen oder ausweichenden Antworten davonkommen, sondern bohrt nach, bis etwas Konkretes vorliegt, mit dem er arbeiten kann. Das ist wertvoll. Aber er kann kein Domänenwissen herbeizaubern.\u003c/p\u003e\n\n\u003ch3 id=\"domain-driven-design-expert-innen-kennen-das\"\u003eDomain-Driven Design-Expert:innen kennen das\u003c/h3\u003e\n\n\u003cp\u003eDomain-Driven Design-Expert:innen werden diese Einschränkung sofort wiedererkennen. DDD erfordert eine dauerhafte, echte Zusammenarbeit zwischen Entwickler:innen und Domänenexpert:innen, um eine gemeinsame ubiquitäre Sprache und ein reichhaltiges Domänenmodell aufzubauen. Wenn Organisationen mit DDD kämpfen (und meiner Erfahrung nach tun das die meisten), liegt das selten daran, dass Entwickler:innen nicht gut genug ausgebildet sind. Häufiger ist das Problem, dass Domänenexpert:innen für Entwickler:innen nicht direkt erreichbar sind. Oft sitzen sie hinter vorgeschalteten Proxy-Product-Ownern. Und egal wie gut diese Product Owner ihre Arbeit machen, es geht dabei fast immer etwas in der Übersetzung verloren. Leider leiden viele Organisationen unter Strukturen und einer Kultur, die die direkte Zusammenarbeit über Bereichsgrenzen hinweg aktiv ausbremsen. Genau diese Zusammenarbeit ist aber entscheidend für erfolgreiches Domain-Driven Design.\u003c/p\u003e\n\n\u003cp\u003eBMAD stößt aus exakt demselben Grund gegen dieselbe Wand. Wenn deine Organisation DDD nicht sauber hinbekommt, kann sie auch nicht von BMADs Spezifikationsschicht profitieren.\u003c/p\u003e\n\n\u003ch3 id=\"vorab-spezifikation-vs-continuous-discovery\"\u003eVorab-Spezifikation vs. Continuous Discovery\u003c/h3\u003e\n\n\u003cp\u003eEs gibt allerdings einen wichtigen Unterschied. DDD setzt voraus, dass Domänenexpert:innen während der Entwicklung kontinuierlich verfügbar sind. Du gehst zu ihnen zurück, wenn dein Domänenmodell bei der Implementierung konzeptionelle Reibung erzeugt – und das passiert wiederholt und nicht planbar. Das Modell entsteht durch Iteration, nicht durch eine Vorab-Spezifikation. Eric Evans sagt das ausdrücklich: Discovery ist kontinuierlich und keine Phase, die man abschließt, bevor man mit dem Coden beginnt.\u003c/p\u003e\n\n\u003cp\u003eSpezifikationsgetriebene Entwicklung basiert auf einer anderen Annahme: Discovery passiert upfront über strukturierte Interviews, und die daraus entstehende Spezifikation steuert die Umsetzung.\u003c/p\u003e\n\n\u003cp\u003eJa, BMAD unterstützt iterative Verfeinerung innerhalb der Planungsphase. Aber der dominante Ablauf bleibt: erst planen, dann implementieren. Kritiker:innen von Spec-Driven Development sagen, hier schlage\n\u003ca href=\"https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html\"\u003e„Waterfall strikes back“\u003c/a\u003e\nzu – mit Big Design Up Front in Form von KI-generierter Dokumentation. Da ist was dran. Ein Domänenmodell, das durch Implementierung und wiederholter Zusammenarbeit entsteht, bildet Dinge ab, die kein Vorab-Interviewprozess zuverlässig ans Licht bringt.\u003c/p\u003e\n\n\u003ch3 id=\"wo-spec-driven-development-wirklich-passt\"\u003eWo Spec-Driven Development wirklich passt\u003c/h3\u003e\n\n\u003cp\u003eEs gibt einen Kontext, in dem BMAD meiner Meinung nach gut passen kann: die technische Gründerperson, die ihre eigene Produktidee umsetzt. Sie ist gleichzeitig Domänenexpert:in, Product Owner, Architekt:in und oft auch Entwickler:in. Es gibt kein Proxy-Problem. Es gibt keine Organisationsgrenzen, die man überwinden muss. Der Analysten-Agent interviewt jemanden, der die Produktidee selbst entwickelt hat, die potenziellen Nutzer:innen idealerweise kennt und zumindest ein grundlegendes Verständnis des Wettbewerbsumfelds mitbringt.\u003c/p\u003e\n\n\u003cp\u003eFür diese Person können BMADs Wettbewerbsanalyse, Marktrecherche und Geschäftsmodellbewertung ziemlich wertvoll sein. Und das Spezifikationsinterview funktioniert, weil das Wissen bereits im Raum ist.\u003c/p\u003e\n\n\u003cp\u003eDie Produktivitätsversprechen, die man in manchen Blogposts liest – etwa dass sich die Planungszeit von Wochen auf Stunden reduziert – werden sich wahrscheinlich vor allem in genau diesem Kontext von Solo-Gründer:innen oder Solo-Entwickler:innen materialisieren.\u003c/p\u003e\n\n\u003ch3 id=\"repariere-die-organisation-nicht-die-toolchain\"\u003eRepariere die Organisation, nicht die Toolchain\u003c/h3\u003e\n\n\u003cp\u003eBevor du überlegst, ob spezifikationsgetriebene Entwicklung dein Requirements Engineering beschleunigen kann, stell dir eine andere Frage: Kann dein Team bei Bedarf echten Zugang zu Domänenexpert:innen bekommen? Sind diese Expert:innen bereit und verfügbar, sich tiefgehend mit Entwicklungsfragen zu beschäftigen? Unterstützen Struktur und Kultur deiner Organisation diese Art der Zusammenarbeit?\u003c/p\u003e\n\n\u003cp\u003eWenn die Antwort ja lautet, können BMAD und andere Methoden aus dem Spec-Driven Development eine sinnvolle Option sein.\u003c/p\u003e\n\n\u003cp\u003eWenn die Antwort nein lautet, hast du ein Organisationsproblem, das kein Interview-Agent lösen kann. Das Tool wird dieses Problem nur expliziter sichtbar machen als ein traditioneller Requirements-Prozess. BMADs hartnäckiges Nachfragen macht Wissenslücken früh sichtbar – und zwar unübersehbar. Aber es kann sie nicht schließen.\u003c/p\u003e\n\n\u003cp\u003eDie Voraussetzung ist dieselbe, die ich in meinem \u003ca href=\"https://www.innoq.com/de/blog/2025/07/erst-agil-dann-agentisch/\"\u003eeingangs erwähnten Beitrag\u003c/a\u003e beschrieben habe: erst organisatorischer Wandel, dann Tools, die ihn verstärken.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/vryvsqyndq0673tsxrfh56yz3um9?_a=BACJ3SAE"},{"id":"https://www.innoq.com/de/blog/2026/03/rest-ist-das-bessere-mcp/","url":"https://www.innoq.com/de/blog/2026/03/rest-ist-das-bessere-mcp/","date_published":"2026-03-19T00:00:00.000+00:00","date_modified":"2026-03-24T12:35:00.207+01:00","author":[{"name":"Martin Otten","url":"https://www.innoq.com/en/staff/martin-otten/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eEs gibt immer Tätigkeiten, die wir gerne automatisieren würden, dies aber aus verschiedenen Gründen nicht tun. Oft fehlt die Zeit, es ist nicht wichtig genug oder wir machen es zu selten. Oder es handelt sich um Aufgaben, die kontextabhängig sind und nur mit hohem Aufwand standardisiert werden können. Diese Aufgaben werden bisher von Menschen erledigt, so langweilig sie auch sein mögen.\u003c/p\u003e\n\n\u003cp\u003eBei mir ist eine solche Aufgabe die regelmäßige Reisekostenabrechnung. Grundsätzlich haben wir hier bereits ein gutes Tool, das mir viel Arbeit abnimmt. Es gibt jedoch viele Faktoren wie Reisezeiten, Orte und verschiedene Rechnungsformate, die dazu führen, dass ich das Anlegen von Verpflegungspauschalen, Kostenstellen und das Zuordnen von Belegen selbst machen muss.\u003c/p\u003e\n\n\u003cp\u003eDerartige manuelle Tätigkeiten verursachen in Prozessen Kosten. Für mich bedeutet das einen Kontextwechsel zu einer Tätigkeit, die nicht wertschöpfend ist. Daraus entstehen für andere Teile des Unternehmens Wartezeiten. Wartezeiten sind dabei vielleicht das größte Problem und zugleich das größte Potenzial in der Prozessoptimierung. Und weil das nicht gerade eine Tätigkeit ist, mit der ich Umsatz erzeuge oder die ich gerne tue, schiebe ich diese Reisekostenabrechnung immer wieder bis zum letzten Moment auf und bekomme dann eine Erinnerung von der Buchhaltung. Dabei müsste das gar nicht passieren, wenn nur jemand anderes diese Aufgabe für mich erledigen könnte …\u003c/p\u003e\n\n\u003cp\u003eZum Glück kann ein KI-Agent das heute für mich erledigen. Dabei müssen Informationen aus verschiedenen Datenquellen kombiniert und in der Anwendung eingegeben werden. Termine und Reisezeiten stammen aus meinem Kalender, Rechnungen aus meinen E-Mails, und die Reisekosten werden in einer Web-Anwendung angelegt. Um auf diese Daten zuzugreifen, gibt es verschiedene Möglichkeiten. MCP-Server wären der klassische Weg, sie haben aber auch Nachteile. Sie laden ihre ganze Anleitung immer in den Kontext, und man muss die Implementierung der Server gut prüfen und auswählen. MCP-Server sind strukturell RPC – der Aufrufer muss vorab wissen, welche Funktionen existieren. Eine Web-Anwendung zeigt im jeweiligen Kontext dagegen, welche Aktionen gerade möglich und erlaubt sind. Daher habe ich für zwei der Integrationen andere Wege gewählt.\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eKalender: Statt eines MCP-Servers nutze ich einen geteilten Kalender, der als iCal-Feed über HTTP abrufbar ist – ein standardisiertes Format, das ohne zusätzliche Implementierung überall funktioniert.\u003c/li\u003e\n\u003cli\u003eMail: Der Zugriff läuft über einen Kommandozeilen-Client (Himalaya), der eine robuste Implementierung und API liefert. Dies ist nah an der Idee von MCP, funktioniert aber erst einmal ohne den zusätzlichen Kontext-Overhead.\u003c/li\u003e\n\u003cli\u003eReisekosten-Web-Anwendung: Hier gibt es keinen Reisekosten-MCP-Server. Wir nutzen stattdessen den Browser über ein MCP für Playwright.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eDoch kann ein KI-Agent gut mit Webseiten arbeiten? Wir denken bei Browserautomatisierung wahrscheinlich an Tools wie Selenium und brüchige automatisierte UI-Tests. Davon müssen wir uns hier lösen. Tatsächlich sind KI-Agenten sehr gut darin, Browser interaktiv zu bedienen. Da sie ihr Verhalten anpassen können, können sie auch mit Fehlern umgehen und Lösungen finden.\u003c/p\u003e\n\n\u003cp\u003eTatsächlich hat die Nutzung von Web-Anwendungen als Schnittstellen für KI-Agenten klare Vorteile gegenüber einem MCP-Server:\u003c/p\u003e\n\n\u003col\u003e\n\u003cli\u003eDie Web-Anwendung ist schon da, wir müssen nichts Neues implementieren.\u003c/li\u003e\n\u003cli\u003eWeb-Anwendungen sind die besten Implementierungen von Hypermedia, wir bekommen über HTML und JavaScript Kontext. Inhalte, Navigationsstrukturen und mögliche Commands sind vorgegeben. Sie ändern sich sogar abhängig vom Kontext, statt wie bei MCP eine statische Auswahl an Funktionen zu liefern.\u003c/li\u003e\n\u003cli\u003eWeb-Anwendungen sind für Menschen gebaut, die Fehler machen. Wir validieren in Web-Anwendungen bereits Eingaben und prüfen, ob Aktionen erlaubt sind oder zu inkonsistenten Zuständen führen. Es ist normal, dass Menschen zumindest Flüchtigkeitsfehler machen. Das ist ein großer Vorteil für KI-Agenten: Diese können hier Fehleingaben machen, bekommen Feedback und passen ihr Verhalten an, um das Problem zu lösen.\u003c/li\u003e\n\u003cli\u003eWeb-Anwendungen haben bereits ein Rollen- und Rechtesystem. Ein Agent erhält minimal notwendige Rechte, ohne neue Sicherheitsinfrastruktur implementieren zu müssen.\u003c/li\u003e\n\u003c/ol\u003e\n\n\u003cp\u003eSomit bewegen sich KI-Agenten in einem konkreten Rahmen an Möglichkeiten, statt ein Problem auf der grünen Wiese zu lösen. Es gibt einen festen Kontext, in dem sich der Agent bewegen kann.\u003c/p\u003e\n\n\u003cp\u003eEs gibt keinen Bruch zwischen der Schnittstelle für Menschen und Maschinen, es ist dieselbe Schnittstelle mit den gleichen Möglichkeiten, Sicherheitsgarantien und Problemen.\u003c/p\u003e\n\n\u003cp\u003eIm Vergleich dazu würden wir bei einer JSON-API oft nur Rohdaten, aber keine Semantik erhalten.\u003c/p\u003e\n\n\u003cp\u003eWirklich durchgesetzt hat sich Hypermedia\u003ca href=\"https://www.innoq.com/de/blog/2026/03/rest-ist-das-bessere-mcp/#fn:1\" id=\"fnref:1\" title=\"see footnote\" class=\"footnote\"\u003e[1]\u003c/a\u003e bisher nur für „menschliche“ Browser-Nutzer. KI-Agenten sind die ersten nicht menschlichen Nutzer, die diese Schnittstellen vollständig nutzen und von ihnen profitieren können.\u003c/p\u003e\n\n\u003cp\u003eUm dies zu ermöglichen, benötigen wir nur einen MCP-Server für die Browsernutzung. Dieser hat selbst, wie ein Webbrowser, keine fachliche Funktionalität. Er ermöglicht den Zugang zu weiteren fachlichen „Tools“ als Web-Anwendungen. Und damit ist die Tool-Auswahl und Tool-Spezifikation kontextabhängig und dynamisch geworden.\u003c/p\u003e\n\n\u003cp\u003eDies passt gut dazu, dass wir auch KI-Agenten durch Prompts dynamisch programmieren. Wir geben eine Anweisung in natürlicher Sprache, und das Sprachmodell ist darauf trainiert, daraus eine Problemlösungsstrategie zu entwickeln. Neu ist die Idee, deklarativ zu programmieren, natürlich nicht. Das erfolgreichste Beispiel ist die Datenbanksprache SQL, bei der ich beschreibe, was ich möchte, aber den Lösungsweg nicht vorgebe. Dies ist jedoch ein viel engerer Anwendungsfall, in dem ein solches Vorgehen bisher möglich war.\u003c/p\u003e\n\n\u003ch3 id=\"praxis-beispiel\"\u003ePraxis-Beispiel\u003c/h3\u003e\n\n\u003cp\u003eBeispiel einer Reisekostenabrechnung mit einem KI-Agenten. Wir starten mit einem naiven Prompt.\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eFür meinen „Event-Storming Workshop“ bei der Capitol Versicherung im Januar muss ich eine Reisekostenabrechnung durchführen. Dazu nutzen wir https://reisekosten.example. Die Reisedaten findest du in meinem Kalender. Rechnungen für Hotel und Bahnfahrt in meinen E-Mails. Bitte lege eine Mappe für die Reise an. Nutze Playwright-MCP, um auf die Webseite zuzugreifen. Lege für jeden Reisetag einen Eintrag Verpflegungspauschale an. Frage mich, wenn etwas unklar sein sollte.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eDieser Prompt ist weit davon entfernt, eine perfekte Anleitung vorzugeben. Dennoch hat der Agent kaum Rückfragen.\u003c/p\u003e\n\n\u003cp\u003eKurz zur Bestätigung:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cul\u003e\n\u003cli\u003eAm \u003cstrong\u003e09.01.2026\u003c/strong\u003e gab es wirklich \u003cstrong\u003ekeine\u003c/strong\u003e gestellten Mahlzeiten?\u003c/li\u003e\n\u003cli\u003eWurde am 10.01.2026, 11.01.2026 und 12.01.2026 Frühstück im Hotel gestellt?\u003c/li\u003e\n\u003cli\u003eDas Projekt „Capitol Versicherung Event-Storming Workshop“ konnte ich nicht finden, ich habe daher nur den \u003cstrong\u003eAnlass\u003c/strong\u003e gesetzt. Soll ich das so lassen, oder gibt es bei euch einen anderen Projektnamen, den ich auswählen soll?\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eDer Agent verpasste mehrere Kontextfaktoren: Dass ich um 22 Uhr Ankunftszeit wahrscheinlich nichts mehr essen möchte, dass die Frühstücksinformation bereits in der Hotelrechnung steht und, dass er nicht versuchte, den Kundennamen für ein existierendes Projekt zu nutzen.\u003c/p\u003e\n\n\u003cp\u003eNachdem ich die Informationen nachgeliefert habe, ist meine Reisekostenabrechnung aber tatsächlich schon fertig. Und das mit wenig Informationen zum Kontext. Vor dem Einreichen prüfe ich die Mappe in der Web-Anwendung selbst.\u003c/p\u003e\n\n\u003cp\u003eNun möchte ich, dass die nächste Reisekostenabrechnung, wenn möglich, ohne Rückfragen läuft. Daher bitte ich den Agenten, selbst eine Anleitung zu schreiben. Zunächst besteht die Anleitung aus einer Ablaufbeschreibung und Heuristiken, die man auch einem Menschen geben würde, um diese Tätigkeit durchzuführen. Zusätzlich hat sich der Agent Notizen zu technischen Problemen bei der Bedienung der Webseite gemacht:\u003c/p\u003e\n\n\u003ch3 id=\"ui-workarounds-playwright-mcp\"\u003eUI-Workarounds (Playwright-MCP)\u003c/h3\u003e\n\n\u003cp\u003eWenn Datepicker Checkboxen blockiert:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cul\u003e\n\u003cli\u003eDatepicker zuerst schließen.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eWenn UI-Klick weiterhin blockiert:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eZustand kontrolliert per \u003ccode\u003eevaluate\u003c/code\u003e setzen (\u003ccode\u003echecked\u003c/code\u003e) und \u003ccode\u003echange\u003c/code\u003e-Event auslösen.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eBei Projekt-Dropdown ohne Treffer:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eFeld leeren, langsam tippen, auf Listbox warten.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eDiese Anleitung können wir als Skill nutzen und den Agenten nun nach jeder Ausführung prüfen und aktualisieren lassen. Somit können auch solche technischen Aspekte dokumentiert werden, die für den Nutzer sonst unsichtbar sind.\u003c/p\u003e\n\n\u003cp\u003eDamit haben wir ein selbstlernendes System, das mit jeder Aufgabe dazulernt, effizienter wird und weniger Fehler macht.\u003c/p\u003e\n\n\u003cp\u003eBereits mit einer abschließenden Kontrolle nimmt der Agent hier viel Fleißarbeit ab. Noch läuft der Agent nicht völlig autonom, er wird manuell ausgelöst, beobachtet und das Ergebnis kontrolliert. Um wirklich die Wartezeit zu entfernen, müsste der Agent selbstständig Reisen erkennen und diese auch einreichen.\u003c/p\u003e\n\n\u003cp\u003eUm eine solche Entscheidung zu treffen, müssen wir nicht nur wissen, ob der Agent Fehler macht, sondern auch Art und Häufigkeit von Fehlern. Der Prozess ist zum Glück für Menschen entwickelt worden, die auch Fehler machen. Hier kommt eine klassische Risikoanalyse ins Spiel: Welche Arten von Fehlern sind möglich, wie wahrscheinlich sind sie und was wären die Konsequenzen? Am Ende kann dann entschieden werden, ob sich die Vorteile aus der Optimierung des Prozesses und die Risiken in Summe lohnen.\u003c/p\u003e\n\n\u003cp\u003eWenn wir dies für einen Prozess mit größerem Volumen umsetzen wollen, z. B. für alle Reisekostenabrechnungen aller Angestellten, dann werden wir auch mehr Varianz bekommen. Eine Strategie ist es, beide Prozesse parallel laufen zu lassen und zunächst nur die Ergebnisse des Agenten mit den manuellen Abrechnungen zu vergleichen. Erst wenn die Zahlen stimmen, kann man schrittweise umschalten. Wenn dieses Verfahren etabliert wurde, kann es auch zur Kontrolle eingesetzt werden, indem nur ein Teil der Aufgaben automatisiert erledigt wird oder Stichproben durch Menschen und KI-Agenten bearbeitet werden.\u003c/p\u003e\n\n\u003cp\u003eEs gibt zahlreiche derartige Prozesse, die von einer solchen Automatisierung profitieren könnten. Wahrscheinlich haben wir diese bisher nicht auf dem Schirm, da sie für die Softwareentwicklung nicht relevant waren. Nun lassen sich jedoch Systeme über Web-Oberflächen automatisiert integrieren. Wir bauen dabei auf einem bestehenden System auf, das Kontext und Sicherheitsgarantien bietet. Die Herausforderung ist es, die Abläufe zu identifizieren, die durch Agenten unterstützt werden können und die größte Auswirkung auf den Geschäftsablauf haben.\u003c/p\u003e\n\n\u003cfoot-notes class=\"footnotes\"\u003e\n\n\u003col class=\"footnotes__list\"\u003e\n\n\u003cli id=\"fn:1\"\u003e\n\u003cp\u003eREST Level 3 (HATEOAS) \u003ca href=\"https://www.innoq.com/de/blog/2026/03/rest-ist-das-bessere-mcp/#fnref:1\" title=\"return to body\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003c/ol\u003e\n\u003c/foot-notes\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/oyho42p94n3boy0i60t226z8odyc?_a=BACJ3SAE"},{"id":"https://www.innoq.com/en/talks/2026/03/agentic-coding-in-the-wild-jug-bern-2026/","url":"https://www.innoq.com/en/talks/2026/03/agentic-coding-in-the-wild-jug-bern-2026/","date_published":"2026-03-12T00:00:00.000+00:00","date_modified":"2026-03-12T11:12:57.482+01:00","author":[{"name":"Ole Wendland","url":"https://www.innoq.com/en/staff/ole-wendland/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWie schlägt sich Agentic Coding in der Praxis? Welche Vorteile sind realistisch, aber auch welche neuen Probleme und Herausforderungen entstehen für das Team und die Organisation, wenn man erfolgreich sein will?\u003c/p\u003e\n\n\u003cp\u003eIn diesem Talk werfen wir einen ehrlichen Blick auf die Realität von Agentic Coding. Denn AI ist eben nicht perfekt: Geschwindigkeit, Massendatenverarbeitung, transaktionale Sicherheit und Zuverlässigkeit bleiben Domänen, in denen klassischer Code seine Stärken ausspielt. Gleichzeitig bietet Agentic Coding Hebel, die Performance zu steigern und Teams produktiver zu machen.\u003c/p\u003e\n\n\u003cp\u003eWir schauen uns an, wie der Agentic Loop funktioniert, warum Context Engineering so entscheidend ist und welche Features zur Verfügung stehen.\nIm Hauptteil geht es um Best Practices: Wie behalte ich als Entwickler die Kontrolle? Wie briefe ich einen Agenten richtig? Und warum gilt „Trust, but Verify” mehr denn je? Abschliessend beleuchten wir die Herausforderungen für Seniors, Juniors, Teams und die gesamte Organisation und werfen einen Blick auf strategische Investitionen, die sich auch dann noch lohnen, wenn sich die Technologie weiterentwickelt (oder Agents doch nur ein Hype ist :P).\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"},{"id":"https://www.innoq.com/en/blog/2026/03/sdd-ddd-why-bmad-wont-save-you/","url":"https://www.innoq.com/en/blog/2026/03/sdd-ddd-why-bmad-wont-save-you/","date_published":"2026-03-18T00:00:00.000+00:00","date_modified":"2026-03-16T11:27:50.805+01:00","author":[{"name":"Daniel Westheide","url":"https://www.innoq.com/en/staff/daniel-westheide/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eIn my post \u003ca href=\"https://www.innoq.com/en/blog/2025/07/erst-agil-dann-agentisch/\"\u003eFirst Agile, Then Agentic\u003c/a\u003e, I argued that organisations need certain capabilities shaped by the agile and DevOps movements before agentic engineering practices can lead to benefits at the organisational level. If you just speed up development work without adapting your organisation accordingly, those local benefits will not translate to system-level improvements.\u003c/p\u003e\n\n\u003cp\u003eSpec-driven development tools like BMAD are receiving a lot of attention right now, and for good reason. They aim to solve a real problem I identified in that post: requirements engineering cannot keep up with AI-assisted development teams. If agents can implement a well-specified story in minutes, your upstream process becomes the bottleneck. BMAD promises to solve this by using structured AI interviews to quickly generate rich specifications. No more waiting for the product owner!\u003c/p\u003e\n\n\u003cp\u003eAre BMAD and other spec-driven development tools the missing piece to make your agentic engineering take off? Maybe, under specific conditions. The problem is the assumption hiding underneath the bold claims.\u003c/p\u003e\n\n\u003ch3 id=\"what-bmad-actually-does\"\u003eWhat BMAD actually does\u003c/h3\u003e\n\n\u003cp\u003eBMAD provides multiple agents, each one covering a distinct role in a software product development team. One of them is Mary, the analyst agent. Mary conducts structured discovery interviews, performs competitor analysis, evaluates business models, and generates comprehensive product requirements documents. For someone who has been vibe-coding their own ad-hoc requirements into existence, this is a significant step forward.\u003c/p\u003e\n\n\u003ch3 id=\"the-specification-is-only-as-good-as-the-domain-knowledge-in-the-room\"\u003eThe specification is only as good as the domain knowledge in the room\u003c/h3\u003e\n\n\u003cp\u003eBut here is the thing: the specification layer depends completely on the quality of domain knowledge the human brings to the interview. The agent asks rigorous questions and can be quite persistent. It won’t let you off the hook with vague or evasive answers, probing until it has something concrete to work with. That is valuable. But it cannot supply domain knowledge that isn’t in the room.\u003c/p\u003e\n\n\u003ch3 id=\"ddd-practioners-have-seen-this-before\"\u003eDDD practioners have seen this before\u003c/h3\u003e\n\n\u003cp\u003eDomain-Driven Design practitioners will recognise this constraint immediately. DDD requires sustained, genuine collaboration between developers and domain experts to build a shared ubiquitous language and a rich domain model. When organisations struggle with DDD (and in my experience, most of them do) it’s rarely because developers are not properly trained. More often, it’s because domain experts aren’t directly accessible to developers. Very often, they are buffered behind proxy product owners, and no matter how good a job those product owners do, there is almost certainly a loss in translation. Sadly, many organisations suffer from a structure and culture that actively discourages the direct cross-boundary collaboration that successful domain-driven design requires.\u003c/p\u003e\n\n\u003cp\u003eBMAD hits exactly the same wall for exactly the same reason. If your organisation can’t do DDD properly, it can’t benefit from BMAD’s specification layer either.\u003c/p\u003e\n\n\u003ch3 id=\"upfront-specification-vs-continuous-discovery\"\u003eUpfront specification vs. continuous discovery\u003c/h3\u003e\n\n\u003cp\u003eHowever, there is an important difference. DDD requires domain experts to be continuously available throughout development. You go back to them when your domain model hits conceptual friction during implementation, which happens repeatedly and unpredictably. The model emerges through iteration, not upfront specification. Eric Evans is explicit about this: discovery is continuous, not a phase you complete before coding begins.\u003c/p\u003e\n\n\u003cp\u003eSpec-driven development operates on a different assumption: Discovery happens upfront through structured interviews, and the resulting specification drives implementation.\u003c/p\u003e\n\n\u003cp\u003eYes, BMAD does support iterative refinement within the planning phase. But the dominant flow is still to plan and then implement. Critics of spec-driven development say that\n\u003ca href=\"https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html\"\u003e“waterfall strikes back”\u003c/a\u003e, leading to big design up front with AI-generated documentation. They have a point. A domain model that emerges through implementation and repeated collaboration will capture things no upfront interview process reliably surfaces.\u003c/p\u003e\n\n\u003ch3 id=\"where-spec-driven-development-actually-fits\"\u003eWhere spec-driven development actually fits\u003c/h3\u003e\n\n\u003cp\u003eThere is one context where I think BMAD can be a good fit: The technical founder building their own product idea. They are simultaneously the domain expert, the product owner, the architect, and often the developer. There is no proxy problem. There are no organisational boundaries to cross. The analyst agent interviews someone who conceived the product idea, hopefully knows the potential users and has at least some understanding of the competitive landscape.\u003c/p\u003e\n\n\u003cp\u003eFor that person, BMAD’s competitor analysis, market research, and business model evaluation can be quite valuable. And the specification interview works because the knowledge is already in the room.\u003c/p\u003e\n\n\u003cp\u003eThe productivity claims you read about in some blog posts, like planning time reduced from weeks to hours, are likely to primarily materialise in this specific context of solo entrepreneurs or solo developers.\u003c/p\u003e\n\n\u003ch3 id=\"fix-the-organisation-not-the-toolchain\"\u003eFix the organisation, not the toolchain\u003c/h3\u003e\n\n\u003cp\u003eBefore asking whether spec-driven development can accelerate your requirements engineering, ask yourself a different question: can your team get genuine access to domain experts when it needs them? Are those experts willing and available to engage deeply with development questions? Does your organisation’s structure and culture support that kind of collaboration?\u003c/p\u003e\n\n\u003cp\u003eIf the answer is yes, BMAD and other spec-driven development methods can be a viable option.\u003c/p\u003e\n\n\u003cp\u003eIf the answer is no, you have an organisational problem that no interviewing agent can fix. The tool will surface that problem more explicitly than a traditional requirements process. BMAD’s persistent questioning makes knowledge gaps visible early and right in your face. But it cannot resolve them.\u003c/p\u003e\n\n\u003cp\u003eThe prerequisite is the same one I explained in my \u003ca href=\"https://www.innoq.com/en/blog/2025/07/erst-agil-dann-agentisch/\"\u003eprevious post\u003c/a\u003e: organisational change first, then the tools that amplify it.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/h03teufg7zxm7n8htz04hrhgmkpo?_a=BACJ3SAE"},{"id":"https://www.innoq.com/en/talks/2026/03/it-modernisierung-vom-monolithen-zu-verteilten-systemen/","url":"https://www.innoq.com/en/talks/2026/03/it-modernisierung-vom-monolithen-zu-verteilten-systemen/","date_published":"2026-03-09T00:00:00.000+00:00","date_modified":"2026-03-09T18:23:55.177+01:00","author":[{"name":"Arne Landwehr","url":"https://www.innoq.com/en/staff/arne-landwehr/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWie gelingt eine sukzessive Modernisierung gewachsener IT-Landschaften ohne Big Bang? Wir sprechen über bewährte Migrationsstrategien, Architektur-Patterns und Lessons Learned auf dem Weg vom Monolithen zu verteilten Systemen – mit besonderem Blick auf Domain-driven Design als Leitprinzip für fachliche Schnitte und nachhaltige Architekturentscheidungen. Ich freue mich auf den Austausch mit Euch!\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n"}]}