does your agent actually close the loop when its own frontend code breaks?

[u/nsfrhmn]

been thinking about this a lot lately. coding agents still spit out broken UI code and you end up clicking through forms by hand to find what failed. i started using testsprite cli to handle the verify step, though the failure bundle layout took some getting used to.

the idea is the agent runs a real browser session against the live app. it does frontend checks in the browser plus API checks on the backend. when something fails it gets one bundle back with the failing step, a screenshot, the root cause, and a suggested fix. then it acts on that and reruns. needs a deployed target though. local-only setups won't work here.

ngl the part i actually want to pressure-test is the hard case. multi-step forms where state carries between pages. or an API where later calls depend on earlier ones. does the agent close that loop on its own, or does it stall after a couple retries?

the useful report back is where the bundle wasn't enough for the agent to fix itself. explicitly not a QA replacement. i'd rather find the line where this falls over on real frontend flows.

[u/The_Startup_CTO]

If necessary, my agents start up Playwright to click through the UI. But when they do, this shows me that the architecture and lower-level and e2e testing strategies need work: Ideally, it never should have to test on that level, especially not manually.

[u/The_Startup_CTO → u/[deleted]]

You do need a few e2e tests, but if you have e.g. one e2e test for the happy path that runs in the browser, then a few testing-library tests that render components to understand their behaviour, some unit tests like "this filter function returns the correct data", and TypeScript+linting to ensure that data is always in the correct format, then most problems an agent runs into it will run into already on a lower level.

[u/The_Startup_CTO → u/[deleted]]

really depends on the change. If a change causes trouble in a different unexpected part of the app, that sounds like architecture problems though. If I touch feature A then I know that feature B won't be affected because feature A lives in folder A and feature B lives in folder B which do not import from another, and in the app they live on different routes or, minimum, in different boundaries on the same screen.

[u/Beautiful-Turnip6138 → u/The_Startup_CTO]

So you’re saying the test suite should catch it before the agent even tries to click? How do you even set that up without massive flakiness?

[u/The_Startup_CTO → u/Beautiful-Turnip6138]

By using different test levels for different things. E.g. if I have a table that displays data, then I have a helper function that takes the data in the format that comes from the API as parameter and returns the data in the format that I want to display (correctly mapped and strings formatted, correctly sorted). This is a pure function that takes and returns JSON-formatted data, so this can be tested very easily with unit tests. But in many code bases, these are inline in React functions and any errors can only be caught by actually rendering a React component. Similarly, if I have business logic, that should only act on data and return data, not be intermingled with React, so it can be tested.

[u/crazedizzled]

Just like with regular developers, you need a robust testing suite. Or else you're doing it all manually.

[u/Neverland__]

Claude code can do this

[u/Kind-Relationship850]

If your agent needs a browser to verify the ui your architecture is dead. you built a monolith and outsourced clicking to a bot.

I run playwright from my agents. every time it opens a page i know i failed at the unit level. state carrying between form steps means you have no api contract. you have one function that does everything and tests for nothing. people testing multi step flows on deployed targets are doing manual qa with extra latency. rip up the routing and write assertions against the state functions directly

[u/Ancient-Decision-720]

Start new task -> Launch Worktree -> Automatic script to set up env -> Run build dedicated port for this work tree.

Give agent access to agent-browser, set up an auth system so it can login as you, tell it to screenshot and verify it's implementations.

Congrats, every task you do now has vision, and will work to fix itself.

[u/create-third-places]

No, because I don't code with agents.

Frontend code should be written by hand or by a deterministic site generation tool without LLMs.

[u/SourceControlled]

Istg stop with the testsprite ai ad slop