u/Specialist_Agent3599

Self taught dev here. I got into this by building stuff at night for years. The fun part was making something work that didn't work an hour ago.

These days most of my job is reading. The agent writes it, coderabbit leaves its comments, and I spend about 6 hours a day going through diffs I didn't write, deciding if they're good enough. It's not hard. It's just not the thing I fell in love with.

The weird part is it leaked into my side projects too. I open the editor on a weekend and my first instinct is to prompt it and review what comes back, because that's what my brain is trained to do now. And then it doesn't feel like mine.

I still like my job and I'm not quitting. It just feels like I burnt out on the hobby without actually losing interest in it. Maybe I'm being dramatic, I don't know. How do you guys deal with this?

I'm starting to think about stepping down as lead.

My team doesn't really have anyone steering anymore. My manager and his manager are all in on agents, and the agents are basically running the team now, not us.

Last week I went through our sprint board properly for the first time in a while. Of the 34 tickets we closed, 31 were opened, written and merged through agents. Specs drafted by Claude, PRs by Codex, first review by coderabbit / bugbot. The humans mostly clicked approve.

Everyone thinks we're moving faster than any team in the company, and on paper we are. Meanwhile nobody can tell me why half of those changes exist, and the one incident we had took 2 days to fix because nobody had read the code it came from.

My manager built a whole internal dashboard over the weekend in one prompt and sent it to the team with "look what I made, not bad huh".

I've tried to slow things down twice. I don't think I can talk them out of it. Sometimes you just have to let them find out.

Agents are great for a lot of things, but I still write most of my TypeScript by hand, and on a team where nobody else does, my PRs are now the slow ones. Mine take a day, theirs take 20 minutes and go through the same coderabbit / claude review pass as mine.

Is anyone else still working like this, or am I just slow now?

So a few weeks ago I was rethinking how we onboard new devs. For years the first week was pairing on a small ticket, reading through the codebase with someone, then shipping one tiny change. But everyone on the team writes basically all their code through Claude now, so that week didn't look like the actual job anymore.

I put together a new first-week task and my manager liked it enough that we ran it with the 3 people who started this month. They get an agent-generated PR that touches billing logic with 4 bugs we planted on purpose. Normally coderabbit / bugbot would flag most of that, so we switch them off for this one. Then we watch how they review it and what they do next.

What surprised me is that none of them really read the diff. They read the PR description, asked the agent "is this safe to merge", and approved. 2 of the 3 caught none of the bugs. When I asked why, one of them said reading code is what the tools are for.

I'm honestly not sure if they're wrong or I'm the one who's behind. If this is how everyone works now, what is a review even supposed to be? And how long until someone upstairs asks why they need me doing it at all...

I've been handed ownership of an external agency team, 8 devs, who build and maintain our internal apps. Nobody asked me, my manager left and it landed on me. They were picked because they were cheap and the quality shows.

We used to give them small, well defined tickets. Now they run everything through agents, turnaround is faster, and I'm getting 30 to 40 PRs a week that build, pass tests and are still wrong in ways that take me an hour each to spot.

Options I'm looking at:

1. Review everything myself, which is basically my whole job now

2. Put coderabbit / bugbot in front so only PRs that pass reach me, which catches the sloppy stuff but not the "this isn't what we asked for" stuff

3. Make them write a short "why" for every PR before I look

4. Go back to management and say cheap stopped being cheap

Anyone been through something like this, and how did you handle it?

Keeping quality up when your whole team works through agents

I know this has been talked to death, but I keep failing to have this conversation with my own team without it turning into a pro vs anti AI argument, so I'm trying here.

Some background: I lead a team of 6 at a mid-sized company. Before this year we were known as the team that shipped clean stuff.

Then agents happened. Everyone uses them for almost everything now, and our merged PRs went from about 40 a month to about 110.

What I can't figure out is how to turn that into better product instead of just more product. Our best work used to come from someone really understanding the problem before writing anything. Now the PRs look fine, tests pass, coderabbit / claude review clean up the obvious stuff, and when something breaks in prod the person who "wrote" it has a vague idea of how it works at best.

I'm not looking for the "AI bad" or "just add more agents" answers, more from leads who have actually had this problem and found something that works.

TL;DR: team output is up almost 3x, understanding of what we ship is down, and I don't know how to fix the second without killing the first. How are you keeping quality up?

We dont. Some people read them, some approve from the summary, one guy blocks anything over 300 lines no matter what. The only thing that happens to every single PR is the coderabbit pass, everything after that depends on who is online.

Does anyone have a written rule? Like agent PRs need X, human PRs need Y. Or is it vibes everywhere and we just dont admit it

12 years in, I lead a team of 6. Two of them are juniors and both ship agent PRs all day. The PRs are fine. Tests pass, coderabbit leaves a couple of comments, they fix them, merged. They are faster than I was at their age by a lot.

What worries me is they have never had a PR fall apart on them. The bot catches the small stuff before it hurts, the agent writes the fix, and they never sit with a bad decision long enough to learn why it was bad. I learned most of what I know from things breaking.

So I am thinking of making them read every line of every agent PR, even when the review is clean. That will slow them down and they will hate it. The other option is trust the process and accept they learn differently.

What do you do with juniors right now? Read everything, or let the tools carry it

Real question from my skip level this week. The agent writes the PR, coderabbit reviews it, tests pass, so why is a human still in the loop and why does it take a day. I gave some answer about context and ownership and I dont think it landed.

How do you explain this to someone who doesnt code? What is the human actually there for now, in one sentence

Genuinely want to know. We used to pair on anything tricky. Now the tricky thing goes to the agent, coderabbit reads the PR before a person does (it catches the boring stuff, it does not catch a bad idea), I read the summary, and I cant remember the last time someone sat next to me and we worked on one thing together. Nobody on my team has mentioned pairing in months.

Is anyone still doing it? And if you are, what does it even look like now, two people watching one agent?

i've been writing up a payments service this week that is maybe seventy percent agent built by now. first time anybody has sat down with the whole thing properly.

there is a hardcoded skip in the nightly reconcile. one account id, sitting in a list on its own. nothing in the code says why it is there. no ticket linked to the commit. the pr description is two lines about what the change does, the commit is called 'handle reconcile edge case', and it went in eight months ago.

nobody who works here now was in the room when that got decided, because there was no room.

so if you are running agents at any volume, get somebody to record why and not what. coderabbit's summary of that pr is still sitting there and it describes the skip accurately. i could already see the skip.

I work on a small platform team and I would rather not be pinpointed so I will leave the roles out, but there is no tech lead and the closest thing we have is a senior who runs standup and keeps the board tidy.

Nobody really reads anything anymore. Approvals come back inside a minute on changes that took an agent the better part of an hour to produce, and I do not think anyone is being lazy, there is just no way through that volume by reading.

What I have tried: asking for a paragraph of design before a whole feature turns up as one diff, leaving actual comments rather than an approve, reopening things a week later once the shape of them starts causing problems, twice now sitting on a call with someone and going through a change line by line because typing it out would have taken longer. None of it has spread past me.

The part wearing me down is that I have started to doubt the thing I am defending. We have coderabbit on the repos and between them they catch more than the humans do at this point, which I say without much pride, but a bot raising something and a person deciding it matters are two different jobs and only one of them still has anybody doing it. My last team argued about every single change and I found it exhausting at the time. I would take it now.

So what is the review actually for here. Do I keep doing it properly while nobody else does, do I stop and clear tickets like everyone else, or is a team where nothing ever gets held up genuinely fine and I am the one with the problem.

Any thoughts welcome

Every plan it writes has a time estimate at the bottom. 2 days, 3 days, sometimes a week. Then it does the whole thing in 15 minutes. The PR is small, coderabbit summarizes it in two lines, done.

I dont get where the number comes from. Is it guessing how long a person would take? Or does it just not know how fast it is? Does anyone know

Is it just me? Twice this week I got the full "done, all changes applied, ready for review" message, opened the PR and it was 2 files when the ticket clearly needed 5 or 6. Second time coderabbit's summary literally said the PR didnt touch the endpoint the title was about, which is how I even noticed. Told the agent, it said sorry and did the rest in a minute. So it can do it, it just... announced done first? Happens more after long sessions I think. Anyone else, or is it my setup

Hey folks!

I'm an engineering manager at a mid sized company, three squads, each with a PM and a designer attached. Over the last two quarters the devs have got a lot faster and we assumed product and design would become the constraint, so we put effort there first. They did not become the constraint. The queue is sitting in review instead. We merged around 40 PRs a week in March and we are at 110 now with the same four people qualified to approve anything that touches billing, and those four are also the people writing the hardest changes. We have coderabbit on the repos which takes the first pass and genuinely helps with the volume, but somebody senior still has to be the one who says yes.

I would really like to hear from anyone who has been through this already. Did you widen who is allowed to approve, cut down what needs approval at all, or just accept that the queue is longer now? Anything is welcome!

We turned on the triage queue last week mostly because our open PR count hit 62 and nobody could say which ones mattered. I expected a sorted list. What I did not expect was a whole view called recommended to close with 9 PRs in it.

Went through them with the other lead. 4 were agent PRs from a ticket that got cancelled, 2 were superseded by a later PR that already merged, 1 was a draft from someone who left in June. The other 2 were mine from before the holidays that I had honestly forgotten about. Closed all 9 in about ten minutes, and nobody had noticed any of them were dead.

The needs you view is the part I actually use every morning now, 62 open PRs became 5 I have to look at today. Curious how other teams decide what to review first when most of the queue is agent output. Do you still go oldest first?

We had 3 PRs sitting red since yesterday, all agent written, all failing on stuff nobody wanted to look at. Typed the fix-ci comment on each one this morning while making coffee. About 2 minutes later there were 3 stacked PRs waiting: a missing env var in the workflow file, a snapshot that needed updating after a copy change, and an import that moved in a refactor. Merged all three before standup.

Should have been doing this a month ago, I've probably lost a full day to red builds that were exactly this boring. It's not magic, one of the three I had to read properly because I wasn't sure the snapshot update was actually right, but it was right.

What does everyone else do with agent PRs that land red? Fix yourself, bounce back to the agent, or let the bot try first?

They merged a 9400 line PR out of Cursor on Friday afternoon. CI was green. Twenty minutes later staging was throwing 500s on the checkout endpoint, so I reverted it and left a comment saying what broke. Monday standup they go "you could have just pinged me to fix it" and call me a control freak in front of the whole team. The part that gets me is coderabbit / claude had actually flagged the null path in review and they resolved the thread without changing anything, so I don't know what is supposed to catch this if not me. Is revert first and ask after actually rude now? I just wanted main to work.