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

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.