Every time a new feature or fix comes up, some people do the same thing. They open their favorite AI chat, copy the requirement or the PR description, paste it in, and ask "generate test cases for this feature". Then they copy the output back into their test management tool or their notes.
There is nothing wrong with using AI this way, it works. I do think there is something wrong with having a manual flow around it. You have to remember to do it, you have to copy and paste the context every single time, and the AI only knows what you decided to paste. If you forget a detail, or if the feature touches something you did not think to mention, the AI will not know either.
Instead of manually going to an AI chat every time, you can integrate that same LLM into your workflow, so it runs automatically and already has the context it needs.
One example I built recently at work is a GitHub workflow that runs on the PR level.
Every time a developer opens a PR implementing a feature or a fix, we have a label called "ai:generate-test-cases". When someone adds this label, it triggers a GitHub workflow that runs a script calling an LLM. This script reads the full PR diff, the comments, and even external links using MCPs, to gather as much context as possible. Then it drops a comment on the PR with a list of possible test scenarios, the risk level of that change, and whether the developer already added automated tests for it. This way we can focus on the areas that matter the most.
Traditional workflow
Requirement
↓
Copy
↓
Paste into AI chat
↓
Generate Test Cases
Integrated workflow
Pull Request
↓
Label added
↓
GitHub Action
↓
LLM reads diff + context
↓
PR Comment with:
- Test scenarios
- Risk level
- Test coverage insights
Test case suggestions are just one output of this. The same context, the diff, the comments, the linked docs, could just as easily be used to flag risk, or check if something important was missed. Generating test cases is just the first thing I built with it.
This is opt-in by design. It will not generate anything on infra related PRs, or any PR where the label is not added. You choose which PRs need test case suggestions. This is useful not only for QAs, but also for developers who want to make sure they covered the main scenarios, and it can surface an outcome or edge case you had not thought about.
Of course this does not replace human judgment. It is a tool to help organize and prioritize scenarios, not a guarantee that every hidden path has been covered. We should always use our own experience to decide what is worth testing and what is not, since it is impossible to test everything.
AI is much more valuable when it becomes part of your engineering workflow instead of another browser tab. Test case generation is just one example of that.
If this is something you want to try or adapt to your own workflow, the repo is public and I am happy to talk through how it works.
Top comments (1)
I agree that AI becomes more useful when it is embedded in the PR workflow instead of living in a separate chat tab. The part I’d be most careful about is the trust boundary: PR descriptions, comments, diffs, and linked documents are all untrusted inputs and can contain prompt injection or misleading context.
I’d also separate “tests exist” from actual coverage evidence. A model can inspect test files, but changed-line coverage, branch coverage, and execution results should come from deterministic tooling. The strongest version of this system would let CI provide the facts and use the LLM only to interpret gaps, propose scenarios, and explain risk.