Remember when profiling Node.js meant wrestling with perf, sed scripts, and mysterious V8 internals? Traditional flame graph generation has been like performing surgery with a rusty spoon, requiring kernel-level tools and arcane command-line incantations. The barrier to entry is sky high. The time to insight is glacial.
We've completely reimagined this at Platformatic with @platformatic/flame - a zero-config profiling tool that works instantly. Just run flame run server.js and get production-grade flame graphs. Combined with our WebGL-accelerated React component library (react-pprof), we handle massive datasets with buttery-smooth 60fps interactions. This isn't just another tool - it's about democratizing performance analysis.
When your Auth Service hits 96% Event Loop Utilization, you need answers NOW. I'll show you our ecosystem-compatible architecture, how we profile microservices in-memory with Watt, and real production cases where this saved millions in infrastructure costs. Performance is everybody's responsibility, but the tools have been nobody's friend until now.

Apollo’s response caching has been rebuilt from the ground up for speed, control, and scale—and it’s easier than ever to use. In this session, you’ll see how to flip on supergraph-level caching with directives and instantly cut latency, all without touching subgraph code.

We’ll get into the good stuff: policy-driven caching, surrogate keys for precise invalidations, and patterns to keep data fresh across a federated graph. You’ll see a live demo of the cache debugger in Apollo Sandbox, complete with expanded metrics and distributed tracing so you actually know what’s going on. We’ll also show off the new invalidation engine—it’s dramatically faster, handles more complex scenarios, and is just plain nicer to work with.

We'll first explore how we implemented our MCP server for GraphQL APIs and then use Grafbase extensions to federate non-GraphQL datasources to have them all available for agents without increasing the number of tools.

In this session, I’ll explore how AI-powered tooling is transforming large-scale refactoring and codebase migrations, making these complex tasks faster and more efficient. By leveraging tools like Large Language Models (LLMs), static analysis, and refactoring frameworks, we can automate repetitive code transformations, accelerate migration paths, and reduce human error. I’ll share practical examples of how we can migrate legacy systems to modern frameworks, break monolithic architectures into service-based structures, and automate large-scale code changes across thousands of files.

I’ll demonstrate how tools like OpenAI Codex, GitHub Copilot, and fine-tuned models for domain-specific transformations can assist in these processes, while still integrating with traditional migration tools and CI/CD systems. I’ll also cover the importance of developer oversight, highlighting lessons learned from real-world production rollouts and how to balance automation with manual reviews.

By the end of the talk, I want attendees to walk away with a clear understanding of how to use AI to enhance their refactoring and migration workflows, ensuring they can handle large-scale transformations while maintaining code quality, consistency, and governance.

In this session, we will break down the concept of code coverage, explore effective ways to improve it, and discuss common pitfalls to avoid. We will share practical tips for optimizing unit tests, leveraging the JEST framework, and integrating coverage checks into your CI/CD pipeline. Strong code coverage is not just about statistics; it’s about catching bugs early, reducing regressions, and building confidence with every code change.

Multi-agent AI frameworks are everywhere right now — OpenAI Swarm, CrewAI, Langflow — but most of them are built Python-first. Meanwhile, a huge chunk of AI startups (60–70% in YC, by some counts) are building in TypeScript. And honestly, spinning up a whole Python backend just to leverage some of these frameworks didn’t feel worth it.

In this talk, we’ll walk through how we approached building a multi-agent AI system in TypeScript — by focusing on the core principles behind these frameworks and building something similar that fits the JS stack.

Abstract

Libraries and frameworks are where LLMs often break down: too much context, too many moving parts, and lots of hidden assumptions. In this talk, we’ll unpack why models struggle in this space and present our method for structuring library knowledge into digestible chunks. Using Svelte as the running example, you’ll see what goes wrong when models get it wrong, and how Tessl's approach can help them finally get it right.

Overview

Why frameworks and libraries trip up LLMs

Software engineering, among other things, requires precision in language, API patterns, and dependency versioning. But models are trained on snapshots of data that:

• Are taken in the past, meaning they have no knowledge of a framework just released;
• Contain mixed and sometimes contradictory information about the same package. For example, different versions without clear differentiation;
• Provide an unbalanced distribution of information. Some packages are well-documented, while others have very little coverage.

We’ll unpack why this matters for developers relying on AI coding tools and introduce a practical tool to help.

Tessl's method

• Structured, doc-like blueprints of a package’s API, best practices, and examples.
• They give coding agents a reliable reference point while iterating, helping them stay aligned with how a library is really meant to be used.

Svelte as a running example

• Svelte poses a particular challenge: LLMs often mix it up with other frameworks or fall back to using older Svelte versions patterns.
• With our method, the same agent can navigate the framework more effectively, producing cleaner, more accurate code.