We require you to submit markdown plan before working on a feature, which must have full context, scope, implementation details. Also verification tests mardown file of happy path and critical failure modes that would affect customer, and how tests were performed. Must be checked in with the commit. More complex, large features require UML diagrams of architecture, sequences, etc. to be checked in too.
If your plan or verification docs have wrong context, missing obvious implementation flaws, bad coupling, architecture, interfaces, boundary conditions, missing test cases, etc then PR rejected.
Every developer’s performance is judged as a systems engineer. Thoughtless features without systems docs and continued lack of improvement in your systems thinking gets you PIPed.
That’s the thing though. Even if the code is good, the plans are good, the outputs are good, etc, it still devolves into chaos after some time.
If you use AI to generate a bunch of code you then don’t internalize it as if you wrote it. You miss out on reuse patterns and implementation details which are harder to catch in review than they are in implementation. Additionally, you don’t have anyone who knows the code like the back of their hand because (even if supervised) a person didn’t write the code, they just looked over it for correctness, and maybe modified it a little bit.
It’s the same reason why sometimes handwritten notes can be better for learning than typed notes. Yeah one is faster, but the intentionality of slowing down and paying attention to little details goes a long way making code last longer.
There’s maybe something to be said about using LLMs as a sort of sanity check code reviewer to catch minor mistakes before passing it on to a real human for actual review, but I definitely see it as harmful for anything actually “generative”
We require you to submit markdown plan before working on a feature, which must have full context, scope, implementation details. Also verification tests mardown file of happy path and critical failure modes that would affect customer, and how tests were performed. Must be checked in with the commit. More complex, large features require UML diagrams of architecture, sequences, etc. to be checked in too.
If your plan or verification docs have wrong context, missing obvious implementation flaws, bad coupling, architecture, interfaces, boundary conditions, missing test cases, etc then PR rejected.
Every developer’s performance is judged as a systems engineer. Thoughtless features without systems docs and continued lack of improvement in your systems thinking gets you PIPed.
That’s the thing though. Even if the code is good, the plans are good, the outputs are good, etc, it still devolves into chaos after some time.
If you use AI to generate a bunch of code you then don’t internalize it as if you wrote it. You miss out on reuse patterns and implementation details which are harder to catch in review than they are in implementation. Additionally, you don’t have anyone who knows the code like the back of their hand because (even if supervised) a person didn’t write the code, they just looked over it for correctness, and maybe modified it a little bit.
It’s the same reason why sometimes handwritten notes can be better for learning than typed notes. Yeah one is faster, but the intentionality of slowing down and paying attention to little details goes a long way making code last longer.
There’s maybe something to be said about using LLMs as a sort of sanity check code reviewer to catch minor mistakes before passing it on to a real human for actual review, but I definitely see it as harmful for anything actually “generative”