Haven’t read the article, but can anyone with more software experience let me know how you’re supposed to collaborate with someone who uses AI to code? I’m working with a vibe coder for the first time. As far as I can tell, his code is all great, but the dude checks in like 3,000 lines at a time. How am I supposed to have any understanding of a codebase that grows and changes that quickly?
Literally “this is a small, simple feature. It should take something like 200 (or 10, or 50) lines to implement. 3000 tells me you didn’t think carefully enough”
Or “you have a bug here, a bug here, another here. This is where I stopped. Ask me back when it’s ready for review”
I promise you that their code is not all great. It takes an order of magnitude more effort to refute bullshit than produce it. Refute part, then don’t engage with the rest. They’ll get the message.
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.
Haven’t read the article, but can anyone with more software experience let me know how you’re supposed to collaborate with someone who uses AI to code? I’m working with a vibe coder for the first time. As far as I can tell, his code is all great, but the dude checks in like 3,000 lines at a time. How am I supposed to have any understanding of a codebase that grows and changes that quickly?
Reject their patches.
Literally “this is a small, simple feature. It should take something like 200 (or 10, or 50) lines to implement. 3000 tells me you didn’t think carefully enough”
Or “you have a bug here, a bug here, another here. This is where I stopped. Ask me back when it’s ready for review”
I promise you that their code is not all great. It takes an order of magnitude more effort to refute bullshit than produce it. Refute part, then don’t engage with the rest. They’ll get the message.
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.