Schedule

2 years ago, the engineering team's structure was fairly standardized, 2-pizza cross-functional teams and an engineering manager leading the team. These days, everyone is figuring it out as they go, making adjustments and seeing what may work and what not.In this talk, Gregor will share how companies like OpenAI, Anthropic, Shutterstock and others build engineering teams in the AI era. He will also share his recommendation on the best structure for a specific type of organization.

We used to explain our bugs to rubber ducks. Now, the duck talks back, writes code, and occasionally lies to our faces.LLMs are incredible tools. They can cure "blank screen syndrome," instantly write boilerplate, and explain weird legacy code. But treating them like senior engineers is a massive trap.

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

AI makes individual engineers faster - and quietly more isolated.As coding agents become everyone's default pair, the collaboration that keeps an org healthy erodes: pairing fades, context gets trapped in private chat histories, knowledge stops diffusing, teams drift into silos.Velocity dashboards look great, so nothing seems wrong - until onboarding slows and bus-factor spikes.This talk names the failure mode, explains why standard metrics miss it, and shows what leaders can do to keep teams connected as AI adoption accelerates.

AI is giving developers unprecedented autonomy. Every engineer can now create their own workflow, combining coding agents, prompts, knowledge bases, and tools in different ways. While this can dramatically increase individual productivity, it introduces a new challenge for engineering leaders: maintaining consistency across teams.In this talk, we'll explore how AI is creating new forms of organizational drift, why team alignment matters more than ever, and practical approaches for building shared AI practices without limiting innovation.

Our telemetry dashboard was green — a bug-fixer skill firing hundreds of times a week, a test-coverage agent running on every diff, manual-tester agents driving browser test cases across products, security reviews kicking off across teams, daily active users climbing. And I still couldn't answer one question: did any of it make us better? Every usage metric was lying. This talk is how we drove real adoption of an internal AI plugin marketplace across 30+ engineering teams — hands-on workshops and embedded champions — and how we now measure what actually matters: fewer bugs, faster cycles, less busywork, not call counts.

AI usage grows, cost follows, and leadership asks you to control it. The instinct is to reach straight for a spending cap. Our concern was that doing so would undermine the adoption we had encouraged, while the arithmetic showed that a daily limit would not control the overall budget anyway.This case study follows the design of cost governance for AI development tooling across an engineering organisation while adoption continues to evolve. Governance that has any chance of sticking depends as much on framing the policy and sequencing cost control efforts as it does on thresholds, and choosing a number is often easier than deciding what the control is supposed to achieve.

As agents become a growing part of the software delivery lifecycle, engineers will need to develop new capabilities beyond writing code alone. In this session, IBM HashiCorp Field CTO Anna McDougall introduces the COG Model for engineering skills development in the AI era: Curation, Orchestration, and Governance. Yet while many tools and skills are changing, many of the attributes that define exceptional engineers remain consistent. So what will distinguish the best engineers in an age of AI?

As LLMs become everyday tools for developers, the way we interview engineers must evolve.We will learn strategies to adapt technical interviews, embracing AI as a tool while still assessing judgment, critical thinking, and collaboration.

 Every engineering org has tried AI tooling. Very few have gotten it to stick. At Amazon, my team behind the Retail Catalog Pipeline moved past the pilot phase entirely: we built internal tooling that engineers actually reached for every day, and it spread to teams we never pitched it to. No mandate, no rollout plan, just adoption that happened because the tools earned it.

How do you know an AI system will refuse the thing it must always refuse? Today the answer is testing: ask it a thousand ways and hope the thousand-and-first isn't different. The policy in this talk has 55 variables a caller controls: that's 36 quadrillion situations! It also has a test suite of 33 unit tests, all green.