1. Review by an LLM
From my experience, using a custom Claude Opus-based reviewer is really beneficial. It is definitely not a replacement for human review, but it provides great assistance. I’ve seen many cases where LLMs spotted tiny mistakes that would otherwise go unnoticed by my co-workers.Dangers & Trade-offs
- Merging a PR can get really prolonged by playing ping-pong with an LLM reviewer that seems to have completely different ideas every time —compared to a typical developer who usually leaves the most important suggestions in the first comment.
- A lot of suggestions might be irrelevant, but you might notice developers still pasting the LLM’s suggestion directly into their LLM coding tool ;)
2. Database migrations
Code that doesn’t build shouldn’t be merged. It breaks deployments and local development. But so do faulty migrations on amain/development branch!
3. Preview Deployments
I think they’re really beneficial because of how they impact quality assurance. Without them, a lot of unrelated PRs are usually merged into the development/staging environment, and every so often, they are checked by a QA person and a PM. And if other developers want to check the changes before approving a PR, they have to do things like stashing/committing their current work, switching to the branch, and running tasks like migrations or package installs. Even when it only takes 1-2 minutes, I think it is enough of a barrier to demotivate other developers from verifying PR changes. But with Preview Deployments, the change can be tested by stakeholders before even getting merged into dev!4. For the JS ecosystem: Fallow
- Preventing dead code & duplication.
- High code complexity detection.
- Respecting React client/server boundaries.