This is the story of eBay’s company-wide Velocity initiative, which doubled engineering productivity across all 5000 engineers, but still could not save the company from its own pathological organizational culture. Once a stock market darling and a pioneering hyperscaler in the 1990s and early 2000s, eBay has been in steady decline since the 2010s. A household name with a flat business, eBay has been unable to make substantive strides in its market reach or its engineering outcomes in the last 15 years. What happened? Randy was a Distinguished Architect at eBay from 2004 to 2011, and returned as Chief Architect and VP of Platform Engineering from 2020 to 2022. As Chief Architect, he led the company-wide Velocity initiative, which doubled engineering productivity across the board. By executing a pretty standard DevOps playbook, this has been an unqualified success on the engineering side. Teams have improved on all of the DORA software delivery metrics, and report better collaboration and developer satisfaction. At the same time, improvements have stagnated, and teams consistently struggle to reach Elite status or to alter the overall trajectory of the business. This talk is an insider’s attempt to make sense of this seeming contradiction between micro-successes and macro-failures, and attempts to abstract 20 years of participation and observation into a set of actionable lessons for any organization attempting to transform itself. We will deep dive into the following: * Strategy and Planning, encompassing Learned Helplessness, the Innovator’s Dilemma, and Centralized Waterfall Planning * Execution and Delivery, covering Massive Coordinated Releases, and the “Feature Factory” * Organizational Culture, epitomizing Westrum’s pathological culture with zero-sum thinking, empire building, risk aversion, and a constitutional inability to acknowledge failures You will learn * how to successfully execute a massive technical transformation across thousands of people using the Accelerate / DevOps playbook * why a technical transformation by itself is not enough * how we would have done things differently in hindsight

Emphemerality: the concept of things being transitory, fleeting, or existing only for a short time. Suddenly, one of the most important considerations for code is ephemerality–how long will this code live? If it's a quick vibe-coded solution then no one cares about good architecture. However…if what you're building is the foundation for future building, you need ways to ensure that agents (either humans or machines) build proper software. How To Teach Your Agents About Architecture represents several years thinking about how to concretely define nine different intersections of software architecture with how humans and agents build software. This class shows developers and architects how to define architecture rules embedded within specifications and how to use the same rules to generate deterministic guardrails. Even with the best models, developers should trust but verify. How To Teach Your Agents About Architecture provides techniques to both teach your agents about architecture and govern non-ephemeral code. We define architecture in code in the following nine intersections: • GenAI • Implementation • Infrastructure • Engineering • Data • Integration architecture • Team topologies • Enterprise Architecture • Business For each of these, we provide examples of how developers and architects can build rules that provide fast feedback when important things happen. For example, this framework allows developers to define rules that prevent developers (or agents) from "cheating" in a mono-repo source code repository. Similarly, when architects need to break a database apart for scalability, we show techniques to restore data consistency and referential integrity.

here is an abstract

We’ve never had better tools. Faster streams. Decoupled architectures. AI writing our code. And yet , systems still drift towards a big ball of mud. Unsatisfying and difficult to change. Better tools aren’t enough. We can’t layer AI on top of confusion and get intelligent systems. Artificial intelligence doesn’t increase organizational intelligence. The more we optimize for speed — delivery, data, tools, or LLMs — the more we strangle knowledge flow. When knowledge doesn’t flow, organizations don’t think. They react. Knowledge Flow is how people and technology co-create intelligence that moves across tools, situations, and time. We don’t have a data problem. We have a knowledge problem. This is a talk is about designing systems that generate momentum, coherence, and resilience — in the technology and in the teams. Because intelligent systems aren’t something we add. They’re something we design.

Modularity has been software design's holy grail since the 1960s ...and we've been failing at it for just as long: OOP, design patterns, architectural styles, SOA, microservices. None of them delivered on the promise, and some quietly made things worse. AI-assisted engineering just raised the stakes. Your codebase isn't only what your team reads anymore; it's the context your coding agent loads on every task. Good modularity multiplies your team's velocity and your agent's accuracy. Bad modularity multiplies the pain, for humans and robots alike. Modular design is a strategic investment of the AI era. Join this talk to learn why decades of modularity efforts have fallen short, and to take home a practical design model for evaluating, fixing, and finally taming the modularity of your own codebase. Your robot friends will thank you.

AI is rapidly changing how companies build products, make decisions, and create value for customers. For established digital businesses, the challenge is no longer whether to adopt AI, but how to evolve into an AI-native organization. In this session, Gertrud shares Scout24’s journey from a successful digital platform to an organization that increasingly embeds AI into its products, processes, and ways of working. She explores how AI is reshaping product development, engineering, and user experience, while also driving broader changes across teams, culture, and operating models. The talk highlights key lessons learned, opportunities and challenges encountered along the way, and what it takes to move beyond isolated AI initiatives toward sustainable transformation at scale.

Ask software architects, tech leads and developers what skills are valuable in developing software systems, and inevitably someone will say 'abstraction'. Ask how a system should be structured, and inevitably someone will say 'levels of abstraction'. Look at programming or modelling paradigms and — inevitably — 'abstract' will appear, as a noun, as a verb or as an adjective. Being so steeped in the terminology of abstractness and abstraction, you would be forgiven for thinking that software developers would have a clear and ready definition of what abstraction means. You would be forgiven, because you would be wrong. Although a foundation of much of computing and progress, developers have varied views on what it means for something to be abstract, often confusing 'abstraction' with 'generalisation', or being unclear about the relationship between 'abstractness' and 'level', or equating 'being abstract' with 'being vague'. In this talk we will look at what 'abstraction' means in theory and in practice. We will see how knowing this helps us to understand the relationship between abstraction and progress in software development in the past as well as its future. It also helps us to properly evaluate claims about AI and abstraction from the perspective of both developer and user.

Given that agile is in it's core: inspect and adapt, what can we see now if we inspect, and how and what can we adapt? Especially now in these AI times. Join this session to hear about 25 years of experience with agile in software, hardware, education, research, and facilitation, and how learnings from this could impact your (work) life. And a little bit about agility in the future with AI. We will look at how to improve meetings, communication, planning, estimation, team work, and our own survival skills in all of this. This will be a provocative inspiration for leaders, architects and engineers, who like to think of how to think about things.

Oh look, another session about AI! Your social media feeds are already flooded with agentic this and spec-driven that; one-shot rewrites and everyone-is-a-programmer-now. I want to share some models and metaphors that are helping me make sense of this new world: why Ward Cunningham hates printers, how riding a fixie isn’t really cycling, why Claude is just a mercenary contractor, how test-first is the new TDD. Beyond the hype, we should still care about iterative development, bounded contexts, decent tests, intention-revealing names. And AI is not going to replace junior developers any time soon, instead it is something... other. I don’t use genAI to go faster or produce more, at least not primarily. Instead it is helping me do 'adjacent' things, allowing me to focus where I want to rather than where I otherwise would have to. My goal is to give you a more nuanced take on generative AI, to help you cut through all the noise and get actual work done.

Can AI help us to modernize these 3 legacy systems faster? This was the question we asked ourselves after yet another bug that forced us to dig through the many synchronization issues and data inconsistencies that comes with trying to keep 3 services in sync. It was now the time to regroup the domain logic spread across the 3 services into a single service and codebase to avoid all these difficulties, and hopefully make these expansive changes across too many code repositories a thing of the past. Removing a system out of the equation was a good experimental field to see what AI could do in terms of legacy modernization. How can AI help us to go faster, learn faster, make better decisions....? We successfully achieved the goals of the project by creating our own harness and custom tools. This included capabilities mapping out the project as a mikado graph with a custom UI, subagents for analysing code and creating diagrams of it, generating migration plans, and providing a skill that could be used by teams to migrate their parts of the code. In this talk we will talk through the pieces of our harness, including what we learned and how we applied them to the project with concrete examples. We'll also share our learnings relevant to the important question: "do humans still need to understand the AI's code changes during a legacy migration or can we trust it without reviewing every line?"

The best developers I know from the “before times” were doing Test-Driven Development. These days almost all of them have stopped writing code by hand, and are using agentic AI instead. This is huge! They also say that the code they are coming up with now is, if anything, even better quality than what they wrote before. That is also huge - these people have really high standards! As a technical coach my perspective is very much how to help ordinary developers make effective decisions minute-by-minute. I mainly advocate for better code quality, more unit tests and to adopt a TDD mindset. A lot of the details of what I’ve been teaching needs to be re-imagined and updated for agentic AI. Even in the most traditional organization the potential upsides of these tools is impossible to ignore. We need to look clearly at what is replacing the hard-won heuristics and skills of the past. What is an engineering process for software development with AI tooling? How can we ensure the quality of the work and the longevity of the systems we are building at the same time as preserving our own health and sanity? In this talk I will go through what is changing and my best advice about an engineering process for developing software with agentic AI.

AI-assisted coding tools are changing what it means to be a developer. For decades, software engineering literacy meant mastering languages, frameworks, and the mechanics of writing code. But when tools like GitHub Copilot, Claude Code, and agentic workflows can generate entire systems in minutes, the scarce skill is no longer typing code. It is thinking clearly about systems, intent, constraints, and feedback loops. This session explores the emerging literacy developers need in an AI-assisted world. Through stories, live examples, and discussion, we’ll examine how coding is shifting from crafting lines of code to shaping environments in which code emerges. We’ll explore how to work effectively with AI without surrendering judgement, how to design systems that remain understandable when much of the code is generated, and why the most valuable developers may soon be those who are best at designing context rather than writing syntax. Expect practical examples, surprising failures, and a conversation about what developer expertise really means in the age of AI.

We spent the last year building the software factory: sandboxes, orchestration, code review, skills, feedback loops. The factory is mostly built — so what happens if we turn the lights off. I'll trace the short, dramatic history of the lights-off factory — from Ralph to strongDM to the hype cycle to the spring cool-off, when many teams learned the hard way that agents can't be trusted in a production codebase without human judgment. The culprit isn't something you can code or prompt your way around. It's that today's models are trained to make the test pass, not to improve the codebase over time — locally correct, globally corrosive. They can write code; they can't yet do architecture. We'll look at what a better benchmark would have to measure — maintainability, navigability, blast radius, outcomes over time — and what that means for the work in front of us right now. Until models can architect, judgment has to re-enter the loop above the code: humans deciding what gets built, a level up from the diff. That's not a bottleneck to automate away. It's the steering wheel — and it's where the next year of progress actually lives.

How did Sweden's third-largest tech company become AI native? What were the drivers, the challenges, the solutions, and outcomes? Why isn't it as simple as providing training and buying licences? Tomasz and Deejay take you through Odevo's journey adopting agentic coding and AI-enabled product management, sharing what worked, what didn't, what this means for the company, and of course some tasty metrics about the outcomes!

With the aid of maps, we take a wander through the history of technology development, what it means, where we are going and what should we learn from the past. This talk will introduce the concept of mapping and use this to explore cloud, devops and serverless before focusing on the impact of AI and what this means in terms of architecture, project management and software engineering.

We have always emphasized shared understanding between domain experts and engineers. But today, there is a third participant in the room: AI agents. How do we establish shared understanding with something that doesn’t see our sticky notes, doesn’t attend our workshops, and doesn’t speak our Ubiquitous Language? We invest days in EventStorming sessions, Domain Storytelling workshops, and Context Mapping exercises. We create rich, nuanced models of our domains and then reduce all of that to vague prompts for AI coding assistants that have no awareness of our carefully modelled boundaries and language. This is a waste. A serious one. In this talk, I challenge how we treat the outputs of collaborative modeling. Instead of short-lived and vague workshop artifacts, we need to turn them into structured, persistent domain knowledge that can actively guide and constrain AI-assisted development. We will explore how to transform insights from collaborative modeling workshops into executable specifications that bridge the gap between human understanding and AI-assisted implementation. These specifications become the interface where domain experts, engineers, and AI agents can finally meet.Concretely, we will look at how collaborative modeling outputs can be translated into structured, machine-readable artifacts such as domain glossaries, boundary definitions, and specification formats that can be embedded into AI development workflows as persistent context and guardrails, rather than being left behind as photos of sticky notes on a wall. Building on this, we will look at how such structured domain knowledge can feed into modern, decomposition-driven development approaches, enabling AI systems to operate within clearly defined domain boundaries instead of guessing their way through implementation. You will learn: - Why collaborative modeling outputs fail to survive contact with AI-assisted development - How to structure domain knowledge so it becomes usable beyond the workshop - How to turn Ubiquitous Language and Bounded Contexts into durable, enforceable constraints - How to close the loop between modeling sessions and AI-guided implementation

Most AI content in 2026 is either shallow slop or a single-lens productivity story: the engineering view, the PM view, the manager view, the CEO view. These views often contradict each other. The truth is that teams and companies are changing faster than ever, and everyone feels they are falling behind in some aspect. This talk pulls the industry's perspectives together into one coherent picture of what AI is actually doing to teams right now, with concrete moves from leading companies. The second part introduces a workshop format, built and proven inside an established product team, that turns this messy reality into concrete change and commitment, station by station. The result: a coherent view across roles, a set of concrete ideas worth trying, and a format to guide ongoing transformation inside any team.

Starting a new project from scratch with a clean slate is one thing; tackling legacy systems with chaotic architectures is another. Many teams inherit systems described as “Monoliths” or “Big Balls of Mud,” and this talk focuses on how to bring order to such challenges. Participants will learn how to evaluate their current systems and identify steps to introduce—or restore—structure. Using Collaborative Modeling, attendees will gain actionable insights to design a clear and future-ready architecture. The talk will equip participants with practical strategies to address common challenges, such as BBOM architecture, anemic domain models, and disorganized teams. By the end of the session, attendees will have a catalog of proven refactorings, actionable heuristics, and concrete tools to immediately evolve their own projects.

Künstliche Intelligenz verändert, wie wir Entscheidungen treffen, Produkte entwickeln und Teams organisieren. Doch bringt sie neben Möglichkeiten auch Herausforderungen mit sich: Überlastete Entwicklungsteams kämpfen mit neuen, durch KI ausgelösten Komplexitäten, unklaren Rollen und einer Vielzahl konkurrierender Anforderungen. "Business as usual" funktioniert nicht mehr – neue Strukturen und Zusammenarbeitsformen sind erforderlich. In unserer interaktiven Session zeigen wir euch, wie ihr mit Team Topologies Eure Teamsituation analysieren und gezielt verbessern könnt. Anhand eines praxisnahen Beispiels eines überforderten GenAI-Teams lernt ihr typische Anti-Pattern in der Teamstruktur zu erkennen und selbst effektive Lösungen zu entwickeln. Kim übernimmt dabei die Rolle der Analytikerin, während Olli die Perspektive des betroffenen Entwicklers einbringt. Gemeinsam führen wir euch durch eine strukturierte Herangehensweise, die hilft, Klarheit über Rollen, Prozesse und Arbeitslast zu gewinnen. Diese Session richtet sich an Entwickler*innen, Produktverantwortliche, Führungskräfte und alle, die ihre Teams und Organisationen gezielt auf die Anforderungen der KI-Ära vorbereiten wollen.

Künstliche Intelligenz verändert, wie wir Entscheidungen treffen, Produkte entwickeln und Teams organisieren. Doch bringt sie neben Möglichkeiten auch Herausforderungen mit sich: Überlastete Entwicklungsteams kämpfen mit neuen, durch KI ausgelösten Komplexitäten, unklaren Rollen und einer Vielzahl konkurrierender Anforderungen. "Business as usual" funktioniert nicht mehr – neue Strukturen und Zusammenarbeitsformen sind erforderlich. In unserer interaktiven Session zeigen wir euch, wie ihr mit Team Topologies Eure Teamsituation analysieren und gezielt verbessern könnt. Anhand eines praxisnahen Beispiels eines überforderten GenAI-Teams lernt ihr typische Anti-Pattern in der Teamstruktur zu erkennen und selbst effektive Lösungen zu entwickeln. Kim übernimmt dabei die Rolle der Analytikerin, während Olli die Perspektive des betroffenen Entwicklers einbringt. Gemeinsam führen wir euch durch eine strukturierte Herangehensweise, die hilft, Klarheit über Rollen, Prozesse und Arbeitslast zu gewinnen. Diese Session richtet sich an Entwickler*innen, Produktverantwortliche, Führungskräfte und alle, die ihre Teams und Organisationen gezielt auf die Anforderungen der KI-Ära vorbereiten wollen.

Can AI help us to modernize these 3 legacy systems faster? This was the question we asked ourselves after yet another bug that forced us to dig through the many synchronization issues and data inconsistencies that comes with trying to keep 3 services in sync. It was now the time to regroup the domain logic spread across the 3 services into a single service and codebase to avoid all these difficulties, and hopefully make these expansive changes across too many code repositories a thing of the past. Removing a system out of the equation was a good experimental field to see what AI could do in terms of legacy modernization. How can AI help us to go faster, learn faster, make better decisions....? We successfully achieved the goals of the project by creating our own harness and custom tools. This included capabilities mapping out the project as a mikado graph with a custom UI, subagents for analysing code and creating diagrams of it, generating migration plans, and providing a skill that could be used by teams to migrate their parts of the code. In this talk we will talk through the pieces of our harness, including what we learned and how we applied them to the project with concrete examples. We'll also share our learnings relevant to the important question: "do humans still need to understand the AI's code changes during a legacy migration or can we trust it without reviewing every line?"

Writing unit tests is pretty much standard practice these days. Otherwise, how would you make sure that your code does what you expect? Yet, some software is mission-critical and merely testing a few examples – or even randomized testing – is not enough. To reach higher levels of assurance, we need proof: mathematical, formal proof. This session will be based on an example from industry, where we successfully verified the core of a financial application. I will describe the core architecture of the system and the mathematical foundations behind the verification, including the classes of problems that we can (or cannot) discover with this approach.

Local-first software promises offline support, low latency, and user-owned data. Delivering that experience hinges on one hard problem: sync. This talk dives into the design of synchronization engines that power local-first systems. We’ll explore how data storage and end-user devices exchange and merge changes under unreliable networks. Techniques, such as Conflict-free Replicated Data Types (CRDTs), are the “secret sauce” to ensure that updates made on one device are automatically reconciled with changes made on others, even when they happen offline. Finally, we’ll ground these ideas in a case study on collaborative spreadsheets, analyzing how sync engines deal with high-frequency edits and complex data models. If you’re building or evaluating local-first systems, this session will give you a concrete mental model and the engineering insights to reason about sync.

There is a lot of focus on frameworks, culture, compliance, and resume-ware technologies. The game of "stop the code delivery" can still be won, if we can give developers the tools and awareness they need to slip through the quality gates and deliver working functionality to production. Let's look at how to write deliverable code...

Client-side AI is having a moment. With tools like Transformers.js and APIs like WebGPU, we can now run sophisticated ML models directly in the browser - no server required. But should we? In this talk, we'll cut through the hype and explore when client-side AI actually makes sense. We'll look at the technical foundations (quantization, tokenizers, model architectures), dive into real-world use cases, and compare the trade-offs: privacy vs. performance, latency vs. model size, accessibility vs. capability. From image processing to language models, we'll examine which tasks thrive client-side and which still belong on the server. Sometimes the answer is clear, sometimes it's nuanced, and sometimes a hybrid approach is the way forward - it depends!

Event-Driven Architecture has become a popular choice for building microservices. At least in theory. Talks and articles praise its potential for scalability, reliability, and decoupling. In practice, however, many teams struggle with a crucial challenge: how do we implement complex business workflows that span multiple domains?

Often, they quickly fall back on “traditional” coordination mechanisms such as workflow engines, durable execution tools, and the Saga pattern. But is that really the way? This talk asks a fundamental design question: are orchestration-centric solutions a requirement for complex cross-domain workflows, or a symptom of modeling problems carried over from monolithic systems?

In this session, we explore a purely event-driven style of workflow design. Rather than transferring monolithic workflows into distributed systems, we look at how event-driven design invites a different way of thinking: not to better manage complexity, but to reduce it.

Bei der ersten Mondlandung hat die IT eine wesentliche Rolle gespielt und es wurden wichtige Fundamente des Software Engineering geschaffen. Der Begriff selbst wurde von Margaret Hamilton während der Entwicklung des Apollo Guidance Computer (AGC), des Steuermoduls der Mondlandefähre, geprägt.

Für eines der ersten eingebetteten Systeme wurden Prioritätsscheduling, Multitasking und ein Echtzeitbetriebssystem entwickelt. Eine der ersten virtuellen Maschinen stellte mathematische Funktionen bereit und abstrahierte von der Hardware. Ein wesentlicher Erfolgsfaktor war die Robustheit der Software, die sich durch eine gute Fehlerbehandlung auszeichnete. Diese Eigenschaft kam Minuten vor der Landung zum Tragen und bewahrte die Mission vor dem Abbruch. Werfen wir einen Blick zurück in die Zukunft!

As developers, we usually implement given UI designs. But wouldn’t it be great to gain a better understanding of the science behind a good design? In this talk, I will cover some of the cognitive psychology principles and UX laws that guide UI/UX experts in their work.

By applying these principles and laws the you can improve both the user interface and user experience, resulting in a better product.

Coding-Agents sind in der Softwareentwicklung inzwischen nicht mehr wegzudenken. Data Engineering bringt mit den Daten jedoch eine zusätzliche Dimension ins Spiel. Lassen sich Agenten neben dem reinen Entwicklungsprozess auch für typische Engineering-Aufgaben wie das Fixen von Pipelines nutzen? Da Feedback-Schleifen hier deutlich langsamer sind als in der klassischen Softwareentwicklung, stellt sich die Frage: Was braucht es für die Anbindung an Datenplattformen? Sind MCP-Server hier wirklich das Allheilmittel? Wir diskutieren die Konsequenzen für Governance und Architektur – und warum Agentic Data Engineering die notwendige Grundlage für ein wirklich funktionierendes „Talk-to-your-Data“ ist

For many developers, learning about web security can seem scary or boring. However, it’s not one of those sessions: I will draw my sketch notes on secure web development live on stage, together with you. ❤️

In this visual talk, I will use live sketch-noting to imagine your website as a masterpiece in an art gallery… or at least a handy security sketchbook. I’ll draw villains like XSS and Broken Access Control, and then we’ll sketch the defenses to stop them together! You’ll leave with a sketch note handout drawn live on stage and practical steps for making your website both beautiful and bulletproof. Let’s do this, as the last line of defense!

When an alert fires, the real work begins: gathering logs, correlating metrics, digging through source code, checking past incidents, and documenting everything — often under pressure.

What if AI could do that for you?

In this talk, we explore how AI agents can transform incident response. From automatically creating enriched tickets, aggregating context across metrics, logs, code, and historical incidents, to generating postmortems and even executing safe remediation steps — AI becomes an active part of your operational workflow. We’ll walk through a real-world architecture, lessons learned, guardrails for autonomous actions, and where AI meaningfully improves MTTR — and where it doesn’t.

Agentic AI is everywhere, but most implementations do not survive beyond prototypes. Building agents that handle real-world complexity requires strong architecture, not just orchestration. In this session, you will learn how to design and operate production-ready single- and multi-agent systems. We will apply monolith-to-microservices principles and domain-driven design to avoid common pitfalls such as context sprawl, tight coupling, and brittle workflows. You will explore practical architectural patterns for building secure, scalable, and resilient agentic workloads and learn how to move from experimental demos to autonomous systems that run reliably in production.

Autonomous coding agents resemble powerful malware: they can write, execute, and modify code, access secrets, and call services—often opaquely.

Building on pioneering work from a year ago on safely applying AI to legacy codebases, this session extends that proven approach to the even riskier setting of autonomous agents. The agent itself is treated as untrusted and clamped down with tightly hardened containers and strict network firewalls that isolate execution, constrain file and tool access, and restrict communication to a minimal allowlist, drastically limiting blast radius and data-exfiltration paths.

The architecture mitigates core risks such as prompt injection, model misuse, and supply-chain abuse, while still enabling meaningful automation for real-world systems. Finally, the session outlines upcoming layers—fine-grained policy engines, runtime behavior monitoring, and end-to-end supply-chain verification—to build a robust, defense-in-depth stack for secure coding agents.

DDD has been telling us for 20 years that a shared language inside a bounded context is the strongest predictor of a software projects long-term success. The same is true for LLMs and most teams adopting agentic development are paying the price for ignoring it.

The same methods you’d use to align a team with a domain expert, explicit ubiquitous language, bounded contexts and modeled handoffs, are exactly what move an LLM from improvisation to reliable collaborator. The AI coding harness becomes a modelling artifact.

Let me show you how to move beyond opinionated agentic workflows and build & evolve your own domain driven harness in collaboration with your team.

You’ll leave with concrete patterns on how to design, evaluate and evolve your own workflow, regardless if your collaborators are human, machine, or both.

The developer role is undergoing its most profound transformation in decades. 51% of developers now use AI coding agents daily. But many of your best engineers are frozen, resistant, or quietly grieving a profession they built their identity around.

This isn’t a motivation problem. It’s neuroscience.

When professional identity is threatened, the brain activates threat responses that look like resistance but function like loss. Engineers who thrive aren’t more resilient, they’re navigating a specific psychological process. Those who freeze aren’t weak, they’re stuck in a transition.

This talk explains:

- What actually happens neuropsychologically when a core skill becomes automated

- Why the “creative director of code” framing lands for some developers and triggers others

- What interventions work, for individuals and for teams

- How CTOs and tech leads can tell the difference between resistance and grief, and respond to both

We all know the giants: the US-based hyperscalers that dominate the SaaS, PaaS, and IaaS markets. Developers love their DX and endless feature lists, but the mindset has shifted. It’s no longer just about checking a GDPR box; it’s about digital sovereignty. As dependencies grow and geopolitical landscapes shift, relying solely on non-European infrastructure has become a strategic risk—especially for those working with the public sector or critical infrastructure.

But is it actually possible to build a modern, scalable SaaS solution on a purely European foundation? One where not just the data center, but the parent company and the entire jurisdiction remain within the EU?

At anny, we decided to find out. We launched an ambitious experiment: building a parallel environment from the ground up using exclusively European providers. In this session, we’ll share our journey—the technical hurdles, the unexpected wins, and the reality of achieving true strategic autonomy.

The current approach to building full-stack applications is sub-optimal, to say the least. The widespread separation between frontend and backend leads to slower development cycles, unnecessary complexity, duplicated logic, and rigid architectures that fight developers more than they empower them.

But it doesn’t have to be that way.

With TanStack Start, we can build modern full-stack applications with a radically different mindset, powered by shared logic, type-safe APIs, and a outstanding developer experience.

Let’s explore what TanStack Start has to offer, and how to use it for building Full-Stack applications.

AI in the engine room sounds like the kind of sentence that belongs on a conference slide. For us at encentive, it is quite literal: we use software to optimize industrial energy systems. But the hard question was not how to optimize the machine but how to prove what has changed when doing so.

This talk walks through the messy path from impact claim to number that customers will trust. First, customer demand a benchmark – in other words, what are potential savings compared to. Then the baseline starts moving, because key parameters – in our case weather, production, energy prices and the optimization itself – keep changing the story. Finally, we turn KPI thinking into a performance page that customers can use.

It is a practical inside story about baselines, CO2, euros, counterfactuals and the awkward moment when your impact is real. Bringing AI into the engine room is only half the job. The other half is about building numbers that people trust.

Freitagnachmittag, Live-Deployment – klingt nach Stress? Nicht, wenn AI ein fester Bestandteil eures gesamten Entwicklungsprozesses ist.

Wir zeigen, wie wir den SDLC konsequent mit AI durchziehen: POs die mit AI-Agenten Stories schreiben und verfeinern, Entwickler die mit Coding-Agenten implementieren, reviewen und testen – und ein Deployment-Prozess, der so viel Vertrauen erzeugt, dass Freitag nachmittags die entspannteste Zeit der Woche wird.

Keine Theorie, keine Demos aus dem Lehrbuch. Ich teile echte Erfahrungen, konkrete Tooling-Entscheidungen und die ehrlichen Learnings daraus – inklusive der Momente, wo AI uns auch mal nicht in den Feierabend geschickt hat.

Everyone’s building their software systems with coding agents now - so do we at my company, neuland. Like many others, we use Claude Code, the one that was recently announced will run in one of the world’s most infamous data centres that made headlines for being ultra-polluting and racist.

In this talk you will learn about AI’s collateral damage: What are the things that we don’t see that come embedded into AI and thus into the software we build? And I will share the journey my company has embarked on to find better ways to use AI responsibly - the tools, the principles, the processes. How did we go about it and what did we learn on the way? And what parts of what we did can you copy to make your own use of coding agents more sustainable?

What if a speaker didn't just talk about AI wearables — but wore them live on stage? This talk ditches the slide deck to let the technology speak for itself. Using open-source Mentra Live AI smart glasses, the entire presentation is driven by voice commands and real-time camera AI — no screen-tapping required.

The audience watches AI work in real time: object recognition, instant language translation with a volunteer, a first-person live stream, and an AI-augmented Q&A where the glasses whisper supporting data to the presenter.

Behind the spectacle is a genuine UX story. Built during a research and prototyping sprint with ISEP Porto students, this talk shares lessons on designing for voice-first and screen-free interaction — a paradigm shift as the smart glasses market is projected to grow from 6 million units in 2025 to 45 million by 2027. You will leave knowing what ambient AI feels like because you just experienced it.

What if a speaker didn't just talk about AI wearables — but wore them live on stage? This talk ditches the slide deck to let the technology speak for itself. Using open-source Mentra Live AI smart glasses, the entire presentation is driven by voice commands and real-time camera AI — no screen-tapping required.

The audience watches AI work in real time: object recognition, instant language translation with a volunteer, a first-person live stream, and an AI-augmented Q&A where the glasses whisper supporting data to the presenter.

Behind the spectacle is a genuine UX story. Built during a research and prototyping sprint with ISEP Porto students, this talk shares lessons on designing for voice-first and screen-free interaction — a paradigm shift as the smart glasses market is projected to grow from 6 million units in 2025 to 45 million by 2027. You will leave knowing what ambient AI feels like because you just experienced it.

As we move toward a world where coding agents do more of the work, what does that mean for software craft? Do we still need it? Or is it already nostalgia? To answer that, we have to understand what actually makes software craft work. As a long-time software crafter, I’ve learned the hard way that how fast and far you can go is determined by what’s under the hood: the design of the code and its changeability, which come down to its simplicity and the limits of our cognitive capacity. Agents have that same limit. So I decided to find out whether craft could keep them inside it, to evolve systems in a sustainable way. I’ll show you how I designed an agent I set loose to run unattended, and what happened next. And what it takes to apply software craft with agents on gnarly, untested legacy code.

Generative AI has made its way into the enterprise. Agents operate autonomously within processes, but this exacerbates risks such as data leaks, skyrocketing costs, and a lack of traceability.

Direct connections to backends and isolated solutions from business units create an unmanageable web that is virtually impossible to control or audit.

In this talk, we will demonstrate how AI gateways and API gateways can be combined to create a central governance layer for secure and cost-effective agent control, enabling innovation without losing control, and will include a live demo that we can test together interactively.

In the strictly regulated field of nuclear decommissioning, a misassigned regulation within a comprehensive risk and safety document leads to rejection by technical inspection authorities such as the TÜV - resulting in weeks of costly work interruptions and corrections. Most production knowledge graphs hide this failure mode: they treat time and location as extracted metadata, when in reality those are claims. Get context attribution right and you have the grounding layer for the whole compliance lifecycle - drafting domain experts trust, validation auditors can audit, corrections that compound. Three proven engineering patterns from real projects in nuclear and others: context attribution as a first-class claim, time as Allen-interval relations instead of just valid_from/valid_to and a hybrid ontology featuring an OTHERS bucket as a placeholder for unknown types in the corpus, as well as for types forming around new competence questions from user queries.

Container images can be described as an operating system in a bottle. They run under the host Linux kernel, but often contain numerous libraries, utilities, and programs alongside the software you put in them.

As an example, the “stable” Debian base image (as of 2025-09-29) contains 111 packages, takes up slightly over 50 MiB of space and lists 21 vulnerabilities.

The “latest” Alpine base image, on the other hand, only has 20 packages, takes up less than 4 MiB of space and lists 2 vulnerabilities.

In this talk, I’ll discuss what makes up a container image, a bit about how they work, and the benefits and drawbacks of these two images (and others, such as Red Hat’s UBI images). I’ll also talk about scratch images—what they are, when you might use them, and some caveats.

Your core business logic _is_ your business - when you write it you want to make sure it’s absolutely correct, robust and reusable across platforms, whilst still allowing it to evolve with you.

In this talk, we first identify your most valuable business logic using Domain Driven Design practices. Then, we use the Ports and Adaptors pattern to encapsulate it in a pure, testable core. Rust is surprisingly good at writing high level software - its type system makes modeling complex business domains easy and invalid states unrepresentable.

We’ll use Domain Events and Managed Effects to insulate this core from the outside world, making tests easy to write, fast and deterministic. Then we’ll show how you can embed this core anywhere - mobile apps, backend services, or even microcontrollers.

We think you should be able to have the highest level of confidence in the correctness of your most important code. This is how you do it.

The ticket was clear, the acceptance criteria were solid, and you shipped on time. Three months later, nobody uses that feature. So whose problem is that?

Most engineers would say it is product’s. Technically, they are not wrong. But this framing keeps talented engineers from making a greater impact, simply because their role stops before the code is ever used.

The Software Product Engineer mindset is not about becoming a product manager. It is about asking why a feature exists before how to build it, and pushing back on requirements that solve the wrong problem. It means owning not just the code, but whether your work actually solves a real-world problem.

In this talk, we will examine this shift in practice, not as an abstract principle, but in the everyday decisions engineers make. We will explore how to challenge what you are handed, where the line is between healthy ownership and overreach, and why this mindset is the true foundation of impactful engineering.

Kinder lernen ausschließlich durch Spielen und durch den Spaß dabei. Irgendwann zwischen Schule und Karriere haben wir entschieden: Lernen ist Arbeit und Lachen ist Pause.

Teams und Organisationen haben dieses Modell unbewusst geerbt. Das Ergebnis: Trainings, die verdampfen. Retros, die niemand ernst nimmt. Feedback, das nicht ankommt.

Dieser Talk zeigt, warum Humor nicht bloß als Auflockerungsübung genutzt werden sollte. Humor macht Lernen unglaublich wirksam. Denn wenn wir über die Absurdität unserer eigenen Gedanken und SChlussfolgerungen lachen, öffnen wir uns für neue Wege.

Mit Erkenntnissen aus Verhaltensforschung, Comedy-Bühne und einem Jahrzehnt Organisationsentwicklung. Und ja… es kann sein, dass du im Talk lachst… Aber du wirst auch etwas mitnehmen.

I put a GPU in a styrofoam box and sent it 37 kilometers up - into the stratosphere, above 99% of the atmosphere, into an environment with no SSH, no reboot button, and no second attempt.

This is the story of that flight: from the first naïve idea, through building self-healing on-board software and testing it in the freezer, to the launch day when everything I’d planned for met everything I hadn’t.

Expect original footage of the earth from above, real telemetry, and the moments when you have no idea if you’ll ever see your GPU again.

2026 brought a wave of supply chain attacks that exposed how deeply modern software relies on trust, automation, and third-party code. This session looks back at the year’s most important incidents, the patterns they revealed, and the defensive lessons teams can take forward.

We’ll look at TeamPCP, Shai-Hulud, GitHub’s reported VS Code extension compromise, and other real-world incidents to understand how attackers compromised dependencies, maintainers, and CI/CD pipelines, then turn those lessons into practical strategies for prevention, detection, and response.

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 der tiefe Hyperfokus 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 Kollegen umgehen können, um deren Potenziale voll auszuschöpfen. Abschließend teilen wir konkrete Strategien und Tipps für Softwareentwickler, 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.

Many good ideas never see the light of day not because they are not good enough, but because the people carrying them do not accumulate enough power to get them implemented.

This talk addresses one central question:

How can we drive structural change in software organizations even if we lack formal authority or informal charisma?

To answer this question, the talk explores how power works in sociotechnical systems through a simple mental model: the Power Loop. The focus lies on the most potent carriers of power: actants — non-human agents such as artifacts, rules, workflows, and norms. Inspired by design patterns, the talk introduces Power Patterns for reshaping the power landscape around us.

This talk is not about influencing people.

It is about influencing the systems that influence people.

Eighteen months ago WAPP was a normal 19-person agency: billable hours, fixed-price quotes, legacy and new projects. Then we went all-in on agentic engineering — and almost made ourselves obsolete.

The shipping speed was real. So was the disruption. Our review queue ate a sprint. We ate a fixed-price quote. Every working agreement we had — how we estimate, what our processes look like, how we review — broke and had to be rebuilt around agents instead of keystrokes. And we had to explain to clients why “faster” isn’t automatically “cheaper.”

This is the honest postmortem from the CEO’s chair — what agentic engineering did to our processes, our pricing and our team’s identity, not just our velocity. No vendor pitch, no 10x-developer slides. Real numbers from a small team that broke a few things, fixed most of them, and figured out — just in time — how it actually wanted to work.