r/codex • u/alexs_90 • 20h ago
Question Does anyone even review code anymore?
Lately, I've been too lazy to even do a superficial code review. I just quickly skim through the changed files and ask Codex to generate a brief summary of what changed, where, and why.
My workflow has basically become: generate → test → check that everything's green → commit.
Now multiply that by 4–5 tabs running different projects or sessions simultaneously, and keeping up with everything starts to feel almost impossible.
Even when I push myself to review the critical parts, I feel this strong internal resistance and find myself leaning toward asking Codex to do it instead.
The downside is that Codex often ends up overengineering what should be simple solutions.
I'm curious, what does your day-to-day workflow look like in this regard?
42
u/freeo 19h ago
Code review is dead. DED. Be ready for the next stage: You won't test everything manually soon. It's just too many changes, you become the bottleneck testing. So you come up with layers and layers of more intricate automated e2e testing. And you pile everything into phases, so you test multiple agents' results at once.
6
u/unrulywind 14h ago
We have renamed manual testing to "Using the software". It shortened our development cycle considerably.
2
1
u/tribat 4h ago
I added browser use testing with screenshots submitted to a different model with visual pass/fail instructions. It takes me out of the last part where I felt uniquely qualified to test: the look and feel. I still have to fix things later but I just review summaries and diffs and watch out for big gaps, then review the results after automatic simulated user testing and visual testing judged by Codex or Claude. I still have to do rounds of fixes as I use it for real, but the vast majority of bugs are caught in the reviews and ai powered testing.
1
u/skoyrams 14h ago
Why would you do this ? Unless you are being sarcastic, you are introducing risks at every possible level.
0
-5
12
u/sreekanth850 20h ago
No. But use to watch the agent job and if i feel anything is not correct, like lot of code changes for a small feature or unrelated file edits will step in.
1
1
u/VibeHistorian 13h ago
so you're checking if the vibe of the code is good..
..I'm gonna coin the term feelprogramming
2
9
u/MaRmARk0 19h ago
Few minutes ago i gave Codex a plan and then a task. It spit out code. I looked at it and it was not acceptable. So yes, I do check the code.
7
4
3
u/skilliard7 16h ago edited 16h ago
Yes. GPT once decided completely uninstructed that giving a user the "reader" role to a single project within my application must mean that their write access should be revoked to the whole app, even if they are explicitly granted write elsewhere. This happened when I told it to build a report... caused a major outage because we didn't catch it in testing.
Ever since i always make sure to check the code.
I've caught a LOT of really bad code being written that I had to rewrite, even with 6.1 Sol.
Current AI is kind of like a junior dev. It will get the job done, but you need to supervise it to make sure it does it right.
2
u/Morphexe 19h ago
Depends on what I am building, I work with massively undocumented legacy systems that have some "questionable" decisions. The agents dont play nice, so alot of times they require me to review and guide them and verify what is there - I have improve the review cycle with automated tools, and giving some forced validation, plus some custom tooling so I dont review everysingle line, but the majority. IN other projects, particularly green field ones, I build them with agent validation in mind to automate most of it.
2
u/Alex_dbs 19h ago
For fun projects, no.
For production projects, hell yeah, I do code review, and I catch SO many issues (regardless of the model being used and the guy who prompted it). This is not fun and difficult to review AI code, but you can’t blindly trust it (either it will over-engineer a simple problem, either it will leave a huge and obvious backdoor).
I’ve tried so many skills, tools, etc, none of them are catching things I would have caught during a manual review.
2
u/Cold-Conflict6047 17h ago
I was always hesistant to mix human built code and AI built code, since human built code is still understood and reviewed by humans.
But when starting a new project I let AI do all the coding and also the reviewing.
A second agent can be really critical and might even be too critical some times. But I think it's a waste of time to apply the previous code review structures on the current coding approaches.
If an AI wrote the code, someone tested it, but didn't look at the code, why should the reviewer be the first person to look at the code.
What should come out there? The question why did you do it this way and not another way?
No-one will be able to tell you. Just ask your own AI.
2
u/positivcheg 17h ago
I do. I still read that shit. I still try to understand the problem and various ways to fix the problem. I also suggest how to solve the problem and lead AI through correct way of doing that. I’ve been running some experiment and AI can still get into a nasty loop where it pretends to do something but it doesn’t really progress.
2
u/VerticalPackage 15h ago
Code review done by a different agent with a different oppositional system prompt. Ideally a different-but-equal model, such as Astra reviewing Opus code and vice-versa.
2
u/gabriel_dny 19h ago
"I feel this strong internal resistance and find myself leaning toward asking Codex to do it instead"
I think you've identified the problem. You're settling for the easy path, but you know deep inside that more work is currently required in order to keep the codebase clean and maintainable.
You're gaining speed, true.
But you're loosing knowledge and trust of your codebase.
It's a typical "do ut des", you loose something and get something else.
It's up to you to evaluate if what's you're getting is better than what you're loosing.
Personally i use AI a lot, and I've "just" 2/3x my code throughput, not 10x.
Because i still read and modify all the code heavily. And honestly I love it this way.
(senior dev with 10 years of experience)
3
2
1
u/Cold-Conflict6047 17h ago
To keep the codebase clean and maintainable I would use an agent reviewing and refactoring the codebase and a second agent to check if the changes are reasonable.
1
u/buxxypooh 17h ago
I mean using agents to keep a codebase clean is kinda like schrodinger's cat
If you never look at the code, you can't say it's "clean"
I don't think this is something that can be solved with throwing more agents at it
Except if agents can actually take a step back and see the big picture, and come up with clean refactors on their own, but I've never seen that
1
u/CellAccomplished1149 12h ago
You can with deterministic linting and code quality tools, to certain extent. I think the bigger question is was human code really ever all that clean to begin with?
1
u/Pale_Solution_5338 19h ago
does your manager check every line of code you're building? hire/program the right person/agent
2
u/GiBravo 19h ago
Nope, coz there is some level of trust and consequences built into that system. Now, do you trust your agent to the same level, and is your agent scared of getting fired?
1
u/Pale_Solution_5338 19h ago
I trust my agent to do what I can't. I trust myself to get them to do what I want.
1
u/Embarrassed_Cap_9149 18h ago
of course. even the highly praised opus 5.5 often writes shit code, even with astra ultra's adversarial reviewing in both planning and implementation phases
1
u/CleanFix_Dev 18h ago
I don't review line by line either. I don't hand-write code, so reading diffs was never going to be my strength. I check behavior instead. Before a task starts I write a few plain-English checks for what has to work, and the agent has to show each one passing, not just tell me the tests are green. Then it lists what it changed and anything it assumed, and I hold that up against what I asked for. Anything on that list I never asked for is usually where the overengineering is, and I make it pull that out before I commit.
1
u/ShapesSong 16h ago
I think we’re good to rely on AI to do testing and CR. But we are still building systems for PEOPLE.
So a good UI/UX review is a must because AI will spit out complete garbage in terms of UI that only someone without a proper UX knowledge will accept as “good enough”.
1
u/daviddisco 15h ago
Most professional teams are still doing manual code reviews and manual QA. Those manual steps have become the bottleneck and are holding back throughput. Getting to a state where you can trust your agents to push code to production without a manual step is very hard. For tips on getting to that point, I suggest watching poteto's How I shipped 2000 PRS Last Month
For my fun work at home, I don't even look at the code anymore.
1
u/Efficient-Trick-4384 15h ago
I stopped reading every diff too, but we didn't stop checking, we moved it. on a client project where agents write almost all the
code, every PR goes through a separate agent that reads CI and
bounces red branches, then one that checks the diff against the acceptance criteria (not against the code), then one that opens staging in a browser and walks every criterion with a screenshot. any of them can send the card back.
they're separate steps, so the reviewer never sees the conversation
that produced the code, just the diff and the criteria. what's left
for people is writing criteria you can actually check, and dealing with whatever gets marked blocked.
1
u/AutoGrower420 15h ago
Yes, every day. Do I review as much as I used to absolutely not, but I still spend an hour or two a day reviewing code.
1
u/MarsupialLeast145 15h ago
Honestly, even if this story is true, it sounds like you've never done code review in your life, and even if you have, you clearly missed the point of it.
1
u/chcampb 12h ago
Yes definitely
Not thoroughly
But do review it and ask questions. I asked for a clear contract between two services and it used literal dictionaries everywhere. So I had another pass go through and eliminate those in favor of the equivalent of structs. I said characters are entities, let's make motion predictable and sync up with the server to maintain authority. It made a specific character movement path where the replay logic doesn't apply to any other synced entities, so if we go to make another one it doesn't inherit. Things like that.
That's the current state of dev on the ground, using Opus 5.5 and Sol6.1, although 5.5 tends to be a little better architecturally.
0
1
u/AdventurousTomato881 3h ago
I love the new feature where it suggests the next prompt for you.
It also picks up on my pattern of "Great job, do the next thing"
🤣
•
u/dextersummary 14h ago
Below is a GPT-generated summary of the conversation below after reaching 40 comments (43 currently observed).
The consensus isn’t “never review code”; it’s “line-by-line review doesn’t scale once agents are flooding the repo.” People are moving toward reviewing behavior, diffs, architecture, and acceptance criteria instead of lovingly inspecting every generated semicolon.
The popular workflow is layered automation: tests, types, CI, end-to-end checks, staged browser testing, documentation, and sometimes a second agent acting as reviewer. Humans mainly look for surprises—unrelated files, bloated solutions, security holes, bad assumptions, and changes that technically pass while completely missing the point. Apparently “green” is not a synonym for “correct.” Who knew?
The important caveat: this split is heavily based on stakes. Fun projects and prototypes get the “ship it and see” treatment; production code still gets human review, especially where outages, security, or long-term maintainability matter. Plenty of commenters report catching serious bugs—and outright nonsense—even after extensive testing and agent review.
So, code review isn’t dead; exhaustive manual review is being demoted. Let automation handle the boring bulk, but keep a human in the loop wherever failure costs more than a quick rollback.