GopherCon UK 2026: Day One

By Ruben Eik Mortensen, Engineering

Why we went

Earlier this year, Lunar introduced a new policy that lets employees attend conferences relevant to their work. GopherCon UK 2026 was the first conference Lunar employees attended since 2024. We hosted Go Aarhus at Lunar in 2026, but that was our own meetup rather than a conference we attended. Going to GopherCon gave us time away from our own services and technology: time to see what the wider Go community is releasing, and what other engineers are learning.

Across six talks, I kept seeing the same question: how do we use more capable tools without losing our understanding of the work?

Keeping ownership while AI gets faster

Ainsley Clark opened the day with How to stay passionate in the age of AI. The starting point was a sentence many engineers will recognise: “Why did you waste two hours on that? AI would have done it in ten minutes.”

That question assumes that time spent understanding a problem is waste. Ainsley challenged that assumption. Engineering is not only the final code. It is the decisions, constraints, experiments, and understanding that make the code ours. If AI takes over more of the implementation, it can also make engineers feel like passengers in systems they are responsible for.

Ainsley’s nine principles gave the talk a practical shape:

• Prompt efficiency
• Post-processing
• Invest in understanding
• Set boundaries and protect your understanding
• Build things — accomplishment creates value
• Teach what you know
• Find your niche and distinguish yourself
• Stay connected — AI cannot build trust
• Keep learning

The point was not to reject AI. Passion is built over time, while AI removes time from parts of the work. We therefore need to protect time for understanding and have patience. That landed with me because speed is useful, but speed without ownership is not much of an engineering experience.

Local AI needs more than a clever demo

Bill Kennedy’s Kronk, Hardware Accelerated Local Inference took the conversation from the effect of AI on engineers to the mechanics of running it.

Kronk is a Go SDK for hardware-accelerated local inference. In the demo, the application used a locally running model server. Depending on the hardware, Kronk can use Apple Metal, CUDA, or Vulkan instead of doing all the work on the CPU.

Bill built an asteroid game with a local 8B model and walked through the setup needed to run it. Local AI is easy to discuss as an infrastructure problem. Seeing the model run locally, and seeing how the pieces connect to a Go application, made it easier to reason about where it could fit.

Bill also introduced seeds. With the same model and runtime configuration, a fixed seed can make repeated runs produce the same output even after stopping and restarting the process. That is useful for local AI in Docker or Kubernetes, where reproducible behaviour makes workloads easier to test and operate.

Tom Coupland followed with From AI Sceptic to AI Sceptic Who Ships. Six months earlier, Tom had been sceptical of the AI hype. Autocomplete was useful, but the results did not match the claims being made about it. Then he got the opportunity to spend several weeks focused on AI, and that work became a high-pressure deliverable for a critical business deal.

Tom’s story was about the gap between an interesting prototype and production Go in front of customers. Scepticism did not mean refusing to use AI. It meant testing the claims against outcomes. That is a useful position for engineering teams: neither accepting every promise nor dismissing the tools before putting them under pressure.

Simpler interfaces, different clients

Haseeb Majid’s Building a Web App with Go and HTMX brought the day back to a more familiar problem. As a backend engineer, Haseeb found it easy to get lost in the JavaScript ecosystem while trying to build a full-stack application.

His alternative stack was Go, HTMX, templ, Tailwind CSS, and Postgres, with little or no JavaScript. The result was a joyful developer experience built around server-side interactions and a small set of tools with clear responsibilities. The lesson was not that JavaScript is wrong. It was that a backend engineer can build a useful web application without accepting more complexity than the problem needs.

Andy Kyszuk’s MCP is the new REST, making MCP Typeform’s new API looked at the same interface problem from an AI client’s perspective. REST works well for conventional clients, but LLMs need discoverable capabilities and interfaces they can reason about. They do not benefit from being handed a collection of PUTs, POSTs, and strict JSON syntax without more context.

Typeform is building MCP alongside its existing REST API. That does not mean REST disappears. MCP becomes an interface for AI clients while the existing API continues to serve other consumers. The hard part is making the new interface secure, reliable, and maintainable without duplicating business logic.

That is the part worth carrying back to Lunar. Adding a new client type is not only an integration task. In a regulated bank, permissions, reliability, and ownership still matter when the client happens to be an LLM.

Curiosity is still the starting point

Eleanor McHugh closed the day with How much compsci can Go tech? The talk started with her experience of learning BASIC on an 8-bit home computer, where the operating system and language had to fit into 16KB of ROM. There was no formal computer science curriculum, only a text editor, a machine, and the desire to find out how it worked.

Eleanor connected that experience to her son, who disliked programming at school but rewrote JavaScript on school pages, bypassed network restrictions, and got Linux running on a locked-down Chromebook. The question was whether Go could give him a different route into programming.

Go is well suited to that kind of exploration. With a text editor and the standard library, a curious learner can move from small experiments into files, processes, networking, and data structures without first adopting a large framework. The language leaves enough of the machinery visible to make the computer science underneath everyday software tangible.

What I took from day one

Day one was worth attending because it did not treat AI as a separate future topic. It connected AI to the things engineers already care about: understanding systems, choosing how much complexity to accept, operating software reliably, and staying curious.

At Lunar, we build software where trust matters. The tools can change, but that requirement does not. AI can speed up implementation. Local inference can make new applications possible. MCP can give LLMs a better interface to existing systems. None of those remove the need for engineers who understand what they are building and why.

That was the useful tension running through the day: move faster, but do not give away ownership. The next post will cover day two.