𝗔𝗜 𝗖𝗼𝗱𝗶𝗻𝗴 𝗶𝗻 𝗚𝗼 𝗜𝘀 𝗡𝗼𝘁 𝘁𝗵𝗲 𝗣𝗿𝗼𝗯𝗹𝗲𝗺.
𝗨𝗻𝘃𝗲𝗿𝗶𝗳𝗶𝗲𝗱 𝗔𝗜 𝗖𝗼𝗱𝗶𝗻𝗴 𝗜𝘀.
I recently read Erwin Hermanto’s article:
“Using AI Code Assistants for Go: What Works and What Still Fails”
It’s a good, pragmatic assessment of where Copilot, Cursor and Claude still struggle — especially with:
→ concurrency
→ context propagation
→ hallucinated APIs
→ code that looks correct, compiles…and still contains bugs
I agree with the problems.
𝗕𝘂𝘁 𝗜 𝗱𝗼𝗻’𝘁 𝘁𝗵𝗶𝗻𝗸 𝘁𝗵𝗲 𝗿𝗶𝗴𝗵𝘁 𝗰𝗼𝗻𝗰𝗹𝘂𝘀𝗶𝗼𝗻 𝗶𝘀 “𝗔𝗜 𝗶𝘀𝗻’𝘁 𝗿𝗲𝗮𝗱𝘆 𝗳𝗼𝗿 𝘁𝗵𝗲 𝗵𝗮𝗿𝗱 𝗽𝗮𝗿𝘁𝘀.”
The bigger issue is that we are still evaluating AI as if it were autocomplete.
The question should no longer be:
❌ “Can an LLM generate perfect production Go code from one prompt?”
It can’t. Not reliably.
The better question is:
✅ “Can an agent understand the repository, implement a change, test it, detect problems, fix them, challenge its own implementation and only then create a PR?”
That is a completely different engineering model.
━━━━━━━━━━━━━━━━━━
𝗧𝗮𝗸𝗲 𝗰𝗼𝗻𝗰𝘂𝗿𝗿𝗲𝗻𝗰𝘆.
If an AI creates a data race, the solution shouldn’t be:
“Hopefully a senior developer notices it during review.”
Run:
go test -race ./...
Add static analysis.
Add adversarial tests.
Let a dedicated reviewer agent inspect concurrency.
Then make those checks mandatory in CI.
𝗧𝗵𝗲 𝗺𝗼𝗱𝗲𝗹 𝗱𝗼𝗲𝘀𝗻’𝘁 𝗵𝗮𝘃𝗲 𝘁𝗼 𝗯𝗲 𝗽𝗲𝗿𝗳𝗲𝗰𝘁.
The system around it has to make failures difficult to survive.
━━━━━━━━━━━━━━━━━━
𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗽𝗿𝗼𝗽𝗮𝗴𝗮𝘁𝗶𝗼𝗻?
Don’t hope Claude remembers the correct pattern.
Make it a project rule:
• propagate the caller’s context
• respect cancellation and deadlines
• don’t introduce context.Background() inside request flows
• derive child contexts correctly
Put those rules into CLAUDE.md / project rules.
Then enforce them through static analysis and tests.
That turns “prompting advice” into an 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗰𝗼𝗻𝘁𝗿𝗼𝗹.
━━━━━━━━━━━━━━━━━━
𝗛𝗮𝗹𝗹𝘂𝗰𝗶𝗻𝗮𝘁𝗲𝗱 𝗔𝗣𝗜𝘀?
The agent should not rely on what it “remembers”.
It should inspect:
→ the repository
→ go.mod
→ package source
→ actual documentation
→ existing usage patterns
Then verify:
go build ./...
go vet ./...
staticcheck ./...
go test ./...
go test -race ./...
govulncheck ./...
If verification fails, the task isn’t finished.
The agent fixes the problem and runs the checks again.
𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗲𝗱 𝗰𝗼𝗱𝗲 𝗶𝘀 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝗮𝗯𝗹𝗲.
𝗩𝗲𝗿𝗶𝗳𝗶𝗲𝗱 𝗯𝗲𝗵𝗮𝘃𝗶𝗼𝗿 𝗶𝘀.
━━━━━━━━━━━━━━━━━━
And there is another important change:
𝗢𝗻𝗲 𝗔𝗜 𝗱𝗼𝗲𝘀𝗻’𝘁 𝗵𝗮𝘃𝗲 𝘁𝗼 𝗱𝗼 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴.
A more mature Agentic Engineering workflow can look like this:
𝗥𝗲𝗾𝘂𝗶𝗿𝗲𝗺𝗲𝗻𝘁𝘀
↓
𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗔𝗴𝗲𝗻𝘁
↓
𝗧𝗲𝘀𝘁 𝗔𝗴𝗲𝗻𝘁
↓
𝗖𝗼𝗻𝗰𝘂𝗿𝗿𝗲𝗻𝗰𝘆 / 𝗖𝗼𝗿𝗿𝗲𝗰𝘁𝗻𝗲𝘀𝘀 𝗥𝗲𝘃𝗶𝗲𝘄
↓
𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗥𝗲𝘃𝗶𝗲𝘄
↓
𝗗𝗲𝘁𝗲𝗿𝗺𝗶𝗻𝗶𝘀𝘁𝗶𝗰 𝗖𝗜
↓
𝗣𝘂𝗹𝗹 𝗥𝗲𝗾𝘂𝗲𝘀𝘁
↓
𝗛𝘂𝗺𝗮𝗻 𝗝𝘂𝗱𝗴𝗺𝗲𝗻𝘁
None of those agents are infallible.
That’s exactly the point.
We should not design a development process where correctness depends on one model being right.
━━━━━━━━━━━━━━━━━━
There’s also an important feedback loop:
If a human reviewer discovers:
“Every goroutine needs a clear termination condition.”
or
“Never create context.Background() inside HTTP handlers.”
or
“Concurrent processing must preserve ordering unless explicitly specified otherwise.”
…that knowledge should not die inside a PR comment.
𝗣𝘂𝘁 𝗶𝘁 𝗶𝗻𝘁𝗼 𝘁𝗵𝗲 𝗽𝗿𝗼𝗷𝗲𝗰𝘁’𝘀 𝗔𝗜 𝗿𝘂𝗹𝗲𝘀.
Now the next task starts with that knowledge.
That is how the engineering system improves over time.
━━━━━━━━━━━━━━━━━━
The original article is right about one very important thing:
The hard parts of software engineering do not disappear just because an LLM can generate the code. �
Using AI Code Assistants for Go_ What Works and What Still Fails _ by Erwin Hermanto _ Sep, 2026 _ Medium.pdf
But AI changes 𝘄𝗵𝗲𝗿𝗲 the engineering effort goes.
Less time manually typing implementation.
More time defining:
• requirements
• architecture
• invariants
• acceptance criteria
• tests
• verification
• security boundaries
• automated quality gates
━━━━━━━━━━━━━━━━━━
The future is not:
❌ AI writes code → humans trust it
And I don’t believe the long-term answer is:
❌ AI writes code → humans manually inspect every generated line forever
The direction is:
𝗔𝗴𝗲𝗻𝘁𝘀 𝗶𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁.
𝗔𝗴𝗲𝗻𝘁𝘀 𝗰𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲.
𝗧𝗼𝗼𝗹𝘀 𝘃𝗲𝗿𝗶𝗳𝘆.
𝗖𝗜 𝗲𝗻𝗳𝗼𝗿𝗰𝗲𝘀.
𝗛𝘂𝗺𝗮𝗻𝘀 𝗷𝘂𝗱𝗴𝗲.
The goal is not to make AI so trustworthy that verification becomes unnecessary.
𝗧𝗵𝗲 𝗴𝗼𝗮𝗹 𝗶𝘀 𝘁𝗼 𝗯𝘂𝗶𝗹𝗱 𝗮𝗻 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝘀𝘆𝘀𝘁𝗲𝗺 𝘄𝗵𝗲𝗿𝗲 𝘁𝗿𝘂𝘀𝘁 𝗶𝘀 𝗻𝗼 𝗹𝗼𝗻𝗴𝗲𝗿 𝘁𝗵𝗲 𝗽𝗿𝗶𝗺𝗮𝗿𝘆 𝗺𝗲𝗰𝗵𝗮𝗻𝗶𝘀𝗺 𝗳𝗼𝗿 𝗮𝗰𝗵𝗶𝗲𝘃𝗶𝗻𝗴 𝗰𝗼𝗿𝗿𝗲𝗰𝘁𝗻𝗲𝘀𝘀.
And that principle applies to human-written code too.
—
Inspired by / response to:
Erwin Hermanto
“Using AI Code Assistants for Go: What Works and What Still Fails”
#AgenticAI #SoftwareEngineering #Golang #ClaudeCode #AICoding #AIEngineering