I have 15 years of experience with Python, C# and C++, but I recently joined a team that now writes everything in Go. The team relies heavily on generative AI to produce code, with pull requests being opened every few hours. I was hired as a senior engineer and can contribute to architecture, system design, planning and stakeholder work, but I'm struggling when asked to review the implementation itself.
The pull requests are often 1,000–2,000 lines and combine features, bug fixes and refactoring. There is also pressure to review them within a few hours because otherwise merge conflicts supposedly make them difficult to integrate.
I'm trying to improve the review process, but I'd also like advice on how to review unfamiliar-language code responsibly. How much can I rely on general engineering and code-review experience, and what should I learn or use to assess the Go-specific parts?
4 Answers
The language is probably the least serious issue here. A 1,000–2,000-line change that combines unrelated features, fixes and refactoring is difficult to review in any language. Start by setting a rule that each change has one clear purpose. Smaller pull requests will also reduce merge conflicts and make reviews much more meaningful.
Use tools to fill in the gaps, but don’t treat AI review as a substitute for engineering judgment. Run the formatter, compiler, static analysis, linters, tests and security checks. You can also have an assistant explain unfamiliar Go constructs and compare them with patterns you know, then verify its claims against the documentation. Reading a well-maintained Go project and making small practice changes will help you learn much faster than trying to decipher huge AI-generated pull requests.
You can review many important things without knowing every language detail: whether the change solves the stated problem, whether the design fits the system, how errors and edge cases are handled, whether concurrency and resource ownership look safe, whether tests cover the behavior, and whether the code is maintainable. For Go-specific idioms and standard-library details, ask another experienced Go developer to be the primary reviewer while you learn through smaller reviews.
I’d address the process before trying to become the team’s Go expert. Tell your manager that you’ll reject changes containing unrelated work, require the author to explain the design and intent, and expect tests and automated checks to pass first. Agree on realistic review targets and priorities; if the team wants fast reviews, it has to keep the changes small enough to review quickly.
Make sure management explicitly supports this approach. Otherwise you may be held responsible for slowing down a process that was already unrealistic.
AI-generated code still needs human ownership. If the authors can’t explain what their change does, why it is designed that way, and how it was tested, that is a reason to stop the review rather than a reason to approve it.