GopherCon UK 2026

For the 3rd year running, I've been at GopherCon UK and am surprised to have survived the heat in London - highs of 36 degrees yesterday - but thankfully The Brewery is a lovely and cool event space.

I'm writing this on the train home, with a slightly tired voice, and a little tired after a good time - thanks again to the organisers for putting it on!

How to Stay Passionate in the Age of AI

Ainsley Clark kicked us off by talking about ways that we can stay passionate with the reshaping of our roles in the world of AI.

Ainsley shared how, as humans, we have an "ancestral" need to create. In the current age of AI, there's a blurred line between human and agent and who is doing the thing, and that impacts the sense of accomplishment that comes from building.

Ainsley quoted a number of studies around developer satisfaction and how AI is leading to increased stress, all of which I'd recommend digging into further, as well as "the IKEA effect" study that showed that people who were involved in making a thing (food, origami, furniture) would put more value onto the resulting artifact.

Ainsley left us with a few tips to reclaim some of the craft in this new age:

1. Prompt more efficiently: studies show it helps makes us feel more competent and accomplished
2. Post process the results: Review why code works, before you accept it
   • This helps you own the decisions over the lines (as, at the end of the day, you are owning them as you're the one committing them)
   • This is why I will always write my commit messages when using AI - I find it a valuable part of the process to understand why we're doing what we do (because I need to explain it in my own words) - I'll blog about this in more detail shortly
   • Ainsley described this as "making sure work passes through your hands"
3. Invest in understanding: Ainsley noted how - writing notes by hand is better for your memory, and this can be a similar avenue
4. Set boundaries: for instance, only use AI when you fully understand a problem, or you could use it to prototype the change, throw it away, and write it from scratch, once you have the understanding
5. Build stuff: it doesn't have to be day-to-day usage, but making sure that you're still building things for fun and as a way to work with the tools and get a feel for them
   • I've personally been finding that sorting out a couple of my personal projects has been good for this
6. Teach what you know: as it reinforces the learnings you've had moreso than if you had only learned it yourself
   • This is one of the reasons I write my learnings as a form of blogumentation.
7. Find your niche: if you can differentiate yourself in a world where code scaffolding is cheap, could you be more T-shaped? Maybe specialise in a domain, or a type of problem like dealing with flaky tests?
   • Ainsley also noted that specialist skills are usually better than generalist, quoting how salaries are affected by it
8. stay connected: for a sense of community and your own mental health and reduced stress levels
   • AI can't - currently? - build trust with a skeptical product leader, or any of the personal challenges that are outside of the code being written, and how there are tiny decisions that lead up to a big one, where the AI can't shine
9. Keep learning: if you continue to stay out of your depth, it'll give you the chance to learn and stretch yourself

A great comment Ainsley made towards the end of the talk stuck with me:

work makes you capable, people give it meaning

Kronk: Hardware Accelerated Local Inference

I'd meant to get to Andy's Full Desktop Environment in Go talk, but my water bottle had leaked all over my bag, which meant I had to run up to my room and dry it off 😅 Luckily the contents of my bag - my laptop in particular - were dry, but it did mean I was then cutting it close to the talk starts, and when I got downstairs, I realised I'd left my lanyard - so was then definitely going to attend late.

Not wanting to join Andy's talk late, I went to Bill Kennedy's talk, which is in a much bigger room that isn't as noticeable when you're trying to sneak in - I was still a late joiner and apologise, Bill!

This was a good live demo, and Bill is a great speaker, and was an evolution of last year's talk he did.

From AI Sceptic to AI Sceptic Who Ships

Tom Coupland from Paddle talked about going from an AI skeptic to someone who was part of a team shipping some pretty large features that wouldn't have been possible with the same human investment.

I'd very much recommend watching this one, as it was both very interesting, but also a really strong talk - it flowed well, was engaging, and didn't feel like an hour long talk, which is hard to do!

Tom took us through how joining onto a "tiger team" to really "kick the tires" of AI, the team were able to lean on AI, allowing Paddle to achieve some very ambitious changes internally, despite Tom being an AI skeptic to begin with.

Tom talked about how, over time, the team would continually improve the "harness" around the agents (not to be confused with a harness like Claude Code) which would allow for the agent to know they're doing the right things with "hooks" and "hinters". Hooks would be deterministic, small-but-important checks like "always raise a PR as a draft", and would be something the LLM doesn't need to think about, but would be enforced, and then the hinters would provide a way to nudge towards non-deterministic skills.

Tom also talked about how getting Claude to quiz you on what it's doing can be a good way to ensure that everyone is aware what's going on - a question may lead to you rethinking the approach, or your answer may surface a change the LLM needs to make to the plan.

Tom noted that for these big new greenfield systems being built, when the team owning it were asked how they were finding it, they mentioned that in the last 3 months, "we barely even think about it", which is incredibly surprising for anyone who's ever been in this situation before.

Tom spent a bit of time talking about how the team decided to lean on Behaviour-Driven Development using Cucumber as a way to provide a stronger test harness for the underlying functionality these services were providing. By blocking the LLM from changing any BDD tests, it allowed large refactors of internals (which often change unit tests) to be done without changing any user-facing functionality, which is something I've found in previous years of writing these tests, and it's a great way to keep the LLM on track.

Tom noted that teams need to be "in a good place" before their AI usage can supercharge them, instead of send them off in the wrong directions. This reminded me of Tom Hoyland's talk Building and Growing an Agile Team, and the fact that if you have a team that is aligned, understands their goals and can work autonomously towards that goal, then they'll achieve well - but adding AI into a team that isn't in that state can be a big mistake (as many organisations are doing).

Building a Web App with Go & HTMX

Haseeb Majid gave a good talk on lessons learned building a Go web application, sharing some great library choices in HTMX, Templ and sqlc.

Haseeb took us through how the application had developed - and how approaches had changed over a few iterations of different web applications, and breaking down the different ways that the stack works.

I'd mentioned to someone after the talk that this is a stack I've been meaning to play around with for some time - hopefully this is the inspiration to get it done!

And thanks Haseeb for the Renovate shout out 🤓

MCP is the new REST: making MCP Typeform's new API

Andy Kuszyk took us through the process of building a set of Model Context Protocol (MCP) APIs at Typeform.

This was a good talk taking us through how Typeform introduced MCP servers into their offerings, and the shift in user experience over the last few years to also needing to take agent experience into account.

A key thing Andy shared was that LLMs prefer MCP because they prefer semantically meaningful tools. If you are ""just"" wrapping your RESTful API as an MCP server that's autogenerated too, you're likely going to be doing things worse for your users.

Instead, you need to consider whether the resulting input/output types can be tuned to be more LLM-friendly, or whether there are orchestration API calls that you can do in the MCP server, so the LLM doesn't need to do them itself.

Andy recommended that instead of building an isolated MCP server that then calls your RESTful/GraphQL/etc API, you instead have the MCP server built into your web API, so it has access to the same underlying code + business logic the rest of the API has. But as you're not constrained by the API's surface, you can do things in a different and more agent-friendly way.

This was a good talk, some great actionable tips, and Andy was a great speaker - I'm very glad I went to both talks!

How Much CompSci Can Go Teach?

Eleanor McHugh and her son took us through the current state of the Computer Science curriculum in schools, and how they've used Go to supplement the teaching.

Instrument Go Without Changing a Single Line

Kemal Akkoyun spoke about some similar things to last year, but with some new tricks.

We heard about some upstream OpenTelemetry projects like OBI which can make it much more straightforward to instrument the boundaries of your application - with no code changes - allowing you to then focus on the internal business metrics.

I'm sure my ex-colleagues at Elastic will be happy to hear Kemal say:

Elastic's OTel profiler (which was donated to the OpenTelemetry community) is a work of art

API Design as a Performance Primitive

Dave Cheny gave an interesting talk about how focussing on up-front performance considerations can really make a difference.

In an ecosystem like Go, we're generally writing performance-sensitive code, and it was interesting seeing how much performance you can gain if you really put in that time up-front, and Dave had the benchmarks to prove it!

Dave noted that no matter how fast the Garbage Collector is, it'll never be as fast as no cost - so we need to take that into account. Additionally, our API design influences how many allocations are needed, and allocations can influence performance.

There was a lot of hard evidence of the approaches, and I'd recommend a watch, as well as reading through the slides. The final code is ~2 pages but very elegant and performant!

Build Your Own Tools to Refactor Go Safely

Bryan Boreham's talk started with a celebration of his 10th anniversary of his first talk at GopherCon UK 🎂

This talk was a good reminder that building tools to support yourself is really important, and especially when they are tools that can help reduce the toil of reviewing large changes.

Go's very lucky because we have the tools to parse and manipulate Go code in our standard library, which makes it pretty straightforward to make these sorts of tools.

Bryan's key example was a refactor of ~5000 lines of Go code, which split a large Go file across multiple files, but that it was then a pretty hard diff to review.

In this case, regular diff tools weren't able to reason about the changes as easily, for instance "these lines are the same from where they were moved from", nor more complex cases like where a package was introduced for some types, further increasing the lines changed.

Bryan - with the help of Claude - wrote a tool to look at the AST before/after, and indicate where lines were "unchanged", "moved", "moved-changed", and it made reviewing much more reasonable, compared to reviewing the diff carefully, asking an AI to review it, or hoping that the tests would cover any changes.

Bryan left us with 3 thoughts:

1. Refactoring is good - but scary if it's from AI
2. Go has built-in things for these sorts of tools - and you don't need to know how they work!
3. Watch (your AI) - AI has no taste

One Definition of Valid

Veronika Volokitina took us through some infrastructure changes at Zalando, and how they used their zalando/skipper ingress as the central point for configuration rules.

Building a polyglot multi-agent AI architecture on AWS AgentCore

Andy Kuszyk took us through more of Typeform's AI evolution from yesterday's talk, and took us through the underlying architecture for Typeform's agent-based infrastructure.

This was another great talk, and Andy took us through some of the different trade-offs of architecture, how Conway's Law comes into effect, and different technical archtiectures.

I'd recommend a full watch of the talk, as there's a lot of great stuff for the exploration of the different architectures they considered, and how they came to the final answer.

Andy left us with 3 thoughts:

1. Conway's law can inform architectures
2. Solve for products, not platforms
3. Make high-stakes decisions two-way doors

• For instance, using AWS AgentCore is an expensive choice, but they've built it in a way that they can switch over to Temporal as needed
• Don't force an overall architecture or language-specific approach - using LangGraph for ease works in Python and Typescript, but it's not a requirement

Go, ONNX & AI in Production: Trading Platform

This one went a bit over my head, as it was fairly heavy on the trading side of things.

Breadth of content

I found it a little harder this year to choose what I wanted to go to, and it didn't seem like there was as much breadth, even though both years only had 2 tracks of talks and a tutorial track.

As I indicated to the organisers last year, having 30-minute talks would be really appreciated. Even not taking into account things like attention span and ADHD, an hour long talk is tough for the speaker and the audience. It takes a lot of effort for speakers to refine their talk - whether that's 45 minutes with time for questions, or using the majority of the hour - and it takes a lot more work to prepare.

Additionally, having shorter talk slots are - in my opinion - a little less daunting. I can imagine - and have spoken to folks before - that if you're looking to submit a talk, a full hour long talk is a harder thing to propose and prepare for, and can seem like something only "more experienced speakers" (for some definition of that) may be able to do. Having more folks at different stages in their speaking journey would be ideal - it's nice to hear from a range of folks who may be further along in their career, who've never done public speaking, or more junior folks who are incredibly talented storytellers.

There may have been some last minute tweaks to the schedule, but I noticed that there were a few speakers who'd had multiple talks, and as much as they're great, it's probably also good to give more folks the opportunity to speak, so we get a wider range of experiences and talk topic.

(And no, this isn't me being salty about not speaking this year)

London Gophers

Given the heat in London, I didn't want to risk getting on a train in ~36 degree heat, so decided to head home this morning.

But that did mean that I was in town for this month's London Gophers! It was nice to travel over with Andy and Dave, and the event was good but fairly subdued because it seemed like most people - me included - were a little conferenced out 🥱

Dave Cheney - Starting and stopping things; the jazz standard of middle ages Go programs

Dave took us through how RAM is a resource that should be treated as finite, even though having a Garbage Collector makes it feel like it's infinite.

In this talk, Dave took us through how Goroutines should also be treated carefully, with resources they allocate then not necessarily being treated as equally by developers, and how we should consider the cancellation of Goroutines (and any cleanup) ourselves, too.

This was a good talk that went through various options and libraries for doing this, finishing up with Dave's github.com/pkg/group library, which distills years of trying to solve this problem.

Andy Williams - Full Desktop Environment in Go

Andy Williams gave a shorter version of the talk (that I'd missed) on Wednesday, and so I was glad to have caught it.

Andy took us through FyneOS and some of the technical challenges that are needed to fulfill the moonshot of "should we build our own desktop environment", from window manager compositing to "how do I make it so someone can create a slot that sleeps on the top of their window".

It's been a good few years since playing around with my setup on Linux has been exciting - namely due to getting into a good rhythm with it, and not having the time to play around with it as much as I had in the past - but Andy's enthusiasm was contagious.

I must say I'm a bit of a bad friend not keeping on top of Fyne as much as I maybe should do - especially when I largely consume content about it in audio-only podcast form, which isn't great for a visual tool! - but it really does look pretty darn great, and I may end up getting more time to play with it soon!