Yesterday Google published "Why Go is an Ideal Language for AI-Assisted Software Engineering" — arguing that AI shifted the bottleneck from writing code to reviewing it, and Go's integrated platform provides the guardrails AI teammates need.
We read it and thought: yes, we know.
Since fall 2025 we've been building Pure Go infrastructure that Go was missing — starting with HDF5 and Born ML (GPU-accelerated machine learning), then launching GoGPU in December 2025. Today it's 1.25 million lines of code. 15 repositories. Shader compiler, WebGPU implementation, 2D/3D graphics, GUI toolkit, audio engine, multi-process compositor. Zero CGO. All built using Smart Coding — our methodology where humans own architecture, specification, and review (70%), while AI handles mechanical implementation (30%), with cumulative knowledge transfer between sessions.
Here's what Google got right, what we learned the hard way, and what the article doesn't mention.
What Google Got Right
"The bottleneck shifted from writing to reviewing"
This is the central thesis, and it's correct. When AI generates hundreds of lines per session, the limiting factor becomes: can you verify this is correct?
In our workflow, every PR gets claim-by-claim validation. When a contributor submits "fix: correct PDF y-axis transform," we don't just read the diff — we verify the math:
Transform.Then applies the receiver first.
Translate(0,h).Then(Scale(1,-1)) → y' = -(y+h) ← WRONG
Scale(1,-1).Then(Translate(0,h)) → y' = h-y ← CORRECT
We write the proof in a temp file, run it, confirm the output, then approve. AI generates the fix. Humans verify the math. Google's thesis in action.
"Go's integrated platform enables AI self-correction loops"
Google argues that gofmt, go test, go vet, and the compiler form a feedback loop where AI can iteratively fix its own output. True — and we run this loop on every change:
gofmt -w . # format
go build ./... # compile (catches type errors, hallucinated APIs)
go vet ./... # static analysis
golangci-lint run --timeout=5m # 30+ linters
go test ./... # behavioral verification
Across 1.25M LOC, this catches most AI mistakes before a human ever looks at the code. The compiler is the first reviewer.
"Static types = safety net for agentic code"
Google: "If an AI agent attempts to use a non-existent method, pass an incorrect type, or leave a variable uninitialized, the code simply will not compile."
We cross-compile for three platforms on every PR:
GOOS=windows go build ./...
GOOS=linux go build ./...
GOOS=darwin go build ./...
This catches platform-specific hallucinations that single-platform builds miss — an AI might generate a Windows syscall in a Linux file, or reference a macOS framework in cross-platform code.
"Single static binary, zero system dependencies"
Our ecosystem proves this at scale. go build produces a binary that includes a WebGPU implementation (Vulkan/DX12/Metal/GLES/Software backends), a shader compiler (WGSL → SPIR-V/MSL/GLSL/HLSL/DXIL), a 2D graphics engine, and a GUI toolkit. No DLLs, no shared libraries, no runtime dependencies. No C compiler required.
This is what "batteries-included" means when taken seriously.
What Google Didn't Do — and We Did
Google created Go in 2009. They wrote the article about Go being ideal for AI in 2026. In between — 17 years — Go lacked three things every serious platform needs: professional graphics, GPU access, and an ML ecosystem.
No GPU graphics. No GPU-accelerated 2D library. No shader compiler. No WebGPU implementation. No GUI toolkit with native rendering. Java had Swing, then JavaFX. .NET had WPF, then MAUI. Rust got wgpu, then Bevy. Go got Fyne (CGO + OpenGL) and Ebiten (game engine, not a platform).
No GPU compute. Python has PyTorch, CUDA, TensorFlow. Rust has wgpu-rs for compute shaders and Burn for ML. Go had... os/exec to shell out to Python. A language "ideal for AI-assisted engineering" that couldn't run a GPU kernel without calling C. The irony: Google co-created the WebGPU standard (W3C) and built Dawn — the reference WebGPU implementation for Chrome. But they never gave Go access to their own standard. We built the third native WebGPU implementation in the world — and the only one in Go.
No ML ecosystem. Google writes the article about Go and AI, then builds TensorFlow in Python/C++, JAX in Python, and Gemini in... not Go. The language they praise as ideal for AI couldn't train a model.
Google builds Flutter (Dart), Android UI (Kotlin), Chrome (C++), TensorFlow (Python/C++). They never invested in making Go a first-class platform for graphics, GPU compute, or machine learning.
We're fixing all three:
- Graphics: Shader compiler ahead of Rust naga on some features (DXIL generator — Rust hasn't shipped theirs). WebGPU implementation — the third in the world after Chrome's Dawn and Firefox's wgpu, and the only one in Go. GUI toolkit listed in awesome-go.
- GPU compute: Born ML — a production ML framework fully migrated to our Pure Go GPU stack. Trains models on GPU. No Python, no CUDA, no CGO.
-
The full stack: 1.25M lines of Pure Go. From shader compilation to neural network training to GUI rendering — one language, one toolchain,
go build.
Google's article validates why Go is the right language. GoGPU and Born ML prove what's possible when someone actually builds the missing pieces.
What We Learned That Google Didn't Mention
AI-generated code needs claim-by-claim validation, not just compilation
Google focuses on the compiler as the safety net. The compiler catches syntax and type errors. It does not catch:
- Wrong algorithm — code compiles but produces incorrect output
- Wrong architecture — code works but cements the wrong design
- Wrong numbers — "renderer.go: ~720 → ~400 LOC" when the actual delta is 2,174 → 1,892
In our dev.to articles, we validate every factual claim against code before publishing. "Flutter's flow/ has ~15K LOC" — we count: actual is ~22K total lines. "ssa.Func has 30+ fields" — we count: actual is 41. "UI has 24 widgets" — we check README: actual is 27.
The compiler can't do this. Humans must.
Enterprise references prevent AI from reinventing wheels badly
Google mentions "cleaner training data" from Go's standardized ecosystem. But they don't address a deeper problem: AI confidently generates plausible-looking architecture that violates well-established patterns.
When we needed a GPU compositor, AI would happily generate a god-struct with 200 fields and bidirectional dependencies. Instead, we researched how Flutter (flow/), Chromium (cc/), and GTK4 (GSK) handle compositors. The answer was consistent: unidirectional deps, concrete structs, minimal callback interfaces. Research before code.
We formalized this as a rule: every GPU/HAL/sync/barrier change starts with enterprise reference research. AI proposes, references validate.
But references aren't always available. When you're building the third WebGPU implementation in the world, or the first Pure Go DXIL generator, there's no "how Flutter does it" to consult. You're the pioneer. AI can't help here either — it will confidently generate plausible architecture that has never been tested at scale. This is where human judgment, deep domain knowledge, and the willingness to read GPU specs directly become irreplaceable. Google's article assumes references exist. In practice, sometimes you are the reference.
Multi-agent architecture, not one AI editing everything
Google's article implies a single AI agent working on a single codebase. At our scale (15 repos), the architecture is fundamentally different.
Each repository has its own specialized agent with domain-specific sub-agents — a shader compiler agent that knows SPIR-V opcodes, a HAL backend agent that understands Vulkan barrier semantics, a GUI toolkit agent that knows widget lifecycle patterns. These agents are tuned for the specific library they serve, with their own project-level instructions, enterprise references, and research protocols.
The ecosystem-level agent only coordinates — it tracks cascade releases, manages cross-repo issues, and communicates via GitHub. It does NOT implement features in other repos. When it makes a claim ("this API should change in wgpu"), the repo-level agent independently validates that claim through its own deep research. They agree, or they push back with evidence. Very often, the first architectural instinct turns out to be fundamentally wrong — the repo agent catches it because it knows the domain deeply.
Cross-repo code changes by the coordination agent are rare exceptions, limited to thin interface seams (a new method on gpucontext.DeviceProvider, a version bump in go.mod). The real work happens inside each repo's agent session.
This isn't a preference — it's a technical necessity. No single AI agent can load 1.25M lines of code into its context window. Each repo is 96K-324K lines — already pushing context limits for a single session. The only way to work at ecosystem scale is specialized agents that deeply understand their domain, coordinated by a lightweight orchestrator that trusts but verifies.
go.work plays a different but critical role: when all repos are in a shared workspace, any agent in any repo always builds and tests against the current local state of every ecosystem dependency — not the last published version. An agent working on gg sees unpublished wgpu changes. An agent fixing a naga shader bug can immediately verify the fix compiles against the latest wgpu consumer code. No publish-wait-update cycles. When it's time for a PR or release, the code goes through multi-stage validation: each repo's agent runs its own pre-flight checks (build, test, lint across platforms, feature completeness audit, dependency freshness, documentation scan). The ecosystem agent validates cross-repo consistency. Agents check each other's claims — stubs, incomplete implementations, architectural shortcuts are caught before they reach production. And at the end, the human reviews and approves before anything is published. No release ships without explicit human sign-off.
The entire process is backed by persistent knowledge artifacts. Every deep investigation produces a research document with enterprise references and source-verified findings. Before implementation, an Architecture Decision Record (ADR) is written — documenting the decision, alternatives rejected, and enterprise patterns adopted. Kanban tasks break the work into trackable units with clear acceptance criteria.
When it's time to implement, specialized agents receive the full context — the research doc, the ADR, the task description, the relevant enterprise references. They write the code. Then the main repo agent reviews everything they produced — validates claims against code, checks for stubs, verifies test coverage, confirms the implementation matches the ADR. Only after confirming the code meets acceptance criteria does the agent approve the commit and public documentation update. If it doesn't meet the bar, the implementation iterates until it does. This is not a one-shot process — it's a quality ratchet that only moves forward.
But it's the multi-agent architecture, not go.work, that makes 15-repo AI-assisted development possible at all.
CI lint versions drift — and AI can't predict it
A practical problem Google's article doesn't address: golangci-lint latest in CI means the rules change under you. We've had PRs that pass locally (v2.12.2 on Windows, Go 1.25.5) but fail in CI (same v2.12.2, but Go 1.25.12 on Linux) because staticcheck behavior differs between Go toolchain versions.
AI generates code that passes your lint. CI runs different lint. The fix is pinning versions — but latest is the default in most GitHub Actions, including golangci-lint's own action.
The Numbers
| What | Scale |
|---|---|
| Total Pure Go code | 1.25M LOC |
| Repositories | 15 |
| GitHub stars | 1,200+ |
| Development period | ~1 year (HDF5 + Born ML fall 2025, GoGPU from Dec 2025) |
| CGO required | Zero |
| External C/Rust dependencies | Zero |
| GPU backends | 5 (Vulkan, DX12, Metal, GLES, Software) |
| Shader targets | 5 (SPIR-V, MSL, GLSL, HLSL, DXIL) |
| Platforms | Windows, macOS, Linux, Browser |
| Contributors | 8+ |
All built using Smart Coding — human architecture + AI implementation + cumulative knowledge — with exactly the Go guardrails Google describes.
The Ecosystem
| Project | LOC | What it does |
|---|---|---|
| naga | 324K | Shader compiler |
| gg | 312K | 2D graphics |
| wgpu | 254K | WebGPU implementation |
| ui | 211K | GUI toolkit (27 widgets) |
| gogpu | 96K | App framework |
| + 10 more repos | ~53K | 3D, audio, composition, system tray, types |
Google's article is the theory. GoGPU is the proof. If you're considering Go for an AI-assisted project — we can confirm: the guardrails work. The compiler catches the easy bugs. The toolchain catches the medium bugs. Humans catch the hard bugs. And Go makes all three layers practical at scale.
But guardrails alone aren't enough. You also need a methodology — Smart Coding — where humans own the architecture, AI handles implementation, and cumulative knowledge files ensure each session builds on the last. Go provides the platform. Smart Coding provides the process.
Star us on GitHub: github.com/gogpu/gogpu ⭐
Support continued development: opencollective.com/gogpu
Top comments (0)