Sessions

Cosine Similarity is like the social network of vectors—it measures how close two points are based on the angle between them. A 0° angle? Total BFFs, perfectly aligned. A 90° angle? Complete strangers, no common ground. It’s the secret sauce behind recommendations, NLP, and clustering, helping machines figure out who’s vibing and who’s not. Math has never been so… social.

Developer Experience, Developer Productivity, Platform Engineering, Engineering Thrive, Enablement, Developer Tools, Engineering Solutions, Productivity & Happiness - 12 different names across 17 top tech companies for what is essentially the same discipline. This fragmentation isn't just confusing - it's actively slowing down DX as a field. When Google calls it "Engineering Productivity," Microsoft calls it "Engineering Thrive," and LinkedIn calls it "Productivity & Happiness," developers can't find each other's work, share practices, or even recognize they're solving the same problems. In this lightning talk, I'll show: - The naming landscape: 12 titles for one function (data from GetDX research across Google, Microsoft, Spotify, Uber, Stripe, and others) - Why this matters: fragmentation prevents knowledge sharing and makes DX invisible as a career path - The DX vs Productivity divide: "experience" is the developer's word, "productivity" is the manager's word - and this difference shapes what gets measured and what gets fixed - A case for convergence: DX needs a brand as recognizable as DevOps or UX

Inference engineers solve a multi-dimensional puzzle across latency, throughput, and cost to serve generative AI models. Spanning interdependent layers of the serving stack, from CUDA to runtimes to containers to Kubernetes, inference engineering is the discipline behind scaling AI applications. In this session, we'll cover key inference engineering concepts across both runtime and infrastructure, including topology-aware model parallelism, prefill-decode disaggregated serving, KV-aware routing, autoscaling strategies, and multi-cluster infrastructure management, with a focus on the work required to run multi-trillion-parameter LLMs efficiently in production.

Commerce engineering spent 2026 building for the agent. UCP, ACP, AP2, MCP endpoints, Instant Checkout integrations. Meanwhile the merchant's own site, still where most revenue converts, has discovery that has not materially improved in a decade. These are treated as two roadmaps. They are one problem, and the second one is the reason the first one underdelivers. Here is the connective fact. Roughly 63% of zero-result site searches come from subjective, use-case queries: "bike for commuting", "something for a beach wedding". Around 81% of US shoppers abandon after an unsuccessful search. That query shape is exactly what an AI agent sends you. If your own search cannot answer it, neither can the agent, and no payment protocol fixes that. Meanwhile Adobe finds product pages are the least machine-readable surface on the average retail site at 66%, worse than the FAQ page, while AI-referred traffic converts 54% better than non-AI traffic and grew 693% year over year over the 2025 holiday. This session makes the case for 360 degree discovery: every surface a human or machine can find a product through, served from one product layer. I will walk the four things it requires: universal agentic feed deployment as table stakes rather than strategy; clean and enriched product data as the foundation everything else silently depends on; three search surfaces rather than one; and visualization, including virtual try-on, as the step that converts finding into buying. Plus the nine-week triage: what is realistically shippable before holiday freeze and what is not.

As agents increase the velocity at which code gets written, platforms get modified, and documentation gets updated, the things teams rely on can change faster than any human can track, validate, or understand. Call it Agentic Drift. Agentic Drift shows up as pipelines failing at increasing frequency, vulnerability counts creeping upward, internal tools that have quietly evolved away from their original intent, and documentation that no longer reflects how a system actually works. Teams are already experiencing it but the frameworks for managing it are still emerging. This talk introduces Agentic Drift and how to solve it. Drawing on experience building and operating developer platforms alongside AI agents, we'll cover: - how to detect drift using signals your team already has: CI/CD pipelines, observability tools, security scanners, and end-user feedback - how to design remediation pathways that fit your team's risk tolerance, from triggered reviews to continuous validation - a model for keeping humans meaningfully in the loop without becoming a bottleneck to the velocity agents provide The future of software engineering is about more than what agents can build. We also need to design teams and systems to keep pace with these changes.

Between February 2025 and February 2026, coding agents went from writing none of Clipboard's code to nearly all of it. That changed our bottleneck. Writing code got cheap, but proving it worked did not. The failure mode was not just model quality. It was flaky E2E tests in shared environments that were hard to reproduce. With limited context, agents often reached for the wrong fix: increase the timeout or add a retry. This talk is a practical case study in rebuilding trust in tests for AI-heavy engineering organizations. I will show the workflow that helped us reduce the share of PRs affected by E2E flakes from 100% to under 15% in six weeks, including the open source libraries and agent skills we built to classify flaky tests, connect to observability signals, and decide which tests to harden, delete, quarantine, or move down the pyramid. Attendees will leave with a repeatable playbook for making coding agents safe to use at scale without teaching them that every failing test should be "fixed" with retries.

Every production agent today is renting its intelligence. You're paying per token, sending your customer's data to someone else's servers, and hoping the provider doesn't rate-limit you during your launch. For most teams, that's fine. But for a growing number of teams in regulated industries, with high-volume products, latency-sensitive workloads, or rising token bills, it's starting to look like a liability. In this 120-minute hands-on workshop you'll get a dedicated GPU and build an agent that runs on infrastructure you control. You'll stand up vLLM, point your agent at it, and drive concurrent load through the stack until you can see batching, KV cache pressure, and throughput limits in the metrics. Then you'll optimize the deployment to improve throughput while keeping per-request latency in line. The focus isn't agent frameworks. It's the inference layer underneath them. You'll leave with working code and a real understanding of continuous batching under real concurrency, KV cache tradeoffs, vLLM's metrics, and the bottlenecks that only show up when you operate the inference server yourself.

The industry has poured billions into LLMs and AI agents, yet many deployments stall in pilot because they lack one thing: fresh context. If your AI agent is reasoning over stale batch data or fragmented profiles, it cannot deliver real enterprise value. The missing piece isn't a bigger model, it's a real-time context engine: a streaming feature store that supplies an up-to-the-second 360° view of the customer, and that actively notifies agents when something they care about changes. This session walks through how we built exactly that at Intuit. The Customer Data Cloud platform ingests data from hundreds of sources, processes data through config-driven Apache Flink pipelines, maintains unified profiles in a low-latency NoSQL store, and serves them via a GraphQL Read API. But the story doesn't end with the read path, every profile update publishes a real-time change notification on Kafka, which forms the backbone of an event-driven AI loop: agents and automation systems subscribe, react to changes the moment they happen, and drive in-product personalization and marketing workflows in real time. We'll cover three ideas developers can take home: * Context over Models: Why a streaming 360° view of the customer matters more than the specific LLM you pick — and how to architect for it. * The Event-Driven AI Loop: Using Kafka change notifications as triggers for autonomous agentic workflows. * Privacy-by-Design in the Stream. Enforcing user consent and asset-based access inside the streaming fabric itself, so compliance is a property of the data, not a layer bolted on top. Expect architecture diagrams, concrete Flink-pipeline patterns, a live walkthrough of a change notification firing an agent, and the honest lessons from operating this in production at Intuit's scale.

LIttle is known about the history of Neural Networks e.g. "Artificial Intelligence." The history goes back to around 1946 when researchers noticed that the mathematics involved with linear algebra wherein materials were stretched that the neighboring atoms were affected, was best modeled with a branch of Math known as tensors. Tensors are used today to create neural networks. Neural networks are run on a powerful Graphics Processing Unit (GPU.) GPUs came about because of video games and entertainment thus we can say that video games laid the groundwork for AI.

Artificial Intelligence (AI) now drives decisions across enterprise operations, for autonomous systems—yet much of this decision-making remains a “black box.” AI Decision Observability is an emerging paradigm that transforms opaque model behavior into traceable, explainable, and auditable decision pathways. This session introduces a unified framework that combines AI Decision Observability with Decision Intelligence—linking how decisions are made, measured, and improved across human-AI systems. Building on our AI Decision Automation Framework, we explore the technical and organizational capabilities required to move from decision outputs to decision systems: continuous, observable pipelines where every inference, rule, and outcome can be traced back to its origin. We discuss key methodologies—comprehensive logging, data and model lineage tracing, model introspection, counterfactual and causal analysis—and how these integrate into enterprise observability stacks. The session also showcases tools and architectures that operationalize observability, alongside real-world case studies from regulated domains like finance, healthcare, and autonomous mobility. We’ll conclude with a forward-looking view on how Decision Observability fuels Decision Intelligence—enabling enterprises to build trusted, adaptive, and compliant AI ecosystems where decisions are not just made but understood, improved, and governed. Key Takeaways: How to architect AI systems for full decision traceability and governance Integrating Decision Intelligence with AI Decision Observability for continuous learning Practical frameworks for scaling decision transparency and automation across the enterprise

The honeymoon phase of AI is over. Organizations across all industries have spent the last two years buying licenses and experimenting, but boards and CFOs in the 2026 fiscal year are demanding proof of value. For CTOs and VPs of Engineering, the challenge has shifted from "how do we build this?" to a critical fiscal responsibility: showing a measurable return on AI investment. The bottleneck isn't the model; it’s the middleware of the human process. Too many organizations are automating tasks (AI-Augmented) while leaving the topology of their engineering organizations untouched. To capture true ROI, we must shift to AI-Native Engineering, where the SDLC is architected around probabilistic capabilities rather than deterministic checklists. In this session, Manu will help teams learn how to move past "productivity vibes" and into measurable ROI. Manu will break down the “Efficiency Trap”: the phenomenon where AI generates code faster, but testing, security, and deployment bottlenecks remain static, resulting in zero net gain in system throughput. Additionally, Manu will present a framework for evaluating ROI at every stage of the product lifecycle and show attendees how they can move their metrics from "PRs per day" to "Outcome Velocity", in short, reduce the “Lead Time to Value.” The 4-Stage ROI Lifecycle - Discovery (The Intent Stage): ROI of using AI to bridge the "Context Gap" between Product, Design and Engineering. - Development (The Build/Composition Stage): Measuring "Unit Cost of Code" to ensure high-velocity output doesn't increase downstream maintenance costs. - Verification (The Quality Stage): ROI of shifting from manual QA to "Automated Eval" stacks. - Operations (The Resilience Stage): The financial impact of AI-driven observability, self-healing systems, and the automation of the Support-to-Engineering feedback loop.

Modern AI systems are incredibly capable and confidently wrong. In this talk, we explore a new architectural pattern: AI systems that argue with themselves. By orchestrating multiple AI agents with opposing perspectives, we can uncover hidden bugs, reduce hallucinations, and dramatically improve output quality without adding human reviewers to the loop. I’ll demonstrate how to design and implement a self-debating AI system using real-world examples: debugging code, validating architectural decisions, and stress-testing product requirements. We’ll explore when AI disagreement is useful, when it fails, and how to measure improvement beyond “it feels better.”

With the arrival of Mythos and other frontier models we enter a new world. They can find security issues in libraries, create individual exploits, and successfully chain them to real-world attack campaigns in 2026. The open source ecosystem is on the verge of something new. What happens next is terrifying and exciting at the same time. At Chainguard we started a coalition with many partners across governments, banks and other large corporations, foundations, and open source communities to use the tools to strengthen our defenses against attackers. We established trust and infrastructure to share exploits, create patches, and bring them to use as binaries. Just in our first weeks we processed over thousands of findings, created well over 1k patches, and touched the code base of hundreds of open source projects. Now it is a few months later, and Manfred will share our experience from working within and outside the project. We will talk about good findings, bad patches, and ugly consequences alike, and dive into the details of examples and our collaboration with open source projects, communities, and their users. Manfred will also talk about the machinery behind the scenes that enables patching at the necessary scale - Chainguard Factory, powered by our open source agentic framework DriftlessAF, and expert engineers assisted by powerful AI models.

Level: Beginner to Intermediate Skills: Leverage AI to extract structured API vocabulary, generate OpenAPI documentation, create human-readable docs, assess security policies, and automate API test script generation and validation. This workshop teaches you how to leverage AI tools like ChatGPT, Claude, Gemini, etc. to optimize the design, documentation, and testing of web APIs. As AI becomes increasingly crucial in software development, this course will equip you to integrate AI-assisted automation into human-driven API design. By the end of the course, you will be able to leverage AI to generate structured API documentation, automate security profiling, and produce comprehensive API test scripts, significantly improving efficiency and accuracy. Participants will see real-world exercises, including AI-assisted vocabulary extraction, OpenAPI generation, and automated test scripting, to gain practical experience in AI-powered API development.

Modern software systems generate incident noise at a volume that overwhelms traditional on-call rotations. In this talk, I will describe how a well designed fleet of GenAI agents are connected to live operational tooling via the Model Context Protocol (MCP) to automate the triage, enrichment, and routing of production incidents at scale. The agentic pipeline classifies and deduplicates incoming alerts, autonomously queries observability platforms, runbooks, and dependency graphs to build context, and routes incidents to the right team with a proposed remediation path. The lessons learned from operating in production, including how to handle low-confidence decisions, maintain human-in-the-loop escalation paths, and measure reliability against ground-truth data, alongside results showing meaningful reductions in mean time to acknowledge (MTTA) and alert fatigue across on-call rotations.

Many people working in AI today skip the math. However, mathematics is one of the most important skill sets for anyone building AI systems. AI models, such as LLMs, are mathematical models, and understanding their structure is key to unlocking their strengths and applying them effectively to your projects. And you don’t need a PhD in mathematics. The math for AI is actually just a few core concepts, and I’m going to break them down for you and present them in an easy-to-learn way using my multimodal learning style. In this session you will learn how to think mathematically about AI so you can cut through the hype and understand what models can (and can’t) do. You’ll leave with the most critical foundational skill in AI today, mathematical intuition, and the ability to translate between math, code, and real-world AI behavior so you can build effective, scalable AI systems that can survive any bubble.

Every LLM API call looks simple on the surface. But under the hood, it’s a deeply layered systems problem spanning kernels, compilers, GPU scheduling, and distributed inference infrastructure. In this session, Dan Fu, VP of Kernels at Together AI, breaks down what actually happens when a request hits a modern AI model—and how inference performance is ultimately determined. He walks through the full inference stack, from tokenization and model execution to GPU kernel dispatch, memory movement, and serving-time orchestration, highlighting where inefficiencies accumulate and why today’s systems operate far below theoretical hardware capability. Drawing on both cutting-edge systems research and production-scale infrastructure experience—including foundational work like FlashAttention, now widely adopted across the AI ecosystem—Dan unpacks the core bottlenecks in modern inference stacks. He also outlines where the largest efficiency gains are still available, and why kernel-level optimization is becoming a critical lever in scaling AI systems.

Let's be honest: many of our so-called "REST" APIs aren't REST. They're just JSON-RPC over HTTP, with versioning challenges, brittle integrations, clumsy error handling, and a maintenance burden we all know too well. Let's do something about this! We’ll go straight to the patterns that matter in production, tackling the real-world challenges head-on: building evolvable versioning strategies, designing sane error responses, providing clear API contracts, and demystifying the practical use of hypermedia (HATEOAS). You'll leave with practical, battle-tested approaches for building APIs that are maintainable and scalable. We'll also discuss when to use REST and when alternatives like GraphQL or gRPC are a better tool for the job. All demos use Jakarta EE and MicroProfile, but the patterns can be applied to any modern web stack of your choosing.

First we optimized for UX, then DX, and now there's AX - the Agent Experience crashing the party. AI assistants are increasingly showing up to use our apps, and right now most of them get in by screenshotting the DOM and guessing where to click. There's a better way. WebMCP lets your Angular app hand agents a clean set of callable tools, and A2UI lets agents hand back real, reactive UI instead of another wall of chat text. In this session we'll architect an Angular app for this shiny (and slightly experimental) new world. We'll walk through the modes of agent interaction, from quiet background data retrieval to rich, agent-generated interfaces, and look at a few ways to wire WebMCP into Angular through navigator.modelContext. Then we'll bring in A2UI so agents can return reactive component trees that your app renders natively, with your styling and accessibility along for the ride. You'll leave knowing how to register tools, render agent-driven UI, and start thinking about your app's tool surface alongside its visual one. You'll also get a clear-eyed sense of what's production-ready today and what's still gloriously bleeding-edge.

This session explores an attack vector, homoglyph-based attacks, that effectively evades state-of-the-art AI-generated text detectors. We'll begin by explaining the idea behind homoglyphs, characters that look similar but are encoded differently. You'll learn how these can be used to manipulate tokenization and evade detection systems. We'll cover the mechanisms of how homoglyphs alter text representation, discuss their impact on existing LLM detectors, present a comprehensive evaluation of their effectiveness against various detection methods, and see how we can protect detectors against these attacks. Join us for an immersive exploration and stay ahead of evolving threats!

Efficiently managing compute capacity is a multi-dimensional optimization problem that has outpaced human-in-the-loop systems. This presentation details the development of an agentic ecosystem used to optimize Meta’s global infrastructure. We delve into the design of tooling that identifies inefficiencies in workload placement and resource allocation, utilizing AI agents to execute complex rebalancing tasks autonomously. We will share the results of these implementations, specifically how we recouped tens of megawatts of power and the lessons learned in building trust in autonomous infrastructure tools.

Coding agents like Claude struggle to get meaningful information from databases. Even though they're good at writing correct SQL, they fall short where it matters - fetching the right answers. When asked a complex question, they consistently fumble their way through the schema catalogs and table descriptions, and then make best-guesses about how to join them, hoping to find some data that looks reasonable. The reason for this is simple - they don't know your domain. It's like hiring an expert in database syntax and expecting them to know how your company works. The solution is equally simple - teach the agent what the data means. Give them a guide to how your database is laid out, how its joined, what column names mean and what kind of queries make sense. All the folk knowledge that that expert hire would eventually acquire in their first 6 months. The technique for teaching agents the meaning of a schema is called a semantic model, there's an open standard that's easy to stick to, and the results are pretty terrific. A single file can take an agent from burning tokens to hallucinate an answer, to one-shotting the correct results. In this talk we'll go through the details of semantic models and the standard, why it's worth using the standard rather than rolling your own, and techniques for creating effective semantic models quickly. All in the service of a simple outcome - making a scalable database analyst that's effective from day one.

Artificial Intelligence is rapidly reshaping how digital products are conceived, designed, and delivered. Yet the most transformative innovation is not driven by AI alone, it emerges from the effective orchestration of human expertise and machine intelligence. Drawing on product leadership experience across global technology organizations including Google, DocuSign, and Coinbase, this session explores how leading companies are integrating AI into product development workflows to accelerate innovation while preserving human judgment, creativity, and strategic decision-making. Attendees will learn how AI is transforming engineering, product management, research, and operational processes; where human leadership remains indispensable; and how organizations can build scalable systems that maximize the strengths of both people and AI. The talk will also examine the emerging paradigm of human-AI collaboration, where AI automates routine and data-intensive tasks, enabling teams to focus on customer understanding, product strategy, cross-functional alignment, and high-impact decisions. Key Takeaways Understand how AI is reshaping the product development lifecycle, from ideation to launch. Learn practical frameworks for integrating AI into product, engineering, and operational workflows. Identify which product development activities are best suited for AI augmentation versus human leadership. Discover how leading technology organizations are balancing automation with creativity, judgment, and accountability. Explore strategies for building high-performing teams that leverage AI to increase speed, quality, and innovation. Gain insights into the future of product leadership in an increasingly AI-enabled world.

Ads Manager powers 84% of Meta's Ads Revenue, but its decade-old codebase was stuck on React class components — blocking modern patterns like hooks, Relay, and React Compiler. Manual migration of 10k+ components class to functional component was impractical. In this talk, I'll show how we built an AI codemod pipeline using LLMs that achieved a 5x speedup, migrating 3k+ components with a 99.6% success rate. I'll cover the tradeoffs between AST and AI codemods, how to classify components by complexity for targeted prompts, and the grading/eval strategies that made non-deterministic AI agents production-ready.

The software development paradigm is shifting, moving AI from a helpful suggestion engine to a collaborative partner. This hands-on session is designed for developers ready to elevate their workflow by integrating powerful AI Command Line Interface (CLI) tools directly into their pair-programming sessions. We will conduct a live comparison of leading tools, specifically focusing on Google Gemini, Anthropic's Claude Code, and OpenAI Codex (or similar contemporary offerings), demonstrating how they act as reliable, functional counterparts—not just code generators. Attendees will see detailed, real-world examples outlining: How to structure effective prompts for complex, multi-step tasks. Deep dives into capabilities like codebase summarization, targeted refactoring, and test generation. Identifying and mitigating common issues like context drift and tool-specific latency limitations. Critically, we emphasize that this is not about "vibe coding"—mindlessly accepting AI suggestions—but about adopting a structured, professional, and efficient way to develop.

Bluesky is a decentralized social media application built on top of the AT Protocol. One way that Bluesky supports decentralization, and empowers users in the Atmosphere community to run their own unique AT apps, is through open source moderation tools. We do this through two primary parts of our stack: *Osprey*, an event stream decisions engine and analysis UI designed to investigate and take automatic action; and *Ozone*, a labeling service and web frontend for making moderation decisions. Osprey is written in Python, and was designed and open sourced in collaboration with Discord. Osprey is a library for processing actions through human written rules and outputting labels, webhooks back to an API and other sinks. It evaluates events using structured logic, user-defined functions, and external signals to assign labels, verdicts, and actions. Some of these, such as our Toxrank model for toxicity detection, make use of fine-tuned LLMs and other classifiers that expose their own web endpoints to Osprey. We also utilize image OCR and hashing to create actionable moderation metadata, which can be automatically actioned, surfaced to moderators via Ozone, and in turn helps shape our Discover feed algorithms. Although some of our internal heuristics are private, Osprey and Ozone are designed to be deployed and run by other app hosts with their own custom rules and moderation practices, whether they are reimplementing the Bluesky Lexicon and feature set or running a different kind of Atmosphere app with a different set of content. In this talk, you’ll see a demo of both applications, learn about our rules engine and other architectural features, and leave with enough knowledge to integrate our open source moderation tools into your own stack.

At Intuit, 5,000+ services run at peak 1M+ TPS across TurboTax, QuickBooks, Credit Karma, and Mailchimp. Eighty percent are multi-region. Before EWOK — our Ecosystem Wide Orchestrator Kit — disaster recovery meant thousands of non-standard DR scripts, per-team runbooks, and 8,000+ engineers each solving the same problems differently. Game days were feared. MTTR was unpredictable. DR was treated as "the database snapshot" — not the full stack. This talk is the story of how we made regional failover boring — predictable, repeatable, automated, no heroics. I will walk through the architecture and the hard lessons: • A declarative YAML DSL for DR plans — stages, parallel blocks, per-stage agent versioning (armador/v1, database/v1, route53/v1), inline IAM role assumption. • AWS Step Functions as the DAG orchestrator — durable state for long-running promotions (Aurora global cluster failover, Redis replication switch), and a visual audit log that doubles as the incident timeline. • A Golang control plane on Kubernetes running goroutine-parallel mutations across thousands of namespaces. • A Python Agent Framework with an ABC contract — PreCheck, Failover, PostCheck — encapsulating IAM, logging, metrics. Product teams shipped a Redis agent in days without platform bottleneck. • Specialized agents per layer: armador (compute/capacity), Route53 (DNS cutover), Database (Aurora global failover), Redis (flush + replication). • The multi-workload problem everyone skips — cron jobs, async consumers, stateful tiers, caches. Parallel suspend, scale, resume, dial. • Progressive Dial — incremental traffic shift with error-gated automatic rollback. • Auto Failover via our Alert2Incident framework. • Same machinery for migrations — same-region failover as an upgrade feature. You leave with: concrete patterns for declarative DR, a replicable agent contract for inner-sourcing reliability, and a checklist of the workload types your DR plan probably does not cover yet.

Quality is a function of iteration. Expo has become the standard for cross platform application development because it accelerates the process of building, distributing, and deploying your applications. And we just made that iteration cycle exponentially faster. With the introduction of Echo, you can now use your preferred coding assistant to prompt beautiful, cutting edge apps into existence from the palm of your hand. In this talk I'll explain what the modern application development experience can look like and why there will be more, better apps because of it.

Trust in technology is declining at the very moment AI systems are becoming more embedded in daily life. Restoring that trust requires more than transparency reports or policy frameworks. It requires product decisions that give people real agency. In this keynote, Ajit Varma shares what it takes to build products that give agency back to users — technically, commercially, and structurally. From modular AI architecture to maintaining engine independence in a Chromium-dominated ecosystem, he will unpack what's behind “the internet on your own terms.”

At many companies right now, the directive is coming from the top: "We need AI in our product." CTOs hear it from boards. Product leaders hear it from executives. Engineering teams hear it from everyone. In this full-day, hands-on masterclass, you'll learn how to build 10 AI features that deliver real value by automating the work your users aren't good at or don't want to do. We'll build things like semantic search that finds results based on meaning instead of keywords, RAG that answers questions over your own content, and extraction that turns messy input into clean structured data. We'll do summarization that cuts long content down to something manageable, classification and routing that triages work on its own, and sentiment detection that tells you when a specialized model beats a general one. You'll see implementation patterns where a human stays in the loop, anomaly detection that surfaces issues, and recommendations that suggest the next right step. And we'll finish with agentic workflows, where a plain-language request becomes a real sequence of actions your app carries out. Most importantly, we'll explore how the real question isn't "where can we add AI?" but "what problems can AI best solve for my users?" You'll leave with practical examples and hands-on experience of where AI might belong in your product and insight into how to explain those decisions to leadership. No prior AI or ML experience is required. Basic software development experience is recommended.

Join me to get up to speed to the right-now in the brave new world of Generative AI for an accessible Zero to... Hero (in training) and look beyond the story the major cloud vendors promote. In four segments we aim to grasp the current state of Generative AI from a hands-on perspective with an independent mindset. Segment 1: Foundations - Concepts and APIs. Together we are tracing the steps on the journey to today's models and how to interact with them. You will learn about the lifecycle of a model from "pre-training" to the models that you finally get to interact with including what's in the model or what's rather an abstracted away PaaS offering on top and what building blocks you work with in the APIs and SDKs Segment 2: Integrating AI Focusing on how to enable your applications, we are looking at the various concepts such as embedding vectors, RAG, tool-calls, skills, plugins, frameworks, to help with that. We will discuss engineering context, how to work with larger documents and content sources to make them accessible by AI models with a mix of technologies. Segment 3: The world of agents Starting with very simple agents, we will effectively leverage AI in an agentic world, meaning, how to have agents do work for you, up to deploying larger teams of agents on complex tasks. This segment description is intentional vague as there is rapid innovation in this space. Segment 4: Local AI, media content, and AI beyond the Western corporate world You may prefer to run AI locally on your own devices. Utilizing tools such as ollama, LM Studio, Azure AI Foundry Local, and other alternatives, we aim to make them accessible to your apps. We explore the wild model zoo that becomes available by going beyond the big cloud vendors including generating images, video, speech, music, more. Some extra attention is awarded to tools from Chinese AI labs and how you can mix-and-match different capabilities for interesting workflows.

Artificial intelligence is evolving faster than any individual engineer, or engineering team can keep up alone. The organizations building the next generation of AI products won't simply have the best models; they'll be the teams that learn, adapt, and share knowledge the fastest. Developer communities have evolved far beyond networking events. Today, they serve as distributed knowledge networks where engineers exchange production lessons, validate emerging technologies, explore new AI frameworks, contribute to open source, and bring those insights back into their teams and organizations. In this session, I'll share practical lessons from helping grow, lead, and advise one of North America's largest developer meetup communities while engaging with engineers, researchers, founders, and technical leaders across the rapidly evolving AI ecosystem. We'll examine recurring engineering themes shaping modern AI: including agentic AI, open-weight models, AI infrastructure, developer tooling, evaluation, and engineering collaboration and explore how communities accelerate the adoption of these technologies. Attendees will leave with a practical framework for leveraging developer communities as a strategic advantage: accelerating technical learning, improving engineering collaboration, strengthening innovation, expanding professional networks, and helping both engineers and organizations adapt more quickly in the AI era.

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.

This session shows how to build a .NET application that lets users generate reports simply by chatting. I’ll walk through my hands-on experience that reads your database schema, understands user intent, creates secure SQL queries, executes them, and exports results to Excel and charts automatically. You’ll see how LLMs can deliver real value in everyday enterprise apps, how to handle schema discovery, query validation, and prompt design, and how to create an intuitive UX for both developers and non-technical users. Attendees will leave with practical patterns, architectural guidance, and code examples they can apply immediately to bring natural-language data access into their own systems.

As enterprises increasingly look to combine data with partners, suppliers, and platforms to power AI, analytics, and personalization — without exposing raw records or violating privacy regulations — Clean Rooms have moved from an emerging concept to a serious architectural option. But most teams encounter them first through vendor documentation and demos that skip the hard parts. This session starts from first principles. It explains the core problem Clean Rooms solve: enabling joint computation across datasets from multiple parties without any party accessing the other's raw data. It then walks through the architectural building blocks — controlled computation environments, output restrictions, access control policies, and the cryptographic boundaries that make privacy guarantees enforceable — and shows how these concepts translate into real design decisions. From there, the session takes an honest look at the implementation landscape. Attendees will understand how Clean Rooms compare to alternative privacy-enhancing approaches — federated learning, differential privacy, synthetic data, and contractual anonymization — and the trade-offs each involves across privacy strength, latency, operational complexity, and regulatory defensibility. The session also covers where production complexity tends to concentrate: access control configuration, output data governance, deployment automation, and integration with AI and ML workloads. Attendees leave with a clear mental model for evaluating Clean Rooms against their own organization's data collaboration challenges, a practical understanding of the architectural patterns involved, and an honest view of what separates a well-designed Clean Rooms implementation from one that looks good in a proof of concept but struggles in production.

AI agents are moving to production, revealing a "visibility gap" traditional monitoring can’t bridge. This talk shares lessons from shipping agentic AI in safety-critical workflows where agents reason, plan, and execute actions. We’ll explore building observable systems that provide high signal telemetry into non-deterministic decision making. We’ll examine production agent architecture, combining LLMs with structured reasoning and guardrails, and how to instrument test time compute to track iterative refinement. The session covers designing interoperable tool interfaces that emit rich execution traces, orchestrating specialized agents with reliable handoffs, and building auto-correction loops that parse feedback to adapt in real-time. Finally, we address evaluation, why traditional metrics fail and how to design domain aware benchmarks that treat reasoning traces as a first class observability primitive. Drawing from production deployments, we’ll discuss how observability helps agents uncover system issues missed by humans and why the future of software depends on agent native infrastructure.

Every agent demo ends the same way: the agent does the thing, the audience claps, nobody asks what happened to the security review. I didn't just theorize about codifying trade-offs. I built an open-source multi-agent system that does it. Git-Ape (github.com/Azure/git-ape) is a platform engineering framework where specialized agents plan, validate, and deploy Azure infrastructure — and where nothing reaches production without passing through explicit guardrails enforced by the system itself. Here's how it actually works. A requirements gatherer agent interviews the human. A template generator produces infrastructure-as-code. Then, before anyone confirms anything, a security analyzer runs a blocking gate — deployment is structurally impossible until issues are resolved. A cost estimator prices the deployment so humans confirm with real numbers, not vibes. A Principal Architect agent runs a Well-Architected Framework review across all five pillars. Only after all of that does a human see the full picture and explicitly approve. After deployment, a drift detector closes the evidence loop: did what we deployed stay the way we deployed it? The key insight isn't that we added checks. It's that we made trade-offs consumable by agents. Security policy isn't a PDF — it's policy-as-code that agents evaluate natively. Cost thresholds aren't guidelines — they're hard constraints. Compliance isn't an audit you do later — it's a gate you pass through now. I'll walk through the architecture, the failures that shaped it, and the design principles that transfer to any multi-agent system where the stakes are real. If your agents can deploy but can't be told no, you don't have guardrails. You have a demo.

In the rapidly evolving landscape of computing, Graphics Processing Units (GPUs), Language Processing Units (LPUs), and Tensor Processing Units (TPUs) play pivotal roles in accelerating complex tasks, particularly in machine learning and artificial intelligence. GPUs are renowned for their parallel processing capabilities, making them ideal for rendering graphics and handling large datasets. LPUs are specialized for optimizing natural language processing tasks, enhancing efficiency in understanding and generating human language. TPUs, developed by Google, are tailored specifically for training and inference of machine learning models, offering significant performance advantages for large-scale AI applications. As we explore these technologies, we'll also look at emerging processing units designed for specific AI use-cases and the future of computational advancements. Join me to dive into the intricacies of these processing units, their applications, and what lies ahead in the world of computing technology.

When agents fail, it’s rarely because the model is weak, it’s because the context is weak. LLMs behave like pure functions: what goes in determines what comes out. That makes context the true battleground, and mastery of it a form of kung fu. Context Engineering Kung Fu is about developing precision, restraint, and control over what a model sees. This session goes teaches the fundamentals: how to write clean instructions, select only what matters, compress information without losing force, and isolate signals so they don’t interfere with each other. You’ll learn how context decays over time, why bloated prompts make agents slower and less reliable, and how to recognize when a model is overwhelmed rather than underpowered. We’ll also cover advanced techniques: when memory strengthens an agent and when it quietly sabotages one, how to structure context so it remains stable under iteration, and how to break complex problems into smaller, deliberate moves that models can execute with confidence.

Context Engineering is the art of shaping what an AI model knows at any moment by managing how information enters, persists, or fades from its working memory. In this session, we explore how machine learning systems “remember” through state objects, notes, and retrieval—and how they “forget” using compression, selection, and context limits. We’ll walk through real-world agent patterns that balance personalization with privacy, performance, and relevance. Participants will learn practical techniques to design memory that feels intentional, evolving, and human-aware.

Engineering culture is easy to talk about. It's much harder to carry it across seed-stage scrappiness, enterprise at scale, and an industry being restructured by AI—without losing what made the team good in the first place. That's the lived experience Thanos Baskous brings to this talk. Thanos has led engineering in some of the most demanding environments in tech: infrastructure at Coinbase during a critical growth period, Chief Architect at Blackstone where he led a company-wide DevOps transformation, and engineering roles at Twitter. Today he's Co-Founder and VP of Engineering at Cogent Security, an AI-native vulnerability management platform that raised a $42M Series A six months after launch. Each of those environments asked the same question in a different way: how do you build a team culture that's durable enough to survive scale, honest enough to survive pressure, and flexible enough to survive a complete rethinking of how software gets built? In this session, Thanos will share what worked, and what broke, as he moved between hypergrowth startups, enterprise transformation programs, and the current shift to AI-native engineering. He'll get into the specific moments where culture either compounds or cracks: when you're scaling headcount faster than your processes, when AI tooling starts to blur the line between junior and senior, and when the team's identity is tied to practices that may not survive the next few months. This won't be a framework talk. Engineering leaders will walk out with actionable tactics addressing the one variable that determines whether a team scales or stalls: leadership.

We are entering a new era where AI agents are first-class users of data infrastructure. These systems don’t behave like traditional applications. They operate in loops, branch workflows continuously, retry autonomously, and demand immediate access to real data. The result? A fundamental shift in how databases must be designed and operated. In this talk, we’ll explore how agentic workloads are redefining database requirements, from latency expectations to isolation models, access control, and data privacy. We’ll look at why traditional staging environments and replication strategies struggle under this new pressure and how emerging patterns like copy-on-write branching and ephemeral environments change the game. If you build backend systems, data platforms, or AI-driven applications, this talk will help you understand what “agent-ready” really means and how to design for it.

We've taught LangChain and LangGraph multi-agent workshops at Grace Hopper two years running to 200+ developers each time. The number one question we get after every session: "This works in a demo — but how do I get past the walls when I try to scale it?" We know those walls firsthand. We've built agentic AI systems across POCs and production in global banking — and between us, we've hit every failure mode: agents losing context mid-task, orchestration logic that doesn't survive real workloads, and delegation patterns that look clean on a whiteboard but collapse under pressure. DeepAgents is a new LangChain framework built to solve exactly these problems — intelligent delegation, advanced planning, robust context preservation, and error recovery designed for production-grade workflows. In this 120-minute hands-on workshop, we'll build a real multi-agent system together in GitHub Codespaces — no setup, no installs, just code. Through guided labs, you'll architect a coordinator that delegates research to one agent, analysis to another, and synthesis to a third. You'll implement human-in-the-loop approval gates, long-term memory, and the error recovery patterns that separate prototypes from systems that survive production. We'll be honest about what's battle-tested and what's cutting-edge — because that's the conversation practitioners actually need. What you'll walk away with: a portfolio-ready multi-agent system you built yourself, production skills across backends, subagents, coordinators, memory, and debugging, a complete code repository with reusable templates and documentation you can extend immediately, and the framework decision-making to know when LangChain chains, LangGraph, or DeepAgents is the right tool for your problem. Bring a GitHub account and a browser. Leave with production-tested patterns.

AI agents are now your APIs' biggest, weirdest consumers. They call 100x more often than humans, hallucinate parameters, retry on every ambiguity, fish your schema for tools you did not advertise, and read your error messages as prompts. Most APIs were not designed for this caller. The result in production today: retry storms, tool-spec drift, runaway costs, and audit trails that cannot tell a real user from an agent acting on their behalf. This is a practical, pattern-driven talk for engineers, architects, and platform leads whose APIs are about to be hit, or already are. I walk through eight patterns that decide whether your API survives agentic traffic: 1. Idempotency that survives non-deterministic callers, not just network retries. 2.Tool-spec design: naming, descriptions, and parameter shapes LLMs do not get wrong. 3.Capability-scoped tokens for agents, instead of broad API keys. 4.Backpressure and adaptive rate limits keyed to agent identity, not just IP. 5.Schema evolution when consumers cannot read changelogs. 6.Error messages as prompts: structured, actionable, safe to feed back to a model. 7.Observability that traces the agent to tool to downstream chain, with agent identity as a first-class span attribute. 8.Cost protection: semantic dedup, response caching, query budgets, and circuit breakers on token spend. For each pattern I show the failure in code, the fix, and the operational signal that tells you it is working. Halfway through, I leave the slides for a live walkthrough of a reference API hardened against agent traffic, with a runnable harness that simulates a misbehaving agent so I can break and fix defenses on stage. This is not about MCP, AP2, or any specific framework. The patterns hold whether your callers are LangChain or custom orchestrators. If your API will be called by something that is not a human in 2027, this is for you. You leave with eight named patterns, working code, and a checklist your team can run on Monday.

Serving AI inference across mobile browsers, native apps and enterprise integrations is not a single engineering problem. Latency tolerances, client capabilities and failure models all differ. Getting it wrong at scale means degraded experiences for millions of users. In this session, Wayne Liu, Chief Growth Officer and U.S. President of Perfect Corp., will share concrete engineering lessons from building and operating API-first AI infrastructure that handles millions of real-time interactions across diverse deployment environments. During this session, Wayne Liu will uncover: - The latency vs. accuracy tradeoff in real-time AI APIs and how to deliberate decisions - Architecture patterns for serving AI across varied clients and what changes between mobile, web and enterprise environments - How abstraction layers that simplify complex inference (such as facial mapping and real-time rendering) work under the hood - Infrastructure decisions that have an outsized impact on cost, reliability and developer experience in high-volume AI deployments

Developers are releasing AI agents into the wild. Who is responsible when AI agents cause harms such as publishing false claims about a person or using tools without proper authorization? In this talk, we'll start by exploring ideas of how deploying AI agents can result in liability under legal doctrine. Then we'll shift gears by diving into practical and hands-on solutions for deploying agents designed to avoid causing harms relating to two specific scenarios: (1) defamation, and (2) unauthorized actions. Finally, we'll walk through some code examples that reflect thoughtful developer practices.

The number of cyber attacks and security risks related to Coding Agents has sky rocketed. AI coding agents like Claude Code, Codex CLI, and Gemini CLI don’t behave like your typical developer tools. They install system packages, modify configurations, delete files, run services, and even spin up Docker containers, often requiring constant permission prompts or risky access to your host machine. This talk explores Docker Sandboxes as a new execution model for autonomous coding agents. Built on microVM-based isolation, Docker Sandboxes provide disposable, agent-safe environments where coding agents can run unattended while remaining fully isolated from the host system. We’ll walk through why traditional approaches like OS sandboxing, containers, and full virtual machines, break down for agent workflows, and how Docker Sandboxes combine the developer experience of containers with the hard security boundaries of VMs. Using live examples, we’ll show how agents can safely run Docker-in-Docker, install dependencies, access only the project workspace, and be reset instantly. By the end of this session, you’ll have a clear mental model for when and how to use Docker Sandboxes to unlock higher levels of agent autonomy without compromising safety, security, or developer experience.

Artificial intelligence is advancing faster than our safety frameworks, and modern architectures are drifting toward unbounded generality and agency. In this talk, David Campbell introduces Domain-Limited General Intelligence (DLGI), a missing tier between today’s narrow systems and the open-ended ambitions of AGI. DLGI is a pragmatic alternative to “more alignment later.” It describes AI systems that can generalize within explicitly defined domains while remaining architecturally constrained, inspectable, and governable. Boundaries are not a limitation. They are the design. Drawing on real-world failures involving emergent behavior, misaligned optimization, and adversarial dynamics, David shows how unrestrained pushes toward broader generality create avoidable risk. He contrasts this with DLGI-oriented design principles that preserve capability without surrendering control. Attendees will leave with a clear mental model for building powerful AI systems that prioritize bounded agency, predictability, and trust by construction. Before things go too far, we need a better tier of intelligence. This talk makes the case for building it.

The rise of vibe coding, AI-generated code, and low-/no-code tools is changing how software is built. Traditional DevSecOps assumptions (full code review, manual security gates, “shift left”) no longer cleanly apply yet prompting an LLM for “secure code” does not guarantee safe handling of data, correct auth logic, or secure outcomes in general. This session will provide examples of how successful teams have addressed this issue and highlight the concept of using secure guardrails that notify (but don’t block) developers in their native workflow and promote the generation of secure code. Find out how to replace brittle security gates with automated guardrails, continuous checks and feedback loops that don’t slow developers. Attend to understand why security is becoming a question of intent and outcomes, not line-by-line code inspection.

At some point, all organizations will hit a similar point. A high-risk time frame exists for each org when a single poor deployment can lead to disaster (holiday peak periods, new product launch times, etc.) In many cases, the first response to such situations is to call for a complete deployment lockdown. Freeze everything. Just wait until things are safer. Unfortunately, such freezes cause problems of their own: emergency patches get blocked, panic releases occur prior to the lockdown, engineers begin treating safety gateways like bureaucratic hurdles they need to find ways around. We posed the question differently. How can we set up our systems so deployments automatically pause at the correct time, and how can we make bypassing eligibility a team-earned privilege rather than simply available to all? This talk is a technical dive into Quiet Period Automatic Protection, the system Netflix developed to replace raw trigger suppression with intelligent, stage-level deployment safety. We will go over how we moved from 'stop the pipeline' to 'pause the right stage at the right time with surgical accuracy'. The presentational topics include how the system determines production impact without requiring manual setup, how it dynamically adds protection to already running deployments, how it will handle multiple-region deployments that may last hours, and how every override is treated as an auditable learning opportunity rather than just a liability. This architectural shift transforms the mechanism of safety. By mandating a justification for every override, we convert raw bypasses into high-fidelity, auditable learning signals. Monitoring these patterns allows the system to act as a barometer for organizational strain, surfacing latent risks before they manifest as outages. Furthermore, we linked bypass eligibility to proven deployment health metrics, ensuring high-velocity teams maintain autonomy while others remain shielded. This "safety by default, freedom by merit" philosophy was battle-tested during our 2025 peak holiday window. I will detail our findings from this high-pressure period, examining where our logic proved resilient and where we recalibrated, demonstrating why designing for dynamic adaptation is superior to static lockdowns.

A customer told me he feels like Billy Beane. He can see his team's good. He can't get a number to say it. Beane's 2002 A's ran $40M against the Yankees' $126M, stopped measuring what everyone else did, and finished 103-59, one loss behind New York. Ask an engineering org how it measures delivery: velocity, story points, commits, and a leader who used to ship and trusts his gut. That's the eye test. I ran on it for 15 years as a CTO. Velocity runs on self-estimates, and AI broke the estimate. Ship in an afternoon what took three days, and the number was fiction before the sprint. Roadmap delivery is harder to measure than commits, which is why people count commits. The method. Each merged commit is scored for the depth of work it represents: how it classifies, how much of the codebase it reaches, where it sits in the architecture, whether it fixes someone else's defect. The sum is one unit, Engineering Throughput Value, scored as a senior engineer would. Work splits into growth, maintenance, and fixes; each commit ties to a Jira or Linear item, so "on the roadmap" is a link, not an opinion, and spend is divided by throughput. One customer team: 80% faster year over year, $25k a month in tooling, about $200 per ETV, roadmap delivery 36% faster, and 40% of the work mapped to the roadmap. Our published healthy line is 75%. Then the failure modes. Where classification stands in for structural analysis. What a rewritten history, squash policy, or monorepo layout does to the score without touching the work. Everything a commit can't see, starting with non-coding overhead. And the case that never makes a marketing page: high token burn, flat roadmap delivery. Team-level throughput, never a ranking of individuals. Code stays on your infrastructure. No demo. Commercial interest declared, so the design and limits are public at research.navigara.com. 500.navigara.com runs the same model across Microsoft, Meta, OpenAI, Google, Vercel, and Cloudflare.

In the transition from lab to production, AI systems often hit a wall: accuracy drops, environmental variables (hardware, hallucinations) introduce chaos, and scaling costs explode. Most teams try to "brute-force" these problems with more data or compute. However, true success in high-stakes enterprise AI requires a different approach: Strategic Creativity. In this session, I will dissect two contrasting case studies to reveal how creative problem-solving overcomes technical bottlenecks. First, we will explore the development of a Unified Intent Recognition Engine, demonstrating how a product-first modular architecture can turn fragmented development into a scalable, high-ROI pipeline. Second, we will look at a Computer Vision project that went "sideways," illustrating the brutal reality of hallucinations and hardware constraints and how a creative pivot saved the initiative from total failure.

AI teams often treat evals as a gate: a benchmark score, a pass/fail dashboard, or one number that decides whether a system ships. That breaks down quickly in production. Users disagree about what "good" means, behavior shifts across workflows, and agent failures often hide inside traces, tools, permissions, and human handoffs rather than in the final answer. This talk reframes evals as production infrastructure. I will show how developers can move from mystery scores to systems that expose failure modes: plural rubrics for stakeholder disagreement, trace-level observability, human review loops, failure taxonomies, and semantic drift/anomaly detection. The goal is practical: help teams ship AI products developers can debug, operate, and trust.

Attending this masterclass, you will be able to architect, monitor, and troubleshoot complex web performance regressions using a combination of deep-dive manual diagnostics and AI-assisted workflows. It moves beyond high-level theory to provide a technical roadmap for engineering resilient, high-speed digital experiences in high-stakes environments. We kick off with a level-setting session to ensure everyone is aligned on the core metrics that define the modern user experience, including the foundational principles and nuances of Core Web Vitals. Moving into active diagnostics, we will examine live production performance issues found on major corporate websites to see how bottlenecks manifest in the real world. You will learn to navigate the complex landscape of monitoring by comparing Real User Monitoring (RUM), Synthetic testing, and APM. We will demonstrate how combining these tools with CI/CD regression tests builds a robust observability strategy that catches issues before they impact your bottom line. We will also focus on the evolving role and impact of Artificial Intelligence in performance engineering, including DevTools MCP to automate trace analysis, leveraging LLMs to refactor rendering-heavy JavaScript and redundant CSS. The day will also feature a hands-on "performance gauntlet" where you will apply these techniques to debug and resolve real issues in a live codebase, so bring your laptop. This masterclass is designed for web professionals who want to move beyond automated scores and master the art of modern performance engineering.

Running large language models at scale can get expensive fast, but the right optimizations can cut latency and GPU costs dramatically. We’ll walk through how to serve models efficiently using vLLM, an open-source, high-performance inference engine. Then and generate and test quantized models, expose them through vLLM’s OpenAI-compatible API, and tune runtime flags to balance throughput, latency, and accuracy on different GPUs. We’ll benchmark performance live, inspect token-throughput metrics, and discuss real-world deployment trade-offs.

Distributed SQL Databases are a powerful new data management technology that addresses modern applications’ need for scalability, availability, geographic distribution, and low response time – with the power of SQL and strong consistency. However, distributed databases bring their own challenges. For example, the familiar trade-offs between consistency, high availability, and partition tolerance still exist. Remote data access will still incur speed-of-light network delays. This talk will describe the inner workings of distributed databases and how to design applications to best exploit their power. Using Oracle and other distributed databases as examples, we will explore the capabilities and unique application challenges posed by distributed databases. This talk will address design patterns that empower applications to handle network latency and consistency in the presence of real-world networks that can and do fail.

Every demo of a voice AI agent looks great — until real users start talking. They interrupt, mumble, switch languages mid-sentence, and ask the one question that sends the agent off the rails. Traditional scripted QA only verifies the behaviors you already thought of, which is exactly why so many voice agents fail in production in ways their teams never saw coming. This session walks through a practical, engineering-grade approach to shipping Voice AI agents you can trust, built on three pillars: simulation, evaluation, and monitoring. You'll see how synthetic "drivers" — AI-powered simulated users with distinct personalities, goals, and contexts — hold realistic multi-turn conversations with your agent across 30+ languages and real-world audio conditions (noise, crosstalk, clipping), actively exploring the edges scripted tests miss. We'll then look at how judge-based, symbolic, and audio evaluations turn those discoveries into CI/CD release gates, so a change that degrades conversation quality fails the build before it reaches users. Finally, we'll close the loop with production monitoring that captures real failures and automatically converts them into regression tests — so the same mistake never ships twice. You'll leave with a concrete blueprint for finding the edges of your Voice AI agent before your customers do.

We all dream of analytics that gracefully deliver real-time results to delighted users. It’s a beautiful thought, but real systems often perform more like slugs than gazelles. This talk covers the 5 top performance killers and explains the underlying behavior that makes them so slow. They include picking the wrong database in the first place, bad input batching, bad schema, queries that parallelize poorly, and going cheap on resources. If you avoid these problems, you might still not be a gazelle. But nobody will call you a slug.

What if your grocery cart could become a clinical intervention? This talk presents an AI framework that links retail food purchase data to personalized nutritional recommendations, turning everyday transactions into population health instruments.

TorqueAGI builds a physics informed foundation AI that enables robots to operate reliably in the real world. Our models power mission critical robotic systems across dynamic environments and are already being adopted by 10+ robotics partners, including production deployments.

Sixty-two percent of public company boards now dedicate agenda time to AI. Fewer than 10 percent have approved budgets for AI projects or adopted meaningful metrics for reporting on them. That gap :between awareness and action :is where AI initiatives go to die. As a board director and former senior P&L executive who has reviewed dozens of AI initiatives across multiple companies, I've seen the full spectrum: structured projects with clear ROI thresholds, and aspirational efforts with no owner, no baseline metrics, and no path to integration. The pattern is consistent :the projects that fail aren't the ones with bad models. They're the ones with no governance framework around execution. In this talk, I'll share practical frameworks that engineering leaders and product teams can adopt to make their AI projects board-ready and business-accountable. I'll walk through the Technology ROI Matrix :a method for evaluating AI initiatives across strategic alignment, investment efficiency, and execution readiness :and the Stage-Gate model adapted for AI, which establishes clear success criteria at each phase from discovery through scale. I'll cover the critical questions every AI initiative should be able to answer: What baseline are we measuring against? Who owns the outcome? How do we detect when the AI system deviates from expected behavior? What's the full cost of building, operating, monitoring, and refreshing this system? This isn't a talk about compliance checklists. It's about the discipline that separates AI projects that transform businesses from ones that quietly drain resources. Whether you're a developer advocating for an AI initiative, an engineering leader allocating budget, or a CTO reporting to a board, you'll leave with actionable evaluation frameworks you can apply immediately.

While "Cloud Native" promised portability, that promise often stops at the boundary of a single infrastructure provider. The traditional definition of Cloud Native rarely addresses the reality of multi-cloud environments, leaving enterprises with deep vendor coupling through fragmented SDKs, distinct authentication flows, and proprietary APIs. It is time to evolve to Multi-Cloud Native, a development paradigm where applications are designed from day one to be agnostic to the underlying provider. In this session, I will explore the architectural principles required to build truly portable applications using driver-based design patterns. I will demonstrate how these patterns are implemented in the ecosystem today, focusing on MultiCloudJ (Salesforce’s open-source Java SDK) and Go Cloud (Google’s open-source Go library). These libraries provide consistent programming models that decouple business logic from cloud providers, enabling a true "write once, deploy anywhere" capability. Drawing from Salesforce’s real-world journey operating hyper-scale services across AWS, GCP, and Alibaba Cloud, I will share the engineering challenges that necessitated this shift. Finally, we will examine the role of AI in this transition: specifically, how the Model Context Protocol (MCP) can analyze SDK usage patterns to automate the refactoring of legacy, vendor-specific code into modern, multi-cloud native standards.

Engineers are drowning in alert fatigue, repetitive toil, and late-night pages. But what if you could flip the script using AI? In this talk, we explore how a solo engineer empowered their practice by building an AI-driven ChatOps bot and anomaly detector—automating the triage of alerts, generating root-cause hints, and triggering runbooks autonomously

Here’s a question: would you build a REST API and make users guess the request and response formats? Doing so opens a Pandora’s Box… * What’s the domain model? * Name the operation… POST? GET? PUT? PATCH? * What does this error code even mean? * Is the documentation - if it even exists - accurate and relevant? Imagine the complex, repetitive logic every consuming system would need to implement to make sense of it all. In a distributed, asynchronous system, these problems are magnified. Apache Kafka's flexibility—messages as simple bytes—is a huge strength, but it's also a major risk. While your event streams likely consist of some structured data (maybe JSON strings), enforcing structure, managing evolution, and basic validations aren’t a hard requirement. This leaves consumer applications to perform this preprocessing of every event - even if that event has no business value. In this session, we'll define data contracts and how to enforce them at the source - the applications that produce events. We’ll cover the practice of using a schema registry - supporting popular serialization formats like Apache Avro and Google Protobuf - to design events in the terminology of our business domain. Because data structures change over time, let’s discuss safe schema evolution practices. Then we’ll utilize these contracts with schema registry-aware producer and consumer code. We’ll end our time by looking at how smart CI/CD pipelines and build-time checks can add an extra layer of defense against the costly problem of poison data. It’s time to stop guessing and start governing. Join us to learn how to move validation upstream and transform your event streams into high-quality, discoverable data products. You’ll walk away with a practical blueprint for enforcing schema integrity and automating evolution—ensuring your data streams are a trusted asset.

In this hands-on, full-day workshop, we'll take a bold app concept and ship it together — from blank slate to running application — using today's agentic AI tooling (Claude Code, Codex, and peers). You'll see how to move from idea to product plan, set up a database, build a NestJS backend, and deliver a React frontend, all driven by AI agents rather than manual coding. No slides, no theory overload - just real development with real tools. We'll work with skills, rules, sub-agents, and multi-agent workflows to move fast, stay focused, and skip the tedious parts. You'll leave with a working app and a practical mental model for how agentic development changes the way software actually gets built. By the end of the day, working with AI won't feel like a novelty - it'll feel like your new default. Let's build something cool (and maybe blow your mind a little).

Our core claims system in the health insurance domain has been running reliably for 17 years. Originally built from scratch as a monolithic java application, it still forms the backbone of our business operations today. Rather than replacing it through a rewrite, we chose a different approach: continuous modernization. Step by step, we migrated the system to the cloud, improved scalability, introduced modular structures, and continuously updated it to the latest Java and Spring versions – all while keeping the system fully operational. Throughout this journey, we often had to prove that our system could stand up against commercial solutions. Each modernization step was not only a technical improvement but also a statement that a well-maintained, custom-built system can remain competitive, flexible, and cost-efficient if continuously evolved. It required alignment and understanding across all stakeholders – from developers and architects to our users and management. Everyone had to embrace the idea that modernization is an ongoing evolution rather than a single project. In this talk, I will share authentic insights into the realities of modernizing a large, business-critical system while it continues to serve millions of claims inquiries annually. I will also reflect on key challenges we faced and the lessons we learned on the way to achieve a future-proof claims system.

No single AI model is best at everything. The challenge is knowing which model to use, how to measure whether it is good enough, and how to control cost as agents move across different tasks. You'll learn how to: Compare proprietary, open-weight, and fine-tuned models for different workloads Evaluate models on quality, latency, and cost using LLM judges Use Smart Routing to automatically match tasks and agent subtasks to the right model Govern agent workflows with policies, token limits, and spending controls This session includes practical demos of model evaluation, Smart Routing, and agent cost controls with the open-source tools Omnigent and MLflow. Whether you're building AI applications or coding agents, you'll leave with a practical framework for choosing, evaluating, and governing models without sacrificing quality.

AI coding agents are reshaping software development, but they are also creating demand for a new class of devices: hardware built specifically for interacting with non-deterministic, always-on personal agents. This talk explores the rise of agentic hardware through a real open-source device: a voice-first, AI-native controller for personal agents such as Claude Code, Codex, and OpenClaw. The device combines a 3D-printed enclosure, mini keyboard, LCD screen, microphone, ESP32-based firmware, and Bluetooth/Wi-Fi connectivity to create an interface that makes sense for AI agents rather than traditional desktop workflows. Using this device as a case study, I’ll walk through the full technical stack behind agentic hardware: PCB design and manufacturing, enclosure prototyping with 3D printing, embedded firmware on ESP32, networking and transport choices, and the WebSocket server architecture that bridges the device to agent runtimes running on personal computers. The session focuses on the engineering trade-offs involved in building hardware for AI-native interaction: latency, connectivity, input ergonomics, voice-first UX, power and form-factor constraints, and the challenges of integrating deterministic embedded systems with probabilistic AI systems. Attendees will leave with a practical mental model for building their own agentic devices, plus concrete lessons on where edge hardware is becoming essential in the age of personal AI agents. Open source repos covered in this talk: * Device firmware: https://github.com/second-state/vibekeys_firmware * WebSocket server that orchestrates AI agents and LLMs: https://github.com/second-state/vibetty * Open source voice recognition models: https://github.com/second-state/qwen3_asr_rs and https://github.com/second-state/cohere_transcribe_rs

We have all had that maddening customer service experience: you text a support line about a delayed flight, receive a confirmation, but when you call in a minute later, the voice agent asks, "How can I help you today?" completely blind to the SMS you just sent. This is the "Channel Amnesia" problem. While businesses are pouring billions into generative AI, most agents are still built on stateless architectures that forget customer context the second a session ends. In this session, we will cure AI amnesia. You will learn how to orchestrate stateful, production-grade AI agents across SMS and Voice using Twilio Agent Connect and Amazon Bedrock. We will dive into why traditional serverless compute fails stateful agents, how to leverage AWS Fargate for isolated, long-lived sessions, and how to configure Bedrock AgentCore over WebSockets to hit sub-50ms streaming voice latency. No slide-ware here — expect a live, cross-channel demo and open-source code you can deploy tomorrow.

As organizations scale their Kubernetes footprint, the "Day 2" reality of GitOps becomes clear: static thresholds are brittle. Standard Canary rollouts rely on fixed Prometheus queries (e.g., Error Rate < 1%), but these rules lack the context to distinguish between a minor transient blip and a systemic failure. For Platform Engineers, this results in "Alert Fatigue" and manual "promotion" gates that slow down the delivery pipeline. In 2026, we are moving from Static Automation to Reasoning Platforms. This session explores how to evolve your delivery infrastructure into an intelligent system that doesn't just follow rules, but reasons through data. We will demonstrate how to wrap ArgoCD Rollouts with an Agentic Reasoning Layer capable of cross-referencing metrics, logs, and distributed traces to make autonomous "Go/No-Go" decisions. We will trigger a Canary deployment that passes basic health checks but introduces a "silent failure" (e.g., a cache hit-rate drop causing downstream latency). You will see the Reasoning Platform detect the anomaly, pause the rollout, "investigate" the root cause, and present a natural-language justification for the automated rollback.

Abstract - For quite some time Flutter has been grabbing attention of client-side developers as it offers big development velocity with high-quality results not just on mobile, but also on web and desktop. One frontier that it never quite solved is backend, which was always written separately and completely isolated from both Flutter framework and Dart language. Are we ready to change that in 2026? Details about the talk for talk evaluation - The talk will explore an example of full-stack project developed fully in Dart (using Flutter for client-side and Serverpod for backend). The theme of the project would be an event aggregator where user can see info, favorite and register to attend various events. While the majority (30 minutes) of the talk will focus on the technical side of full-stack development in Dart, the last five minutes of the talk would be spent on process advantages that this offers which is allowing Dart developers to cover both verticals and that allows front-end developers to substitute back-end developers in case of sickness or vacation as well as vice-versa. This helps small teams keep development velocity high in real world when unexpected time-off happens for any reason.

I've joined teams where I spent months being invisible. Not because people were bad. Just because all the knowledge was buried in 50,000 commits I'd never seen. Who owns the auth flow? Who actually likes debugging race conditions? I had no idea. I was guessing, and it showed. So I built Team X-Ray. It's a VS Code extension that analyzes people, not code. How they communicate. Who they collaborate with. What they're genuinely good at. What kinds of problems they actually enjoy solving. It started as a GitHub Copilot integration connected to repository data through MCP. But the architecture evolved. Today it talks directly to the Copilot SDK with custom tools that give the agent native access to your team's data. No Docker. No middleware server. Then something unexpected happened: AI agents started making commits. Suddenly my tool was lying to me. It was attributing expertise to bots. Inflating contributions that no human wrote. I had to teach it to separate human work from automated work, and in doing that I stumbled onto something more interesting. In the age of agents, expertise isn't just who writes the code. It's who understands it. Who directs it. Who makes everyone else better. In this talk I'll walk you through: - The technical evolution: from MCP to Copilot SDK with custom tools - How I built Team X-Ray and what it taught me about real team dynamics - The agent problem: how to detect bot commits and separate human expertise from automation - Real examples of AI surfacing mentors, knowledge silos, and hidden team dynamics As Moira Rose said: "When one of us shines, we all shine." I'm not trying to replace human connection. I'm trying to accelerate it. Even when agents are already part of the team.

Every agent demo runs with a god-token. Then it ships, and someone has to explain why the helpful AI just rm -rf'd the staging database "to clean up." I run platform infrastructure at a frontier lab, and for the last year my job has partly been: let coding agents do real work against real systems, without ever having to write the postmortem. This talk is the permission model that fell out of that - not RBAC-with-extra-steps, but primitives designed for an actor that's smart, fast, tireless, and occasionally *confidently wrong*. **The four primitives:** - **Asymmetric verbs** - the agent can `quarantine` but not `delete`, `retry` but not `approve`, `propose` but not `merge`. The verb list *is* the security boundary. Stop thinking in resources, start thinking in reversible vs. irreversible actions. - **Regenerating budgets** - every agent identity gets N disruptive actions per window. Burn the budget, you're benched until it refills. No human-in-the-loop until the budget's gone — which means 95% autonomy with a hard ceiling on blast radius. - **The undo test** - if the agent can't undo it, the agent can't do it without a second key. One line, surprisingly load-bearing. - **Tripwires over allow-lists** - let the agent roam, but instrument the three actions that would actually hurt. Cheaper than enumerating everything safe. I'll show the ~200-line policy layer that implements all four, the failure modes each one exists to catch, and the one design I shipped that turned out to be security theater. Tool-agnostic - works whether your agent is touching CI, a database, a cloud account, or your users' files. If you're shipping an agent that does anything more than read, you'll leave with a threat model and a starting policy you can paste into your repo on the flight home.

It started as a simple security research project on a local SQL Server instance. A single vulnerability led me down a rabbit hole from compromising Azure SQL Database to successfully escalating privileges on GCP CloudSQL for SQL Server, Amazon RDS, and Alibaba ApsaraDB. In this session, I’ll walk you through the techniques I used to escalate from a limited user to sysadmin on managed SQL Server platforms offered by the four biggest cloud providers. I’ll also demonstrate post-exploitation techniques, including how I retrieved plaintext [sa] passwords from internal logs and accessed highly sensitive internal metadata. More importantly, I’ll share lessons on how these vulnerabilities were possible in the first place and what you, as a developer, DBA, or security professional, can do to secure your applications against similar attack vectors. Finally, I’ll share how each cloud provider responded to the vulnerabilities I disclosed, the remediation timelines, and the broader lessons this experience teaches us about cloud security.

Large Language Models are expensive. With context windows expanding to 200K+ tokens, a single API call can cost several dollars—and in production systems handling thousands of requests, these costs compound quickly. Most optimization efforts focus on model selection or prompt engineering, but there's an overlooked dimension: the context itself often contains massive redundancy. Headroom is an open-source Python library that sits between your application and your LLM provider, transparently optimizing context before it reaches the model. The core insight is simple: LLM contexts—especially in agentic workflows—are filled with repetitive tool outputs, verbose JSON arrays, and boilerplate that consumes tokens without adding proportional value. What makes Headroom different? Traditional compression destroys information irreversibly. Headroom introduces CCR (Compress-Cache-Retrieve), a reversible compression architecture. The compression itself is content-aware. Code gets AST-parsed to preserve signatures while compressing function bodies. JSON arrays undergo statistical analysis—we identify outliers, errors, change points, and representative samples rather than blindly truncating. Markdown preserves headers and structure. Each content type gets specialized handling. Real-world results: - 50-90% token reduction on typical agentic workloads - Drop-in integrations for LangChain, OpenAI, Anthropic, and any OpenAI-compatible provider - Zero code changes required when using the proxy server

Since December 2025, I've built Mazarin, an open-source microkernel OS written in Go with reasonable Linux emulation and a new UI paradigm. 940 commits over 5 months. Zero lines of code written by me. (The title overstates it slightly—but it is a difference only in degree.) This talk isn't really about Mazarin. It's about how it got built and what that means for you. Three points: 1. Vibe-coding is a disaster. Human-directed AI coding is a superpower. The difference is experience. 30 years of it, in my case—enough to make every architectural and strategic decision myself, then farm out the implementation and cross-check the result. I'll walk through specific strategic calls I made and why. 2. The further you get from the code, the more process matters. Hard problems—virtual memory, for instance—have to be decomposed into chunks the AI can actually handle. Don't expect architectural insight from the tool; treat it as a bonus when it happens. And because you're moving so fast, you need rigorous internal documentation so both you and the AI can remember past decisions and their rationale. I'll demonstrate by live-fixing a bug in Mazarin on stage with my process. 3. Get on the train or get run over. Pre-AI, Mazarin would have been a 2–3 person, multi-year project. I'm a solo engineer and I have a day job! The force multiplier for senior engineers is going to have profound consequences for junior ones—and a real bottleneck is coming in how we train the next generation of seniors. I'll share job market data, productivity measurements, and my own take. I can't predict the future, but I can tell you what I'm seeing.

Duolingo's iOS app has nearly 1.8M executable lines and, until recently, test coverage that lagged far behind. We built an autonomous pipeline that writes unit tests and gets them to a merged state. Scheduled Temporal workflows pick untested code, Claude Code agents open real pull requests, and a lifecycle manager monitors CI, self-heals failures, runs AI review, and merges. Humans act only as final reviewers. The pipeline has merged over 85,000 lines of test code and tripled unit-test coverage of our MVVM components. This talk walks through the architecture, the guardrails that keep agent-written code trustworthy, the failure modes we hit, and how we are using the same skeleton for additional migrations across the company. You will walk away with a concrete blueprint for agents that ship code in a large production codebase.

On April 22, 2026, a threat actor used stolen Checkmarx credentials to push malicious images to a trusted Docker Hub repository. The payload quietly collected scan output, encrypted it, and exfiltrated it to attacker-controlled infrastructure. It was live for 83 minutes before Docker caught it. This talk is about how. Not the incident itself, but the detection model behind it: what signals fired, why no single one was enough, and what it means to build a supply chain posture where the question is not "can we prevent every breach" but "how fast can we find it and how small is the blast radius." We cover the structural pattern behind Trivy, KICS, LiteLLM and axios: stolen credentials, legitimate publishing flows, short exposure windows. Then we get into what Docker actually does differently: provenance-linked builds, digest pinning, cooldown periods, cross-registry signal sharing, and Docker Hardened Images as the foundation that sits outside the attack surface entirely. You leave with a concrete checklist your team can act on tomorrow, and a mental model that holds regardless of which tool gets hit next.

Performance is the most overlooked problem in mobile engineering — not because engineers don't care, but because it's invisible. When something crashes, there's a log. When servers cost too much, there's a bill. When an app is slow, users just leave. No alert fires, no ticket gets filed. That invisibility is the whole problem, and the talk is a systematic answer to it. The framework it introduces — Performance, Reliability, Efficiency — exists to show that these three things are connected and pull against each other. Making one screen faster can make the whole system more expensive. Understanding the trade-offs is what separates reactive firefighting from deliberate engineering. The core of the talk is a cycle: instrument the app, collect the right data, analyze it, prioritize what to fix, implement, and validate. The instrumentation piece is more nuanced than it sounds — what you measure and where you start the timer matters. The rule is to measure what the system does, not what the user does, because user behavior introduces noise that makes the data useless. Once you have data, averages mislead. Percentiles tell the truth. A small number of metrics — median latency, tail latency, success rate, failure rate, abandonment rate — gives a complete picture of any screen. Abandonment is the one most teams ignore, and it's the most honest signal: a user who left before the page loaded is a direct conversion loss that shows up nowhere in traditional monitoring. The abandonment curve is where engineering data becomes a business argument. It shows exactly how increasing load time drives users away, with a clear inflection point above which every additional millisecond has an outsized cost. That curve, combined with traffic volume, tells you where to focus: a small improvement on the screen every user sees daily is worth more than a large improvement on a screen almost nobody visits.

Your AI agent works great in the demo. Then you deploy it and it hallucinates a refund policy, exposes customer data, or just loops endlessly burning tokens. This session walks through a layered approach to agent safety using tools like Amazon Bedrock AgentCore and the Strands Agents SDK: guardrails, observability, multi-agent safety patterns, and reference architectures you can adapt immediately.

Meetups often die the same way. People show up once, have a fine time, and never come back. Code & Coffee is a nonprofit that runs 300 meetup events a year across 30 cities for a community of 80,000 members, on an annual operating budget under $6,000 and with almost no paid marketing. It only works because people return for an actual community, not just another audience. This session is about meetup and community design. Steve will show how Belonging, Trust, and Safety translate into specific decisions rather than values on a slide: the intro-circle ritual run at every event, the cadence rule organizers have followed since 2017, and why Code & Coffee events are social by default instead of built around endless talks. Steve will also cover the unglamorous operations: where to find a free venue in your city, what to ask a sponsor for, and what to offer in return. If you have ever wanted to organize a meetup community, run events, grow a developer community, or have simply been waiting for someone else to start the meetup you want to attend, this talk is for you. You will leave with a repeatable meetup event format you can adapt and a concrete first step you can take toward building community.

Most teams still think of authorization as a security concern. In modern systems, it has quietly become a reliability concern as well. Authorization logic is no longer confined to one codebase. It is spread across application services, API gateways, background workers, data platforms, and now AI driven automation. Each layer makes its own decision, often with incomplete context and slightly different assumptions. This works until scale, automation, and non human identities turn small inconsistencies into systemic failure. In this talk, we will look at real world failure modes where authorization bugs manifested as cascading outages, stuck workflows, data corruption, or unexplainable behavior under load. We will show how fragmentation hides these problems until decision volume spikes, and why traditional testing and observability rarely catch them early. The session introduces a practical mental model for treating authorization as part of system reliability. We will cover warning signs that teams can spot before incidents happen, and architectural patterns that reduce blast radius without centralizing every decision or rewriting existing systems. Attendees will leave with concrete criteria for evaluating their own architectures, and a checklist for making authorization behavior predictable, testable, and explainable at scale.

Deep in enterprise infrastructure, platform engineers often play the mad scientist, stitching together disparate MLOps tools into a terrifying "Franken-stack", a fragile ecosystem held together by custom code and vendor lock-in. Let’s move past these infrastructure headaches and look at how Uber open-sourced Michelangelo to bring architectural order to the chaos. This session reveals how the platform anchors a consistent developer experience across the entire ML lifecycle using its three core open-source pillars: Uniflow for pipeline orchestration, the native Job Controller for automated cluster execution, and the Model Serving layer for low-latency inference. Through a live demo, we’ll provide a blueprint to seamlessly swap out your underlying infrastructure components, like shifting compute or orchestrators, without breaking your Python workflow code. Finally, attendees will get an inside look at our local sandbox architecture, allowing developers to safely spin up, experiment with, and master this composable, cloud-native stack on their own hardware.

All programming languages have their foundations: the engine that interprets your code and makes everything run. In PHP, this is the Zend Engine, a critical piece of software that powers millions of applications worldwide. When everything works, you don’t even think about it. You deploy to production, and the engine does its magic behind the scenes. But what happens when something goes wrong in that core? What if a subtle bug opens the door to a full security breach? Suddenly, the invisible foundation becomes the most important part of the story. Let’s shine a light on two such cases: a recent, real vulnerability in the PHP engine (which has since been patched), and a backdoor that, just a few years ago, actually made it into the release candidate and allowed remote code execution. We’ll walk through how each issue could be exploited and, most importantly, what lessons developers can draw from them. And yes, there will be live, local, sandboxed demos of both exploits in action. Ready to dive in?

Most teams think KV cache is about making inference faster. That's true, but it's not the point. KV cache is really about controlling memory, reducing recomputation, and keeping costs from spiraling as usage grows. As models get deployed at scale, the real bottleneck is no longer raw compute. It's memory, bandwidth, and power. This session takes a step back to explain what KV cache does at a system level, why it matters for real workloads, and how approaches like vLLM, LMCache, and SGLang change how we think about scaling inference. We'll also connect this to a problem many teams are already seeing: confidently incorrect answers in agent systems. When cache behavior, context reuse, and routing aren't designed well, systems don't just get slower or more expensive. They get inconsistent. And that shows up as wrong answers with high confidence. This session will walk through these trade-offs using live demos, showing how different KV cache strategies impact cost, latency, and output quality in real time.

Building a successful open source company without venture capital is rare - scaling it past $50M in revenue is even rarer. This talk distills two decades of hands-on experience growing and sustaining a commercial open source business from zero to global scale. We will share the real strategies that worked - navigating product-market fit, monetizing open source while keeping the core free, building a distributed team long before remote work was mainstream, and developing a repeatable go-to-market engine without external funding. We’ll also explore what didn’t work, the pitfalls we hit along the way, and the lessons learned from building a business that competed against well-funded alternatives. Whether you’re a founder, engineer, community leader, or simply curious about the business side of open source, you’ll walk away with practical insights, battle-tested frameworks, and a clearer understanding of how to build and scale an open source company the hard way - by bootstrapping.

For years, a common bias has held that serious AI development is best left to other ecosystems. This session is here to change that perspective with a live, hands-on demonstration. It’s time to show the world what enterprise Java can really do in the age of AI. With the release of Helidon MCP, it allowed us to explore and challenge this old narrative. We can now build high-performance, GenAI-native MicroProfile (MCP) servers from scratch. This is a "fresh perspective" on modern Java, proving that you can build secure, powerful, and scalable AI applications entirely within the JVM ecosystem you already know and trust. This session introduces the JAQ Stack, a novel technology pattern for this new reality: J (Java/Helidon MCP): We’ll use Helidon to build a blazing-fast, lightweight, and cloud-native server, perfect for handling enterprise workloads. A (AI/Ollama): We'll integrate a local LLM via Ollama, solving one of the biggest real world enterprise problems: 100% data privacy and security. Q (Query/LangChain4j): We'll use this powerful Java-native library to build a sophisticated RAG (Retrieval-Augmented Generation) pipeline and orchestrate our AI logic. This is not a slide heavy talk. This is a dynamic, live coding session, delivering deep technical insights for developers. Attendees will see, step-by-step, how to solve a common business problem with a 100% Java-native stack. And because the JAQ Stack is batteries included and comes with pre-built applications, they'll leave with a blueprint that is incredibly easy to get started with.

Most AI agents move files. Ours run machines. Loominus Studio is an AI workbench. You use it to build agents that work alongside people to design and make real things: materials, formulations, devices. The jargon for this is collaborative cyber-physical agents. The plain version is agents with hands. What you build is a harness. A harness is everything an agent needs to do real work: the tools it can reach, the steps it follows, what it remembers, what it is allowed to touch. Coding agents have harnesses. That is why they work. Labs and factories have none. You build one by wiring nodes into a graph. Each node is a step or a tool: run this machine, mix this batch, ask a person to check, measure the result, pick what to try next. Wire them together and the agent runs the loop. Two things matter about these harnesses. Configurable: no two labs work the same way, so you build yours instead of buying someone else's. Portable: build it once, run it on someone else's machines. Your process should not be locked to one vendor's box. We use it ourselves. MetaLab is a harness for making formulations. BioLoom is a harness for printing parts. Same workbench, different graph. Five minutes on why the loop that made coding agents work is the same loop every lab runs, why nobody built the workbench for it, and what that changes for the bioeconomy age, when the things ahead of us have to be made, not just written.

Loop Engineering and Graph Engineering are rapidly emerging as important directions for the next generation of AI agents. Our work sits at the intersection of frontier research and real-world implementation. Rather than discussing these ideas only at a conceptual level, we build and test self-evolving agents in practice. We use real systems, long-horizon tasks, and failure cases to evaluate emerging research, understand what works, and identify what is still missing. In this session, we will share practical lessons from building self-evolving agent systems, including how agent workflows evolve from simple loops into graphs, how these graphs can adapt and rewrite themselves, and how agents can improve not only their outputs, but also the way they learn and evolve. The audience will gain both a clear understanding of the latest research and actionable insights from real-world experimentation.

What happens when multiple coding agents work on the same codebase at the same time? Vlad Luzin, CTO of BAND, will run a real multi-agent coding session, with multiple coding agents (Claude Code, Codex, and others) working collaborating to complete one shared engineering task. The session will demonstrate how Jam from BAND acts as a collaboration layer across otherwise isolated agent sessions, allowing developers and agents to work together with shared context. On stage, we'll bring in different coding agents from different team members and watch them coordinate on one shared task: splitting up work, handing off context, flagging blockers, looping in a QA agent to check a piece of the work adversarially. This is loop engineering in practice: the patterns for keeping a team of agents, and the humans behind them, working from the same picture instead of a pile of disconnected sessions.

What happens when you actually try to use MCP at scale? In this talk, I'll build an agent live on stage, connect it to 1,000+ tools via MCP, and show exactly what breaks: context explosion, ambiguous routing, and security vulnerabilities from indirect prompt injection. Then I'll show how to fix it. I'll cover dynamic tool discovery (reducing context from 500 tools to 1-2), code-mode execution, and why every MCP tool is a trust boundary your security team should care about. This isn't specifically MCP advocacy as thes issues go beyond MCP and affect any agent that needs tools (and any modern agent is very tool hungry). It's a practitioner's guide to what works (and doesn't) when you scale MCP tools.

The dominant framing of enterprise AI is speed: faster code, faster decisions, faster discovery. That framing misses the larger story. When AI is anchored to the equations of physics, chemistry and biology rather than to the corpus of the open web, it does not just compress timelines — it expands the space of what can be explored. A bigger biochemical landscape for drug discovery. A bigger materials landscape for batteries and alloys. A bigger design landscape for everything humans build. Drawing on SandboxAQ's deployments across pharma, energy and navigation, Yuval shows why Large Quantitative Models are the first AI architecture capable of growing the pie rather than slicing it thinner, and what that means for any enterprise still measuring AI value in cost reduction.

As engineering organizations scale, merging code into a shared codebase becomes a major productivity bottleneck. Thousands of engineers changing code continuously can overwhelm build systems, slow feedback loops, and erode trust in the mainline. This talk explores how large teams keep builds green while maintaining high developer throughput by treating code integration as a systems problem. We’ll introduce the core ideas behind speculative merging, including dependency graphs, speculation trees, and invalidation, and show how predicting likely future states of the codebase enables parallelism without sacrificing correctness. We’ll examine why naive approaches don’t scale, how combinatorial explosion and finite CI resources shape real-world designs, and what tradeoffs are required to make speculation practical. Finally, we’ll share lessons learned from evolving SubmitQueue over several years, highlighting how build stability, fast feedback, and merge confidence directly impact engineering productivity.

The microservices revolution gave us a hard-won set of principles: small services with well-defined contracts, owned by independent teams, composable into larger systems, replaceable without rewriting the world. The agentic AI era is rediscovering these lessons the hard way. Most enterprises today are building agents the way we built monoliths fifteen years ago: each agent a self-contained stack with its own conversation store, its own auth, its own observability, unable to talk to the agent built down the hall. There is a better pattern. We call it a MicroAgent, and it is to the agentic world what a microservice is to the API world. A MicroAgent is a lightweight, independently-deployable package consisting of two things: an MCP server that exposes domain-specific tools, and a prompt template that encodes domain expertise. That is the entire contract. No session management. No streaming code. No auth boilerplate. Those concerns belong to a shared Base Agent Service, the way platform concerns belong to a service mesh or API gateway. The Model Context Protocol is the API contract that makes this work. MCP is not just a tool-calling format. It is the service boundary that lets MicroAgents from different teams compose into super-agents through configuration alone. The Base Agent routes tool calls over MCP, fetches prompt templates via HTTP with conditional caching, and merges state updates from _meta fields in tool responses. This talk walks through the architecture: MicroAgents as units of ownership, MCP as the contract, shared infrastructure as the substrate, and the multi-agent composition patterns that emerge once these boundaries are clean.

Modern cloud native systems often span hundreds of microservices, thousands of endpoints, and fragmented telemetry across logs, traces, metrics, deployments, and service catalogs. Even with strong observability, engineers still struggle to answer two high impact questions fast: why did this deployment fail, and if I change this service or API, what breaks. This industry session presents an AI powered Microservice Cognitive Index, an intelligence layer on top of existing observability. It builds a canonical evidence graph by ingesting telemetry, deriving runtime topology from traces, clustering incident signatures from normalized logs, correlating regressions with deployments, and propagating change impact through dependency and contract signals. It combines graph based reasoning with machine learning and large language models to summarize evidence, rank likely causes, and explain blast radius with confidence. Unlike chat with logs approaches, it enforces tool grounded answers with evidence references, confidence scoring, and refusal policies when data is incomplete or confounded, making results auditable and safer for operations.

The era of betting everything on a single LLM is over. Developers building production AI agents face a reality no model vendor wants to talk about: no one model excels at every task, no single API guarantees 100% uptime, and no proprietary provider offers the cost profile that works for every layer of an agentic pipeline. The open-source LLM ecosystem has changed the equation. Llama 3.3, DeepSeek-R1, Qwen3, Gemma 3, Kimi-K2 — these models are not fallback options. They are, for many agentic workloads, the better choice on quality, latency, cost, or all three. But the real power is not in picking one winner. It is in architecting agents that route across multiple models, failover when an endpoint goes down, and match model strengths to task requirements in real time. Resilient agentic engineering demands a multi-model, multi-provider architecture — and the neocloud is built for exactly this. Crusoe Managed AI provides a single API surface across every major open-source LLM, on infrastructure purpose-built for the throughput and latency demands of agentic workloads. This session draws from production experience to walk through the architecture decisions, failure modes, and performance tradeoffs of moving from a single-model prototype to a resilient, multi-model agent in production.

The Space Shuttle was the most advanced machine ever designed. It was a triumph and a marvel of the modern world. And on January 1986, shuttle Challenger disintegrated seconds after launch.This session will discuss how and why the disaster occurred and what lessons modern DevOps and Site Reliability Engineers can learn. The Challenger disaster was not only a failure of the technology, but a failure of the engineering and management culture in NASA. While engineers were aware of problems in the technology stack, there was no conception of the risks they actually posed to the spacecraft. Management had shifted the focus from “prove that it’s safe to launch” to “prove that it’s unsafe to stop the launch”. This session will present the risk analysis (or lack thereof) of the Shuttle program and draw parallels to modern software development. In the end, launching a shuttle is an extremely complex deployment to the cloud… and above it.

Every developer working with IoT or Smart TVs has met the ultimate villain: the Out-of-Memory (OOM) killer. As digital commerce grows more complex, we’re asking low-spec hardware, often with less than 1GB of RAM—to juggle massive JSON payloads and multi-step transactional state machines. The result? System stutters, service crashes, and lost revenue. In this 10-minute lightning talk, we’ll look at a practical architectural pattern to solve this: The State-Shift. Instead of asking a resource-constrained device to manage complex logic, we migrate the entire transactional state and error-recovery mechanism to a cloud-side "Stateful BFF" (Backend-for-Frontend). We’ll quickly cover: - The "Thin-Client" Transformation: How to turn a struggling device into a stateless observer. - The Double-Handshake: A simple pattern for state recovery after a hard reboot. - The Results: Real-world metrics showing how this shift can cut heap usage by 35%. You’ll walk away with a clear blueprint for extending the life of legacy hardware without sacrificing modern functionality.

The time between a vulnerability being found and being exploited has gone negative - see X, LinkedIn, Hacker News, etc. AI models now surface flaws faster than maintainers can patch them. The industry's answer (some at least) is coordinated, pre-disclosure defense: pool findings, patch under embargo, push mitigations before the bug is public. It works. But it works for the people inside the coalition — the banks, hyperscalers, the vendors who can patch on an attacker's timeline, commercially. Most of us aren't in that room. We're building, scaling, pivoting, and breaking things at machine speed. Our priorities are different, but security affects us, no less than the big guys. I call it "the middle: small security teams, heavy open-source dependencies, no seat at the embargo table" aka most of us. We inherit the same risk on the public side of disclosure — and we're not idle about it. This talk is about what coordination looks like from down here. Not a poorer copy of the embargo club — an open response commons: when a disclosure drops, a mitigation gets generated once and propagates across the enforcement points teams already run, at machine speed, instead of every shop reinventing it alone. I'll show an early, working v0 built with security partners who aren't limited to being conventional, and make the case for what we build next. I don't have all the answers, I'm just a guy trying to solve some problems. This is an invitation to contribute.

In large-scale systems, multiple teams, third-party integrations, and shared codebases can make testing feel impossible to coordinate. In this session, Bartosz and Pawel reveal how to bring order to that chaos using a unified full-stack testing strategy inside a monorepo architecture that powers both React and React Native applications. They’ll show how to combine contract, integration, gRPC, API, and visual regression testing into one consistent framework that helps teams work independently without breaking each other’s services. You’ll learn how TypeScript and shared logic enable type-safe, scalable testing across platforms — and how this approach speeds up releases while reducing integration pain. Expect practical patterns, real examples, and lessons learned from building test architectures that survive complex, distributed environments.

This talk focuses on strategies for businesses to efficiently manage their AI products through API governance and observability. It covers methods for reducing costs and optimizing consumption, ensuring effective and scalable AI integration within enterprise environments.

Production pipelines combine models, rule-based automation, and human reviewers to achieve a single outcome. Designing systems that allow these to coexist reliably at scale is a hard problem. At Netflix, every title that reaches our millions of subscribers passes through complex content metadata workflows. Some decisions are fully automated by rules. Others are handled by ML models. And some require a human to make the call. Building a system that coordinates all of these consistently — without breaking when any one component fails, changes, or gets replaced — required rethinking how we architect workflow orchestration entirely. In this talk, we share how we built a production framework where rule-based automation, ML models, and human-in-the-loop review are all first-class citizens in the same pipeline. We'll cover how we handle routing, failure isolation, and feedback across heterogeneous components — and how this foundation naturally extends to incorporate AI agents.

Your Ring camera sees everything. So does the company behind it. What if you built your own with a Raspberry Pi, a $10 webcam, and an AI that actually understands what it sees? Same smart alerts. Same intelligent answers. Zero cloud. Zero subscription. Zero strangers watching your footage. Your data. Your hardware. Your rules. Today, we build that. Live. In front of you. From scratch. A Raspberry Pi, a webcam, and 45 minutes. That's all it takes to own your own intelligent camera and never hand your privacy to anyone again.

Security isn’t just about firewalls and patches, it starts long before the first line of code is deployed. In this workshop, we’ll explore how threat modeling helps teams move from a reactive security mindset to a proactive, design-first approach. You’ll learn how to identify vulnerabilities before they become incidents, map out potential attack paths, and make risk-informed decisions, all before the build is complete.

The majority of current notification systems for AI fail, for either too much noise training users to ignore the notifications or too much conservatism missing important signals. Proactive AI at scale lessons learned from designing and operating such service on real world product. Authors started with quite optimistic assumptions that more intelligence would lead to more engagement after couple of iterations (and lots of usage), they learned that first version of the product was pretty noisy and unreliable. Most importantly, after couple of iterations, they learned that the issue wasn’t actually in the model, but in how you framed the decisions. In this talk I explain the thought process behind some design choices I made in shifting from an automatic system to a more deliberate one. In this session user preferences for things like consent and frequency limits as well as quiet hours are implemented. Then I’ll explain how the system determines if it has enough context to make a different decision. If the system doesn’t have enough information OR it has inconsistent information then the system does nothing –there is no fallback or force engage. My talk goes through how I used multiple user signals, user behavioral preferences, real world events, and timing to make a series of decisions leading up to a decision point. The hardest part was getting others to understand that suppression was a valid outcome and NOT a failure. We'll cover these core concepts as well as advanced topics such as how system handles duplicate events, user longitudinal data, and what we mean by engagement versus trust. This talk is for engineers who build AI powered product features, not just demo the features to users but also to systems, to others who are engineering similar features and are trying to understand trade offs.

We usually treat cloud costs as an infrastructure problem - something to be solved with better budgets or Reserved Instances. But in a world of serverless and containers, your bill is a direct reflection of your code's efficiency. A memory leak isn't just a bug anymore; it’s a monthly recurring expense. A "chatty" frontend isn't just slow; it’s a self-inflicted DDoS attack on your own wallet. This lightning talk shifts the FinOps conversation to where costs actually start: the IDE. We’ll trace a single request through a standard GCP stack—from an Angular frontend, through Java services on GKE, and down into Cloud Spanner. Instead of high-level theory, we’ll look at the specific code-level anti-patterns that wreck unit economics. You’ll see how "polite" frontend code helps GKE bin-packing density, how Java serialization impacts Dataflow costs, and how specific query patterns can quietly destroy a budget. You'll leave with a developer-centric checklist to stop the bleeding in production.

You're already integrating LLMs into your products and workflows, but what does it mean to do this *well?* In this talk you'll receive a framework for how to ensure you build truly *good* things. In 1893, Clark Stanley, the "Rattlesnake King," hawked an oil made from boiled rattlesnakes that could cure all pains and even lameness. It did nothing. Stanley was fined handsomely for his fraud, but the crazy thing is that there actually was a kernel of truth under all his extravagant claims. He had stolen the idea from transcontinental railroad workers who had used Chinese water snake (*Enhydris chinensis*) oil as a legit anti-inflammatory! But all he succeeded in doing was turning "snake oil" into a synonym for fraud. We face a similar moment today with LLMs. The underlying tech is real, but we're overselling it when we promise that it can act as anything from your programming intern to your therapist. In this talk I'll share a simple framework for evaluating not just *what* we build, but whether the things we build are net *good.* (1) Does it augment humans or replace them? (2) Can we deliver a better product *without* LLMs? (3) Does it enable something truly novel, good, and impactful, or would the world be mostly the same with or without it? We'll apply it to leadership scenarios you're likely to face in your job and see how you can be an advocate for building the company's great ideas responsibly. As technical leaders, we have the agency and the duty to steer our companies past snake oil hype so that we can make an actually positive difference in the world.

Every NGINX config encodes intent — is this a reverse proxy? an API gateway? an SSL terminator? — but that intent is never written down. At fleet scale, nobody can tell you what your configs actually do. This session shows how we taught a machine to read them. We classify NGINX server configs into eight canonical roles using a three-stage pipeline: parse the raw config into a structured directive tree with CrossPlane, then run two complementary classifiers against it — a precision-tuned rule engine that abstains when signatures are ambiguous, and an ML model that generalizes to configs the rules don't cover. A confidence-fusion layer blends them, auto-accepting confident calls and routing borderline ones to expert review. The counterintuitive lesson: we deliberately didn't just throw an LLM at this. The hybrid beats either approach alone — keeping rule-level precision while recovering the coverage rules lack. You'll see why "negative evidence" (the absence of a directive) is often the strongest signal, how an LLM-as-judge eval validated the design, and how a closed expert-feedback loop turns review hours into measurable accuracy gains. Live, against real configs — including yours, if you bring one.

Autonomous robotics demands advanced AI under strict embedded constraints such as limited compute, memory, and energy. This talk presents the Real-Time Embedded AI Framework (RE-AIF), a three-layer architecture that unifies deterministic real-time control with adaptive AI inference on resource-constrained systems. Built on a Perception–Cognition–Execution model, it enables synchronized sensor fusion, optimized inference, and reliable actuator control. RE-AIF combines C++ for real-time execution with Python-based AI modules via low-overhead bindings, achieving performance beyond single-language systems. It incorporates embedded optimizations such as quantized neural networks, ARM NEON/GPU acceleration, compile-time scheduling, and lock-free communication. Energy-aware techniques like dynamic voltage scaling and memory pooling ensure sustained, efficient operation. Real-world applications demonstrate improved precision, throughput, and 24/7 reliability, validating RE-AIF for mission-critical autonomous systems.

This session focuses on spotting those risks early by thinking through how an LLM app can be misused or broken. We’ll discuss common attack patterns like prompt injection, data leakage, tool abuse, and jailbreaks, using familiar setups such as RAG pipelines, agents, and function calling. We’ll also talk about how teams intentionally test these scenarios, what usually gets missed, and which defenses actually help in production. Attendees will have a simple, reusable threat-modeling approach and a practical checklist they can apply to their own LLM applications, without slowing down development or overcomplicating security.

When a critical service goes down at 2 AM, every second counts. But traditional incident response is a maze of manual steps: hunting through logs, correlating GitHub commits, pinging teams on Slack, and piecing together timelines while customers are impacted. At Slack, we solved this by building AI agents that think like our best senior engineers, but work at machine speed. Using custom MCP tools integrated directly into Cursor, our system transforms a simple incident alert into a complete investigation: automatically surfacing relevant logs, identifying suspect commits, mapping blast radius, and even drafting incident communications. This production-grade automation is already saving our team multiple hours per week and dramatically improving our escal response. This session will be useful for anyone building developer productivity tools who wants to see AI deliver measurable operational impact.

AI-infused applications demand a rethinking of our testing practices. Developers face a new class of challenge as LLMs become standard integration points in modern applications: non-deterministic behavior that traditional testing approaches were never designed to handle. The current wave of distributed, orchestrated, agentic AI systems is evolving fast and, if we're being honest, it smells a lot like the early days of microservices. In this session, we'll explore how your DevOps and testing practices must evolve when you wire AI into your applications. Not all AI failures look the same, and recognizing the difference is the first step toward building systems you can actually trust. We'll walk through practical testing and observability strategies, using open source tools that give you confidence in AI-infused applications at every layer of the stack. You'll leave with a concrete mental model for reasoning about AI failures and one grounding question: What if AI was just an API call?

Most teams think event-driven reliability means keeping Kafka online, avoiding consumer lag, and making sure messages keep flowing. But in real production systems, the harder question is: can you safely recover when something goes wrong? This session explores the architecture patterns behind replay-safe event-driven systems. We will look at how APIs, CDC pipelines, stream processors, consumers, databases, and reconciliation jobs interact when retries, duplicate messages, partial failures, out-of-order events, and historical replays become unavoidable. The talk will cover practical design patterns such as idempotency keys, deduplication, event ordering, outbox patterns, replay-safe consumers, audit trails, reconciliation workflows, and operational runbooks. Drawing from real-world experience building high-scale distributed systems and inventory platforms, we will discuss why reliability is not only about uptime. It is about being able to prove what happened, recover safely, and preserve trust in a business-critical state. Attendees will leave with concrete patterns for building event-driven systems that can survive failure, replay data, and recover without corrupting downstream systems.

As we shift from simple chatbots to long-running agents, we face a critical engineering challenge. The risk is no longer just bad output. It is memory poisoning. This occurs when malicious data permanently corrupts your vector database, causing agents to hallucinate or leak private information indefinitely. This session will present a Zero Trust architecture for Responsible AI starting prompt injection until agent isolation. We will dissect a reference stack built entirely on open source standards that treats your vector storage as a high-security vault. Attendees will walk away with practical techniques to: Replace risky API keys with cryptographic verification using SPIFFE and SPIRE, ensuring only valid code can access long-term memory. Use policies to write security rules as code, separating your safety logic from your application logic. Block sensitive data and malicious prompts before they are ever stored using tools like Microsoft Presidio. Join me to learn how to build agents that are resilient, audit-ready, and secure by design.

"I panicked instead of thinking. I destroyed months of your work in seconds." That's a Replit agent, after wiping a production database during an active code freeze. "I have failed you completely and catastrophically." That's Gemini CLI, after silently overwriting every file in a developer's project. These aren't edge cases. Between July 2025 and February 2026, documented incidents include a Claude Code session that ran terraform destroy on 2.5 years of student data for 79,000 learners, a supply chain attack that weaponized --dangerously-skip-permissions to steal 2,349 secrets from developers, and a three-layer sandbox escape where Claude Code reasoned its way past procfs restrictions, bubblewrap, and the ELF dynamic linker without a jailbreak. The flags are warnings dressed as features: --dangerously-skip-permissions, --yolo, --trust-all-tools. Developers use them anyway because approving 100 permission prompts per hour isn't a workflow, it's babysitting. Docker Sandboxes (sbx) changes this. Each agent session runs in a microVM with its own kernel, Docker daemon, and network stack. The agent gets full autonomy. Your host stays untouched. Attendees will leave knowing why container isolation is architecturally insufficient for AI agents, how the sbx isolation model works (microVM, network policy, credential proxy), and a concrete pattern for running agents in full YOLO mode safely.

Agentic AI-assisted engineering tools promise cleaner code, faster development, and fewer late-night debugging sessions. But do they truly deliver? In this live showdown, Viktor and Baruch will each use a different set of cutting-edge AI coding tools, like an IDEs and CLI agents (we'd name them, but honestly, things move too fast in this space), to develop a non-trivial IoT application, from initial setup to testing and debugging, all live on stage. Will the IoT bulb turn on by the end of the session, and which tool will make it happen? You don't know, we don't know, but we'll find out together—live on stage. You, the audience, decide which tool actually improves quality and productivity and which just adds noise instead of useful code. Bring your skepticism, cast your vote, and get ready for surprises.

You know that - A demo works on your laptop, then you deploy it elswere and it's not. Migrating a Kubernetes workloads from one platform to another is not just flipping the switch. I created the LLM app utilizing a small quantized open model (~4B, CPU-only, serving inside the cluster) running it on a local kind cluster on my M4 MacBook. However, once moved to the AWS EKS, the pod died with 'exec format error'. The fix exposed the next failure, and the next... a liveness probe killing the model server mid-load, ':latest' meaning different images on different clusters, kubelet garbage-collecting the multi-gigabyte model weights, a hardcoded DNS suffix, a NetworkPolicy silently doing nothing. Let's find out what lies between "works on my laptop" and "runs anywhere", because "Build once, deploy anywhere" is a claim you must earn.

Almost every asynchronous action at Meta passes through a single system most people have never heard of. The Facebook Ordered Queueing Service (FOQS), a fully managed, horizontally scalable priority queue, moves close to a trillion items per day for 300+ engineering teams, and it has become critical infrastructure for AI at Meta's scale. Async LLM inference, Llama serving, GenAI image generation, and AI compute demand control all ride on it. This talk traces how a queue originally built to absorb massive backlogs and prioritize work across highly heterogeneous producers and consumers grew into the reliability layer beneath Meta's AI stack supporting critical use cases like Ads, Integrity, AI Training and Whatsapp message delivery. It explains how one system came to serve hundreds of teams without them stepping on each other, how it keeps the most important work moving under enormous load, and how it evolved from isolated regional deployments into a globally distributed service that delivers region-level disaster recovery in seconds with zero client-visible downtime. The finale looks at how that same queue now acts as a control plane for shaping AI compute demand.

What happens when security measures cannot be used by everyone? Any security control that is not accessible becomes a barrier, and barriers trigger unsafe workarounds that create security risks. We face a paradox, security mechanisms designed to protect users can systematically exclude the most vulnerable populations, including people with disabilities and older adults, and this exclusion can become an exploitable vulnerability. Users facing accessibility barriers adopt insecure coping mechanisms: sharing passwords, delegating authentication to others, storing credentials insecurely, relying on weaker fallback paths, or abandoning security measures altogether. Each workaround is a predictable security failure caused not by user negligence, but by design choices that made the secure path inaccessible. This presentation introduces Secure-by-Inclusion, a new practical approach that ensures that security controls actually function for all intended users across diverse abilities, devices, and assistive technologies. We will walk through common patterns where security and accessibility collide, including CAPTCHAs, multi-factor authentication, biometric authentication, time-limited one-time codes, brittle account recovery flows, and inaccessible verification steps. For each pattern, we connect the accessibility failure to concrete security outcomes, then show safer, more inclusive alternatives. We will also look into the European Accessibility Act (EAA) and the WCAG 2.2 Accessible Authentication requirements, examining their implications for security design and testing. We will learn practical techniques for incorporating inclusive evaluation into security testing practices and identify accessibility gaps as security vulnerabilities. Accessibility and security might seem like separate disciplines, but they share common goals: protecting users and ensuring inclusive, trustworthy digital experiences.

As enterprises deploy agentic AI, everyone's building capabilities—but who's building the guardrails? When an autonomous agent generates a prompt containing AWS credentials, or a compromised data source injects malicious instructions, what stops that payload from reaching the LLM? This session reveals how I built SecurePrompt, a pre-flight security scanner that intercepts prompts before they're sent to any AI model—addressing the critical blind spot at the boundary of autonomous AI systems. You'll learn: 1. Real-world scenarios where credentials leak, prompt injections propagate, and PII compliance fails 2. Why I chose Go and rules-based detection for sub-10ms latency 3. Parallel scanning architecture for secrets, injection attacks, PII, and data exfiltration 4. Policy-as-code profiles for enterprise risk tolerances 5. HMAC-signed audit logs with causal traceability 6. Evolving from deterministic rules to LLM-powered semantic analysis Leave with practical patterns for implementing security at the prompt boundary—the layer nobody else is building.

AI agents are moving from demos to production. They're accessing databases, calling APIs, orchestrating workflows—but most lack basic security primitives that we've required for human users for decades. This talk covers the security infrastructure layer every AI agent deployment needs: The Challenge - Agents run with API keys: no identity, no audit trail, easy to leak - MCP servers proliferate without verification—shadow IT for the AI era - No visibility into what agents are doing or what they're connecting to The Solution: Three Pillars - Cryptographic Identity: Ed25519 keypairs give agents unforgeable identity. Not credentials that can be shared—proof of who they are. - MCP Server Attestation: Verify every MCP server before connection. Detect configuration drift. Know when tools change. - Behavioral Trust Scoring: Static allow/deny isn't enough. Trust scores adapt based on agent behavior over time. Live Demo I'll secure an agent from scratch: generate identity, connect to attested MCP servers, enforce capability policies, and show the audit trail. You'll leave with patterns you can implement whether you use our open-source platform (AIM) or build your own. The concepts apply to LangChain, CrewAI, AutoGen, or any MCP-based system. 20 years of enterprise security lessons, applied to the AI agent era.

A hidden layer, sealed off from the world. It’s not a secret society or a Cold War bunker, it’s the Shadow DOM. Tucked quietly behind your browser’s renderer, it protects the structure within, keeping your styles and scripts from spilling out into the chaos of the global page. The Shadow DOM isn’t about hiding, it’s about harmony. We’ll explore how this quiet guardian helps us build cleaner, safer, more robust components. Shadows aren’t something to fear; they’re where the web truly comes together.

AI has made implementation faster, cheaper, and more widely available. That changes the real bottleneck in software. Every team can generate code and spin up agents. The advantage moves to a different layer: knowing what is worth building, who it is for, how people will discover it, and how the product should behave once they do. This keynote introduces the system of public signal, user intent, agent experience, distribution loops, and product judgment that helps builders decide what deserves to exist before they commit time, infrastructure, and trust to building it. We will look at how AI changes the software lifecycle from “can we build it?” to “should this exist? When anything can be built, the most valuable builders are the ones who can read signal early and shape the right experience.

Let's see how AI is becoming a first-class citizen in your browser! In this session, I'll show you Chrome’s Built-In AI APIs - now available behind feature flags in regular Chrome and evolving in Canary. From language detection to summarization and even creative writing, these APIs promise to revolutionize how we build web applications. Whether you're a developer, tech enthusiast, or decision-maker, this talk will equip you with insights and inspiration to stay ahead in the fast-moving AI landscape.

Slow CI/CD pipelines delay code from reaching production and frustrate development teams. Beyond testing and compilation, a major bottleneck comes from repeatedly fetching dependencies from remote artifact repositories, a slowdown that also affects developers in their daily work. This presentation will show how to eliminate these delays by caching build and runtime artifacts such as Docker images, NPM packages, Go modules, and even Git clones and fetches. Since most artifact repositories deliver dependencies over HTTP, a reverse caching proxy like Varnish can dramatically accelerate artifact delivery at scale. We’ll break down the actual HTTP requests behind docker pull, git clone, go get, and npm install, and demonstrate how Varnish can be configured to cache these assets effectively, without compromising access control or security. We’ll also compare the power of an HTTP reverse caching proxy like Varnish to other optimization strategies such as disk caching & shallow fetches.

Let’s be honest: if your .NET Framework app was easy to migrate, you would have done it three years ago. You’re likely stuck with legacy WCF services, deep dependencies on System.Web, or a NuGet graph that looks like a bowl of yarn. The .NET Upgrade Assistant is a great start, but it’s the last 20% of the migration—the part that the tools can’t automate—that actually keeps us up at night. In this session, we’re moving past the "hello world" migration demos. We’ll look at real strategies for modernizing .NET Framework 4.x apps into .NET 8/9/10 without a complete rewrite. We will get into the weeds on: The "Bridge" Strategy: Using YARP (Yet Another Reverse Proxy) to migrate your app piece-by-piece rather than a "Big Bang" release. The Dependency Trap: What to do when your critical library hasn't been updated since 2014. Modernizing the "Un-modernizable": Strategies for dealing with legacy config systems and static state that modern .NET hates. This isn't a theoretical talk about "embracing innovation." It’s a tactical session for developers who need to get their legacy code onto a supported, performant, and AI-ready platform without breaking the business.

We spend too much time chasing model benchmarks and not enough time engineering the architecture that feeds them. Most production AI failures are not caused by a lack of model intelligence, but by poor information design. If you are still relying on long-form prompting and naive RAG, you are building systems that are destined to hallucinate or break at scale. This talk moves past the hype of prompt engineering and dives into context as a persistent, versioned infrastructure. We will examine the shift from stateless chat sessions to structured context engineering, using a mental model borrowed from engineering management: setting boundaries, managing state, and delegating tasks through coordination protocols. We will cover technical areas like: - The evolution of AI coding workflows: Moving from iterative chat to spec-driven development and graph-based task management. - The limits of RAG: Why semantic similarity fails for complex business logic and how to build a core data layer with rich, structural metadata. - Decoupled Planning: A three-tier architecture that separates the planning phase from execution, allowing for human-in-the-loop validation and deterministic outputs. You will leave with a systematic framework for context architecture that replaces black box prompt tweaking with auditable, glass-box systems. Stop guessing with prompts and start engineering your state.

We have all been there. You need a database or a quick node environment, so you throw "FROM node:latest" into your Dockerfile and deploy. It works, but you have just introduced a black box into your Kubernetes cluster. For the Developer, it’s a quick fix. For the Platform Engineer, it’s a nightmare. Most upstream images from public registries are a roll of the dice. They come pre-packed with critical vulnerabilities, unknown binaries, and bloated libraries that you didn’t ask for and definitely don’t want running in your secure environment. In a world of Zero Trust, why are we trusting random upstream maintainers with the keys to our infrastructure? In this session, we will dismantle the myth that "open source means secure" when it comes to container images. We will walk through the architecture of a truly Secure Software Delivery pipeline—one that establishes trust before a single line of code is committed. We will discuss: - The hidden dangers inside popular "official" images. - Moving beyond basic scanning: Why you need SLSA L3 provenance, SBOMs, and cryptographic attestation. - The "Build vs. Buy" dilemma: Should you curate your own base images or rely on a hardened upstream provider? Join us to learn how to bridge the gap between developer velocity and platform security, ensuring that the only thing running in your cluster is code you actually trust.

Most AI agents today suffer from digital amnesia: they forget conversations, lose context between sessions, and treat every interaction as if meeting you for the first time. We explore how knowledge graphs can serve as persistent, temporally-aware memory systems for AI agents, moving beyond static vector embeddings to dynamic, relationship-rich storage that evolves with each interaction. This talk covers practical implementation patterns for building graph-based agent memory, comparing direct database integration with tool-based approaches through frameworks like Graphiti and Zep. You'll learn how to extract entities from conversations, model temporal relationships, and implement cross-session continuity that makes agents truly conversational partners rather than stateless responders.

Moving from a viral demo to reliable enterprise AI is the hardest hurdle in modern software engineering. Because agents are inherently non-deterministic, validating performance requires a granular look at the "why" and "how" behind every action. This session explores how observability redefines agentic evaluation beyond binary pass/fail testing, shifting the focus from the result to the entire reasoning chain. Featuring a live demo using Arize Phoenix and LangGraph, we’ll showcase how to trace complex loops and automate evaluations in real-time. What you’ll learn: Beyond Output: Why judging final answers alone is a recipe for silent failure. Live Implementation: Using Arize Phoenix with LangGraph to visualize traces and debug agentic "thought processes". The Playbook: An incremental framework for evaluation-first development. Are you ready to stop guessing and start measuring? Join us to master the art of agent evaluation.

Host of the Tech Leaders Panel at We Are Developers in San Jose, 20 Mins | Sponsorship Inclusion for AWS _____________________________________________________________________________________________

AI features now involve agents, tools, databases, and external systems working together. Most teams still test them manually or rely on mocks that do not reflect real behavior. In this session, I will show how to test AI workflows using Testcontainers and real dependencies running locally. We will build a setup where an AI agent interacts with tools and services, and run tests against it in a reproducible environment. You will see how to spin up dependencies on demand and validate real interactions instead of guessing. This session is focused on making AI systems testable, reliable, and easier to develop.

Modern engineering teams move fast — but brittle tests, flaky mocks, and sluggish integration pipelines can bring even the strongest React + Node backends to a crawl. One area that consistently gets often overlooked is database testing for the APIs powering today’s web applications. SQL tests are skipped entirely because they usually require a persistent database instance, complicating CI/CD pipelines and slowing development. But there’s a better way: using SQLite as an ephemeral, SQL‑compatible stand‑in for your production database. This session introduces a battle‑tested approach to backend API testing that replaces fragile mock frameworks with a lightweight, in‑memory SQLite database that behaves like the real thing. The payoff is immediate: faster feedback loops, more reliable tests, and dramatically simpler debugging. You’ll learn how to spin up a fully isolated test database for each suite, seed it with realistic data, and run true end‑to‑end API tests without touching production infrastructure. We’ll walk through schema setup, SQL‑driven test design, teardown automation, and strategies for keeping tests blazing fast as your backend grows. This talk offers a fresh perspective on a familiar challenge: testing backend logic as it actually runs, not as mocks pretend it runs. Expect live coding, practical patterns, and insights drawn directly from real‑world engineering work. If you’re ready to elevate your backend testing strategy and ship with confidence, this session will show you exactly how to get there.

In the high-stakes world of algorithmic trading, infrastructure costs and execution latency are the primary enemies of alpha. But what if you could run a production-grade, event-driven trading engine for less than the cost of a cup of coffee per year? This session explores the architectural blueprint of LambdaForge, an open-source trading platform built entirely on a serverless stack. We will break down how to orchestrate Python microservices, AWS Lambda, and EventBridge to handle real-time market data and execute high-stakes trades with sub-second latency, all while maintaining an operational cost of ~$0.15/month.

If vibe coding is giving in to vibes and one-shotting code that you are likely to throwaway, then agentic engineering is the deliberate practice of designing systems to help agents create high-quality code that gets better over time. In this talk, we cover the agentic engineering loop and how to leverage it to multiply your output at every phase. We cover the new challenges that arise when agents write most of the code and we provide useful mental models for thinking about software development in the world of agents. This talk is for anyone that wants to adopt an agent-first approach to software development and get the most out of agents and the latest frontier models.

At Netflix, performance waste is everywhere- and almost no one is looking for it. Degradation is silent. It compounds. The manual cost of closing the loop (profile, analyze, trace, fix, validate) means most inefficiencies quietly burn compute for months before anyone acts. By the time a human gets there, the damage is done. We decided the loop should close itself. We built an autonomous agent that continuously hunts performance inefficiencies across live production services, traces them to source code, proposes fixes, and validates results through canary deployment- grounding every decision in measured production outcomes, not model confidence. In this talk, we'll share what it actually took to make an autonomous agent trustworthy enough to act in production: where it earns autonomy, where it doesn't, and a novel approach that changed how we think about agent reliability entirely. One finding the agent surfaced- caught, fixed, and canary-confirmed- with no ticket, no oncall, and no performance engineer in the loop. This is not a demo. This is already in production at Netflix.

The rise of generative AI has created a significant paradox at the core of the software industry. On one side, AI co-pilots are automating entry-level tasks—such as code generation, testing, and boilerplate work—leading to a damaging "broken first rung" for recent computer science graduates, with job postings decreasing sharply and requirements for experience increasing. This disruption threatens to destroy the crucial talent pipeline needed for future innovation, as senior engineers are not simply born; they are developed through mentorship and hands-on experience that AI is now replacing. At the same time, this powerful technology democratizes development, enabling non-engineers (citizen developers) to build functional applications more quickly than ever before. This rise in easy, low-code/no-code, AI-assisted development presents a strong, deflationary threat to established software companies, service agencies, and the traditional billable-hour model. The key question is: how can organizations capitalize on AI’s undeniable productivity boost without incurring disastrous technical debt, security vulnerabilities, or organizational self-destruction? This session will go beyond the hype to present a dual-focused strategic plan, explaining how engineers must shift from being mere coders to architects and how companies should implement strong AI governance frameworks to manage the wave of decentralized code creation—ensuring the future pipeline is reinvented, not replaced.

LLM-accelerated coding has dramatically increased the pace at which developers can fix bugs and write whole new features. But a lot of companies that have wholeheartedly embraced AI assistance for coding have discovered that with coding fast, new points in the software development lifecycle become the bottleneck. In particular, if people are writing code 2x, 5x or 10x faster, how do you review all that code? This talk explores the current landscape of solutions to this extremely timely problem, including changing job titles, building guardrails, writing far more detailed product specifications and tests, using yet more LLMs to review the PRs themselves, and a surprisingly frequently-cited alternative: just ship stuff slower.

95% of AI projects fail. And according to MIT (https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf), the vast majority of AI initiatives never even make it past the prototype stage. In 2026, the problem isn’t a lack of models or ideas (builders have plenty, after all)—it’s a fundamental misunderstanding of what AI is for. We’ve all seen the billboards promising that AI will magically evaporate the most complex business problems or seamlessly abstract away entire workforces. It’s a high-priced fantasy. Many organizations treat AI as a "magic pill"—a way to bypass the difficult, manual work of evaluating how technology actually supports business growth. They invest in brittle, fragmented stacks of point solutions, chasing automation hype without ever defining a purpose. The result? A graveyard of expensive prototypes that can’t scale, can’t adapt, and eventually, just stop working. In this session, Tara Hernandez (VP of Developer Productivity, MongoDB) talks about her work ensuring that MongoDB becomes part of the “5% Club”: the group of organizations who have been able to successfully leverage AI to advance their business. What if the technical stack behind the AI is an implementation detail within a much larger, requisite culture shift? We’ll explore why successful AI deployment requires identifying a core business purpose before touching a single line of code, and staying aligned with your business goal as your AI scales. Tara will share how the 5% club align their culture and goals first, and then build a unified data foundation that supports continuous adaptation. You’ll learn why the most critical technical puzzle pieces—retrieval quality, scalability, and grounded context—are the final, critical steps in an AI deployment journey that begins with "why," not "how".

Incidents are usually reviewed as timelines: what failed, who owned it, and how we restored service. That works well for understanding a single outage. But when you operate platforms used by many services, the root causes change while the user-impact patterns start to look familiar. This talk introduces incident shapes: a way to look at failures by the pattern they draw across impact, time, and blast radius. I’ll use a few public incidents as reference points, including CrowdStrike’s outage, AWS’s DynamoDB outage where retry amplification played a role, Cloudflare’s WAF incident, and GitHub’s 2018 database failover incident. The incident shapes are useful because they change the questions we ask. A sudden spike makes us look at rollout containment and rollback paths. A slow burn pushes us to examine saturation, queues, and retries. A repeating sawtooth suggests the system may be recovering temporarily without becoming stable. Fan-out patterns expose the risk of shared platform layers. Boundary shifts are often the hardest to catch: one layer reports success, while users are still having a bad experience. The main idea is simple: the shape of user impact can tell us what the what the architecture failed to protect against. Attendees will learn how to quantify impact using breadth, depth, and duration, and how to connect those shapes to engineering responses such as staged rollouts, rollback automation, retry budgets, semantic canaries, cell isolation, contract checks, and end-to-end verification. The goal is to make postmortems more useful: not just to explain what happened, but to help design platforms that are harder to break in the same way twice.

Most AI agents misuse MCP and treat tools as prompt-time function calls: tool definitions and results are repeatedly injected into the context, tokens are wasted, and context rots. The result? Slower, less reliable agents, and the misleading conclusion that “MCP sucks, CLIs are better.” To challenge this narrative and show how agents can get the best of both MCP and CLI, we’ve built `mcpc`, an open-source universal CLI client for MCP. It maps MCP operations to intuitive CLI commands, which agents quickly pick up through `--help` without external skills. It turns out, CLI is the perfect local interface for agents to interact with MCP, giving them access to full protocol capabilities, including modern features like code mode or progressive tool discovery, through a single `Bash()` tool call, while leveraging MCP’s standard remote interface for server discovery, authentication, payments, and access control. To once and for all kill the MCP vs. CLI debate and show those two technologies are not exclusive but complementary, we’ll present evals comparing the performance of agents using naive MCP, modern MCP, native CLIs, other MCP CLIs, and `mcpc`, in various real-world scenarios.

Everyone can build an AI agent. Almost nobody knows how to run thousands of them safely in production. Over the past two years, we've watched AI agents evolve from demos into software that writes code, answers customers, automates workflows, and makes decisions. The challenge has shifted from building smarter agents to operating them reliably at scale. Having built one of Meta's first internal AI agents and now leading Guild.ai, CEO and Co-Founder, James Everingham has seen firsthand where production systems fail. It's rarely the model. It's the surrounding infrastructure: context management, permissions, observability, cost controls, versioning, evaluation, and governance. This session explores what changes when AI agents become real production systems instead of prototypes. He’ll cover the architectural patterns that separate successful deployments from expensive experiments, why "agent engineering" is becoming its own discipline, and the infrastructure every engineering team should think about before deploying autonomous software. Attendees will leave with practical frameworks for designing AI agent systems that are observable, secure, reusable, and capable of evolving over time, not just impressive during a demo. Whether you're building your first agent or managing hundreds across an organization, this talk offers lessons from operating AI where reliability matters.

From the early steps that set me onto this path, to the challenges of mentorship and leadership roles, I'll discuss what it means to thrive as an Individual Contributor (IC) in a world that often pushes for management. This talk will not only reflect on my personal experiences but also provide insights and strategies for engineers who aspire to make a meaningful impact while staying true to their technical passions.

As AI moves from chat demos to “do-things” software, the platform requirements change: identity, policy, network controls, data governance, audit, and safe tool execution become mandatory. This session explains why a private application platform on private cloud is the most reliable foundation for enterprise AI—especially for agentic workflows and development assistants that touch sensitive systems. We’ll map the core platform capabilities (runtime, workload identity, secrets, supply chain, service brokering, observability, guardrails) to real AI components: model endpoints, vector stores, tool APIs, MCP servers, and skills routing. You’ll leave with a reference architecture and a pragmatic checklist to evaluate whether your current platform can safely run “full-blown” AI experiences.

Everyone says AI made developers faster. But did it really? This session dives into the hidden layers of AI-assisted development: How it affects focus, flow, and trust. Drawing from real-world experience building AI tools and observing developer behavior, We'll reveal what we gained, what we lost, and what we must redesign to make productivity human again.

Every enterprise thinks their AI adoption story is unique. It isn't. After leading GitHub Copilot's rollout across Fortune 100 engineering teams at Microsoft and before that, launching Gemini Code Assist at Google Cloud with hackathons in over 60 countries I've seen the same patterns repeat at scale: the initial excitement, the plateau, the backlash, and finally the transformation. This isn't a talk about features or benchmarks. It's about the human journey: how SDLC actually changes when AI becomes a collaborator, why adoption curves look nothing like what vendors promise, and what separates teams that truly level up from those who just add a new tab to their IDE. I'll bring real patterns from the frontlines with honest stories, no marketing spin.

After spending over a billion tokens on AI-assisted coding over the past two and a half years - from creating one of the first agentic coding tools (Kaguya) to daily production use - I've realized that vibe coding and traditional software engineering are not opposites. They exist on a spectrum. This talk introduces a four-level framework for agentic coding: 1. Vibe coding - let AI go wild, forget the code exists 2. Agentic coding with discipline - version control, file-level understanding, basic testing 3. Agentic software engineering - CI, pre-commit hooks, function-level understanding 4. High-quality software engineering - line-by-line understanding, interactive code reviews, indistinguishable from handwritten code You'll learn when to use each level, how to level up your agentic coding practices, and why the real problem with "slop" isn't AI - it's not putting enough thought and effort into the process. The key insight: more tokens spent doesn't have to mean more garbage. It can mean higher quality code, better research, and deeper understanding.

Cloud companies spent years getting enterprise to go off-premise; now we're going to spend years getting them to go on-premise. This talk provides a practical snapshot of the local AI landscape and what building with on-device AI means for developers in 2026. We'll survey the current ecosystem, from open-weight models and model architectures to runtimes, inference engines, quantization techniques, and deployment options. We'll compare today's leading on-device models, discuss which workloads are best suited for local inference, and examine how developers are combining local and cloud models into hybrid systems. We'll also explore the broader trends shaping the ecosystem: the rise of open weights, improvements in model quality and efficiency, and the growing importance of AI sovereignty. We'll also discuss where local AI still falls short, including hardware constraints, operational complexity, and the workloads where cloud inference continues to be the better choice. Whether participants are early in their exploration of local models or already deeply embedded with on-device AI, this session will provide an up-to-date map of the ecosystem, explain the major technologies driving it forward, and offer practical guidance for choosing the right tools and architectures for their next project.

If you're trying to get agents out of a prototype and into the real world safely, this session is for you. Writing code used to be the hard part. AI changed that. But the infrastructure to run agents in production hasn't kept pace, and most teams are discovering this the expensive way. Agentic deployments fail differently than traditional software. Credentials leak across task boundaries. State persists when it shouldn't. Agents reach systems they were never meant to touch. The instinct is to write more rules. Rules don't fix structural problems. This session makes the case that agent deployment is an infrastructure problem and lays out what the fix actually looks like: isolated sandboxes per task, credential proxying that keeps API keys out of agent reach, tool-level access control, and event streams that make every agent interaction observable and reproducible. To prove it isn't theoretical, we spin up a production-ready agent environment live on stage in under a minute. Watch the same agent that causes a failure in a standard environment get stopped cold by the architecture itself. The teams shipping agents fastest today aren't winning on model quality. They're winning on infrastructure. Come if you're shipping agents into production.

The AI revolution has accelerated software development timelines, but at what cost to security? While teams rush to integrate LLMs and other AI capabilities into their applications, security is overlooked as new attack surfaces are created in places traditional security measures weren't designed to handle. This presentation exposes the hidden vulnerabilities in AI-powered applications through live demonstrations of common attack vectors that exploit user input channels. Attendees will perform their own attacks on their mobile devices or laptops using prompt injection to bypass traditional security controls and compromise entire systems - with nothing more than carefully crafted text or images. By the end of this session, you'll have actionable strategies to identify vulnerabilities in your AI applications, practical tools to implement security controls without sacrificing innovation velocity, and a security mindset that treats AI components as critical infrastructure requiring specialized protection.

Most developers using AI coding assistants are stuck in a loop of generating code, eyeballing it, and hoping for the best. No architecture context, no validation pipeline, no way for the coding agent to learn from past mistakes. The result: most of what the AI writes gets thrown away. This session introduces a battle-tested engineering loop - Plan, Implement, Validate - that treats AI assistants as true engineers who need architecture docs, project rules, and a validation pipeline, not just a prompt. You'll see how to front-load context so the AI understands your codebase from minute one, structure implementation as manageable tasks the AI can execute reliably, and build a multi-layered validation system that catches most issues before you have to review the code. The real unlock isn't better prompts - it's building a system that evolves. When your AI makes a mistake, you don't just fix the code; you fix the system that allowed it. By the end, you'll have a concrete, tool-agnostic framework you can apply with any AI coding assistant to consistently ship production-ready code.

While the "do you have to read the code" debate rages on, we've been hard at work figuring out how to get models to write code that gets better over time, not worse. We'll discuss why current model training approaches and benchmarks checking "do the tests pass" are not enough, and how we're approaching evaluating the long-term-quality of LLM-generated code.

AI infrastructure has long been dominated by a single ecosystem, but the model is changing. In this session, Kyle Bell from TensorWave explores how to build & operate large-scale AI clusters on AMD Instinct GPUs using Kubernetes as the orchestration backbone. Attendees will learn about: AMD-specific technologies like ROCm, GPU Operator, & RVS (ROCm Validation Suite). Kubernetes integration patterns for AI scheduling, node triage, & GPU telemetry. Slurm-on-Kubernetes for HPC-style orchestration, & how it impacts resource management and observability. Custom convergence testing & GPU validation pipelines that ensure reliability at scale. This talk provides an open-source roadmap for operators, ML engineers, and platform teams who want to move beyond vendor lock-in while maintaining reliability, performance, & observability at scale. Viewers will walk away with practical guidance on designing Kubernetes clusters purpose-built for AMD Instinct GPUs, integrating ROCm into existing cloud-native toolchains, applying reliability engineering patterns for AI workloads, & building open sustainable infrastructure that contributes to a more diverse AI hardware ecosystem.

Building apps with TypeScript is the norm these days, but there's one major pain point, speed. At first, everything runs smoothly, but as your project grows, build times drag, your editor lags, and even basic code completion slows to a crawl. The good news? A solution has been hiding in TypeScript’s documentation for years, overlooked but incredibly effective. In this talk, we’ll uncover this hidden gem, optimize your setup, and keep TypeScript fast as your app scales.

Large Language Models are often described as if each generation introduces an entirely new architecture. In practice, most modern LLMs still retain the transformer core, but their real progress comes from a series of targeted design changes around attention, positional handling, feed-forward computation, routing, and memory efficiency. This talk explains LLM architectures through the engineering tradeoffs that shaped modern models: why some attention mechanisms evolved for lower inference cost, how architectural choices influence long-context behavior, why sparse activation changed the economics of scale, and how these shifts affect real-world deployment. Rather than treating LLM architecture as a static diagram, this session presents it as a set of design decisions made in response to practical constraints in latency, memory, context length, and system efficiency. Attendees will leave with a clearer mental model of what remained stable, what changed, and why those changes matter.

This session explores how today’s most powerful AI-based coding tools are shaping the future of accessible technology. With tools like GitHub Copilot, ChatGPT, and other AI code assistants becoming mainstream, developers face both new opportunities and new risks. This session will provide a candid overview of the leading AI coding platforms and evaluate how well they support accessibility—from generating accessible code patterns to avoiding common pitfalls that exclude users with disabilities. We’ll also discuss their role in remediation: Can AI help fix inaccessible code, or does it introduce new challenges? To ground the discussion, we’ll showcase real-world examples of accessible web and native mobile products built with the help of AI tools. Attendees will walk away with practical insights on what AI coding tools can (and can’t) do today, best practices for ensuring accessible outcomes, and a vision for how accessibility professionals and developers can “vibe” with AI to build more inclusive digital experiences.

Everyone's pitching "agentic," "AI-native," and "autonomous" — but what's actually getting term sheets? In this fast-paced 30-minute conversation, Mariane Bekker (Head of Developer Relations, You.com) sits down with top VCs to cut through the noise and get specific: which categories are seeing real capital move, what separates a fundable agent startup from a feature wrapped in a demo, how diligence has changed now that every deck claims to be "agentic," and where the smart money is placing bets for the next 12 months. Expect direct answers, real portfolio examples, and zero fluff — a session for founders who want to know what VCs are actually looking for, not what they say at conferences.

Software factories are not products. They are a pattern built from a few core capabilities. We will review those capabilities, assemble a software factory from them in under 20 minutes, and see what kind of work it is good for.

Session details will be announced soon.

Most platforms add AI agents as apps: the agent runs with the permissions of whoever invokes it. Simplest thing to ship. At 250,000 teams, serving enterprises that audit every access, that model fell apart. This is how monday's R&D org rebuilt agents as first-class users, with their own identity, permissions, and audit trail. The first architecture was the obvious one: an agent could do only what both it and the invoking user were allowed to do. Simple to build, it broke at scale. The agent's access changed with every invoker, so no one could say what it could actually reach. Actions were attributed to the human, leaving no per-agent audit. And a shared agent became a leak risk, exposing its invoker's data to everyone allowed to run it. Fixing this meant making a non-human a first-class user inside a system built for humans: its own identity, scoped least-privilege permissions, admin-managed provisioning, and a place in the workspace where it can be assigned work and audited. The payoff was counterintuitive. Once an agent is a user, 20 years of enterprise identity infrastructure (SSO, RBAC, provisioning, audit logs) works for it for free, instead of a separate control plane for AI. One enterprise built 25 agents, each needing different access. Before, any agent could read what its invoker could read and pass it to the whole team. Now each is shared across the team and never touches data it was not explicitly granted. The permission models, the tradeoffs we got wrong first, and what it takes at scale. From the applied AI perspective, Why agent identity is the central design problem for AI at work. Expect real systems and real failure modes.

Writing code is no longer the bottleneck in software development. Today, we can describe what we want in natural language and (mostly) receive entire applications in a few minutes. But while tools and demos move fast, a deeper topic largely stays behind: what happens to programming languages, compilers, and responsibility when humans stop writing the code themselves? We have all been promised, that everything will be done autonomously when AGI is here, but what about until then ... the next 3-5 years? Is your current stack/your current favorite programming language ready for real work relief professional environments? If software is increasingly generated from intent rather than authored line-by-line, then many assumptions baked into our current languages begin to crack. Syntax stops being the primary interface. Compilers are no longer just translators. Code reviews no longer guarantee understanding. And "the AI wrote it" becomes an unacceptable answer to questions of security, correctness, and long-term maintainability. We will explore how language design must evolve beyond syntax toward intent, constraints, and guarantees — and why this shift matters not just to developers, but especially to CTOs and tech leaders responsible for systems they may no longer fully read or write themselves. We’ll examine what responsibility means in a world of generated code, how engineering judgment changes when implementation becomes fluid, and why senior engineers become more critical—not less—in AI-native teams. Finally, we’ll look at which existing language ideas already point in the right direction, which ones quietly break under vibe-driven development, and what a future “vibe-aware” programming language would need to get right to be trustworthy in production. This session is an invitation to stop treating vibe coding as a novelty — and start treating it as a forcing function to rethink the core of software engineering itself.

Logging systems are designed to help us understand failures, but what happens when the Logging itself becomes the cause of an outage? In this session, I will walk through a real-world incident involving Amazon ECS where the default logging configuration used blocking mode with CloudWatch as the log destination. When CloudWatch experienced an outage, application containers continued attempting to push logs while buffering them locally. As the logging buffer reached its limit, containers became blocked waiting for the logging driver, ultimately impacting application availability. This talk explores how a seemingly harmless default configuration can create an unexpected reliability risk in distributed systems. We will look at how ECS logging works under the hood, why blocking mode can create cascading failures during downstream outages, and how switching to non-blocking mode can isolate application workloads from logging system failures. I will share the investigation process, architectural decisions, and practical lessons learned from redesigning the logging strategy to prevent observability dependencies from affecting production workloads. Attendees will leave with actionable guidance on designing resilient logging pipelines and avoiding a class of failures where logging infrastructure unintentionally becomes the single point of failure.

As organizations rapidly adopt Generative AI and autonomous AI agents, ensuring the reliability, safety, and trustworthiness of AI-powered systems has become a critical business and engineering challenge. Unlike traditional software, AI systems introduce unique risks such as hallucinations, bias, model drift, prompt injection attacks, unpredictable behavior, and compliance concerns that cannot be addressed through conventional testing approaches alone. This session explores the emerging discipline of AI Assurance and the evolving role of quality engineering in validating AI systems at enterprise scale. Attendees will gain insights into modern strategies for testing and evaluating AI applications, including large language models (LLMs), Retrieval-Augmented Generation (RAG) systems, and AI agents. The discussion will cover key areas such as AI evaluation frameworks, safety and security testing, continuous model validation, observability, governance, and responsible AI practices. Through real-world examples and practical lessons learned, participants will discover how leading organizations are building confidence in AI solutions while balancing innovation, regulatory requirements, and customer trust. The session will also examine how quality engineering teams are evolving from traditional test execution toward becoming stewards of AI reliability, transparency, and accountability. Whether you are a quality engineer, software developer, architect, engineering leader, or AI practitioner, this session will provide actionable insights and a practical framework for building, testing, and governing trustworthy AI systems in production environments.

Most large organizations still plan infrastructure capacity using spreadsheets, manual reconciliations, and tribal knowledge. It works at small scale. It collapses at hyperscale. As systems grow more interdependent, one team’s workload change silently creates induced demand across shared compute, storage, and platform layers. Forecasts get revised late in the cycle. Finance loses confidence. Engineering overprovisions to stay safe. Toil increases while accuracy decreases. In this talk, I’ll walk through how to replace spreadsheet-driven capacity planning with a self-serve forecasting platform built using control plane design principles. Instead of static files and ad-hoc meetings, forecasting becomes an operational system with explicit dependency modeling, automated recomputation, validation gates, audit trails, and clear ownership boundaries.

Most iOS performance testing focuses on short benchmark-style validation such as launch time, API latency, and crash-free startup behavior. In practice, many production failures only emerge after hours of sustained real-world usage. Applications that initially feel smooth gradually degrade due to thermal throttling, memory accumulation, background process contention, frame pacing degradation, and main-thread amplification effects that simulators often fail to reproduce. This session explores performance as a systems problem rather than an isolated metric problem. Using a real production case study involving an airline crew application designed to operate during 18-hour flights without WiFi connectivity or server fallback, the talk demonstrates how long-session degradation patterns emerge over time and why traditional benchmarks consistently miss them. The session walks through practical techniques for diagnosing sustained performance degradation using Xcode Instruments, including Energy Log, Time Profiler, Leaks, Allocations, Core Animation, and os_signpost instrumentation. Attendees will learn how to instrument warm-start latency, track thermal state transitions, analyze FPS degradation, and correlate performance signals across extended session timelines on physical devices. The focus is highly practical and grounded in production engineering experience, providing mobile engineers and performance-focused developers with repeatable approaches for identifying degradation before it becomes user-visible in production systems.

AI agents are starting to pay for the APIs they call, no keys, no billing dashboards, no checkout. In this session, Brian Whippo, Senior Director of Integrations and Developer Tooling at the Algorand Foundation, walks through x402, an open protocol that embeds payment logic directly into HTTP requests, letting agents transact per call in real time. Brian will cover how to turn any API into a paid endpoint, what a resource server and facilitator do under the hood, and why instant-finality settlement matters for high-frequency agent traffic. He'll also share how developers can put this into practice. Attendees will leave with a working understanding of the protocol and a clear path to building their first paid endpoint.

Large language models are transforming how we build software, but physical AI systems expose a hard limit: you cannot recompute reality. When robots, sensors, and production systems interact with the real world, failures are causal and time-based, not semantic. You cannot go back to record sunlight you missed, human behavior you never captured, or robot telemetry lost to fragile connectivity. Backfills rewrite history. Late data arrives with new stories. Model performance drifts without obvious errors. In this talk, I will show how these constraints fundamentally change how we design ML data platforms for robotics, agriculture, manufacturing, and other physical-world domains. Using real production workflows, I will walk through how engineers correlate time-aligned telemetry, inference metadata, and operational events to debug subtle drift and root causes that dashboards and LLM-based tooling often miss. We will cover concrete architectural patterns for capturing irreversible data reliably at the edge, building reproducible ML pipelines when recomputation is impossible, managing late and out-of-order data without rewriting history, and unifying analytics, training, and debugging on a shared data backbone. I will close with where LLMs do fit powerfully in this workflow, and why physical AI still needs fast, reliable analytics as its foundation.

We like to think our decisions are logical. But they’re often not. Cognitive biases can trick us into choosing the wrong solution, underestimating complexity, or overestimating our abilities. In this talk, we’ll uncover the most common mental shortcuts developers fall into and how they impact real engineering work. By recognizing these patterns, you’ll be able to make clearer decisions, avoid subtle pitfalls, and build better software.

Green CI. Clean eval suite. Staged rollout looked fine. Then your agent hit an edge case at 2am, chained three tool calls nobody anticipated, and did something irreversible. Your evals didn't catch it. They couldn't. They were never designed to. This is the talk the agent ecosystem needs to have right now — because we've spent two years obsessing over eval quality and almost zero time on what happens *after* the agent is deployed and acting in the world. **Evals are a pre-flight checklist. Your agent is already in the air.** I'll show you exactly where the gap lives — and how to close it with a runtime verification layer you can bolt onto any agent stack this week: - **Why the gap is structural, not a skill issue.** Evals test known distributions. Agents encounter unknown ones. No eval suite survives contact with real users at scale. - **The failure taxonomy nobody publishes.** Tool call hallucination under load, trust decay in multi-step chains, silent state corruption between agent hops — with real examples from production systems. - **Runtime verification without the rewrite.** How to instrument your execution graph with lightweight trust checkpoints — behavioral tripwires that fire *during* execution, not in your test suite. - **Halt, retry, or escalate?** A decision framework for real-time agent health that doesn't tank your latency or annoy your users. You'll leave with a concrete verification architecture, a failure taxonomy you can use in your next incident retro, and serious second thoughts about that agentic pipeline you're about to ship.

With a global daily user base in the hundreds of millions, AI agents are rapidly becoming a primary interface for how people discover, evaluate, and purchase products. Enabling those products to be listed and paid for directly through agents opens an entirely new, and enormous, commerce channel. The Agent Commerce Protocol (ACP) and Shared Payment Tokens provide a secure framework for agent-driven commerce within Stripe’s ecosystem, without exposing payment data or sacrificing user control. This session walks developers through the complete implementation: setting up Stripe integration, creating permission-based payment tokens, interacting with ACP endpoints, and designing trustworthy user experiences. You'll learn how to enable your agents to transact safely and predictably, handling everything from checkout flows to error scenarios and webhook events.

Here's a scenario most API teams have lived through: you set a rate limit of 40 TPS, your downstream averages 2.3 seconds per call, and your executor tops out at 25 threads. The limiter is happily approving work. The pool can't actually run it. Throughput collapses and nobody can explain why, because every component looks correctly configured in isolation. The root cause is that teams size thread pools, HTTP connection pools, and database pools independently — usually from defaults or past incidents — instead of from the relationship between them. The math isn't complicated. It's just rarely done. This talk covers one formula and its consequences: in-flight work equals throughput times latency. We'll apply it to executor pools, HTTP client pools, database connection pools, and distributed limiter client pools. I'll show the configuration mistakes that create each mismatch, what the symptoms look like in production, and the sizing cascade that keeps the gates consistent with each other. If you've ever stared at a dashboard where the rate limiter says everything is fine but p99 latency is through the roof, this talk is for you.

Threat modeling was created for a time when the intended design closely matched what shipped. That is no longer true. Most teams still model what they plan to build, including user flows, design decisions, and evil user stories, but they rarely re-evaluate the model against what is actually deployed. Pipelines continuously uncover real risks through SAST, SCA, DAST, IaC scans, and cloud configuration checks, yet those signals are not fed back into the threat model. This creates a growing blind spot where decisions are based on assumptions instead of production truth. This session shows how to extend threat modeling beyond design and incorporate evidence from the built system. You will learn how to treat discovered vulnerabilities as inputs that evolve the model and how to update the model continuously without waiting for new platforms. The approach is practical and can be adopted with tools most teams already have.

This talk presents a deep technical exploration of implementing zero-trust security principles to enable secure agentic AI workflows across both internal systems and external enterprise tools. We'll examine the architectural patterns that allow granular access controls, unified authentication, and audit-ready visibility to work together, enabling productive AI automation while maintaining strict data sovereignty. Through real-world deployment examples, we'll demonstrate how these zero-trust foundations solve critical security challenges at the intersection of AI, cloud infrastructure, and regulatory compliance.