This happens when you prompt it poorly. If you want to avoid slop, the first step is to write an extensive BRD. Read it, understand it, make sure it has everything needed. Then write a solutions architecture document. Read it, understand it, make sure it is fully specified including how things are structured, architecture, principles etc. You can use AI to write these documents. Just make sure to read them, and edit them as needed.

When you have your functional spec, and your tech spec, ask it to implement it. Additionally add some basic rules, say stuff like "don't add any fallback mechanisms or placeholders unlessed asked. Keep a todo of where you're at, ask any questions if unsure.

The key is to communicate well, ALWAYS READ what you input. Reivew, and provide feedback. Also i'd reccomend doing smaller chunks at a time once things get more complicated.

▲

albertgoeswoof 5 days ago | parent [-]

When do you read the code

	▲	swalsh 5 days ago \| parent [-]
		While it's being generated, I'll spot check it, and after I test the code i'll peek in more detail at it. I review the code in much the same way I review code from a human dev. I almost never look closely at ALL lines. I'll do a quick look through just looking to see if anything jumps out, and then for the areas I intuitively know there might be some funny business I'll do a deeper dive into the code.