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

Lera

Karyna Bunta

Kseniia Korostelova

Vitor Barbosa

Yakovlev Eugen

Varun

Michael Chiche

Sanketh Kumar

Rosa Anna Chintemi

Estefania León

Karina Bunta

Vitória Zoche

Hasini Liyanawadu 

Juan Picado

Thomas Martinsen

Oliver Küchen

Mohamed  Haji

Marcin Kołodziej

Andrew Siggemann

Camila Coello Merino

David

Chris Eady

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

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

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

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!

AI Coding Summit Berlin

FocusReactive

Hygraph

FocusReactive is an&nbsp;<meta charset="utf-8" id="isPasted">engineering-led <a href="https://focusreactive.com/" target="_blank" rel="noopener noreferrer">Headless CMS Development Company</a>&nbsp;and&nbsp;<a href="https://focusreactive.com/next-js-expert-agency/">NextJS&nbsp;development experts</a>. Independent partners of Payload CMS, Sanity, Storyblok, Vercel and Shopify. Delivering&nbsp;<meta charset="utf-8" id="isPasted">Composable content platforms built for AI SEO, growing teams, and marketing velocity.

AI Coding Summit Berlin

See how AI transforms software development