Autopilot is now a coding agent

Ask a developer what UiPath Autopilot can do, and the answer depends entirely on when they last used it.

Autopilot has moved through several capability sets, each one doing more than the last. If your picture comes from an earlier set, it's still accurate — for that set. The newest one is a different beast, and it's worth updating to the latest Studio STS.

We heard what you kept asking for:

• Let me describe what to click, and generate the selector for me.

• Understand my whole project, not just the file I have open.

• When something fails, find the cause — don't guess.

• Take my process document and build from it.

That list was the starting point. Autopilot is now a coding agent.

Not an upgrade—a rebuild

What changed isn't a better model behind the same features. Autopilot was rebuilt on UiPath for Coding Agents — the work that opened the UiPath Platform up to coding agents in the first place.

With Autopilot, skills and tools come loaded by default. Nothing to install, no keys to manage, no second subscription.

Under the hood, three pieces do the work:

• The coding agent — plans, builds, runs, and reasons about your project.

• The uip CLI — connects your machine to UiPath. It authenticates to your organization, scaffolds projects and solutions, runs and publishes automations.

• UiPath skills — packaged instructions that teach a coding agent how to do specific UiPath tasks, maintained in the public UiPath skills repository.

A coding agent on its own doesn't know what a selector is, how an Object Repository should be structured, or what a well-formed automation looks like. The skills and the CLI are what turn general coding ability into UiPath ability.

If you formed an opinion of Autopilot a while ago, it's worth trying again. It has put on serious muscle since.

What your week will look like moving forward

The change is easier to see across a project than in a feature list.

Plan from a spec. You used to read the process document and translate it into a build plan yourself. Now you hand Autopilot the PDD or SDD, and it produces the plan, then builds against it. "Build the onboarding process from this SDD" — a 30-page document in, a working automation back, UI selectors included.

Build. Low-code workflows, coded workflows and REFramework projects, generated and modified against UiPath conventions rather than generic ones. "Filter every invoice row above 1,000 into a new sheet" returns a working Excel automation without manually wiring activities. "Turn these PDF invoices into a CSV and send it to finance" wires extraction, transformation, and delivery end to end. And when you inherit a five-year-old project nobody wants to touch, it explains it to you workflow by workflow, then restructures it — "split this 80-activity workflow into smaller reusable pieces" comes back as modular sub-workflows, properly invoked.

Debug and check. Running the automation, stepping through it, and reading what broke. Alongside that, Workflow Analyzer against what was produced, and test cases with assertions written for the workflow it just built — so the first version you review has already been checked.

Publish and manage. Packing and publishing the automation, and handling the Orchestrator side that goes with it — the resources the process needs to actually run.

Troubleshoot what's already running. A job fails in production at 3 am. Autopilot in Studio pulls the logs from Orchestrator, correlates them with the project open in front of you, and names the cause — a missing robot permission, a data problem, or a real defect in the workflow. If the fix belongs in the source, you're already in the place where you can make it.

It's the same coding agent the whole way through. You don't switch tools between building, publishing and fixing, and it doesn't forget your project's conventions when it moves from one file to the next.

The RPA part

The part that makes RPA RPA — driving real applications through their interface — works on day one:

• Build UI Automation workflows from a prompt, using the latest UIA package.

• Extract data from application UIs into structured tables. Point it at a live site and get back a clean DataTable.

• Repair broken selectors — point it at a failing Click and it names the root cause and fixes it. Try it on the RPA Challenge.

One thing worth knowing, because it changes the quality of what you get back: a good Object Repository is a multiplier. If your project has one, Autopilot uses it, and generated UI Automation is measurably more accurate and maintainable. If your project doesn't have one, Autopilot builds it as it works, following UI Automation best practices, rather than targeting elements ad hoc.

So it isn't a prerequisite. It's just better input, and better input gets better output.

You decide what ships

Autopilot executes; you decide. It can take work all the way through to deploying, and whether it gets there reviewed or unreviewed is genuinely your call — nothing stops you.

Our recommendation is the same one that already applies to every other line of code in your project: don't send something to production that nobody has reviewed. That's not a rule about coding agents. It's the reason code review exists at all, and it doesn't change based on who wrote the code. A generated workflow deserves the same pass you'd give a colleague's pull request.

You don't have to do that pass cold, either. Ask Autopilot to review the project, and it runs validation and Workflow Analyzer across it and comes back with findings ranked by severity — a first pass that catches the mechanical problems, so your attention goes to the judgement calls. Which is where it should be: the last call is still yours.

It's also worth being straight about where it's strong. On well-scoped workflows, Autopilot gets you a working draft fast. On large multi-layer processes it's still improving — architecture-level decisions like dispatcher/performer, API versus UI, or how to break a big process apart are directional rather than production-grade. The best results come from letting it build and iterate on the parts while you stay in the loop on the overall structure and the edge cases.

Try it

Update to the latest Studio STS, open the Autopilot panel in a project, and give it something real — build from a spec, hand it a broken selector, or ask it to explain the inherited project nobody wants to touch.

If something's off, run /uipath-feedback directly in Autopilot. It's the fastest route to us: it attaches diagnostics automatically, so we get what happened and the context around it without you having to write it up.

Want to see it work on a real app? How to automate an app that has no API, with Autopilot spreadsheet in records created through the interface, including how Autopilot handles selectors and builds the Object Repository as it goes.

Where is Autopilot, UiPath's coding agent, coming next

• VS Code compatible editors — Autopilot is also available as an extension in Public Preview.

• Studio Web — Public Preview is targeted for September 2026.

• Studio LTS — this capability set arrives in the 26.10 release.

Full details on availability and licensing are in the UiPath Community Forum GA announcement.