> That's what a good PM and developer pair should be doing, it's just that it's a lot faster for both of them now to review and work in tandem to get the feature done, because the bottleneck is the code generation.
The bottleneck is understanding, never "code generation."
Below is an an axiom which has served me well over the years. Perhaps it will for you as well.
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.
In my opinion software is a "set of decisions". If you let the AI loose, you will get software and the AI will make decisions on your behalf. Even if you read the code once for review, you probably won't know what those decisions were, until you've familiarized yourself with the code base.
> Sometimes it is code generation, not just understanding, especially if many of the tickets are just CRUD.
If "the tickets are just CRUD", then code generation reduces to a typing exercise if and only if the requisite functionality of the "CRUD tickets" are understood by the engineer(s) delivering them.
More generally, I have yet to see engineers which understand what needs to be delivered be limited by typing speed. Conversely, I have too often observed rapid code generation lacking intrinsic understanding fail to deliver satisfactory solutions.
> If "the tickets are just CRUD", then code generation reduces to a typing exercise if and only if the requisite functionality of the "CRUD tickets" are understood by the engineer(s) delivering them.
Correct, that's basically most tickets as I had said. They truly are not complex.
The bottleneck is understanding, never "code generation."
Below is an an axiom which has served me well over the years. Perhaps it will for you as well.