Yesterday you wired the agent into your real sources; today is what that wiring buys you on an ordinary Tuesday bug.
Here is the scene, and it will feel familiar. For this one, picture Tumble Kitchen grown up into a full product, with accounts, plans, and saved carts; the practice store on my site is its little sibling. A bug surfaces in a chat channel. Support has a few tickets about saved carts going empty. Engineering half-reproduces it on a different browser. Someone remembers the session length changed in the 1.42 release. Product points out that free users are exactly the ones the team wants to keep. Support asks if someone can please file it properly, and then everyone goes back to being busy. The bug lives on as a scroll of messages nobody owns.
With the agent connected to that channel, the repo, and the tracker, one instruction turns the mess into a filed bug. This is the exact prompt I use:
Read the cart-bug discussion in the #support channel, then
turn it into a single filed bug in our issue tracker. Pull
the reproduction details, the affected browsers, and the
free-plan account type out of the conversation, and confirm
the likely cause by checking the cart retention and cleanup
code in the repo, especially anything that changed in the
1.42 release. Write clear numbered steps, a specific
expected versus actual, and list the concrete evidence to
attach, including the failing cart request and the relevant
server log line. Set severity to High and assign it to the
cart team.
Copy it. Swap the channel name and the release number for yours. What comes back is not a summary of the thread. It is a bug in your format: a title that names the affected users, numbered reproduction steps, a specific expected versus actual, and, because it checked the code, the evidence worth attaching: the cart request that returns an empty items array with a 200 status, and the server log line where the cleanup job runs against the wrong timestamp. The structure it follows is the one in my bug report template. The agent did not invent any of it. It read the conversation, confirmed the cause against the code, and wrote it up where the team works.
The same bug, taken to a pull request
Filing it is half the loop. Because the agent already has the repo, you can hand the confirmed bug straight back:
The saved-cart bug is confirmed: the cleanup job is keying
off the free-plan retention timestamp instead of the cart
timestamp. Find the exact code in the repo, make the
smallest fix that keeps saved carts independent of the
account retention window, and add a test that fails on the
old behaviour and passes on the new one. Open a pull
request with a clear description and the test output.
Change nothing else.
Copy that one too, and notice its anatomy, because this is how I write every task for an agent: name the confirmed fact, ask for the smallest fix, demand a test that fails on the old behaviour and passes on the new one, and end with a hard stopping point. Change nothing else. The pull request that comes back has the fix, the proving test, and its output. What it does not have is a merge. That part is yours: review the diff, confirm the retention rule is the one the product actually wants, and decide whether it ships as a hotfix or waits for the release.
The mental model that makes this work
Treat the agent like a smart junior engineer in their first week. Fast, willing, no context about your team, no idea which mistakes matter. A smart junior needs real access to the work, one clear task at a time, and honest review of everything they hand back. Notice what the agent produced at every step of the loop above: evidence. A filed bug with reproduction steps. A failing test. A diff. Test output. Your job is to judge the evidence, and that is a QA job to its bones.
Workflow
- Messy thread
- Filed bug
- Smallest fix
- Failing test passes
- Your merge call
One more move while it is in there
With the code in context, do not stop at the reported bug. Ask the agent to go deeper on the same flow and find where else it breaks, not confirm the happy path. On the saved-cart bug, the obvious follow-up is the retention rule for every other plan type, and whether anything else keys off that same timestamp. The reported bug is often the one instance of a pattern that got noticed.
Evidence at every step, and the merge decision stays yours. That is the loop.
Try this today
Find one bug living in a chat thread right now, and there is one. If your agent has the access, run the first prompt on it. If not, do the translation by hand into the bug report template and time yourself. The gap between those two times is what the Day 2 wiring is worth on a single bug. The full worked example, the thread and the filed bug side by side, is on give your AI real context.