When I walked into the conference, there was a mix of excitement and unease in the air. Everyone seemed to sense it: we weren’t just talking about “what’s coming someday”, we were already living through a shift. The main idea came up again and again, in different words and contexts: we’re moving from writing code to orchestrating AI agents that build, maintain, and deploy our applications.

It wasn’t theory anymore. It felt like watching the next era of software engineering unfold right in front of us.

The event itself reflected that momentum. Between big keynotes, hands-on workshops, and parallel tracks, there were multiple ways to engage. I chose to immerse myself in the Discovery Track, a space dedicated to focused talks, product deep-dives, and candid conversations with engineers and practitioners.

That decision shaped the whole experience. Instead of only hearing high-level visions, I saw how companies are already experimenting with AI agents in practice.

With that foundation, here’s a walkthrough of some of the most striking sessions I attended , each one offering a unique perspective on where AI engineering is heading and what it means for developers today.

Context Engineering: The Art of Feeding LLMs

One of the first sessions that really grabbed the audience came from Shopify. Alberto Castelo, the speaker, introduced Sidekick, their AI assistant, and made a point that landed with many of us: more memory isn’t always better.

They compared it to a conversation: just as humans can lose track if there’s too much noise, an LLM with an oversized context window risks missing the crucial details.

While it’s tempting to simply expand this window, Shopify demonstrated that bigger isn’t always better. An oversized context leads to:

• Reduced precision with too much irrelevant data.
• Increased cost, since every token adds to compute and API charges.
• Higher latency, as more data slows responses and hurts user experience.

Instead of brute force, Shopify’s AI agent Sidekick employs three strategies:

• Explicit memory: saving clear user preferences (e.g., “always use this background for product images”).
• User profiles: capturing long-term patterns and interests from past interactions.
• Episodic memory: retrieving and reusing specific past actions, like a recent analytics query.

Finally, they highlighted “just-in-time instructions”, delivering guidance only when it’s needed to keep the system fast, safe, and accurate.

Rewriting all of Spotify’s code base, all the time

Spotify’s talk was one of the most relatable. Aleksandar Mitic and Jo Kelly-Fenton explained how automation scripts could handle around 70% of their migrations, but the remaining 30% formed a long, messy tail of complex issues.

That’s where their AI agent loop came into play. Instead of relying on rigid scripts, they experimented with an LLM-driven process. The loop works much like an engineer would:

• Try to apply the code change.
• Run automated verification (builds, tests, linters, schema checks).
• Extract the relevant error messages.
• Iterate until it passes.

What stood out was the surrounding ecosystem: automated verifiers for multiple build systems, an AI ‘judge’ that prevents the model from taking shortcuts (such as deleting tests just to pass CI), and dashboards that categorize failures to help engineers refine prompts. They also emphasize code standardization to make automation more effective.

The underlying message was simple but strong: clean code enables automation, and automation helps keep code clean. This wasn’t just theory, they’ve already merged over 1,000 AI-generated PRs in production.

Automating massive refactors with parallel agents

OpenHands offered a powerful vision of the developer’s evolving role. Robert Brennan described the shift from single agents handling atomic tasks to entire fleets of agents working in parallel on large-scale projects. Imagine migrating a whole codebase from Python 2 to 3, not by hand, but by dozens of cooperating agents.

The potential was staggering, but the speaker didn’t hide the difficulties: compounding errors, coordination headaches, the need to split work into truly independent chunks. They walked through strategies like breaking down tasks file by file, starting with dependency “leaf” nodes, or scaffolding systems so agents can work component by component without breaking everything at once.

Sharing knowledge between agents emerged as just as important as decomposition. Without it, each agent risks relearning the same lessons. The options ranged from humans pasting insights around, to shared files like agents.md, to experimental futures where agents talk to each other directly.

Still, the idea resonated. The goal isn’t 100% automation, they said. It’s 80–90%. Turning months of work into days, or maybe a week.

In this vision, the developer’s role evolves into orchestrator: breaking projects into agent-sized tasks, supervising their progress, curating shared knowledge, and keeping the swarm aligned rather than letting it spin into chaos.

How We Built an AI Agent for Highly Regulated Environments

Security and compliance often kill innovation before it starts. Jesús Espino, from ONA, tackled this head-on with a question many in the room had heard before: “Why don’t we just ban these tools?”

Everyone knew the problem: bans don’t work. They just push employees into shadow IT, with 58% admitting to pasting sensitive data into ChatGPT.

The alternative? Flip the model: bring compute to the data instead of sending data to the compute, this model is based on several key principles:

• AI agents operate within isolated, disposable sandboxes hosted directly in the client’s own private cloud.
• The architecture ensures the AI provider never has access to the source code or data; everything is controlled and logged within the company’s infrastructure.
• A “pull-based” runner model avoids opening insecure inbound network ports, as the client’s infrastructure initiates all connections.
• Sensitive data is encrypted client-side with the company’s own keys, making it unreadable to any external party.

It wasn’t flashy, but it felt real. A way forward for industries like finance where productivity and compliance have always been at odds

AX is the only Experience that Matters

Perhaps the most forward-looking concept presented was the shift from User Experience (UX) to Agent Experience (AX). Toma Puljak argued that most tools today break the moment you remove the human from the loop, because everything has been built for people clicking buttons and dashboards. But in a world where agents will interact with software on our behalf, we need to design platforms for machines too.

The definition of AX is basically: how easily agents can autonomously access, understand, and operate within digital environments to achieve user goals. In other words, the same spirit as UX, but from an agent’s perspective.

To make that work, a few principles stand out:

• API-first design: everything should be exposed programmatically, not hidden behind UI buttons.
• Machine-readable docs: similar to Stripe’s .md pages or Daytona’s llms.txt, which are directly integrated into their websites so that agents can actually learn how to use the product.
• Authentication for agents: systems like Arcade let agents log in and act as you, while other models authenticate agents on their own behalf.
• Standardized protocols: MCP is emerging as a common way for agents to talk to apps.

The talk also highlighted that this isn’t just theory: 25% of YC startups in one batch said AI wrote 95% of their code, and 37 were building agents. The number of agents is expected to explode, not just one per human, but agents using other agents.

The message was clear and powerful:

“If agents can’t use your product, nobody will.” Soon, agents will be the primary intermediaries for digital services, and companies that optimize for AX today will gain a significant competitive advantage.

Building AI workflows: from local experiments to serving users

One of the most powerful insights from the conference was that AI agents shouldn’t be treated as simple chatbots, but as full distributed applications. Each agent is built from three key pieces: the “brain” (the LLM), the tools it uses to interact with the world, and the system prompts or business logic that guide its behavior. In this setup, AI isn’t the entire product; it’s the part that handles the “fuzzy calculations” that traditional code struggles with, inside a larger application.

Oleg Šelajev, from Docker, explained how they are bringing their application expertise into this new AI landscape with a set of tools designed to make agents easier to build and run. These include Docker Model Runner for running LLMs locally, the MCP Toolkit (and its MCP Catalog) to plug in and manage tools securely, Compose for Agents to orchestrate whole AI applications with a YAML file, and the newer C Agent, which strips things down even further into a simple DSL that anyone can use to define an agent.

The big picture is clear: building an AI agent is really just building an application with AI as one component, and Docker wants to make that as straightforward and familiar as possible for developers.

The rise of local CI tooling. Thanks AI coding agents!

As AI agents begin to generate more and more code, our current Continuous Integration (CI) workflows are showing their limits. Pushing every AI-generated change to a remote CI server creates slow feedback loops, high costs, and endless “fix the CI” commits. This is a major bottleneck for the new pace of development.

Instead of merely improving existing CI, Yves Brissaud, from Dagger, proposes to reinvent it. Its open-source engine allows developers to define pipelines as code, which can be executed identically anywhere: locally, in the remote CI, or by an AI agent itself. Because every step runs in an isolated container, this approach guarantees reproducibility and portability, finally solving the “it works on my machine” problem. This unified pipeline provides a single source of truth for both human and agent developers.

---

Walking out of the conference, one powerful idea stayed with me: AI isn’t just a tool, it’s a co-pilot, fundamentally reshaping how we build software. It was clear that the future isn’t about replacing developers; it’s about elevating our role to one of strategy, architecture, and orchestration. The conversations weren’t just about code anymore; they were about agent experience, smart AI context, and a complete rethinking of our CI/CD pipelines. The companies that get this right, that invest in the right mindsets and tools, are the ones who will truly lead the next wave of innovation.

Yet alongside this momentum, I found myself circling back to a deeper concern, because as fast as we’re moving, something essential still feels unresolved. We celebrated groundbreaking agent orchestration and automation, yet the security discussions felt more like a prelude than a plan. Compliance and sandboxing were good starting points, but only scratched the surface. And that left me with pressing questions:

• How do we actually threat-model these AI agents?
• How do we protect the communication between them from misuse or adversarial attacks?
• What frameworks can we build to ensure transparency and auditability without slowing down the very innovation we’re celebrating?

This isn’t a dead end; it’s a huge opportunity. The industry is sprinting ahead, and the security layer is playing catch-up. Building those foundations will be critical if we want AI to safely become the backbone of tomorrow’s software ecosystems.

Read you in the comments below 👀 👇