Comment by orwin
6 days ago
I now started to us AI to help review my juniors PRs, because I couldn't keep up with the amount of code they ship. It started poorly, but now I have my method: I first read the code and flag the lines I'm not sure about, then ask any frontier model (I like Claude here for analysis, even if I don't use it for the rest) to explain the PR and to put effort on the parts I flagged (basically explain in detail the code, not only the PR), and to search through the libraries. Sometimes it notices something I would have missed (like missing an 'order_by' or off by one errors, because the underlying lib wasn't coded like the original AI pretended it was).
I also changed the way I do review because it has been more than a year and the juniors/new hire are still lost, wether on domain knowledge for the older new hire, or just capabilities for the juniors, and discussing with other departments, it's the same for like 95% of them. Now, rather than correcting the PR or adding a request for change, I add a whole unit/functional test to the PR and let that as an exercise to pass the test. They can use AI but I tell them to try to find what part of the code doesn't work before generating the fix, hopefully they'll take ownership of the code if I keep doing that.
>I tell them to try to find what part of the code doesn't work before generating the fix
this makes me kinda sad. they don't do this on their own? are they not even a little curious
even before AI very few developers cared about the actual craft. I'd say only about 3%. For a lot of people it's just a job, no matter if it's a corperate dev or a startup dev.
One of my customers now added a policy that junior developers may use AI assistance, but are expected to write code by hand. Only proven developers can use AI to generate code, and are then expected to understand the generated code, and take ownership.
> are they not even a little curious
Some are. Some aren't. Usually a good indicator of career trajectory.
It's a different mindset. Has nothing to do with curiosity.
For me and you, "fixing" something means finding which assumption was violated and redesigning the solution in light of that. Sometimes this means adding code, sometimes it means making the solution smaller.
For a lot of people, "fixing" means adding code to make it work. This always makes the solution larger.
The latter group can still be curious! But they're curious about which addition makes it work, not about their incorrect beliefs.
An engineer that refuses to understand how their craft is constructed is a poor engineer.
> For a lot of people, "fixing" means adding code to make it work.
What if the fix requires deleting a single line of code?
Is the additive fix to enshroud it in if (0) { } ?
2 replies →
Why are you paying them if they insist on remaining meat proxies?
"because the underlying lib wasn't coded like the original AI pretended it was"
So, the models ARE dumb. They just are very good at finding patterns in their training data. I mean, when they code minecraft clones, it is not because they can cook up how to write minecraft clones, rather, their training data includes a lot of minecraft-like games code, and they just reuse that.
Yes this is the reason they fail miserably when it comes to novel problems.
Wow, that painful AI aided review process, it's like you are computering with eyes closed.
where do u work that even hires juniors lol
[dead]