I have about 15 years of experience with Python, C#, and C++, but I recently joined a team that works entirely in Go. The team uses generative AI to produce code and opens pull requests every few hours, often with 1,000–2,000 lines of changes combining new features, bug fixes, and refactoring. Reviews are expected within a few hours because older branches quickly develop merge conflicts.
I was hired as a senior engineer and can contribute to architecture, system design, planning, and stakeholder work, but I feel less confident reviewing unfamiliar Go code. I would like to improve my Go skills while also helping the team establish a healthier review process. How should I approach reviewing code in a language I know less well, especially when the changes are large and AI-generated?
4 Answers
You can review many important things without being a Go expert: whether the change matches the requirement, error handling, concurrency risks, security, tests, observability, failure modes, and whether the design fits the system. For language-specific details, pair with an experienced Go developer and use the compiler, formatter, static analysis, and tests as part of the review process. Reading smaller, well-written Go projects can also help you learn the conventions quickly.
Set explicit review boundaries with your manager. For example, require small, focused changes, a useful description, passing automated checks, and enough time for a careful review before merging. If a change is urgent, define what truly has to ship instead of treating every request as urgent. If the team refuses to change the size or timing of reviews, the quality risk belongs to the process rather than to you personally.
The biggest issue is probably not your Go knowledge. Pull requests that combine multiple features, bug fixes, and refactors are extremely difficult to review in any language. Start by setting a rule that each change has one clear purpose and that unrelated cleanup belongs in a separate pull request. The team may need to accept slower throughput in exchange for changes that can actually be reviewed safely.
AI-generated code still needs human ownership, and large AI-produced patches are especially hard to validate. You can use a separate AI tool to explain unfamiliar Go constructs, identify likely bugs, compare patterns with languages you know, and suggest areas to inspect, but treat its output as a second opinion rather than a reviewer. Ask the author to explain the change and reject anything they cannot clearly justify. Over time, track recurring failures and use them to argue for smaller patches, better tests, and stronger automated checks.
Pull requests can be a useful way to learn how the team actually uses Go, but I would not make someone unfamiliar with the language the sole or primary reviewer for important changes.