You walk past a ministry office and notice that there is nobody at the door checking people entering, you walk in, you find an office door open, many binders on the shelves, nobody present. You read through the binders, pull out the drawers and see private info etc. You then walk out and send a mail about this. What do you think is going to happen?
The custom Github Actions approach is very customisable and flexible. In theory you could make and even auto approve bumps.
If you want something more structured, I’ve been playing with and can recommend Renovate (no affiliation). Renovate supports far more ecosystems, has a better community and customisation.
Having tried it I can’t believe how relatively poor Dependabot, the default tool is something we put up with by default. Take something simple like multi layer dockerfiles. This has been a docker features for a while now, yet it’s still silently unsupported by dependabot!
The refined github extension[0] has some defaults that make the default view a little more tolerable. Past that I can personally recommend Renovate, which supports far more ecosystems and customisation options (like auto merging).
I think they mean if they already have her fingerprint from somewhere else, and a secret backdoor into the laptop. Then they could login, setup biometrics and pretend they had first access when she unlocked it. All without revealing their backdoor.
I'm not sold at the idea - for most projects it makes sense that the author of the PR should ultimately have ownership in the code that they're submitting. It doesn't matter if that's AI generated, generated with the help of other humans or typed up by a monkey.
> A computer can never be held accountable, therefore a computer must never make a management decision. - IBM Training Manual, 1979
Splitting out AI into it's own entity invites a word of issues, AI cannot take ownership of the bugs it writes or the responsibility for the code to be good. That lies up to the human "co-author", if you want to use that phrase.
> It doesn't matter if that's AI generated, generated with the help of other humans or typed up by a monkey.
It doesn't matter how true this should be in principle, in practice there are significant slop issues on the ground that we can't ignore and have to deal with. Context and subtext matter. It's already reasonable in some cases to trust contributions from different people differently based on who they are.
> Splitting out AI into it's own entity invites a word of issues, AI cannot take ownership of the bugs it writes
The old rules of reputation and shame are gone. The door is open to people who will generate and spam bad PRs and have nothing to lose from it.
Isolating the AI is the next best thing. It's still an account that's facing consequences, even if it's anonymous. Yes there are issues but there's no perfect solution in a world where we can't have good things anymore.
Most code was garbage before AI, and most engineers made significant mistakes. Very little code is not future tech debt. Review and testing has always been the only defense, reputation or skill of the committer is not.
> The old rules of reputation and shame are gone. The door is open to people who will generate and spam bad PRs and have nothing to lose from it.
The important part here is that reputation creates an incentive to be conscious of what you're submitting in the first place, not that it grants you some free pass from review.
There's been an unfortunate uptick in people submitting garbage they spent no time on and then whining about feedback because they trust what the AI put together more than their own skills and don't think it could be wrong.
The issue is the asymmetry between the time it takes to generate convincing AI slop and the time it takes to review it. The convincing part was still somewhat difficult when slop had to be written by hand.
I agree that accountability should always rest with the human submitting the PR. This isn't for deflecting ownership to AI. The goal is transparency, making it visible how code was produced, not who is accountable for it. These signals can help teams align on expectations, review depth, and risk tolerance, especially for beta or proof‑of‑concept code that may be rewritten later. It can also serve as a reminder to the author about which parts of the code were added with less scrutiny, without changing who ultimately owns the outcome.
As far as I'm aware, all of the Snapdragon ARM laptops are existing chassis designs with different motherboards. I'm not sure how ARM affects build quality. Moreover, Snapdragon X support on Linux is still heavily a work in progress with issues with sound, power management, webcam support, and video acceleration. I don't know why anyone would go with a Snapdragon laptop today when Intel Lunar Lake excels at the exact same workloads Snapdragon X does, has similar battery life, and Intel actually works on getting device support upstreamed in a timely manner.
reply