It sounds like it has no CI / merge gating solution. This doesn't look like a substitute for pull requests -- just a way of sharing edit history.
I don't buy the argument that being able to trace down the initial LLM prompts that led to a line of code will meaningfully accelerate review. That's just like a more advanced git blame. Reviewers will need to understand the code for themselves. A more advanced git blame doesn't really help with that
Just looking at the final version of the PR without all the intermediate history may be better since it won't sidetrack you with half-baked thoughts and assumptions from the development process. You can just focus on the result
There are cool things about this, but I'm not convinced it's actually useful. Even less convinced it's a replacement for pull requests. GitHub isn't great but I don't think this is really tackling the problems with GitHub
Did you finish the video? It has CI, but I don't know if they implemented merge gating. Though I suppose that could be part of the land skill
Ok I rewatched that now. Maybe this could work? I'm still not sure how much confidence to place in their system for merge gating
Having land as a skill seems weird to me. You could write in your land skill that it should make sure CI is passing, but I wouldn't want to leave it up to the LLM to decide if CI is passing. I'd rather that be a decision enforced by the git remote
I think to make this work the way I imagine merge checks should work, I'd have to set up my git remote to only allow fast forward merges with checks passing. I don't think this work very well with my org's current merge queue setup, but might work better for people not using a merge queue