Learning from bugs is amazing. Connect to production support tickets to link code changes to real incidents. When done manually by on-call, there is no other historical context.
Automate estimation with "this story reminds me of stories A, B, C, which were estimated to be X points and took Y days." A link lets folks drill down to code metrics, artifact version, etc.
A QA agent would be remarkable in that it has a complete and total timeline for everything, and can be queried in chat.
Also yes on chat querying. One of the most useful parts was letting PMs ask questions like “Has this bug happened since April?” and getting a full trace across releases. The idea of automating grooming using historical story similarity is spot on too. This could easily save teams hours per sprint.
Cost-wise, it’s surprisingly reasonable. The version I saw ran in containers that spun up based on commit activity or deploy frequency. So if no one is pushing code, it's idle. But during launches or busy dev cycles, it ramps up. Much cheaper than staffing a full team to maintain 24/7 vigilance.
In the case I saw, the agent handled things like regression patterns, diff analysis, and known-risk detection across thousands of past issues. The QA team actually became more valuable because they weren’t stuck rerunning the same test plan for the fifth time that week. It was augmentation, not replacement.
That said, I totally agree if a team is just rubber-stamping PRs, the issue isn’t automation, it’s expectations and leadership.
duxup•1mo ago