News and analysis
AI-generated code: review the change and the tool that displays it
JetBrains, GitLab and CNCF highlight separate checks for code review, tool safety and approval before release.
An AI agent may propose a form fix or a new integration in one pass. A product owner still needs someone to establish whether the change preserves permissions, data and the working customer journey. Three October publications address different parts of that decision. An extra glance at the code cannot cover all of them.
Understand the scope before reading lines
In its 6 October research article, JetBrains proposes a three-level review workflow: an overview, file-level risk assessment and selective examination of code fragments. The proposal draws on work with 17 practitioners and a survey of 43 professionals. It is a conceptual framework, not proof that following it makes every generated change reliable.
For a buyer, the useful implication is that a change description should explain behaviour. “Updated the form” tells you little if server validation and request persistence changed too. Ask for the affected data, permissions and external actions. That list helps identify the right reviewer and the journeys worth repeating.
Viewing a change also involves execution
On 2 October, GitLab described ConfigPoisoning in DeepSeek-Reasonix, where untrusted configuration could invoke Git clean filters during diff viewing. The article identifies fixes in Studio 2.21.0 and npm 1.39.3. Ordinary repository cloning does not transfer .git/config; it would be inaccurate to describe every clone as sufficient for this attack.
The connection matters: careful reading does not replace checking the software used to display the change. If your team uses the affected product, establish its version and operating conditions first. Separately review whether the agent can access secrets or alter local configuration. Those questions concern the environment rather than the correctness of business rules.
Keep a proposal separate from deployment
In an 8 October CNCF article, the author argues for representing the next system state as a reviewable change instead of giving an agent root access. This is an architectural argument, rather than a universal defence.
A customer product can use a straightforward operating rule: the agent prepares a change, a reviewer assesses it, and the release process applies the approved version. For an order form, test successful persistence, rejection of incomplete input and recovery after an error. Establish that staging uses separate data and permissions.
Start with one change and a named reviewer. Match the depth of review to its consequences: a colour adjustment and a permission change deserve different checks. Our guide to business rules helps define those boundaries. The archived custom API design discusses contracts and access without claiming adoption of these new tools. If AI contributes to your customer product, discuss a specific change and its acceptance criteria.