Sorry, so the tool is now even circumventing human review? Is that the goal? So the agent can now merge shit by itself? Just the let damn thing push nto prod by itself at this point.
In some workflows it's helpful for the full loop to be automated so that the agent can test if what's done works. And you can do a more exhaustive test later, after the agents are done running amok to merge various things.
Show HN: I built a tool to assist AI agents to know when a PR is good to go
21–30 of 38 posts
Re: Show HN: I built a tool to assist AI agents to know when a PR is good to go
#22Very interesting! This has a gem in the documentation: Using the tool itself as a CI check. I hadn't considered unresolved comments by say a person, or CodeRabbit or similar tool being a CI status failure. That's an excellent idea for AI driven PR's. On a personal note; I hate LLM output to advertise a project. If you have something to share have the decency to type it out yourself or at least redact the nonsense fro…
Re: Show HN: I built a tool to assist AI agents to know when a PR is good to go
#23This looks nice! I like the idea of providing more deterministic feedback and more or less forcing the assistant to follow a particular development process. Do you have evidence that gtg improves the overall workflow? I think that there is a trade-off between risk of getting stuck (iteration without reaching gtg-green) versus reaching perfect 100% completion.
Re: Show HN: I built a tool to assist AI agents to know when a PR is good to go
#24Earlier quoted context omitted.
I did! The issue however, is having a clear, deterministic method of defining when the code review was 'done'. So the hooks can fire off subagents, but they are non-deterministic and often miss vital code review comments - especially ones that are marked in an inline comment, or are marked as 'Out of PR Scope' or 'Out of range of the file' - which are often the MOST important comments to address! So gtg builds all of…
I thought hooks are always fired if you use it as a PreToolUse event. Wouldn’t that work for the GitHub action tools from the GitHub mcp?
Re: Show HN: I built a tool to assist AI agents to know when a PR is good to go
#25Sorry, so the tool is now even circumventing human review? Is that the goal? So the agent can now merge shit by itself? Just the let damn thing push nto prod by itself at this point.
And yes there are plenty of use cases were ai code doesn't hurt anyone even if it gets merged automatically...
See it as an interesting new field of r&d...
Re: Show HN: I built a tool to assist AI agents to know when a PR is good to go
#26Sorry, so the tool is now even circumventing human review? Is that the goal? So the agent can now merge shit by itself? Just the let damn thing push nto prod by itself at this point.
At a scale, I don't see a net negative of AI merging "shit by itself" if the developer (or the agent) is ensuring sufficient e2e, integration and unit test coverage prior to every merge, if in return I get my team to crank out features at a 10x speed. The reality is that probably 99.9999% of code bases on this earth (but this might drop soon, who knows) pre-date LLMs and organizing them in a way that coding agents ca…
Re: Show HN: I built a tool to assist AI agents to know when a PR is good to go
#27Earlier quoted context omitted.
At a scale, I don't see a net negative of AI merging "shit by itself" if the developer (or the agent) is ensuring sufficient e2e, integration and unit test coverage prior to every merge, if in return I get my team to crank out features at a 10x speed. The reality is that probably 99.9999% of code bases on this earth (but this might drop soon, who knows) pre-date LLMs and organizing them in a way that coding agents ca…
I hate this paradigm because it pits me against my tools as if we're adversaries. The tools are prone to rewrite or even delete the tests, so we have to write other tools to sandbox agents from each other and check each others' work, and I just don't see a way to get deterministically good results over just building shit myself. It comes down to needing high trust in my tools to feel confident in what we're shipping.
You can deterministically always get good results at your pace. But most likely, you won't achieve that at the speed and scale that a coding agent running in 4-5 worktrees, 24/7 without food or toilet breaks, especially if the latter will mostly help achieve the product/business goals at an "OK" quality (in which case you will perhaps be measured by how good you can steer these agents to elevate that quality from "OK" without sacrificing scale too much).
Re: Show HN: I built a tool to assist AI agents to know when a PR is good to go
#28Re: Show HN: I built a tool to assist AI agents to know when a PR is good to go
#29Earlier quoted context omitted.
At a scale, I don't see a net negative of AI merging "shit by itself" if the developer (or the agent) is ensuring sufficient e2e, integration and unit test coverage prior to every merge, if in return I get my team to crank out features at a 10x speed. The reality is that probably 99.9999% of code bases on this earth (but this might drop soon, who knows) pre-date LLMs and organizing them in a way that coding agents ca…
Yup! Software engineers aren't going to be out of work anytime soon, but I'm acting more like a CTO or VPE with a team of agents now, rather than just a single dev with a smart intern.
Re: Show HN: I built a tool to assist AI agents to know when a PR is good to go
#30Sorry, so the tool is now even circumventing human review? Is that the goal? So the agent can now merge shit by itself? Just the let damn thing push nto prod by itself at this point.