Senior · Go with coding agents
Review AI-written concurrent Go
What should you inspect first in generated goroutine code?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Find ownership: who starts each goroutine, who cancels it, who waits, and who closes every channel. Check all blocking sends, receives, semaphore acquisitions and I/O calls.
Inspect shared mutable state, copied mutexes, loop capture semantics for the supported Go version and whether capacity limits apply before spawning work. A default select or a buffered channel can hide a leak without fixing it.
Use a deterministic blocked-path test plus race detection on relevant paths. Verify no work remains after the operation ends and source/result data is not concurrently reused. The race detector does not prove liveness or distributed idempotency.
Common trap
Generated code often looks structured while leaving the early-return or error path without a join.
Try it
The agent launches one goroutine per input, then acquires a semaphore inside each. Is total concurrency bounded?
Worked solution
Active work may be bounded but the number of waiting goroutines is not. Acquire capacity before spawn with cancellation or use a fixed worker pool and bounded queue. Test a large input under a memory budget and cancellation.
Change the constraint
How would you prove a worker cannot keep using a buffer after its caller returns it to a pool?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.