Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To verify AI-generated code before deployment, check the change against the behaviour and architecture it was meant to satisfy, run tests you can trust independently of the ones the agent wrote, review dependencies and security findings, and have a qualified person understand and approve the change before it reaches production. The pull request is not disappearing as a control point. Coding agents now open and modify pull requests, and AI systems review them, but current official guidance still requires human understanding, review, testing and approval.
Where the pull request stands
“The end of the pull request” and “post-human era” are a provocative framing, not an established fact. The observable change is real: agents open pull requests and modify them, and AI systems review them. A Reddit discussion asking “How do you verify AI-generated code before deploying?” shows what engineers are asking, but it is one anecdotal thread, not a representative survey.
The evidence does not show that human engineering controls have become unnecessary. It shows that verification and accountability have to adapt to code that is produced faster and by agents. That adaptation is what the rest of this article covers.
What the AI-to-AI review data shows
A 2026 study by Selvanayagam and Ghaleb analysed AI-attributed pull requests and the review events attached to them. Its figures apply to the study’s own dataset and attribution method:
#1 Best Overall
- 248,641 AI-attributed pull requests received at least one AI-attributed review.
- Within that dataset, 45,269 AI-attributed reviews were classified as cross-product and 208,145 as same-product.
- Cross-product AI-to-AI review appeared in about 1.6% of identified agent-authored pull requests. This is a study-specific estimate and should not be generalised beyond the study’s dataset and attribution rules.
- Cross-product review volume grew by more than two orders of magnitude between 2025-Q1 and 2025-Q3.
The study defines “closed-loop” narrowly, as AI appearing as both author and reviewer. Its data do not mean humans were absent from those pull requests. It is evidence of a changing workflow, not evidence that pull requests have ended or that AI review is equivalent to qualified human review.
How a platform-hosted agent fits into review
GitHub’s Copilot cloud agent shows the mixed model in practice. It performs security validation, records agent activity and opens draft pull requests, while repository protections and human review remain part of the documented process. GitHub’s documentation states: “Draft pull requests created by Copilot cloud agent must be reviewed and merged by a human.” The cloud agent also cannot approve or merge its own pull requests.
On June 9, 2026, GitHub announced that automatic security validation was generally available for third-party coding agents working in repositories. Depending on repository settings, it runs CodeQL, dependency advisory checks and secret scanning. These are vendor-specific behaviours that may change, and they describe GitHub’s platform rather than every coding agent or repository host.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →A verification sequence
Run these six stages in order. Each earlier stage decides what the later stages need to test.
1. Establish the contract before reading the implementation
Translate the task into observable requirements and into the things the change must not do. Then compare the change against its ticket, design, API contract, threat model and the architecture the codebase already follows. GitHub’s review guidance recommends asking whether the code solves the right problem and follows project conventions.
Ask what the agent assumed about users, business rules, permissions and failure handling. For a password reset endpoint, the contract might state that the response must not reveal whether an address is registered, that reset tokens must be single-use, and that repeated failed attempts must be rate limited. If the implementation does not enforce one of those rules, you have found a gap before reading a single line of logic.
2. Inspect the complete change and its provenance
Read the whole diff, not only the application code. That includes generated tests, configuration, dependency manifests, workflow files, and any deletion or weakening of an existing check. Confirm that the change can be traced to a specific agent task and to the person who requested it.
GitHub documents Copilot-authored commits, co-author attribution, commit signatures, session logs and audit events for its agent. These make a change attributable and auditable. They do not show that the code is safe or correct. With standard Git, two useful starting points are shown below. Adjust the paths to your project’s dependency manifests and workflow directory.
git log --show-signature <base>..HEAD
git diff <base>...HEAD -- package.json package-lock.json .github/workflows3. Run independent functional and structural checks
Build or compile the change, run the existing test suite, and read the warnings rather than treating a green run as the end of review. Then add tests for the behaviour and boundaries that matter most.
NIST’s testing guidance, as updated on October 6, 2026, describes three kinds of test that map well onto this stage:
- Black-box tests against requirements, covering invalid inputs, boundary values and combinations of inputs.
- Structural tests derived from the implementation, which can exercise code paths that requirements-based tests miss.
- Regression tests built around previous bugs, so that a fixed defect cannot quietly return.
Tests are evidence about specified behaviour, not proof of all behaviour. Tests generated alongside the code share the agent’s assumptions, so write or closely review the boundary and regression cases yourself.
4. Probe security and dependencies
Review every new dependency for existence, maintenance status, provenance, licence and known vulnerabilities. AI tools can suggest packages that do not exist or look suspicious, and they can miss project constraints, so confirm each package in the registry your organisation trusts before it is added.
Best Value
Then add security tooling suited to the code: static analysis, secret scanning, and fuzzing for components that parse or otherwise handle heavy input. For network-facing software, NIST recommends dynamic security testing such as a web-application scanner, because reading the code does not show how the running service responds. Keep included libraries and packages under continuing vulnerability monitoring after release. A clean check on the day of merge does not cover advisories published later.
5. Review AI-specific failure modes
Look for the failures that appear most often in generated code:
- APIs, functions or options that do not exist in the version you actually use.
- Project constraints the agent ignored, such as required authorisation checks or logging standards.
- Logic that reads plausibly but violates the stated intent.
- Changes that delete, skip or weaken failing tests.
- Edge cases and maintainability problems that pass every current test.
When an AI reviewer or an automated scanner raises a finding, ask the reviewer to explain why it matters and how it can be reproduced. A second model can help triage findings, but it should not be counted as independent assurance unless there is evidence that it fails in different ways from the first and that its findings have been validated.
6. Require accountable approval and keep a recovery path
The UK Home Office engineering standard, under its “Use AI” guidance, requires AI-assisted output to be reviewed and approved by suitably qualified people before production. It makes teams accountable for that output and requires AI-assisted changes to be traceable. It also directs teams to plan for incorrect or insecure output and to keep ways to detect, mitigate and recover from failures. The standard is written for that department’s organisational context and should not be read as universal law.
The standard puts the principle directly: “Teams will retain full accountability for all AI-assisted code and outputs. AI tools cannot replace human judgement, understanding, ownership, or responsibility for decisions, designs, or changes made to systems.”
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Which control answers which question
The controls answer different questions. Compare them on what each one establishes and what it leaves open, not on a single score.
Quick Recap
| Control | What it can establish | What it cannot establish |
|---|---|---|
| Human review against requirements and conventions | Whether the change solves the stated problem, follows project conventions and fits the architecture | Runtime behaviour, which needs tests or reproduction |
| Independent functional and boundary tests | Behaviour the tests specify, including invalid inputs, boundaries and prior regressions | Behaviour nobody specified; tests are not proof of all behaviour |
| Build, compile and static analysis | Whether the change builds, plus warnings and known code-pattern findings | That the logic matches intent |
| Dependency checks | Known vulnerabilities, licence and maintenance signals for listed packages | Vulnerabilities not yet in advisory data, or how a package behaves at runtime |
| Secret scanning | Credentials that match the scanner’s detection rules | Secrets in formats the scanner does not recognise |
| Fuzzing | Crashes and unexpected behaviour from malformed input to input-heavy components | Code paths the fuzzer never reaches |
| Web-application scanning | How a running network-facing service responds to dynamic probing | Internal logic the scanner never triggers |
| Signed commits, session logs and audit events | Which agent task produced a change and who requested it | That the code is safe or correct |
| AI review | Additional findings to triage and reproduce | Independent assurance without evidence of different failure modes and validation |
When a check fails
Decide the next action from the type of failure:
- A test was deleted, skipped or loosened. Restore the original test before any further review. A passing run after deletion says nothing about the change.
- A dependency is unfamiliar or does not resolve in your trusted registry. Stop the change and replace the package with one you have verified. Do not install it to see whether it works.
- The scanners are clean but the behaviour is wrong. The gap is usually a missing requirement or boundary test, not a scanner failure. Add that test before merging.
- An AI finding cannot be reproduced. Keep it as an open question rather than a confirmed defect, and ask the reviewer for the steps that trigger it.
- The change touches authentication, permissions, configuration or pipeline files. Route it to the owner of that area for approval before merge, as the step 6 approval rule requires.
- A problem reaches production. Use the detection and rollback path you confirmed before release, rather than patching forward without tests.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
