Matt Palmer demonstrates using Cursor Cloud Agent to generate a UI motion video against real Slack

Using a Cursor cloud computer to "look at the real Slack" and turn the interface into a code video

A hands-on demo from @mattyp, covering overall: Why → Cursor agents & computer use → Video as code → Slack → Chat · Agent · Computer → Inner loop/Outer loop → The ladder → Skills → Feedback loops → Recap.

The demo looks like "an Agent recreating Slack's motion effects," but what it's really about is a reproducible creative method: give an Agent a computer it can control, open the reference interface, have it make video assets with code, and let it iterate on its own in an inner loop of "do → check against the real thing → fix"; the human only provides references, preferences, and permissions in the outer loop, then turns one success into a Skill, generalizes it into an abstraction, and finally automates the outer loop.

What the demo is actually doing Matt opens Chrome on the Linux remote desktop of a Cursor cloud Agent, with Slack running; at the same time he uses the Agent to make motion video (treating UI motion effects as code artifacts). He stresses: Slack was not decompiled; he just told the Agent what he wanted, gave it video references, and opened the real Slack on the Agent's computer so it could extract visual and easing / motion patterns by comparison. On screen you can see recreated channels, threads (e.g., in # ci-oncall the Agent checks payments-svc tests), and assets like @ Marketer drafting Team Bots copy in # launch-copy; on the left the Agent is also merging PRs, exporting an asset pack, and turning "what was just done" into a bootstrap motion skill. He says this kind of thing was nearly impossible a year ago.

Video as code When video assets are generated with code, "is it right" becomes: can it render / compile, and does it look as expected. Previously visual acceptance Agents were very weak; now it can be put into the feedback loop, where after rendering the model checks against the real reference and then changes the code.

Shape: one chat + one Agent + one computer Most demos are isomorphic: you direct things in chat; the Agent has full desktop control (screenshots, clicks), whether in the cloud or locally. He prefers the cloud (it can run for a long time and doesn't fear laptop sleep), and is also trying a Mac mini.

Inner loop and outer loop · Inner loop: the Agent does the work → checks against the real thing → if there are clear failure/evaluation criteria, fixes it → continues until it considers itself done, then hands it to the human for acceptance. · Outer loop: the human provides inputs (references / preferences / access) and judges outputs (artifacts / screenshots / analytics). Slack example: you need to create a sandbox, give credentials, and log in on the computer; he half-jokingly says this may violate the ToS, "don't tell Slack HQ." The goal is to push as much automatable work as possible into the inner loop.

The ladder Spoken path: first do it once (vibe coding it out yourself in chat) → codify it into a Skill → generalize (not just Slack; you can also produce visualizations / B-roll for products like X) → finally automate in the outer loop, feeding context into the inner loop like software and collecting high-quality output. The ladder on screen is labeled Do (workflow) → Codify (skill) → Generalize (abstraction).

What to do when it fails, and why Skills matter Use the "desk lamp" analogy: it's plugged in, the switch is on, and the bulb has been checked, so the problem lies between the socket and the lamp, and the engineer has to find the break point. When an Agent fails it's the same: ask why, debug, then encode the cause into a Skill so later Agents inherit it and eliminate that class of problem. He also compares feedback loops to raising plants, fitness, and learning guitar; and says care and habits get amplified when working with Agents. At the end he says he is still refining these ideas.