Local VibeCoding is a lot of fun..

Hi everyone! I don’t consider myself a professional, even though my current position is officially called "programmer." I’ve been writing code for many years, using different languages and technologies, most of which I’ve already forgotten)

I decided to put together (to articulate for myself) a small list of useful rules that I’ve arrived at while working with LLMs. This is an open list — just a set of general ideas (quite simple and obvious) that might be useful to someone else.

Test the model and try to understand its capabilities and limitations for yourself.

- Experiment with the model. Use different prompts, from simple to crazy (make a Snake game, make a program to download videos from YouTube, make me a new version of Windows). Try interesting prompts on large models and compare the results with a local one. This applies not only to code. This will give you a general understanding of quality and capabilities. Don’t be lazy, take the time to do this — it’s a lot of fun!

Try to set tasks at 80% of the model’s actual capabilities.

- In this case, the model will sometimes pleasantly surprise you) This will give you more reliable solution options. Don’t expect a miracle. Models are not yet ready to write complex projects from scratch to completion, but they are already very good as assistants

Break tasks down into smaller pieces.

- The smaller and simpler each task is, the better. You can’t swallow a whale in one go, but you can take bites of it, piece by piece.

Try to explain each task as concretely as possible.

- You can phrase tasks in simple language — you don’t necessarily need to use complex prompt engineering — but your prompts must be unambiguously understandable to the dumbest of the dumb, including yourself.

Proceed gradually according to a pre-planned strategy.

- A journey of a thousand miles begins with a single step.

Always review the code written by the agent.

- You must clearly understand what is happening at each step. Often, the model produces redundant code, and it can easily be simplified by removing or replacing a couple of extra lines. Sometimes the model can go off the rails — the code will work, but much later you will run into architectural difficulties.

ALWAYS TEST FOR SECURITY!!!

- Be a paranoid. Test security yourself, use the model in a separate session, and ask it to come up with ways to bypass safeguards. Do this as often as possible, always think about it, and never forget!!!

You must always understand what and how you are building.

- Unlike the first point, you always need to be competent. Learn new things (technologies, architecture, your own and others’ mistakes, etc.), create different prototypes for small parts, and test ideas — don’t be lazy. Gradually dive into the issue, but deeply enough for practical application. Learning programming is great brain exercise!

My current VibeCoding stack: llama.cpp, Qwen3.6-27B-Q4_K_M, Qwen-coder-cli

Feel free to add your own rules and to criticize this list or the approach itself.

Peace and good to everyone!