GopherCon UK 2026: Day Two
By Ruben Eik Mortensen, Engineering
In the first post, I wrote about why Lunar went to GopherCon UK and the talks that stood out on day one. Day two had a different rhythm: how to observe Go without changing the code, how an API affects performance, and what Go’s type system gets right about numbers. Later, the focus shifted to AI systems being used across a company and inside a live trading operation.
I kept coming back to a practical theme: the choices we make about where complexity lives. Sometimes it is in the instrumentation around a service, sometimes in the shape of an API, and sometimes in the platform or process that gets a model into production.
Instrument Go Without Changing a Single Line
Kemal Akkoyun, a staff software engineer at Datadog, started Instrument Go Without Changing a Single Line with a challenge to a familiar assumption: observability has to mean adding code to every service.
He covered several ways to instrument Go without editing application source: eBPF-based agents, compile-time rewriting, shared-library injection, and USDT probes. Each works at a different layer, and each comes with its own trade-offs. The point is not just whether an approach can avoid source changes, but how it behaves in a real service: what overhead it adds, how stable it is, and how ready it is to use with OpenTelemetry and the wider ecosystem.
Removing changes from the application does not remove the work; it moves it elsewhere. For teams responsible for many Go services, that can be a worthwhile trade. But “zero-touch” still needs to be measured against the services you run and the signals you actually need.
API Design as a Performance Primitive
David Cheney, staff systems engineer at GitHub, made the case in API Design as a Performance Primitive that performance problems are often baked into an interface long before anyone starts tuning an algorithm.
His case study was a high-speed, streaming JSON parser. Convenience-first APIs, including the familiar shape of Go’s encoding/json, can make allocations part of the cost of using them. Once the contract pushes that cost onto every call, small optimisations inside the implementation can only do so much. Cheney described a different model: a sliding window where the provider owns the data, rather than asking each caller to supply and manage it.
What I took from this was that an API is not just a way to expose a library. It decides who controls data and what the caller has to pay for. If performance matters, those decisions belong in the design from the start, not as a round of micro-optimisations afterwards.
Numbers
In Numbers, Cheney moved from performance to a more fundamental question about Go itself. The talk traced Rob Pike’s 2009 quip that, in Go, numbers are just numbers, and explained the role untyped constants play in making that true.
Go lets a numeric constant remain untyped until it is used in a context that gives it a type. That avoids choosing a type too early and saves programmers from unnecessary conversions in ordinary expressions. It does not make Go less strongly typed; it delays the decision until there is a reason to make it.
It is a small feature, but a good example of the language quietly preventing a category of mistakes rather than asking every programmer to work around them.
Building a polyglot multi-agent AI architecture on AWS AgentCore
On day one, Andy Kuszyk’s “MCP is the new REST: making MCP Typeform’s new API” showed how Typeform was adding an AI-facing interface alongside its REST API. Andy described this day-two talk as a continuation: moving from that interface to the platform needed to support AI agents across Typeform’s products. The company’s conversational form-building experience, launched in 2025, now powers around two million AI interactions a month. That success brought a new expectation: customers wanted similar experiences across more of Typeform’s products.
Andy described moving the core agent architecture from self-managed Kubernetes on AWS to Amazon Bedrock AgentCore, a managed runtime for AI agents. The goal for 2026 is to let every product team build its own specialised agents, in the programming languages that make sense for that team. The talk covered the organisational model as well as the architecture: growing from one assistant and one team to an agent platform used across the company.
That shift is about more than running additional agents. If AI features are going to spread across a product organisation, teams need a platform they can use without all having to start from scratch. I liked that the session treated the team structure as part of the technical problem, rather than something to figure out later.
Go, ONNX & AI in Production: Trading Platform
Andrew Wormald, senior staff engineer and competency lead at Luno, brought AI into a very different setting with Go, ONNX & AI in Production: Trading Platform. He started Bramfield Trading Company to explore what becomes possible when AI helps build a trading company and takes part in its decisions. The company trades only his own capital, and one rule is firm: no manual trading.
Andrew described a path from training models in Python, to using ONNX for portability, to running live inference in Go. Around 90% of the production platform is written in Go. Classical machine-learning and CNN-based models run in a 24/7 trading stack, while LLMs are part of the live decision loop for deciding whether to trade and how much to order.
What I found useful was the end-to-end picture. Research, model portability, inference, and the live decision process all have to fit together in a system where the decisions have real financial consequences. It is a reminder that getting a model into production is as much about those handoffs as the model itself.
What stayed with me
I left day two thinking about ownership: the data moving through an API, the instrumentation outside an app, the agent platform product teams depend on, and the decisions that affect real capital. The subjects were far apart, but each talk asked who is responsible once a system is running for real.
In the final post, I’ll write about the talks that stayed with me most across both days, along with the meetup I went to on day two.
