The Shift That Didn't Come (Yet)

Hi ,

The Go developer survey 2025 results are out, and one thing that caught my attention is how the Go community (or rather, the 5000+ Gophers that took part in the survey) thinks about using AI as part of their development workflows. 17% don't use AI-powered tools for meaningful work on Go projects. Of those who use AI-powered tools, only 55% are satisfied with the results; non-functioning and poor-quality code were the problems most frequently complained about. Of 13 different tasks that AI can assist with, eight are used by less than half of the survey participants.

The massive shift from hand-crafted code to AI-generated code that has been predicted by some did not set in—at least not yet. But the gradual increase in AI-powered tooling is undeniable.

What sticks out to me (and to the Go team) is that using AI for writing tests isn't as popular as one could expect, even though writing tests is commonly perceived as a tedious routine task.

Surprisingly, “testing code” showed lower AI adoption than other toilsome tasks, though we don’t yet have strong understanding of why.

If I may take a guess: Gophers who use Test-Driven Design don't let AI write tests. The reason is simple: Writing initial tests for a TDD project is part of the thought process. Tests in TDD are like scaffolding: They have to be set up first, before the actual code can be built. But if tests are a result and, to some degree, a documentation of the thought process, there is no point in having an AI generate them.

Sure, I might be utterly wrong; there are dozens of other factors that influence the decision to use or avoid AI. And I daresay that the 2026 survey results will show an entirely different picture.

–Christoph

Featured articles

Results from the 2025 Go Developer Survey - The Go Programming Language

Did you know that Gophers love Python and Rust? That the largest group of Gophers has more than 15 years coding experience? That almost all Gophers are developers by profession? That the two kinds of apps that Gophers build most are CLI apps and API/RPC services? That the most frustrating thing about Go is to ensure that a team's Go code follows best practices and Go idioms? That many Gophers don't want AI to be involved in deploying software to production? Well, I didn't, until I've read the results of the latest Go developer survey.

Your Go tests probably don't need a mocking library | Redowan's Reflections

Code with external dependencies (such as a database or a REST API) is often tested by generating a mock-up for the dependency. While mock libraries provide a convenient way of generating mock-ups, they may have unwanted effects in the long run. Luckily, there are simple ways in creating mock-ups without a mocking library. This article shows how.

Writing your first compiler

Warning: Your first compiler probably isn't your last one.

Podcast corner

Cup o' Go | Go pherJS. 🌐 Go survey. 📈 Go podcast. 🎧

A podcast within a podcast? Almost: This episode's guest is Dominic St-Pierre who runs go podcast(), the other one of the two Go-related podcasts since Go Time is gone and Fallthrough moved to other topics.

More articles, videos, talks

How We Built Golang-Native Durable Execution | DBOS

context.Context was designed for a very specific goal: to transport request context across package borders. The DBOS team has repurposed context.Context as the basis of the main API for their durable workflow library.

A genius move or heresy?

Backpressure Patterns in Go: From Channels to Queues to Load Shedding

From the causes of backpressure in concurrent systems to useful patterns for avoiding or dealing with backpressure.

Projects

Libraries

GitHub - alnah/go-md2pdf: Professional PDF generation from Markdown. No LaTeX. No complexity.

Interesting background: The author is a French teacher who needed to solve a problem for himself: finding a Markdown-to-PDF batch converter (that doesn't have to use LaTeX behind the scenes). So he wrote a specification and let Claude chomp through it. The result is a lib with a wrapper CLI tool and tests and all.

Tools and applications

elC0mpa/aws-doctor: Diagnose AWS costs, detect idle resources, and optimize cloud spending directly from your terminal. 🩺 ☁️

Stay informed about what's going on in your AWS accounts. Created for making daily AWS (Dev)Ops routines faster and easier.

GitHub - Zxilly/go-size-analyzer: A tool for analyzing the size of compiled Go binaries, offering cross-platform support, detailed breakdowns, and multiple output formats.

Binary too large? Run go-size-analyzer and see what consumes most of the space on a 2d treemap.

JPM

From a Go perspective, Java build systems may look overly complicated. So what does a Gopher do who also does Java development? Correct: Writing a Java build system in Go.

GitHub - isaacharrisholt/pgfga: A basic implementation of OpenFGA/Google Zanzibar in pure Postgres. Used in production at getrover.com.

Authorization services typically impose a hefty overload on small projects. What if you could have your entire authorization inside your PostgreSQL database?

No problem: Just write an OpenFGA authorization schema and run Melange to generate PostgreSQL functions for your model.

GitHub - cloudness-io/cloudness: An open-source, self-hostable application platform for building and operating applications on Kubernetes

So you have a Kubernetes cluster around and don't know what to do with it? Deploy an app! Cloudness makes this quite easy, according to the author who open-sourced this project just recently.

GitHub - openfluke/loom: Layered Omni-architecture Openfluke Machine

Loom brings Go and GPU computing together, with an interesting goal: To run neural networks in a deterministic execution environment that "guarantees bitwise-identical results across all platforms, backends, and language bindings."

Isn't that a contradiction to the seemingly non-deterministic behavior of neural networks, especially LLMs? No, LLMs basically consist of matrix calculations, and they vary their output only if mixing some randomness into the process. That's why LLMs typically have a "temperature" control. Zero temperature means a given input always generates the same output. Loom wants to make this determinism even independent of outer factors like OS, backend, or client framework.

GitHub - ARJ2211/ShutterTrace: PRNU extraction + validation

Every camera sensor produces some background noise. This noise can be used as a unique fingerprint ti identify that sensor, mostly for forensic purposes. This tool is a proof of concept for this kind of camera fingerprinting.

Author: "It was a pain to implement though but super rewarding."

GitHub - go-extras/nolintguard: nolintguard is a static analysis tool designed to enforce organizational policy around the usage of "nolint" directives in Go source code

//nolint directives should be used consciously and with care. Blank //nolint directives appear to be way too popular, however; at least from the author's perception, who wrote a tool to guard agains such indiscriminate disabling of all linters. See his Reddit post for more background information.

Completely unrelated to Go

Interfaces and traits in C

Not entirely unrelated: Anton Zhiyanov starts by looking at Go interfaces, then takes a turn towards Rust's traits before finally implementing interfaces/traits in good old C. (Old, yes. Did I say good?)

research!rsc: Pulling a New Proof from Knuth’s Fixed-Point Printer (Floating Point Formatting, Part 2)

Part 2 of Russ Cox's series on floating-point formatting that started in... 2011!

research!rsc: Floating-Point Printing and Parsing Can Be Simple And Fast (Floating Point Formatting, Part 3)

Part 3 of the Floating-Point Formatting series. The pace has accelerated, apparently.