Should I vibe code
Cloud and desktop bots for browser, spreadsheet, and back-office workflows
APIs break loudly. A UI just moves, and your bot keeps clicking confidently on whatever is there now.
?
Their verdict, the Solo price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Every other automation entry on this site worries about a system deciding something wrong. RPA has the opposite problem: it decides nothing at all. It re-enacts a sequence of clicks against a screen nobody promised would stay the same, so there is no contract to break and therefore no error to catch. When the portal adds a column, the bot does not fail — it types the amount into whatever now occupies that position and reports success. Robomotion is refreshingly direct about the territory it covers: ERPs, banks, CRMs, tax portals and help desks, signing in and updating records, handling the one-time code. Read that as a list of things you cannot un-submit. Then read the sign-in step properly, because a bot that logs in unattended is a bot holding the password and, for the portals that demand it, the second factor, on a machine that runs at 2am with a human's permissions and nobody watching the dialog it does not recognise. The engineering is genuinely accessible now — Playwright makes the browser half an evening — and that is exactly why this one is worth slowing down for.
What actually breaks
not "if". the specific failures.
- The selector, first and worst. A vendor moves a field or renames a label and the bot carries on: it does not throw, it types into whatever is at that position now, and the run log says success
- Retries, because a user interface has no idempotency key. Re-running a flow that got as far as the Submit button submits it again, and there is no request ID anywhere to reconcile the two against
- The credential store, including the second factor. Unattended sign-in means the password and the OTP seed sit together on the runner, which turns multi-factor authentication into a file
- Partial state. A flow that dies at step nine of fourteen leaves the target system somewhere your code has never seen, and the recovery procedure is a person reading the screen and guessing
- Permission scope. The bot has precisely what the logged-in account has, continuously, including every menu you never intended it to reach and every record that account can delete
- The environment: a screen-resolution change, an OS update, a browser auto-update, a new cookie banner, a maintenance notice. Each is a layout change your selectors did not anticipate, and the last two are not even bugs
- Silence as the default failure mode. Nothing between the bot and the portal is ever going to tell you the numbers are wrong. The accountant will, in about eleven weeks
- Bot detection, which is the other ending: the portal decides you are automation and locks the account you were automating with, usually the week you needed it most
The e-invoice downloader had run every night since March. Sign in, one-time code, open the list, take everything since the last run, post it into the bookkeeping system. In June the portal added a column — a compliance status flag, inserted third — and the flow addressed cells by position, because that is what the recorder generated and it had worked for a hundred nights. From that evening the net amount landed in the field bookkeeping reads as gross. Nothing failed. The nightly run logged fourteen invoices imported, then eleven, then nine, exactly as it always had, and the dashboard stayed green for eleven weeks. The accountant found it during the quarterly return, the way these are always found: two figures that should have agreed, didn't, by a suspiciously consistent ratio. The fix was one line. The remediation was three months of postings reviewed by hand and a correction filed against a return that had already gone in, which is a different kind of afternoon.
Is that you?
the verdict is a default, not a law
- The target system is yours, the data is yours, and the worst case is redoing an hour of work by hand
- Every run is read-only — download, scrape, summarise — and nothing anywhere submits
- It runs attended, in front of you, on a schedule you are awake for
- There genuinely is no API, and you checked properly, including the CSV export nobody advertises
- It signs into anything financial, statutory or contractual on your behalf while nobody is watching
- The account it uses can do more than the task requires, which is the default when the account belongs to a human
- Nothing downstream independently re-checks the numbers it wrote
- The credentials are a colleague's, so every action the bot takes will appear in the audit log under their name
If you build it anyway
the checklist, then the prompt that enforces it
- Try the API, then the export, then the UI, in that order, and write down which you rejected and why. A surprising share of "there's no API" portals have a CSV button three menus deep, and a download is not an irreversible action.
- Read-only for the first month. Download and reconcile against what a human did. You are not testing the code, you are testing whether the screen stays where you left it.
- Assert before acting. Verify a landmark — this column header reads Net, this row's invoice number matches the one we asked for — before typing anything, and stop the run when the assertion fails rather than continuing carefully.
- Screenshot every step and keep the artefacts with the run log. When the numbers turn out wrong in September, those screenshots are the only record of what the screen looked like in June.
- Give the bot its own account with its own permissions, never a person's session. If the target system cannot issue one, that is useful information about whether it should be automated at all.
- Enforce idempotency yourself: record the external identifier of everything processed and refuse to process it twice, because the UI will not stop you.
- Reconcile out of band. A second, independent check on counts and totals, plus an alert on "identical result for N runs" as well as on errors — the failure you are looking for is the one that does not raise anything.
- Keep the OTP seed off the runner if there is any way to do so, and if there is not, be explicit in writing that the machine holds both factors and that this is what you decided.
I want to automate a business process by driving a website or desktop UI. The
failure I fear is the silent one: the layout changes and the bot keeps going,
confidently, into the wrong field. Work in this order and push back if I skip.
1. Before writing a flow, ask whether the target has an API or a file export.
If it does, build against that and say why UI automation is the worst option.
2. Build read-only first: sign in, navigate, extract, write a report. Nothing
submits or updates anything on the far side, and it stays that way a month.
3. Never address elements by position or generated index. Anchor on stable text,
labels or test IDs; if only position is available, assert on the neighbours.
4. Assert the shape of the screen before every action: expected header text,
expected row identity, expected field label. A failed assertion stops the
run and alerts. It never falls back to "try anyway".
5. Capture a screenshot and the DOM at every step, keyed by run ID, and keep
them. This is the only forensic record that will exist.
6. Enforce idempotency in my own store: record the external identifier of each
item processed and refuse to reprocess. A UI cannot deduplicate for us.
7. Design for partial failure: per flow, what state is the target left in if we
die at each step, and what is the recovery? Confirm irreversible steps first.
8. Credentials come from a secrets manager at run time, never from the flow
definition. Ask me whether the bot can have its own account with narrowed
permissions, and if the answer is no, record that decision in the README.
9. If the process needs a one-time code, stop and tell me that unattended
operation means this machine holds both authentication factors, and what an
attacker with the runner therefore gets.
10. Build reconciliation before scheduling: an independent check on totals and
counts, an alert when a run's output is suspiciously identical to the last
one, and an alert when it has not run at all.
11. Out of scope until I ask: anything that pays, files, orders or cancels.
Those are the ones with no undo, and Robomotion is $49 a month if what I
want is a runner and a scheduler rather than the responsibility.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Forty-nine dollars a month for Solo buys a runner, a scheduler, a recorder, a credential proxy and somebody else's browser-version treadmill, and all of that is real value for a small back office. Be clear about what it does not buy, though: the vendor cannot absorb the selector problem, because the fragility lives between their bot and someone else's website. Whoever owns the flow owns the maintenance, and that is you either way. The thing genuinely worth paying for is the operational shell — logs, retries, secrets, scheduling — while the discipline of assertions and reconciliation stays your job.
$49/mo is cheaper than your weekend.
The awkward truth is that the flows are not portable, so plan for the exit by keeping everything except the flows outside the tool. Downloaded artefacts — invoices, statements, exports — belong in your own storage the moment they land, not in the platform's. Run logs and screenshots go to the same place. Selectors, assertions and the credentials inventory live in git with a comment per flow saying which screen each one depends on. And for every automated process, keep the manual procedure written down and current, because the week the vendor redesigns their portal you will be doing it by hand, and a bot that has been running for a year is also a year of nobody remembering how.
Mature, actively maintained keyword-driven automation framework with browser and desktop libraries.
Windows-native open-source RPA with a visual designer and UI-element recorder, though releases have been quiet since mid-2025.
Once the reference open-source RPA tool; AI Singapore has since discontinued maintenance and support, which is its own lesson about flow longevity.
Questions
Isn't this just Playwright with extra steps?
The browser half is, and that is precisely why it is worth a warning — Playwright made the fun part easy and left the dangerous part unchanged. What RPA platforms add on top is the operational shell: scheduling, credential handling, a desktop runner, retries, run history. What nobody adds is a guarantee that the page still looks the way it did last month, and that is the failure this entry is about.
Why is UI automation riskier than API automation, if both are code?
Because an API is a contract, and a contract breaks loudly. Rename a field and the call returns a 400; change a type and your client throws. Screens have no such property. Move a column and the click still lands, the form still submits and the run still reports success, so the failure surfaces weeks later in someone else's spreadsheet. That is the whole difference, and it is why the guardrails here are all about asserting what should be true before acting.
Where does the regulatory exposure actually come from?
From what these bots are pointed at. Robomotion's own examples include tax portals and e-invoicing, and the moment automation is writing figures that end up in a filing or in your books, the accuracy of those figures is a recordkeeping obligation rather than a preference. The IRS and the EU invoicing rules do not care that a selector moved. Keep the artefacts, keep the logs, and reconcile independently.
Can I at least automate the boring read-only stuff?
Yes, and that is the recommendation. Downloading statements, scraping a dashboard into a spreadsheet, checking whether a status changed — none of those can be un-done, so the worst case is stale data and a wasted evening. The line this entry draws is at the first button that changes something on the other side. Everything before it is a good weekend.
- IRS — what kind of records should I keep
- EU VAT invoicing rules
- GDPR Art. 32 — security of processing (EU)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
A reconciliation that reports nothing looks exactly like a reconciliation that is not running.
The scraper is one node. The nine after it translate, guess someone's email address and press send.
An automation hub is a box holding every API key you own, wired to the internet.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice