From bug report to fix: closing the QA loop with coding agents

Coding agents are good at fixing bugs they can see. Most bug reports do not let them see much: a sentence in a chat, a screenshot without context, no record of what the server returned. This guide shows how LeanTracker, LeanMachine and LeanBrowser close the loop from a tester's report to a verified fix, with every step visible to the people involved.

Start with a report an agent can use

LeanTracker is a desktop app for testers. When something goes wrong, the tester captures it in one step:

• Annotated screenshots with numbered marks, so a description can say "2 is misaligned" and mean something precise.
• The network calls behind the problem, captured automatically: the most recent requests with their status, timing and bodies, with authorization, cookie and token headers redacted at capture time.
• A clear state: a severity, and a workflow that runs from draft through open and in progress to ready for verification and resolved.

The project lives in a folder beside your code, and it is written for agents as much as for people: an index points to every issue, and a short guide in the folder explains the format and the workflow.

Let the agent work the queue

A coding agent starts from the index, picks the issues that are open, and goes straight to each one. It looks at the screenshots and the captured calls before it opens the code, because they usually locate the defect faster than the description does.

{
  "project": "Storefront",
  "byStatus": { "Open": 4, "ReadyForVerification": 2, "Resolved": 18 },
  "issues": [
    { "id": "K7M2PQ", "title": "Order total shows NaN", "status": "Open",
      "severity": "Major", "screenshots": 2, "apiCalls": 10, "line": 142 }
  ]
}

When a report is ambiguous, the agent asks instead of guessing. It adds a clarification to the issue, and the tester answers in the same place, next to the evidence.

Reproduce it in a clean environment

A fix is only as good as the environment it was tested in. LeanMachine gives the agent an isolated Linux sandbox for each piece of work: it reserves a key, creates a session machine, connects to it, and runs the build and the tests there.

# Reserve a key with POST /machine/instance-key, then start the machine
curl -X POST /api/v1/machine/instances \
  -H "Authorization: Bearer $LEANTOOLS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "key": "<instance key>", "instanceType": "Session", "tag": "issue-K7M2PQ" }'

Session machines dispose of themselves after an idle period, and billing stops the moment a machine stops, so the agent can start from a fresh environment for every issue without leaving anything running.

Check the fix in a real browser

For anything a user sees, the agent confirms the fix the way the tester found the bug: in a browser. LeanBrowser captures the page after the change, and the screenshot goes on the issue as evidence.

curl /api/v1/browser/screenshot \
  -H "Authorization: Bearer $LEANTOOLS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://staging.example.com/cart", "options": { "type": "png", "fullPage": true } }' \
  -o cart-after-fix.png

Hand it back

The agent adds a remark that explains the root cause and the change, marked as written by AI, and moves the issue to ready for verification. The tester checks the fix against the original screenshots and network evidence, then resolves the issue or sends it back with a note. Issues stay in step with cloud trackers such as ClickUp, so the rest of the team sees the same state.

Keeping it under control

• One key for the coding agent, scoped to machines and the browser, with a monthly spend cap.
• Nothing left running. Machines stop automatically if credits run out, and idle session machines clean themselves up.
• A shared record. The issue holds the report, the questions, the fix and the evidence; the activity log holds every call and its cost.

Getting started

1. Get LeanTracker and open a project for your application.
2. Create an API key for your coding agent, scoped to LeanMachine and LeanBrowser.
3. Point the agent at the project folder and give it the loop: read the index, reproduce, fix, verify, hand back.

The API reference covers the machine lifecycle and every browser call.