pull down to refresh

228 sats \ 8 replies \ @k00b OP 21h \ on: The Cult Of Vibe Coding Is Insane AI devs

I haven't prompted much with it yet, but I've added the following rule to cursor hoping it might fight the generation bias:

1. Prefer deletion to addition.
2. Do not introduce new abstractions unless at least 3 concrete call sites clearly need them.
3. Inline one-off helpers.
4. Reduce files, layers, and indirection.
5. Optimize for minimum code surface area that preserves clarity.
6. Show the simplest working version first.
write
compose
139 sats \ 2 replies \ @BitcoinErrorLog 10h

IMO be careful with sweeping rules like this, as they naturally conflict with the ai using its own judgment, which improves with every update.

Tip: tell the ai to make the rule for you so you can see how it interprets your desires instead. Just explain what you dont like conversationally.

These rules you listed are way too general imo, which means sometimes they will be the wrong rules.

Also, why not use ai to refactor and rearchitect code you think is slop? If you can define your requirements, ai can help.

reply
16 sats \ 1 reply \ @k00b OP 10h

Because I’m reading code that I’m familiar with, I know that AI’s own judgement biases toward more code when it shouldn’t regardless of how much I talk to it.

If reading the code isn’t important, then I agree with you - let the AI do everything because they’re the producer and the consumer of the code.

reply
16 sats \ 0 replies \ @BitcoinErrorLog 5h

well, i do prefer rules like "don't ask the user to do things you can confidently do yourself"

reply
72 sats \ 1 reply \ @justin_shocknet 20h
  1. Avoid long functions, break down into short functions with clear names
reply
33 sats \ 0 replies \ @k00b OP 20h

I don't run into that problem with GPT 5.4. It's subjective but I also prefer larger functions all else being equal hence inline one-off helpers. It's easy to go overboard with function shortening IME.

reply
139 sats \ 2 replies \ @optimism 21h
  • I like 5..
  • I think that 1. and 4. are contextual / specific to job-at-hand and could objective-poison generic functioning and degrade.
  • 2. and 3. are subjective, but valid.
  • 6. I would personally not do because rework is expensive. I'd rather "1-shot" (after planning / analysis / exploration) an implementation and throw it away than have a bot rework stuff. Arguably, latest releases did get better at rework, but I'm still feeling as if it is more costly.
reply
85 sats \ 1 reply \ @k00b OP 20h

I agree with your assessment of the rules. They are my personal generic rules absent bots - context is usually something relatively frivolous where human readability takes precedence over nearly everything. I find rework from a checkpoint created by these rules easier than going in the other direction.

reply
139 sats \ 0 replies \ @optimism 20h

I guess rework from checkpoint also means redo, rather than rework. (The checkpoints were broken when combined with having full control cmdline git in the early days, so I hated that feature most of all)

reply