3 ms·

I’ve felt like a good response to the vibe coding thing is that customers, product managers, etc ask for features and don’t read the code. You don’t need to rea

by IanCal 8mo ago

I’ve felt like a good response to the vibe coding thing is that customers, product managers, etc ask for features and don’t read the code. You don’t need to read the code of something to build a level of trust about what it does and whether that matches your expectations. It is not that wild that you can have a setup where you get an application and without reading the code decide if it solves your problem to your satisfaction.

system2 8mo ago
I bet there will be strict companies that will ask not to vibe code ever. It will become a bigger problem as vibe coding gets more popular.
acedTrex 8mo ago
There will absolutely be systems of the future that are entirely LLM written. Honestly they will probably be better quality than the standard offshore team output. But lets all hope these are not vital systems we end up depending on.
- fragmede 8mo ago
  The failure mode, as foretold by James Cameron, is in handing control of the nuclear launch systems over to an AI. Let's all really hope not!
overgard 8mo ago
I'm using Claude every day and I am correcting the output all the time, by reading the code, because it does bad things and breaks things. I feel like the people saying that it doesn't matter either aren't building anything real or they're outsourcing their work onto reviewers or they have a time bomb on their hands.
sarchertech 8mo ago
And what happens when you change one word in the specification and the app completely changes? Sure everything you have unit tests for might stay the same, but unless your unit tests are testing all observable behavior (and if they are they’ll be 100x longer than the code) users will notice incredibly confusing differences in every build.
- IanCal 8mo ago
  Vibe coding doesn't mean that it's rebuilt from the spec from scratch each time, nor does it mean nobody looks at the application. It originally meant nobody looked at the code at all, although that's much more diluted I feel now - things are called vibe coding that sit on a larger spectrum. My point was that "didn't look at the code, looked at the app and gave feature requests and tried the results" is a way of building applications that essentially anyone who doesn't code has been doing all along.
  - sarchertech 8mo ago
    >rebuilt from scratch I have actually encountered multiple people proposing that. People in the camp of LLMs are the new high level compiler and code is assembly language. That’s what prompted this entire are compilers deterministic article. But ignoring whether it’s regenerated from scratch, when you ask an agent to add minor functionality, it will regularly change existing unrelated functionality. Some of that is accidental, and could theoretically be solved. For example agents when refactoring won’t copy and paste existing code, they will rewrite it from scratch and frequently change it. Some of it is a required because systems are intertwined. If the application is small enough you can get away with just trying the results to build confidence. However for any non-trivial application combinatorics explosion means that this stops working very quickly. This has been understood for decades. > My point was that "didn't look at the code, looked at the app and gave feature requests and tried the results" is a way of building applications that essentially anyone who doesn't code has been doing all along. That is not building applications. That is delegating building applications to a trusted team of humans. If that trusted team of humans are essentially junior programmers with no agency or ability to learn and improve, your app will fail. Imagine being a product manager with a team of 100 off shore junior developers that rotate out every day. You could 100% build something useful with that setup. But anything more complex than a todo app would eventually collapse under the chaos.
1718627440 8mo ago
They are able to extrapolate behaviour from single examples, because the implementor has common human sense, and produces an algorithm, that is continuous, and doesn't exhibit completely different behaviour for slight input changes. That is precisely the problem here.

by IanCal 8mo ago

system2 8mo ago

I bet there will be strict companies that will ask not to vibe code ever. It will become a bigger problem as vibe coding gets more popular.

acedTrex 8mo ago

There will absolutely be systems of the future that are entirely LLM written. Honestly they will probably be better quality than the standard offshore team output. But lets all hope these are not vital systems we end up depending on.

fragmede 8mo ago
The failure mode, as foretold by James Cameron, is in handing control of the nuclear launch systems over to an AI. Let's all really hope not!

overgard 8mo ago

I'm using Claude every day and I am correcting the output all the time, by reading the code, because it does bad things and breaks things. I feel like the people saying that it doesn't matter either aren't building anything real or they're outsourcing their work onto reviewers or they have a time bomb on their hands.

sarchertech 8mo ago

And what happens when you change one word in the specification and the app completely changes? Sure everything you have unit tests for might stay the same, but unless your unit tests are testing all observable behavior (and if they are they’ll be 100x longer than the code) users will notice incredibly confusing differences in every build.

IanCal 8mo ago
Vibe coding doesn't mean that it's rebuilt from the spec from scratch each time, nor does it mean nobody looks at the application. It originally meant nobody looked at the code at all, although that's much more diluted I feel now - things are called vibe coding that sit on a larger spectrum. My point was that "didn't look at the code, looked at the app and gave feature requests and tried the results" is a way of building applications that essentially anyone who doesn't code has been doing all along.
- sarchertech 8mo ago
  >rebuilt from scratch I have actually encountered multiple people proposing that. People in the camp of LLMs are the new high level compiler and code is assembly language. That’s what prompted this entire are compilers deterministic article. But ignoring whether it’s regenerated from scratch, when you ask an agent to add minor functionality, it will regularly change existing unrelated functionality. Some of that is accidental, and could theoretically be solved. For example agents when refactoring won’t copy and paste existing code, they will rewrite it from scratch and frequently change it. Some of it is a required because systems are intertwined. If the application is small enough you can get away with just trying the results to build confidence. However for any non-trivial application combinatorics explosion means that this stops working very quickly. This has been understood for decades. > My point was that "didn't look at the code, looked at the app and gave feature requests and tried the results" is a way of building applications that essentially anyone who doesn't code has been doing all along. That is not building applications. That is delegating building applications to a trusted team of humans. If that trusted team of humans are essentially junior programmers with no agency or ability to learn and improve, your app will fail. Imagine being a product manager with a team of 100 off shore junior developers that rotate out every day. You could 100% build something useful with that setup. But anything more complex than a todo app would eventually collapse under the chaos.

1718627440 8mo ago

They are able to extrapolate behaviour from single examples, because the implementor has common human sense, and produces an algorithm, that is continuous, and doesn't exhibit completely different behaviour for slight input changes. That is precisely the problem here.