the website is just using go standard library and templ.
the voice is grok tts. the images are generate by nano banana from prompts written by claude, according to styles. it is all generated by a program called lg: https://yagnipedia.com/wiki/lg
the blog pages are markdown on disk, generated dynamically for each request, cached by cloudflare.
The colored functions point is fair, I was imprecise. My real argument is about the human cost of the compiler fighting AI-generated code, not about async semantics.
Fair comment. In my production code I always separate out the css and embed it in the go binary as files that can be cached. Having it in embedded into the page was really useful to iterate behind cloudflare and not worry about css caching but is a terrible practice.
Last night I built a website from scratch. Not a landing page. A full blog with three-domain routing, animated video covers, an audio player with playlists, dark mode, RSS feeds, social cards, and a sticky sidebar with a lightbox. Seven commits. Zero test failures. One binary.
The site you've read the article on. Built in one session. In Go.
I work with an AI that writes most of the code. The question everyone asks is which language to vibe in. Python is fast to start. Rust is correct by construction. Go is boring.
Software Engineering is the discipline that, in 1968, looked at the smoldering wreckage of every software project ever attempted and concluded that what it really needed was not better practices, better tools, or better understanding, but a better name. Specifically, someone else’s name. Specifically, the name of people who build bridges.
It has spent the subsequent fifty-eight years proving the metaphor wrong in every measurable way, while simultaneously insisting on keeping it....
I've been building AI applications in Go since August 2024 — before "vibe coding" had a name. After 18 months of AI-assisted development on a Fortune 100 project, the argument for Go isn't performance or deployment anymore. It's the compiler.
When the machine writes 90% of the code, Go gives you five layers between the AI and production: compiler, type system, explicit errors, enforced simplicity, and the human. JavaScript gives you one: the human. And good luck.
The machine proposed a wrapper type last Tuesday. `go build` rejected it on line 47. I said five words: "why do we keep both around?" The wrapper died. In JavaScript, it would have compiled (nothing compiles in JavaScript), passed all tests, shipped to production, and coexisted with the original type for six months until someone proposed a `UnifiedStoreInterface` to bridge the gap.
TypeScript helps — but it's a type system that asks permission. `// @ts-ignore` exists. `strict: false` exists. `any` exists. Go has one mode. There is no `go build --please-actually-check-the-types`.
The machine can generate complexity faster than it can recognise it's unnecessary. Go is the language where the human can still recognise it.
Author here. Yagnipedia is a personal encyclopedia I've been writing — humorous entries on tech concepts, tools, and practices, written in the voice of someone who's spent 20 years building software and has opinions about most of it.
The Boring Technology entry started as a love letter to Dan McKinley's original talk, filtered through the experience of choosing Go, HTMX, and server-rendered HTML for a product in 2026 while everyone around me reaches for React and microservices. The boring choice is almost never the exciting one. It's almost always the right one.