Re:Bad ideas that aren't bad anymore
by dava96 on Thursday November 12, 2026 @04:03AM
(#50464754)
On one hand, I like the idea of being 100% responsible for reviewing my own code because it allows me to get changes in quicker.
The way we've been working is that we own a feature end-to-end rather than just a slice of it. So I understand my work, and other people understand theirs. In that context, not having code reviews makes some sense.
But part of me already misses what code reviews used to bring: learning opportunities. I can no longer rely on someone more senior than me to give me feedback, challenge my decisions, or help develop a shared understanding of the codebase.
«I can say to Claude "hey, bring me up to speed on this thing they've been building - how does it work, where is it at, and what still needs to be done?"»
I think there's an opportunity to solve this differently. If you could see your teammates' conversations with their agents, you could actually follow the decisions they made and understand why. Although I appreciate that's a bit "big brother".
«What I'm recommending instead is to still build a very strong foundation in engineering fundamentals, because that's where I think we as humans offer the most value right now.»
Whilst I partly agree with this, how do you actually do it in practice?
How can you possibly know what good looks like without writing good code yourself and experiencing the consequences of bad code?
I've been thinking of this as a privileged point of view, particularly from engineers who've spent more of their careers working pre-AI than post-AI.
You've had the benefit of years of experience developing the judgment needed to distinguish good engineering from bad engineering. You can now use AI effectively precisely because you've built that foundation.
But how are newer engineers supposed to develop that same judgment, especially if their workplace operates like yours?
But it's valuable to experiment with these instincts.
The way we've been working is that we own a feature end-to-end rather than just a slice of it. So I understand my work, and other people understand theirs. In that context, not having code reviews makes some sense.
But part of me already misses what code reviews used to bring: learning opportunities. I can no longer rely on someone more senior than me to give me feedback, challenge my decisions, or help develop a shared understanding of the codebase.
«I can say to Claude "hey, bring me up to speed on this thing they've been building - how does it work, where is it at, and what still needs to be done?"»
I think there's an opportunity to solve this differently. If you could see your teammates' conversations with their agents, you could actually follow the decisions they made and understand why. Although I appreciate that's a bit "big brother".
«What I'm recommending instead is to still build a very strong foundation in engineering fundamentals, because that's where I think we as humans offer the most value right now.»
Whilst I partly agree with this, how do you actually do it in practice?
How can you possibly know what good looks like without writing good code yourself and experiencing the consequences of bad code?
I've been thinking of this as a privileged point of view, particularly from engineers who've spent more of their careers working pre-AI than post-AI.
You've had the benefit of years of experience developing the judgment needed to distinguish good engineering from bad engineering. You can now use AI effectively precisely because you've built that foundation.
But how are newer engineers supposed to develop that same judgment, especially if their workplace operates like yours?
But it's valuable to experiment with these instincts.