# Working effectively

> The mindset, prompts, and review habits for working with a coding agent on UiPath projects, and what separates a draft from a shippable result.

A coding agent is a fast collaborator, not an autonomous developer. You set the direction and judge the results; the agent does the legwork. Working well with one is a skill in itself, and the right habits separate a draft you throw away from a result you can ship.

## How a coding agent works, and your role

A coding agent takes a goal and carries it out step by step, checking the result of each action and adjusting as it goes, much like a navigation app rerouting after a missed turn. Hitting a problem partway through and recovering from it is the system working as intended, not a breakdown.

Your role stays central throughout. You set the goal, watch the work, catch issues, and approve anything that changes state. A more capable agent raises the stakes for that oversight rather than removing it: the agent assists, and you decide.

## Setting it up to succeed

Good results come from three things working together, not from clever wording alone:

- A clear request.
- A sound setup.
- The right context.

The agent works from a finite working memory, so what is relevant and current matters more than volume.

- The agent does best with the specific files, goals, and standards a task needs, rather than everything you have.
- The right UiPath skill needs to be available, since skills are not always selected automatically. Naming the skill for the task, such as `uipath-rpa` for Robotic Process Automation (RPA) work, and confirming it loaded keeps the agent on the house patterns. See [Skills overview](skills-overview.md).
- A fresh session for each new task keeps stale context from bleeding in.
- Conventions you repeat every session belong in a file the agent loads automatically. See [Give your agent project context](agent-context-files.md).

## Five habits that work

- **You are the architect.** Clear intent and structure, including what you want, the inputs, and the constraints, are yours to bring.
- **The output is a draft.** Generated work is worth reviewing before you rely on it, and is not for shipping unreviewed.
- **Validation beats trust.** UiPath's own checks, such as the Workflow Analyzer (Analyze Project) and a local run, are more reliable than the agent's "done" message.
- **It is a reviewer, too.** An agent is good at spotting security issues, gaps, and unfamiliar code, not only at writing it.
- **Closing the loop compounds.** A short note on what worked, after a substantial session, pays off as team knowledge builds.

## Writing prompts that work

The quality of your request is the single biggest factor in how a session goes. A strong prompt includes:

- A clear deliverable: the exact file or project to produce, and where it lives.
- Named inputs and outputs, with their types.
- The expected behavior, end to end.
- Explicit constraints: the activities or packages to use, and the ones to avoid.
- Any context the agent needs, such as existing dependencies.

A vague request costs more iteration to correct than a specific one. For example, "create `UploadInvoice.xaml` that reads `in_FilePath (String)`, uploads it to SharePoint, and returns `out_Url (String)`" works better than "make something that uploads files."

## Start from a PDD or SDD

The strongest input for a non-trivial automation is a structured spec. A Process Design Document (PDD) or Solution Design Document (SDD) already carries most of what a good request needs:

- the steps
- the inputs
- the systems involved
- the exception paths

Handing that to the agent, rather than describing the process from memory, produces a closer first result with less back-and-forth.

For larger work, the agent can turn a PDD into an SDD and a build plan, then work through it piece by piece, instead of building everything from a raw document in one pass. One caution: a PDD or SDD can hold real customer data, so removing it before the document reaches the agent matters, since the agent needs the structure, not the real values.

## Plan first, and iterate on the plan

Your coding agent may offer a plan mode: before changing anything, the agent drafts a plan of what it intends to do, for your review. A plan takes less time to revise than code, so iterating on it, by correcting the approach, the file layout, or the order of work, pays off before a single line is written. Approving the plan only once it reads correctly keeps the build on track and stops a wrong architecture from surfacing late.

A reviewed, agreed plan is the difference between a guided session and one that drifts.

## The generate, check, refine loop

Most non-trivial work runs in two or three cycles: the agent generates, you check, then you refine or regenerate. Checking after each meaningful step, rather than only at the end, isolates the first problem and is faster overall, even when it feels slower. For UiPath projects the check is concrete: the agent runs the Workflow Analyzer and the build, resolves every problem, and confirms a local run before anything counts as done.

| Iterate when | Start over when |
|---|---|
| The issue is localized and you can name the fix | The agent loops on variations of the same broken output |
| The structure is right | The structure itself is wrong |
| You are within a fix or two | You are on your third or fourth fix attempt |

Starting fresh is not failure; it tends to be the fastest path. What you learn about phrasing carries into a better next prompt.

## Staying in control

A coding agent can take actions that are hard to undo. A few rules keep the work safe:

- Actions that change a shared system, such as publishing or deploying to Orchestrator, are worth approving explicitly.
- Secrets stay out of prompts; stored as UiPath assets or in a credential store, they are referenced by name instead.
- Real customer data does not belong in a prompt, since the agent needs the structure, not the values.
- Every package change is worth reviewing, with versions pinned in `project.json`.

The agent acts under your UiPath identity, with your permissions and audit trail, so its actions are effectively your own. For how this applies to your organization, see [Governance and trust](governance-and-trust.md). For what to look for in generated work, see [Reviewing and validating output](reviewing-agent-output.md).