> Can we avoid big PRs with lots of code generated by bots? :) From your lips to God’s ears :)
Yeah this is why I think it would have to be opt-in and non-blocking. It shouldn’t be a target that you point your agent to iterate against, it’s just another useful bit of signal. As I said, I’ve found it helpful when developing locally. > On 30 Oct 2026, at 11:47, Michael Sokolov <[email protected]> wrote: > > I would have thought the bots would mostly be iterating on the code, > but do you think the bots will become aware of the code coverage > metrics too if we expose them? I'm not sure what we could do to > prevent that. > > On Fri, Oct 30, 2026 at 7:30 AM Robert Muir <[email protected]> wrote: >> >> Can we avoid big PRs with lots of code generated by bots? :) >> >> My experience is that the bots will generate even more completely >> worthless tests to try to satisfy line coverage metrics / goals. Tests >> that ... exercise the code but don't actually make any valuable >> assertions. >> >> On Fri, Oct 30, 2026 at 6:17 AM Alan Woodward <[email protected]> wrote: >>> >>> I’ve been using a python script that combines our existing gradle coverage >>> tool with https://github.com/Bachmann1234/diff_cover to highlight any new >>> lines in a commit that aren’t covered by unit tests, which has been very >>> helpful in finding untested corners of big PRs (especially useful when lots >>> of code is generated by bots). It occurs to me that this would also be >>> useful as an opt-in GitHub action, maybe triggered by a specific label >>> being applied to a PR. What do people think? Keeping it opt-in would be >>> important I think as the reports can be noisy, and of course not all >>> coverage gaps really need to be filled. >>> >>> - Alan >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
