What a goroutineWhat is goroutine?A lightweight concurrent function in Go launched with the go keyword - much cheaper than an OS thread (~2KB vs ~1MB of stack). Ask AI for more actually is

A goroutine is not an OS thread. It's a function executing concurrently, managed entirely by the Go runtimeWhat is runtime?The environment that runs your code after it's written. Some languages need a runtime installed on the machine; others (like Go) bake it into the binary. Ask AI for more's scheduler. The runtime multiplexes potentially millions of goroutines onto a small number of OS threads using an M:N scheduling model.

When you ask AI to "make this concurrent," it will add the go keyword. What it often won't do is think about what happens after.

AI will generate something like:

func main() {
    go doWork()
    fmt.Println("done")
}

This program almost certainly prints "done" and exits before doWork runs at all. The main goroutine doesn't wait. When main returns, the entire process terminates, all goroutines are killed mid-execution with no cleanup.

Launching goroutines

The go keyword before any function call launches that function in a new goroutineWhat is goroutine?A lightweight concurrent function in Go launched with the go keyword - much cheaper than an OS thread (~2KB vs ~1MB of stack). Ask AI for more:

go myFunction()           // named function
go obj.Method()           // method call
go func() {               // anonymous function (closure)
    fmt.Println("inline")
}()

The calling goroutine continues immediately, it does not block. There is no guarantee about execution order between goroutines.

Waiting with sync.WaitGroup

The correct way to wait for goroutines is sync.WaitGroup:

func main() {
    var wg sync.WaitGroup

    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            fmt.Printf("Worker %d finished\n", id)
        }(i)
    }

    wg.Wait() // blocks until all Done() calls match Add() calls
    fmt.Println("All workers complete")
}

The protocolWhat is protocol?An agreed-upon set of rules for how two systems communicate, defining the format of messages and the expected sequence of exchanges. Ask AI for more is strict:

1. Call wg.Add(n) before launching the goroutineWhat is goroutine?A lightweight concurrent function in Go launched with the go keyword - much cheaper than an OS thread (~2KB vs ~1MB of stack). Ask AI for more
2. Call wg.Done() inside the goroutine (always via defer)
3. Call wg.Wait() to block until the counter hits zero

// WRONG - AI generates this regularly
for i := 0; i < 5; i++ {
    go func(id int) {
        wg.Add(1)        // race: Wait() might win
        defer wg.Done()
        process(id)
    }(i)
}
wg.Wait()

// CORRECT - Add before go
for i := 0; i < 5; i++ {
    wg.Add(1)
    go func(id int) {
        defer wg.Done()
        process(id)
    }(i)
}
wg.Wait()

The loop variable capture bug

This is the single most frequent bug in AI-generated concurrent Go code. Before Go 1.22, loop variables were shared across iterations:

// BUGGY (Go < 1.22) - AI generates this constantly
for i := 0; i < 3; i++ {
    go func() {
        fmt.Println(i) // all goroutines likely print 3
    }()
}

All goroutines capture the same i variable. By the time they execute, the loop has finished and i is 3. The fix is to pass i as an argument:

// CORRECT - parameter creates a copy
for i := 0; i < 3; i++ {
    go func(n int) {
        fmt.Println(n) // each goroutine gets its own copy
    }(i)
}

Go 1.22+ changed loop variable semantics so each iteration gets a fresh variable. But AI trained on older code still generates the buggy pattern, and you'll encounter pre-1.22 codebases constantly.

GoroutineWhat is goroutine?A lightweight concurrent function in Go launched with the go keyword - much cheaper than an OS thread (~2KB vs ~1MB of stack). Ask AI for more leaks

A goroutine that can never exit is a leak. Unlike memory, leaked goroutines consume stack space, hold references to heap objects, and may hold locks or file handles indefinitely.

// LEAK - goroutine blocks forever
func fetchData() {
    ch := make(chan string)
    go func() {
        result := <-ch // nothing ever sends on ch
        process(result)
    }()
    // function returns, goroutine lives forever
}

The question to always ask when reviewing AI-generated goroutines: "Under what conditions does this goroutine exit?" If there's no clear answer, no channelWhat is channel?A typed conduit in Go used to pass values between goroutines - can be unbuffered (synchronous) or buffered (async queue). Ask AI for more close, no context cancellation, no return path, it's a leak.

The Go scheduler

You don't need to manage the scheduler, but understanding it helps you evaluate AI's concurrencyWhat is concurrency?The ability of a program to handle multiple tasks at the same time, like serving thousands of users without slowing down. Ask AI for more choices.

The scheduler has three key entities: G (goroutineWhat is goroutine?A lightweight concurrent function in Go launched with the go keyword - much cheaper than an OS thread (~2KB vs ~1MB of stack). Ask AI for more), M (OS thread), and P (processor/execution context). GOMAXPROCS controls how many P's exist (defaults to number of CPU cores). Each P can run one G at a time on one M.

When a goroutine makes a blocking syscall (file I/O, network), the scheduler detaches it from the P and assigns another goroutine. When a goroutine does channelWhat is channel?A typed conduit in Go used to pass values between goroutines - can be unbuffered (synchronous) or buffered (async queue). Ask AI for more operations or calls runtime.Gosched(), it yields to the scheduler cooperatively.