I hope it sticks around so that I can use the same workflow at work and home. I'm really enjoying how fast all the jj operations are compared to mercurial.
I'm working on my (mostly) R7RS Scheme Interpreter. I've just finished call-with-current-continuation and exceptions which were rather difficult for me to grok. Currently working on improving the debugging experience before starting the monotonous work on implementing the ~400 required functions and documentation.
The distinction is that in vibe coding you don't even look at the code.
Although I don't endorse it for most use cases, I like the distinction. There are some things I vibe code that are useful in the moment but I always throw out
I would go even further, in true vibe coding you have no idea what you’re doing, don’t even have software engineering knowledge, but whatever your prompting is working so you just keep going. It’s basically user-driven development.
I disagree. There are some cases where I want to bang out an experiment and iterate on it. While I have the ability to understand what's going on, the iteration loop makes more sense to go through the model than trying to understand what it did. This feels like vibe coding in those cases, even though I have the skills. Many talented developers I know are doing this as well to address pieces of a larger problem with expanded scope relative to what they could do without vibe coding. I work in research though, where the code is expected to be fairly exploratory (although high quality).
but the point is, you don't know what's going on. It's not that you could understand it's that you actively choose not to know... that's the essence of vibe coding.
Main reason I started using ollama is because it actually worked. I spent half an hour trying to get huggingface models to run on my GPU with no success. Meanwhile `sudo pacman -S ollama-rocm` seemed to just work out of the box.
reply