Or how I learned to manage Rails development as a PHP guy.  ;)

When you're building a new system by yourself, you know everything that's there.  More importantly, you know what isn't there.  The organization of the entire system is in your head - or in my case the whiteboard next to me - and documentation and sharing information isn't that important.

Once you add a second person to the mix, things become fractured.  The information has to get shared between two people, documentation becomes more important, and each of you has different skills and weaknesses.  But there are two more important aspects...  you don't always know what they're doing and you steadily lose a complete understanding of the codebase.

As long as the code works, what does it matter?

Well... not quite.

As you lose a complete understanding and a mental inventory of what is and isn't in the code, you begin to run the risk of duplicating efforts.

For example, you create a nifty little function to format dates in a particular way.  And then someone else writes a similar function that is just a bit different.  Each of you use the similar but not identical code for different things in different places and eventually a bug is found.  Even worse, the bug appears in one place but no where else with the same behavior.  And I can guarantee it's just going to get worse...

When you're working on a system, you need to rigorously defend it... but it takes everyone being involved.  When someone makes a check in, someone else needs to take a look at it.  Ask the obvious questions, note concerns, and if something strikes you as odd, ask about it.

The entire point of this is to minimize the paths through the code.  Every variation you have, every line of code, and every different interpretation offers the chance for bugs or unexpected behavior (not always the same) to creep into the code.  Each one requires more work, more effort, and tends to annoy people.  The sooner and faster you can catch/prevent these, the happier everyone will be.

I'm not a Rails guy and you're probably not either...  so although we'd love to be on the front line on this one, we can't always be.  If you don't have all of the relevant skills to perform a code review, you can still facilitate and mediate the discussion whenever it occurs... or better yet, specifically plan on a regular discussion to address these issues and keep people moving in the same direction.