5 ms·

If you're maintaining OSS, that's understandable, and you're free to say no, but in the corporate world, that's not realistic, AI is here to stay, if they don't

If you're maintaining OSS, that's understandable, and you're free to say no, but in the corporate world, that's not realistic, AI is here to stay, if they don't harness it they would just be left behind. even if the AI gets good and stops writing sloppy stuff, it's still gonna write a lot of stuff, and you're gonna review it anyway, and take responsibility and ownership, and it's still gonna take you more time, because the bottleneck is now reviewing and understanding the code. I agree that the workflow is broken, but only on the reviewing side, AI is a tool we use to make products just like any other we used in the past, punch cards, machine code, assembly, ...etc. AI is just the new tool that sits on top of the code as the next level, no one codes with punch cards, no one writes machine code anymore, we used to write the compiled language and don't care about how it's compiled or turned into machine code, same with AI, although it's not there yet and still requires babysitting by engineers, but that's our new job now, and we need to learn how to use it and make our lifes easier.

embedding-shape 17d ago
> but in the corporate world Sure, but that's irrelevant when someone says "I'm an OSS maintainer" and the context is explicitly about reviewing code submitted by others in a FOSS context, where you can say "No" and don't need any SaaS in order to do so.
bmurphy1976 16d ago
That's not true at all of the corporate world. If your team is mass producing slop and you don't have processes in place to get it under control, you've got a big problem on your hand. If any engineer sent me a 20,000 line refactor I'd immediately reject it and tell them to go back and start making changes incrementally at minimum. More likely I'd force them to have a whole design discussion with the team to make sure that what they are doing even makes sense. What happens if they push out slop that significantly increases your infrastructure costs? What happens if they push out slop that significantly increases the number of bugs or outages? What happens if they push out slop that has no observational metrics, dashboards, or tooling? In every case you push back on the team and make them fix their shit. I don't care if they are using LLMs or not. They are responsible for their work being sufficient quality. If they aren't meeting those standards, then they need to step it up.
- othmanosx 14d ago
  I don't disagree with you on this, I worked my whole life in corporate and haven't worked as a OSS maintainer before, though I will _and already did_ reject PRs way less than that, I speak for myself and my team here and it's unrealistic to ship a single PR as complex as this, we usually plan features as tech designs with PRs of no more than 500 LOC, but that doesn't mean we could never have a 20k PR at all. in my experience, those huge PRs are usually the simple ones where most of it is just noise. I did one recently and moved the UI library in one of our old codebases three major versions up to the very latest, although it was 20k lines of changes, all of it is just mechanical chanes, renames, codemod stuff, test fixes, snapshot updates, ...etc. and it's not realistc to split this into multiple smaller PRs as this can bring other complications like having multiple versions of the same UI library in the codebase, which could cause more problems than it fixes, AI helps with that kinda work a lot and I would've never been able to do this migration is such a short time without it. despite that, reviewing it was a UI challenge, not code, with UI libraries, the breaking changes are usually in the UI so you can't see it from the code, and we did have a special process to review it, although on the code side, Github was a nightmare to deal with reviewing this PR, we noticed that github was the bottleneck here since it lays out the code changes without much context and is already hard to navigate and stuggles with huge PRs, the review surface and the developer experince on github was horrible, and that's why I suggested you look for better alternatives, there are a lot out there and all of them are free for OSS so why not try them?

embedding-shape 17d ago

> but in the corporate world Sure, but that's irrelevant when someone says "I'm an OSS maintainer" and the context is explicitly about reviewing code submitted by others in a FOSS context, where you can say "No" and don't need any SaaS in order to do so.

bmurphy1976 16d ago

That's not true at all of the corporate world. If your team is mass producing slop and you don't have processes in place to get it under control, you've got a big problem on your hand. If any engineer sent me a 20,000 line refactor I'd immediately reject it and tell them to go back and start making changes incrementally at minimum. More likely I'd force them to have a whole design discussion with the team to make sure that what they are doing even makes sense. What happens if they push out slop that significantly increases your infrastructure costs? What happens if they push out slop that significantly increases the number of bugs or outages? What happens if they push out slop that has no observational metrics, dashboards, or tooling? In every case you push back on the team and make them fix their shit. I don't care if they are using LLMs or not. They are responsible for their work being sufficient quality. If they aren't meeting those standards, then they need to step it up.

othmanosx 14d ago
I don't disagree with you on this, I worked my whole life in corporate and haven't worked as a OSS maintainer before, though I will _and already did_ reject PRs way less than that, I speak for myself and my team here and it's unrealistic to ship a single PR as complex as this, we usually plan features as tech designs with PRs of no more than 500 LOC, but that doesn't mean we could never have a 20k PR at all. in my experience, those huge PRs are usually the simple ones where most of it is just noise. I did one recently and moved the UI library in one of our old codebases three major versions up to the very latest, although it was 20k lines of changes, all of it is just mechanical chanes, renames, codemod stuff, test fixes, snapshot updates, ...etc. and it's not realistc to split this into multiple smaller PRs as this can bring other complications like having multiple versions of the same UI library in the codebase, which could cause more problems than it fixes, AI helps with that kinda work a lot and I would've never been able to do this migration is such a short time without it. despite that, reviewing it was a UI challenge, not code, with UI libraries, the breaking changes are usually in the UI so you can't see it from the code, and we did have a special process to review it, although on the code side, Github was a nightmare to deal with reviewing this PR, we noticed that github was the bottleneck here since it lays out the code changes without much context and is already hard to navigate and stuggles with huge PRs, the review surface and the developer experince on github was horrible, and that's why I suggested you look for better alternatives, there are a lot out there and all of them are free for OSS so why not try them?