The Diagnosis

Hi ,

We're in trouble... or are we? The world seems topsy-turvy; The rise of LLMs questions everything we knew about software development, writing, and even making art. Reactions range from enthusiasm through indifference to panic. I lean towards a fourth option: skeptical curiosity. Collect the facts, take different viewpoints, consider the pros and cons. Then sort all this by writing, because writing trumps pondering every time.

That's why I started the series "Still Writing Go." Its this sorting done in public. The first part is called "The Diagnosis," in which I will look at what LLMs do to us. It is just a look without early conclusions. In software projects, profiling comes before optimizing, right? Same here. So in this week's Spotlight, I start by sorting the concerns that people, including you and me, might have about LLMs.

Talking about diagnoses: A survey is also a kind of diagnosis. And talking about surveys, the Go Developer Survey 2026 is open and waits for your input! But the newsletter also waits to be read, so which will you do first?

I'd do the survey first, because it's quick and then you can lean back and get lost in new articles and projects...

And another one: A diagnosis of how SIMD works in Go. Scroll on and read on.

Happy diagnosing!

–Christoph

Featured articles

SIMD and Go | Internals for Interns

SIMD accelerates number-crunching, and Go's new simd packages bring this speedup to Go.

Help set Go's priorities for next year

This newsletter issue is interactive! Your task: Click the link and fill out the 2026 Go developer survey.

[security] Go 1.27.3 and Go 1.26.10 are released

If your regular govulncheck tests didn't already ring the alarm bells: New Go releases are out, fixing CVE-2026-111943.

Podcast corner

4 Is Not a Secret & Go Dev Advocacy with Ainsley Clark

The latest security patches for Go (see the Featured Articles section) were necessary due to a quite grotesque misconfiguration of eight intermediate CA certificates whose secret keys had only one non-zero byte. Also on the show: The Go developer survey, and an interview with JetBrains' Ainsley Clark, who discusses the importance of staying passionate in the age of AI (because passionate people take better care of the code), how regional communities differ at Go conferences, and why templ and sqlc are his favorite third-party libraries.

"I've come back and I wanted to be a bit more Kenyan then, be a bit happier, be a bit less grumpy." – Ainsley Clark

Spotlight: Your Skepticism Is a Feature

AI has been causing a ruckus in the software development space. Nothing seems as it was just three, four years ago. The clankers are taking our raison d'être[^1] away from us. Since around December 2025, they seem to write code better than the average programmer. And faster, without a doubt.

Companies have tried to ride the wave by sacking developers en gros[^2] and replacing them with LLMs (with various degrees of success). The big question lingers in everyone's head: Will crafting elegant, robust, effective and efficient code by hand—a part of our craft that we are proud of (and reasonably so)—be soon a thing of the past? Or is it already, and we just don't want to realize it?

This is not the only concern that the raise of LLMs trigger. In fact, there are quite a few aspects of LLMs to be upset about. Upon a closer look, they belong to three categories: threats to culture and society, risks that are personal, and hype damage.

Threats to culture and society

Since the release of ChatGPT 3.5, AI has accumulated a lot of negative headlines, especially about observed or anticipated impacts on our cultural and societal achievements. It started with the artist crisis: Midjourney produced tons of generated images every day that many perceived as the democratization of art ("Now everyone can do artwork!") while artists weren't amused at all. Did human-made visual art lose its value?

And, more importantly, did AI even steal art? After all, LLMs are trained on all sorts of artifacts of human work: texts, images, music, code—anything you could imagine. AI companies willfully ignored copyright because no one stopped them. AI proponents claim that LLMs "learn" how to do art, in the same way humans do: by studying and memorizing the work of great artists. But LLMs were caught reproducing existing work almost verbatim, just like a human forger.

The exploitation doesn't just affect the planet's cultural work but also labor. AI companies paid legions of click workers a few measly dollars to .

The third big threat besides killing cultural achievements and exploiting labor is the risk of concentration of power at a handful of companies. Imagine if the frontier models push all other models out of the market. AI services would become an oligarchic system where few tech overlords can do whatever they want to their models (and their customers who won't have much choice anymore). Product enshittification is the mildest of all consequences. (Open weight models to the rescue!)

And on top of this, with the advent of LLMs, the main resource bottleneck is not software but hardware. Up to then, hardware was cheap and fast. If software is slow, engineers optimized the algorithms or switched to fast programming languages. Now the hardware is the limit. LLMs need large amounts of RAM for quick access to their knowledge. Building and running supersized hardware requires resources: energy, water, and all kinds of chemical elements including rare earths. At this point, AI oligarchs seem to have chosen cheap and dirty over sustainable but more expensive. It's a destructive war they fight against each other, and the environment doesn't seem to be on the winning side.

Personal risks

Besides their impact on society, LLMs have a detrimental influence on individuals, regardless of whether they chose to use LLMs or were forced to, and even regardless of whether they are active users at all.

First, there's the risk of deskilling. The convenience and speed of LLMs can trick us into running our brains in energy saver mode, trusting the LLM to do the right thing. Studies found that offloading brain work to LLMs can adversely affect our ability to think clearly. On the positive side, clever use of LLMs can not only avoid that decline but even help to increase our thinking abilities.

Developers face another potential risk: Being held reliable for code they did not write. While LLMs spit out code at an insane rate, yet, they cannot really be held responsible for their outpourings. Humans can. And managers don't care who or what created the code. Welcome to the developer's dilemma: They can take responsibility seriously, review every machine-generated PR, and become the human bottleneck. Or, to make PR reviews match the speed of code output, they can have one LLM review the output of another. Now they're the meat blob whose only job is to formally take ownership of code they neither own nor control. It seems like a catch-22: you can't escape this game in neither direction.

Some developers will choose the second option, often forced by orders from above: Management needs results. And the competitors don't sleep. Is there another choice?

Hype damage

The consequences I looked at so far are bound to building and using LLMs. But there is another, less tangible aspect causing a sense of menace: The hype that built around LLMs since their first sensational successes (remember, even the first clunky attempts of GPT 3.5 at human conversation were perceived as a sensational breakthrough) feeds exaggerated expectations. Headlines go like, "LLMs are ten times more productive as human developers!"; "Company X replaces their entire development team by LLMs!"

A proof doesn't exist, and it can't; for coding is but one small part of software development. But the damage has been done. Engineers have been let go in an attempt to turn into a "dark software factory" where bots do all the software development while a few humans keep them on track and even fewer humans pocket all the profit.

Stay vigilant

Let's be honest: LLMs are a technological revolution. They already affect our work and lives more than other technological shifts in the software industry. Reactions to this ongoing change range from fear ("We'll all be losing our jobs!") to ignorance ("Just wait until the bubble bursts."). I say, pick your reaction carefully. Extreme positions rarely help. What we can do is to separate justified concern from reactionary panic. Nothing is purely black or white; everything has upsides and downsides. So let's take the multiple facets and sort them into what we can fix, mitigate or only navigate (but still!)

In the next articles of this series, I'll look at each facet and try to make them more manageable. A healthy mix of skepticism and curiosity gets us further than giving in to the fanboys and doomsayers.

[^1]: This is just a fancy way to say "reason for being" while showing that you know a few words of French without saying that you know a few words of French.

[^2]: There it is again. "In large amounts."

More articles, videos, talks

Kubernetes Events and Controller design

Kubernetes controller developers can make use of an event mechanism, but how do events work exactly, and what are good use cases? A guide by Jubril Oyetunji.

ConcurrentML: Improving on Go's concurrency model

Concurrent ML versus Go's CSP-based concurrency model. To understand the Racket code examples (and the points the author Nikhil Marathe makes), basic knowledge of Lisp-like languages and some love for the functional programming mindset is s plus.

Acquiring TLS certificates at runtime | dushed blog

Go's HTTP handler reads TLS certificates from the file system on start. The Dushed team didn't want to restart their web app after a certificate renewal, and (for some reason not discussed in the article), they also don't make use of a proxy that can serve as TLS endpoint. They found the solution right inside net/http: an optional field that defines a function the server can call to get up-to-date certificates.

HMAC-SHA-256 from Scratch in Go | moroz.dev

Episode XYZ in the series "I Have Never Understood How This Works, So I Built it in Go." Highly recommended to try for yourself: If you don't seem to fully grok a piece of technology, try a minimal working implementation in Go and write up (or better, share) the learnings. Here, the author implemented HMAC-SHA-256, a message authentication algorithm widely used (e.g., in TLS).

Projects

Libraries

imclaren/vero: Go backend, native frontends

Many Go frontend kits run on top of a browser engine. Few use the operating system's native UI. One of them is vero. The concept is simple: Your Go backend is the same on all platforms, your frontend is Swift on macOS, GTK on Linux and BSD, and WPF on Windows. This way, your apps get a native desktop look-and-feel while you can continue to write cross-platform Go.

Tools and applications

cristianadrielbraun/gofer: Self-hosted multi-account email client with support for JMAP/IMAP/SMTP, direct integration with Gmail and Outlook APIs. Also Contacts and Calendar. Built with Go, templ, and HTMX, SQLite for storage

I guess I'll try this as a replacement for Thunderbird on my 2015 Macbook Air.

titpetric/task-ui: Task UI - a web based runner for Taskfile.yml

Tit Petric dusted off his Task UI project, with some help of Claude.

Anga205/CodeExecutionAPI: An API to execute code snippets in multiple languages and return the output and execution metrics

Minimalist containerization for code execution, aiming at fast startup times. Go is not yet supported as a guest language, though, due to sandbox restrictions that go in the way.

neria-cloud/gosim: Tooling for deterministic simulation testing of distributed systems

The original project stalled two years ago. Now it got an overhaul, with Claude's help.

kunalgoesbyken/gostman: Free, open source API client for REST, GraphQL, gRPC and WebSocket. Desktop, web and CLI. No account.

A fully open-source API client along the lines of Postman or Bruno, but requiring no signup nor payments. It comes with a web mode for interactive use and a CLI for CI runs (or also interactive use, if you want to). All requests, collections, and environments are locally stored YAML files, so you would lose the comfort of "configure once, use everywhere", but Git may come to the rescue.

Completely unrelated to Go

What requirements don't you have?

"Why doesn't X have feature Y?" Deliberately not implementing a certain requirement that seems indispensable may seem gross at first, but sometimes this decision leads to more freedom or better performance, resource use, etc. in other aspects or the software.

Interesting systemd features you may not know about - Martin Alderson

So you plan to build a five-cluster Kubernetes infra for your vibe-coded Wordle clone? Save 99% of the work and use systemd instead. (For a nice, quick intro to using systemd with Go apps, see How I made Inkmi in Go Self Healing (The original site is gone, unfortunately.)