The best damn diff

Mikkel is back!

He has spent 60 days out of the 112 thus far being sick.
He still claims that it was a series of unfortunate events (COVID, enteritis, a bike accident, and the flu), but I cannot help but think that much would be alleviated if he just ate more broccoli.

Regardless, it is good to have him back.
I've been living solo, and I must say, the benefits of having another are all too clear.

Having someone hold you accountable helps.
Having that someone be really smart and capable of critique helps even more.

Quite a few of the things we're doing rely on our intuition.
And while I certainly do trust mine, hearing his perspective always makes my own clear.

It becomes obvious whether my ideas are affectations or sincere attempts to innovate.
Or as Mikkel would put it, "shit" and "not bad."

Anywho, here's what we were up to.

Last week, I wrote that we would write the best diff tool in a week.
That was tad ambitious, but I think we're about half the way there.

To start with, why are diffs (or PRs) important?
They are important because they force you to read code.

It has become incredibly easy to write code.
And if something is incredibly easy, we tend to be less considered when we do it.

That means that it is now very possible (or really, probable) that people are writing a lot of code that they shouldn't be.

I tend to be a victim of this myself, where I'll often spin up quite a few Claudes in relation to my ambition, and then usually end up discarding the majority.

The experience of vibe-coding makes you feel productive by lowering the mental barrier of starting a task, but really only delays the critical thinking required.

You wake up from that dream when you have to review code.

Now there's a few types of the kind of code you'll have to review.

1. A no-brainer — a bug fix, a UX nit, a boilerplate job.
2. Everything else

AI is good at the first (and seemingly capable at the second), but I'll argue that most of the value it drives is the first.

The reason why is that you still own your code.
Your own understanding of your code (and your product) is what is important.

It is plenty possible for me to task Claude to write a new GitHub from scratch, and it is likely that it will output something. But that doesn't really get us anywhere.

The value of an engineer is not an accumulation of the code that he's written, but it is the understanding that he has.

If we want to build a better Git, we better damn well be world-class in it before we even have the gall to say we're trying.

So, we're designing diffs for that.

The experience is you just wrote a lot of code with Claude.
Now you need to think about it, reason through it, and make that code your own.

You need to understand it — and that's what we're building diffs for.
I'll write a more proper post later, but enjoy a preview for now.

Thank you,
—baepaul.