# GopherCon UK 2026 > Source: > Published: 2026-08-14 09:40:55+00:00 For the 3rd year running, I've been at [GopherCon UK](https://www.gophercon.co.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! [Ainsley Clark](https://ainsleyclark.com) 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: A great comment Ainsley made towards the end of the talk stuck with me: work makes you capable, people give it meaning 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](https://www.linkedin.com/in/william-kennedy-5b318778)'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](https://www.jvt.me/posts/2025/08/15/gophercon-uk-2025/#building-a-coding-agent-from-scratch). [Tom Coupland](https://uk.linkedin.com/in/tomcoupland) 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](https://www.jvt.me/posts/2019/10/12/devopsdays-london-2019/#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). [Haseeb Majid](https://haseebmajid.dev/) 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](https://docs.renovatebot.com/) shout out 🤓 [Andy Kuszyk](https://akuszyk.com/) 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! 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. [Kemal Akkoyun](https://kakkoyun.me) spoke about [some similar things to last year](https://www.jvt.me/posts/2025/08/15/gophercon-uk-2025/#unleashing-the-go-toolchain), 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 [Dave Cheny](https://dave.cheney.net/) 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](https://dave.cheny.net/paste/gophercon-uk-2026.html). The final code is ~2 pages but very elegant and performant! [Bryan Boreham](https://uk.linkedin.com/in/bryanboreham)'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](https://www.jvt.me/posts/2023/05/29/learn-how-to-build-tools/) 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: [Veronika Volokitina](https://de.linkedin.com/in/veronika-volokitina) took us through some infrastructure changes at Zalando, and how they used their [zalando/skipper ingress](https://github.com/zalando/skipper) as the central point for configuration rules. [Andy Kuszyk](https://akuszyk.com/) 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: This one went a bit over my head, as it was fairly heavy on the trading side of things. 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) 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](https://www.meetup.com/londongophers/events/315973770/)! 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 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](https://github.com/pkg/group) library, which distills years of trying to solve this problem. [Andy Williams](https://andy.xyz) 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!