Technical talks, great craic, tech community.

Erased From the Commit Log: Forty Years of Queer Computing, and the Systems We're Building Next

Adam D'Arcy

10:00 (30 minutes) · Hall 1B · Talk · Introductory · Wildcard

In January 1976, a shipping clerk in Belfast had his home searched and his private papers seized. Five years later, Jeffrey Dudgeon won a case at the European Court of Human Rights that decriminalised homosexuality in Northern Ireland. It was 1988 when Norris v. Ireland put the Republic on the road to decriminalisation. These rulings are younger than some of the companies we work for. Our industry was built by people who had to hide to do their work. Alan Turing died a convicted criminal. Lynn Conway was fired by IBM in 1968 and rebuilt a career from nothing, then wrote the methods that every chip designer still uses. Sophie Wilson designed the instruction set that runs on almost every phone in this hall. Most of us learned their architectures without ever learning their names. This talk traces that history forward into the code we ship today: the name field that can't hold both a legal and a chosen name, gender modelled as an enum, the deadname that survives in every backup and audit log, the identity check that fails on mismatched documents, the retention policy that turns a user record into an outing risk in the wrong jurisdiction. These are architecture decisions with owners and tickets, not HR problems. We'll close by considering what the next decade asks of us and why designing for the edges has always produced better systems for everyone in the middle. Key takeaways * Named, specific ways production systems fail queer users - identity modelling, audit trails, verification flows, data retention - and design patterns that can provide solutions * A working test: how to audit your own schema and logs for assumptions that only hold for the default user * Why inclusive design consistently improves reliability and usability for the whole user base, with the mechanism, not the platitude * A pocket history of queer computing you can cite, from Belfast in 1981 to the ARM core in your pocket

Chaining the Unchainable: Finding and Exploiting Logic Flaws in Modern Web Architectures

Raj Dhruv

10:00 (30 minutes) · Room 1A · Talk · Intermediate · Security

Most scanners will never find these bugs. This talk is about what happens when you chain enough of them together anyway. Spoiler: it ends in RCE and full tenant isolation bypass. Business logic flaws are unglamorous. They don't have CVEs, they don't get blog posts, and individually they'll barely register as medium severity on most reports. But in the microservice-heavy, federated identity, multi-tenant environments most organisations are running today, these small mismatches compound. The interesting stuff happens at the joins, like where an API gateway hands off to a downstream service, where an event queue trusts state it shouldn't, or where OAuth flows have one assumption too many baked in. This session walks through three attack chains pulled from real engagements. This is not sanitised theory. We will look at actual proxy logs, HTTP pairs, and the exact moment each system broke. The three paths covered include: 1. Race conditions in async queues: Abusing state validation gaps in event-driven architectures to push through unauthorised transactions. 2. Token propagation abuse: Exploiting the trust gap between an API gateway and its downstream services to chain into deep IDOR. 3. OAuth state-machine quirks: Turning minor implementation oversights into persistent session hijacking. The goal isn't just to show what broke. Attendees will come away with a method for reading an architecture diagram and spotting where the logic synchronisation is weakest, a framework for building these chains deliberately, and concrete design-layer fixes that actually address the root cause rather than just patching symptoms. Key Takeaways for Attendees: - A clear method for analyzing an architecture diagram to spot where logic synchronization is most vulnerable. - An adversarial framework for systematically building exploit chains out of low-severity context flaws. - Concrete, design-layer remediation strategies that address the root cause of these architectural gaps.

Ranking Every Trainer in Pokemon Red

Nathan Sullivan

10:00 (30 minutes) · Room 1B · Talk · Intermediate · Wildcard

Title could maybe be better. At the start of this year I was working on a small project to rank every trainer in Pokémon Red. There’s a mix of how the GameBoy system works, how Pokemon Red works, how you can use emulation and Python to automate the game and build a fun set of statistics. The output of the project was 1400 hours of video from around 1.6 million battles run in the cloud, and there’ll be a YouTube video about it sometime in the coming months if I get around to finishing my write up Topics involved: * The Game Boy system * Console emulation * Pokemon Red * Assembly * Python * The Cloud (minor)

Create You First Linter

Manuel Doncel Martos

10:00 (1 hour) · Workshops · Workshop · Intermediate · Engineering

Over the years, I’ve built several linters and in this session, I’ll show you how surprisingly simple it is to build your own linter in Go, but also,how powerful it can be. You’ll learn how to create a linter from scratch, plug it into golangci-lint, and use it to enforce your team’s style guide automatically in CI.

Deprecated: The role was redundant. Not me.

Andrew Paul

10:45 (30 minutes) · Hall 1A · Talk · Introductory · Career

When my manager asked for "a team update", I had no idea I was about to enter one of the least-talked-about experiences in a professional career. And yet within days I discovered something uncomfortable: almost everyone I told had quietly been through something similar. The nods. The knowing looks. The "yeah, that happened to me too." So why does nobody talk about it? Redundancy is surprisingly common, poorly understood and almost entirely absent from any conversation about career resilience... until it happens to you. A bit like pensions, really. A few people in the loop. Most people beside it. Almost nobody prepared. Drawing from my own recent experience and 15+ years working across the software industry, this session maps the redundancy process honestly against the Kübler-Ross five stages of grief. Because it turns out you don't go through it once. You go through it twice- first through the consultation, then again through the job search. And the second loop is the one nobody warns you about. This isn't a session about failure. It isn't toxic positivity about doors and windows either. It's an honest conversation about something that happens to good people doing good work at companies that simply pivot. You can do everything right. The role still gets deprecated. You'll leave with a framework for recognising where you are emotionally if or when it happens, the language to talk about it (to yourself and others) and the reassurance that end of support doesn't mean end of service. Because deprecated isn't deleted. It's just ready for what's next.

Local AI at the End of the Tunnel

Mike Irving

10:45 (30 minutes) · Room 1A · Talk · Introductory · AI

In this session we'll combine Local AI, .NET and Dev Tunnels! To begin we'll look at how easy it is to install Ollama, and download a suitable model to run locally, on our own computers. Turning to code, we'll then discover how quick it is to connect to Ollama via our own C# Code, using the Microsoft.Extensions.AI library. Initially interacting via our own Console App. Sidestepping, we'll look at an often overlooked feature: Visual Studio Dev Tunnels. We'll look at the benefits for Web Applications and Web API. Bringing everything together, we'll take our (minimal) Console App code, bake it into a Blazor Web Application, and expose this via a Web Tunnel. Creating a route through to our Local AI installation from any web modern browser.

This code is a crime scene!

Nick Cousins

10:45 (30 minutes) · Room 1B · Talk · Introductory · Engineering

There’s been a murder. The victim? A perfectly respectable software project. The codebase is riddled with technical debt. Nobody dares touch that module. Deployments require two developers, a spreadsheet and a small religious ceremony. So, who killed it? Was it the developer who copied and pasted the same logic six times? The architect and their seventeen microservices? The product owner who kept changing the requirements? Let’s examine the evidence. Because terrible software isn’t necessarily written by terrible developers. Often, it’s written by good people making reasonable decisions in circumstances that make bad software inevitable. In This Code Is a Crime Scene, we’ll follow the clues from bad code back to the organisation that produced it — and discover why fixing the code without understanding what killed it can leave you with another body two years later. Three key takeaways * Examine the evidence: recognise when technical problems point to deeper organisational problems. * Establish the motive: understand why bad technical decisions were made before trying to fix them. * Prevent the next murder: change the conditions that created the mess, not just the code they produced.

Introduction to Python and Electronics - code your own game controller

Vicky Twomey-Lee

11:15 (1 hour) · Workshops · Workshop · Introductory · Engineering

Ever wonder how Python and electronics work together? What's CircuitPython? This exciting electronics-based workshop brings creativity and technology together to enhance the gaming experience. Learning how to build a custom game controller, participants will develop skills to tailor the design and functionality of their gaming preferences. 👉 What you need to bring is your laptop with Thonny installed - https://thonny.org We will provide the rest of the components and materials needed for the workshop.

Don’t Let the Bots Win: Taming Web Traffic Without Hurting Real Users

Eve Brennan

11:30 (30 minutes) · Room 1A · Talk · Intermediate · Security

With automated traffic now surpassing human users and with "bad bots" making up 37% of web traffic, the modern web is increasingly hostile. Traditional security measures like robots.txt are routinely ignored, leaving modern applications highly vulnerable to non-organic traffic surges. This results in outages, increased infrastructure spend, skewed metrics, and decreased confidence from advertising networks. Attendees will learn how to counter this threat by deploying a Web Application Firewall (WAF), while navigating its trade offs such as elevated page load times and false positives that can mistakenly block human users, search engine crawlers, or third-party ad integrations. The session presents a rollout playbook, based on a real world case study from a global media company: a phased, risk-managed approach to introducing WAF safely and reducing bot traffic without disrupting legitimate users or business-critical integrations. This session is aimed at engineers and anyone responsible for the performance, security, or business metrics of a high-traffic website.

Getting Shit Done in Two Worlds

Stephen McCullough

11:30 (30 minutes) · Room 1B · Talk · Advanced · Engineering

I build software in two completely different worlds, with the same AI in both. By day I am a principal engineer on a ten-person team, building a distributed AI framework on a graph, wrapped in real governance: human-in-the-loop, guardrails, sign-offs, the lot. By night I run a small consultancy that is me, sometimes one other engineer and a salesperson, shipping monolithic apps with barely any of that. Same models. Same thirty years of habits. Wildly different rules about how far I let the machine run. And I have spent this year paying close attention to what that actually does to the work. The timing is the part I cannot stop chewing on. My day job embraced all of this early and hard, and at the very same time it was scaling up, which meant Agile, governance, sign-offs and ceremony arriving in force. So one world went all-in on the new way of building and wrapped it in heavy process. The other went all-in with almost none. Same paradigm shift, same embrace of it, wildly different amounts of scaffolding around it. And thirty years in I am certain the shift is real: what it means to be a software engineer has genuinely changed, not just sped up, changed. Getting to watch that land in two such different setups at once is the most instructive thing this career has handed me. This is not a "how AI made me faster" talk. We are all faster, and that turned out to be the least interesting part. What is interesting is everything the tool exposed the moment it stopped being the bottleneck: how much governance a piece of work really needs, when guardrails save you and when they are just fear with a process bolted on, and what a big team is genuinely for once one person and a machine can carry a whole app on their own. I will show you the software factory I actually use to get things done: the full-throttle version I run solo, and the stripped-down version that survives inside a governed team. The gap between those two is the clearest picture I have ever had of what engineering at scale really costs, and really buys. I am measuring both sides between now and the conference, and I will put the honest results on the screen, including the ones I do not like. Then I will give you the rule I use to decide how much to trust the machine, and how much rope to give it, depending on which world I am standing in. No sales deck, no tool demo. Just a thirty-year engineer, two very different ways of shipping software, one AI, and what I have learned running it at both extremes. Key takeaways: Why the job of a software engineer has genuinely changed, not just got faster, and what happens when a scaling org embraces that shift and layers Agile, governance and ceremony on top of it at the same time. How to decide how much governance a piece of work actually needs, instead of wrapping everything in the same process by reflex. When guardrails and human-in-the-loop genuinely save you, and when they are just expensive fear. A software factory you can steal: the full version I run solo, and the stripped-down version that survives a governed team. Honest results from running the same AI at both extremes, including what went wrong.

Taste in the Age of AI: Designing When Everyone Can Create

Rachael Aluko

13:00 (30 minutes) · Room 1A · Talk · Intermediate · Design

AI has made creating faster, cheaper and more accessible than ever. We can generate interfaces, prototypes, images, code and entire product concepts with a few prompts. But when everyone can create, what separates a useful solution from a convincing one? This talk explores why taste the ability to make informed judgements about what is good, appropriate and worth creating is becoming an increasingly important skill for designers. We’ll look at how designers can use AI more effectively by bringing the skills AI cannot provide on its own: understanding people, framing problems, setting meaningful constraints, making trade-offs and thinking beyond the interface to the wider system. We’ll also explore prompting as a design skill. Rather than treating prompts as magic words, we’ll look at how better questions, context and constraints can lead to better AI outputs and why the quality of an AI generated solution is often limited by the quality of the thinking behind it. The future of design may not be about who can create the most. It may be about who can decide what is worth creating.

Cyberdecks : From scifi to reality

Dervla O'Brien

13:00 (10 minutes) · Room 1B · Lightning · Introductory · Wildcard

Cyberdecks: what are they, why are people making them and how far can I get towards making my sci-fi dreams a reality? There's been a trend in some (admittedly niche) areas of the internet for making cyberdecks. These devices started out in 1970s sci-fi novels as personal devices hackers owned, came on screen in 1990s techno-optimist films and now young people online are making their own using Raspberry Pis and hot-glue guns. In my talk I want to briefly explain the internet subculture, show off my progress into making my very own and explain how creative side projects like this can bring use back to what is currently just e-waste. A perfect talk for anyone who reads too much sci-fi and wants to bring creativity back to their side projects.

OWASP PTK Hands-On: Test the Browser State Your Scanner Cannot See

Denis Podgurskii

13:00 (1 hour) · Workshops · Workshop · Intermediate · Security

Modern web applications are authenticated, JavaScript-heavy and stateful. A server response is only the input to the application the user ultimately runs: the browser adds routes, DOM mutations, storage, tokens, loaded components and the exact sequence of actions that reached the state under test. This is a practical, laptop-based workshop using OWASP PenTest Kit (PTK), a browser-native application-security toolkit. Participants will test deliberately vulnerable applications running only on their own machine. They will reproduce a transient SPA weakness, correlate DAST, SAST and IAST evidence, compare it with a repaired control, and then run DAST, SAST, IAST and SCA across one authenticated macro-guided journey. A final request-focused exercise shows why a JWT inside nested JSON is different from a token discovered in cookies or browser storage. We finish by taking the same deterministic journey toward CLI and CI automation. The workshop does not position browser-native testing as a replacement for proxies, source analysis or established scanners. It shows how the browser's live session and runtime state can supply evidence those tools may not observe alone, and how the resulting workflow can complement OWASP ZAP. Participants leave with a repeatable method for connecting a user action to a request or runtime operation, a security finding and a repaired control—not just a list of scanner alerts. ## Format - 60-minute hands-on workshop - Approximately 15 minutes of guided explanation and 40 minutes of exercises - Individual or paired work on attendee laptops - Local, deliberately vulnerable targets only - Prepared screenshots and completed results are available as a catch-up path ## Intended Audience Developers, testers, students, DevOps engineers and AppSec practitioners who work with modern web applications. No previous PTK or professional penetration testing experience is required. Basic familiarity with a browser and web requests is helpful. ## Learning Outcomes By the end, participants will be able to: 1. explain the difference between an HTTP response and live browser state; 2. use DAST, SAST, IAST and SCA as complementary views over one journey; 3. reproduce and validate a transient SPA finding against a repaired control; 4. run an authenticated macro-guided scan without adding an unrelated crawl; 5. inspect and actively test a JWT carried in a nested JSON POST body; and 6. identify how a recorded journey can become a deterministic CLI/CI security check. ## Participant Prerequisites Attendees should bring a laptop with: - Chrome or Edge; - OWASP PTK 9.9.9 or later installed before the workshop; - either Docker Desktop or Node.js 20 or later; - the supplied workshop bundle or pre-pulled container images; and - permission to run local services on ports 3001 and 3080. Firefox is supported as a fallback, but the primary workshop path uses Chrome or Edge. No internet access or cloud account is required during the exercises. ## Safety Boundary All active testing is restricted to the supplied loopback targets. Attendees must not scan public, employer or third-party systems during the workshop.

When Your Software Starts Looking Like Your Org Chart

Shreya Sahu

13:15 (10 minutes) · Room 1B · Lightning · Intermediate · Engineering

We like to think software architecture is driven by technical decisions. In reality, it's often driven by reporting lines, ownership boundaries and incentives. This talk explores how organisational structure quietly shapes software, when that's helpful, when it hurts customers, and how engineers can recognise and challenge it.

Less Engine, More Game: Building a Game Engine Inside a Game Engine

Paul Barrett

13:30 (10 minutes) · Room 1B · Lightning · Intermediate · Engineering

What if limiting a general-purpose game engine could actually make development faster? This talk explores building a smaller, genre-specific engine on top of a broader one, replacing low-level concepts with reusable building blocks that simplify development and speed up iteration. A point-and-click adventure engine built with PlayCanvas React provides the case study, turning generic engine features into rooms, characters, hotspots, dialogue and inventory. PlayCanvas is the demo, but the idea applies equally to engines such as Godot, Unity and Unreal: invest in the abstraction once then spend more time building the game.

Terminal Panic: Building A Physical Console-Horror Experience, Because I Can

Neil McCallion

13:45 (30 minutes) · Hall 1A · Talk · Intermediate · Wildcard

I have always loved the chunky tactility of physical buttons, switches, flashing lights and all the trappings of the retro-future promised by classic science fiction, and realised in the arcades of my youth. So I'm building it: a bespoke physical game terminal, part retrogame remake and part movie prop, in an attempt to reimagine one of the most unique and obscure games in the legendary Alien franchise. The fact I can barely hold a soldering iron, never mind design circuits or work a 3D printer, will not scare me off. Join me for a personal project deep-dive that touches on game coding, hardware design, survival horror mechanics, emergent narrative, 3D printing, ‘cassette futurism’ and movie set UI. This is a story of actually finishing a project, building weird things for the love of the process, and the need for creative curiosity now more than ever.

From Zero to Container: A Java Quarkus Deep Dive

Jason Bell

13:45 (30 minutes) · Hall 1B · Talk · Introductory · Engineering

Java has a reputation problem in the cloud-native world: slow startup, heavy memory footprints, and an inner development loop that hasn't changed in a decade. Quarkus was built to fix all three and in this session, we prove it live. In twenty minutes we go from an empty directory to a running Docker container, using nothing but the Quarkus CLI and the tooling the framework generates for you. We scaffold an application with quarkus create app, explore a dev mode that makes Java feel like a scripting language, and finish by building and running a production-ready container image and no hand-written Dockerfile in sight. But this is a deep dive, not a demo reel. Along the way we unpack the single idea that makes Quarkus different: moving framework work, classpath scanning, dependency injection, configuration parsing, from runtime to build time. Attendees see how that one decision explains Quarkus's startup speed, its memory footprint, its live-coding dev mode, and its path to GraalVM native images. Key learning areas: - Bootstrapping a production-shaped project with the Quarkus CLI and its extension ecosystem - The modern inner loop: live coding, the Dev UI, continuous testing, and Dev Services (zero-config databases via Testcontainers) - Build-time processing: what actually happens under the hood and why it matters - JVM vs. native packaging: honest trade-offs and a clear decision framework for each - Containerising Quarkus applications: the generated Dockerfiles, layered fast-jar packaging, and daemonless image builds What attendees take away: The exact commands, the mental model, and the reference material to go from quarkus create app to a deployed container the same day plus a grounded sense of where Quarkus fits in their stack, and where it doesn't. WHO SHOULD ATTEND Java developers curious about Quarkus or re-evaluating Java for cloud-native workloads. No prior Quarkus experience needed; basic familiarity with Maven and Docker is helpful but certainly not required.

All the data in the world

Pablo Brasero Moreno

13:45 (30 minutes) · Room 1A · Talk · Intermediate · Data

You may have heard of OpenStreetMap, a decades-old volunteer effort that seeks to rival with Google Maps. Or does it? This presentation will seek to dispel some common misconceptions, and show how you can use OSM for fun, profit, and even helping in disaster recovery on the other side of the world. Perhaps it will even encourage you to contribute back? This will be an AI-free presentation.

In Good Taste: How To Build Success Not Slop

Louise Laughlin

13:45 (10 minutes) · Room 1B · Lightning · Introductory · Design

How we design, build and deliver products is evolving… and the roles within that are changing too. Today, everyone has access to tools that can quickly create features that feel real. But fast doesn’t necessarily mean “right”. In this presentation, I’ll share five tangible design tips for those who say, “I’m not a designer,” helping you create successful solutions and ensure your vibe-coded ideas deliver real value for customers, today and tomorrow.

The Weird Creature You Have to Keep Alive Is You: Building a Self-Care Tracker with AWS and an ESP32

Hephzibah Wilson

14:00 (10 minutes) · Room 1B · Lightning · Introductory · Wildcard

Being a grown up is a lot like caring for a Tamagotchi, except the weird little creature that you have to keep alive is you! Unlike a Tamagotchi, it can be hard to track exactly what you’re doing wrong. In this lightning talk, I’ll run you through how I set out to make this a little easier for myself by combining cloud technologies with an ESP32 microcontroller to create a portable self-care tracker and virtual pet as well as hopefully giving you some inspiration to make your own!

Product Market Fit isn't a moment: Designing the systems that get you there

Nelson Okpalachukwu

14:15 (10 minutes) · Room 1B · Lightning · Intermediate · Product

Many founders and product managers treat product market fit as a destination - a single moment where customers suddenly arrive and growth takes off. In reality, its rarely an event. It is the outcome of deliberate systems, customer discovery, feedback loops, distribution, experimentation and product decision making. Drawing from experience in building technology products in both start up and enterprise environments, This session explores why product market fit should be viewed as a system rather than a milestone. Attendees will learn practical frameworks for validating ideas and identifying real customer problems, avoiding common product traps and designing products that continuously evolve towards market fit.

Making the Smart Dumb Thing Smart

Andrew Fletcher

14:30 (30 minutes) · Hall 1A · Talk · Intermediate · Engineering

I wanted one simple thing: access to the data from my own electricity meter. What followed was a journey through low-level Bluetooth, awkward pairing, undocumented behaviour, failed approaches and a bit of reverse engineering to make a supposedly “smart” device actually useful to me. But the meter is only one example. Our homes are full of devices and services that collect useful data about us while giving us little practical, programmable access to it. This talk is about making one proprietary thing work for me and the questions that journey raised about openness, interoperability and whether the smart things around us really work for the people who use them.

So, Why Do We Need Quantum Computers?

Jane Moore

14:30 (30 minutes) · Hall 1B · Talk · Introductory · Engineering

Quantum computing has gone from a scary research topic to a technology attracting a lot of interest from the wider tech industry. But beyond the hype, what problem are we really trying to solve... and what does quantum computing mean for software developers? This talk is an introduction to quantum computing from a software and engineering perspective. We'll look at what we've achieved so far, what quantum programs actually look like, and what it takes to get a quantum program running on a real quantum computer. The aim isn't to predict exactly when quantum computing will become mainstream, but to help developers understand what quantum computing is, why we might need it, where it could be useful, and what role we as software engineers could play in its future. Key takeaways: 1. Understand the basic ideas behind quantum computing without all the complex maths. 2. See how quantum programs differ from conventional programs and how they interact with classical computers. 3. Explore some of the big technical and practical challenges facing quantum computing. 4. Separate some of the potential applications of quantum computing from the buzz surrounding it. 5. Get an insight into the emerging roles for software developers in a future with quantum computing. No prior knowledge of quantum computing is required!

How to Be a Good Citizen Contributor to Open Source in the Age of Regulation

Roman Zhukov

14:30 (30 minutes) · Room 1A · Talk · Intermediate · Security

Open source runs everything. But in 2026 the ecosystem that sustains it experiences, perhaps, the biggest simultaneous challenges in its history: maintainer burnout, chronic underfunding, regulatory pressure (e.g, from the EU Cyber Resilience Act), an AI-accelerated vulnerability tsunami, and a flood of AI-generated issues and PRs. Open source projects experience "enforced collaboration" that has led companies, researchers, everyone to shove pull requests and demand immediate response from the community, often lacking awareness of the diverse open source governance and contributing norms. This session outlines how people from companies and society can responsibly contribute back to open source while preserving upstream health. It highlights two OpenSSF initiatives. First, a Concise Guide for Upstream Collaboration, developed by the Best Practices WG and aiming to help OSPOs guide employees through security upstream contributions. Second, the deliverables of the Global Cyber Policy WG, including CRA Maintainer Guidance, demonstrating how community developers can establish clear consumption expectations, shielding them from unreasonable compliance pressure. Attendees will leave with a clear understanding of diverse upstream ecosystem operations and how to interact with and responsibly contribute to open source projects we all depend upon.

Agentic AI lessons from my smart home

Rory Gallagher

14:30 (10 minutes) · Room 1B · Lightning · Introductory · AI

A story of what my smart home taught me about agentic AI: Where GenAI genuinely helps to build a smarter home, where it breaks down, the practical lessons that I bring back to my workplace, and where I think AI-powered smart home tech is heading next.

The Shortcut Tax: What AI Is Costing Your Career Growth

Destiny Amba

14:45 (10 minutes) · Room 1B · Lightning · Introductory · Career

Before AI, a hard bug meant hours of digging. You read docs, tried things, failed, tried again. That struggle is what built your skill, the same way lifting weights builds muscle. The weight is the struggle. Now AI can hand you the answer in one prompt. Fast, but you skip the workout. You get the fix, not the strength. This talk is about a habit I use to keep growing while still using AI every day: I start the code myself. I write the function signature, sketch the pattern, make the hard calls about how it should work. Then I let AI finish the typing. The thinking happens first. I'll walk through real examples from my own work, including building a notification system in Go, to show what this looks like in practice. I'll also share the trap version of this: what it looks like when someone skips straight to "write me a function that does X" and never builds the muscle for the hard part.

The 'Enlightenment' of LLMs and How to Exploit Them

Corey Duffy

15:00 (10 minutes) · Room 1B · Lightning · Introductory · Security

Your system prompt, a user's message, and the contents of a scraped webpage all arrive at a language model as one flat stream of tokens. There are tags marking who said what, but models largely ignore them, inferring roles from what text sounds like instead. When tone and tag disagree, it looks like tone wins. This talk walks through why the most interesting attacks don't come from users typing "ignore previous instructions": they come from a Jira ticket, a PR description, or a tool response that quietly tells your agent to do something else. I'll also look at why writing a stern system prompt just isn't enough to protect your agentic system. Key takeaways: - Why LLMs can't distinguish instructions from data. - How indirect prompt injection reaches your agent through the content it retrieves, not necessarily just the input that it's given. - An overview of some practical mitigation strategies.

Two Radios and a Terminal: Building a LoRa Command Line

Chris Laughlin

15:30 (30 minutes) · Hall 1A · Talk · Intermediate · Engineering

Off the grid... No Wi-Fi. No cellular. No internet. But the machine is still out there, and we still need to talk to it. In this talk, I'll show you how I built a remote outpost that can be monitored and controlled from miles away using LoRa: a Low-power Radio technology designed for sending small amounts of data over surprisingly long distances...( well, in this example maybe nearer rather than farther) Along the way we'll look at how LoRa actually works, its strengths and limitations, and decisions involved in building software for a connection that is slow, constrained and occasionally unreliable.

You Are Not Netflix

Lauren Taylor

15:30 (30 minutes) · Hall 1B · Talk · Intermediate · Engineering

Somewhere right now, an app with 12 monthly active users has a dedicated K8s cluster. Somewhere else, a "temporary" script is celebrating its 4th birthday in production. This talk will teach you how to avoid both fates. You'll leave knowing when to keep things simple, when complexity is genuinely justified, and how to spot the warning signs of over-engineering and under-engineering before shipping. Our LLM besties have dramatically reduced the time it takes to write code, making design the new bottleneck in software delivery. The most expensive mistakes now happen before anyone opens an IDE. It has never been easier to build the wrong thing at warp speed, whether that's a multi-region failover setup for an app with 12 users or a hacky fix that miraculously becomes the backbone of the entire company. Netflix's architecture is brilliant. It solves Netflix's problems. Most of us have very different problems, and copying their homework won't help. This is a practical framework for designing at the scale you actually operate. We'll dig into why over-engineering and under-engineering are two sides of the same mistake, and walk through questions that tell you whether the simplest design will still be standing in two years. Expect real stories and lessons learned from getting these decisions right, and a few from getting them very wrong. What will I take away? - A cheat sheet for validating that a simple architecture can be extended later, without adding speculative complexity - How to figure out whether a design decision is easy to reverse later, or a one-way door that deserves the whiteboard inquisition - Team habits for making better architecture trade-offs

Is this the CVE-nd? Inside the Vulnerability Data Crisis

Samuel Dynes

15:30 (30 minutes) · Room 1A · Talk · Intermediate · Security

This talk explores a growing crisis in the vulnerability intelligence ecosystem. The number of reported CVEs (Common Vulnerabilities and Exposures) keeps rising, while the agencies responsible for tracking them, CISA (Cybersecurity and Infrastructure Security Agency) and the NVD (National Vulnerability Database), are being weakened by political cuts. As a result, traditional vulnerability management tools are quietly failing, and their users don't even know it. At the same time, security researchers are finding it increasingly difficult to disclose vulnerabilities responsibly, exacerbating the long-standing tension at the heart of the CVE programme: balancing the interests of software vendors and researchers. Finally, we look at the latest disruption hitting the community: AI-assisted vulnerability discovery. As automated tooling begins generating CVEs at unprecedented scale, and with hugely variable quality, it is placing even more strain on an already creaking ecosystem. So all of this begs the question: is this the CVE-nd for vulnerability intelligence as we know it? And how do we as developers cope with a increasingly fragmented security space?

Debugging Feelings: a neurodiverse engineer learns how emotions and culture are made

Cormac O'Donnell

15:30 (30 minutes) · Room 1B · Talk · Introductory · Career

In my twenties I developed a crippling fear of flying. What eventually helped wasn't willpower or drugs - it was learning about the theory of constructed emotion, that the racing heart and clammy hands weren't an immutable part of me, but emotions that my brain was constructing from prior experience, and which I could learn to construct differently. That idea turned out to work on far more than aeroplanes. As a neurodiverse engineer - now an engineering manager - I've always found the human layer of work more layered and harder to pin down than the technical one: the emotions you're meant to just get, the unwritten cultural rules, the shared sense of what's "professional" or "fair" that nobody ever writes down. So I did what we do with any undocumented system: I went looking for an explanation, for the source code. This talk is on what I found, drawn from the science of how our own emotions are constructed, how moral foundations theory helps explain why others think differently and how all this comes together as culture. I'll move from managing my own stress before high-stakes moments, to why well-meaning people with different moral instincts end up furious and talking straight past each other, to learning how to read the company or team culture from what emotions are fostered and which ones are forbidden. It's for anyone - neurodivergent or not - who's found the people part of work harder than the code. It's based in real science, and it's given me a model to navigate the work environment. Key takeaways: Emotions as constructed predictions you can reframe — a practical handle on anticipatory stress before demos, incidents, and difficult conversations Why moral disagreements at work lead to deadlock, and how seeing the intuitions underneath makes them navigable rather than infuriating How to read a team as a culture formed of the emotions they display, instead of taking what they say at face value.

Decoding Irish Trad

Sean McGurk

16:10 (30 minutes) · Hall 1A · Talk · Introductory · Wildcard

How an engineering mindset helped me to understand, appreciate and participate in Irish traditional music sessions Will include a live demo of a playthrough of some tunes and introduction to some technology that will help you to recognise, catalogue and learn tunes to play in next year's Fleadh

Follow the Twenty Quid: The AI Bill That Doesn't Add Up

Yuan Zhang

16:10 (30 minutes) · Hall 1B · Talk · Introductory · AI

No prompts, no agent architecture, no tooling demo. This is a talk about money. Twenty quid a month. That's what an AI subscription costs, near enough, whether it's ChatGPT, Claude or Cursor. Tens of thousands of pounds for a single chip. Warehouses of them, drawing power like a small city. Somebody is covering the difference, and it isn't me. I went looking for who, and got it wrong twice. Maybe nobody's covering anything, and this simply isn't expensive to run. Except power is only about 1% of what an hour of GPU time costs. The money goes on the chip itself. So the gap is real. Then maybe they're taking the loss on me. Except OpenAI's leaked, FT-verified accounts show serving turns a profit, and the twenty-billion-dollar hole is research. The answer is other users. The 95% who pay nothing, and more surprisingly the quiet payers who barely touch it. The expensive ones are the people in this room running coding agents overnight, and three companies have now said so publicly. That should have been the end of it. Except the labs spent twenty billion a year themselves, so somebody funds them too. Keep pulling and it stops being about software: thirty-eight billion dollars per gigawatt of datacentre, companies buying repurposed jet engines because grid connections take years, and SoftBank selling its entire Nvidia stake to fund a company that hands the money straight back to Nvidia. We have seen most of this film. Netflix burned cash for a decade at £5.99, turned profitable, and only then brought in ads, a password crackdown, and a £12.99 price tag. All three have now appeared in AI, the last of them in April. You'll leave knowing which of the five very different layers of this industry actually makes money, whether you personally are one of the expensive users, and one question worth asking about whatever you're building: what happen if the price of a token doubled tomorrow? Nothing to sell here. Every figure is sourced.

One Architecture, Any Silo: Proving Patterns Without Naming Victims

Megan D'Arcy

16:10 (30 minutes) · Room 1A · Talk · Introductory · Security

Domestic abuse reporting has a data architecture problem. To corroborate a pattern of abuse, systems currently assume the underlying raw data of the victim must be seen by whoever's verifying it. That single assumption forces an impossible trade-off: survivors either stay silent contributing to the dark figure of crime or expose sensitive data to centralised systems that become high-risk targets in their own right. This talk walks through a working Zero-Knowledge Proof architecture built to remove that trade-off entirely one where a statutory authority or third-sector agency can learn that a pattern exists. This can be a perpetrator that has been flagged by multiple independent reports, a threshold crossed, or a count without ever seeing a single name, incident report, or plaintext record. The system works by having each party for example, a police force and a support agency independently commit their records to a cryptographic hash rather than sharing the records themselves. Before that commitment happens, names go through a fuzzy-matching step so that naming variants, like "O'Neill" versus "Oneill," get grouped into the same bucket without anyone comparing raw strings directly. Each party then generates a proof from their commitment, and a verifier who never sees either party's plaintext data checks those proofs and groups them by their public phonetic identifier. When proofs from multiple independent agencies land in the same group, the verifier can say a pattern exists and how many times it's been corroborated, without ever learning a name, date of birth, or case reference. The only thing that crosses back to whoever's watching for patterns is a count and a yes/no flag nothing that could re-identify anyone. Key Takeaways: How Zero-Knowledge Proofs differ practically from Private Set Intersection and Data Clean Rooms, and why PSI's binary yes/no output can't support pattern-counting use cases A working architecture for cross-silo pattern detection where a verifying authority learns only an aggregate signal (a count crossing a threshold) never plaintext records, names, or case files The real engineering challenge of encoding fuzzy, approximate matching (handling naming variants) ahead of a zero-knowledge circuit, and what's involved in eventually moving that logic inside an arithmetic circuit A transferable architectural pattern: any scenario with multiple independent parties needing to corroborate a pattern, without a central party being trusted with raw data

We Sped Up Apache Commons' CI Pipeline 3x With an Algorithm From 1969

Marjia Siddik & Samson Oloruntola

16:10 (30 minutes) · Room 1B · Talk · Intermediate · Engineering

While working as software engineers, we kept watching our CI pipeline crawl to the finish line; one job would drag on forever while three others finished ages ago and just sat there. We got fed up and decided to fix it. Turns out the answer already existed: Longest Processing Time (LPT), a scheduling algorithm from 1969, decades before GitHub Actions was even a thing. We built TestSplit, a CLI tool that profiles your JUnit test suite and uses LPT to split tests across parallel CI jobs so no single job ends up carrying everyone else. We’ll go through why naive splitting, alphabetical order, and round-robin always end up with one overloaded job and a bunch of idle ones, and why LPT's dead simple rule (sort by duration, fill whichever bucket is emptiest) beats it every time. We also implemented MULTIFIT, which uses binary search to obtain a tighter split when LPT's approximation isn't sufficient. We'll get into the actual problems we ran into building both: tests with ordering dependencies that broke LPT's assumptions, floating-point precision bugs in our binary search, and the challenge of parsing Java source files for dependencies without writing a full AST parser. We ran it against Apache Commons Lang, a real open-source repo with 231 test classes and 64,725 tests, and got a 2.24x speedup on test execution and 3.1x over running it sequentially. We'll also be honest about where it falls short: almost 90% of Commons Lang's tests returned a zero duration in the XML output, which messes with scheduling accuracy. If you've ever sat there watching a CI pipeline crawl and thought "there has to be a better way," this is for you. No ML or academic background needed, just tests that take too long. You'll leave with a real mental model for how a 1969 algorithm still beats most naive approaches to a very modern problem, and a working, open-source CLI tool you can point at your own test suite this week to see the difference yourself.