5 ms·

It's an unpopular truth for our industry, but the point of commercial software development is not to write good code; it's to write profitable code. There are

It's an unpopular truth for our industry, but the point of commercial software development is not to write good code; it's to write profitable code. There are some cases where the most profitable code is also good code. We like those. But in most (99%+) cases, the code is not going to survive contact with the market and so spending any time on making it good is wasted.

arcticbull 7mo ago
Yep this is especially true in the pre-product-market-fit phase. Most if not all of that code should be written to be thrown away. Any time you spend writing perfect code instead of your MVP is burnt runway and a chance for competitors to catch up. Once you show PMF though the balance changes to long-term sustainability and maintainability. What's going to be interesting is getting to a place where it generates better code than we would from specs. You can get better and better generated code by filling in the context the model infers. Do that long enough, and well, a perfect spec is just code. We do live in interesting times.
- KellyCriterion 7mo ago
  > Any time you spend writing perfect code instead of your MVP is burnt runway This. Once we crashed a product/company becaues of "we want it to be engineered perfectly" :-X
okr 7mo ago
To my believe there was not a goal to write good code. The goal was maintainability and to keep it simple, so that people understand. People come and go, you constantly get to see foreign code and you have to do something with it. Anyways, i see the maintainability hell coming onto us. I still wonder how i organize this with AI. I definitly do not want to touch it what is written by AI.
- drob518 7mo ago
  I think the industry-wide hope is that AI manages the AI-written code, but it’s unclear whether that’s actually going to work out in practice. Right now, my experience is that is dicey. I’ve had AI mess up a codebase to the point where I threw it away and restarted. Maybe I was doing it wrong, though, in that I was looking at the code and was increasingly horrified by the slop. I get the feeling that in this new world, we’re supposed to ignore how the sausage is made and just focus on the final outcome.
  - abustamam 7mo ago
    IME AI-native engineering requires a lot of infrastructure to make it viable. Teams who are just opening up cursor and putting it on "auto" and trying to one shot features may get stuff that works but is indeed slop. Since the beginning of the year, I've been spearheading a low-stakes AI-native project (an internal tool). No one's written a single line of code. And we've learned so much from this experience. The first rule was our product manager, who is technical but isn't typically in the weeds, needs to be able to one-shot prompts with cursor auto. And so many rules stem from there, from e2e tests to ensure he doesn't break stuff, to custom linters to ensure that code lives in the right place, to architectural spec sheets so the LLM doesn't try to do raw DB queries from the client. We're still not there, but we're getting closer and learning and improving every day. I think the folks who are vibe coding a lot either aren't working in a team, or they are omitting the fact that they have spent a long time building harnesses to ensure the LLM doesn't run amok. And I think the people who hate vibe coding are likely just asking Claude Code to do X without using Skills that have opinionated ways to do X. All that said, I don't think we should ignore how the sausage is made at all. Part of what makes me able to move quickly in this project is knowing where stuff lives. I may not understand the line-by-line code, but if I know where to look to find out why I'm missing data that's in the DB, I can move a lot faster than if I have no idea what's going on in the codebase. Then when I find the problematic file or function, I can ask the LLM why it's like X and tell it it should be like Y.
    - drob518 7mo ago
      Cool. Are you restricting the AI to be very focused on a function or an architectural blocks that is envisioned, or are you giving it more freedom? I seem to have less slop when I really constrain things, but that takes a lot of work (e.g., specs) and dialogue with the AI (“focus on X, now let’s design block Y,” etc.).
deterministic 6mo ago
In my experience (30+ years) writing good code (and good automatic tests) makes me way more productive. Both when initially writing the code and later when maintaining it. Good code dramatically reduce bugs and makes the remaining bugs more visible. I spend almost zero time fixing bugs. Because there aren't many. Not a brag. Just the truth.

arcticbull 7mo ago

Yep this is especially true in the pre-product-market-fit phase. Most if not all of that code should be written to be thrown away. Any time you spend writing perfect code instead of your MVP is burnt runway and a chance for competitors to catch up. Once you show PMF though the balance changes to long-term sustainability and maintainability. What's going to be interesting is getting to a place where it generates better code than we would from specs. You can get better and better generated code by filling in the context the model infers. Do that long enough, and well, a perfect spec is just code. We do live in interesting times.

KellyCriterion 7mo ago
> Any time you spend writing perfect code instead of your MVP is burnt runway This. Once we crashed a product/company becaues of "we want it to be engineered perfectly" :-X

okr 7mo ago

To my believe there was not a goal to write good code. The goal was maintainability and to keep it simple, so that people understand. People come and go, you constantly get to see foreign code and you have to do something with it. Anyways, i see the maintainability hell coming onto us. I still wonder how i organize this with AI. I definitly do not want to touch it what is written by AI.

drob518 7mo ago
I think the industry-wide hope is that AI manages the AI-written code, but it’s unclear whether that’s actually going to work out in practice. Right now, my experience is that is dicey. I’ve had AI mess up a codebase to the point where I threw it away and restarted. Maybe I was doing it wrong, though, in that I was looking at the code and was increasingly horrified by the slop. I get the feeling that in this new world, we’re supposed to ignore how the sausage is made and just focus on the final outcome.
- abustamam 7mo ago
  IME AI-native engineering requires a lot of infrastructure to make it viable. Teams who are just opening up cursor and putting it on "auto" and trying to one shot features may get stuff that works but is indeed slop. Since the beginning of the year, I've been spearheading a low-stakes AI-native project (an internal tool). No one's written a single line of code. And we've learned so much from this experience. The first rule was our product manager, who is technical but isn't typically in the weeds, needs to be able to one-shot prompts with cursor auto. And so many rules stem from there, from e2e tests to ensure he doesn't break stuff, to custom linters to ensure that code lives in the right place, to architectural spec sheets so the LLM doesn't try to do raw DB queries from the client. We're still not there, but we're getting closer and learning and improving every day. I think the folks who are vibe coding a lot either aren't working in a team, or they are omitting the fact that they have spent a long time building harnesses to ensure the LLM doesn't run amok. And I think the people who hate vibe coding are likely just asking Claude Code to do X without using Skills that have opinionated ways to do X. All that said, I don't think we should ignore how the sausage is made at all. Part of what makes me able to move quickly in this project is knowing where stuff lives. I may not understand the line-by-line code, but if I know where to look to find out why I'm missing data that's in the DB, I can move a lot faster than if I have no idea what's going on in the codebase. Then when I find the problematic file or function, I can ask the LLM why it's like X and tell it it should be like Y.
  - drob518 7mo ago
    Cool. Are you restricting the AI to be very focused on a function or an architectural blocks that is envisioned, or are you giving it more freedom? I seem to have less slop when I really constrain things, but that takes a lot of work (e.g., specs) and dialogue with the AI (“focus on X, now let’s design block Y,” etc.).

deterministic 6mo ago

In my experience (30+ years) writing good code (and good automatic tests) makes me way more productive. Both when initially writing the code and later when maintaining it. Good code dramatically reduce bugs and makes the remaining bugs more visible. I spend almost zero time fixing bugs. Because there aren't many. Not a brag. Just the truth.