GopherCon UK 2026: Using AI with Purpose

This was my third year at GopherCon UK, and it's been interesting watching how the way AI is talked about at the conference has evolved over that time: timid experimentation at first, a much more confident embrace of it last year, and this year, something different again, a more engineering-minded approach. The best talks weren't about AI as a magic black box that does your work for you. They were about AI as a tool, one that, used well, demands more deliberate thinking from developers, not less. Two threads ran through the talks I found most interesting: running AI yourself, and staying a deliberate, engaged human when you let a hosted service run it for you.

The trend that stuck with me most was running AI models locally and embedding them directly into a Go application, instead of calling out to a hosted provider. Bill Kennedy’s workshop on Kronk, an SDK-first Go project, walked through what this actually looks like in practice: no server required, the model runs in-process, called from your own code via PureGo and FFI, which let Go talk directly to native inference engines like llama.cpp without compiling any C into the binary. The appeal is obvious. You're no longer dependent on a costly AI provider sitting in someone else's data centre, and the software stays yours end to end.

What's less obvious, and more interesting, is the flip side. Running the model yourself means taking ownership of everything involved in getting it to work well: which model actually fits your use case, how much accuracy you can afford to lose to quantization, whether a dense or mixture-of-experts model suits your hardware, how you balance context window size against memory. None of that is optional once you own the model instead of renting access to one. It's the same tension as the classic build-versus-buy decision: buying a hosted API gets you a black box that mostly just works; building it yourself gets you control, but only if you're willing to do the thinking that control demands. Bill also gave a talk with the shortened version of the workshop, which is available on YouTube.

That same idea, that AI rewards deliberateness rather than replacing it, showed up again and again outside the workshop.

Ainsley Clark's talk, “How to Stay Passionate in the Age of AI,” made the case that AI is blurring the line between what a developer built and what an agent produced, and that this can quietly erode the sense of accomplishment that comes from making things. His line that stuck with me: work makes you capable, but people give it meaning. His advice was practical rather than preachy: prompt efficiently and post-process results so you keep ownership of the decisions, write your own commit messages so you actually understand the why behind a change, set boundaries on how much you lean on AI, keep building things independently, teach others, and stay connected to communities, because the harder problems still need people, not just code. AI can be a genuinely good learning tool, but only if you decide to make the time for it rather than letting it make the decisions for you.

Tom Coupland's talk, “From AI Sceptic to AI Sceptic Who Ships,” was an account of actually shipping meaningful AI-built features at Paddle. His team builds what he called harnesses around their agents: hooks, which are deterministic rules like always raising pull requests as drafts, and hinters, softer nudges toward good practice, both refined continuously over time. They lean on behaviour-driven development (see this talk for more on BDD) with Cucumber to lock down user-facing behaviour while still letting agents refactor freely underneath it. The habit I hadn't heard before, and the one I found most interesting, was the reverse of what you'd expect: rather than quizzing the model, he has Claude quiz him about the work he's doing. It keeps him on track and pushes back against the very common temptation to just accept every edit and skim the diff. At the same time, judging the quality of the questions Claude asks becomes its own check on the model: if the questions start missing the point, that's a signal something has drifted. He also pointed out that AI shifts the usual build-versus-buy calculus toward building, which only raises the stakes on testing everything you build properly.

Andy Kuszyk gave two connected talks about how Typeform rebuilt parts of its product around AI. The first, “MCP is the New REST,” argued that simply wrapping an existing REST API as a set of MCP tools isn't enough: large language models work far better with semantically meaningful, purpose-built tools than with raw endpoints. Pointing an agent straight at a REST API means it can bypass all the business logic and checks that normally sit in front of that API elsewhere in the stack. His fix was to build MCP servers that sit alongside existing services, carrying the same guardrails and domain logic, but tuned specifically for how an agent consumes them, with orchestration handled server-side to reduce the cognitive load on the model. Each team owns the MCP servers for its own domain. The second talk, “Building a Polyglot Multi-Agent AI Architecture,” followed directly from that: an architecture of specialised agents, one per service, each with access to only a handful of MCP tools, with a single dispatch agent as the only thing the user actually talks to. Keeping each agent's context small this way is what makes memory and token usage manageable at scale. He grounded the design in Conway's Law, argued for favouring product solutions over platform ones, and framed the highest-stakes infrastructure choices as reversible two-way doors, so a decision like starting on AWS AgentCore doesn't become a trap if you later need to move to something like Temporal.

Put together, the common theme underlying these talks wasn't really about developers doing more deliberate thinking, though that was part of the talks, too. It was about being more deliberate with how we’re using AI agents: what systems, boundaries and checks get put in place, purposefully chosen for the use case in front of you, rather than left to default. Whether that's picking and tuning a model to run inside your own Go binary, or deciding exactly which tools an agent is allowed to touch, the pattern is the same. I came back from this year's GopherCon UK inspired to be more purposeful and deliberate in how I use AI agents day to day, and with a concrete plan to start exploring embedding local AI models into my own Go apps.

Need help?

Nimble Ape has been consulting on real-time media projects for over a decade. We build products, including in Go, for clients big and small all over the globe. If you’re working on these technologies and need some extra support, we’re happy to help.

Why not drop us a line on [email protected].

- Marco and the Nimble Ape team