# Reviewing and validating output

> What to check in a coding agent's UiPath output before relying on it, and where the agent tends to fall short.

A coding agent will tell you it is done. That is a claim, not a guarantee: the most common failure mode is output that looks complete but is partly stubbed or subtly wrong. Reviewing before acceptance is what makes the workflow safe.

## What to check before you accept

The actual files, rather than the agent's summary, are what reveal problems. Common ones to watch for:

- **Placeholders dressed up as logic** — a Log Message or TODO standing in for real work. It looks finished but does nothing.
- **The wrong activity for the job** — Invoke Code or a generic fallback where a native UiPath activity exists.
- **Logic in the wrong place** — real work crammed into Assign expressions, or everything in one file.
- **Package issues** — dependencies unpinned in `project.json`, the wrong package, or a missing one.
- **Broken or deleted selectors** — UI targets removed from the Object Repository rather than repaired.
- **Stability across the project** — a fix in one workflow can quietly break another, so the whole project is worth validating, not just the file that changed.
- **Logging and error handling** — actually present, or only mentioned.

When something is off, returning it for regeneration is faster in practice than cleaning it up by hand.

## Validating with UiPath's own tools

A visual read alone is not enough. The dependable check is the agent running the Workflow Analyzer (Analyze Project) and the build, resolving every error and warning, and confirming a local run before the work is accepted. The Workflow Analyzer catches rule and style issues a quick glance misses, and a clean build catches problems that validation alone does not.

## Using the agent as a reviewer

Reviewing is an under-used capability, and one the agent does well. It is good at spotting:

- security issues
- incomplete logic
- wrong outputs
- problems in unfamiliar technology

A specific request, paired with an instruction not to change anything, gets the most out of it:

"Review `GetInvoices.xaml` for security issues, incomplete error handling, and incorrect activity choices. List the findings with severity. Do not fix anything."

A specific request produces a specific review, while a generic "review this" produces a generic one. For a repeatable, read-only review across a whole project, the agent has a dedicated review capability for exactly this. See the [Skills catalog](skills-catalog.md).