5 ms·

> 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 DAY

> 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.

trhway 7mo ago
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 7mo ago
  > 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 7mo ago
  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 7mo ago
    >- 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 7mo ago
      > 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").
queenkjuul 7mo ago
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"
tomjen3 7mo ago
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 7mo ago
  > 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 7mo ago
    That is a possibility, but even then the models won't become more stupid (you can just keep using the current ones).
shailesh-1403 7mo ago
[dead]
raincole 7mo ago
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 7mo ago
  > 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 7mo ago
    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 7mo ago
      OpenAI Codex is a much higher quality harness than Claude Code or OpenCode, and available as open source.
- croes 7mo ago
  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
lelanthran 7mo ago
> 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.
- kstenerud 7mo ago
  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 7mo ago
    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 7mo ago
      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!
barnabee 7mo ago
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.
julenx 7mo ago
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.
kristianp 7mo ago
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?

trhway 7mo ago

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 7mo ago
> 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 7mo ago
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 7mo ago
  >- 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 7mo ago
    > 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").

queenkjuul 7mo ago

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"

tomjen3 7mo ago

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 7mo ago
> 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 7mo ago
  That is a possibility, but even then the models won't become more stupid (you can just keep using the current ones).

shailesh-1403 7mo ago

[dead]

raincole 7mo ago

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 7mo ago
> 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 7mo ago
  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 7mo ago
    OpenAI Codex is a much higher quality harness than Claude Code or OpenCode, and available as open source.
croes 7mo ago
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

lelanthran 7mo ago

> 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.

kstenerud 7mo ago
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 7mo ago
  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 7mo ago
    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!

barnabee 7mo ago

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.

julenx 7mo ago

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.

kristianp 7mo ago

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?