GopherForgeA WORKBENCH FOR GO

Around Go: coding agents · 3 MIN READ

A Go agent task starts with a contract and a failing example

Turn an ambiguous coding request into a small, verifiable Go change.

Claude Code, Codex and Cursor can inspect files, propose patches and run available tools. Useful work still needs a concrete behavior and a way to check it. In this unit you guide an agent in your own repository; GopherForge does not connect to an AI provider or send your projects to one.

A Go agent task starts with a contract and a failing example · A MAP OF THE IDEA

  1. State the defect
  2. Inspect code and callers
  3. Review a small patch
  4. Run meaningful checks

Useful when

  • Turn an ambiguous coding request into a small, verifiable Go change.
  • Define the contract, inspect the relevant code, make one reviewable change and require concrete evidence. Use the explanation to check understanding, not replace it.

Watch out

  • A tool can generate and execute code while still misunderstanding the product invariant. Review behavior as well as syntax.

Implementation & operation cost: Choose the policy from the actual contract, then verify its failure path in the target environment.

01

Give the task an observable result

Suppose LowerBound returns an arbitrary duplicate index. Supply a minimal input, expected answer, supported Go version and public API constraint. Ask the agent to inspect the implementation and existing tests before proposing a change. A broad instruction such as improve search does not tell either of you which behavior matters.

text
Task: fix LowerBound in internal/search.
Input: [1, 3, 3, 8], target 3. Expected index: 1.
Preserve the exported signature and half-open interval invariant.
Inspect existing callers and tests first. Add empty, missing and duplicate cases.
Run: go test ./internal/search
Explain why equality moves hi instead of returning immediately.
Read the code

This is an example task prompt, not a tool-specific command. It names the defect, scope, invariant and verification. Replace paths with real repository paths; the agent must not invent a test result if the environment cannot run the command.

02

Inspect before accepting a patch

Read the actual diff, including tests. A test that merely duplicates the new implementation may be green without protecting the contract. Ask which previous input fails, why the change fixes it and which other callers could observe a difference. Formatting changes should not hide the behavior change.

03

Keep human judgment at the boundary

An agent can miss an overflow, copy a mutex or drop a cancellation path while producing plausible prose. Identify the owner of mutable values, the lifetime of every goroutine and the meaning of public errors yourself. A small patch is easier to understand and revert than an unexplained rewrite.

04

Repeat a reproducible check

Run the focused test, then the affected package checks. Record the actual compiler and command. If a remote integration service is unavailable, label that check unverified and keep an isolated reproduction. Passing unit tests is useful evidence; it is not proof about database failover or every interleaving.

TAKE THIS WITH YOU

Define the contract, inspect the relevant code, make one reviewable change and require concrete evidence. Use the explanation to check understanding, not replace it.

Check your understanding

An agent reports a fix but never names a reproducing input or test. What should you establish first?

Go to the source

Progress stays in this browser. No account needed.