- Prioritize whatever is most valuable and/or can stand on its own
If you just say “I don’t know” and have no target, even if that’s more honest, the project is less likely to ever be shipped at all in any useful form.
I don’t think “ready to merge” necessarily means the agent actually merges. Just that it’s gone as far as it can automatically. It’s up to you whether to review at that point or merge, depending on the project and the stakes.
If there are CI failures or obvious issues that another AI can identify, why not have the agent keep going until those are resolved? This tool just makes that process more token efficient. Seems pretty useful to me.
This tool seems agent-oriented for them to merge, rather merely check readiness. In that regard, the page doesn't mention anything about human reviewers, only AI reviewers. Honestly wouldn't be surprised if author, someone seemingly running fully agentic workflows, didn't even consider human reviewers. If it's AI start-to-end*, then yes, quite possibly could push directly to master without much difference.
Call me pessimistic, and considering [1][2][3] (and other similar articles/discussions), believe this tool will be most useful to AI PR spammers the moment is modified to also parse non-AI PR comments.
*Random question: is it start-to-end or end-to-end?
edit: P.S. Agree that it's useful, given its design goals, tool though.
Humans make subtle errors all the time too though. AI results still need to be checked over for anything important, but it's on a vector toward being much more reliable than a human for any kind of repetitive task.
Currently, if you ask an LLM to do something small and self-contained like solve leetcode problems or implement specific algorithms, they will have a much lower rate of mistakes, in terms of implementing the actual code, than an experienced human engineer. The things it does badly are more about architecture, organization, style, and taste.
But with a software bug, the error becomes rapidly widespread and systematic, whereas human error are often not. Doing wrong with a couple of prescription because the doc worked for 12+ hrs is different from systematically doing wrong on a significant number of prescriptions until someone double check the results.
I agree with the excel thing.
Not with thinking it can't happen with vibecoded python.
I think handling sensitive data should be done by professional.
A lawyer handles contracts, a doctor handles health issue and a programmer handles data manipulation through programs.
This doesn't remove risk of errors completely, but it reduces it significantly.
In my home, it's me who's impacted if I screw up a fix in my plumbing, but I won't try to do it at work or in my child's school.
I don't care if my doctor vibe codes an app to manipulate their holidays pictures, I care if they do it to manipulate my health or personal data.
Of course issues CAN happen with Python, but at least with Python we have tools to check for the issues.
Bunch of your personal data is most likely going through some Excel made by a now-retired office worker somewhere 15 years ago. Nobody understands how the sheet works, but it works so they keep using it :) A replacement system (a massive SaaS application) has been "coming soon" for 8 years and cost millions, but it still doesn't work as well as the Excel sheet.
I think it’s just realpolitik grand chessboard strategy. Knocking out an unfriendly/uncooperative leader of a strategically important country. That’s always been the real justification for US foreign policy. It’s a game of risk, without moral considerations beyond optics. There isn’t much more to it than that.
You can be socialist if you cooperate. You can be a dictator if you cooperate. It’s not about political philosophy or forms of government, just playing ball with the hegemon.
I definitely see your point. I'd just say though that it can put a lot of pressure on the romantic relationship. Some can handle it; others might not. And also it makes it much more difficult to recover if things don't work out.
Social life is a bit like SEO. To get the full benefits, you needed to start on it years ago. Trying to do it just-in-time is generally a very frustrating experience. I think there's wisdom in doing casual cultivation when you don't feel you need it. It's like keeping your skills/résumé up-to-date just in case.
Going further, you don't even need to count your reps or track how much weight you're lifting. Literally just do any exercise with any weight per muscle group to near failure for 2-5 sets. Rest the muscle groups you targeted the next 1-3 days, and be consistent every week. Bodyweight, free weights, machines, bands, kettlebells, etc. are all fine. That gets you 80-90% of the benefit with no stress.
Right, but you have to do a lot of work, and really most of your work is in this area. Less on the actual building stuff.
Figuring out what to build is 80% of the work, building it is maybe 20%. The 20% has never been the bottleneck. We make a lot of software, and most of it is not optimal and requires years if not decades of tweaking to meet the true requirements.
> In reality, even an ASI won’t know your intent unless you communicate it clearly and unambiguously.
I recently came to this realization as well, and it now seems so obvious. I feel dumb for not realizing it sooner. Is there any good writing or podcast on this topic?
- On precision vs. noise: yeah, this is a core challenge. Quick answer is the scanner tries to be conservative and lean towards not flagging borderline issues. There's a custom guidance field in the config that lets users adjust sensitivity and severity based on domain/preferences.
- CI times: on a medium-sized PR (say 10k lines) in a fairly large codebase (say a few hundred K lines), it will generally run in 5-15 minutes, and run in parallel with other CI actions. In our case, we have other actions that already take this long, so it doesn't increase total CI time at all.
- Vulnerability types: the post goes into this a bit, but I would look at scanning and red teaming as working together for defense in depth. RAG and tool misuse vulnerabilities are definitely things the scanner can catch. Red teaming is better for vulnerabilities that might not be visible in the code and/or require complex setup state or back and forth to successfully attack.
reply