[kstenerud]

> It should serve as a warning to developers that the code doesn’t seem to matter, even in a product built for developers.

Code doesn't matter IN THE EARLY DAYS.

This is similar to what I've observed over 25 years in the industry. In a startup, the code doesn't really matter; the market fit does.

But as time goes on your codebase has to mature, or else you end up using more and more resources on maintenance rather than innovation.

[lelanthran]

> Code doesn't matter IN THE EARLY DAYS.

> This is similar to what I've observed over 25 years in the industry. In a startup, the code doesn't really matter; the market fit does.

> But as time goes on your codebase has to mature, or else you end up using more and more resources on maintenance rather than innovation.

Counterpoint: Code does matter, in the early days too!

It matters more after you have PMF, but that doesn't mean it doesn't matter pre-PMF.

After all, the code is a step-by-step list of instructions on solving a specific pain point for a specific target market.

[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?

[kstenerud]

That hasn't been my experience. What I've found worked is:

1. Find a potential customer who's excited about the idea of what you're going to build.

2. Build just enough to make them a mostly happy, paying customer while you secure more customers.

3. Now that you have a few customers, you have a better idea of where your architecture and business flow doesn't fit their needs.

4. Adapt to this reality, and make things robust enough that you're not spending too much time on customer support.

[lelanthran]

I follow that too, when I try a new venture, but what does that have to do with "The Code Is/Isn't Important"?

What you listed is important, but those findings are distilled into the source code of the product. If you open the source, you are providing step-by-step instructions on solving some problem that other people are prepared to pay to solve.

Basically, you come up with a recipe for success for $FOO - why would you give that recipe away unless you've already capitalised on it?

[kstenerud]

None of what I said even speaks about source code. It could just as well be run by a bunch of people with notebooks, sending emails from time to time.

All that matters is that the product works, and we have a scaling path once we find a market fit. Yes, that's likely to involve source code, but I've no qualms with tossing out the MVP code and starting over from scratch. Or adapting the quickie we put together, if it happens to contain a kernel of value. Whether I open source it or not depends on where our moat lies.

But regardless, the new reality is that anyone can decompile your code with an AI and duplicate it. So merely putting an app out there opens the door for someone to copy it. So really, your moat better be something besides the code!

[lelanthran]

> It could just as well be run by a bunch of people with notebooks, sending emails from time to time.

And does that give all your startup competitors the findings that make your solution something that others pay for?

[UqWBcuFx6NV4r]

Nope. That’s what self-important engineers will tell themselves, but it doesn’t make it remotely true. You’re patting yourself on the back for throwing together a CRUD app and burning through a bajillion dollars on AWS.

[lelanthran]

>> Counterpoint: Code does matter, in the early days too!

>> It matters more after you have PMF, but that doesn't mean it doesn't matter pre-PMF.

>> After all, the code is a step-by-step list of instructions on solving a specific pain point for a specific target market.

----------------------------------

> Nope. That’s what self-important engineers will tell themselves, but it doesn’t make it remotely true. You’re patting yourself on the back for throwing together a CRUD app and burning through a bajillion dollars on AWS.

Did you perhaps reply to the wrong comment?

[raincole]

Claude Code (and other agent tools) are not expected to be mature. They'll all be obsolete in two or three years, replaced by the next generation of AI tools. Everyone knows that.

In less than four years the AI coding workflow has been overhauled at least twice: from Chat interface (ChatGPT) to editor integration (Cursor), then to CLI agent harnesses (CC/Codex). It would be crazy to assume that harnesses are the end of evolution.

[otabdeveloper4]

> Everyone knows that.

Except, apparently, Anthropic - who are doing their darndest to get everyone onboard their tools as a moat. Apparently that's the only strategy to AI stickiness.

[benterix]

And their strategy kind of worked, right? CC is the most popular agentic coding tool. Anthropic faces competition from OpenAI (potentially better model, weaker TUI tool) and from the rest (potentially worse models, weaker TUIs). So their strategy is to develop both: make their closed model and closed tool better than competition so that when people want to vibceode they will choose their ecosystem.

[zozbot234]

OpenAI Codex is a much higher quality harness than Claude Code or OpenCode, and available as open source.

[croes]

Claude Code 2.0 (and other agent tools) are not expected to be mature. They'll all be obsolete in two or three years, replaced by the next generation of AI tools. Everyone knows that.

Claude Code 3.0 (and other agent tools) are not expected to be mature. They'll all be obsolete in two or three years, replaced by the next generation of AI tools. Everyone knows that.

And so on and on and on.

A promise of AI was mature software

[operatingthetan]

If there is a market for a mature harness, surely it will be built right?

[raincole]

I don't know what your point is. What you said is exactly what I expect to happen, except they might have a more creative name than "Claude Code 2.0".

[croes]

My point is that the mature version will always be the next future version.

[queenkjuul]

My CTO mentioned today how we haven't ever had to revision our API such that it breaks users, and even then, our v2 is still so compatible that client builds from 2017 are still vaguely useful for the end user.

But now everything is, "ship as fast as is humanly possible, literally" from management, and "garbage Claude-written PRs" from devs. Trying to maintain sanity over my monorepo is impossible.

We have nearly a century of examples of "somebody who only mostly understands making a breaking change" and decided, "what the hell, this thing is called Claude, so it can wreak havoc for as long as corporate decides"

[barnabee]

This code matters for exactly one reason: they’re playing stupid DRM games restricting what subscriber tokens can be used for to force you to use their front ends and harnesses or buy more expensive API credits.

Claude Code is strictly worse than e.g. OpenCode in my experience. Not much to see in the app’s code except how it authenticates itself…

Sure I try and use all my subscription allowance with CC on side tasks, etc. but I still end up burning a bunch of API tokens (via OpenRouter) for more serious work (even the UI and ability to quickly review what the agent has done/is doing is vastly inferior in CC).

What they have done is got me experimenting with cheaper models from other providers with those API credits.

[kristianp]

Yes, and once they've found their market, why does claude code need to keep changing at high velocity? Has the harness really needed to change so much that they're not converging on a stable shape to the code?

Is it possible to start with something of this size that's vibe coded and refactor your way into something resembling a human codebase?

[julenx]

Code quality aside (n.b. there exist many bad quality codebases before AI), a risk I perceive as an industry is we are making the logic of our businesses dependent on a few big players.

Given the output speed, it's practically impossible for developers to keep up, which directly impacts maintenance: the knowledge that would previously reside in-house, now is becoming dependent on having codebases pre-processed by LLMs.

I hope in the near future local LLMs will gain traction and provide an alternative, otherwise we are in the risky path where businesses are over-reliant on a few big companies.

[tomjen3]

You are right.

But you can use AI to improve your codebase too. Plus models are only going to get smarter from here (or stay the same).

[croes]

> Plus models are only going to get smarter from here (or stay the same).

Training models on AI generated content leads to model collapse so they hardly become smarter if more and more code is from AI

[tomjen3]

That is a possibility, but even then the models won't become more stupid (you can just keep using the current ones).

[trhway]

alternatively the code can go the way of "fast fashion" and even "3d-print your garments in the morning according to your feelings and weather and recycle at the end of the day".

If dealing with a functionality that is splittable into microfeatures/microservices, then anything that you need right now can potentially be vibe-coded, even on the fly (and deleted afterwards). Single-use code.

>But as time goes on your codebase has to mature, or else you end up using more and more resources on maintenance rather than innovation.

tremendous resource sink in enterprise software. Solving it, even if making it just avoidable - may be Anthropic goes that way and leads the others - would be a huge revolution.

[otabdeveloper4]

> microfeatures/microservices

Have you seen the code generated by AI? These things converge on the "1 million lines to make an API call" pattern. They're a lot of things, but certainly not "micro".

[ezst]

I can totally wrap my head around that, and it's an interesting thought experiment, though:

- building functionalities as components that are swappable on a whim requires a level of careful thought, abstraction and architecture that essentially is the exact opposite to ai slop

- in this day and age we still don't make software for the sake of it, and who's financing it doesn't generally require such levels of functional flexibility (the physical world commandeering the coding isn't nearly as volatile as to justify that)

- this comes loaded with the implication that "stuff needs to work": if you are developing software that manages inventory, orders, resources, ... you just can't take the chance to corrupt your customers data or disrupt their business processes. Shipping faster than you can test and with no accountability and no oversight is a solution to a problem I've personally never encountered in the wild

[trhway]

>- building functionalities as components that are swappable on a whim requires a level of careful thought, abstraction and architecture that essentially is the exact opposite to ai slop

that is only for humans really. Why we need these careful thought, abstraction and architecture? Because otherwise the required code becomes an unmanageable pile of spaghetti handling myriad of edge cases of abstraction leaks and unexpected side effects. Human brain can't manage it. AI can or at least soon would be able to. It will just be a large pile of AI slop.

It may also happen that AI will also start generate good component based architecture if forced to minimize or in some other measurable way improve its slop.

[ezst]

> Why we need these careful thought, abstraction and architecture?

your answer focused on maintainability, but you are overlooking what I think is the bigger problem: those components will eventually interact with one another (technically, by nature of living in the same code tree, sharing the same storage backend, framework, common libraries, …, or logically, by referencing the same entities for slightly different and complementary features). With that comes the need to centrally control what they should/can/cannot do. There is no shortcut to having to clarify (with your customer) and formally document what those layered interactions are, or, before you know it, you have multiple incompatible user access controls, row-level access policies, competing master/reference data, or different parts of the application interpreting differently the same data.

It's a pretty bad value proposition, if you ask me, to have to do so much hand-holding for a result that comes with no guarantees whatsoever (you will never know the extent of which your clean spec "made it in").