Abstract

The Code Was the Easy Part Building Spaghetti Code Foundry We started building Spaghetti Code Foundry with a simple vision: place a label on a GitHub issue and let AI agents plan the work, write the code, run the tests, review the result and prepare it for delivery. The first design treated the factory as a pipeline for producing code. We quickly discovered that writing code was the easy part. The real engineering challenges lived around the pipeline. Stories had to be clear and small enough to build. Parallel agents needed coordination. Approvals became queues. Status information had to remain trustworthy after partial failures. Retry loops needed brakes. Test suites became production bottlenecks. The factory needed monitoring, recovery procedures, capacity limits and an operating model of its own. At one point, the Foundry became so effective at improving itself that it stopped delivering work for the product it was supposed to support. This talk shares eleven practical lessons learned while building and operating an open-source AI software factory. It covers the failures that changed the architecture, the features those failures produced and the trade-offs involved in moving from assisted coding toward autonomous software delivery. Along the way, we will look at how Spaghetti Code Foundry turns issues into coordinated flows of questions, planning, implementation, testing and review—and why increasing autonomy makes visibility, governance and operational discipline more important rather than less. The central lesson is simple:

A software factory is a coordination and trust problem with a coding step in the middle. The talk is intended for software engineers, platform teams, SREs, engineering leaders and anyone experimenting with AI agents in real software-delivery workflows.

Bio

I am a Site Reliability Engineer, Platform Engineer, author and speaker with more than 25 years of experience in IT. My work sits at the intersection of reliability, automation, cloud platforms, observability and operational leadership. I have spent much of my career helping organisations build, run and improve critical systems where downtime matters, incidents are expensive, and vague ownership quickly becomes a real business risk.

Abstract

AI tools already run inside your organization: MCP servers over internal docs, RAG services over company data, and agents that call other systems. Agents use the same platform APIs your developers do, but they need different things: a finite context budget, no memory between sessions unless the platform keeps it, an identity of their own, and a human before they write. Without shared guardrails, every team solves isolation, data access, and policy on its own, and the platform team becomes a ticket queue. This talk applies platform engineering to AI tools: paved roads where a team brings its tool and the platform provides an isolated runtime with guardrails in place from the start. We cover: - Roads by risk class: a read-only docs server, a data tool, an agent with write access, and a GPU workload each get a different baseline - Isolating teams on a shared cluster with virtual clusters - A live demo: a team ships a real MCP server without writing a security rule, the road refuses an unsafe deployment, and another team's AI assistant uses the tool from a plain-English request - A maturity model for agent platforms, from ad hoc API keys to agents that earn wider permissions.

Bio

An active contributor to open source, content creator on Medium and YouTube, focusing on practical, scalable solutions in cloud-native environments. DevOps and Platform Engineering practitioner and advocate.

Abstract

We build a voice AI co-worker that lives inside web apps, and we build it with coding agents like Claude Code. The problem is that voice isn't something a coding agent can test by itself, because it can't hear. It writes the change and runs the tests, but it has no idea if the voice still works. And for voice AI it's not only about whether sound comes out or the transcript is right. It also has to get what the user wants and call the right function, so the thing actually happens in the app, even when someone's tapping on the desk or the network drops. So we built a twin. It role-plays a user with a goal and talks through a fake microphone into the real voice pipeline. The whole session comes back as text the coding agent can read. A test only passes if the right action really happened in the app, not because the answer sounded right. A run costs one or two cents, so the coding agent can run it after every change. I'll run it live and show what it caught, for example a reconnect that killed the session 11 seconds in, which in the end was triggered by our own test tool. I'll also show what it can't catch, like the day our German sessions went silent while every transcript looked fine. Hopefully you leave with a way to test your own voice features without listening to every change.

Bio

Ebrahim(Ebi), has shipped product across three continents, director of engineering at a Middle East company he helped take to IPO, an engineering manager in Germany, a staff engineer in New York, then NearDynamics, a voice AI venture he built and saw through an exit. Now he's building Coworkkit, a batteries-included AI co-worker any app can drop in and ship. What excites him most is the faceless app that serves one UX rendered for each user.

Abstract

Every conversation with an AI starts from zero. To help users, we have to populate an LLM's context with correct information, in the right amount, at tolerable latency. We explore:

• Populating the context: static knowledge injection, RAG and the agentic loop.
• Types of information — and which database each one needs.
• Dealing with stale context in vector knowledge bases: decay and priority metrics on the reranking phase — or pushed inside the HNSW KNN walk itself.
• Bypassing embedding context limitations with semantic centroids. This is an engineering talk with learnings from different use cases, from local chatbots to large e-commerce applications. Forgetting is not a bug. It's a design choice.

Bio

More than 13 years of software development experience. Software Architect, specializing in AI services (RAG, model self-hosting), cloud solutions (AWS, Hetzner), and infrastructure optimization. + 6 years at moebel.de. Certifications:

• TOGAF Enterprise Architecture Foundation
• AWS Certified Solutions Architect – Associate
• AWS Certified Developer – Associate
• AWS Certified ML Engineer – Associate Education:
• K.T.N in Logistics (Technical Sciences)
• Retrained in software development (second diploma)

Abstract

Getting an autonomous driving system to work in a demo is easy; getting it reliably into production is where the real engineering happens. Jan spent nearly a decade on exactly that, building autonomous driving systems that had to pass large-scale cloud simulation, scenario-based testing and safety assurance before they reached the road. In this talk, he shows how he applied those lessons to the MoinMeister Phone Agent, an AI voice assistant that answers calls and books appointments for car repair shops, from building a scenario library and regression evals to testing with simulated callers. Attendees will leave with a practical playbook for taking LLM agents from impressive prototype to a system real businesses trust with their phone line.

Bio

Jan Kleine-Klatte is the founder and CEO of MoinMeister, an AI operating system for car repair shops and dealerships. He grew up as the son of a workshop owner, trained as an automotive mechatronics technician, and then spent nearly a decade building AI and software for autonomous driving and renewable energy at companies like Continental, SICK and Enpal. At SICK he developed a safety-certified emergency brake assist system, including the company’s first machine-learning component in a safety-certified product. With MoinMeister he now brings that experience to automotive aftersales, one of the least digitized industries, where many shops still run on paper or on software written before smartphones existed.

Abstract

AI personalization for apps with a large and global user base is a difficult engineering challenge. Global companies like Tripadvisor, Medium, and ShareChat depend on highly available, low-latency AI infrastructure to deliver hotel recommendations, "For You" feed items and relevant short-form video content. In this talk, we cover the underlying systems that power these user facing recommendation use cases. - Running real-time model inference with millisecond latency - Setting up a centralized feature store that feeds both training and serving - Leveraging OSS feature store frameworks and tools - Best-practice data modeling approaches for online inference to minimize latency - Cost-effective utilization of cold/object storage, hot caches, and low-latency databases for model training and user-facing inference - Meeting strict SLAs (p90, p95, p99, etc) By the end, attendees will learn how to design AI infrastructure that serves fresh features in milliseconds. They will also see real data models, latency numbers, and cost trade-offs from three production systems.

Bio

Attila Toth is a senior developer educator at ScyllaDB, where he helps developers build reliable, scalable data systems for AI applications. He has spent 10 years in the data industry, first as a data and software engineer building ecommerce data applications, and later in developer education. Attila is a contributor to AI projects including Feast, Mem0, and LangGraph, as well as databases like TimescaleDB and ScyllaDB.

Abstract

If you’re being challenged by deploying artifacts for AI workloads on a platform built for lightweight, ephemeral containers, you’re not alone. Model deployments are coming with 20-minute cold start times, nodes OOMing, and downloads restarting due to pod failures. We’ll unpack all the solutions out there, starting with level 1 - implementing an in memory caching solution. As we progress the levels get more intricate, such as leveraging kServe cluster storage containers and HuggingFace XET proxies. The final level includes ModelPack, Harbor, and Spegel - which can either supercharge or super-nerf your approach. To finish the game we will answer the most important questions of them all: “Can model artifacts be converted into OCI artifacts, and if so, at what cost?” You’ll leave knowing which solution can be implemented into your platform today, and the cheat codes to complete the next levels of solutions. It’s dangerous to deploy model artifacts alone, take our lessons with you.

Bio

Philip Laine is the founder of Kvick a company making pod-startup times a problem of the past. He runs Spegel, a stateless cluster-local peer-to-peer OCI registry mirror for Kubernetes, and is a former core maintainer of Flux and Zarf.

Abstract

A chatbot can answer general questions. It can't tell you why a key metric dipped last week, because it can't see your data, tickets, documents, or code. This talk shows how we turned a generic chat assistant into a "company brain": one place where employees ask questions in plain English and get answers drawn from the systems they already use. We start with a chat interface that can use any large language model. We then add three building blocks:

• Connectors to internal data, documentation, ticketing, and communication systems, built on an open standard (the Model Context Protocol).
• Skills, which are centrally maintained, reusable bundles of domain knowledge.
• Tools such as web search and code execution. Wiring these up by hand in every chat doesn't scale, so we package them into pre-built agents. Specialist agents each own one domain, and an orchestrating agent routes every question to the right specialist. Connectors run under each user's own identity and are read-only, so the assistant only sees what the person asking is allowed to see. You'll leave with a practical blueprint: how to layer models, connectors, skills, and agents, how to handle permissions, and what to watch out for when rolling it out company-wide.

Bio

Shekhar Khandelwal is a Principal AI Engineer at adjoe, part of the AppLike Group. He has more than a decade of experience building enterprise-grade AI products, including roles at Accenture, IBM, and EY. He holds a master's degree in Data Science and is the author of two books on deep learning. At adjoe, he builds AI agents, agentic workflows, and AI solutions.

Abstract

Most voice AI conversations focus on models, voices and latency. In production, those are rarely what decides success. The harder problem is operational: how agents are built, tested, released and kept healthy once real customers start calling. This talk shares the operating model HeyBreez uses to deliver inbound and outbound voice agents for banks, telcos and e-commerce companies across the Middle East, in multiple Arabic dialects. It covers how builder teams are organized to balance speed and quality, the QA process every agent passes before going live, and how calls are reviewed and agents improved week after week. It also covers when an agent should hand off to a human, and the metrics that separate an agent that sounds good from one that delivers results. Attendees will leave with a practical framework for running voice AI as an ongoing operation rather than a one-time project, and a clear view of the failure points most teams discover too late.

Bio

I lead the Forward Deployment Engineers department in HeyBreez AI . My role focuses on designing innovative solutions, leveraging expertise in solution architecture and workflow automation to drive business efficiency and growth. Where I architect Enterprise voice agents and integrate cutting-edge STT, TTS, and LLM technologies to deliver impactful automation systems. At HeyBreezAI, I collaborate with cross-functional teams to support sales efforts by demonstrating technical capabilities and addressing client challenges. My work emphasizes translating complex AI solutions into tangible business outcomes, aligning with organizational goals and fostering client success. I am passionate about combining deep technical execution with customer-focused strategies to empower businesses through intelligent automation.

Abstract

Your agent says it’s done. It isn't. I spent 15 years hearing that from humans. In 2013 I worked on building a browser document editor. A decade later the product died, so I rebuilt it without writing code, in an agentic factory made of the practices everyone calls essential, then quietly skips. Two products from the Factory so far: an office suite with .docx round-trip and track changes, and ReaLLM, a space RPG you can play on your phone if this talk gets boring. Together, about 1,700 commits, 1,700 end-to-end tests and 460,000 lines of product code. You will learn to:

1. Define "done" so an agent can’t talk its way past it, with checkable acceptance criteria, a read-only reviewer, and a merge left to a script, never a model.
2. Turn your backlog, story points, WIP limits, code review and CI/CD into agent stages, using tools you already have.
3. Decide what humans still own: keep GitHub credentials from agents, never let the factory change its own gates, and count every human touch.

Bio

Miroslav Dzunic is a senior software engineer at DKB Code Factory GmbH, with a strong background in Frontend Systems and Software Architecture. He is building Agentic AI Systems & Software Factories and promotes AI-driven development.

Abstract

As AI assistants and agentic systems increasingly interact with emails, websites, social media, online reviews and digital documents, a new attack surface is emerging: the manipulation of AI systems through seemingly harmless external content. Malicious actors can exploit indirect prompt injection by embedding instructions in content that an AI system is asked to read, analyse or process. Unlike traditional scams that target people directly, these attacks attempt to manipulate the AI assistant acting on a user's behalf, potentially influencing its decisions, revealing sensitive information or triggering unintended actions. This talk explores how everyday online interactions can become attack vectors for AI-powered systems. It examines why these threats become particularly concerning when AI systems have access to personal information, communication channels and external tools, and discusses practical approaches to reducing risk through trust boundaries, permission controls, input handling and human oversight.

Bio

Al Engineer focused on adapting and fine-tuning LLMs for specialized domain tasks. Experienced in building custom training setups, practical LLM applications, optimizing PEFT pipelines, improving downstream model evaluation, and evaluating Al safety. Driven by technical innovation and integrating raw research architectures into reliable production systems.

Abstract

Over the last year, we have seen many examples of development harnesses and agent factories. Many of us now use them, and each organisation has its own version. We know how to run them. We are less clear about who should own them, who actually feels responsible for them, and how developers should work with them. This talk looks at the organisational design behind the harness: how it represents stakeholders, reflects the organisation’s structure, and receives and uses context.

Bio

CTO and technology executive who led AI product and engineering transformations in consumer and enterprise settings. His is focusing on conversational AI, complex UX products, platform and product migrations, trust and safety, and engineering organisation design. Former CTO of Replika (40M users) and Seldon Digital, Director of Engineering at LivePerson, Senior Engineering Manager at Meta, Head of Engineering at Jimdo, and founding engineering team member at Wix.

Abstract

From Idea to PoC: Spec-Driven Development with LLMs How can LLMs help turn an app idea into a working proof of concept? In this talk, Pedro shares how he used agentic coding and spec-driven development to build a PoC for a startup. From shaping the initial idea and defining the architecture to implementing the app. Through practical examples, he walks through his workflow, shares tips for guiding coding agents, and showcases useful tools along the way. He wraps up with lessons learned: what worked, what didn’t, and what he would do differently next time.

Bio

Pedro Treuer is an AI Engineering Consultant at Netlight Consulting, specialising in AI transformation. With a deep understanding of modern AI models and methods, he builds practical solutions, from RAG chatbots and classification systems to AI enablement initiatives that help teams work more efficiently. His focus: turning AI experimentation into real business impact.

Abstract

RAG reduces hallucinations, but it doesn't stop them. A model can retrieve the right documents and still state something they never say. For example, it might name a software product's pricing tier that appears nowhere in the retrieved data. To a user comparing tools before a purchase, a confidently wrong price looks exactly like a correct one. This talk presents the grounding gate built into OMR Reviews' multi-agent AI Buying Assistant. Before an answer reaches the user, the gate extracts its claims, and an LLM judge checks each one against the retrieved data. The talk covers how claims are extracted and matched to sources, where LLM-as-a-judge verification holds up and where it fails, and the trade-offs between latency, cost and strictness. The gate is one part of a larger evaluation package that includes LLM-judged regression tests, automated QA on every merge to staging that checks tool calls and trajectories, and post-hoc issue detection on live traffic. The talk closes with how these layers work together.

Bio

Izabel Cvetkovic is an AI Engineer at OMR Reviews in Hamburg. There she builds the AI Buying Assistant, a multi-agent system based on hybrid RAG, Neo4j knowledge graphs and LangGraph. She also leads the AI Tooling & Automation stream, a cross-team initiative on Claude Code adoption, shared tooling and architectural standards. She holds a PhD in Information Systems on human-AI collaboration in knowledge work, and her technical focus is on the limits of RAG, knowledge graphs and LLM evaluation.

Abstract

What changes when a design team runs its whole workflow through an AI agent? We rebuilt ours at justtrack as scoped skills: requirements, research, design, critique, pre-handoff check. One feature now goes from ticket to clickable prototype in a day, whatever its size. That prototype replaced the Figma file as the thing product owners react to, so feedback lands earlier and the requirements document updates itself from what gets decided. Engineering receives a design that has been through a mechanical check before anyone opens it. But generating a screen is the easy part. Making it match an existing design system, survive a review, and arrive in a form engineering can build takes more than a prompt. This session is also about the parts that did not work: what happened when we handed Claude Design our design system, why the obvious fixes failed, and what the handoff to developers looks like when the artefact itself is in question. What you'll take away:

• Why one agent with scoped skills beats one agent per role
• How to feed a design generation with real inputs: the ticket, the requirements, industry patterns, and your own user research
• Why attaching a design system file or a component library produces worse output than you expect, and what works instead
• How to give your agent a written set of UX principles so its design critique becomes usable instead of noise
• The open question: Figma file or working prototype as the artefact engineering receives

Bio

Gabriel is Lead UX/UI Designer at justtrack, part of the applike group, where he built the design function from the ground up: a team, a design system, and a working relationship with engineering that did not exist before. He rebuilt his team's workflow around AI agents and shipped it as an internal Claude plugin, from requirements through to the handoff to engineering. He is interested in where that works, where it does not, and what it means for design systems.