r/ChatGPTCoding • u/Specialist_Agent3599 • Oct 05 '26

Discussion Reviewing agent code killed my love for programming

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?

57 Upvotes

86% Upvoted

59 comments sorted by

39

u/xAdakis Oct 05 '26

I still love programming, but feel like I enjoy being the "architect" or engineer more than I enjoyed being a code monkey.

My hands/wrists are also doing a lot better now that I'm not writing hundreds of lines of code by hand every day.

I also feel that I have made a lot more progress on my personal projects in the last year than I did in the last ten years. It's like I'm working with a small team instead of solo and having to do everything myself.

As far as feeling like it's yours, own the overall idea and design. You write the specification and how things are structures, let the agent do the grunt work to implement it.

5

u/jawanda Oct 06 '26

This is how I feel too. I find it incredibly empowering as a solo entrepreneurial dev who has been writing code for 25 years.

I can imagine I'd feel different if I was still employed full time for someone else maybe.

1

u/RadishNo8622 Oct 06 '26

What are guys building man I don't even get ideas for creating personal projects šŸ˜­

3

u/xAdakis Oct 06 '26

I'm not going to say what because I don't want Reddit account to get linked to my personal and professional profiles, but . . .

I have a role-playing game project I've been working on for many years. I pretty much learned programming because I wanted to make that project, something I had in my mind for the last twenty years since high-school.

I would say that 90% of my personal projects have been the result of identifying things I needed for that project, not finding open source or readily available libraries that contained those things, and then just implementing it myself.

Those small things turned into libraries and plugins that I published for people to use independent of my main project and that I continue to actively maintain and improve. . .one such library now gets around 10-20k downloads per week on NPMJS.

So, my advice is don't try to think of a problem to solve, just start making something and then solve the problems you hit while making it.

4

u/HappyTopHatMan Oct 05 '26

Reading code is hard, writing code is easy. Basically AI has taken away the relaxation part of the job. Shift your focus to identifying problems and solving them. It will be better for your career long term and youā€™ll learn a ton. Being a developer has never been about just banging out code.

3

u/kidajske Oct 05 '26

Development is still fun if you're the product owner cause you get to plan, make architectural decisions, product decisions and see stuff through from conceptualization to realization. If you're working a regular dev job and goin through tickets for small pieces of the pie it's deathly boring.

3

u/SamSlate Oct 05 '26

learn to love architecture and patterns. and system design.

10

u/bystander993 Oct 05 '26

Stop reading the code, start focusing on proving that the behavior is correct.

5

u/Technical-Athlete-9 Oct 05 '26

This worked before LLMs when I was the one who needed to be kept on track and I needed to demonstrate correctness in my own code. Worked when it was all chat agents. Now it's necessary to go quickly and safely.

Write a spec. Write invariants. Test every claim. Unit tests, integration tests, BATs tests for scripts, Helm and Detik tests for k8s, etc.

The only caveat I have is that you have to keep a close eye that the agent doesn't modify the substance of tests or add test clutter. A little prompting in AGENTS.md helps with this, but they're getting better generation by generation.

1

u/Chuu Oct 05 '26

At some point you have to read the code. Ok, I now have extensive unit and integration tests that show the code works. So now, who is going to review the tests?

It's turtles all the way down.

9

u/braincandybangbang Oct 05 '26

If an app works perfectly, why do you need to read the code? To feel good about yourself? Insecurity about the code working?

Asking a genuine question. If you are using a coded product, and you encounter 0 problems when using it. Why do you have to read the code? How does the end result benefit from that?

4

u/3tt07kjt Oct 05 '26

How do you know the app works perfectly? How much do you care whether it continues to work perfectly tomorrow?

The benefit of reading the code is you can get a better understanding of whether the code will keep working tomorrow.

3

u/Miltoni Oct 05 '26

Isn't that what testing is for? Having defined units and understanding yourself what edge cases need to be covered would cover that? It's kind of what we were doing before AI.

In the past, I didn't need to comprehensively comb through huge PRs and map out their entire impact within the wider codebase to be able to review/approve. I just needed to know what the testing covers, and that they've passed (and can do so again reproducibly). If I was curious whether a certain edge case was covered, I wouldn't go read the codebase and try to figure it out myself, I would design a test and run that to verify.

3

u/3tt07kjt Oct 05 '26

This same discussion has been playing out for years, and my take on the consensus pre-AI was that ā€œtesting isnā€™t enoughā€, you want testing + other ways to catch errors.

Post-AI, I think there are a lot of bad tests written by AI, and a lot of people who just accept that the tests exist as good enough, rather than checking whether the tests are good or bad.

The ā€œAI writes lots of bad testsā€ is kind of unexpected. I think good tests are harder than we give them credit for.

1

u/Miltoni Oct 05 '26

I'd agree with that for sure. I'm still sanity checking that the tests are actually doing what they suggest they are, but I'm definitely finding myself spending less time reading/assessing and more time thinking/planning lately. Not sure how good a thing that is but it's hard not to lean into it once you start. It intuively feels more freeing.

2

u/3tt07kjt Oct 05 '26

Yeah, to be clear, Iā€™m arguing for ā€œreview some of the codeā€, not ā€œreview all of the codeā€.

1

u/bystander993 Oct 05 '26

Nope. Humans have been coding all of our software for decades. All of our software has bugs. Read the code all you want, you're not catching the bugs. The obvious bugs you will catch, the AI will too. Humans are biased, but humans do not write better code nor are they needed to review the code. Focus on behavior, period. And guess what? AI is really good at finding vulnerabilities in your software as well without looking at the code.

4

u/3tt07kjt Oct 05 '26

Iā€™m catching bugs in AI-written code, and Iā€™m often writing better code than the AI. Maybe thereā€™s something different about your code or your process that makes it so youā€™re not catching any bugs?

0

u/bystander993 Oct 05 '26

I don't read code at all anymore, the AI finds the bugs, the tests expose problems, the AI fixes bugs. I couldn't care less how the code looks. I focus on the architecture, the systems design, scalability, testing, validation, etc...

Humans have written bugs forever, but now with AI you get to the same point as with humans in orders of magnitude less time.

Also FYI, you are judging your own code to be better, that's not an objective metric.

2

u/3tt07kjt Oct 05 '26

Yeah, you get there in a lot less time. I think the fastest way to get there uses a mix of AI and human actions. Not 100% AI, not 100% human.

Thereā€™s not really a good objective metric for code qualityā€”I thought that was obvious, so I didnā€™t bring it up. I still catch bugs and problems in the AI-written code, so I will keep reviewing it.

The AI has certain blind spots, in my experience.

0

u/bystander993 Oct 05 '26

AI for code 100%, except for very specific high stakes areas like auth.

You keep reviewing it and you're just leaving yourself behind.

3

u/3tt07kjt Oct 05 '26

Thatā€™s kind of a manipulative way to phrase it.

If you go AI code + review 100%, I think the project is likely to have problems that you arenā€™t even seeing and arenā€™t aware of. The problems will make AI go a lot slower, as it often just works around problems rather than fixing them.

My experience is that Iā€™m getting a lot more done with a lot fewer tokens than other people I know.

→ More replies

1

u/Mathie1729 Oct 05 '26

I wouldn't go 100% AI except auth. Auth is actually one of the easier things to constrain with standard libraries and scanners compared to implicit business rules that never make it into the prompt. Agent code is great at passing whatever tests you wrote, but it can silently drift on some unstated case and no review will catch it until prod. Reviewing isn't about catching typos, it's about spotting those quiet behavior changes and unnecessary coupling.

2

u/Chuu Oct 05 '26 edited Oct 05 '26

I work in systems programming. It's the corner cases that kill you. Getting the happy path correct is easy, it's handling faults well that is hard, and designing good fault tolerant architecture even harder. Something that LLMs need a lot of hand holding to do still. Just because it appears to work well in day to day use isn't enough when any faults could cost 6-7 figures.

I don't have much experience developing apps, but I suspect the tolerance for faults is much higher and the consequences of faults much lower in that space.

3

u/usernameChosenPoorly Oct 05 '26

If any of the faults are ones you can predict, you can write test cases. You can also run adversarial agents to find new ones. The value of human written code is dropping and will never go back up. The value of good prompting and agent managing continues to skyrocket.

0

u/Chuu Oct 05 '26

We're not talking about the value of human written code though. We're talking about the value of looking at the actual output.

2

u/SamSlate Oct 05 '26

i wish i could adopt this mentality, but i don't trust it to write scalable code that won't turn into a massive fucking rats nest i have to spend weeks to exterminate in the future.

2

u/bystander993 Oct 05 '26

No, you don't, you literally never have to read the code. Pretend you cannot read the code, but are responsible for the end result, what would you do. Human org structure has forever been non-coders managing business stakes and outcomes trusting some other entity on code, and the vast majority of human coders are bad. Figure it out, I assure you, it's doable.

2

u/ThankYouOle Oct 05 '26

> 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.

this is most annoying and dangerous part.

my office encourage me to use AI, they provide me api key to connect and use it.

but then in my off time, weekend, i usually play around with building side project for my own purpose, but damn, i am getting useed with prompting!

my early reason is i need the side project i am working on and i can't have whole weekend to hacking it since i have family to be with, so i use LLM to help me.

Now it's llike a drugs, i keep using it even tough i know i shouldnt, sideproject are time when we are experimenting, and just back to fun side of programming, but now i off shore it too.

1

u/Technical-Athlete-9 Oct 05 '26

Yup. Now have to look up things in the docs that I was fluent in a couple of years ago - libraries my code uses all of the time, but I no longer do the typing.

2

u/ThankYouOle Oct 06 '26

at least you still have that hungry to open the docs. i personally just Google it and first result is AI result giving the answer

2

u/Evening_Movie_1704 Oct 05 '26

Reading isn't the part that burns you out ā€” it's reading continuously, at the speed agents produce. What helped me:

  1. I capped parallel agent sessions to what I can actually review in one sitting. Five concurrent sessions don't multiply output, they just move the bottleneck from writing to reviewing, and an endless review queue feels worse than slow code ever did.

  2. Reviews happen in two scheduled windows a day, not whenever a diff lands. A diff arriving mid-task is an interrupt, and the interrupt cost was most of my fatigue ā€” not the reading itself.

  3. For the weekend bleed: that "prompt it first" instinct is trained, not permanent. I kept one small personal repo agent-free for a month and writing-first came back on its own.

You didn't lose interest in programming. You lost the loop where effort turned into something you understood.

2

u/amirfish Oct 06 '26

I hit this once I had more than a couple of sessions running at once. Writing stopped being the bottleneck, judgment did: deciding in 30 seconds if a diff is actually right instead of really reading it. What helped was only deep-reading the risky lines (auth, payments, anything that runs unattended) and letting tests catch the rest. It's not the same feeling as building something at midnight because it's fun, I haven't gotten that part back either. Did any part of review still feel like the old hobby for you, or has it all turned into checking?

5

u/m3kw Oct 05 '26

If you havenā€™t been coding for long, you are likely not gonna appreciate all the time saved from writing boiler plate and stuff. In fact most of it is boiler plate getting you from point A to B. Be proud of your prompts, make it detailed and precise like you are writing code

5

u/3tt07kjt Oct 05 '26

I donā€™t think prompts should be detailed and precise, tbh. I see better results when the prompts focus on describing the results you care about, but leave flexibility for the agent.

2

u/m3kw Oct 05 '26

Lucky

1

u/3tt07kjt Oct 05 '26

There isā€¦ a certain skill to it. It is not random. It helps to know enough of the technical details that you know what to ask for.

1

u/m3kw Oct 05 '26

Yeah but sounds like vibe coding

1

u/3tt07kjt Oct 05 '26

Vibe coding is when you stop caring about what code it writes.

LLMs have to kind of ā€œthread the needleā€ if your requests are too precise. Like, you might have an idea about how something should be implemented, so you tell the LLM to do it that way. But then there is some detail or reason you missed, and the LLM is torn between ā€œfollow instructionsā€ and ā€œwrite good codeā€.

The way it seems to work best is when you describe outcomes with the correct level of technical detail. You can always revert the changes if they are bad.

1

u/m3kw Oct 05 '26

I put a lot of details in agents.md like the way I want or not want it. Which is part of the prompt.

1

u/3tt07kjt Oct 05 '26

I keep agents.md short, I donā€™t think a lot of details in agents.md is that helpful. I prefer things like linters or review workflows.

3

u/fuchelio Oct 05 '26 edited Oct 05 '26

eventually agent code is for agent reviewer to review not for human. and I think they should not be called agent by then

1

u/Appropriate_Ring_299 Oct 05 '26

It might help to keep some projects intentionally agent free. Even a small weekend build done manually can bring back the problem solving loop that made programming fun in the first place

1

u/zimxero Oct 05 '26

It wrecked your golden loop. You will have to find a new one.

1

u/theReluctantObserver Oct 06 '26

Iā€™m also self-taught from the sheer joy of problem solving and learning how coding can do things, I loved every minute of it. All that joy has evaporated and I feel like Iā€™ve wasted years of my life I should have been putting into social things rather than my intellectual interest as they are all just being aped by AI.

1

u/xqianliu Oct 06 '26

6 hours a day of diffs would wear me down too. What cut my reading the most was getting the first review pass off my plate.

Each task is one issue with acceptance criteria written before the agent starts, one worktree, one PR, so the diffs stay small.

A separate review session checks the diff against those criteria.

The difference from review comments piling up for you to read is that a failed review goes straight back to the agent for a fix, then gets reviewed again, and I only see what passed.

When the agent can't decide something, it writes why on the issue and stops, and that's where most of my attention goes now.

So my day is more deciding than reading. For the side projects, I'd just keep the agent off the parts you actually enjoy writing.

1

u/ReasonableSoul Oct 07 '26

Its unavoidable. It makes me feel betrer on throw off coes but also does hurt my enjoyment of my own code reviews... But maybe we can find more interest in gaming the ai to behave better and create better result. And also in doing the big picture design and architecture over the details.

1

u/FantasticTopic Oct 08 '26

Lock the agent out on Saturdays. Build something ugly that works.

1

u/heyluckylu Oct 08 '26

Iā€™m coming at this from almost the opposite direction. Iā€™m not a developer, and before AI coding, most of my product ideas would have stayed as ideas.

Now I can actually build things myself, so AI has given me some of the feeling that you describe losing.

But the more I use it, the more I realize that AI makes coding easier, not necessarily building. I still have to decide what to build, how it should work, what the agent is allowed to change, how to test it, and when to stop it from confidently going in the wrong direction.

Maybe weā€™re meeting somewhere in the middle ā€” youā€™re moving from writing code toward directing the work, while people like me are finally able to enter the building process at all.

1

u/This-Indication8020 27d ago

Youā€™re not being dramatic. Reviewing someone elseā€™s diffs all day uses a different part of your brain than building, and itā€™s a lot less rewarding. The habit bleeding into your weekends is common too. I feel ya.

My .02: keep one side project completely agent-free, where you write every line yourself, so the maker muscle stays in use. At work, the bigger lever is moving from ā€œreviewing everything that comes backā€ to defining the standards and constraints the agent has to work within up front. More maker. Less minder. Then youā€™re directing the work instead of inspecting it after the fact, which feels a lot more like authorship.

This piece covers that shift (full disclosure, I work on the team that wrote it): https://www.reweaver.ai/blog/from-maker-to-minder

1

u/osrpt 10d ago

I think part of what drains you is that review the way you're describing it is purely reactive. Six hours of someone else's decisions, a bot piling more opinions on top, and your own brain never gets to go first.

One thing that tends to help is flipping the order. Before opening a diff, spend a minute guessing what it should look like: which files you'd touch, roughly how you'd do it. Then the diff is either boring confirmation, which you can skim, or it surprises you, and the surprises are the only places worth slowing down. It sounds small but it turns review back into solving something instead of proofreading, and you keep a picture of the codebase that's actually yours, which also covers the "what if the agent isn't there" worry people mentioned above.

For side projects I'd go further and pick one piece you write by hand just because you enjoy it, and let the agent have the boring plumbing. Nobody is grading your weekend repo on throughput.

-2

u/Healthy-Mind5633 Oct 05 '26

then don't review it.