

Not Everything Needs an LLM
Dave Hall Principal Consultant Dave Hall Consulting
I got frustrated. My support tickets kept getting routed to the wrong team. Every misroute added a day to resolution. I decided to fix it.
The obvious approach in 2024 was to throw the problem at an LLM. I knew that wasn’t going to work. The overlap in team responsibilities made it impossible to write a concise prompt. Tokens would burn fast, accuracy would be unpredictable, and the whole thing would be fragile.
So I built Gata instead. It’s an open source ticket router for Zendesk, and the core routing uses a fine-tuned BERT model trained on your organisation’s own ticket history. LLMs do appear in the stack, but for the tasks they’re actually good at: priority classification and ticket summarisation. The routing itself doesn’t need one.
This talk walks through that decision-making process. How do you evaluate whether a problem actually needs an LLM? What signals tell you a fine-tuned classifier will outperform a general-purpose model? And how do you build something that gets more accurate over time rather than drifting with every prompt change?
You’ll leave with a practical framework for matching automation problems to the right tool, and a concrete case study of what that looks like in production.

The AI Tax and "legal" ways to minimise it
Krishna kanth Mundada Software Engineer Versent
AI tools feel productive. That's the problem. A 2025 METR study found experienced developers were 19% slower using AI on their own codebases, yet believed they were 20% faster. I didn't need a study to tell me something was off. I could feel it: more code shipping, more bugs slipping through, reviewing functions I couldn't quite explain, and a growing sense that I was managing a workflow rather than doing engineering. That's the AI tax. The hidden overhead that accumulates every time you prompt, verify, redirect, and re-contextualise. It doesn't show up in your commit count. It shows up in your cognitive load, your code familiarity, and eventually your production incidents. This talk is about what that tax actually looks like day to day, why it's hardest to spot when you're most productive-feeling, and the practical strategies I've used to minimise it without throwing away the tools.

Your engineers aren't afraid of AI. They're afraid of becoming junior again.
Andy Kelk Fractional CTO Self Employed
When you roll out AI coding tools, you expect pushback about job security and workflow disruption. What you get instead is something harder to fix: senior engineers watching AI produce in seconds what used to take them years to master.
This talk is about what's really driving quiet resistance in your team and what you can do about it.

Panel: Engineering Reality
AJ Fisher; Dave Hall; Krishna kanth Mundada; Andy Kelk Technologist & Writer ajfisher.me
A moderated conversation closing the L3 Engineering Reality session. AJ Fisher leads a discussion with Dave Hall, Krishna Mundada, and Andy Kelk on when not to reach for an LLM, the real costs of AI in production, and what it means for engineering teams and careers.