vibe coding

Community Community & Industry Discussion
1

how I vibe code:

make a bare bones program in this case a small game.

take that to chatgpt and tell them what I want to do they help me and we talk then they get something I like then I take that to grok in cursor ai. Grok takes the text from chatgpt writes a note to take to pycharm, I take that to cursor ai coding assistant in cursor ai. They make the code and the chatgpt tests it and then I commit it to github but I don’t commit it or give it directly to chagpt, no when cursor finishes I then go use chatgpt cosing assistant in pycharm to debug, then google ai assistant to debug, then cursor to debug I might do this many time going through agents to debug when I’m happy I then say to cursor now make the code simple for a beginner to read and they do then I might go through more debugging with multiple ai in pycharm, then I go back to cursor and I say now reduce the size of the files so a beginner can read the code and they do and make more files. then I debug some more then I get the cursor to add in comments then after all that i debug onem ore time then I give that to chatgpt then they help me commit it to github then I go show grok.

That’s a lot of steps and I think if unreal is going to be vibe coding in unreal engine 6 this is what they are going to need to do.

Thank you for reading this. :slight_smile:

2

edit.: paste the below into the ai chat and wait then fix it to fit your project and replace the ai agents. when your done copy strategy.txt make a new project and put the strategy.txt into the main.rs

"

Read every line of code and find bugs. When you find bugs, only write them in bugs.txt, describe where you found them, The lines the bug is on, don’t fix them, don’t change the code.

right now I finished getting bugs.txt filled by (google ai, chatgpt, cursor ai) in rust rover, now you add to the bugs in bugs.txt with the bugs you find.

My idea is to put the chess game grok made me into rust rover, and ask the rust rover ai to find bugs, I also want all the rules of chess, and to only write them into bugs.txt and not to fix them or change the code.
I ask the ai to think of how to take the main.rs and the bugs.txt, and just remake the game to include the bug fixes into strategy-chess.txt, so that the bug fixes aren’t added on but instead they are there by design.
Then keep repeating this, so every bug fix the ai writes in the bugs.txt, the ai then remakes the entire game to add the fix writing the new game into strategy-chess.txt.
This way the bug fix isn’t bloat, the bug fix is there by design, which might help keep vibe coding less bloated, what do you think of my idea?

What Makes This Idea Strong

  1. Fixes by Architecture, Not Monkey-Patches:
    ◦Instead of adding special-case handlers for bugs (e.g., “if en passant and white king is on a5 and rook is on h5, don’t allow…”), you redesign the data model and invariants so the bug is impossible by construction.

  2. Keeps the Cognitive Overhead Low:
    ◦The code stays clean, concise, and intentional rather than reading like an archaeological dig of past mistakes.

  3. The “Bugs File” Acts as a Specification:
    ◦Cataloging bugs before touching the code gives you an explicit checklist of requirements rather than vague impressions.

Rewrite the new chess game into a text file strategy-chess.txt, then I will build the game then ask the ai to find bugs again and repeat and repeat the process.

After you find the code say, “I am ready to take main.rs and bugs.txt and make a new game in strategy-chess.txt”, then if I say “ok” then you put the new game into strategy-chess.txt

To make the new game keep the behavior the same in the new version as the old version, for reference the original game is in original_strategy-chess.txt, so you might need to compare it to the previous version and or original version."

3

(post deleted by author)

4

That is an interesting workflow. One thing that helps a lot with AI-assisted coding is keeping the loop small: ask for one change at a time, read the diff before accepting it, and commit after every change that works. That way, if a generated edit breaks something, you can roll back a single commit instead of untangling several changes at once.

For game projects, it also helps to keep a short notes file describing the architecture (what each script or class is responsible for) and pasting it into the prompt. Models tend to produce more consistent code when they know the existing structure instead of guessing it.

And even for small prototypes, write a few simple tests or at least a manual checklist for the core mechanics, so regressions show up early.