[keeda]

I'm probably missing something. Pre-PMF code by definition is not yet proven to solve a specific pain point, so why does it matter?

I think the crux here is the OP means the "quality of code" doesn't matter until PMF, only the utility matters (to the extent it helps you find PMF), in which case you're both in violent agreement.

But even then you don't need code. I briefly worked for a startup that found PMF by calling people, sending text messages, creating social media posts, measuring engagement to create reports, and sending invoices... all manually. The "code" as such was a bunch of templates in a doc for each of those. Once they actually started getting paid they moved to writing code.

[lelanthran]

> I briefly worked for a startup that found PMF by calling people, sending text messages, creating social media posts, measuring engagement to create reports, and sending invoices... all manually.

Right, and in that case there is no step-by-step recipe for the product. When all that is implemented in code, that is a set of step-by-step instructions for solving the pain points.

[keeda]

But the manual workflow was the step-by-step recipe the founders iterated on until they got traction; the product that came later was just an embodiment of that workflow as code.

[lelanthran]

> But the manual workflow was the step-by-step recipe the founders iterated on until they got traction;

Okay, and did they publish that under an MIT license? Did they give those manual workflows away for free to other startups?

[keeda]

I don't see how that is relevant? I thought the point under discussion was that code does not matter until PMF, and that this would be an illustrative example because there was no code until PMF.

Like, from the users' perspectives they were interacting via text messages both before and after PMF, until later down the line they were migrated to an app. At this point, the change was largely aesthetic, the core idea was the same.

Maybe we're using different definitions of terms like "PMF" here?

[lelanthran]

> Maybe we're using different definitions of terms like "PMF" here?

No, maybe different perspectives on what "the code matters" means.

In this context, I took it to mean that "code being closed/open does not matter", because the context included leaking the source.

I see you're taking it to mean "code being good/bad does not matter", because the context included a startup product.

We're talking at cross-purposes. There are two assertions here:

1. The code being good/bad (or even existing) is irrelevant.

2. The code being closed is important.

Both those assertions can be true at the same time.

My point is that the code, if it exists, is a recipe for solving some profitable pain point. In that case, there is absolutely no upside to making it open, and so the code does indeed matter.

[keeda]

Ah gotcha, that makes complete sense.

On that open/close aspect, however, this case is interesting because the leaked code was for a product that was shipped to users' machines in the wild. I'd say that while Anthropic, to your point, absolutely does not want this code leaked, they'd also know very well that any software released this way cannot be considered a competitive advantage for long.

Like, the ability of LLMs to reverse engineer software is well known by now. In fact this blog describes how, even before the leak, they reversed the CLI to patch bugs that Anthropic wouldn't! https://dev.to/kolkov/we-reverse-engineered-12-versions-of-c...

Which may be why other tools in this space have been open sourced. Yet Claude Code hasn't been, so clearly Anthropic wants to protect some rights there. I am very curious about these labs' decision processes when considering what functionality to put in the CLI versus on the servers. That could be a hint about their IP strategy and how they're thinking of moats.