AI Coding Agents Need a Verification Loop
September 24, 2026 Avishka Devinda
September 24, 2026 Avishka Devinda
A coding agent can generate correct-looking code very quickly.
That is useful.
But the biggest improvement I have seen does not come from asking for a better first answer.
It comes from letting the agent verify its own work.
I think an AI coding workflow should be a loop, not a one-shot generation.
The simplest AI workflow looks like this:
Prompt
↓
Generate code
↓
Done
The problem is obvious.
The agent has no evidence that the change works.
The TypeScript might fail.
The route might return 500.
The page might render incorrectly.
The button might not work.
The mobile layout might be broken.
The generated code can look convincing while the application is unusable.
I prefer:
Understand
↓
Edit
↓
Run
↓
Observe
↓
Fix
↓
Repeat
This gives the agent feedback.
That feedback can come from different places.
The first level is static checks.
For a Next.js project:
npm run lint
npm run build
or project-specific type checking.
This catches things like:
It is useful, but it is not enough.
The development server knows things the static build may not show immediately.
A good agent workflow watches:
Modern Next.js tooling is making this information easier for agents to consume directly.
That reduces the need to scrape random terminal text.
The browser is where I find a different class of problems.
Examples:
A coding agent needs browser access if I expect it to validate UI work.
For API-connected features, I also want the agent to inspect network behavior.
A contact form is a good example.
The UI can show an error, but the real problem may be:
POST /api/send/mail/talk-me
504
Then I want the agent to continue:
Browser failure
↓
Server runtime logs
↓
External provider logs
↓
Source code
↓
Fix
That is debugging, not code generation.
Local development is not always enough.
A feature can work locally and fail after deployment because of:
For important changes I want a preview deployment before production.
Then the agent can inspect the deployment state and logs instead of assuming local success means production success.
If a behavior matters, I like writing a test for it.
For example:
test('contact form submits successfully', async ({ page }) => {
await page.goto('/talk');
await page.getByLabel('Name').fill('Test User');
await page.getByLabel('Email').fill('test@example.com');
await page.getByLabel('Message').fill('Hello from Playwright');
await page.getByRole('button', { name: 'Send' }).click();
await expect(page.getByText('Message sent')).toBeVisible();
});
Now the agent has an objective target.
It can keep changing the implementation until the test passes.
A verification loop is a good example of something that belongs in an agent Skill.
I do not want to explain the whole process in every prompt.
A Skill can encode:
After editing:
1. Check compilation.
2. Open the affected route.
3. Inspect console errors.
4. Perform the changed interaction.
5. Inspect failed network calls.
6. Fix any issue.
7. Repeat until clean.
The agent can reuse the same quality bar across many tasks.
An endless loop is not useful either.
A good workflow has completion conditions.
For example:
Build passes
Affected route compiles
No browser console errors
Target interaction works
Required tests pass
Diff contains no unrelated changes
When those conditions are true, the agent can stop.
If the remaining problem requires a product decision, that is when I want the agent to ask rather than guessing.
The quality of AI coding depends heavily on what happens after the first code generation.
Give the agent a compiler, dev server, browser, logs, tests, and a clear definition of done.
Then it can do something much more valuable than generate code.
It can debug its own implementation.
That verification loop is one of the biggest differences between using AI as autocomplete and using an AI coding agent as part of a real development workflow.