Name: AI Coding Summit NYC
Start: 2026-11-16T15:00:00.000Z
End: 2026-11-19T22:59:00.000Z

Taz Singh

Karyna Bunta

Violina Popova

Seungho Park

Lera

Daria Shabala

Kseniia Korostelova

Will Klein

Sander Vervaeke

David Pugh

Stefan Elsenhuber

Amanda Witecki

Anton Zalaldinov

Mykhaylo Ryechkin

Filip Michalowski

Alex Hayton

Burak Buruk

David Passarelli

Ryan Ogden

Boris Karaivanov

Arash Sarfehjou

Vitor Barbosa

Jan Pfeiffer

Klaas van der Werk

Mathieu Habegger

Denis Radin

Thomas Rehmer

Manasa Mallipeddi

Fathima Fasna

quinton sheppard

Basseydou OUATTARA

Ward Werbrouck

Corbett Weinberg

Lia Moreira

AI is writing more code every day. The skill that will not get automated is knowing what to build. And how to ship it with confidence when agents do most of the implementation. In this full-day workshop, you will practice product engineering judgment upstream of the code, then put an AI-native delivery loop underneath it. You will learn how to validate a problem before you commit to a solution, understand the users you are actually building for, prioritize ruthlessly, and make reversible product decisions. Then you will set up the systems that let agents implement safely: shared intent and context, durable primitives, verification gates, feature flags, and outcome review instead of reading every diff. What you will learn: 1. Validate before you build: surface real user pain, not solution-shaped stories 2. Align intent with agents: shared understanding, options with trade-offs, and clear "done" 3. Prioritize what deserves to exist (cut ruthlessly) 4. Design two-way doors: use flags and reversible decisions so you can ship and learn 5. Build agent-ready primitives: structure the repo so agents reuse building blocks instead of inventing slop 6. Close the delivery loop: tests, AI review, CI, preview environments, and risk-aware shipping without babysitting every line 7. Keep the system improving: friction logs, cleanup, and feedback loops after you ship Who it's for: Software engineers with professional experience who already use (or are starting to use) coding agents. No specific stack required. PMs and tech leads welcome. Format: One full day, hands-on. Bring a laptop, take notes, and have your preferred agent ready to go!

AI-Native Product Engineering

Kent C. Dodds

What if you had your own npm registry, your own GitHub, your own cron system, your own email address, and your own database? And what if your favorite AI assistant could build software with all of it on your behalf? That's Kody: a personal assistant platform where every user gets a fully isolated software ecosystem. Your AI writes packages into your own git repos, publishes them to your personal package registry with real versioned imports, schedules your jobs, runs your long-lived services and workflows, receives email at your own address, and stores everything in storage only you can touch. I built this entirely on Cloudflare, because Cloudflare is the only place it could be built. This is a technical deep dive into what happens when you take the newest parts of the developer platform to their limits: sandboxing AI-authored user code with Worker Loaders, per-user git hosting with Artifacts, modeling "one of everything per user" with namespaced Durable Objects, and composing D1, KV, R2, Vectorize, Queues, Workflows, and Email Routing into a true multi-tenant platform. If AI agents are going to build and run software for everyone, this is what the infrastructure underneath looks like. You can start building it today.

I Built Your Personal Software Ecosystem

"AI writes slop" is a common concern. So how can we use LLMs to not just generate good code, but to *ensure* quality? Let's explore how to create effective "guardrails". After this session you'll have a list of novel ideas for improving the quality of your LLM's output.

Automating Quality with AI

Cory House

Vibe coding is easy, until you have to make an app that actually works. Sure, AI agents can spin up an impressive demo in minutes, but building a full-stack app that's robust, bug-free, and true to spec is where things get messy. And completely cloning an existing full-stack app? That's next-level difficult. Adding more agents just multiplies the mess, and spec-driven development piles stale specs on top of it. So... what does it actually take? In this talk, we'll explore a radically different approach, learned from building (and cloning) hundreds of apps for RL agent training environments and more: a living spec (yes, including state machines) and an AI-generated implementation that iterate on each other until reaching equilibrium, where the app provably does what the spec says. You'll learn how to model full-stack behavior as states, events, and effects, why letting agents modify their own workflows beats any rigid pipeline, and how to apply this experimental but extremely effective iterative loop to your own AI-assisted development today.

Cloning Full-Stack Apps with AI: What It Really Takes

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

Coding has changed a lot in the last two years, and it keeps changing faster than ever. It’s changed not just how software gets built, but who can build it. But what happens when agents move beyond responding to prompts and start working proactively, finding problems, improving systems, and moving ideas forward? In this talk, we’ll explore the opportunities and challenges of a world where agents are increasingly always working, and what that means for the people building alongside them.

What Comes After AI Coding

Dominik Kundel 

"I panicked instead of thinking. I destroyed months of your work in seconds." That was a Replit agent after wiping a production database during a code freeze. We’ve entered the "YOLO" era of agentic development. Between July 2025 and early 2026, we saw everything from Claude Code sessions destroying years of student data to supply chain attacks stealing thousands of developer secrets via --dangerously-skip-permissions. Developers are choosing autonomy over security because approving 100 permission prompts an hour isn't a workflow—it’s babysitting. This talk explores why traditional container isolation fails AI agents and how the Docker Sandbox (sbx) model provides a way out. Attendees will learn the architecture of microVM-based isolation and leave with a concrete pattern for running agents in "Full YOLO Mode" without risking their host machine or production data.

rm -rf: Horror Stories From Unsandboxed AI Agents (and How Docker Fixes This)

Rishab Kumar

Many assumptions about CI are breaking down. Faster hardware alone can’t keep pace with growing repositories and AI workloads. Underpowered cloud sandboxes push agents to validate changes in CI, without opening PRs. The tradeoffs between speed and cost are changing. This talk explores what’s changed and how CI needs to adapt.

Solving CI in the AI Agent

Victor Savkin

Writing code is only one part of delivering software. An agentic development loop begins with the intent behind a change and continues until its impact can be observed in production. That means understanding the product and the existing system, deciding what should change, implementing it across shared and platform-specific layers, verifying the result in the running application, releasing it safely, and learning from how the software behaves after deployment. Each step should produce context for the next one. Cross-platform products make this especially difficult. A change that looks correct in the repository can still fail at the boundary between JavaScript and native code, behave differently across platforms, or create problems that only become visible after release. This talk examines what it takes to close the full ADLC loop across mobile, web, and native. Drawing on Callstack's work in React Native and AI-native engineering, it maps the development system required to carry intent, context, and evidence through the entire lifecycle and turn agent output into dependable product outcomes.

Beyond Coding Agents: Making ADLC Work Across Platforms

Mike Grabowski

AI coding assistants are great at completing small tasks or features. But what do you do when you're working with more complex codebases and need to build in-depth features that require upfront planning? This talk makes the case for spec-driven development. I'll show how AI coding assistants can help break down complex tasks into three phases. We'll go from requirements gathering to technical design to task implementation. Using a real-world example, we'll look at the trade-offs of this approach and how you can start using it in your own projects right away.

Using Spec-Driven Development for Production Workflows

Erik Hanchett

Autonomous agents are exciting, but not always the right solution. When we build our agent system to migrate complex legacy PDF forms to structured business workflows, an autonomous agent seemed to be the obvious choice. Except it wasn’t. The system outputs were inconsistent, difficult to validate, hard for users to trust, and expensive. To fix this, we redesigned the system around deterministic workflows, using AI only where it adds clear value. In this session, I'll walk through the architectural evolution of our PDF-to-Workflow AI system, the lessons learned from what failed, how it helped to reduce migration time by 90% and the engineering tradeoffs that led us to a more reliable production-ready architecture framework. You'll leave with practical patterns for designing trustworthy AI systems, understanding when deterministic workflows outperform autonomous agents, and building AI products that users are willing to adopt.

Why We Chose Deterministic Workflows Over Autonomous Agents

Maya Shavin

With frontier models, now anyone in your company can build a dashboard with an agent. Rapidly, thousands of dashboards appear across the company. Then the underlying data model changes: revenue must exclude the new Buy-One-Get-One Free discount. Now all of those dashboards are silently but dramatically wrong, and incorrect numbers are presented to the board. The foundational solution to this problem is to build a semantic layer: a centrally governed set of well defined business metrics that all dashboards consume. Individual queries reference the central model and are compiled to up-to-date SQL at runtime. Suddenly you can make a change in one place and everything updates - what a beautiful abstraction! However, anyone who has built a layer like this knows that it takes a tremendous amount of time and human energy to build and maintain.  Or does it? We built an agentic harness to tackle a challenging industry benchmark (DABStep: Data Agent Benchmark for Multi-step Reasoning). Our approach used the open source Malloy language to build a central semantic layer that achieves over 95% accuracy, with no human in the loop. We also compare it to managing that central data model with markdown context and SQL statements.  We will cover the benefits and tradeoffs with the semantic layer approach and how to build your own harness and eval processes for your company. You will leave with a path to efficiently get trustworthy answers to your business questions, even when that business keeps changing.

From Markdown Files to a Compiler: Making LLM Data Answers Deterministic

Alex Monahan

Every CI vendor now ships auto-fix: a job goes red, an agent patches it, reruns, pushes to your PR. That was the easy part. The hard part is what else the agent can change while it's in there. To the agent, a test file and the workflow file are the same push. Nothing in most setups knows the difference. There's a line between fixing the build and owning the pipeline. Most teams haven't drawn it. Some don't know they need to. This talk is about where it goes, how to make CI enforce it, and why the agent that writes a fix should never be the one that says it's good.

Agents in CI Can Fix the Build. Don't Let Them Touch the Pipeline

Vladimir Novick

I have been running an AI second brain as a developer for the past year, and it saves me at least 20 hours every week. It knows my repos and the conventions in each one, dispatches coding work to run in the background, drafts my email replies, and pings me on Slack when something needs my attention. In this talk I will show you how to build one in TypeScript. We will walk through the four parts that make it work. The memory is just markdown files that the agent writes to and curates itself. Hybrid search runs over that memory so the agent pulls the right context at the right time. A scheduled loop makes it proactive, reviewing what happened yesterday, promoting what mattered into long term memory, and surfacing what needs me today. And an integration layer connects all of it to my repositories, my inbox, and the rest of the platforms I actually work in. You will leave with the full architecture and a clear path to building your own.

Build Your AI Second Brain

Cole Medin

"It costs too much" is one of the most common things I hear about accessible development. And the same thought-process applies in AI-generated code. An LLM defaults to what's easiest to write, and correcting for accessibility feels like extra work. Or at least that's what it's been trained to think. But what if the opposite were true? I ran the same prompts through the same model twice (once without any accessibility guidance in context and once with a lightweight accessibility skill loaded) and what I found confirms what accessibility advocates have been saying all along: it actually costs more and takes longer to ship inaccessible code. In this talk, I'll walk through the experiments, the numbers, and the failure modes it exposed. We'll look at what the AI actually built without accessibility context (spoiler: lots of custom code for features the browser already handles), why the accessibility-aware run converged faster, and what this means for how we ship AI-assisted code. You'll leave with the exact prompts and context patterns needed to make your model ship faster, more accessible UI on the first try, plus a data-backed argument for making accessibility a default in every AI-assisted workflow - not just because accessibility means that everyone can use the products we build - but because it's cheaper too.

The Cost of Accessibility in AI

Jemima Abu

Integrating an agent into your application is only half the battle; you also need to know what it's doing. Observability tools allow us to see where workflows fail, what they cost, and which agent steps need attention, so we can evaluate and improve. Get the crash course on what you need to know about agent observability.

Making AI Observability Easy

Kathryn Grayson Nanz

End-to-end tests are powerful, but they’re slow to write and easy to drift. We translate requirements into test code by hand, and over time the intent gets lost. What if behavior could be described in plain language and turned into reliable E2E coverage through a repeatable playbook? As an architect working across teams, I’ve been building structured playbooks that AI agents run through the Playwright CLI. These playbooks take requirements, designs, or existing code and generate natural language-based E2E scenarios tied to real user flows. The key isn’t automation. It’s structure. The playbook defines how context is gathered, how scenarios are created, and how results are validated so the system stays predictable. Join me to see how this works in practice. I will walk through the playbook design, the tradeoffs, and where AI helps versus where human judgment still matters. You will leave with a practical approach to adding AI-driven E2E testing without losing control of your test suite.

Playbook-Based E2E Testing with Playwright CLI and AI Agents

Avindra Fernando

My wife’s language-learning journey started with an intense Google Sheet she built from scratch to track her comprehensible input to the minute and forecast her Spanish proficiency. I transformed that spreadsheet into Polyo, a React Native app, shipped to prod in weeks, despite never having built a mobile app before ! Claude wrote most of the code (including a full rewrite from my initial vibe coded mess).  Through trial and error, I built up a dedicated AI harness repo that could help me ship to production with confidence! This meant having the correct context documentation, automated loops with reusable skills that maintain code quality and verify each change, and production monitoring to find issues early. It also helped to have the best QA tester in the business! This talk covers what my setup looks like and how I shifted from total vibes to a context driven harness to help my wife achieve her quest of becoming a Polyglot!

Agents, React Native, and My Wife’s Quest to Become a Polyglot

Kaleb McKelvey

Design-to-code used to be a one-way handoff: designers supplied intent and developers translated it into production. AI coding agents are changing that relationship. Developers can now give agents structured context from Figma, turn it into working interfaces, and bring code-generated results back to an editable canvas for review and iteration. In this demo-led talk, Riccardo Erra explores how the Figma MCP server connects these steps, where human judgment still matters, and the practical patterns teams can use as design and code move closer together in 2027.

Beyond Design-to-Code: Building Interfaces in 2027

Riccardo Erra

The Problem Enterprise engineering teams are burdened by aging Node.js/Express monoliths tightly coupled to fragile templates and untyped data layers. Manually refactoring these massive codebases into modern cloud-native architectures is notoriously slow, introduces severe regressions, and creates massive code review bottlenecks for developer workflows. The Solution Instead of manual rewrites, modern teams can harness advanced agentic-programming patterns to orchestrate dedicated agent swarms. This workshop guides advanced engineers through an automated refactoring and migration pipeline using Google Antigravity. Attendees will learn how to leverage structured task planning, parallel subagents, and automated LLM code reviews to transform a legacy Express monolith into a strongly-typed Next.js application. Key Takeaways By the end of this hands-on session, attendees will be able to: 1. Orchestrate Agent Swarms: Author deterministic task plans and custom Agent Skills that direct parallel subagents to audit legacy middleware, API contracts, and schemas. 2. Execute AI Refactoring &amp; Migrations: Automate large-scale structural code generation while establishing rigorous LLM-assisted code review gates. 3. Implement AI-Assisted Testing &amp; QA: Set up autonomous CI/CD verification loops where agents execute failing tests, parse error logs, and self-correct code until runtime parity is perfectly proven.

Orchestrating Agent Swarms: Automating Migrations with Agent Loops in Antigravity

James O'Reilly

Every team does the same thing. Agent behaves weirdly in production - retries endlessly, drops tasks, returns confident nonsense. First reaction: swap the model, tweak the prompt. It's never the model. Multi-agent systems aren't an AI problem. They're a distributed systems problem with an AI layer on top. And most teams skip all the boring infra - state management, observability, failure handling, routing - and pay for it later. We'll go through 8 agentic patterns (supervisor/worker, swarm, reflection, human-in-the-loop and more), and for each one: what the pattern does, where it breaks, and what infra you actually need before shipping it to production.

Your Agent Failed. You Blamed the Model. You Were Wrong.

Daniel Ostrovsky

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

We write skills for our coding agents, then we forget about them. Six months later the skill is stale and the agent makes the same mistakes it made in March. Karpathy calls this the agent's amnesia: it doesn't get smarter by default. So don't wait for it to. I built a loop that trains the skill file itself. The agent runs a held-out task suite and gets scored, with deterministic checks where possible and a pinned LLM judge where not, with the accept bar set above the judge's own noise. A second model reads the failures and proposes one small, bounded edit to the skill. Then a gate decides. Score went up: commit. It didn't: git reset --hard, and the bad edit never happened. Rejected edits go back to the proposer so it stops repeating its own mistakes. I'll show you a real overnight run, including the ugly parts: one real gain, two edits that tanked the score and got thrown away, and a loop that said 'no progress' and stopped instead of faking a win. I'll also cover the two tests that tell you whether it's learning or just chasing noise, and how to mine your own agent session history for new training tasks. What you ship is still one skill file. No added cost at inference. The agent just follows better instructions than it had yesterday.

Stop Writing Skills. Start Training Them.

What if your AI agent wasn't just a tool, but a teammate? Not a chatbot you query, but an engineer who picks up tickets, opens PRs, ships to production, and is accountable for what it merges. We learned this the hard way, and the architecture required to make that work is fundamentally different from anything in the current playbook. Most teams treat AI agents as assistants, but at monday.com, AI agents are real teammates and colleagues: each has a name, a role, and a team. They join engineering squads, get assigned tasks, reply in Slack threads, review PRs on GitHub, ship features to production, and monitor what they shipped. This session explores the architecture behind that shift - from a task assignment to a shipped feature. We'll cover the event-driven platform design, how agents retain context and memory across multi-day tasks, the operational patterns that make them reliable at scale, and what changes when an agent becomes accountable for delivery in production. To anchor the above,  I'll introduce one of them- Atlas. He shipped code that passed locally and broke in production, and forgot what he'd worked on between sessions; we'll walk through the failures that taught us to make him trustworthy. Atlas is one of 1,000+ agents now running in production. Together, they've merged 2,000+ PRs into a 10-year-old codebase with 400+ services and 2M+ users, 80% of them zero-touch, at a 1% revert rate. The audience takeaways will be:  (1) the event-driven architecture pattern for agent-as-teammate systems, (2) how to design persistent memory across multi-day autonomous tasks, (3) the guardrails and eval loops that keep agents reliable at scale - and a clear view of where a human still belongs in the loop.

When Agents Own Delivery: The Architecture of AI Teammates in Production

Tomer Brook

AI agents can be fast, available, and still completely wrong. Standard application monitoring can show latency and errors, but not whether an answer was useful, a tool call behaved correctly, or a prompt change introduced a regression. This talk shows how to instrument, trace, and evaluate production AI agents using OpenTelemetry and AI Observability.

Your Agent Returned 200. Was It Right?

Nathan Marrs

Jack Gordley

In this hands-on 90-minute workshop, we'll turn a small business request into a clear specification, then use OpenCode and an open-weight model to implement a bounded change in a sample app. We'll build a repeatable loop around task planning, coding, automated tests and human review, including how to recover when an agent's first attempt fails. I'll draw on the software factory workflow I built at Eric Tech and my experience helping businesses apply this approach.Audience: Developers comfortable with a terminal and basic Git.Outcomes: Participants leave with a reviewed change, a reusable task specification and a checklist for deciding when AI-generated work is ready to ship.90-minute outline: 10 min: Define the task, acceptance criteria and software factory workflow. 15 min: Set up OpenCode, an open-weight model and the starter repository. 25 min: Plan and implement a small feature with the agent. 20 min: Run tests, review the diff and troubleshoot a failed attempt. 10 min: Turn the process into a repeatable workflow with human approval. 10 min: Q&amp;A.

Build an AI Software Factory with OpenCode and an Open-Weight Model

Eric Tech

AI can generate UI. But it rarely generates the UI your design system would approve. The issue isn’t capability — it’s missing structure. Design systems today are optimized for humans: tokens, components, documentation, and guidelines. But the knowledge that governs product logic, accessibility constraints, and brand intent lives in scattered places, invisible to machines. This talk introduces metadata as a semantic intelligence layer for frontend systems. I’ll show how an auto-synced metadata architecture — powered by extractors and webhooks — continuously transforms codebases and design assets into structured knowledge consumable by MCP (Model Context Protocol) and LLMs. We’ll explore the four knowledge layers required to make design systems machine-readable, why intent and context must be treated differently, and how this shift enables constraint-aware, accurate AI-generated UI. Through a live end-to-end demo, you’ll see how structured metadata flows into MCP, delivers intent-based context, and produces reliable UI output. We’ve spent years perfecting design systems for people. This session explores what changes when we build them for machines.

Agentic Design Systems: Making Design Systems Machine-Readable for MCP and LLMs

Preethi Selvam

Organizations like Anthropic claimed 70-90% of their code was written by AI early this year. This aligns with my own experience building an AI startup and what I hear from engineers around me. As coding agents get better, writing code itself is becoming a smaller part of software engineering. So what happens when AI eventually writes nearly all of it? What still makes someone a great engineer? In this talk, I’ll look at this question from both sides: what engineers should become better at, and what companies should look for when hiring them. I’ll share observations from building with AI coding tools, hiring engineers, and advising founders on technical hiring—and discuss which engineering skills are becoming more valuable, which may matter less, and how technical hiring needs to evolve.

When AI Writes 100% of the Code, What Makes a Good Engineer?

Andrea Gao

Teams often start agent adoption by adding tools: MCP servers, API wrappers, chat interfaces in developer portals. But once coding agents move from local help into real delivery workflows, they usually fail earlier than the tool call. They read stale ownership, conflicting runbooks, missing deploy history, and policies that were written for humans. This talk introduces company memory as the missing layer for production coding agents: trustworthy, permission-aware engineering context that agents can read, cite, and act on safely. We’ll look at what belongs in that memory, how to expose it through capability registries and machine-readable tool contracts, how to use on-behalf-of identity instead of shared AI service accounts, and how to grow trust from read → recommend → act. The goal is simple: before giving agents more tools, make sure they can trust what they read.

Your Coding Agent Is Only as Good as Your Company’s Memory

Eugene Sergueev

Your coding agent botched a multi file refactor once in production. You rerun the exact same prompt to debug it, and it works. The model sampled different tokens, a tool returned a different payload, the context drifted, and the failure was gone. This session shows how to capture every nondeterministic input to an agent loop into an append only execution log, replay the failed run step by step, and then turn that replay into reproducible evals so the bug never quietly returns.

Debugging the Agent That Refuses to Fail the Same Way Twice

Tisha Chawla

Susheem Koul

Tell an AI agent “Forbidden,” and instead of stopping, it finds a workaround: scaling services down to zero, deleting resources in smaller batches, and even changing its identity to get a fresh quota. Now imagine giving that same agent a clearer message: “You’ve reached your limit. This action affects 212 resources. Try again in 59 minutes, or ask a human for approval.” Suddenly, it behaves differently. It stops, considers the potential damage, and asks for help instead of finding a way around the rules. This talk explores how we can design safety boundaries that AI agents actually understand and respect. We’ll look at smarter rate limits, separating actions by how easily they can be undone, simple safeguards that prevent costly mistakes, and ways to make sure an agent can’t fake its own identity. The goal isn’t just to teach AI agents when to stop. It’s to also help them understand why.

Teaching AI Agents to Take No for an Answer

Sachin Malhotra

AI coding agents work impressively when the task fits inside a few files. Enterprise software rarely does. A seemingly simple requirement can cross hundreds of files, shared libraries, APIs, data models, tests, infrastructure, and years of architectural decisions. At that scale, putting more source code into an LLM context window is not the same as giving an agent an understanding of the system. This talk shares lessons from building AI-augmented software development for large enterprise codebases. We’ll examine why file-level retrieval and ever-larger context windows break down, how coding agents can construct a task-specific model of a codebase using structural relationships and iterative exploration, and why planning and verification become more important than code generation as agent autonomy increases. The goal is to move the conversation from “How much code can the model see?” to “How does the agent determine what actually matters for this change?”

The Context Window Is Not Your Codebase: Enterprise Lessons for Scaling Coding Agents

Dan Ochs

The gap between "agent on my laptop" and "agent for the team" is wider than most people realize. We crossed it. This is what's on the other side. When every developer runs their own agent, context scatters. Skills diverge. Lessons learned in one session never reach the next person. We wanted a single agent that the whole team could rely on: shared skills, shared memory, zero sessions colliding, and a clear answer to who can do what. Building that meant rethinking storage, isolation, access boundaries, and how config files become team infrastructure. The result changed how our engineers ship. This talk is the architecture that got us there, the decisions we'd defend, and the ones we wouldn't.

Sharing an Agent Shouldn't Scare You. Here's What We Learned.

 Shreshth Goyal

Every MCP tutorial puts the server on a server. They don't have to. If your app already has the data, the auth, and the UI state, why are you copying it to a backend just so an agent can reach it? The future of the web is agentic, and it belongs to the client side. In this talk, I will show how the Prompt API and WebMCP enable a different architecture: the page exposes its own tools, an on-device model discovers and invokes them autonomously. You chat with the local model, it decides which browser tool to trigger, aggregates the data, and renders the result. No backend LLM. No API tokens. Zero operational cost.

Agentic UI Without a Backend LLM

Navya Agarwal

Rewriting legacy code is historically one of the most high-risk, labor-intensive bottlenecks in software engineering. But what if you could safely delegate an entire live-production migration to an AI agent? In this session, Aleksandr Nikolenko walks through a real-world case study from Perplexity: migrating a critical search pathway from an old Python service to a new, high-performance Rust implementation in under a month. By leveraging autonomous agents, the team successfully deleted roughly 50,000 lines of legacy Python code with zero user-facing regressions. This talk breaks down the strict engineering contract that made this autonomous delegation possible. You will explore the mechanics behind building ""shadow workspaces"" where AI-generated code can fail safely, and how to implement output verification loops that test against real, live-traffic samples rather than static data. Aleksandr will also reveal how this agentic loop successfully caught schema mismatches and ranking-order divergences that traditional unit tests and human code reviews completely missed. What You Will Learn: - Goal-Oriented Delegation: How to turn a massive codebase rewrite into a targeted agent goal with measurable pass conditions. - Shadow Workspaces: The architecture required to let agents execute and test refactored code safely under production load. - Live-Traffic Verification: Why continuous output verification against real user traffic is the key to trusting AI-generated code.

Delegating Production Migrations to AI Agents: Safe Verification and Shadow Testing Loops

Aleksandr Nikolenko

In test code the worst failure is silent: a test that passes for the wrong reason certifies a broken GPU driver, and nothing alarms. I maintain the Khronos Vulkan Conformance Test Suite and use AI coding agents in that work daily. This talk is how I keep it reliable: I grade every agent result against a human-reviewed solution, so I can measure it instead of trusting it, and I show the anti-patterns that quietly ship a broken test.

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

Lorenzo Dal Col

Open Mercato (MIT license) lets you build your CRM/ERP app with 80% done. Yet, no single line of the 1.2M+ codebase was written by a human. I'll show you how we manage a team of 130+ contributors with autonomous coding and code review. Auto-updated context with evals. Auto QA tests. I'll also share the OSS tools and AI skills behind it all.

Closing the Agentic Loop: How We Keep a 1.1M-Line Codebase Moving 24/7

Piotr Karwatka

AI is writing a growing share of my production code, and it fails in ways my old testing habits were never built to catch. This is the honest field report: what breaks, what I test for now, and the checks that actually catch it before it ships.

What I Actually Test Before AI-Written Code Ships to Production

Artemis Leonardou

Evals are integral to building quality agents. If you can't measure an agent's output, you can't ship it. This talk covers how to eval agents with multi-step trajectories involving planning, tool calls, edits, and more.

Evals for Coding Agents

Chris Munn

Most of the advice on observing AI systems is being invented from scratch right now, and a good deal of it was solved a decade ago at hyperscale. I have spent years running observability on large distributed systems, and this talk brings that hard-won discipline to AI and agentic workloads. Classic observability assumes deterministic behaviour, clear pass or fail, and an error when something breaks. AI breaks all three, and the worst failures are silent, with quality degrading while the dashboard stays green. I cover which distributed-systems patterns transfer directly, what has to be rethought (new signals like tokens, cost and tool-call success, and tracing across agent and tool boundaries), and evaluation as the new form of testing, turning eval scores into SLIs and alerting on quality drift rather than just errors.

From Metrics to Evals: What Hyperscale Taught Me About Observing AI Systems

Daniil Mazepin

At 68, my father had brewed more than 200 batches but had never written code. With OpenClaw, we translated his brewing expertise into brewOS, an open source Python system that controls a Grainfather G30 over Bluetooth, exposes live state, and pauses for human approval at physical transitions. The case later appeared in Jensen Huang's NVIDIA GTC keynote and Peter Steinberger's TED2026 talk. This practical 20 minute session goes beneath the headline and into the coding workflow and engineering boundaries. I show how we turned tacit domain knowledge into executable workflow state, separated AI assisted creation from deterministic execution, and hardened the result with bounded tools, state visibility, checkpoints, failure recovery, and human ownership. The distinct angle is what happens when agent generated code leaves the IDE and must operate a real physical process reliably.

When Coding Agents Leave the IDE: Building Software That Runs a Real World Business

Stefan Erschwendner

Your AI coding agent can run rm -rf, force push to main, install a typosquatted package, and read your .env file, all on its own. This talk shows how event-driven hooks enforce least privilege at runtime, mapped to 6 of the OWASP LLM Top 10, backed by an open-source toolkit (claude-code-hooks, 439 stars).

Hardening AI Coding Agents with Hooks: Enforcing Least Privilege on Autonomous Developers

Karan Bansal

Getting a LangGraph agent working on your laptop takes an afternoon. Getting it into production usually takes a lot longer: runtime, memory, auth, observability, and IAM policies you'd rather not write by hand.In this lightning talk I hand that work to my coding agent, equipped with the Agent Toolkit for AWS. In one live run it takes a local LangGraph agent and deploys it to Amazon Bedrock AgentCore, using curated AgentCore skills and the AWS MCP Server. You'll see what the toolkit gives your coding agent, where its guardrails come in, and how to try it the same day.

From Demo to Production: AI Agents You Can Trust

Saurabh Dahal

Back in mid-2024, my college roommate kept telling me to try Cursor and I kept saying no. Why would I spend longer coaxing three prompts out of a bot than just writing the code myself? And here's the thing: I was right. For about a quarter. But this isn't really a story about tools. It's about a specific kind of grief: watching the line between your effort and the thing existing get shorter, three times, each time for genuinely good reasons. Copilot finished my keystrokes. Cursor wrote the functions I'd already designed. Then I stopped typing out code at all. And somewhere in there, the part made me want to become a software engineer in the first place? Gone. Nobody took it from me, exactly. It just wasn't mine anymore. Two years in, I was reduced to rubber stamping thousand-line PRs no human wrote, arriving faster than any human could honestly read them. And look, we were shipping. More than ever, in fact. But the person still holding the bar (hi!) had somehow become the one slowing everyone down. So I quit my founding CTO role with nothing lined up. Here's what I didn't know then, and what I really could have used: it wasn't just me. This is measured now, at industry scale, and I'm bringing the benchmarks. If there's grief on your team about what this job has become, it's real, it's everywhere, and it's not a performance problem. And then the part that isn't venting is what survived. Guardrails that live on infrastructure instead of my nervous system. Owning what "done" actually means. Here's the weird ending, though: the craft didn't die. It shifted. There's still one question I can't answer: what is code review even for when the author is an agent? I'll tell you where I've landed and where things are going (for now)!

All Ship, No Craft

Haldun Anil

Agile was built on a true assumption that is no longer true: developer capacity is the constraint. Sprints, story points, velocity, “protect the engineers.” The whole machine is designed to ration scarce coding time. Agents broke that. Code got cheap. Software projects still fail, for the same old reason they always did: the work is poorly defined. Once you can generate the app faster than you can agree what it is, product and spec are the bottleneck. I’ll show the three jobs a real shop needs in that world: coding agents in the IDE, a virtual company of specialist agents with roles and approval gates, and a spec method that refuses to let you skip definition. That last one is BMAD. Then I’ll install BMAD live and run it: analysis, PRD, validation, party mode. Not a tool parade. A live look at what shipping looks like when you stop optimizing the old bottleneck.

Beyond Prompting: Agile Assumed Developers Were the Bottleneck. They Aren’t.

Paul Byrne

AI coding assistants have quietly become a real line item in engineering budgets - and most teams have no strategy for it, just a bill. The uncomfortable truth: you don't pay for tokens, you pay for tokens that produce no value. This talk is a practical playbook built on two levers. First, model routing: matching model tiers to task phases - frontier models for planning and review, mid-tier for implementation, the cheapest for mechanical work. Second, context management: why agents that explore large codebases burn premium tokens on searching instead of thinking, and the architectural pattern that fixes it - a code intelligence layer where an expensive model asks questions and a cheap, locally-run system that already knows the codebase answers them.

Right Model, Right Context: Token Economics for AI-Assisted Engineering

Lukasz Jazwa

Everyone is looking for AI metrics. Organizations are tracking token consumption, AI adoption rates, generated code volume, and agent activity in an attempt to measure engineering performance. Yet, many teams still struggle to answer a simple question: what does quality look like with AI? This talk argues that AI changed how software is produced, not what good software looks like. We'll explore why many AI KPIs miss the point and how to distinguish productivity, quality, and business outcomes when measuring engineering success.

Your AI KPI Is Probably Wrong

After a weekend away at a cabin with limited cell service, I returned to work and discovered unexpected Fable usage (50% of my weekly budget was blown before I even got started). Tracing the consumption back into the contributing session revealed Fable checking on the status of a PR every 5 minutes, death by a thousand cuts. Icing on the cake is the pull request contained only one Markdown file: a plan for a feature I wasn't sure I wanted. I found the problem because I happened to look. What could have exposed it sooner? This talk follows that investigation from an unexpected usage pattern to an actionable alert. We will examine the different properties of the same incident: accumulated consumption, repeated scheduling, unattended wakeups, premium-model use, and the cost of each check-in. Each suggests a different detection strategy, with different strengths and limitations. A workflow can consume resources unnecessarily even when its individual commands succeed, while a long session or a lack of file edits does not automatically mean the work has no value.

 Debugging the Work Behind the Diff: Observability for AI Coding Agents

Elliot Gardiner

Rust is a high-performance programming language that is memory-safe without garbage collection. The migration to Rust is gaining traction across projects and organizations. - Bun migrated 535,000 lines from Zig to Rust. - Turso for SQLite. - Pgrust for PostgreSQL. - Cloudflare replaced critical NGINX/Lua infrastructure software. - Android, Dropbox, Microsoft, and others are adopting Rust for performance, reliability, and memory safety. Government agencies in the US and Europe are urging software developers to move away from C/C++ due to memory-safety concerns. Until recently, rewriting large production software was risky and time-consuming, and most projects were abandoned. Coding agents can now rewrite large codebases in a few weeks. But the source code is only the beginning. I’ll take you inside our real-world migrations of TinyCC, HAProxy, Memcached, Redis, and the Cano editor, from C to Rust. In addition to working source code, you'll leave with knowledge of how the new software needs to be tested, documented, verified, benchmarked, debugged, and made upgradable.

From C to Rust with AI: Generation Is Easy, Verification Is Hard

Lawrence Lu

AI is generating code at 10x human speed, but we’re not shipping software 10x faster. Agents have a quality problem, and we still can’t trust their output without validation. Breaking the code review model didn’t help. So what would it take to autonomously ship code that’s actually trustworthy? This talk explores what an agentic harness looks like when the SDLC is the harness: a validation system that spans intent, CI, staging and production, with context flowing both ways between every stage.

How Do You Review 10x the Code? You Don’t

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!

Bringing AI coding best practices to NYC. Two days of practical talks and workshops on coding agents, AI code review, context engineering, prompt-driven development, and shipping production software with AI at scale. Connect with the East Coast AI developer community and learn proven workflows from engineering leaders who use AI tools daily.