Schedule

In 1978, Detroit was at its peak. General Motors, the largest of America's Big Three carmakers, hit record sales and profits.

Two years later, the Big Three had lost $4 billion between them, and Chrysler was asking for a government bailout. Meanwhile, Japanese carmakers were quietly taking over the American market with smaller, cheaper, and better-built cars.

Detroit's response was to spend tens of billions of dollars on automation, filling its factories with robots, betting that technology would close the gap.

It didn't.

Toyota and other Japanese manufacturers won by crafting a better system, one that built quality into every step of the factory, and a culture obsessed with building the cars customers actually wanted.

Today's software landscape is eerily reminiscent of 1978. AI has made coding largely automatable, and teams are shipping more than ever before.

Most companies are responding the way Detroit did: rolling out AI tools, and betting that the technology will close the gap.

It won't.

AI has sped up one part of the lifecycle. Everything around it, from deciding what to build to knowing it works, has stayed the same. The answer is to rethink the whole software development lifecycle: start from customer value, be rigorous about what gets built and what doesn't, and bake quality into every step of the SDLC, rather than inspecting it in at the end.

Mo Khazali has spent the last few years introducing AI into engineering organisations across multiple companies as a consultant, most recently rolling out an AI-native SDLC to a team of 160 engineers. In this opening keynote, he shares what he has learnt about building systems and the right culture around AI, and how to make sure this isn't your 1978.

Coding agents have gone from autocomplete to something closer to a software factory. But delivery is more than writing code fast. Once the agent opens the PR, how do you know nothing regressed and that the original intent survived the trip from ticket to production?

This talk is about zero-trust harnesses. Every agent action is untrusted until something other than the agent proves it, and intent travels with the work through planning, building, QA, and production monitoring.

I'll run a feature end-to-end from a coding agent, break it the way it breaks in production, then show the harness catch it, route it back with evidence, and converge to green on its own. I'll cover the failure modes you'll hit: flaky gates burning the attempt budget, why that budget needs a ceiling, and what goes wrong when the orchestrator drifts from enforcing policy into chatting with the agent. I'll be specific about the decisions that kept the loop trustworthy rather than just impressive, and about how the harness gets stricter each time production teaches it something.

Then we go past the merged PR. A green build is a checkpoint, so we'll follow the same loop into monitoring and incident response, where production tells you what the gates missed.

Attendees will leave with an architecture they can put on the stack they already have.

It's easy to tell people to use AI. It's harder to understand what that actually feels like unless you're doing it yourself. This talk shares lessons from a leader's own journey of learning AI and how that experience helped her not only to effectively support change across her software organization but also how that helped her to do her own work.

AI coding agents now produce a deployable artefact in minutes. That collapses the cost of every hand-off in the traditional software lifecycle, so its phase structure has to be re-derived from the new economics. In this talk I propose that the long chain from mission to running software reduces to two complementary phases: Agentic Discovery and Agentic Engineering.

Agentic Discovery is an expedition into the problem domain, and its instrument is the agentic probe: a stakeholder-runnable artefact that an AI agent builds from the stakeholder's own words in minutes. A probe can be a prototype, a process simulation or a possible future. It is not a first draft of the product but an instrument for finding out what the product should be. Probes work in two modes. A problem-validating probe simulates the current way of working, its constraints and its pain, so stakeholders can confirm, correct or relax them. A solution-proposing probe is working candidate software that stakeholders evaluate by using it. In both modes a stakeholder (the Dreamer) works with an AI agent, while a human Orchestrator curates the queue between them.

The evidence comes from eight in-room field engagements with two partner organisations: 69 probes, about 140k lines of generated code, 100% probe-generation success, and intent-to-code amplification averaging 1:56 (up to 1:467). The most interesting finding is where the bottleneck went. First it was production. At seven parallel requests it became the human Orchestrator. Once we automated orchestration for engagements of about 100 invited participants, it moved to the supply of stakeholder ideas and the speed of stakeholder validation.

Joint work with Leena Pitkäranta (Aalto University).

How can we best assist users in creating their own user interface (UI)? The generative competence of large language models (LLMs) enables people to describe their task (e.g., creating a dinner event plan) to an LLM and get a functional UI on demand. This way of using LLMs is called generative UI (GenUI), which promises a future where people can create UIs to perform their tasks in a way they want, instead of learning to operate on UIs designed for general users. However, ongoing studies on GenUI mostly focus on assisting designers, whose goal is to design UIs. It remains unanswered how such technology can be adapted to everyday users whose goal is to use UIs for their tasks. In this talk, I will present our research work showing the strengths and limitations of three GenUI approaches in assisting task-oriented users and offer the underlying cognitive mechanisms of how each approach succeeds or fails. The talk will further offer three actionable insights into how GenUI needs to be advanced to be useful for users, not just for designers.

How Elisa drove AI adoption across the SDLC beyond expectations through leadership, tooling, communities, and shared practices. The talk also covers how governance continues to evolve to manage costs in the new era of token-based development, while operating critical infrastructure under high levels of regulation.

In February, Viljami handed AI coding agents to every PM, designer, and support rep at epilot, then opened the whole codebase to them. He expected a few translation fixes. Instead, they shipped thousands of PRs: hundreds from people who had never written code, with dozens still contributing every week. Engineers review and merge, features go to customers, designers ship real UI, PMs ship features they had waited months for, and customer success builds its own tools. This talk shares what they learned, the guardrails they put in place, the parts that broke, and the day someone pushed unreviewed code to production.

AI is making software development faster, more automated and more factory like. Code can be generated in seconds, tests created automatically and ideas moved toward production with less effort.

But speed does not replace clear intent, sound architecture, independent verification, security, ownership or operational feedback. When these foundations are weak, AI can produce convincing results while moving cost and risk into review, release and production.

This session examines why software delivery fundamentals matter more as AI adoption grows. It considers how technical and business leaders can recognize false confidence, set appropriate boundaries and maintain accountability across an AI enabled SDLC.

The aim is not to slow the factory down. It is to help ensure that faster output becomes software that can be understood, operated and sustained.

Zak Allal shares an industry perspective on applied AI in software development. In this talk, he will show how supercomputers and high-performance languages such as Rust, Julia and C++ enable radical medical breakthroughs and exponential scientific discoveries that were impossible before, surpassing black-box deep learning.

Generative AI has made writing code cheap, but it has not made understanding it cheap, and that gap is becoming the central problem in software engineering. Drawing on recent research and his own empirical study of 1,500 AI-generated refactorings across 15 repositories, Dr Waseem shows that code which looks correct in a single file is often unsafe once it ripples through the wider system. He traces how the work is shifting across four fronts: writing, where AI is fast, reading and verification, where humans have become the bottleneck, deciding, where agents are becoming users and even customers, and caring, where security, accountability, and the training of future engineers are at stake. The talk argues that architecture, verification, and the recorded reasoning behind our systems now matter more, not less, because they are exactly what AI cannot generate for us. The message is simple: code was never the hard part, and closing the understanding gap is the real work ahead.