Google has made its internal code review guides public on GitHub. One guide covers reviewers, another covers authors and defines terms like LGTM and CL. The repository shows how Google standardizes its code review process.

• Google published its internal code review guides (reviewer and author docs) publicly on GitHub under google/eng-practices.
• The guides mandate no CL sit unreviewed for more than 24 hours.
• Author guide specifies concrete conventions like "<area>: <summary>" commit messages and splitting big features into logical CLs.
• Reviewer guide gives specific checklists covering security, readability, test coverage, and performance (including C++ memory-allocation checks).

Researchers tracked 112 professional developers using AI agents on the job and found they plan tasks, review every diff, and limit agent scope rather than handing off vague prompts. In trials, AI slowed senior devs by 19% and produced merged PRs only 8% of the time, revealing a 92% failure rate when agents ran unsupervised.

• Study of 112 pro developers found they treat AI agents like junior devs—scoping tasks tightly, reviewing every diff, and stepping in for cross-system or ambiguous work rather than vibe coding.
• In one trial, experienced open-source maintainers using AI were actually 19% slower.
• An agent connected to an issue tracker only got its PRs merged 8% of the time—a 92% failure rate when run with less supervision.
• The "hands-off swarm of agents" demos popular on social media don't match how real production code gets shipped.

Non-programming leaders starting to contribute to code with LLMs can increase iteration speed and introduce diverse perspectives, but this also risks compromising the implicit architecture of the codebase. As more non-engineers make changes, maintaining design intent and code maintainability becomes a challenge, requiring developers to adapt their roles to focus on architectural oversight. Despite these risks, democratizing coding could lead to better solutions as more perspectives are included in the development process.

• LLMs are lowering the barrier enough that non-engineer bosses/founders are now directly committing code, not just prototyping
• The real risk isn't code quality but erosion of implicit architecture—decisions and conventions that were never written down and that LLMs can't infer
• This forces a shift in developers' roles toward explicit architectural oversight and codifying design intent so it survives contact with non-engineer contributors
• Despite the risks, wider participation in coding could surface better solutions by incorporating more diverse perspectives into development