What's worked best with Gemini such I made a DSL that transpiles to C with CUDA support to train small models in about 3 hours... (all programs must run against an image data set, must only generate embeddings)
Do not; vibe code from top down (ex. Make me a UI with React, with these buttons and these behaviors to each button)
Do not; chat casually with it. (ex. I think it would look better if the button was green)
Do; constrain phrasing to the next data transform goal (ex. You must add a function to change all words that start with lowercase to start with uppercase)
Do; vibe code bottom up (ex. You must generate a file with a function to open a plaintext file and appropriate tests; now you must add a function to count all words that begin with "f")
Do; stick to must/should/may (ex. You must extend the code with this next function)
Do; constrain it to mathematical abstractions (ex. sys prompt: You must not use loops, you must only use recursion and functional paradigms. You must not make up abstractions and stick to mathematical objects and known algorithms)
Do; constrain it to one file per type and function. This makes it quick to review, regenerate only what needs to change.
Using those patterns, Gemini 2.5 and 3 have cranked out banging code with little wandering off in the weeds and hallucinating.
Programming has been mired in made up semantics of the individual coder for the luls, to create mystique and obfuscate the truth to ensure job security; end of the day it's matrix math and state sync between memory and display.
THis is remarkably similar to the process we had to follow a couple of decades ago, when offshoring to IT mills: spell out every little detail in small steps, iterate often, and you'll usually get most of what you want.
This. I find constraints to be very important. It's fairly obvious an llm can tackle a class or function. It's still up to the human to string it all together. I'm not quite sure how long that will last though. Seems more of an engineering problem to me.
At the end of the day you absolutely can get good outputs from these things if you provide the proper input. Everything else is orchestration.
Do not; vibe code from top down (ex. Make me a UI with React, with these buttons and these behaviors to each button)
Do not; chat casually with it. (ex. I think it would look better if the button was green)
Do; constrain phrasing to the next data transform goal (ex. You must add a function to change all words that start with lowercase to start with uppercase)
Do; vibe code bottom up (ex. You must generate a file with a function to open a plaintext file and appropriate tests; now you must add a function to count all words that begin with "f")
Do; stick to must/should/may (ex. You must extend the code with this next function)
Do; constrain it to mathematical abstractions (ex. sys prompt: You must not use loops, you must only use recursion and functional paradigms. You must not make up abstractions and stick to mathematical objects and known algorithms)
Do; constrain it to one file per type and function. This makes it quick to review, regenerate only what needs to change.
Using those patterns, Gemini 2.5 and 3 have cranked out banging code with little wandering off in the weeds and hallucinating.
Programming has been mired in made up semantics of the individual coder for the luls, to create mystique and obfuscate the truth to ensure job security; end of the day it's matrix math and state sync between memory and display.