Fast täglich hören wir neue Vorhersagen über Künstliche Intelligenz: Sie werde uns ersetzen, übertreffen oder sogar eine eigene Spezies werden. Doch welche dieser Annahmen halten einer genaueren Betrachtung stand? Tina Klüwer verbindet ihre Erfahrung aus KI-Forschung, Wirtschaft und Technologiepolitik und zeigt, warum KI gleichzeitig weit weniger und weit mächtiger ist, als viele glauben – und welche Konsequenzen das für die Zukunft der Softwareentwicklung und die Rolle des Menschen hat.

ADHS ist mehr als nur das Bild des zappeligen Kindes – gerade in der IT-Branche sind viele Erwachsene betroffen, oft ohne es zu wissen. Doch ADHS kann sowohl Fluch als auch Segen sein: Die kreativen Höhenflüge und das tiefe Hyperfokus-Tauchen sind oft genauso präsent wie das chaotische Durcheinander und der ständige Kampf mit Prokrastination.

In diesem Vortrag klären wir über die typischen Symptome von ADHS auf und geben erste Anhaltspunkte, wie man bei sich selbst mögliche Anzeichen erkennen kann. Außerdem beleuchten wir, wie Teams am besten mit ADHS-betroffenen Kolleg:innen umgehen können, um deren Potenziale voll auszuschöpfen. Abschließend teilen wir konkrete Strategien und Tipps für Softwareentwickler:innen, wie sie mit den Herausforderungen von ADHS besser umgehen und ihre Stärken besser nutzen können. Dieser Vortrag richtet sich an alle, die in der IT arbeiten und mehr über ADHS erfahren wollen – egal, ob als Betroffene oder als Kollegen.

Was muss eine Architektur leisten, damit ein Coding Agent darin sinnvoll arbeiten kann und das Ergebnis am Ende noch jemand verantworten will? Architekturarbeit war immer Kommunikationsarbeit zwischen Menschen. Mit Agenten kommt ein neuer Stakeholder mit Eigenheiten dazu: begrenztes Kontextfenster, kein Bauchgefühl, keine Kaffeeküche, emotionslos bei Architecture Decision Records (ADRs), dafür unermüdlich, schnell und mit zukünftig unbekanntem Pricing-Modell.

Aus diesen Eigenheiten lassen sich Kriterien ableiten, und die meisten davon kennen wir schon. Hohe Kohäsion und lose Kopplung halten das Kontextfenster beherrschbar. Eine durchgängige Ubiquitous Language von der Anforderung bis in den Code spart Übersetzungsschritte und Tokens. Branchenstandards nutzen das parametrische Wissen der Modelle, statt es teuer überschreiben zu müssen. Statische Typisierung, ArchUnit-Regeln, Custom-Linter und die erweiterte Testpyramide werden vom Disziplin-Thema zum Feedback-Mechanismus, mit dem der Agent sich selbst korrigieren kann.

Wir wollen zeigen, dass das, was wir heute schon unter guten Architektureigenschaften verstehen, auch für agentische Codegenerierung äußerst hilfreich ist. Gleichzeitig arbeiten wir heraus, welche Teile davon wirklich neu sind, natürlich unter der Bedingung, dass heute noch niemand sagen kann, wie wir in fünf Jahren Software entwickeln werden.

Agile Methoden haben ein Imageproblem. In Zeiten von Krisen, Disruption und wachsendem Kontrollbedürfnis ziehen sich viele Organisationen auf klassische Strukturen zurück: Agile Transformationen werden gestoppt, Scrum-Teams aufgelöst, Planbarkeit zum neuen Ideal erklärt. Die Ernüchterung ist spürbar: War das alles nur ein Hype?

In diesem Vortrag zeigen wir, dass agile Werte jenseits von Methoden und Prozessen relevanter sind als je zuvor.

Ausgehend von einer klaren Abgrenzung zwischen Werten und Prinzipien wird ein agiler Wertekanon hergeleitet, jenseits des Agilen Manifests, gespeist aus XP, Scrum und Lean. Wir zeigen auf der Basis aktueller Forschungsergebnisse, dass Menschen, die nach diesen Werten handeln, nachweislich resilienter, anpassungsfähiger und entscheidungssicherer sind. Gerade in der VUCA-Welt (Volatility, Uncertainty, Complexity, Ambiguity) sind das keine Nice-to-haves, sondern Kernkompetenzen.

Die Zuhörenden nehmen aus diesem Vortrag konkrete Orientierung mit: Sie verstehen, warum agile Werte auch dann wirksam sind, wenn klassische agile Methoden im eigenen Umfeld nicht durchsetzbar sind. Sie erhalten ein einfaches, anschlussfähiges Wertemodell, das sie unmittelbar in ihrer täglichen Arbeit anwenden können, unabhängig davon, ob ihr Umfeld agil aufgestellt ist oder nicht. Und sie gewinnen eine Haltung, die ihnen hilft, auch in hierarchischen oder widerständigen Kontexten als Brückenbauer:innen zu wirken: mit Respekt für die Nöte der Menschen, mit klarer Wertorientierung als Kompass und mit der Offenheit, agiles Denken dort einzubringen, wo es gebraucht wird, ohne Dogma, ohne Konfrontation.

Die Versuchung ist groß, mit AI Coding Agents die eigene Legacy-Codebase über Nacht komplett umbauen zu lassen. Aber nach tausend angepassten Klassen durch Hunderte von Agents (und zehn automatisch erhöhten LLM-Nutzungslimits) stellt sich dann oft nur eines heraus: Nichts funktioniert mehr, null, nada.

In diesem Vortrag zeigt Markus Harrer, warum Agents im Brownfield so schlecht abschneiden und was Sprachbarrieren und To-do-Listen-Apps damit zu tun haben. Aber auch, was gut funktioniert, kommt nicht zu kurz: Klassiker wie Seams, Slicing und Sprouting begrenzen vorab das potenzielle Chaos, Anker und Strukturen helfen dabei, Agents zielsicher zu navigieren, und Fitness Functions bringen bei Bedarf alles wieder auf Kurs. Das Ziel ist es, Legacy-Modernisierung mithilfe von AI Coding Agents verantwortbar zu machen.

Wie anders über Architekturentscheidungen nachgedacht werden kann.

Architekturentscheidungen sind nicht trivial. Manche begleiten uns ewig, andere hätten wir lieber anders getroffen. Es gibt Werkzeuge, die dabei helfen, es gibt Prozesse, die eingehalten werden sollten.

In diesem Vortrag geht es darum, wie man anders auf Entscheiden und Entscheidungen schauen kann. Wir betrachten:

• das Konzept von Architectural Decision Records aus der Perspektive eines Cheaters
• das Kapitel Entscheidungen aus arc42 aus der Perspektive kognitiver Verzerrungen
• den glauben an die Notwendigkeit von Entscheidungen aus der Perspektive eines Predigers

Alles in allem stellen wir das ganze Gerümpel in Frage. Und dann stellen wir fest, dass es nicht anders geht, aber trotzdem anders gemacht werden muss. Das Wie passt nicht mehr in den Abstract, aber in den Vortrag.

Gerade wird es spannend: Agentische KI fängt an, echte Arbeit in Unternehmen zu übernehmen. Ein solches Feature als Demo zum Laufen zu bringen, ist nicht schwer. Schwer wird der Weg in die Produktion. Und der entscheidet sich selten am Prompt. Den Ausschlag gibt alles drumherum.

Genau diesen Weg sind wir bei der österreichischen Versicherung NV gegangen. Unser Service liest eingehende Schadendokumente, ordnet sie ein und leitet sie an die passende Stelle im Prozess weiter, ob E-Mail, PDF oder eingescanntes Schriftstück. Mitten im Kerngeschäft, nicht am Rand.

Gemeinsam geben einen Erfahrungsbericht aus dem laufenden Projekt: Peter Friedl, der den Service auf Kundenseite entwickelt, und Michael Seel, der die AI Systems Architecture dahinter mitgestaltet. Wie wurde aus dem ersten Prototyp ein produktionsreifer Service? Wo hat uns die Architektur geholfen, wo haben wir Lehrgeld gezahlt?

Im Mittelpunkt stehen die Fragen, die kein Prompting-Guide beantwortet und die erst im Betrieb wirklich wehtun: Wie hält man den Vertrag zwischen Modell und Anwendung stabil, wenn die Antworten des Modells schwanken? Wie sichert man Qualität, wenn es kein simples richtig oder falsch gibt? Wie geht man mit Fehlern um und lernt daraus? Und wie behält man ein System im Blick, das sich nicht deterministisch verhält?

Ehrlich und aus erster Hand: was funktioniert, was wir wieder verworfen haben, und was wir beim nächsten Mal anders machen würden.

Datenprodukte sind ein zentrales Konzept moderner Datenarchitekturen. Doch wie groß sollte ein Datenprodukt eigentlich sein? Sind sie zu klein, müssen Konsument:innen mühsam Daten zusammenstückeln. Ist es zu groß, verliert das Produkt seinen klaren Zweck und seine Ownership. Dieser Talk gibt eine praxisnahe Einführung in Datenprodukte und die Architekturen, in denen sie eingesetzt werden. Anschließend werden konkrete Heuristiken für den richtigen Schnitt vorgestellt, die nach den drei Archetypen source-aligned, aggregate und consumer-aligned gegliedert sind. Der Fokus liegt auf anwendbaren Leitfragen, die Teams dabei helfen, bessere Entscheidungen beim Design ihrer Datenprodukte zu treffen.

Coding agents are increasingly capable, but most development environments were never designed to run untrusted, autonomous code with access to our tools, files, and networks. In this talk, I describe how I use a development sandbox for coding agents on macOS. By sharply limiting user permissions inside the sandbox, I reduce the agent’s access to private data and significantly constrain its blast radius – addressing the first and most obvious security risk.

Restricting file system access alone is not sufficient, however. Building on Simon Willison’s “lethal trifecta,” this talk explores additional measures for reducing the risks introduced by unrestricted network access and exposure to untrusted content. I discuss approaches for enforcing explicit network policies, removing the need for constant human oversight while still preventing arbitrary communication and data exfiltration. The goal is not perfect isolation, but a development setup that makes agent-assisted workflows safer by default without sacrificing usability.

Best Practices versprechen Orientierung: bessere Zusammenarbeit, weniger Reibung, stabilere Systeme. Trotzdem funktionieren bewährte Muster im eigenen Kontext nicht automatisch. Was in der Theorie sinnvoll klingt, trifft in der Praxis auf gewachsene Strukturen, unterschiedliche Verantwortlichkeiten, lokale Optimierungsziele und unausgesprochene Erwartungen.

Dieser Vortrag betrachtet Reibung zwischen IT-Teams als Signal in soziotechnischen Systemen – nicht als bloßes Kommunikationsproblem. Am Beispiel der Zusammenarbeit zwischen Plattform- und Entwicklungsteams wird gezeigt, warum Missverständnisse, Wartezeiten und Workarounds auch dann entstehen, wenn alle Beteiligten vermeintlich „das Richtige“ tun.

Painstorming dient als pragmatisches Werkzeug, um diese Reibung sichtbar zu machen: nicht durch vorschnelle Lösungsfindung, sondern durch bessere Fragen. Wer erlebt welchen Schmerz, in welcher Situation, mit welcher Wirkung – und welche Annahmen stecken dahinter?

Die zentrale These: Best Practices liefern mögliche Antworten. Aber erst bessere Fragen zeigen, welches Problem tatsächlich gelöst werden muss.

Stell dir vor, deine Fachanwender:innen fragen einfach: „Wer sind unsere Top-Kunden?", und schon liefern KI-Agenten wie Claude, ChatGPT oder Copilot die Antwort direkt aus euren internen Daten. Klingt riskant? Dank Data Contracts und dem Model Context Protocol (MCP) ist das kein Problem. Data Contracts liefern den semantischen Kontext für automatische SQL-Generierung und definieren verbindliche Nutzungsbedingungen. Der MCP-Server prüft jeden Datenzugriff gegen eure Governance-Richtlinien. Das Ergebnis ist demokratisierter Datenzugang ohne Kontrollverlust.

An agent produces code at speed. Producing a codebase you can still read, review, modify and test in six months is a different and more interesting problem.

Ever more extensive prompts and specification frameworks don't solve this. But cutting up a system into meaningful modules that support reasoning, changing, verifying and securing the whole is the core of software architecture and has been around for a long time already.

This work has only become more valuable with the advent of agentic software engineering: agents work more efficiently in well structured code environments, and humans profit in similar ways from "divide and conquer" that they always have. Creating, maintaining and iterating over a well-structured codebase has become both more relevant and more attainable now than ever before in a virtuous circle.

This talk is about how we shouldn't write off software design just yet, and how a bunch of well-placed constraints might just set you free.

„Open Source Slack-Alternative" googeln liefert Mattermost, Rocket.Chat, Element. Auf der Feature-Matrix sitzen Single Sign-On (SSO), Clustering und Compliance-Export zuverlässig hinter der Enterprise-Lizenz. Wer wechselt, tauscht das Logo auf der Rechnung, nicht die Abhängigkeit. Bei Datenbanken (Redis 2024) und Infrastruktur (HashiCorp 2023) zeigt sich dasselbe Muster: Open Core ist kein Bug, sondern das Geschäftsmodell.

Dieser Vortrag greift die Annahme dahinter an, dass „selber bauen" zu teuer und zu komplex ist. Mit agentischer Softwareentwicklung und einem strukturierten Spec-Driven-Prozess habe ich im Alleingang einen Matrix-kompatiblen Enterprise-Chat-Server gebaut: Nebu. Er ist Apache 2.0 lizenziert, läuft mit drei Laufzeit-Komponenten ohne Lizenzabhängigkeiten und bringt SSO, Audit-Log sowie Compliance-Zugriff ab der ersten Instanz mit.

Was du mitnimmst:

• warum das Cloudflare-Vibe-Coding-Desaster vom Januar 2026 die Branche zu Recht skeptisch gemacht hat und was Spec-Driven Development anders macht
• welche Architekturentscheidungen Komplexität wirklich rausnehmen, etwa der Verzicht auf Federation oder Elixir/OTP (Open Telecom Platform) statt Redis und NATS
• wie sich die Buy-vs-Build-Rechnung verschiebt, wenn eine einzelne erfahrene Fachkraft plus Agent ersetzt, was vorher ein Team brauchte
• wo der Ansatz nicht funktioniert und warum nicht alles selbst gebaut werden sollte

Für IT-Entscheider:innen, die bei der nächsten Lizenzverlängerung mehr Optionen wollen als „zahlen oder migrieren".

In last year's "First Agile, Then Agentic" talk, I argued that organisations need the right foundations before adopting agentic development and that you merely create a new bottleneck if all you do is speed up implementation work.

Studies show that AI makes coding faster. But the data suggests that for organisations without the right foundations, delivery doesn't get faster. Overall cycle time increases and software stability decreases. Yet many organisations respond by reinvesting in more output: accelerating requirements engineering and shipping more features. In this talk I will explain why that’s the wrong move.

The real opportunity is product discovery: understanding what is worth building in the first place. I will take a critical look at current AI discovery tools, examine where they hit fundamental limits, and make the case for investing the freed capacity in deeper, more rigorous discovery work. I will also explore what this means for how teams are structured and why agentic development finally makes it possible for developers to contribute where their technical perspective creates the most value.

Software zu entwickeln war noch nie so einfach wie heute. Ideen lassen sich schnell ausprobieren, Features schnell umsetzen, Releases schnell ausliefern. Dank generativer KI wird diese Entwicklung auch noch deutlich beschleunigt. Ich finde das spannend, weil dadurch vieles möglich wird, was früher deutlich mehr Aufwand erfordert hat. Gleichzeitig frage ich mich: Was nützt uns diese Geschwindigkeit, wenn wir nicht wissen, ob wir das richtige Problem lösen? In vielen Projekten sehe ich, dass Teams viel Energie in den Output stecken: Roadmaps, Tickets, Velocity, Releases. Das ist verständlich, weil all das sichtbar und planbar wirkt. Gleichzeitig fehlt manchmal das gemeinsame Bild davon, für wen wir eigentlich entwickeln und welchen Nutzen ein Feature haben soll. Dann sind wir zwar schnell, arbeiten aber nicht unbedingt in die richtige Richtung.

In meinem Talk möchte ich zeigen, wie Outcome-Driven Architecture Teams hilft, sich auf das Wesentliche zu konzentrieren, nicht als neue Rolle oder Framework, sondern als Haltung. Architektur bestimmt nicht nur, wie ein System gebaut ist, sondern auch, wie wir lernen, beobachten und uns verbessern können. Gute Architektur hilft Teams, Annahmen zu prüfen, Experimente zu ermöglichen und auf neue Erkenntnisse zu reagieren. Am Ende zählt nicht, wie viel Code entsteht, sondern welchen Wert Software für Menschen schafft.

In 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.

In 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 denen 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.

Beim Technology Day 2025 habe ich gezeigt, wie sich Passkeys mit WebAuthn integrieren lassen, dem W3C-Standard für passwortlose Authentifizierung. Der Fokus lag dabei bewusst auf dem großen Ganzen. In diesem Vortrag knüpfe ich daran an und gehe technisch deutlich tiefer: Diesmal geht es um die konkreten Probleme, die bei der Einführung von Passkeys in bestehende Systeme auftreten. Wer sich die Aufzeichnung vom letzten Jahr ansehen möchte, findet sie auf dem INNOQ YouTube-Kanal.

Models help us make complex domains manageable in software. We don't map reality itself, but rather a reduced version: one that's powerful enough to create value. But how do we build such models? In Java, object orientation is often the first choice, since many widely used frameworks embrace and promote this paradigm.

Over the years, however, Java has gained many functional features that allow us to leverage the strengths of functional approaches for domain modeling.

Using an example, we'll explore how to express functional models of our business domains in code using modern Java features. This gives us another powerful tool in our toolbox, one that helps us not only design new systems with more value but also gradually regain control over legacy systems.

Es war nie leichter, Software zu bauen. Was früher ein Team und ein Quartal gebraucht hat, entsteht heute in Tagen. Aber diese neue Superkraft macht einsam. Der Agent wird zum wichtigsten Gesprächspartner, das eigene Setup immer besser, die Zusammenarbeit immer dünner. Und wer allein rennt, verrennt sich. Nur eben jetzt richtig schnell.

Bei der österreichischen Versicherung NV haben wir es anders versucht. Statt Software für den Fachbereich zu bauen, haben wir die fachliche Verantwortung ins Team geholt: Die Product Ownerin und jemand aus dem Fachbereich gehören zum Miniteam, nicht zur Auftraggeberseite. Wir erzählen zu zweit, wie sich das anfühlt: Stefanie Lintner, Product Ownerin bei der NV, und Michael Seel von INNOQ.

Wie wird aus Fachgesprächen und Workshops der Grundstein für eine Spec? Domain-driven Design wird dabei wichtiger, nicht überflüssig: Die gemeinsame Sprache und das fachliche Modell, die im Team entstehen, werden zum Arbeitsmaterial für den Agenten. Wie kommt dieses Domänenwissen in den Agenten, ohne über Tickets, Übergaben und Interpretationen die Hälfte zu verlieren? Und wie verändert sich die Rolle der Product Ownerin, wenn der Fachbereich nicht mehr bestellt, sondern mitbaut?

Wir berichten aus dem laufenden Projekt, aus beiden Perspektiven: Wie arbeitet man agentisch als Team, statt als Einzelkämpfer mit jeweils eigenem Agenten? Wie muss sich der Entwicklungsprozess ändern, damit man mehr an Agenten delegieren kann, ohne in den Blindflug zu geraten? Und wo hakt es trotzdem?

Wir nehmen euch mit in den Projektalltag eines Miniteams: wie sich agentische Entwicklung anfühlt, wenn Fachbereich, Entwicklung und Agent an einer Sache arbeiten.

Ich habe letztes Jahr ein atemberaubendes Foto von zwei Löwenbabies im Sonnenuntergang von Namibia geschossen. Aber das Foto ist nicht der Punkt. Der Punkt war, stundenlang in der Hitze zu warten, die Tiere zu lesen, in der Natur zu versinken, das Vertrauen des Rudels aufzubauen und sich dann mit der Kamera vor all den Löwen weit aus dem Auto zu lehnen, als das Licht perfekt war. Klick, und ich hatte den perfekten Shot im Kasten. Eine Maschine hätte mir das Bild in zwei Sekunden generiert, ohne Hitze, ohne Passion. Das Bild wäre wertlos.

Genau das passiert gerade in unserem Beruf. Wir verwechseln das Artefakt mit dem Wert. Der Code ist das Foto. Das Verstehen, das Ringen, das gemeinsame Modellieren sind das, was ich weiter oben beschrieben habe. Und wir sind dabei, genau das wegzuautomatisieren.

Diese Keynote ist nicht gegen KI. Sie dreht sich um das, was uns überhaupt in diesen Beruf gebracht hat: Neugier, Geschmack, Haptik, Spaß und Leidenschaft.

Wie behalten wir das alles, wenn die Maschine uns das Tun abnimmt?