Hacker News Reader

Comment by jebarker | Hacker News Reader

I don’t think the good programmer bad programmer framing is helpful. I think AI fits the working style of some developers better than others. Where it fits I’ve seen some developers become so productive that they suck all the air out of the room and drown everyone else in review - not clear if this is good or bad. Where it doesn’t fit I’ve seen developers shut down because they find the workflow so depressing and their former productivity craters. Similarly I’ve seen perfectly good developers turn into slop generation machines and go largely unchecked because everyone else gets alarm fatigue from reviewing their PRs.

View on HN

Yeah the review fatigue thing is a huge problem at the moment. When your work becomes 90% reviewing AI code, it is very demotivating.

I have been focusing a lot more on testing and "manual" validation than on reviewing individual lines of code. (And on setting up rules for what the lines of code should look like that are easily checked with deterministic tools or by llms.)

For large diffs, I’ll have the human driver walk me through the code in a call and if they understand it well enough to explain it to me, and explain the implications of the changes, that’s good enough for me; if they can’t answer how something works, I’ll respectfully turn down their contribution.

This cost shifting is how I stay sane and avoid burn out at work as well as stay apprised of major behavioral changes in the software we run.

I also think it’s important to emphasize that in an organization, individual productivity is secondary to group productivity, and group productivity is different than the sum of its parts.

I understand your reasoning but my reaction to this suggestion is very strong revulsion :) On both sides of it, I would despise this process.

But you're right about thinking in terms of group productivity and costs and incentives.

We solved this at work by creating a system that has an LLM read a Jira ticket assigned to Mike, create an implementation by itself and post a PR using a service account. Then Mike can come along and review it, thereby satisfying peer review as it was authored by a different user (in our SCM) than the one that reviewed it.

Needless to say it is getting really hard to care about my job anymore

> I have been focusing a lot more on testing and "manual" validation than on reviewing individual lines of code.

Same, but there is a reason I did not choose to work in QA so this sucks too

Fair. But a big part of what I disliked was the tedium, which is largely alleviated. I quite enjoy making sure things I'm building work properly, now.

I've seen this phrased as "some people enjoy software development because they like making things, others enjoy it because they like solving the mental problems it throws up, others enjoy it because it pays well", and AI is really only helping the first type of programmer.

Turns out, business also favor "making things" at least before the other categories.

Although I believe they favor "making the right things" even more. Which is harder but neither the 2nd och 3rd categories help here.

I've seen no evidence that they favour making the right things at all ;)

Lots of evidence that they favour making the thing that the executive wants made, regardless of what the nerds pushing the nerd-buttons think is the right thing.

Reply on news.ycombinator.com