Serkan Özal’s IronBee Express writeup is worth reading for the things that broke: Jev chooses from visible browser controls, ordinary code performs the action, and an optional language model handles writing or recovery.

I read the complete article, not the project implementation, and did not run its demos or reproduce its measurements. The reported experiments are the developer’s own; the title’s “fastest, cheapest” claim is not an established comparative result.

Batch decisions—but check their relationships

  • One request asks for the operation, each possible target and the text value; code validates the selected operation and corresponding target.
  • Independent answers do not know one another: a card number once went into a PIN field.
  • Target-specific follow-up questions repair suspicious pairings; another asks what the completed field should contain after replacement or joining.
  • Put stalled-action guidance in the relevant option, the author found, rather than accumulating general prompt rules.

Better state beats a smarter-sounding prompt

  • Give identical controls distinguishing product context, and include relevant history and prior-page evidence.
  • Wait for requests started by an action before judging the next snapshot.
  • Count progress as changed page content—not merely a reload—and remove repeatedly ineffective clicks from the offered menu.
  • Reported fixes use small examples; they are design lessons, not broad accuracy guarantees.

Replay is not classifier exploration

  • Saved runs normally replay without model-selected steps; ambiguous or missing controls can trigger a narrow matching question or fresh exploration.
  • The author reports $0.00054 in Jev charges for a replayed checkout, principally its final checks, versus $0.0042 for an explored 20-action run. Neither result was reproduced here.
  • In a controlled local-shop test, the author reports 110/130 correct replay outcomes initially and 130/130 after fixes to waiting and repeated-control matching.
  • Those fixes were evaluated on the same controlled change suite—not evidence of perfect reliability on arbitrary sites.

Completion is still a model judgment

  • A fresh goal check reads page state, API response bodies and logs; HTTP 200 or a success banner alone can conceal a failed order.
  • The author also documents false passes: an unapplied Airbnb search change, Google Translate runs, and an order judged before payment failure arrived.
  • The Airbnb false pass carried a reported 0.99 probability. A typed verdict and high confidence did not make it correct.
  • The project removes explicit assertions. For consequential acceptance checks, keep independent, deterministic postconditions rather than treating a classifier’s DONE as proof.

The strongest reusable idea is to narrow the model’s choices and improve the evidence around them. Bounded actions reduce what can be invented; they do not guarantee the right target, authorization or a correctly verified outcome.