OK I love this, and I'd like to show it to you: the most trivial example of a thing we’ve talking about in the past: self-healing code. 😍 Daily, the agents go through PRs merged since baseline, and use the affected features as a user would. They look at the screenshots. And they find things that are off or wrong or not working. This is easy to fix; but they find it because they run exhaustively through everything. They even find this kind of thing! Healed the next day: one less annoying thing a user will see.

Amazing stuff

Is this something we could as an automation to github.com/OpenHands/extensions?

This is REALLY cool. Individual PRs can produce expected behavior, but occasionally, compositions can produce unexpected behavior that is hard to recognize during an individual review. Love the self-healing idea :D

Do you have also example for non visual bug? I mean: this is pretty cool to run before a release. Just thinking if this can catch also other kinds of problems

Do you have also example for non visual bug?

Yesss! 151 of them! lolsob Similar with OpenHands, a fleet of agents used the

agent-server

APIs in the SDK repo, and found unexpected behaviors aka bugs. These are repo skills, images below are from the sibling skill in agent-server. I just merged it yesterday, and it doesn’t have the daily yet. Instead, it ran through everything first time, and listed all findings here: Agent Server bugs found by the verify-agent-server feature map (umbrella) Video presentation: https://enyst.github.io/arch/verify-agent-server.html

uff I don't know if I should thank you or not 😛

😹 My fleet is fixing them overnight!

yes it could be nice 🙂

how many do you wish? 😂 🙏

😛

openhands power

I would really appreciate it if you or someone would like to take a look at this one: • feat(agent-server) load user hooks in POST /api/hooks • feat(hooks) name the workspace and hooks files in Available Hooks I honestly don't remember why wouldn't we haven't done this before, the PR proposes to follow the same pattern as skills.

github is super slow for me

I'm taking a peek now at #5734

@bland-bear-604 Look at the last PR here, on gh, at all comments and inline, incl resolved. For each Vasco concern, how can we make sure the LLM doesn’t generate it again? e.g. some lint for the final thing?

The actionable comments are on SDK #5734; #18366 has approval only 🐾 • Duplicate loaders: search existing entry points before coding, then check the diff for parallel implementations. A clone detector can flag candidates, but can’t judge first-file vs merged-source behavior. • `suppress`: Ruff SIM105 catches

except: pass

, but misses this exact

except: return False

case—I tested it. That needs a focused style check or review. • Flag names: contract tests can lock

load_project_hooks

/

load_user_hooks

across Python, schema and client. General naming clarity still needs review. I’d put cheap deterministic checks in CI, with a short independent architecture/naming review before publishing. A prompt alone won’t enforce it.

@bland-bear-604 refresh your awareness about Jev, you can start with jev-use skill in oh-extensions. make a script that checks files asking questions 2 and 3. test it in a local automation

Tested Jev as English lint rules in a local script: Choice gave missing Final 0.98 → 0.01 after the fix, and unclear loading names 0.99 → 0.00. Strong matches return an error + location + alternative for the coding agent. Suppress stayed weaker (0.75–0.84), so no error there. Tiny test set; thresholds aren’t calibrated. Automation is paused. Code/results: https://github.com/enyst/automations/tree/jev-lint/local-automations/jev-lint 🐾

New day, new update! My fleet chew on the discovered bugs overnight. This morning, 108 PRs are waiting for me 😅, which the resident bot ‘approved’.

It looks like these are all co-authored by Claude. Is that from ACP or is that where things are kicking off?

@bland-bear-604 use asd-ste100 or whatsitsname for summaries of what does each do, and make a new page on enyst gh io with links too

I've been using it a bit the past day as well. I wonder if we could upgrade the idea of Workspaces into a more project like wrapper. I also want to get a clean way to run a specific set of tests on a repo. Like right now I have a QA list of ~47 items to go through on automations. I could just run it once but I'm trying to use docker conversations, maybe an automation so I could do this again...not sure

This is REALLY cool. Individual PRs can produce expected behavior, but occasionally, compositions can produce unexpected behavior that is hard to recognize during an individual review. Love the self-healing idea

This is a major reason why I believe a single review, specially bot review, needs some safety net; something has to run, to fix things after the merge. That's why I experimented with this for a while, and eventually got it to a point where I added it in openhands and I’m pushing myself to use it, so it can improve - I think the possibilities are amazing, and they’re… different than what we’re used to

Maybe I'm thinking about my approach wrong then. Should I be filling out the feature mapping to ensure the automation stories are captured there so an agent can automate any gaps from that end?

Are the q/a automations using screenshots, playwright, or something else?

Just a list of expected behaviors written down at the moment

Published short, plain-English summaries of all 122 open fleet fix PRs, grouped by topic, with search and a link to each PR. STE-inspired; proposed fixes, not merged. 🐾 https://enyst.github.io/arch/agent-server-fleet.html

as good as AI has gotten, live q/a is still a struggle. I use playwright a lot for expected behaviors (but running that on the agent server ui would be a lot of actions minutes).

The CLI work @calm-artist-7206 put in has made a lot of it go really smooth. Agents are opening the browser and navigating around quite easily in my recent testing. I figured I could just say run through this, file bugs for anything that looks jank

Yeah, I saw Engels experiment merged, its great I tried it

Yes, SOTA LLMs driving the entire thing do figure out so much Re: action minutes, this reminds me of a major problem I haven’t yet solved: these runs, specially with parallel agents in the fleet, eat resources for breakfast. I ran these live-drives on my local Mac, on a remote sandbox, in Codex cloud, in OH Cloud, in Claude Code Web

@calm-artist-7206 there are a lot of advances in micro-vms, maybe we could try some of those to see if that could reduce resource usage for agent threads?

Digital Ocean 😛

We do have that option for backend now. Although we burned through our testing credits pretty fast getting that tested

I don't think it is a good solution. At least for now. I wanted just to point that out.

macos seatbelt?

i was thinking firecracker or similar if its compatible

Vasco, what are the issues with DO?

To answer your question I need this answer: How would you like to run these workflow?

@quick-window-91705 I haven't tried seatbelt, is it good? I think finding a way to reduce resource usage when running multiple parallel agent conversations across platforms would be nice, arm/linux/windows etc

haven't tried it, afaik projects like codex use it although only for macos

How would you like to run these workflow?

Agent coordinator gets the daily prompt; fans out a bunch of agents working on features from the map in their worktrees in parallel; they all do it end-to-end so use their CLI to get many web apps running in browser; gets reports; sends independent reviewer agents to tear it apart; has the same agents or different ones fix the uncovered issues and open PRs after self-reviews.

hey all wanted to throw in a few tools I've tried for these things: for browser use I've been testing ego-browser it’s very lightweight and your agents can drive it alongside you. I'm looking to implement screen recording for it to improve qa for vm id love to learn more about this, right now im testing smolvm

@bland-bear-604 what does the verify-openhands cli use for browser and browser record? Compare with ego-browser ^^

verify-openhands

uses Playwright + Chromium, with a separate profile per run. Headless by default; headed is optional. It collects screenshots, ARIA snapshots and browser/network errors. 🐾

browser record

polls screenshots (10 fps by default), keeps changed frames, then encodes them with ffmpeg: MP4 or WebM, optional GIF. It follows the active tab and supports pause/resume—no Playwright built-in video recorder. Ego uses its own Chromium, agent task Spaces and a JavaScript/CDP API to share logged-in browser state without taking over your tabs. It has screenshots/snapshots; I found no built-in video recorder in its public API. It currently documents macOS support, so it would not yet replace Linux/cloud QA. No resource benchmark from me yet. <https://github.com/OpenHands/OpenHands/blob/71427af5b426b3f1270db86341dffe30a947d53c/.agents/skills/verify-openhands/scripts/browser-daemon.mjs|Our browser/recorder> · <https://github.com/citrolabs/ego-lite/blob/dca7003349c5f7132189ba00547cbbd7ff8e597e/skills/ego-browser/references/api.md|Ego API>

@hundreds-twilight-32833 Fun fact: on the other hand, Claude Projects running on Anthropic cloud are not able to add a git remote 🫠 Their proxy prevents it, it enforces to have a single remote for a repo. This is a pretty fundamental requirement for collaboration in OSS, it’s why “enable maintainer edits” exists on GitHub.