5 ms·

Code review is part of the job, but one of the least enjoyable parts. Developers like _writing_ and that gives the most job satisfaction. AI tools are helpful,

Code review is part of the job, but one of the least enjoyable parts. Developers like _writing_ and that gives the most job satisfaction. AI tools are helpful, but inherently increases the amount of code we have to review with more scrutiny than my colleagues because of how unpredictable - yet convincing - it can be. Why did we create tools that do the fun part and increase the non-fun part? Where are the "code-review" agents at?

cmrdporcupine 1y ago
If you have a paid Copilot membership and a Github project you can request a code review from Copilot. And it doesn't do a terrible job, actually.
- sublinear 1y ago
  I will second this. I believe code review agents and search summaries are the way forward for coding with LLMs. The ability to ignore AI and focus on solving the problems has little to do with "fun". If anything it leaves a human-auditable trail to review later and hold accountable devs who have gone off the rails and routinely ignored the sometimes genuinely good advice that comes out of AI. If humans don't have to helicopter over developers, that's a much bigger productivity boost than letting AI take the wheel. This is a nuance missed by almost everyone who doesn't write code or care about its quality.
phito 1y ago
Because the goal of "AI" is not to have fun, it's to solve problems and increase productivity. I have fun programming too, but you have to realize the world isn't optimizing make things more fun.
- fhd2 1y ago
  I hear you, but without any enjoyment in the process, quality and productivity go down the drain real fast. The Ironies of Automation paper is something I mention a lot, the core thesis is that making humans review / rubber stamp automation reduces their work quality. People just aren't wired to do boring stuff well.
  - skydhash 1y ago
    Enjoyment and rewards are the drivers for motivation.
    - fhd2 1y ago
      Yeah, though in my experience, reward alone is not enough.
- lapcat 1y ago
  > you have to realize the world isn't optimizing make things more fun. Serious question: why not? IMO it should be. If "progress" is making us all more miserable, then what's the point? Shouldn't progress make us happier? It feels like the endgame of AI is that the masses slave away for the profit of a few tech overlords.
  - cindyllm 1y ago
    [dead]
  - phito 1y ago
    As a human, I do agree that it would be better and we should strive for that. However I don't think humans are really driving all this progress/innovation. It is just evolution keeping doing what it's always done, it is ruthless and does not care at all whether we are having fun or not.
simonw 1y ago
> Where are the "code-review" agents at? OpenAI's Codex Cloud just added a new feature for code review, and their new GPT-5-Codex model has been specifically trained for code review: https://openai.com/index/introducing-upgrades-to-codex/ https://openai.com/index/introducing-upgrades-to-codex/ Gemini and Claude both have code review features that work via GitHub Actions: https://developers.google.com/gemini-code-assist/docs/review-github-code https://developers.google.com/gemini-code-assist/docs/review... and https://docs.claude.com/en/docs/claude-code/github-actions https://docs.claude.com/en/docs/claude-code/github-actions GitHub have their own version of this pattern too: https://github.blog/changelog/2025-04-04-copilot-code-review-now-generally-available/ https://github.blog/changelog/2025-04-04-copilot-code-review... There are also a whole lot of dedicated code review startups like https://coderabbit.ai/ https://coderabbit.ai/ and https://www.greptile.com/ https://www.greptile.com/ and https://www.qodo.ai/products/qodo-merge/ https://www.qodo.ai/products/qodo-merge/
- vrighter 1y ago
  you can't use a system with the exact same hallucination problem to check the work of another one just like it. Snake oil
  - bcrosby95 1y ago
    I don't think it's that simple. Fundamentally, unit tests are using the same system to write your invariants twice, it just so happens that they're different enough that failure in one tends to reveal a bug in another. You can't reasonably state this won't be the case with tools built for code review until the failure cases are examined. Furthermore a simple way to help get around this is by writing code with one product while reviewing the code with another.
    - jmull 1y ago
      > unit tests are using the same system to write your invariants twice For unit tests, the parts of the system that are the same are not under test, while the parts that are different are under test. The problem with using AI to review AI is that what you're checking is the same as what you're checking it with. Checking the output of one LLM with another brand probably helps, but they may also have a lot of similarities, so it's not clear how much.
KronisLV 1y ago
> Developers like _writing_ and that gives the most job satisfaction. Is it possible that this is just the majority and there’s plenty of folks that dislike actually starting from nothing and the endless iteration to make something that works, as opposed to have some sort of a good/bad baseline to just improve upon? I’ve seen plenty of people that are okay with picking up a codebase someone else wrote and working with the patterns and architecture in there BUT when it comes to them either needing to create new mechanisms in it or create an entirely new project/repo it’s like they hit a wall - part of it probably being friction, part not being familiar with it, as well as other reasons. > Why did we create tools that do the fun part and increase the non-fun part? Where are the "code-review" agents at? Presumably because that’s where the most perceived productivity gain is in. As for code review, there’s CodeRabbit, I think GitLab has their thing (Duo) and more options are popping up. Conceptually, there’s nothing preventing you from feeding a Git diff into RooCode and letting it review stuff, alongside reading whatever surrounding files it needs.
- aleph_minus_one 1y ago
  > I’ve seen plenty of people that are okay with picking up a codebase someone else wrote and working with the patterns and architecture in there BUT when it comes to them either needing to create new mechanisms in it or create an entirely new project/repo it’s like they hit a wall - part of it probably being friction, part not being familiar with it, as well as other reasons. For me, it's exactly the opposite: I love to build things from "nothing" (if I had the possibility, I would even like to write my own kernel that is written in a novel programming language developed by me :-) ). On the other hand, when I pick up someone else's codebase, I nearly always (if it was not written by some insanely smart programmer) immediately find it badly written. In nearly al cases I tend to be right in my judgements (my boss agrees), but I am very sensitive to bad code, and often ask myself how the programmer who wrote the original code did not yet commit seppuku, considering how much of a shame the code is. Thus: you can in my opinion only enjoy picking up a codebase someone else wrote if you are incredibly tolerant of bad code.
aleph_minus_one 1y ago
> Code review is part of the job, but one of the least enjoyable parts. Developers like _writing_ and that gives the most job satisfaction. At least for me, what gives the most satisfaction (even though this kind of satisfaction happens very rarely) if I discover some very elegant structure behind whatever has to be implemented that changes the whole way how you thought about programming (oroften even about life) for decades.
- marklubi 1y ago
  > what gives the most satisfaction (even though this kind of satisfaction happens very rarely) if I discover some very elegant structure behind whatever has to be implemented that changes the whole way how you thought about programming A number of years ago, I wrote a caching/lookup library that is probably some of the favorite code I've ever created. After the initial configuration, the use was elegant and there was really no reason not to use it if you needed to query anything that could be cached on the server side. Super easy to wrap just about any code with it as long as the response is serializable. CachingCore.Instance.Get(key, cacheDuration, () => { /* expensive lookup code here */ }); Under the hood, it would check the preferred caching solution (e.g., Redis/Memcache/etc), followed by less preferred options if the preferred wasn't available, followed by the expensive lookup if it wasn't found anywhere. Defaulted to in-memory if nothing else was available. If the data was returned from cache, it would then compare the expiration to the specified duration... If it was getting close to various configurable tolerances, it would start a new lookup in the background and update the cache (some of our lookups could take several minutes*, others just a handful of seconds). The hardest part was making sure that we didn't cause a thundering herd type problem with looking up stuff multiple times... in-memory cache flags indicating lookups in progress so we could hold up other requests if it failed through and then let them know once it's available. While not the absolute worst case scenario, you might end up making the expensive lookups once from each of the servers that use it if the shared cache isn't available. * most of these have a separate service running on a schedule to pre-cache the data, but things have a backup with this method.
mercutio2 1y ago
Junior developers love writing code. Senior developers love removing code. Code review is probably my favorite part of the job, when there isn’t a deadline bearing down on me for my own tasks. So I don’t really agree with your framing. Code reviews are very fun.
jmcodes 1y ago
Maybe I'm weird but I don't actually enjoy the act of _writing_ code. I enjoy problem solving and creating something. I enjoy decomposing systems and putting them back together in a better state, but actually manually typing out code isn't something I enjoy. When I use an LLM to code I feel like I can go from idea to something I can work with in much less time than I would have normally. Our codebase is more type-safe, better documented, and it's much easier to refactor messy code into the intended architecture. Maybe I just have lower expectations of what these things can do but I don't expect it to problem solve. I expect it to be decent at gathering relevant context for me, at taking existing patterns and re-applying them to a different situation, and at letting me talk shit to it while I figure out what actually needs to be done. I especially expect it to allow me to be lazy and not have to manually type out all of that code across different files when it can just generate them it in a few seconds and I can review each change as it happens.
- skydhash 1y ago
  Code is the ultimate fact checker, where what you write is what gets done. Specs are well written wishes.
  - jmcodes 1y ago
    Yes, hence tests, linters, and actually verifying the changes it is making. You can't trust anything the LLM writes. It will hallucinate or misunderstand something at some point if your task gets long. But that's not the point, I'm not asking it to solve things for me. I'm using it to get faster at building my own understanding of the problem, what needs to get done, and then just executing the rote steps I've already figured out. Sometimes I get lucky and the feature is well defined enough just from the context gathering step that the implementation is literally just be hitting the enter key as I read the edits it wants to make. Sometimes I have to interrupt it and guide it a bit more as it works. Sometimes I realize I misunderstood something as it's thinking about what it needs to do. One-shotting or asking the LLM to think for you is the worst way to use them.
- kiitos 1y ago
  the time spent literally typing code into an editor is never the bottleneck in any competently-run project if the act of writing code is something you consider a burden rather than a joy then my friend you are in the wrong profession
crazygringo 1y ago
> Developers like _writing_ and that gives the most job satisfaction. Not me. I enjoy figuring out the requirements, the high-level design, and the clever approach that will yield high performance, or reuse of existing libraries, or whatever it is that will make it an elegant solution. Once I've figured all that out, the actual process of writing code is a total slog. Tracking variables, remembering syntax, trying to think through every edge case, avoiding off-by-one errors. I've gone from being an architect (fun) to slapping bricks together with mortar (boring). I'm infinitely happier if all that can be done for me, everything is broken out into testable units, the code looks plausibly correct, and the unit tests for each function cover all cases and are demonstrably correct.
- pmg101 1y ago
  You don't really know if the system design you've architected in your mind is any good though, do you, until you've actually tried coding it. Discovering all the little edge cases at that point is hard work ("a total slog") because it's where you find out where the flaws in your thinking were, and how your beautifully imagined abstractions fall down. Then after going back and forth between thinking about it and trying to build it a few times, after a while you discover the real solution. Or at least that's how it's worked for me for a few decades, everyone might be different.
  - esafak 1y ago
    He did not say he does not iterate! And it is much easier and faster to do when an LLM is involved.
- skydhash 1y ago
  > Tracking variables, remembering syntax, That's why you have short functions so you don't have to track that many variable. And use symbol completion (a standard in many editors). > trying to think through every edge case, avoiding off-by-one errors. That is designing, not coding. Sometimes I think of an edge case, but I'm already on a task that I'd like to finish, so I just add a TODO comment. Then at least before I submit the PR, I ripgrep the project for this keyword and other. Sometimes the best design is done by doing. The tradeoffs become clearer when you have to actually code the solution (too much abstraction, too verbose, unwieldy,...) instead of relying on your mind (everything seems simpler)
dearilos 1y ago
I'm building something to solve exactly that - automating all the boring and repetitive parts of code review.

cmrdporcupine 1y ago

If you have a paid Copilot membership and a Github project you can request a code review from Copilot. And it doesn't do a terrible job, actually.

sublinear 1y ago
I will second this. I believe code review agents and search summaries are the way forward for coding with LLMs. The ability to ignore AI and focus on solving the problems has little to do with "fun". If anything it leaves a human-auditable trail to review later and hold accountable devs who have gone off the rails and routinely ignored the sometimes genuinely good advice that comes out of AI. If humans don't have to helicopter over developers, that's a much bigger productivity boost than letting AI take the wheel. This is a nuance missed by almost everyone who doesn't write code or care about its quality.

phito 1y ago

Because the goal of "AI" is not to have fun, it's to solve problems and increase productivity. I have fun programming too, but you have to realize the world isn't optimizing make things more fun.

fhd2 1y ago
I hear you, but without any enjoyment in the process, quality and productivity go down the drain real fast. The Ironies of Automation paper is something I mention a lot, the core thesis is that making humans review / rubber stamp automation reduces their work quality. People just aren't wired to do boring stuff well.
- skydhash 1y ago
  Enjoyment and rewards are the drivers for motivation.
  - fhd2 1y ago
    Yeah, though in my experience, reward alone is not enough.
lapcat 1y ago
> you have to realize the world isn't optimizing make things more fun. Serious question: why not? IMO it should be. If "progress" is making us all more miserable, then what's the point? Shouldn't progress make us happier? It feels like the endgame of AI is that the masses slave away for the profit of a few tech overlords.
- cindyllm 1y ago
  [dead]
- phito 1y ago
  As a human, I do agree that it would be better and we should strive for that. However I don't think humans are really driving all this progress/innovation. It is just evolution keeping doing what it's always done, it is ruthless and does not care at all whether we are having fun or not.

simonw 1y ago

> Where are the "code-review" agents at? OpenAI's Codex Cloud just added a new feature for code review, and their new GPT-5-Codex model has been specifically trained for code review: https://openai.com/index/introducing-upgrades-to-codex/ https://openai.com/index/introducing-upgrades-to-codex/ Gemini and Claude both have code review features that work via GitHub Actions: https://developers.google.com/gemini-code-assist/docs/review-github-code https://developers.google.com/gemini-code-assist/docs/review... and https://docs.claude.com/en/docs/claude-code/github-actions https://docs.claude.com/en/docs/claude-code/github-actions GitHub have their own version of this pattern too: https://github.blog/changelog/2025-04-04-copilot-code-review-now-generally-available/ https://github.blog/changelog/2025-04-04-copilot-code-review... There are also a whole lot of dedicated code review startups like https://coderabbit.ai/ https://coderabbit.ai/ and https://www.greptile.com/ https://www.greptile.com/ and https://www.qodo.ai/products/qodo-merge/ https://www.qodo.ai/products/qodo-merge/

vrighter 1y ago
you can't use a system with the exact same hallucination problem to check the work of another one just like it. Snake oil
- bcrosby95 1y ago
  I don't think it's that simple. Fundamentally, unit tests are using the same system to write your invariants twice, it just so happens that they're different enough that failure in one tends to reveal a bug in another. You can't reasonably state this won't be the case with tools built for code review until the failure cases are examined. Furthermore a simple way to help get around this is by writing code with one product while reviewing the code with another.
  - jmull 1y ago
    > unit tests are using the same system to write your invariants twice For unit tests, the parts of the system that are the same are not under test, while the parts that are different are under test. The problem with using AI to review AI is that what you're checking is the same as what you're checking it with. Checking the output of one LLM with another brand probably helps, but they may also have a lot of similarities, so it's not clear how much.

KronisLV 1y ago

> Developers like _writing_ and that gives the most job satisfaction. Is it possible that this is just the majority and there’s plenty of folks that dislike actually starting from nothing and the endless iteration to make something that works, as opposed to have some sort of a good/bad baseline to just improve upon? I’ve seen plenty of people that are okay with picking up a codebase someone else wrote and working with the patterns and architecture in there BUT when it comes to them either needing to create new mechanisms in it or create an entirely new project/repo it’s like they hit a wall - part of it probably being friction, part not being familiar with it, as well as other reasons. > Why did we create tools that do the fun part and increase the non-fun part? Where are the "code-review" agents at? Presumably because that’s where the most perceived productivity gain is in. As for code review, there’s CodeRabbit, I think GitLab has their thing (Duo) and more options are popping up. Conceptually, there’s nothing preventing you from feeding a Git diff into RooCode and letting it review stuff, alongside reading whatever surrounding files it needs.

aleph_minus_one 1y ago
> I’ve seen plenty of people that are okay with picking up a codebase someone else wrote and working with the patterns and architecture in there BUT when it comes to them either needing to create new mechanisms in it or create an entirely new project/repo it’s like they hit a wall - part of it probably being friction, part not being familiar with it, as well as other reasons. For me, it's exactly the opposite: I love to build things from "nothing" (if I had the possibility, I would even like to write my own kernel that is written in a novel programming language developed by me :-) ). On the other hand, when I pick up someone else's codebase, I nearly always (if it was not written by some insanely smart programmer) immediately find it badly written. In nearly al cases I tend to be right in my judgements (my boss agrees), but I am very sensitive to bad code, and often ask myself how the programmer who wrote the original code did not yet commit seppuku, considering how much of a shame the code is. Thus: you can in my opinion only enjoy picking up a codebase someone else wrote if you are incredibly tolerant of bad code.

aleph_minus_one 1y ago

> Code review is part of the job, but one of the least enjoyable parts. Developers like _writing_ and that gives the most job satisfaction. At least for me, what gives the most satisfaction (even though this kind of satisfaction happens very rarely) if I discover some very elegant structure behind whatever has to be implemented that changes the whole way how you thought about programming (oroften even about life) for decades.

marklubi 1y ago
> what gives the most satisfaction (even though this kind of satisfaction happens very rarely) if I discover some very elegant structure behind whatever has to be implemented that changes the whole way how you thought about programming A number of years ago, I wrote a caching/lookup library that is probably some of the favorite code I've ever created. After the initial configuration, the use was elegant and there was really no reason not to use it if you needed to query anything that could be cached on the server side. Super easy to wrap just about any code with it as long as the response is serializable. CachingCore.Instance.Get(key, cacheDuration, () => { /* expensive lookup code here */ }); Under the hood, it would check the preferred caching solution (e.g., Redis/Memcache/etc), followed by less preferred options if the preferred wasn't available, followed by the expensive lookup if it wasn't found anywhere. Defaulted to in-memory if nothing else was available. If the data was returned from cache, it would then compare the expiration to the specified duration... If it was getting close to various configurable tolerances, it would start a new lookup in the background and update the cache (some of our lookups could take several minutes*, others just a handful of seconds). The hardest part was making sure that we didn't cause a thundering herd type problem with looking up stuff multiple times... in-memory cache flags indicating lookups in progress so we could hold up other requests if it failed through and then let them know once it's available. While not the absolute worst case scenario, you might end up making the expensive lookups once from each of the servers that use it if the shared cache isn't available. * most of these have a separate service running on a schedule to pre-cache the data, but things have a backup with this method.

mercutio2 1y ago

Junior developers love writing code. Senior developers love removing code. Code review is probably my favorite part of the job, when there isn’t a deadline bearing down on me for my own tasks. So I don’t really agree with your framing. Code reviews are very fun.

jmcodes 1y ago

Maybe I'm weird but I don't actually enjoy the act of _writing_ code. I enjoy problem solving and creating something. I enjoy decomposing systems and putting them back together in a better state, but actually manually typing out code isn't something I enjoy. When I use an LLM to code I feel like I can go from idea to something I can work with in much less time than I would have normally. Our codebase is more type-safe, better documented, and it's much easier to refactor messy code into the intended architecture. Maybe I just have lower expectations of what these things can do but I don't expect it to problem solve. I expect it to be decent at gathering relevant context for me, at taking existing patterns and re-applying them to a different situation, and at letting me talk shit to it while I figure out what actually needs to be done. I especially expect it to allow me to be lazy and not have to manually type out all of that code across different files when it can just generate them it in a few seconds and I can review each change as it happens.

skydhash 1y ago
Code is the ultimate fact checker, where what you write is what gets done. Specs are well written wishes.
- jmcodes 1y ago
  Yes, hence tests, linters, and actually verifying the changes it is making. You can't trust anything the LLM writes. It will hallucinate or misunderstand something at some point if your task gets long. But that's not the point, I'm not asking it to solve things for me. I'm using it to get faster at building my own understanding of the problem, what needs to get done, and then just executing the rote steps I've already figured out. Sometimes I get lucky and the feature is well defined enough just from the context gathering step that the implementation is literally just be hitting the enter key as I read the edits it wants to make. Sometimes I have to interrupt it and guide it a bit more as it works. Sometimes I realize I misunderstood something as it's thinking about what it needs to do. One-shotting or asking the LLM to think for you is the worst way to use them.
kiitos 1y ago
the time spent literally typing code into an editor is never the bottleneck in any competently-run project if the act of writing code is something you consider a burden rather than a joy then my friend you are in the wrong profession

crazygringo 1y ago

> Developers like _writing_ and that gives the most job satisfaction. Not me. I enjoy figuring out the requirements, the high-level design, and the clever approach that will yield high performance, or reuse of existing libraries, or whatever it is that will make it an elegant solution. Once I've figured all that out, the actual process of writing code is a total slog. Tracking variables, remembering syntax, trying to think through every edge case, avoiding off-by-one errors. I've gone from being an architect (fun) to slapping bricks together with mortar (boring). I'm infinitely happier if all that can be done for me, everything is broken out into testable units, the code looks plausibly correct, and the unit tests for each function cover all cases and are demonstrably correct.

pmg101 1y ago
You don't really know if the system design you've architected in your mind is any good though, do you, until you've actually tried coding it. Discovering all the little edge cases at that point is hard work ("a total slog") because it's where you find out where the flaws in your thinking were, and how your beautifully imagined abstractions fall down. Then after going back and forth between thinking about it and trying to build it a few times, after a while you discover the real solution. Or at least that's how it's worked for me for a few decades, everyone might be different.
- esafak 1y ago
  He did not say he does not iterate! And it is much easier and faster to do when an LLM is involved.
skydhash 1y ago
> Tracking variables, remembering syntax, That's why you have short functions so you don't have to track that many variable. And use symbol completion (a standard in many editors). > trying to think through every edge case, avoiding off-by-one errors. That is designing, not coding. Sometimes I think of an edge case, but I'm already on a task that I'd like to finish, so I just add a TODO comment. Then at least before I submit the PR, I ripgrep the project for this keyword and other. Sometimes the best design is done by doing. The tradeoffs become clearer when you have to actually code the solution (too much abstraction, too verbose, unwieldy,...) instead of relying on your mind (everything seems simpler)

dearilos 1y ago

I'm building something to solve exactly that - automating all the boring and repetitive parts of code review.