Qualitative Automated PR descriptions

21 February, 2026

The field of software engineering has been reaping the fruits from generative technologies for some while now, prompting longer term research to measure its exact effects on teams. A recently published research tracked 3 agile teams for 13 months, measuring 5 different dimensions. After introducing AI tooling, the results showed a significant increase in performance, and perceived speed of delivery, however, it maintained a flat amount of commits and lines of code. The paper explains it as an improvement in value density, not necessarily in volume.

According to Christof Elbert, an adjunct professor at the University of Stuttgart with over 150 scientific publications, validating the output of these technologies is problematic, and we should not ignore its risks, despite massive adoption since its inception. However, he emphasizes the enormous potential in software productivity, being able to automate many repetitive tasks and workflows, generating code, testcases, but also the ability to explain and maintain code, when correctly prompted to do so.

One such activity is creating, and reviewing pull requests (PRs). In a paper by Pirouzkhah et al, a pull request is defined as a submitted code contribution that undergoes review by other developers, and is merged in the source code after approval. During this research, an large amount of Github pull requests are analyzed, and developers are interviewed, to determine the value of an effective PR description. They observe that a PR serves two roles, descriptive, explaining purpose, code, and testing, but also as a way to shape the reviewing process, setting the expectation for both parties. Notably, the paper states that writing a PR description is a context-sensitive task, and not just a simple repetitive task.

According to a paper by Jiang et al, PRs help reviewers make informed decisions, however descriptions are not always clearly written. They argue that reviewer modification has often been neglected in previous studies, despite being key information for improving description quality, but also for speeding up a time-consuming process. During the research, thousands of PRs are analyzed to understand what makes a high-quality description. The research explores best practices and shares a candidate set of 12 practices, whereby practices in bold are considered very important:

Practice	Description
1. State the Motivation	Explain the “why” behind this change. Provide context on the problem being solved or the value being added to the project.
2. Link to the related issue	Provide a URL or reference to the tracking ticket (e.g., Jira ticket, GitHub Issue, or Trello card) to keep documentation connected.
3. Describe the bug	If this fixes a bug, detail the specific error, steps to reproduce it, and the expected behavior versus the actual behavior experienced.
4. Describe the functionality	Provide a high-level summary of what the code changes in this Pull Request actually accomplish.
5. Release note info	Write a concise, user-friendly summary suitable for the public changelog or release notes (e.g., “Fixed login crash on iOS”).
6. Clarify the effect	Detail the impact on the existing system. Does it improve performance? Does it introduce breaking changes or affect database schemas?
7. Explain the trade-offs	Discuss why this specific approach was chosen over others. List any downsides or technical debt accepted to ship this solution.
8. Technical details	specific implementation details, such as new libraries used, architectural patterns applied, or complex logic that reviewers should focus on.
9. Testing information	Describe how the changes were verified. Include unit test results, manual testing steps, and evidence like screenshots or screen recordings.
10. Update the checklist	Go through the standard PR checklist (e.g., “Tests passed,” “Linter checked,” “Documentation updated”) and check off completed items.
11. Format requirements	Use standard GitHub keywords to link the PR to issues (e.g., use Closes #12, Fixes #45, or Resolves #99) to automate workflow.
12. Delete template content	Remove the instructional text or unused sections provided by the default PR template to keep the description clean and readable.