Sessions

Your team adopted AI. Coding is measurably faster, developers are saving hours, and the dashboards look impressive. But customer delivery still hasn’t sped up nearly as much. That’s not a failure of effort or tooling. It’s arithmetic. This talk follows one feature through a real value stream: a 45.5-day lead time with just 9.5 days of actual work, which means flow efficiency is 21%. Then it runs the test everyone expects to help. Halve coding time, the part AI improves most, and lead time gets better by only about 4%, because the prioritization queue and security review stay exactly where they are. The bigger point is simple: AI compresses execution, so the bottleneck has moved. It has shifted out of writing code and into deciding what to build, coordinating across teams, governing risk, and learning from what shipped. Most teams are still measuring the part that got faster. You’ll leave with a practical lens, not a slogan: how to measure flow efficiency on one of your own initiatives, how to find where work really waits, and why adding more AI upstream of a queue changes almost nothing. This is for engineers, tech leads, and platform and DevOps folks who feel the gap between “we are faster” and “we are not shipping faster,” and want to understand where it actually comes from.

AI SRE tools are being sold as the end of the 3am page: agents that detect, diagnose, and remediate incidents before a human even wakes up. The reality on the ground is messier. This talk walks through several real production incidents where an autonomous "fix" made things worse, not better, and traces exactly where the agent's reasoning diverged from what an experienced human on-call engineer would have done. Instead of a general warning about AI risk, this is a forensic walkthrough: timeline, decision point, what the agent saw, what it did, and why it was wrong. From there, we extract concrete patterns that repeat across incidents (the agent trusted a stale signal, the agent optimized for a symptom instead of a cause, the agent had no concept of blast radius) and translate those patterns into practical design changes teams can make today: guardrails that actually hold, escalation triggers that catch agent overreach, and a way to think about "autonomy level" as a dial you tune per failure class rather than an all-or-nothing switch.

Open source has always run on a simple trust model: contributions are scarce, contributors are known, and review keeps quality high. AI broke all three assumptions at once. Maintainers are already closing the door: some projects now ban drive-by AI PRs outright. But closing the door isn't the answer. Maintainers need to prepare their repos for AI coding assistants rather than push well-meaning contributors away. This talk argues the OSS trust model needs five concrete operational changes. Provenance over identity: Review the path a change took, not just who pushed it. Patterns: signed agent attestations, PR templates that surface generation context, and CI provenance checks. Agent declaration standards: Require contributors to declare which tool generated a PR, a DCO for the agentic era. Layered triage: Automated reviewers handle style, security, and test coverage, giving contributors faster feedback and freeing maintainers for higher-order decisions. Sandboxed execution for untrusted code: Test external contributions in isolated environments so a malicious or broken PR can't poison the build cache or compromise the code. Self-healing CI: When the build breaks, an agent opens a fix PR rather than waiting for a human. Drawing on real-world experience and lessons, this session also addresses what doesn't change: code of conduct, governance, and community health matter more than ever when contributors are non-human.

AI coding agents are getting better, but might still fail if they are given the wrong context. Developers often paste raw files, random chunks, stack traces, or half the repository into an LLM and hope the model figures it out. This might not perform well for large codebases. This session shows how to build a local-first context layer for AI coding agents using Chronicle, an open-source Python SDK and MCP server. We will walk through how Chronicle prepares structured context before an LLM call using AST-indexed symbols, dependency graphs, patch-aware retrieval, call-chain context, session memory, and token-aware handoff packets. The talk includes a live demo on a real repository: starting from a code-change request, we will inspect the repo, identify impacted files and symbols, generate a compact context packet, and hand it off to an AI coding agent such as Codex, Claude, Cursor, or any MCP-compatible workflow. Attendees will learn the architecture behind context orchestration, how to reduce token waste without losing codebase relevance, and how to design inspectable, reusable context systems for AI-assisted software development. This talk is about making AI coding workflows more grounded, debuggable, and reliable. Github repo: https://github.com/animeshdutta888/chronicle/tree/main SDK with MCP integration: https://pypi.org/project/chronicle-sdk/

Every AI tutorial starts the same way: sign up for an API key, add a credit card, spin up a server. For working developers, that's friction. For students, it's a wall. This workshop skips all of that. Participants build a working AI agent in a single HTML file: streaming chat, a custom persona, multi-turn memory, and agentic tool-calling. The model runs in the browser tab. No API keys, no servers, no cloud bill. The stack is open-source: Google's Gemma 2 2B (4-bit quantized), WebLLM from MLC-AI (an OpenAI-compatible API from a single CDN import), and WebGPU for GPU-accelerated inference natively in the browser. Four hands-on phases: Phase 1 - The AI Loop (40 min): Load a quantized model, run a chat completion, add token streaming, and wire multi-turn memory. Phase 2 - Chat UI (20 min): Styled chat application with message bubbles, scroll container, and loading progress. CSS is provided so participants can focus on the JS logic. Phase 3 - Make It Yours (40 min): Custom personas, prompt engineering, then a live demo of agentic tool-calling where the model calls Wikipedia and weather APIs through structured output markers parsed and executed in a loop. Phase 4 - Ship It (15 min): Save the single HTML file and host. The WebLLM API mirrors OpenAI's chat.completions interface, so everything learned here transfers directly to cloud-hosted models. Note that every phase (1-4) includes a checkpoint file so nobody falls behind.

What if robots didn’t just react - but actually understood their world and remembered it? In this session, we explore how to build world-aware, context-driven agents using a graph-based memory layer and real-world robotics. You’ll see how users, objects, and environments can be modeled as a living digital twin, how interactions are captured as structured memory, and how agents reason over long-term context. Through a live demo, a robot recognizes returning users, recalls preferences, and adapts its behavior across sessions. This talk provides a practical blueprint for building persistent, embodied AI systems that move beyond stateless interactions.

As the web becomes increasingly global, modern UIs can no longer assume left-to-right text, fixed layout directions, or static component structures. Interfaces today must support internationalisation, RTL languages, vertical writing systems, and dynamic layouts that reflow across responsive dashboards and design systems. In this talk, we explore how Logical CSS enables a fundamentally more resilient approach to UI architecture. You’ll see how properties like margin-inline, border-block, and inline-size allow layouts and components to adapt automatically to writing direction, writing mode, and layout orientation - without duplicating styles or introducing fragile overrides. Through real-world examples, we’ll look at supporting Arabic and Hebrew, enabling vertical Japanese layouts, designing components that flip seamlessly as layouts change, and building design-system primitives that remain stable across products, regions, and use cases. We’ll also cover practical migration strategies, local testing techniques, and the mindset shift from physical directions to flow-based design. Whether you’re building a global application, maintaining a design system, or planning for the long-term evolution of your UI, this session will help you create future-proof, direction-agnostic interfaces - designed for every direction.

Every React developer knows how to open DevTools. Far fewer know which numbers to trust — and which ones are lying to you. Lighthouse scores look great in reports but don't always correlate with real user experience. Bundle size matters, but not in the way most teams optimize it. And in React Native, the JS thread can be silently killing your UX while your profiler shows green. I work on the Dynatrace React Native agent — SDK-level instrumentation that runs inside production apps across a wide range of codebases. That gives me an unusual vantage point: not just how one app performs, but what patterns consistently hurt performance across many apps, on both web and mobile. In this talk, I'll walk through the metrics that actually matter — TTI, JS thread jank, startup time, hydration cost — and show how to measure them properly using Hermes profiler, Flashlight, React DevTools, and custom instrumentation. I'll share real before/after benchmarks from web and React Native projects, and explain how to build a measurement culture in your team so performance doesn't regress the moment you stop watching. No generic advice. No "just memoize everything." Real numbers, real tools, real workflows.

As Generative AI moves from prototypes to production, prompt engineering alone is no longer enough. Developers now need a broader engineering layer around prompts, models, retrieval, tools, agents, evaluation, logging, safety checks, and observability. This session introduces Harness Engineering as a practical approach for building reliable and governed GenAI applications. Through enterprise-style architecture patterns, the talk explains how teams can add traceability, prompt/version control, metadata logging, policy checks, evaluation loops, and monitoring to GenAI systems. Attendees will leave with a practical blueprint for moving GenAI applications from experiments to production-ready systems.

Google Zanzibar is the singular authorization service that powers permissions and sharing across all Google properties, including Docs, YouTube, and Cloud IAM. Creating a consistent, global-scale authorization system that can process "more than 10 million client queries per second” is not a trivial task. The talk will cover how the paper lays out an engineer-friendly blueprint for building a highly scalable distributed system with flexible consistency guarantees. This talk will start with foundational knowledge of Relationship Based Access Control (ReBAC) and then cover the technical implementations behind Zanzibar - How Google solved for correctness, scale and speed. The presentation will cover the different APIs for interacting with the system and also a deep-dive into how the “New Enemy” problem was solved. The talk will conclude with how you an use open source tools to build authZ into your application.

In 2023, proposal reviews and cross-team alignment took about 40% of my week as an engineering manager. Today it's 70–80%. This talk is the story of what happened in between — not from headlines, but from inside a team at a major fintech — and what it means for how engineers and managers should grow from here. What I'll cover: - What actually changed in our development cycle between 2023 and 2026 — a real before/after of one team, including where the time went and which parts of the manager's job quietly automated themselves - The initiative explosion: why engineers now surface proposals that would never have existed before (an incident fix that turned into major recurring infra savings), and what that means for how ICs build careers when ideas are no longer scarce - The AI slop problem nobody budgets for: how twenty-page generated documents and AI-assisted code shift the review burden onto leads and managers — and the simple norms that fixed it for us, including "the author owns the compression, not the reviewer" - Confession of a bottleneck: how I ended up as the slowest part of my own accelerated team, and the operating-model change that followed — which decisions moved to tech leads, and which stayed with me - Tech leads as amplifiers of judgment, not just execution: what I now look for when identifying and growing leads, and why they're the real unlock behind "one manager, wider charter" - What the flattening headlines (50 engineers per manager, managers back to code) get right and wrong — grounded guidance for engineers deciding between IC and management tracks in this era or excelling in each.

Six months ago, the most critical API in our platform had p99 latency that regularly spiked into minutes. Our primary database CPU was at capacity. Customers were timing out. We were three engineers staring at dashboards full of red. This talk is the story of how we traced that meltdown to six compounding failures — and fixed all of them. Not one silver bullet, but six layers of the stack quietly making each other worse. I'll walk through each failure and the fix, with real metrics: Queries running without statement_timeout — a single slow scan holding connections for 90+ seconds while the pool starved CompletableFuture.supplyAsync() on Java's shared ForkJoinPool — blocking JDBC calls saturating 11 threads and silently losing our @ReadOnly ThreadLocal, routing every read to the primary while the replica sat idle Composite indexes on the wrong column order, dead JOINs the ORM added that the query never needed, and aggregations spilling to disk A cache miss thundering-herd that turned a cold restart into a self-inflicted DDoS For each one, I'll show the before-and-after: the EXPLAIN ANALYZE output, the thread dump, the Grafana panel. I'll demo a set of regex patterns we now run in CI to catch these anti-patterns before they reach production. You'll leave with a checklist of ten things to audit in your own Spring Boot + PostgreSQL services tonight — and the grep commands to do it.

Every team that's tried to go multi-cloud has hit the same wall: it was never really a software problem. The code was fine. What broke was the architecture. At a membership platform I worked on, a failover meant to improve reliability instead sent every customer an email about rewards and gift cards from years past — because the offset state tracking who'd already been notified didn't migrate with the failover. The result wasn't a minor bug. It was a resend to the entire consumer base, and a cost to the business in the millions. The instinct after an incident like that is to plan the "proper" multi-cloud project: a dedicated effort, estimated at a year of engineering time, to make failover state consistent across providers. That's the traditional path — and it's exactly the wrong frame. Here's the reframe: multi-cloud isn't a target you build toward. It's a side effect of a more fundamental decision — building durability-first. When state, retries, and recovery are guarantees of the execution layer rather than logic your team hand-rolls per cloud, failover stops being a year-long architecture project. With Temporal's durable execution model, what was estimated at a year became a matter of enabling replication with a single click. You'll leave with a different mental model: multi-cloud as a test of your architecture's fundamentals, not a project you fund separately.

Every production issue leaves a trace. In traditional software, it's often an another line of code. In AI systems, it's often another sentence in the prompt. Over time, these sentences become difficult to maintain. I saw this happen while building and running AI systems in production. A RAG-based agent that kept returning incorrect answers led to more prompt changes. MCP server tool descriptions become broader as new edge cases appeared. These instructions behaved differently with models and AI clients, hence more workarounds were implemented. Each change solved a problem, but together they made the system difficult to understand and maintain. I call this prompt debt. In this talk, I will explain how prompt debt builds up, why it often goes unnoticed until teams become afraid to change prompts or switch models, and why this is really a specification problem rather than a prompt engineering problem. We will start with a prompt for an AI application that works well. Then I will show how each fix adds another instruction until the prompt becomes difficult to understand and test. Finally, I will show how defining expected behavior through evaluation driven-specification makes it easier to compare models and iterate with confidence. You will leave knowing how to identify prompt debt in your own systems, decide when a prompt needs refactoring instead of another workaround. You will also have a practical framework to prevent prompts from becoming the long-term specification of your application.

Quantum Computing sounds like something only physicists with wild hair can understand. But what if we could learn it without the jargon? In this fun and beginner-friendly session, we will explore: - Qubits - Superposition - Schrodinger's cat experiment - Heisenberg uncertainty principle - Entanglement - Quantum Gates No physics degree required. Just bring your curiosity.

I have three years of experience building interfaces for AI agents, currently at Slack, where I work on agentic AI surfaces. As a developer working in this area daily, I have seen a consistent pattern: React applications that perform well under normal user interaction degrade quickly when connected to a streaming agent, where a single response can produce dozens of state updates per second. In this session, I will cover the rendering and state management challenges specific to agentic UIs, drawing from production experience and from a public benchmark I built to measure rendering strategies under real agent event streams. The session will address three areas. First, state architecture: how partial and final text differ as state shapes, why conventional Redux patterns struggle with high-frequency token streams, and what alternatives exist. Second, implementation tradeoffs: when a streaming library is justified, when a custom buffering layer is the better choice, and how primitives like useSyncExternalStore fit in. I will demonstrate these comparisons through live coding, with performance measurements for each approach. Third, standards: what the AG-UI protocol currently specifies for agent-to-UI communication, and where it leaves decisions to the implementer.

MCP demos are easy. MCP in production, multi-tenant, for tens of thousands of users, is a different sport. Connecting an MCP server takes an afternoon. Running one for real customers is where the interesting failures live. I'll cover what actually holds up under load: stateless MCP transports on serverless (why an in-memory session map quietly kills horizontal scaling, and why request/response JSON just works), OAuth 2.1 connectors with PKCE, and on-demand data stores - with real numbers from a burst test. Then the security landmines that are specific to this shape of app: a public per-tenant connector that will happily hand every customer's name, email, and phone to any anonymous caller; forgeable session cookies that also mint an OAuth token; an unauthenticated endpoint that can wipe a tenant's data; and the host-side constraints you simply cannot control - your connector's icon is your domain's favicon, and you can't pre-fill the install dialog no matter what you try. Every item comes with the fix, straight from a production readiness audit.

I say "unlock my phone and search YouTube for X" out loud. 10 physical Android phone sitting on the table does it - while an orb on screen reacts to my voice in real time. That demo has been watched over 10 million times and garnered over 300 stars on GitHub; this talk is the architecture underneath it, running live on stage. Three things had to work. First, real-time voice: a WebRTC session to a real-time speech model, where I learned the hard way that the model finishes generating well before the audio finishes playing - so an event-driven state machine gets ahead of the actual voice, and you have to drive state off the output audio itself. Second, hands: a Model Context Protocol (MCP) server bridging the voice agent to ADB and the device's accessibility tree, with fast deterministic scripted actions for the common cases and an autonomous observe-decide-act-verify loop for everything else. Third, honesty about what I built - including the moment I realised my agent's system prompt tells it to dismiss Android's own permission dialogs, and what that means for anyone thinking about shipping this. Expect real architecture, real code, live devices on stage, and a candid account of where this design is genuinely unsafe and why I drew the line where I did.

Most MCP server design advice stops at "write good tool descriptions." That advice falls apart the moment your agent has the power to break things on purpose. I own the Resilience Testing MCP at Harness, where agents drive chaos experiments against live infrastructure: killing pods, injecting latency, partitioning networks. An ambiguous tool call does not get clarified, it gets guessed, the wrong experiment runs, and the blast radius becomes a real number. This talk covers what survived and what did not: Tool granularity: why we collapsed five experiment tools into one, and the one case where splitting them back out was the right call Descriptions agents actually use correctly, shown with before-and-after tool-call traces Confirmation and dry-run patterns for destructive tools Auth and multi-tenant context isolation across agent sessions Error responses that let an agent recover instead of giving up The eval harness we run against our own server to catch regressions before they hit production Attendees leave with a checklist they can run against any MCP server they own or are about to build. This talk is for engineers already building MCP servers that touch anything destructive or stateful, not for people evaluating whether to build one. Assumes familiarity with LLM tool calling; no prior MCP experience required.

AI can help product teams generate ideas, prototypes, user stories, content and features at unprecedented speed. But what happens when that speed is applied to the wrong customer problem? This is a highly interactive product-management workshop not a lecture. Participants will work in teams to invent an AI-powered product, pitch it with excessive confidence, challenge its assumptions, receive unexpected customer evidence and decide whether to build, test, reframe or stop. Through product roasts, customer “truth bombs,” a feature-investment auction and rapid experiment design, participants will experience how AI can amplify solution-first thinking, weak discovery and feature-factory behaviour. They will then use a practical Wrong Product Faster Canvas to separate evidence from assumptions, clarify the real customer problem and design the smallest meaningful experiment before committing to development. Participants will leave with a reusable decision framework for product discovery, prioritisation and outcome-based thinking plus a memorable experience of creating, defending, killing and rebuilding a product with their peers.