5 ms·

Seems like reading the code is now the real work. AI writes PRs instantly but reviewing them still takes time. Everything flipped. Expect more projects to follo

Seems like reading the code is now the real work. AI writes PRs instantly but reviewing them still takes time. Everything flipped. Expect more projects to follow - maintainers can just use ai themselves without needing external contributions.

Analemma_ 8mo ago
This is probably true, and while I expect productivity to go up, I also expect "FOSS maintainer burnout" to skyrocket in the coming years. Everyone knows reading code is one-hundredth as fun as writing it, and while we have to accept some amount of reading as the "eating your vegetables" part of the job, FOSS project maintainers are often in a precarious enough position as it is re: job satisfaction. I think having to dramatically increase the proportion of reading to writing, while knowing full well that a bunch of what they are reading was created by some bozo with a CC subscription and little understanding of what they were doing, will lead to a bunch of them walking away.
- binary132 8mo ago
  Not to worry! Microslop probably has a product in the works to replace disgruntled open-source maintainers with agreeable, high-review-throughput agentic systems.
- em-bee 8mo ago
  i have fun reading code, but the fun comes from knowing a human did this. if i find errors i get the satisfaction of teaching that human become a better developer by helping them realize the error and avoid it in the future. if the code is the contribution of a volunteer to a project of mine, even more so. that all goes out the window with AI generated code.
exactlie 8mo ago
[flagged]
patcon 8mo ago
In the civic tech hacknight community I'm part of, it's hard to collaborate the same now, at least when people are using AI. Mostly because now code often feels so disposable and fast. It's like the pace layers have changed It's been proposed that we start collaborating in specs, and just keep regenerating the code like it's CI, to get back to the feeling of collaboration without holding back on the energy and speed of agent coding
- octoberfranklin 8mo ago
  Clowns will just use LLMs to post slop comments in the spec discussions.
- internetter 8mo ago
  > Mostly because now code often feels so disposable and fast I really like this thought. We used to take pride in elegant solutions and architectural designs. Now, in the era of shipping fast and AI, this has been disregarded. Redundancy is everywhere, spaghetti is normalized. AI code has always been unsettling for me and I think this is why.
  - pjmlp 8mo ago
    Think 1 <pick currency> shops, now that factories have fully taken over. I see a future where those that survive are doing mostly architecture work, and a few druids are hired by AI companies.
bigstrat2003 8mo ago
Understanding (not necessarily reading) always was the real work. AI makes people less productive because it's speeding up the thing that wasn't hard (generating code), while generating additional burden on the thing that was hard (understanding the code).
- jchanimal 8mo ago
  It makes a great code reading tool if you use it mindfully. For instance, you can check the integrity of your tests by having it fuzz the implementation and ensure the tests fail and then git checkout to get clean again.
- corndoge 8mo ago
  There are many cases in which I already understand the code before it is written. In these cases AI writing the code is pure gain. I do not need to spend 30 minutes learning how to hold the bazel rule. I do not need to spend 30 minutes to write client boilerplate. List goes on. All broad claims about AI's effects on productivity have counterexamples. It is situational. I think most competent engineers quietly using AI understand this.
  - Analemma_ 8mo ago
    The problem is, even if all that is true, it says very little about the distribution of AI-generated pull requests to GitHub projects. So far, from what I’ve seen, those are overwhelmingly not done by competent engineers, but by randos who just submit a massive pile of crap and expect you to hurry up and merge it already. It might be rational to auto-close all PRs on GitHub even if tons of engineers are quietly using AI to deliver value.
  - csomar 8mo ago
    I mean we did copy/paste before this? Also create-react-app is basically that. And probably better than a stochastic AI generating it.
  - solid_fuel 8mo ago
    > There are many cases in which I already understand the code before it is written. In these cases AI writing the code is pure gain. That's only true if the LLM understands the code in the same way you do - that is, it shares your expectations about architecture and structure. In my experience, once the architecture or design of an application diverges from the average path extracted from training data, performance seriously degrades. You wind up with the LLM creating duplicate functions to do things that are already handled in code, or using different libraries than your code already does.
foretop_yardarm 8mo ago
I actually think Ada has good potential as an AI adjacent language because the syntax is optimised for readability (I personally find it very readable too.)
- timeon 8mo ago
  I think problem is not with quality but quantity in reasonable time frame.
em-bee 8mo ago
this is precisely why i refuse to use AI to generate code at all. i'd have to not only read it but internalize it and understand it in a way as if i had written it myself. at that point it is easier to actually write the code myself. for prototypes and throwaway stuff where only the results count, it may be ok. but not for code that goes into a larger project. especially not FOSS projects where the review depends on volunteers.
steveruizok 8mo ago
Reviewing code is much less of a burden if I can trust the author to also be invested in the output and have all the context they need to make it correct. That's true for my team / tldraw's core contributors but not for external contributors or drive-by accounts. This is nothing new and has up to now been worth the hassle for the benefits of contribution: new perspectives, other motivations, relationships with new programmers. It's just the scale of the problem and the risk that the repo gets overwhelmed by "claude fix this issue that I haven't even read" PRs.
ryanxcharles 8mo ago
you can use ai to review PRs. i do this daily.
reacharavindh 8mo ago
Using a coding agent over days on a personal project. It has made me think 1. These llms are smart and dumb at the same time. They make a phenomenal contribution in such a short time and also do a really dumb change that no one asked for. They break working code in irrational ways. I’ve been asking them to add so many tests for all the functions I care about. This acts as a first guard rail when they trip over themselves. Excessive tests. 2. Having a compiler like Rust’s helps to catch all sorts of mines that the llms are happy to leave. 3. The LLMs don’t have a proper working memory. Their context is often cluttered. I find that curating that context (what is being done, what was tried, what is the technical goal, specific requests etc) in concise yet “relevant for the time” manner helps to get them to not mess up. Perhaps important open source projects that choose to accept AI generated PRs can have such excessive test suites, and run the PRs through them first as a idiotic filter before manually reviewing what the change does.
- quectophoton 8mo ago
  Questions. I want to get into coding agents, so, out of curiosity: which one(s) did you use and how much money has it costed you? (Any metric is fine)
  - reacharavindh 8mo ago
    My wife has a Gemini AI pro Ultra whatever that she paid for to help with her academic research, but uses barely. She was generous to login with it on my computer to let me use the cli with her credentials. So Gemini-3.0-pro comes from there. I use OpenAI and Claude API keys with EUR 20 credits that I topped up (pay per use). I've mostly settled on Gemini-3.0, but occasionally pit codex, Gemini and Claude at each other at a gnarly problem reviewing each other's work, and proposing actionable changes with clear reasoning. They tend to catch teachers blind spots, an dI get to learn something from their reviews as well.

Analemma_ 8mo ago

This is probably true, and while I expect productivity to go up, I also expect "FOSS maintainer burnout" to skyrocket in the coming years. Everyone knows reading code is one-hundredth as fun as writing it, and while we have to accept some amount of reading as the "eating your vegetables" part of the job, FOSS project maintainers are often in a precarious enough position as it is re: job satisfaction. I think having to dramatically increase the proportion of reading to writing, while knowing full well that a bunch of what they are reading was created by some bozo with a CC subscription and little understanding of what they were doing, will lead to a bunch of them walking away.

binary132 8mo ago
Not to worry! Microslop probably has a product in the works to replace disgruntled open-source maintainers with agreeable, high-review-throughput agentic systems.
em-bee 8mo ago
i have fun reading code, but the fun comes from knowing a human did this. if i find errors i get the satisfaction of teaching that human become a better developer by helping them realize the error and avoid it in the future. if the code is the contribution of a volunteer to a project of mine, even more so. that all goes out the window with AI generated code.

exactlie 8mo ago

[flagged]

patcon 8mo ago

In the civic tech hacknight community I'm part of, it's hard to collaborate the same now, at least when people are using AI. Mostly because now code often feels so disposable and fast. It's like the pace layers have changed It's been proposed that we start collaborating in specs, and just keep regenerating the code like it's CI, to get back to the feeling of collaboration without holding back on the energy and speed of agent coding

octoberfranklin 8mo ago
Clowns will just use LLMs to post slop comments in the spec discussions.
internetter 8mo ago
> Mostly because now code often feels so disposable and fast I really like this thought. We used to take pride in elegant solutions and architectural designs. Now, in the era of shipping fast and AI, this has been disregarded. Redundancy is everywhere, spaghetti is normalized. AI code has always been unsettling for me and I think this is why.
- pjmlp 8mo ago
  Think 1 <pick currency> shops, now that factories have fully taken over. I see a future where those that survive are doing mostly architecture work, and a few druids are hired by AI companies.

bigstrat2003 8mo ago

Understanding (not necessarily reading) always was the real work. AI makes people less productive because it's speeding up the thing that wasn't hard (generating code), while generating additional burden on the thing that was hard (understanding the code).

jchanimal 8mo ago
It makes a great code reading tool if you use it mindfully. For instance, you can check the integrity of your tests by having it fuzz the implementation and ensure the tests fail and then git checkout to get clean again.
corndoge 8mo ago
There are many cases in which I already understand the code before it is written. In these cases AI writing the code is pure gain. I do not need to spend 30 minutes learning how to hold the bazel rule. I do not need to spend 30 minutes to write client boilerplate. List goes on. All broad claims about AI's effects on productivity have counterexamples. It is situational. I think most competent engineers quietly using AI understand this.
- Analemma_ 8mo ago
  The problem is, even if all that is true, it says very little about the distribution of AI-generated pull requests to GitHub projects. So far, from what I’ve seen, those are overwhelmingly not done by competent engineers, but by randos who just submit a massive pile of crap and expect you to hurry up and merge it already. It might be rational to auto-close all PRs on GitHub even if tons of engineers are quietly using AI to deliver value.
- csomar 8mo ago
  I mean we did copy/paste before this? Also create-react-app is basically that. And probably better than a stochastic AI generating it.
- solid_fuel 8mo ago
  > There are many cases in which I already understand the code before it is written. In these cases AI writing the code is pure gain. That's only true if the LLM understands the code in the same way you do - that is, it shares your expectations about architecture and structure. In my experience, once the architecture or design of an application diverges from the average path extracted from training data, performance seriously degrades. You wind up with the LLM creating duplicate functions to do things that are already handled in code, or using different libraries than your code already does.

foretop_yardarm 8mo ago

I actually think Ada has good potential as an AI adjacent language because the syntax is optimised for readability (I personally find it very readable too.)

timeon 8mo ago
I think problem is not with quality but quantity in reasonable time frame.

em-bee 8mo ago

this is precisely why i refuse to use AI to generate code at all. i'd have to not only read it but internalize it and understand it in a way as if i had written it myself. at that point it is easier to actually write the code myself. for prototypes and throwaway stuff where only the results count, it may be ok. but not for code that goes into a larger project. especially not FOSS projects where the review depends on volunteers.

steveruizok 8mo ago

Reviewing code is much less of a burden if I can trust the author to also be invested in the output and have all the context they need to make it correct. That's true for my team / tldraw's core contributors but not for external contributors or drive-by accounts. This is nothing new and has up to now been worth the hassle for the benefits of contribution: new perspectives, other motivations, relationships with new programmers. It's just the scale of the problem and the risk that the repo gets overwhelmed by "claude fix this issue that I haven't even read" PRs.

ryanxcharles 8mo ago

you can use ai to review PRs. i do this daily.

reacharavindh 8mo ago

Using a coding agent over days on a personal project. It has made me think 1. These llms are smart and dumb at the same time. They make a phenomenal contribution in such a short time and also do a really dumb change that no one asked for. They break working code in irrational ways. I’ve been asking them to add so many tests for all the functions I care about. This acts as a first guard rail when they trip over themselves. Excessive tests. 2. Having a compiler like Rust’s helps to catch all sorts of mines that the llms are happy to leave. 3. The LLMs don’t have a proper working memory. Their context is often cluttered. I find that curating that context (what is being done, what was tried, what is the technical goal, specific requests etc) in concise yet “relevant for the time” manner helps to get them to not mess up. Perhaps important open source projects that choose to accept AI generated PRs can have such excessive test suites, and run the PRs through them first as a idiotic filter before manually reviewing what the change does.

quectophoton 8mo ago
Questions. I want to get into coding agents, so, out of curiosity: which one(s) did you use and how much money has it costed you? (Any metric is fine)
- reacharavindh 8mo ago
  My wife has a Gemini AI pro Ultra whatever that she paid for to help with her academic research, but uses barely. She was generous to login with it on my computer to let me use the cli with her credentials. So Gemini-3.0-pro comes from there. I use OpenAI and Claude API keys with EUR 20 credits that I topped up (pay per use). I've mostly settled on Gemini-3.0, but occasionally pit codex, Gemini and Claude at each other at a gnarly problem reviewing each other's work, and proposing actionable changes with clear reasoning. They tend to catch teachers blind spots, an dI get to learn something from their reviews as well.