How to use Codex to build a Go distributed system
The author reports around 13,000 lines of generated Go in just over two weeks, roughly 300 PRs, good unit-test coverage and learning idiomatic Go along the way.
news.ycombinator.com
Prompt to try
Editorial adaptation, not the source author’s exact prompt. Replace bracketed inputs and review tool permissions first.
Use [design brief] to build [distributed system] in Go. First refine ambiguities, specify all messages and agree on a project plan. Implement in small reviewable PRs, generate unit and integration tests, and use [runtime observations] to investigate design problems. Periodically identify internal inconsistencies and suggest fixes.
Reach people exploring AI agents
See placements →What happened
The author reports around 13,000 lines of generated Go in just over two weeks, roughly 300 PRs, good unit-test coverage and learning idiomatic Go along the way.
Reported by mhandley on Hacker NewsHow the agent did it
- Write a design brief and refine it with o3.
- Request and revise a specification of all messages.
- Request and revise a project plan before coding.
Where a person stepped in
The author revised design documents, skimmed small PRs, adjusted logging, and closely reviewed integration tests to assess the design.
A person approved each step before the agent continued.
An engineer describes developing a non-trivial distributed system with Codex over just over two weeks. Before coding, they wrote a design brief and refined it with o3 to make it more complete and less ambiguous. They then requested a specification of all messages, revised it until satisfied, and repeated that process for a project plan.
Codex generated around 13,000 lines of Go, while the author wrote approximately 100 lines and adjusted logging to understand runtime behavior. The work was divided into about 300 pull requests so the author could skim and understand each chunk rather than lose track of the system's design.
The author requested many unit tests, using them as starting points for investigation and as constraints on architectural changes. They paid closer attention to integration tests because those helped assess whether the design itself was right. They also kept roughly three tasks running at once, choosing work to reduce merge conflicts, and occasionally requested multiple solutions for more open questions.
As another check, prompting Codex to find a bug and suggest a fix exposed real internal inconsistencies. The author also reports learning more idiomatic Go from the generated code. Who it's for: engineers who can own the architecture, review manageable increments, and use integration tests to examine distributed-system behavior.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: Hacker News · mhandley
Frequently asked questions
What happened before code generation?
The author wrote and refined a design brief with o3, iterated on a specification of all messages, and then iterated on a project plan before starting implementation.
How did the author review the growing system?
They kept changes small enough to skim, used about 300 PRs, adjusted logging and paid close attention to integration tests. Unit tests also helped locate problems and constrain architectural changes.
More details
Remaining steps
- Generate Go functionality in small pull-request increments.
- Add unit and integration tests and inspect behavior with logging.
- Periodically ask Codex to find bugs and suggest fixes.
About this account
Codex generated implementation and tests, explored alternative solutions and found inconsistencies, with the author directing small chunks of work.
Platform: Hacker News. Attribution: https://news.ycombinator.com/item?id=44457868. Prompt: Suggested (written by Agents In Use, not the author's). Sourced by the Agents In Use pipeline.
Credit: mhandley on Hacker News
Source published 3 Jul 2025
Source checked 14 Oct 2026
Tools and topics
Codex · o3 · Go
Go · Distributed systems · Integration tests
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.