| ▲ | embedding-shape 7 hours ago |
| > after a few minutes of vibe coding Don't vibe-code, it's a joke someone coined in the moment, that somehow the industry decided shouldn't be a joke, and some people think it's a feasible way of developing stuff, it's not. Find a better way of working together with agent, where you get the review what's important to be reviewed by a human, and "outsource" the rest, and you'll end up with code and a design that works the way you'd program it yourself, you just get there faster. I probably end up reviewing maybe 90% of the code that the agent writes, but still it's a hell of a lot more pleasant writing/dictating a few prompts over typing tens of thousands of characters and constantly moving between files. Maybe I'm just tired of typing... |
|
| ▲ | Xmd5a 6 hours ago | parent | next [-] |
| I've been thinking of using Kiczales's Systematic Program Design [0]. Write the skeleton. Let the IA fill in the blanks. [0] https://news.ycombinator.com/item?id=16563160 |
| |
|
| ▲ | ActorNightly 8 minutes ago | parent | prev | next [-] |
| Vibe coding is fine. Its just the next step. Python for example is vibe coding compared to C. You pip install some library and just use it. Wanna modify a class instance variable and not use the proper accessor function? Sure, go right ahead. The big thing about vibe coding is, as ironic as it sounds, prompt engineering. You can have tons of slop, but if it works, it works. The key defining factor is what constitutes as working. Namely, defining input output contracts, and automatic checks. |
|
| ▲ | wahnfrieden 6 hours ago | parent | prev [-] |
| There are tasks where it is appropriate to vibe code |
| |
| ▲ | embedding-shape 6 hours ago | parent [-] | | Agreed, whenever you're 99% sure you'll throw away the code afterwards. | | |
| ▲ | da_chicken 5 hours ago | parent | next [-] | | Yeah, the problem is that "code you're sure to throw away" includes school coursework. That's always been one of the problems, though. Writing code for class is much less stressful than writing code that other people will rely on. | |
| ▲ | legulere 5 hours ago | parent | prev | next [-] | | I let Claude translate a horribly written vb program writing some xml data into a pdf form. Most of the code I didn't even read until much later, I just checked the end result. The code won't be touched again, and if it will simply be replaced. Some code is foundational and you should put a lot of effort into it, a lot of code isn't though. Other than that agentic coding has not really been working that well for me at our main codebase though. | |
| ▲ | wahnfrieden 6 hours ago | parent | prev [-] | | Internal/personal tooling, marketing automations, etc. tend to afford it without needing to throw it out after. These are also cases where you can simply rewrite later without having to address a mountain of debt. If you do this work for a wage and are nearly fully alienated from the value of your labor, I understand the distaste for applying it in any circumstance. You'll care more for your personal experience of the work: how informed you appear when reporting on it to your colleagues, how your boss/colleagues will judge you when an issue arises, how much you feel you are learning from the work, how frustrating it feels to return to items at the behest of others, etc. Vibe coding in these circumstances is unpleasant. | | |
| ▲ | embedding-shape 6 hours ago | parent [-] | | I care about building programs that work, do their thing well and are easy to change today and in the future :) I'm not sure where you're extrapolating the rest from, vibe-coding simply isn't for long-lasting software, you need to actually be involved then. Don't get me wrong, most of the code I "produce" today is written by LLMs/agents, but almost none of it is "vibe-coded". Personal tooling especially, since you want to be able to just do small changes over long periods of time, it's important it makes sense when you come back to it, even if you forgotten all about it since your last change. |
|
|
|
