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

Karyna Bunta

Seungho Park

Lera

Daria Shabala

Kseniia Korostelova

Thibault Van den Broecke

Nikita Golovko

Mykhaylo Ryechkin

Boris Karaivanov

Sauparna Sarkar

Vitor Barbosa

Mathieu Habegger

Myron Davis

Thomas Rehmer

quinton sheppard

Vladyslav Abramov

Chaitanya

Yakovlev Eugen

Varun

Artem Zozulia

Michael Chiche

Marvin Kaunda

Sebastien HUGUENOT

Jeff Costello

Filipe Dávila Fernandes

Sanketh Kumar

Nico Deufemia

Yousuf Tafhim

Tatiana Shibaeva

Jeferson Franco

Frank Puk

Ota Švimberský

Weam Adel

Dmitry Melnikov

From Vibe Coding to Vibe Engineering

Kitze

Vibe coding feels productive until you have to maintain it. Behind the agent "thinking..." you ignore and the code you never opened lies a growing pile of wasted tokens, nondeterministic behavior, and compounding errors hiding in plain sight. This talk pushes back on the status quo: elaborate agent architectures, "prompting astrology", overnight automation loops burning through context windows and credit cards. We'll look at why determinism, state machines, and explicit guardrails aren't "old-school"... they're the only sustainable way forward. We'll look at why vibe coding compounds technical debt faster than any era before it, and how modeling behavior explicitly lets you ship AI features you actually understand, maintain, and trust.

Goodbye Slop; Welcome Determinism

David Khourshid

Most agents fail in production for reasons the model can't fix. In this workshop, we start from an agent that fails and lies about it, then harness it step by step until it does the job reliably, without a single change to the prompt. Workshop outline: 1. The failing agent: why it breaks, and why it claims success anyway 2. The agent loop, built up from an empty loop 3. A tool registry and context management 4. Guardrails, context compression and retries that hold whichever model sits underneath 5. Deterministic verification, so the agent fails honestly instead of claiming success 6. Moving secrets and fragile steps, like login, out of the model and into the harness 7. A harness plan for the agents you're building

Build a Production Agent Harness

Tejas Kumar

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

Most LLM calls in our apps aren't asking for prose. They ask "which team?", "is this safe?", "is this fix good enough?", and then we parse a sentence back into a boolean. A new class of models, decision models, skips the sentence: you send state and typed questions and get back a calibrated probability for every option, in one pass. You'll leave this session knowing where a decision model replaces an LLM call, where it must not, and how to use confidence to decide when to act, ask or escalate.

Stop Generating, Start Deciding

Maxim Salnikov

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

As coding agents write more of our software, token efficiency becomes part of developer experience. The framework influences the time and effort agents spend, how well they can verify their work, and the performance and user experience of the applications they build.This talk shares how we’re using evals on the Next.js team to measure and improve agent success. We’ll look at what we’re learning, how framework features and automated workflows support that work, and what that means for developers building with agents.

Building Next.js for Agent Success

Aurora Scharff

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

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.

Vladimir Novick

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

Every repo has them now: CLAUDE.md, AGENTS.md, a folder of markdown rule files written to steer the AI. Write the rule once, get the code you want. Except these files are advisory, not enforced, as every major vendor says so in their own docs. The research backs it up. Adding them doesn't always improve results, and it can raise the costs by more than 20%. Adherence fades as files grow and conversations run long. This talk is about how to minimize and fix this problem. First, how the tools really work: how Cursor, Claude Code, and Codex load and rank rule files, why precedence between them is often undefined, and how to check what actually reached the model on a given run. Then how to govern rules like real code: scope each one so it fires only where it should, put the non-negotiables up top where the model pays attention, and prune the files before they rot or start contradicting each other. And for the rules that truly cannot fail, move them out of prose and into hooks and CI, where the action is guaranteed every time. Do all that, and each rule earns a second job. Beyond steering the AI, a written-down rule is the standard you measure the finished code against. And that gap, between the app you described and the app you got, is where trust actually lives. You'll leave knowing which of your rules do real work and which just sit there looking like they do, and how to verify that instead of assuming it.

Why Agents Ignore Your Rules

Filip Hric

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

AI will not replace data engineers tomorrow. But it is already changing how we work — including, occasionally, helping us do stupid things with more confidence. Used badly, AI will make us weaker engineers. We outsource judgment, trust the output too quickly, miss the details, and slowly lose the habit of critical thinking. Used well, it can make us sharper. AI can help with the parts our brains are weaker at: holding lots of context, exploring many options, drafting code, explaining errors, and moving faster. This talk is inspired by a real example: Claude Code building a dbt project on DuckDB from API data. It created models, tests, docs, incremental loads, and freshness checks. Impressive. Until you realise it missed API pagination, dropped useful fields, and made questionable modeling choices. The pipeline looked like it worked, but it did not. AI is great at speeding up the mechanical parts of data engineering: writing boilerplate, debugging dbt errors, generating SQL, suggesting tests, and exploring unfamiliar code. But it does not remove the need for judgment. Someone still needs to ask: Is the data complete? Is the model correct? Are the assumptions safe? Would I trust this dashboard in a real business decision? So this is not a talk about "AI instead of data engineers.", it is about data engineers using AI well. Not to delegate thinking, but to help us magnify our skills.

Claude Code Isn’t Going to Replace Engineers (Yet)

Olena Kutsenko

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

AI agents now write more code than any team can review diff by diff. This talk is a simple way to split the rules your code must never break: static rules you can check without running userland code, and runtime rules that need real execution to verify. You'll leave knowing what to enforce statically, what needs a runtime check, and how to generate both from your own codebase so your standards hold as agents outrun your reviewers.

Static and Runtime Enforcement for Agentic Code

Jakob Heuser

AI can generate a React feature in minutes, but getting it to production quality is a different story. In this advanced, hands-on workshop we go beyond simple prompting and build a real React application with Cursor AI, the way professional teams do it. You will learn how to: - Set up Cursor for a real codebase with project rules, context and reusable prompts - Plan and build features with Cursor's Agent while keeping full control over architecture and code quality - Generate and maintain tests, types and documentation with AI - Review AI-generated code for security issues, performance problems and hidden bugs - Refactor and scale an existing React codebase safely with AI assistance - Prepare the application for production with CI checks, linting and deployment best practices By the end of the workshop you will have a practical workflow for using AI to ship React features faster without sacrificing quality, security or maintainability. Level: intermediate to advanced. Basic React and TypeScript knowledge is recommended.

Building Production-Ready React Applications with Cursor AI

Kristiyan Velkov

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

AI has made writing code cheaper, but the hardware doesn’t get any cheaper. I build React apps used worldwide, many running inside WebViews on affordable Android phones. These devices often represent the slowest 10% of user experiences. Even when all CI checks pass, performance issues can still slip through review. AI has also made another part of this process harder. We can release more code, but reviewers still have the same time. With more changes in each PR, reviews get crowded, and it’s easier to miss performance problems. To help with this, I built a loop around a coding agent. It reads runtime traces, runs the same benchmark every time, and compares the results with what we see from real devices in the field. I find this setup is useful, but it’s not all about success; it brings new ways to make mistakes in different forms: the benchmark gives better numbers, but the user experience gets worse. LLMs say the changeset is a win, but the trace shows the opposite. While LLMs are working on performance improvements, I’m working on guardrails and more deterministic tools for LLMs to make this loop more successful. In this talk, I’ll walk you through the setup I landed on: runtime traces, benchmarking, and the guardrails I put around the agent. I’ll also share a few places where my first assumptions turned out to be wrong. Twenty minutes is not enough to cover everything about performance engineering, but it is enough to share questions that helped me build this loop. I hope this gives you a helpful starting point for your own projects.

Continuous Performance Engineering in the LLM Era

Halil Emre Özen

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

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

A founder spent around eight weeks of his spare time adding 349,000 AI-written lines to a sports platform we had built. On the surface it worked. Underneath, anyone signed in could read strangers' private chats, and the tests that came with it passed. Three of us could not review our way through it. Agents write faster than any team reviews, and an AI marking its own homework gives itself a pass. The harness is the scaffolding in your repository that an agent works inside, so every session inherits your standards and every change meets checks the model doesn't control. In three hours you build three of its five layers: Repository instructions every agent session picks up, whichever tool it runs in Deterministic enforcement: your team's rules as custom checks that fail the build (analyzers, lint rules, strict types, post-edit and pre-commit hooks, CI that blocks the merge), with error messages the agent has to fix before it continues A validation loop the model doesn't grade: tests written from the spec by a session that never saw the code, and a check that calls every endpoint as every kind of user You work on a deliberately vibe-coded club app, then spend the last half hour on your own repository. Every merge faces one test: could you debug it half asleep at three in the morning? If not, it doesn't merge. What participants take away - Structure a repository so any coding agent inherits your standards - Move enforcement into deterministic tooling that gives agents immediate, non-negotiable feedback - Validate agent work with checks the model doesn't grade: tests from the spec, and every endpoint called as every kind of user - Hold your next merge to a gate you can defend at three in the morning Practical exercises 1. Run the task with no harness, find the defects in your own run, and see that the agent's tests pass 2. Write house rules as repository instructions and re-run a probe task 3. Write a custom lint rule (ESLint in the lab; a Roslyn analyzer or your stack's equivalent at home) that fails the build when code changes a balance outside the ledger, with an error message written for the model; wire it to a post-edit hook and watch the agent fix its own code 4. Break the hook on purpose and watch the edit go through: hooks fail open 5. Have a second session that never saw the code write tests from the spec, and run a check that calls every endpoint as every kind of user; it finds the hole the agent added and one nobody touched 6. In your own repository: your team's most repeated review comment as a custom lint rule or analyzer that fails the build, or one spec-first test for code nobody fully owns Prerequisites A laptop with Claude Code, Codex or a comparable coding agent installed and authenticated, and the lab repository cloned before the session; we'll send a setup check in advance. Bring a repository you actually work in for the last half hour.

Build the Harness: Guardrails That Make Agent-Written Code Safe to Merge

Georgios Diamantopoulos

A founder spent six weeks with AI tools and shipped 300,000 lines: a WhatsApp clone with real users and a polished UI. Underneath, security holes, queries that pull an entire table to count its rows, and a codebase three senior engineers couldn't untangle. With low-code the limit was visible: the blocks ran out and you called an engineer. Vibe coding has no visible wall. Nothing stops you, nothing warns you, until production. He never saw the line he crossed. The constraints didn't vanish, they shifted: security, maintainability, performance, UX. The AI generated with a weak feedback loop: generate, glance, ship. Exploration is real value: you have to build things to understand what you're building, and AI makes that faster than ever. So I'll rebuild it the other way: hand the AI the instruments engineers spent years mastering, as a tight loop it answers to while it writes. Constraining AI before it writes, not after, is what I call Human-Driven Development. Tooling only goes so far: it raises the floor and can't make the judgement call. The hard skill is catching the moment a prototype gets run as a product, bearing load it was never designed for, and humble enough to get a real review first. Drawing that line is what separates a product from a rewrite. I'll run both loops on the same work, generation after generation, and you'll watch them diverge, my AI sidekick Loyal calling out what's rotting, or holding, underneath. AI made the engineer the last line of defense.

Vibes Don't Scale

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

We had more incoming requirements than our team could review, so we built a multi-agent pipeline in CI that takes raw requirements and turns them into reviewed, scored, spec-ready work items. Each requirement gets scored across five dimensions with a hard pass threshold. The ones that pass go through four parallel AI reviewers covering Feasibility, Testability, Scope, and Architecture. Each reviewer writes its findings back to Jira as markdown that engineers actually pick up and use. I'll walk through the rubric design, how the parallel reviewers work, and why calibrating the pass/fail threshold was harder than building the pipeline.

Score, Review, Spec: Multi-Agent Quality Gates in CI

Dipanshu Gupta

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

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

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

"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

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

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

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

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

The core idea: coding agents have made implementation fast and inexpensive, but acceptance remains a human bottleneck. Before any code is generated, user scenarios should therefore be translated into executable end-to-end acceptance tests. The workflow: Context → Problem → Specification → User Scenarios → End-to-End Tests → Agent Implementation → Human UAT There are two points where human judgment is essential: At the beginning: deciding what to build and why, defining the scope, and making architectural decisions. At the end: accepting or rejecting the result. A green test suite indicates engineering readiness, but it does not prove that the product delivers value.

Define Done Before the Agent Starts: Turning Product Scenarios into Executable Acceptance Tests

Innokenty Bodrov

Before You Pick an Agent Orchestrator: What I Learned Wiring a Self-Driving SDLC

Yedidya Schwartz

Most coding agents are evaluated at the moment they answer. Software teams discover whether an answer was useful much later: a test fails, a reviewer requests changes, the pull request stalls, or the code ships. This talk shows how to turn those delayed signals into a continuous evaluation system. We instrument AI conversations, tool calls, diffs, commits, CI runs, review comments, and merge outcomes, then join them into one trace from prompt to production. Using a working implementation, I’ll walk through the event model, correlation logic, and queries that separate accepted work from rework and repeated failure. I’ll show the hard parts: carrying trace context across unrelated tools, distinguishing flaky CI from agent errors, protecting developer privacy, and avoiding vanity metrics. Finally, we’ll turn recurring corrections into human-approved candidate skills and test whether they improve first-pass CI, review rounds, and time-to-merge. You will leave with a product-agnostic blueprint for outcome-based evaluation of coding agents.

The PR Is the Eval

Jack Fitzsimons

The SDLC has barely changed since software engineering began: a linear, largely single-threaded process, optimised for a world where writing code was the expensive part. AI has made expression cheap, and the whole coordination layer is now built for a scarcity that no longer exists. I argue the unit of coordination should move from the ticket to the plan, the reasoning behind the work, as a shared, continuously changing artefact rather than something local to one engineer.

The Critical Engineer: Collaboration When AI Makes Code Cheap

Dries Samyn

Architecting for Agents: Your Codebase Design Matters More Than Your Prompts

Waldemar Neto

A test that passes for the wrong reason is the worst failure in test code: it certifies a broken GPU driver and nothing alarms. I maintain the Khronos Vulkan Conformance Test Suite and run AI coding agents on it every day. This talk is the grading discipline that keeps that work honest: every agent result checked against a human-reviewed reference, so I can tell a correct fix from a lucky-looking one before it ships.

A Test That Passes for the Wrong Reason: Reliability for AI-Assisted Conformance Testing

Lorenzo Dal Col

AI-assisted coding is transforming how we build software - from copilots to autonomous agents, developers ship faster than ever. But in enterprise environments governed by ISO 27001, SOC 2, and strict SDLC requirements, speed doesn't exempt you from compliance. If you didn't write the code, where do you safely run it? This talk explores sandboxing strategies for AI-generated code: isolated environments that sit between your laptop and production, providing network isolation, ephemeral reproducibility, and audit trails. We'll also tackle the data problem - why empty sandboxes aren't enough, and how AI-generated mock data and copy-on-write production snapshots each solve different challenges. Through real-world stories, we'll see why the "legacy user" can't be mocked, and what a proper AI-assisted development workflow looks like in a compliance-driven organization.

Move Fast(ER), Stay Compliant

Florian Margaine

For decades, we've built software around a simple assumption: the same input produces the same output. If behavior changes, we can usually trace it back to a code change. We write tests, review diffs, deploy to staging, and rely on CI because software is fundamentally deterministic. LLM systems break that assumption. As you build with language models, behavior increasingly emerges from the interaction between prompts, retrieval, context, model choice, and evaluation—not just the application code itself. Features can regress without a single line of business logic changing. A prompt tweak fixes one failure mode while introducing another. The engineering instincts that served us well for years don't disappear, but many of them stop being sufficient. This talk is about what that transition has actually looked like while building agentic systems at Typeform. Rather than presenting a polished architecture or a success story, I'll walk through real features we're building today - including the trade-offs, dead ends, and problems we still haven't solved. Each example highlights an engineering habit I had to rethink. I'll cover four practices that have become essential: continuous evaluation instead of relying on traditional test suites, trace-level observability instead of application logs alone, reviewing prompts and other AI artifacts as first-class engineering assets, and orchestrating systems whose components are inherently non-deterministic. The goal isn't to convince you that AI changes everything. It's to show which engineering principles still hold, which ones need to evolve, and the practical patterns we've found useful along the way. If you're already building LLM applications - or are about to start-this talk aims to save you from having to unlearn some of those lessons the hard way.

When Software Stops Being Deterministic: Rethinking Engineering Practices for AI-Native Systems

Susanna 

One real workflow: warm a repository once, fork it into several isolated agent workers, collect build and test evidence from each, reject the contaminated branches, and reduce to one trustworthy patch. This talk is built around that one mechanism and a measured result, not a survey of agent frameworks.

Software Factories Need Forkable Computers, Not Bigger Context Windows

Yossi Eliaz

The engineers who make it to staff level aren't the ones who wrote the cleverest code. They're the ones who figured out that code was never the point. Most of us learn this too late — after burning hours on solutions no one asked for, defending implementations no one remembers, wondering why technical excellence isn't translating into career growth. Agentic AI just made this lesson impossible to ignore. But for engineers feeling anxious about that, there's good news: what actually drives growth at every level — senior, staff, and beyond — has always been more human than technical. How you communicate. How you understand a problem before you solve it. How clearly you can articulate what kind of engineer you are. Scott Batson (Staff Engineer at Medium, with 15 years building at Netflix, PBS NewsHour, and beyond) makes the case that the engineers thriving in the agentic era were already thinking this way. This talk is about getting there.

The Code Isn't Precious: What Every Staff Engineer Figured Out That You Haven't Yet

Scott Batson

AI coding tools make developers faster, but they do not automatically make organisations ship faster. PR volume rises, review queues grow, tests weaken, and context, security, and platform bottlenecks become visible. AI does not remove the constraint; it moves it. This talk combines the AI Adoption Ladder with the emerging architecture of software factories. It shows how teams progress from first licences to agentic delivery, and the six systems required to scale safely: orchestration, sandboxes, context, validation, governance, and learning loops. Attendees will learn how to identify their next bottleneck and build beyond “everyone gets Copilot.” Licences create activity. Software factories create durable advantage.

From Copilot to the Dark Factory

Pini Reznik

How we wired production MCP servers into a company operating loop where Slack feedback becomes Linear work and real PRs, while CI stays the merge gate.

Our Software Factory Ships Through MCP: Slack In, PRs Out, CI Decides

Kaan Karakas

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

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!