The tweet is criticizing over-reliance on the "agents will fix it anyway".
The fact that we can fix things faster now doesn't mean that we should throw away caution and prevention. The specific point of his tweet is that we're seeing a lot of people starting to skip proper release engineering.
Agents are quick to fix bugs, yes, but it doesn't mean that users will tolerate software that gets completely broken after each new feature is introduced and takes a certain number of days to heal each time.
Matt Might's website has taught me so much over the years, going all the way back to ... I want to say 2008-2009? From programming languages to Unix-fu to a huge amount of topics in-between. I'm super glad to see his writing still being shared. One of my favorite corners of the web.
I don't understand the rush to be "the first". Facebook isn't the first social media, Google isn't the first search engine, iPhone is not the first smart phone, Microsoft is not the first OS, the list goes on.
Clearly there's an advantage for being an early adopter, but the advantage is often overblown, and the cost to get it is often underestimated.
> You’re a primary maintainer or core team member of a public repo with 5,000+ GitHub stars or 1M+ monthly NPM downloads.
I've been an open source maintainer of one of the biggest open source projects in the world[1], and it wouldn't fill any of these requirements. Anybody else hates it that now "open source" is conflated with Github (a private company, itself not open source) popularity?
The way I experience this is through unprecedented amount of feature creep. We don't use AI generated code for all our projects, but in the ones we do, I see a weird anti-pattern settle in: Simply because it's faster than ever before to generate a patch and get it merged, it doesn't mean that merging 50+ commits this week makes sense.
Code and feature still need to experience time and stability in order to achieve maturity. We need to give our end users time to try stuff, to shape their opinions and habits. We need to let everyone on the dev team take the time to update their mental model of the project as patches are merged. Heck, I've seen too many Product Owners incapable of telling you clearly what went in and out of the code over the previous 2 releases, and those are usually a few weeks apart.
Making individual tasks faster should give us more time to think in terms of quality and stability. Instead, people want to add more features more often.
> Open Source is not the absolute social good we delude ourselves into thinking.
Historically the term "Open Source" was specifically developed to divorce the movement from the "social good" ideas that were promoted by Free Software.
That's where I stand. I don't do Open Source to make the world better. I do Open Source because I believe that makes my software better.
I'm not an activist. I'm an engineer. Nothing wrong with activism, all the power to the people doing it, but the licensing I chose for my code doesn't take it into account.
I don't know if you're "wrong", but I do feel differently about this.
I've written a ton of open source code and I never cared what people do with it, both "good" or "bad". I only want my code to be "useful". Not just to the people I agree with, but to anyone who needs to use a computer.
Of course, I'd rather people use my code to feed the poor than build weapons, but it's just a preference. My conviction is that my code is _freed_ from me and my individual preferences and shared for everyone to use.
I don't think my code is "stolen", if someone uses it to make themselves rich.
I think this is moving the goal post. Cloudflare isn't challenging the need to restrict access to some websites, it is challenging who has the right to decide. Quoting the tweet:
> We believe Italy, like all countries, has a right to regulate the content on networks inside its borders. But they must do so following the Rule of Law and principles of Due Process.
I live in Italy, I'm a citizen. I don't feel any safer having the internet regulated by a bunch of bureaucrats than I do state actors and bots.
What he's saying is that the grandparent (top-rated as of this writing) comment claiming that agribusinesses are hiding the benefits of "community gardens, local food, farmers markets, grass fed, free range..." because they don't make money off of them is unfounded.
I personally don't have any insight into the situation and I definitely don't want to defend big businesses, I'm just explaining what you're replying to.
You're not wrong, however the issue is that it's not always easy to detect if a PR includes proof that the change works. It requires that the reviewer interrupts what they're doing, switch context completely and look at the PR.
If you consider that reviewer bandwidth is very limited in most projects AND that the volume of low-effort-AI-assisted PR has grown incredibly over the past year, now we have a spam problem.
Some of my engineers refuse to review a patch if they detect that it's AI-assisted. They're wrong, but I understand their pain.
The fact that we can fix things faster now doesn't mean that we should throw away caution and prevention. The specific point of his tweet is that we're seeing a lot of people starting to skip proper release engineering.
Agents are quick to fix bugs, yes, but it doesn't mean that users will tolerate software that gets completely broken after each new feature is introduced and takes a certain number of days to heal each time.