Name: AI Coding Summit Berlin
Start: 2026-12-04T08:00:00.000Z
End: 2026-12-07T20:00:00.000Z

Seungho Park

Lera

Thibault Van den Broecke

Karyna Bunta

Kseniia Korostelova

Mykhaylo Ryechkin

Sauparna Sarkar

Boris Karaivanov

Vitor Barbosa

Myron Davis

Irina Baeva

quinton sheppard

Chaitanya

Artem Zozulia

Yakovlev Eugen

Marvin Kaunda

Jeff Costello

Filipe Dávila Fernandes

Varun

Michael Chiche

Nico Deufemia

Yousuf Tafhim

Tatiana Shibaeva

Jeferson Franco

Frank Puk

Sanketh Kumar

Greg Motyl

Christian

Jelena Marjanović

Aleksandr Popov

BEDNAR

Thomas Rehmer

Ethan Garrison

Alfredo Soto Nolazco

Every team has coding standards. Almost none of them are written down: they live in years of PR review comments, repeated over and over by senior engineers who are tired of typing the same feedback. Meanwhile, AI coding agents write code faster than your seniors can review. The code is technically correct, but somehow never quite up to standards, and you end up being a human nitpicking machine for AI generated code, the same way you nitpick a junior dev. What if all that review history could work for you instead? Your old PRs are a record of every standard your team actually enforces. It's the feedback real engineers gave on real code. This talk shows how to turn that archive into something your AI tooling understands, so agents write and review code the way your team does, and how to check the results against the original human feedback so you know it actually works. You'll see the whole approach in practice, and leave with a method you can apply to your own repos regardless of which AI tools you use.

Your Old PRs Are Your Coding Standards

Eddy Vinck

I built a software factory: a Kanban board where dragging a card starts an agent, tasks that unblock each other as they finish, agents with their own roles and prompts, and an adversarial reviewer that goes through the code before I ever see it. It worked. I barely used it. The problem wasn't the factory, it was that I kept working the way I always had: sitting with an agent, pushing it forward, jumping to the next one, course correcting. Everything interactive. A factory can only take work you've already made the decisions for, and almost none of my work arrived that way. You'll leave this talk with a concrete way to split your work into online work that needs your continuous attention and offline work an agent can run with for hours, and with the rebuilt factory I actually use now: tasks I arm during the day, fire in the evening, and verify and push forward the next morning.

I Built a Software Factory. I Barely Used It. Here's How I Fixed It.

Juri Strumpflohner

It is 2 AM. Production is down, and the code that broke was written by an agent nobody on your team fully understands.  This is the real cost of AI coding: you shipped fast, then traded away the one thing an incident demands,  the ability to reason about your own system.  Green tests hid it. Review waved it through.  Using real production stories, you will walk the failure patterns unique to agent-written code and the warning signs that surface them early. Keep the velocity.  Just make sure you can still debug what you ship, so that at 2 A.M. you can say "I got this!!"

Your AI Wrote It. Can You Debug It at 2 AM?

Maish Saidel-Keesing

We all write code with AI tools now, and those tools are basically agents with real access to our machines. This year gave us a good look at what happens when that goes sideways. The case this talk makes is that these problems aren't new or mysterious. They're the same kinds of security bugs we've dealt with for years, just wearing an agent costume: something untrusted comes in, and something with real permissions goes out. And often it isn't one bad action, it's a few normal ones that add up.

When Your Coding Agent Does Something You Didn't Ask For

Natalie Pistunovich

You don't need a framework to orchestrate coding agents well — you need the disciplines. In this hands-on workshop you'll take a real repo and orchestrate a small fleet by hand, reaching honest L1 Orchestrated Coding (spec: https://github.com/vnovick/orchestrated-coding) — one owner of context, worktree-per-task isolation, brief/report handoffs, an independent reviewer behind a deterministic gate. Then you'll flip on orchestra - an open-source plugin - and watch the exact same disciplines become enforced: a hook that refuses to let an agent commit, fail-closed verification that says "unverified" instead of lying. Finally I'll run the fully autonomous L3 version live. Vendor-neutral, spec-driven, nothing to buy.

Orchestrate a Fleet of Agentic Loops: From By-Hand L1 to Enforced Doctrine

Vladimir Novick

Last time at AI Coding Summit London I gave you From Prompting to Orchestrating — the argument that coding with fleets of agents is a systems problem, and the spec (grounded in dozens of research papers from the major labs) that names the fix. Then I went and built that spec.  Twice. Once as an autonomous daemon that runs the whole loop for you, once as a plugin that lives inside your own coding session. The disciplines came out identical both times. The only thing that changed was who conducts the orchestra - and that turned out to be the whole lesson.  This is the sequel: what two real implementations taught me that the spec couldn't, including the two MUST-level checks my own reference implementation failed when I audited it against my own rules.

The Orchestra Plays Itself. Who Runs the Loop? Lessons from Two Spec Implementations.

Browser-based AI inference is stuck between two bad options: follow a standard and get portability at the cost of speed, or hand-tune your own kernels and burn weeks of deep GPU expertise per model. For Transformers.js, we tried something that probably shouldn't have worked as well as it did: handing that hand-tuning work to an AI coding agent, with way less supervision than seemed responsible. It found multiple-x speedups across LLMs, audio transcription and text-embedding models running in the browser, on hardware we already had. This talk is a case study, not a pitch. I'll walk through the loop that turned autonomous kernel optimization from chaotic into trustworthy, the one instruction that changed the agent's behavior more than any amount of prompt engineering, and the counterintuitive lessons from real experiments, including why our biggest wins did not come from clever algorithms and why you should never let your agent gaslight you into thinking it's done.

"I'm AFK for a Bit": Letting an AI Agent Run Wild on WebGPU Kernels

Nico Martin

The team already had a design system, but it covered only part of the ecosystem. Web and mobile interfaces were still built separately, patterns drifted between products, and feedback arrived late. AI could speed up code generation, but without shared context and enforceable rules, it could reproduce the same inconsistencies faster. In this talk, we’ll show how we rebuilt that workflow around shared React and React Native components, agent-accessible design context through MCP, Figma Code Connect, pre-write guardrails, and automated visual checks. We’ll also explain how moving working prototypes ahead of final design sign-off brought stakeholder feedback into the process earlier. The result: more than 60 mapped components, a visual-diff threshold below 2%, and prototype time cut from about an hour to ten minutes. AI can generate a screen quickly. This talk is about what it takes to trust the code behind it.

Why a Design System Wasn’t Enough for AI-Generated UI

Szymon Chmal

Nora is the agent harness that runs my company of 1500+ employees and thousands of agents. Everyday Nora handles about 2k+ Slack requests and 300+ pull requests generation across 300+ team-specific personas. We built it the way most teams build agents today, with a central router delegating to specialist subagents for Jira, Slack, Salesforce, and a half-dozen other domains. Each one carried its own prompt, tools, and LLM call. Over the past year we deleted almost all of them. The pattern was the right call for the models we had in 2024, when breadth made them hallucinate tool calls and loop. Then the models got better and the scaffolding we built to compensate became the ceiling. A subagent boundary is a second copy of your prompt layer, identity, quota, model choice, authz surface, and tool namespace, and every copy drifts from the first. This talk show you the wrong answers that drift produced in production, and what we replaced them with, including the one place we put delegation back on purpose. You can learn about Nora from this blog : https://builders.abnormal.ai/p/nora-our-first-agent-employee

Delete Your Subagents. Keep Your Delegation.

Tushar Amrit

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.

(MCP Security) - How Your Friendly MCP Tool Might Betray You

Daniel Ostrovsky

Ten files changed, pull request open, four minutes of work. The agent ships – but nobody reads what's being produced anymore. What happens to the domain logic when code stops being the artifact humans use to verify it? And why do teams get slower even as they produce code faster? As a Microsoft MVP for Developer Tools, Daniel helps teams build agent-driven workflows – and shows the patterns where they consistently break down: architectures that erode under the flood of files, untested legacy code, requirements that end up in the prompt instead of in acceptance criteria. His antidote isn't a better prompt – it's determinism: acceptance criteria as executable BDD scenarios, TDD as a stopping condition, hooks that actually enforce the rules. Because "please test the code at the end" in your AGENTS.md isn't a quality gate – it's a request.

Determinism over Prompts: When the Agent Ships and Nobody Reviews

Daniel Sogl

Building Production-Ready React Applications with Cursor AI

Kristiyan Velkov

In this workshop, I'll guide participants through a decision framework for Claude Code's orchestration tools. Most people already use two or three of them and guess about the rest.

Advanced Claude Code Orchestration: A Decision Framework for Skills, Subagents, Goals, and Workflows

 Shrey Shah

AI has completely changed how software engineers work. But interview processes haven't caught up. Coding assistants solve LeetCode problems in seconds. AI can generate polished system design answers. Almost every candidate walks into an interview with powerful AI tools, yet many companies are still trying to evaluate engineers as if none of this exists. So what actually separates exceptional engineers from everyone else? After interviewing hundreds of engineers at Elementor, I realized we had to stop testing who could write code without AI and start testing who could build, reason, and make decisions with it. In this talk, I'll pull back the curtain on what modern engineering interviews actually measure. You'll see why some candidates fail despite using AI effectively, why others succeed even when AI makes mistakes, and what signals experienced interviewers look for beyond generated code. Whether you're interviewing for your next role or redesigning your hiring process, you'll leave knowing which skills matter now, how to demonstrate them during interviews, and why engineering judgment has become more valuable than ever. Key Takeaways 1. Why traditional engineering interviews are breaking down Understand how AI tools have changed the signal we get from coding interviews and why many common interview formats no longer evaluate the right skills. 2. What actually matters in engineering interviews today Learn which capabilities distinguish strong engineers in the AI era, including technical judgment, problem framing, and system-level thinking. 3. How to evaluate candidates when AI is part of the process See practical approaches for assessing coding ability, system design skills, and engineering decision-making when candidates are using AI tools. 4. Signals that reveal real engineering strength Discover the behavioral and technical indicators that distinguish high-impact engineers from candidates who rely on AI to compensate for weak fundamentals. 5. How candidates can stand out in AI-era interviews Understand how engineers can demonstrate their ability to use AI effectively while still showing strong engineering thinking and ownership. 6. A practical framework for modern engineering interviews Leave with a concrete approach for redesigning interview processes to evaluate the skills that matter in the AI era.

AI Ruined Engineering Interviews. Now What?

Dennis Nerush

Every new project starts with copy-pasting agent instructions, skills, hooks and custom agents from the last one. Improvements have to be propagated everywhere, and within months you have a dozen repos running subtly different versions of the same setup. I fixed this for our team by building a shared Git repo of composable agent packages, managed by APM (Agent Package Manager) and installed in one command. In this lightning talk, I'll walk through how I structured the repo, how each project declares only the packages it needs, how you can mix in community-built skills alongside your own, and how APM deploys the right config to the right tool. You'll leave with a concrete setup you can bring to your own team that same week.

Stop Copy-Pasting Your AI Agent Config

Dante De Ruwe

AI agents seem complicated. But once you look under the hood, they're built from a few simple ideas. In this talk, I'll use a real AI agent to show how its core loop fits in around 80 lines of code. We'll then explore the key ideas behind modern agents, including tool calling, conversation history, and stopping conditions. I'll also explain what frameworks actually do and which problems they're designed to solve. You'll leave with a clear mental model of how AI agents work and the confidence to choose the right approach for your own projects. Table of contents: - AI agents are simpler than you think: an 80-line implementation - What do we actually send to the LLM? - How does the LLM know what to do next? - How does tool calling work? - Conversation history - Stopping conditions - Where frameworks really help: retries, fallbacks, security, and conversation management

The Dirty Secret Behind AI Agents: Build One in 80 Lines of Code

Sylwia Laskowska

We used AI agents to speed up the hand-tuned flamegraph renderer in our continuous profiling product. Across 43 agent passes, we got 66 proposed optimizations. Most were wrong, too small, or failed once measured. The one that shipped took normal renders from about 21ms to 6ms, and inverted renders from about 44ms to 8ms in production A/B tests. This talk is about using agents for React performance work without trusting their first answer.

Red Teaming AI Performance Ideas: What Survived Measurement

Yomi Eluwande

When we audited our AI coding-agent instructions (CLAUDE.md files, skills, agent definitions) against our actual monorepo, we found docs that were confidently wrong: styling guides producing CSS that never matched the build, test templates that crashed on render, "best practices" used by 1 of 50 real files. Every wrong doc cost a multi-thousand-token debug loop each time an agent followed it. This talk is the playbook that came out of fixing it: how to distribute knowledge across instruction surfaces based on their loading semantics, and how to test docs the way you test code.

Your Agent Docs Are Lying: Structuring and Testing Instruction Files for Coding Agents

Hamid Shoja

"How do you write a regression test for a bug that refuses to reproduce? A production bug you cannot reproduce is a bug you cannot prove you fixed. If you have ever patched an agent, rerun it, watched the failure vanish, and still had no idea whether you fixed it, you know the problem. Rerunning a nondeterministic system changes the very thing you are trying to measure, while replay holds it fixed.But what if you could replay the incident exactly as it happened and change only the one boundary you fixed? Enter cut point replay. A boundary is any point where the agent calls a model, invokes a tool, or makes a routing decision. We serve every boundary upstream of the fix from the recording, then run the boundary you changed, the cut point, and everything downstream live with no model call, so you see what your fix actually does and get the same incident on every run. We check the result in two layers, a deterministic structural check that never flakes and an LLM judge for wording changes that should not change behavior. You will leave able to commit any agent incident to git as a regression test that runs in CI on every pull request, turning a failure nobody could reproduce into part of your test suite, using Chronicle, an open source tool we built for exactly this and run against production agents."

Turn Agent Incidents Into Regression Tests That Actually Hold

Tisha Chawla

Susheem Koul

Application modernization has always been hard. The hardest cases combine decades of complexity with missing knowledge, proprietary technology, hardware dependencies, unclear requirements, and systems that cannot simply be switched off. Agentic AI gives us a new chance to make these projects technically and economically viable. It can reconstruct knowledge, explore unfamiliar systems, and support modernization at a previously unrealistic scale. But producing modern code does not prove successful modernization. Agentic engineering is only as good as its verification mechanism. This talk shows how to assess a candidate, build the right context, define what good looks like, and modernize in controlled increments. We will examine a framework combining human judgment, AI based evaluation, and deterministic tests to create credible evidence that the new system actually works. The question is not whether agents can modernize a legacy system. It is whether we can prove that they did.

Agentic AI Can Modernize It. But can you Prove it Did?

Julia Kordick

Demo agents break in production: loops, wrong tools, leaked context, silent regressions. Not a model problem. This session builds the reliability harness, a deterministic layer that observes, constrains, bounds, and evaluates the model with AWS building blocks. Numbers are real traces or evals.

The Reliability Harness for AI Agents on AWS

Guilherme Dalla Rosa

I've been doing TDD and clean architecture for years. When I started using Claude Code to build a real application, I wanted to create it the right way from day one - test-first, walking skeleton, steps sized for review. And it worked. Partially. The agent could explain TDD better than most developers, but then skipped the red phase in the same session. And when I noticed, it apologized. And did that again. It also avoided my recommendation to change only a few files at one go. And when I noticed - this one was hard to hide - it apologized. Then did it again. Code agents do what we ask, until they decide not to. And that put our product at risk. The good news: My way - using the classic hits - works. I just needed to teach it to my agent. And that requires putting reinforcements in place. Measure things and report them on the way, and make tasks small so they can be reviewed without putting the human to sleep. In this session I'll show the steps, prompts, processes I set in the project to implement my ideal work process. I'll show how I enforced the TDD loop. How I made sure no extra code was created. The structured planning. And the thought process behind making the automation controllable and reviewable. I'll also show how the project evolved to support my learning and retaining knowledge, performing diagnostics and tracking decisions. I'm now producing code I can trust. And you can take those techniques and use them in your process too.

Teaching AI to Build Software My Way

Gil Zilberfeld

AI agent memory might sound complicated until you realize there's already a perfect example of it, and it's a human brain. That's the whole idea behind this talk - agent memory becomes easy to understand the moment you compare it to your own. We'll take the different types and techniques of AI agent memory and match each one to the part of the brain it mirrors, so instead of learning abstract concepts, we'll just recognize how our own mind already works. Then we'll see how it works in a real agentic system we built in production, with these techniques in action: how it decides what to remember, how it recalls the right thing at the right moment, and how it forgets the rest.

How Memory Works, from the Human Brain to AI Agents

Alina Astapovich

Stop prompting. Start orchestrating. In four intense hours you'll go from using Claude Code like a faster autocomplete to commanding it like a senior engineer commands a team: engineering its context, deploying fleets of subagents, locking it down with hooks, and turning it loose on work that runs without you.Every Claude Code user hits a ceiling where the easy wins run out. The agent handles small stuff beautifully, then loses the thread on anything real. The difference between that ceiling and real mastery isn't better prompts. It's control. This workshop is about control.You'll spend the whole four hours inside CLASH, a real full-stack application, handed to you fully built so nothing stands between you and the hard parts. A serious codebase is the point: it's the only place agentic engineering shows you whether it actually holds up.The throughline is context. Treated carelessly, the context window fills with noise until the agent drifts. Treated as a resource you engineer, it becomes the biggest lever you have. From there the toolkit opens up. Repeatable work becomes a reusable Skill. Noisy, exploratory work goes to subagents that run in their own isolated context, several at once when the job allows. Hard rules become hooks the agent cannot cross. Your own systems come into reach through MCP.Then you let go of the wheel, carefully. The same agent that pairs with you can run headless in a pipeline, drive a long task to a defined finish on its own, or live inside your software through the Agent SDK. We close by setting two greenfield methodologies, Spec Kit and BMAD, side by side, so you leave knowing not just how to drive the agent but which approach fits which problem.Two ideas hold it together: context is king, and you push it, you own it. This was never about generating code faster. It's about staying in command while the agent does more.This is an advanced session for engineers, tech leads, and architects who already use Claude Code every day and want to reach the top of the curve. We move fast, and we start in the deep end.

Claude Code: Black Belt

Pawel Sawicki

Don’t get left behind—discover how AI is revolutionizing software engineering at the AI Coding Summit. Dive into cutting-edge talks and hands-on workshops on AI-powered software development. Network with industry leaders, explore game-changing tools, and stay ahead in the fast-evolving world of AI-driven development. Do not miss the biggest shift in software engineering.

AI Coding Summit

I'm attending AI Coding Summit with 5k other participants to learn how AI transforms software development and stay up to date with the latest AI tools - get your free remote ticket and join me there!