Not sure how much experience you have, but I’m 25+ years at this point.
Just make sure the project is well structured and things are put in the right place so you can at least get the gist of a chunk of code’s purpose. Then drill down as needed adding fidelity to your understanding. There is no secret sauce here other than practicing reading lots of code.
For very large change sets (because your coworker is a lazy fuck), mentally pick out the automated shit like variable/function/class renames, function/interface abstraction, basically whatever your IDE can do and discard them. That is just noise. For the rest, start with their commit message that should describe the change in sufficient detail and look specifically to validate its claim. It can help to ignore the diff and instead just checkout their branch and read through the finished code with all the nice things your IDE provides to follow calls, look up definitions, etc. and mentally/actually run the code to see evidence of the expected change.
The other thing you can/should do is tell him to break up his commits and direct the agent in smaller steps. I’ve legit done this in the before days to prolific peeps I’ve worked with. Believe it or not, the introduction of agile/sprints and all that nonsense helped to keep commits smaller simply because you don’t have time to keep a long lived branch. It was (and still is) good kata to layer your changes in commit-by-commit such that the mutation is a smooth, deployable gradient of incremental changes.
Heh, that’s another can of worms. The project is in a “get a bunch of stuff quickly” mode at the moment, and he’s taken to treating main like his personal codebase. Pushing to main, no comments. Even our Linear tasks he just marks as “complete” with no comments or context.
But yeah, I think the rest of your advice would work well if he was a bit more of a team player.
You need to isolate his work behind a well-defined interface and then ask yourself if Conway’s law works in both directions.
Seriously though, an interface is easier to test than a mess of spaghetti code, and also easier to replace the implementation when you eventually realise that vibe coders are a net-negative to any project.
Not sure how much experience you have, but I’m 25+ years at this point.
Just make sure the project is well structured and things are put in the right place so you can at least get the gist of a chunk of code’s purpose. Then drill down as needed adding fidelity to your understanding. There is no secret sauce here other than practicing reading lots of code.
For very large change sets (because your coworker is a lazy fuck), mentally pick out the automated shit like variable/function/class renames, function/interface abstraction, basically whatever your IDE can do and discard them. That is just noise. For the rest, start with their commit message that should describe the change in sufficient detail and look specifically to validate its claim. It can help to ignore the diff and instead just checkout their branch and read through the finished code with all the nice things your IDE provides to follow calls, look up definitions, etc. and mentally/actually run the code to see evidence of the expected change.
The other thing you can/should do is tell him to break up his commits and direct the agent in smaller steps. I’ve legit done this in the before days to prolific peeps I’ve worked with. Believe it or not, the introduction of agile/sprints and all that nonsense helped to keep commits smaller simply because you don’t have time to keep a long lived branch. It was (and still is) good kata to layer your changes in commit-by-commit such that the mutation is a smooth, deployable gradient of incremental changes.
TL;DR: Tell him to quit being fuckin lazy.
Heh, that’s another can of worms. The project is in a “get a bunch of stuff quickly” mode at the moment, and he’s taken to treating main like his personal codebase. Pushing to main, no comments. Even our Linear tasks he just marks as “complete” with no comments or context.
But yeah, I think the rest of your advice would work well if he was a bit more of a team player.
You need to isolate his work behind a well-defined interface and then ask yourself if Conway’s law works in both directions.
Seriously though, an interface is easier to test than a mess of spaghetti code, and also easier to replace the implementation when you eventually realise that vibe coders are a net-negative to any project.