Two days, built for engineers.
Sessions, keynotes, and breaks across every stage. Released day by day as the lineup locks in.
31 sessions locked in.
Agents are easy, enterprises are where they break
Konrad Bujak
You already built the agent, probably wrapped it in a harness, added evals, connected observability, and it still falls the moment it uses company data. Building agents was never hard since tools calling has released in 2023 and then MCP standardized it. Now anyone can build an agent in an afternoon. The hard part is the thing that makes software like Palantir worth millions of dollar, and it isn’t LLMs. It’s everything around it, orchestration, RAG, knowledge graphs, master data management, semantic layer, ontologies and in short what company’s data means. Most failures happen in the boring layers like isolation, data quality, context across systems, and the data model itself. Let me tell you why skipping them turns a “Palantir for X” into “Accenture for X.”
Agents as a Workload: Platform Engineering for Autonomous Systems
Aiswarya Venkitesh
Agentic AI arrives on platform teams the same way Kubernetes once did: as a workload someone else built, running on infrastructure you are responsible for, with none of the operational primitives your existing services have.
Beyond the Codebase: Giving Coding Agents the Business Context They're Missing
Raj Navakoti
Coding agents can read your entire codebase — and still make confidently wrong decisions. The code tells them how the system works, but not why: the business rules, the domain language, the "we always check X first," the service that was renamed two years ago that three teams still call by its old name. That knowledge lives outside the code — in people's heads, stale wikis, and closed tickets — and your agent can't see it. This talk is about engineering that missing non-code context into something an agent can actually use: structured, bounded, lightly-typed knowledge (ontologies without the RDF/OWL pain), kept current and honest instead of dumped into a vector store. I'll show why one giant knowledge corpus rots — and how bounded contexts fix it — how to keep the knowledge self-evolving, and where it still breaks. You'll leave with a repeatable method and an open-source toolkit to try on your own domain next week.
Building the next generation of AI developer tools
Krzysztof Cieślak
AI has already changed software development. Tools like GitHub Copilot have become ubiquitous part of the workflow of millions of developers. Like other well-known editor features, AI-in-editor increases productivity, reduces required context switching, and lets developers stay in the flow while focusing on important parts of their job. However, this was just a first step - with the rapid developments of large language models (LLMs), which have become more powerful and knowledgeable with every release and have excellent reasoning capabilities, we can do more. Nowadays, we see AI agents such as Claude Code able to solve complex, repository-wide tasks or even generate whole applications. In the talk, I will discuss how AI developer tools has changed over the years, describe emerging usage patterns of AI agents and how they change whole software development process, and peek into the future of developer tools. All that while trying to answer the most important question - how to design applications using AI with humans in mind.
Designing Reliable Distributed Systems: Failures, Retries & Idempotency
Violetta Pidvolotska
Modern backend systems operate in unreliable environments: networks drop packets, services time out, messages duplicate, and partial failures become the norm. Reliability isn’t a feature - it must be intentionally designed. In this session, Violetta Pidvolotska breaks down the essential building blocks of resilient distributed systems: timeouts, retries, exponential backoff, idempotency, consistency guarantees, and failure-aware architecture design. She shows how to reason about real-world failure modes, how to identify reliability risks before they appear in production, and how to design systems that degrade gracefully instead of catastrophically. The talk focuses on clear mental models and practical design patterns rather than tools or vendor-specific solutions. Attendees will leave with a solid foundation for designing more robust backend systems - and a deeper understanding of how architecture decisions impact reliability at scale.
Design Systems That Explain Themselves
Szymon Chudy
You don't know a design system until you have to change it. The components are the easy part. What gets you is everything they assume you already know: the API that looks consistent until you extend it, the token whose name only makes sense if someone explains its history. Hawkins, Netflix's design system, runs across thousands of applications and is used by 2k+ engineers. A major new version ships this year. At that scale, preparing a release is mostly archaeology. Before you change anything, you have to uncover what the system does, why it does it, and which assumptions have accumulated over a decade. AI raises the price of that gap. An agent reading your system can't walk over and ask a teammate. Whatever the code and docs leave unsaid, it has to guess. And more documentation alone won't save you. Consistent APIs, token names that carry their meaning, accessibility built into the primitives - that's what lets a system explain itself. I'll use the Hawkins redesign throughout: evolving a ten-year-old system without breaking the applications standing on it. You'll leave knowing how to find where your own system depends on knowledge nobody wrote down, and how to turn that knowledge into constraints, conventions, components, tokens, and documentation that both humans and agents can understand.
Forensic DDD: Reverse-Engineering the Domain Your Legacy System Never Documented
Raj Navakoti
The DDD textbook promises a clean path: gather the experts, run Event Storming, discover your bounded contexts. Beautiful — and almost never how it goes in a large enterprise. Try it when you've inherited a 30-year-old delivery domain: built by vendors who left years ago, powering millions of daily transactions, its logic scattered across monoliths, legacy databases, and black boxes nobody can see inside. Nobody wrote it down. The people who built it are gone. You run Event Storming, people tell you how they think it works — and the production logs show it doing something else entirely. This talk is about forensic DDD: treating a legacy system like an archaeological dig, using production artifacts — logs, schemas, APIs, incidents, error codes — to reverse-engineer the domain model nobody ever documented. I'll share practical detective techniques for surfacing bounded contexts and hidden business rules from that evidence, how to reconcile the domain people remember with the one actually running (the gap is where the real insight lives), and how to extract safely without a big-bang rewrite. Legacy systems aren't just tech debt — they're dense archives of domain knowledge, if you know how to read them.
GitHub Actions moves to CosmosDB: data migration at internet scale
Bassem Dghaidi
A walthrough of how my team and I seamlessly migrated 450 million writes and billions of reads per day from MySQL to CosmosDB. Data that is on the critical path to queueing every single workflow run and job handled by GitHub Actions. We'll discuss the architecture, the tech debt, the storage topology, the consistency challenges, the high availability constraints and the lessons learned from this multi-months journey.
I packaged my application in a container image, and now what?
Aurélie Vache
Have you managed to package/build your application as a container image, with Docker or Podman, and push it into an image/artifact registry? Congratulations... but the work is not finished 🙂. Now it’s time to implement the best practices of Software Supply Chain Security! Why and how to sign an image? Why and how to generate the inventory of my image? Does my image have vulnerabilities? Are they exploitable? What is the purpose of certificates? How to automate all this? In this talk, step by step, with a mix of slides and live demos, we will see all that, and much more. You will know how to implement these best practices, locally and even in your CI/CD pipelines. And bonus track, after this talk terms like 'cosign', 'sbom', 'vex', 'in-toto'... will no longer have any secrets for you!
Knowledge is the infrastructure. Everything else is just tooling.
Daniel Ostrovsky
Everyone's talking about being AI native. Management wants it. Developers are doing it. You've got Cursor, Claude, Copilot - the full stack. And yet somehow, nothing actually got faster at the team level. Here's the thing nobody warns you about: the problem isn't the AI. The problem is what the AI is working with. Your architecture is in Miro. Your PRD is in Confluence from 2022. Your README hasn't been touched in 14 months. 15 companies over 25 years. The one constant is that everyone has a knowledge problem. Everyone knows it. Nobody fixes it before buying the AI tools. In this talk we'll go through what actually needs to happen first - how knowledge flows (or doesn't) across a product lifecycle, why RAG alone doesn't solve it, and why GraphRAG is the architecture that finally makes AI useful at the organizational level, not just the individual one. We'll also look at what this looks like in production — real system, real stack, real lessons.
Magical Mystery Tour: A Roundup of Observability Datastores
Josh Lee
From plain-old Postgres to the Grafana stack (Loki, Grafana, Tempo, and Mimir), OpenSearch, Cassandra, and ClickHouse, the landscape of telemetry storage options is as vast as it is overwhelming. With so many choices, how do we decide which datastore is right for the job? In this talk, Joshua will guide attendees through the foundational principles of telemetry—covering metrics, traces, logs, profiles, and wide events—and break down the strengths and limitations of different database technologies for each use case. We’ll examine how traditional relational databases like Postgres can still hold their own, where OpenSearch and Prometheus fit into the picture, and why specialized stacks like LGTM (Loki, Grafana, Tempo, Mimir) are so popular in modern observability pipelines. And, of course, we’ll highlight the growing role of ClickHouse as a versatile and high-performance option for logs, traces, and more and VictoriaMetrics as a drop-in replacement for Prometheus. By the end of this session, attendees will have a clearer understanding of the trade-offs between these datastores and how to make informed decisions based on the unique requirements of their systems. Whether you’re building an observability stack from scratch or looking to optimize an existing setup, this tour of the observability datastore landscape will leave you better equipped to navigate the options.
(MCP Security) - How Your Friendly MCP Tool Might Betray You
Daniel Ostrovsky
We all love the convenience and power of AI-enhanced tools using MCP. But what if these handy servers had a hidden dark side? Let's dive into real-world examples of how MCP servers can silently leak your data, execute malicious commands, or even grant attackers access to your systems. You’ll learn about sleeper attacks, tool poisoning, shadowing, and remote code execution—complete with chilling real-life cases and practical advice on defending yourself. This is an eye-opening session that exposes why blind trust in MCP is a dangerous game.
MFA? Game over! Watch your protection collapse – live
Christoph Menzel
In a digital world where passwords and multi-factor authentication are considered impenetrable defenses, reality looks quite different. Every month, millions of attacks bypass these very security mechanisms. Yet, many still believe that MFA guarantees complete security. In this talk, I will demonstrate live how effortlessly passwords can be stolen and MFA mechanisms bypassed. And the best part? It’s free, can be set up and executed in just a few minutes, and becomes even easier with the use of AI. I will show that the biggest weakness is often not the technology itself, but the trust we place in it. However, there are solutions. When technological advancements and human vigilance work together effectively, the attack surface for hackers shrinks significantly.
No Framework, No Server: Making AI Agents Collaborate in One Terminal
Lech Kalinowski
AI coding agents are powerful, but they usually work in isolation. One agent analyzes the code, another writes tests, and a third reviews the result—while the developer manually copies context between them. I built Agents Commander to explore a simpler alternative. Inspired by the classic Norton Commander interface, it places multiple agentic CLIs—such as Claude, Codex, and Gemini—side by side in a single terminal. More importantly, it allows those agents to communicate directly. At the center of the project is the Commander Protocol: a minimal, text-based communication format implemented through output observation and input injection. An agent can analyze a problem, delegate a task to another agent, receive the result, and continue working without a central orchestration server, complex API integration, or heavyweight multi-agent framework. Through live demonstrations, I will show agents delegating engineering work, exchanging findings, challenging one another, and refining their conclusions. I will also examine what happens when communication becomes part of the system being tested: messages are misunderstood, context is lost, agents disagree, and unexpected collaboration patterns emerge. Attendees will leave with a practical understanding of multi-agent communication, lightweight orchestration, and how visible agent-to-agent workflows can make AI-assisted engineering easier to inspect, debug, and control.
Pipeline Patterns and Antipatterns - Things your Pipeline Should (Not) Do
Daniel Raniz Raneland
Automated pipelines have become an integral part of our daily workflow. As the pipelines become increasingly important, the demands placed on them rise proportionally. As with many things, a great pipeline operates seamlessly in the background, while a poorly designed one becomes a constant irritation. Are you publishing your artefacts every time the pipeline runs, running all steps in a sequence, or installing all the tools every time a new build starts? In this talk, I will address these antipatterns and more I have encountered during my work as a consultant, explaining why I consider them such and what you should do instead. After listening to this talk, you will better understand what makes a pipeline great and concrete things you can do to improve it and shorten the feedback loop.
Private AI with Docker and UpCloud
Paweł Piwosz
In this workshop we will build something useful with AI. But! There is a catch! No ChatGPT, no Anthropic, no AWS Bedrock, no SaaS platform will e used. We will run AI powered application using local machine and GPU offered by cloud providers to run AI natively on Docker, without downloading Ollama or any other tools. No, just Docker, LLM model, and you. Join me and learn how to utilize AI in Docker and save a lot of moey on tokens!
Same Bug Twice: What Happens When AI Writes Your Code And Your Tests
Mourjo Sen
AI can generate code faster than humans can write tests. More than speed though, when AI writes both the source and the test, it introduces a dangerous blind spot. Bugs that occur in the source code could also affect the test suite. The risk of bias and hallucinations in AI-generated source and tests mean that there is no longer a last line of defense that prevents the end user from a sub-par experience Hand-written example-based tests cannot keep up with AI generated code. Property-based testing (PBT) offers a different solution that relies on deterministic verification of a problem space. Instead of enumerating individual test cases, PBT explores the invariants in a system. It tests the code by systematically trying to find inputs that could break the invariant. When it finds a violation, it shrinks the failing input to the smallest possible case, surfacing bug reports that AI-generated code could likely have missed. The key idea here is that the exploration is deterministic, backed by mathematical probing of the problem space. We will walk through how PBT fights the logical holes of probabilistic source code and how it fits directly with modern trends in software engineering like spec-driven development.
Securing AI Agents on Kubernetes: Identity, Sandboxes, and Policy Enforcement
Roland Huß
AI agents call external APIs, access databases, and execute code on behalf of users. With the Model Context Protocol (MCP) becoming the standard for how agents discover and invoke tools, every MCP tool call is a security boundary crossing. The agent holds the user's intent, the MCP server holds the capability. The question is: who decides what the agent is allowed to ask for? This talk covers three operational patterns for securing agentic MCP interactions on Kubernetes. Workload identity with SPIFFE gives each agent a cryptographic identity without shared secrets, so MCP servers know exactly which agent is calling. Token exchange for delegated access lets agents act on behalf of users without holding their credentials: the agent presents its own identity, the platform issues a scoped token that the MCP server can verify and constrain. Kernel-enforced sandboxing with NVIDIA's OpenShell wraps the agent in per-binary network policies and L7 HTTP/MCP traffic inspection, so even a compromised agent cannot reach MCP servers it was not granted access to. Walk away knowing how to secure the MCP tool chain from agent identity to server-side verification, and why most agent deployments get this wrong.
Securing AI Agents with Fine Grained Authorization
Sohan Maheshwar
This talk could prevent the next data breach. Building enterprise-ready AI poses challenges around data security, scalability, and integration, especially in compliance-regulated industries. We're already seeing security breaches with AI Agents in the news. This is a complex problem - Imagine having N users, M Agents and O actions. How do you design permissions around that? This session will cover how modern permissions systems can ensure AI Agents have access only to authorized data. The talk will look at why the Google Zanzibar model of authorization which uses Relationship-Based Access Control (ReBAC) is well suited for fine-grained authorization at scale. The talk covers the nuts and bolts of how a Google Zanzibar system works under the hood, and how to apply it to AI Agents with techniques such as pre-filteration and post-filteration. The talk will also include a live code demo implementing authorization for AI Agents + RAG using Open Source tools such as Weaviate, Langchain, OpenAI, and SpiceDB.
Sourcecode translation as a step in Legacy Modernization
Leszek Włodarski
Legacy Systems are not a myth, they are all around us, just not visible to modern developer. How to make a transformation of those big, usually critical and crucial systems is a riddle that almost nobody can solve, except mBank. The talk would be an inspiration of how automated sourcecode translation might be the solution for one of the obstacles at the legacy system modernization path. What steps have we taken to finally switch 3m LoC into modern platform with success: • Translation models o Low level .NET translation o Logical kind of DSL approach … the runtime o What about a compilers … • Sourcecode translation built from 3 steps o Preprocessing o Translation to .NET o Postprocessing • Start small – unit tests • Grow bigger – functional tests • Pilot and run .NET for new stuff • Comparison tests • Run everything And the pros&cons of such an approach in context of: • quality & test automation • people transformation • effort needed to maintain such a platform • effort and capabilities to make translation work • performance tunning • tools and libraries available The story based on CORE Banking system transformation, so heavy, critical system – the heart of the Bank, nothing simple and small. mBank was awarded by Forrester https://www.forrester.com/blogs/forresters-2025-technology-strategy-impact-award-winner-and-runners-up-for-emea/ and by CIO.NET Poland organization https://www.linkedin.com/posts/brush_digital-excellence-awards-2025-za-przebudow%C4%99-activity-7397562530610544640-B31l/?originalSubdomain=en for this Replatforming/Transformation project. The projects itself it was 9 years of work and we just did it
Spec-Driven Development: Making AI Coding Assistants Build What You Actually Want
Roland Huß
AI coding assistants generate code fast. The problem is that fast and correct are different things. Without a clear specification, even the best AI tools produce code that looks right to you, passes tests, and misses the point entirely. Spec-driven development (SDD) flips the workflow: build a specification first, then let the AI implement against it. The spec starts as a structured brainstorming interview: the AI asks questions, you provide direction, and together you converge on a precise description of what needs to be built. That specification becomes the contract between your intent and the machine's output. When the AI drifts, the spec catches it. When requirements change, you update the spec, not the prompt. This talk introduces the SDD methodology and demonstrates it live using Spec Kit, an open-source toolkit that turns brainstorming conversations into structured specifications, implementation plans, and quality gates. You will see the full cycle: brainstorm, specify, plan, implement, and review, all driven by AI but anchored to a shared specification. Beyond solo development, the talk covers collaborative SDD: how teams split specification ownership from implementation, how code review integrates with spec compliance checks, and how to avoid the "it works but that's not what I asked for" conversation that plagues AI-assisted projects. Walk away with a practical workflow you can apply the same day, whether you use Claude Code, Cursor, Copilot, or any other AI coding assistant.
Terraform, day 1001
Piotr Trębacz
Have you ever seen a Terraform/OpenTofu tutorial from a perspective of full cloud migration running longer than 5 minutes? Most of them leave you after setting a VPC, VMs and some supplementary resources in the MVP state. Then You are told to implement that technology in your complex production environment and ... there are enough 2nd day mistakes to conclude that IaaC sucks? Or maybe your company did click-ops till it becomes unmanageable, then fail to implement IaaC as an afterthought? Well, let me help you understand how to write code for scalable infrastructure that itself also scales. Without costly TACOS platforms that vendor lock you, just your favorite tools. Let's fast track from typical Terraform Tutorial Repo to Enterprise Level Terraform with good practices gathered by someone who designed and fixed IaaC Architectures for companies ranging scale ups to big corporations!
The Missing Paper Trail for Agentic Engineering
Rizèl Scarlett
For decades, software engineering has relied on a foundational necessity: a reliable paper trail. Commits, pull requests, CI logs, and reviews help teams understand what changed, why it changed, and whether it is safe to ship. We deliberately used this collaborative friction to maintain code quality. But today, a new class of autonomous collaborators has disrupted the traditional engineering workflow. Coding agents can turn a single prompt into a full feature. The speed is exciting, but it creates a new problem: we can now produce code faster than we can understand it. For an industry obsessed with artifacts, we often throw away the one record that explains agent-authored work: the session itself. Join Rizèl to learn how agent sessions can become procedural memory, helping humans and future agents search prior work, reconstruct decisions, preserve handoff context, and maintain trust as development accelerates. Because in an AI-native world, the session is the story.
Understanding at machine speed with thousands of contextual tools
Tudor Girba
As AI accelerates code generation, it becomes impossible to ignore the real bottleneck in software development: making sense of systems. In truth, this has always been the largest cost. Code reading never really worked as a scalable solution because it is the most manual way to extract information from a system. Today, that limitation is even sharper: systems are too large, and AI produces code too fast. Reading does not scale, and we should stop relying on it as the primary means of informing ourselves about our systems. Instead, we should augment human cognition with deterministic, contextual tools built for each problem. These tools that compress the system around the question at hand and help both humans and AI explore and reason faster. We call this Moldable Development. It enables teams to see their systems clearly and answer system questions quickly. These contextual tools do not help only people: they also help AI agents make sense of systems. Spread throughout the system, they become contextual skills and form an extensible kind of agent memory. What exactly is a contextual tool? Come to the talk to see live examples built with Glamorous Toolkit, the free and open-source environment that helps you understand and steer systems through thousands of contextual tools.
Save your seat before it fills.
Early pricing runs while the programme is still being finalised.