Not leadership as much as the other developers! Leadership is open but concerned about SOC 2 compliance.
The other devs have already torpedoed standups and now no one wants to code review anymore. I'm sitting here remembering at the start of my career how people had to advocate for version control and code review and now my head is spinning because we're about to abandon it in favor of AI writing the code and AI reviewing it.
I maintain that code review is about having one another's back more than being a hoop to jump through, and that the rest of the folks in the employ of the company depend on our diligence. But I also am keeping note that all the "fixes" are on the reviewers side rather than the onus being on the dev requesting review. In my opinion, it's easier than ever to make a clean branch with clear atomic commits with good commit messages, and not knowing how to rebase is no longer an issue. But still the PRs are messy and large.
Yes, not only management but the customer too, the promise of speed has creept in their minds too. Errors are always at my expense and must be corrected faster, even if it's a provider mistake
I haven't seen it happen. They're the bottleneck now, and for some people, removing the bottleneck may mean removing the process. But there's probably a good reason why it's the bottleneck.
Some people think that as long as it passes all tests, that's all jolly - but it still needs a code review to check whether all the tests are still relevant and whether everything that needs to be tested is tested.
Even if AI gets the PRD 100% right, the PRD may be wrong. Getting the communications right is the essence of software engineering in the end.
Today productivity is the mantra that drives the world of work. Too often products are released with the reason "as long as it works" and aspects such as security and performance are often neglected, and this costs effort and slipping of release times. The features of a product is only one of the aspects of software production: security and code optimization are other 2 branches of development that require parallel developments. Design of test suites, measurements, data analysis, study of optimizations and rewriting of code require effort and development times incompatible with the requests of managers and of the marketing department. Let's hope that the speed with which AI systems today are able to produce code will be used not only to produce new applications and services faster and faster, but also to optimize their code and make it more secure.
Leadership not so much. Its mostly engineers who interpret shipping fast as “no code review” and other risky things like automated deployment with poor test suite, all while taking months to go from idea to implementation and nobody seems to be payin attention to this part
Our leadership is not pushing us to skip dev review. We have AI coding guidelines where engineers are trusted to merge in pull requests with no review if they pass certain criteria. Our code reviews are more so reviewing architectural docs, plans, evaluation criteria, etc. that an AI would then write the code for later.
I have found that skipping review rarely saves time in the end, because small misunderstandings about requirements or edge cases tend to surface later when they are more expensive to fix. What has worked better in my experience is keeping reviews small and focused: short pull requests, a clear description of what changed and why, and automated tests for the routine checks. That way the human review can focus on logic and risk rather than style, and it stays fast enough that teams are less tempted to skip it.
Not leadership as much as the other developers! Leadership is open but concerned about SOC 2 compliance.
The other devs have already torpedoed standups and now no one wants to code review anymore. I'm sitting here remembering at the start of my career how people had to advocate for version control and code review and now my head is spinning because we're about to abandon it in favor of AI writing the code and AI reviewing it.
I maintain that code review is about having one another's back more than being a hoop to jump through, and that the rest of the folks in the employ of the company depend on our diligence. But I also am keeping note that all the "fixes" are on the reviewers side rather than the onus being on the dev requesting review. In my opinion, it's easier than ever to make a clean branch with clear atomic commits with good commit messages, and not knowing how to rebase is no longer an issue. But still the PRs are messy and large.
Yes, not only management but the customer too, the promise of speed has creept in their minds too. Errors are always at my expense and must be corrected faster, even if it's a provider mistake
I haven't seen it happen. They're the bottleneck now, and for some people, removing the bottleneck may mean removing the process. But there's probably a good reason why it's the bottleneck.
Some people think that as long as it passes all tests, that's all jolly - but it still needs a code review to check whether all the tests are still relevant and whether everything that needs to be tested is tested.
Even if AI gets the PRD 100% right, the PRD may be wrong. Getting the communications right is the essence of software engineering in the end.
Today productivity is the mantra that drives the world of work. Too often products are released with the reason "as long as it works" and aspects such as security and performance are often neglected, and this costs effort and slipping of release times. The features of a product is only one of the aspects of software production: security and code optimization are other 2 branches of development that require parallel developments. Design of test suites, measurements, data analysis, study of optimizations and rewriting of code require effort and development times incompatible with the requests of managers and of the marketing department. Let's hope that the speed with which AI systems today are able to produce code will be used not only to produce new applications and services faster and faster, but also to optimize their code and make it more secure.
Leadership not so much. Its mostly engineers who interpret shipping fast as “no code review” and other risky things like automated deployment with poor test suite, all while taking months to go from idea to implementation and nobody seems to be payin attention to this part
I'm at a small company:
Our leadership is not pushing us to skip dev review. We have AI coding guidelines where engineers are trusted to merge in pull requests with no review if they pass certain criteria. Our code reviews are more so reviewing architectural docs, plans, evaluation criteria, etc. that an AI would then write the code for later.
[flagged]
[flagged]
I have found that skipping review rarely saves time in the end, because small misunderstandings about requirements or edge cases tend to surface later when they are more expensive to fix. What has worked better in my experience is keeping reviews small and focused: short pull requests, a clear description of what changed and why, and automated tests for the routine checks. That way the human review can focus on logic and risk rather than style, and it stays fast enough that teams are less tempted to skip it.
[flagged]
[flagged]