4 ms·

I'm as much of a skeptic about vibe coding as you are. I consider engineering a bit of an art, so it's not for me. That said, the kinds of things I've been hea

I'm as much of a skeptic about vibe coding as you are. I consider engineering a bit of an art, so it's not for me. That said, the kinds of things I've been hearing as going wrong with vibe coding are all or mostly fixable. I would even go as far as to say they're manifestations of the same problems that make IDEs such clumsy tools for humans to use at the moment, which is why we're trying to foist all this annoyance of using them off onto AIs. The biggest problem, THE problem in this space is that tools we use don't have the language to describe the logic -- the intent -- behind refactorings. If you've never captured the user's intent, you can't learn from it. The ability to capture that intent is absent all the way from the highest level UX right down the lowest level of serialization: the patch format That's why I believe it's my tech they really need and not Windsurf's -- I'm working on capturing the intent top to bottom.

cdelsolar 2y ago
Iunno, Cline is vibe coding some stuff for me right now while I’m surfing through hacker News.
- conartist6 2y ago
  Yeah that's weird to me but I've made my peace with it. I do this to make the software I want to use, and I think that's a chance everyone should have.
skydhash 2y ago
Isn’t the intent described in the commit message, which is one of many ways the developer can use to share intent? Code is only the what and the how. The why should be in Wiki, Readmes, Commit, Issue tracker…
- mycall 2y ago
  Typically intent needs to be well defined, such as PR discussions, use case / need assessments, or user stories on a backlog.
- conartist6 2y ago
  Let's say the change is to rename a variable. The patch format can never capture that the intent was to rename a variable. You can say so in a commit message, sure, but the action is never recorded, only it's effects, causing merges involving the rename to have conflicts
  - skydhash 2y ago
    That’s because the code is data for an execution machine. All the other stuff are for the hunan mind. There’s multiple way to transition from one state of code to another, so mostly people record the existence of a transition (version control) and why it has happened (commits and other texts). Recording how is not fruitful, unless the technique is good. In this case, the essence will be extracted, and it will become a checklist or a script. If you have two itents producing conflicting patches, the merge intent that emerges is good because it brings empathy (understanding the message) and harmony (working code). And that’s why almost everyone says that the code itself doesn’t matter. Only the feature that it brings into play and the the mind that birth it do. It is a medium. And a merge conflict is nice because it detects overlapping work and the fact that the concerned people should propably meet.
re-thc 2y ago
> the kinds of things I've been hearing as going wrong That’s the problem with this stuff. It’s all hearsay.
hotstickyballs 2y ago
Intent being unclear is exactly why different languages exist

cdelsolar 2y ago

Iunno, Cline is vibe coding some stuff for me right now while I’m surfing through hacker News.

conartist6 2y ago
Yeah that's weird to me but I've made my peace with it. I do this to make the software I want to use, and I think that's a chance everyone should have.

skydhash 2y ago

Isn’t the intent described in the commit message, which is one of many ways the developer can use to share intent? Code is only the what and the how. The why should be in Wiki, Readmes, Commit, Issue tracker…

mycall 2y ago
Typically intent needs to be well defined, such as PR discussions, use case / need assessments, or user stories on a backlog.
conartist6 2y ago
Let's say the change is to rename a variable. The patch format can never capture that the intent was to rename a variable. You can say so in a commit message, sure, but the action is never recorded, only it's effects, causing merges involving the rename to have conflicts
- skydhash 2y ago
  That’s because the code is data for an execution machine. All the other stuff are for the hunan mind. There’s multiple way to transition from one state of code to another, so mostly people record the existence of a transition (version control) and why it has happened (commits and other texts). Recording how is not fruitful, unless the technique is good. In this case, the essence will be extracted, and it will become a checklist or a script. If you have two itents producing conflicting patches, the merge intent that emerges is good because it brings empathy (understanding the message) and harmony (working code). And that’s why almost everyone says that the code itself doesn’t matter. Only the feature that it brings into play and the the mind that birth it do. It is a medium. And a merge conflict is nice because it detects overlapping work and the fact that the concerned people should propably meet.

re-thc 2y ago

> the kinds of things I've been hearing as going wrong That’s the problem with this stuff. It’s all hearsay.

hotstickyballs 2y ago

Intent being unclear is exactly why different languages exist