I agree with what is said. When we lean into agents and want to use them for productivity, we need to accept the fact we will not fundamentally understand the code as we have designed and written it, otherwise might as well write the code ourselves. We already used to ship code with different levels of quality and technical debt to production before ai and developed a taste for what is "good enough" depending on the requirements, our long term workflow (how we close technical debt, and handle bugs), and our own personal capabilities. AI gives us more hands in the process and allows us to do more with less time, and less low level understanding. We should still question the code, and get our hands dirty in some sections, slow down and write ourselves small testing environments and chunks of code to get fundamental understanding of code which is critical. Otherwise we should just ship and forget and handle tech debt and "understanding debt" only when relevant. A lot of production code delivered pre ai already had tech debt that even the devs were not aware of, and yet a lot of it never fails and gets the job done, probably will be replaced in the future as those features become obsolete. Just because ai can surface those kinds of issues better does not mean straight away those have to be addressed meticulously.
The same way we do not understand already what the compiler does and how the code we have written runs against the machine, it's ok to delegate some of the lower level of understanding to AI, as long as the process produces the required results.
Different projects will have different sections where tech debt and code understanding debt are more critical, and we should with time acquire the intuition to know where we should rely more, and where we should rely less on ai to fill in the gaps.
If you dont understand the code, how do you know what it actually does ? How do you know its not doing the wrong thing, where wrong could be really bad ?
> Second, while the author may not understand the code at a level where they could have written it themselves, they should still understand it as a reviewer. Treat it like the agent is the author and the human author is the first reviewer; don't pull somebody else in until you're satisfied first.
Emphasis mine.
That brings you back to square one. You should only be satisfied with the state of the PR once you understand it. Anything below that and you’re not doing your job properly. That doesn’t mean the code needs to be flawless on first PR, but you should understand everything it is doing and the why of the approach, otherwise there’s no point to you doing it.
So to the question in the title, the answer is quite simply “never”.
This leans heavily on what "doing your job properly" means. Code quality, understanding, and doing your job properly are not so black-and-white. Your job is probably not to push out flawless code; it's more likely to push out valuable code, that minimizes risk, and appropriately trades off speed and quality (for some appropriate definition of "appropriate").
Maybe we’re in violent agreement? In the example of a staging database config, I understand the problem that CI faced, the fix in the PR, and a rough upper limit on the tech debt impact of the connection strings diverging. I have an assumption (not an understanding) about how long it might take to learn about PgBouncer in Neon, and the worst case if it is wrong (CI breaks). Does that qualify as understanding the PR? I couldn’t have authored it by myself with this understanding, because to do so would require me to have learned about PgBouncer to find the fix.
I agree with what is said. When we lean into agents and want to use them for productivity, we need to accept the fact we will not fundamentally understand the code as we have designed and written it, otherwise might as well write the code ourselves. We already used to ship code with different levels of quality and technical debt to production before ai and developed a taste for what is "good enough" depending on the requirements, our long term workflow (how we close technical debt, and handle bugs), and our own personal capabilities. AI gives us more hands in the process and allows us to do more with less time, and less low level understanding. We should still question the code, and get our hands dirty in some sections, slow down and write ourselves small testing environments and chunks of code to get fundamental understanding of code which is critical. Otherwise we should just ship and forget and handle tech debt and "understanding debt" only when relevant. A lot of production code delivered pre ai already had tech debt that even the devs were not aware of, and yet a lot of it never fails and gets the job done, probably will be replaced in the future as those features become obsolete. Just because ai can surface those kinds of issues better does not mean straight away those have to be addressed meticulously.
The same way we do not understand already what the compiler does and how the code we have written runs against the machine, it's ok to delegate some of the lower level of understanding to AI, as long as the process produces the required results.
Different projects will have different sections where tech debt and code understanding debt are more critical, and we should with time acquire the intuition to know where we should rely more, and where we should rely less on ai to fill in the gaps.
If you dont understand the code, how do you know what it actually does ? How do you know its not doing the wrong thing, where wrong could be really bad ?
https://en.wikipedia.org/wiki/Thalidomide
> Second, while the author may not understand the code at a level where they could have written it themselves, they should still understand it as a reviewer. Treat it like the agent is the author and the human author is the first reviewer; don't pull somebody else in until you're satisfied first.
Emphasis mine.
That brings you back to square one. You should only be satisfied with the state of the PR once you understand it. Anything below that and you’re not doing your job properly. That doesn’t mean the code needs to be flawless on first PR, but you should understand everything it is doing and the why of the approach, otherwise there’s no point to you doing it.
So to the question in the title, the answer is quite simply “never”.
This leans heavily on what "doing your job properly" means. Code quality, understanding, and doing your job properly are not so black-and-white. Your job is probably not to push out flawless code; it's more likely to push out valuable code, that minimizes risk, and appropriately trades off speed and quality (for some appropriate definition of "appropriate").
> it's more likely to push out valuable code, that minimizes risk, and appropriately trades off speed and quality
And you can only ascertain you have done so if you can understand what you pushed.
Maybe we’re in violent agreement? In the example of a staging database config, I understand the problem that CI faced, the fix in the PR, and a rough upper limit on the tech debt impact of the connection strings diverging. I have an assumption (not an understanding) about how long it might take to learn about PgBouncer in Neon, and the worst case if it is wrong (CI breaks). Does that qualify as understanding the PR? I couldn’t have authored it by myself with this understanding, because to do so would require me to have learned about PgBouncer to find the fix.