About Perspectives

Hi ,

A mask, a helmet, high speed, and medical conditions can cause tunnel view. Focusing too closely on a small part of the whole is also a kind of tunnel vision, in a metaphorical sense. AI's claim of 10x productivity increase is based on a too-close focus. This episode's spotlight shows why.

A change in perspective is genuinely useful to learn more about things we think we already know, whether it's looking at the internals of go:embed, examining how maps grow, or evaluating the details of (old and new) JSON unmarshalling—all in the featured articles.

Have a code-ful week!

–Christoph

Featured articles

How //go:embed Works: From Source Files to Binary | Internals for Interns

Have you used //go:embed yet? I bet you have; if not, try it out. Embedding files and folders right into the binary is a superpower. The steps are easy, but how does the embedding work internally? Jesús Espino takes you on a tour from the first keystrokes to the final shape at runtime.

Accepted proposal: grow an existing map with maps.Grow

Map too small? Automatic resizing takes care of this... but if performance is a critical factor, pre-allocating sufficient space at once would be nice! Go 1.28 will make this possible; Redowan Delowar examines how it works.

A new Go API for JSON

Go 1.27 stabilizes encoding/json/v2 and encoding/json/jsontext, and the existing encoding/json is now implemented on top of v2.

WIIFM? (What Is In For Me?) The latest Go blog article has the answers.

Podcast corner

🌉 Ready, Sets, Go! Live from SF, hosted by Assembled!

Sets in Go? map[<type>]bool. Yes, that's a crutch, and with generics, we can do better: A proposal suggesting a generic set package has been accepted. Also in the episode: A proposed support for workspace-specified custom analyzers for go test, native Go support in Next.js, JSON v2, Go maps internals, and more.

Spotlight: The Tenfold Tunnel Vision

The universe ends in about 10^10^120 years from now. It doesn't really end, according tho the Big Chill theory; rather, it will reach an equilibrium state at that time, where nothing happens anymore (to put it in simple words).

What made me think of that? Oh, right: It was the popular claim that AI assistance in software development leads to a tenfold productivity increase. Does it? I have my doubts.

Projects are more than coding

The first question that pops up is, why tenfold? When I look at my own vibe-coded side projects, I experience an almost infinite increase of productivity with each of them. If you don't believe me, here's the math:

• Each project took a few minutes of prompting and a few minutes of bot work to reach the first prototype stage. From there, accumulated work is counted in hours, in the low single-digit range. (I'd estimate 2 hours on average.)
• Without bots, I wouldn't have written any of these projects until the end of the universe.

So: 10^10^120 years / 2 hours on average = almost infinitely faster. Quod erat demonstrandum.

My side projects aren't representative, of course: An idea pops up in my head, I think about the implementation, turn this into a prompt, and let the bot ruminate. In a sufficiently large project, coding is but a small part of overall project work. Time goes into planning, talking to stakeholders, deciding and agreeing on the architecture, setting up environments, writing code, testing code, integrating code, writing technical documentation, writing user documentation, and so on.

What do LLMs accelerate? Coding. That's what they're strong at. They can't take over all the planning and the conversations, because these aren't algorithmic tasks. They are good at technical testing but not at testing whether the code meets the intents. They can't evaluate user experience because they have no taste. All of this still requires manual work.

The "tenfold productivity increase" claim is a tunnel vision. It looks legitimate if you only look at the coding phase, but it falls apart when taking on a bird's view.

The bottleneck just moves

Okay, writing code is just one of many tasks in a project, but obviously, it's THE bottleneck, right? Manual coding is slow, and it's error-prone. This may be true when looking at the pure development phase (except for high-functioning developers). But once the coding bottleneck is removed, the next-slowest activity in the development cycle becomes the new bottleneck. Usually, it's the review and test activities. Coding bots produce PRs within minutes and then wait for human reviews and approvals.

For documentation, it's the same. A draft is ready within minutes, but the review needs hours—particularly for technical documentation, where a small shift in wording can distort or completely change the intended meaning.

I'm well aware that autonomous end-to-end software development and maintenance is already seen in the wild. The software built this way is not particularly high-risk software, though: Mostly games or productivity software (see the ArtCraft Suite as an example). I have yet to come across high-stakes software that is involved in critical business operations or even controlling critical infrastructure (but please send me examples if you come across any).

My point is, as long as humans are still involved, and be it only for intervening, the x-fold productivity increase remains made up.

We can't have it all

Autonomous code writing, autonomous testing, stable software over an extended period: pick two.

Even with the wild progress in agentic coding made in 2026, humans are still a critical success factor. We can choose to pass coding or review to the bots, but not both.

Yet, at least we have the Gopher advantage. Go is incredibly well-suited for AI-assisted work. Just listing a few Go advantages:

• Quick turnaround times: A compile phase takes seconds to minutes, not minutes to hours. The code-test-deploy flow is fast.
• Locality: Code does what it says. A + sign is a + sign; it can't change its meaning from an operator overload that happened five inheritance levels above and seven source code files apart. Both human brains and bots appreciate this.
• Built-in testing: An established, language-native unit test harness is much easier for an AI to learn than a multitude of third-party testing frameworks that other languages need.
• A rich public body of open source code since 2011: AI needs plenty of code to learn from. Go has been designed as a team-focused language from the very beginning; this pays off today in clear, idiomatic code seen in many open source projects. (I'll discuss the legal and ethical implications of this in another article; it's not a Go-specific issue but affects all open source projects alike.)

...and probably more. But you get the point: Bots have an easy time with Go. Whenever I ask Opus 5.5 to write something, it produces stable, bug-free code most of the time; the usual "bugs" are of the kind "you did not understand what I want." I can review every PR and point the bot at wrong or silly code (and I do need to do so more regularly).

I could also go the opposite way and have the bot write or extend tests for me while I write code against these tests, then have the LLM review my PR.

Studies indicate that this kind of human-AI cooperation can actually improve output in terms of speed and/or quality. Two interaction models seem to stick out: the centaur and the cyborg. One draws clear borders between human and AI tasks, the other describes a fine-grained intertwining of human and AI work.

So while tenfold productivity is clearly an AI myth, thoughtful delegation of selected tasks to LLMs can improve throughput, or quality, or maybe both. Critical supervision by humans isn't optional at this point, and I doubt it will become optional in the foreseeable future.

Em-dashes proudly hand-crafted.

More articles, videos, talks

I contributed to Golang, here is how you can too - YouTube

If you plan to contribute to the Go project, Alex Pliutau shares some tips.

Building Barista—Part 1: Postgres, Embeddings, and Jev

This looks familiar to me! Teiva Harsanyi, author of 100 Go Mistakes, built a tool that watches over a number of sources (HN, Lobsters, blogs,...), classifies, and ranks them. Then it sends an email with the top-ranking ones. This article describes the tools's architecture.

Porting ECS to Go | Tomas Votruba

How AI agents helped porting PHP code to Go, bringing execution time of a task down from 2 minutes to 4 seconds.

GoLand’s Profiler Now Works With AI Agents

GoLand 2026.3 adds a profiler skill and MCP tools for enabling agents to profile a Go app.

The MustCreate Pattern for Go Tests

How a new (generic) function helps Michael Lnych to write more readable and less repetitive tests.

A Quick Guide to Go's Assembler

When would you need assembly code? Well, if your code shall be as fast as fu... possbile, or if you need to work close to the hardware where high-level languages don't deliver. The Quick Guide to Go's Assembler introduces the reader to the unusual, Go-specific assembler format.

Threadline · Concurrency Visualized: Java, Python, JavaScript, Go, Rust

Concurrency remains hard, even with a clear concept like Go's. Visualizations help to understand particular concurrent patterns. The Threadline website not only offers quite a few patterns for Go but also for other languages.

Go 1.27: encoding/json/v2, Stricter Defaults, and Finally [] for Nil Slices · cekrem.github.io

Christian Ekrem examines the aspects that make json/v2 better than the v1 version.

Projects

Libraries

chanx-dev/chanx-go: Typed WebSockets for Go: net/http, gin, echo and Fiber servers, typed client generator, and a shared Redis layer with Python and TypeScript. Speaks the chanx protocol.

WebSockets are typically used for binary streams or other use cases that need no real protocol. But when WebSockets carry a "real" API, the chanx protocol helps to hold implementation effort at bay.

Tools and applications

changkun/occamy: 🖥️ a modern remote desktop proxy written in Go

Put desktops and terminal in your web browser, via VNC, RDP, SSH, or Kubernetes (to access a shell in a pod).

fantuz/entropy-service: Randomness, on your terms. A self-hosted Go toolkit to generate, stream and inspect random data from hardware or software RNGs, through HTTP and WebSocket APIs.

A random number service that turned into "a sort of networking, cryptography, and systems-programming laboratory."

dspv/caprock: Agentic development environment: run Claude Code, Codex, OpenCode and Gemini CLI side by side, and follow every PR from agent to release with its cost. Desktop app for macOS, Windows and Linux, plus a Claude Code plugin. Local, free.

Do you know what your agents are doing? ALL of them?! If not, then you either have too many agents or just not the right tool. Caprock tracks your agents—where they are, what they do and how they burn through your hard-earned money.

Updates

qax-os/excelize: Go language library for reading and writing Microsoft Excel™ (XLAM / XLSM / XLSX / XLTM / XLTX) spreadsheets

Excelize v2.11.1 has a few upgrades and a bunch of bug fixes.

GoLand 2026.3 Is Now Available! - The JetBrains Blog

GoLand 2026.3 brings some fresh Air into your workflows. Agentic air.

Completely unrelated to Go

How do we auto-approve and merge 60% of PRs?

Agentic workflows tend to produce more PRs that humans can review. Swizec Teller proposes moving reviews to earlier and later stages: Architectural reviews up-front, and behavioral and UX review after the implementation. Code-level reviews can be automated for low-risk changes. This, plus better risk classification and other measures can significantly lift the percentage of PRS that can be auto-merged.

I wish tech companies knew more about me | exotext

Big tech companies know more about you that you might like. They use this information to serve you ads. They could use the very same information to improve the user experience, says Rakhim Davletkali.