Review an AI-generated Laravel change before accepting it

Start with the behavior you need to preserve

Suppose a profile endpoint lets authorized users update a name. Successful requests return JSON, missing or invalid names must be rejected, and a user cannot edit someone else’s profile. A shorter controller is not automatically an improvement. Before asking an assistant to refactor it, write those behaviors as acceptance criteria and keep a copy of the original code.

Inspect the original checks

This simplified controller authorizes the operation before validating a narrowly selected field. The application still needs its actual policy, route middleware and model configuration. Inspect those dependencies when reviewing the complete change; one pasted file cannot establish the application’s security behavior.

public function update(Request $request, User $user)
{
    $this->authorize('update', $user);
    $data = $request->validate(['name' => ['required', 'string']]);
    $user->update($data);
    return response()->json($user);
}

Compare the proposed revision

The revised example removes explicit authorization and validation, passes all request fields to update and adds a log call. Load the Laravel example in the inspector to see these changed lines. Its text patterns flag the removed checks and logging. They do not prove that equivalent checks are absent elsewhere, or that the model accepts every supplied field.

public function update(Request $request, User $user)
{
    Log::info('Profile update', $request->all());
    $user->update($request->all());
    return response()->json($user);
}

Run tests that can distinguish the versions

Test an authorized valid request, an invalid or missing name, an unauthenticated request and an authenticated user without permission. Assert both HTTP status and response shape using the application’s intended JSON headers. Check the database to confirm rejected requests make no changes. Submit an extra field that should not be editable and assert it stays unchanged. Inspect captured logs using fake sensitive values, not live credentials.

Review findings the patterns cannot see

A helper method, route middleware or form request can provide equivalent validation and authorization without matching the inspector’s patterns. Conversely, a revision can change HTML escaping or transaction behavior without producing any signal. Read the full diff, inspect callers and dependencies and run the project’s existing checks. A no-signal report is an explicit reminder to continue reviewing, not a clean bill of health.

Use an assistant for a focused second review

Copy the generated review prompt and notes, then provide a minimal redacted reproduction separately. Ask the assistant to verify each signal against the code, explain missing context and propose focused regression tests. The exported report deliberately omits source code and your entered acceptance criteria. Review any suggested patch and actually run the tests before accepting the revision.