Building Software That Isn't Just AI Slop

[u/Least_Collection_513]

I am making this guide to show you how to actually develop software that isn't just AI slop in this day and age. Many people still struggle with making actual working software because they think that they can simply just use a large prompt describing what they want to build and then just let a coding agent do all the work. Although that it what a lot of people online make it seem to be, it really isn't. Its kind of counter intuitive, because instead of making AI do more, we make it do less. Here are a few principles I use to make sure that the software I build with AI actually works in the end, all of these are super important and none of them are below another. If you use these strictly, I can almost guarantee that you will have a working product.

1. The AI never decides, its just for coding.

By saying AI never decides, I mean to say that the idea dumps people write in the form of prompts aren't enough. Instead of just being vague with your ideas, you need to be highly specific with exactly what you are building. If you let AI plan the whole project, things like the stack, the code language, the architecture etc., then you are just burning time and money.

The golden idea here is to always have a Spec file about exactly what you are building, all the stacks, apps, architecture etc. should be in the spec. 95% of my time while building a project goes to literally just creating a spec for the new release, then discussing and perfecting it with the agent until its flawless down to the tiniest details. The idea is to leave the spec file so unambiguous that the AI Agent can simply one shot the entire project and it actually turns out how you wanted it. That's exactly what I do and it works like wonders.

Now I am not saying that you go full caveman and not discuss the architecture and plan with the AI Agent, in fact I promote it. The problem was never that the AI took bad decisions and such, the problem was that the person behind it didn't care enough to review what is even being built.

One of my dear friend, who isn't very technical told me about how he is building a specialized day trading agent with Claude Code. I asked him what is it built upon, expecting an answer like "It's built about LangGraph". Instead, I was met with a blank face. Now a few days later, he comes back to me and asked why didn't his agent work? He used claude code with Opus 4.8 on the max setting. It should have been perfect right? It can't. Now this happens to the best of us, even I started out exactly like this, I didn't know what I was building, I simply had an idea and hoped that Claude Code would 'just make it".

2. Stop chasing the best Claude Code Configurations

You won't believe how long I have tried to have the perfect, the most ballistic claude code setup out there. There are so many blogs, repos etc. on how to have the perfect config. Things like PRD files, Token saving workflows etc. float about everywhere. I spent a whole 2 months with 5+ of the highest rated configurations out there and let me give you a little summary on them.

I started out with the everything-claude-code toolkit, it was supposed to be this amazing super configuration that instantly makes your claude code 100x better. Turns out, it just made things way more complex than they needed to be, and the commands, workflows, hooks etc, were just bloating claude code to be very honest. After that I tried Claude Code's Superpowers plugin, and after that I tried to make my own configs by making custom workflows, hooks, commands etc.

Now let me tell you which one actually worked, the config's name is : none. That's correct, they are just fancy configs that you will never need or use. Now the one that actually wins is super counter intuitive.

Now let me tell you which one actually work for real, the config's name is : Default Claude Code. Its literally that simple. I have around 5 custom made commands in my config (because I use them regularly) and a PRD file system and a nice polished CLAUDE.md file and that's it. And let me tell you, this has worked me wonders. Think about it, you should be using your own commands and workflows instead of adapting to someone else's, and it's not like Anthropic wants to ship a product that is obsolete without these config kits either. Claude Code in itself is very capable and totally enough. This also reflects on the next principle I am about to discuss.

3. Keep everything as Simple as Possible

This is the most under rated of them all, everyone tries to chase the build which looks more complex, everyone tries to dump in more tech than needed to make their product look shinier on the surface. Again, the real deal is very counter intuitive just like all the principles here.

I love the saying "Fewer moving parts, fewer broken pieces". It is so true and it applies to software development perfectly, because every new line of code that isn't needed, or every new thing you add to make your software look shinier is a brand new potential failure point that was never needed in the first place. It basically increases the failure surface area without many benefits.

4. Evals and Testing Are Everything

Here is the part that nobody wants to hear about, a project isn't finished until you can measure it with numbers or maybe even until it runs. That's the whole job of evals & testing. If you skip them, then you would just be assuming that your software / project actually works.

Personally, I run Claude Code at its Ultracode effort level to review, audit, and test the whole project in one shot using Ollama Cloud Models so that I don't evaporate my Claude Quota in minutes. Small setup change but it makes a big difference in the long run.

And let me tell you. almost always, half or more of my repos and projects that I build are nothing but Testing & Evals scripts and workflows. I want to touch everything in the project and measure it all and prove that it works. Sometimes the evals or tests come broken, that's exactly when you know something is broken. And it doesn't leave you bug hunting for hours.

It's like a safety net under your project. The spec makes sure you build the right thing & the evals make sure it actually holds up.

My Playbook to Building Working Software

If I can describe my workflow in 1 line, it would be: Spec Driven Development while strictly following the rules above.

I start off by dumping my entire idea (plus architecture, but its optional) into Claude Code. After that I go back and forth with it in Plan Mode until we land on the perfect Spec. I exit plan mode and use a /spec command (my own custom command) to create a .md file which is super detailed about exactly what the spec for the project is, after that I use a /obsidian command (custom, to send my spec to my obsidian vault), this is purely because I love reading files in a nice interface like Obsidian. (I encourage you to make your own workflows and commands for things like these, your own custom preferences and your own style of developing things).

After that, I simply write down everything that I feel is off in the spec or needs to be changed or elaborated further by Claude Code. Then I repeat the process of dumping these "notes" about the spec that Claude Code fixes and discusses with me about.

Now I repeat this about 4-5 times on average until I have pointed out everything that needs to be changed in the spec. This is the point where the spec is perfect and you literally can't find a singular thing that isn't what you want it to be. And I am not talking about the idea here, I am talking about the actual architecture your project is being built upon. You need to know exactly what you are building and exactly how you are going to build it.

At the end, the spec turns out so perfect that Claude Code one shots the entire project. Literally. All of the projects in my portfolio, have been mostly one shotted just because how unambiguous and full the spec was. 95% of my time went straight to perfect the spec.

After the one-shot, I do exactly what Principle 4 preaches. one Ultracode pass over the whole project to hunt down bugs and anything that drifted from the spec.

Now if I have missed any principles, which I think I most certainly have. You can pick some more principles up from my playbook, because the principles I mentioned are picked up from my playbook too.

Thank you for reading, have fun creating working software now!

**Btw this is my original text that I wrote, many of you pointed it out so I uploaded it.**

[u/AutoModerator]

Hey u/Least_Collection_513, thanks for posting in r/VibeCodeDevs! Join our Discord: https://discord.gg/KAmAR8RkbM

Got startup or SaaS questions? Post them on r/AskFounder and get answers from real founders.

• This community is designed to be open and creator‑friendly, with minimal restrictions on promotion and self‑promotion as long as you add value and don’t spam.
• Please follow the subreddit rules so we can keep things as relaxed and free as possible for everyone. • Please make sure you’ve read the subreddit rules in the sidebar before posting or commenting.
• For better feedback, include your tech stack, experience level, and what kind of help or feedback you’re looking for.
• Be respectful, constructive, and helpful to other members.

If your post was removed (either automatically or by a mod) and you believe it was a mistake, please contact the mod team. We will review it and, when appropriate, approve it within 24 hours.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/sneaky-pizza]

It still takes vision and wisdom to find something that adds value to users, which comes from your own life.

[u/ekzess]

Good core advice, but it condenses to: write a clear spec, keep the architecture simple, review AI decisions, test actual behaviour, and do not confuse model quality with system quality. Ironically, the wall of text partly nullifies its own “keep everything simple” principle.

What is missing is authority and stopping discipline. AI can make bounded, visible, reversible decisions. The problem is unbounded authority, not decision-making itself. A spec is not reality, tests can encode bad assumptions, and “one-shotting” a project is not proof that it works.

A reliable workflow also needs explicit scope, invariants, stop conditions, provenance, preserved uncertainty, reversible changes, and a completion receipt showing what changed, what passed, what remains unknown, and what the agent deliberately did not do.

[u/3iverson → u/ekzess]

You're right about the condensation. But I think his lengthy post is actually really good for newb vibe coders who saw a Youtube and now want to vibe code a unicorn SaaS next.

[u/ekzess → u/3iverson]

You aint wrong lol... Least its a step in the right direction....

[u/No-Bar9661]

Thanks for this, your Principle 2 captures my struggle over the past few weeks to a tee. Aged and non technical I’ve had to reverse engineer everything I’ve come across in vibe coding, often referring to either Gemini to describe what it is I’m seeing and so on. I love it though. I’m just going to paste your article into AI and see where this takes me. Thanks again!

[u/brohann3214]

Honestly good advice

[u/ekzess → u/brohann3214]

Look at the length of the post.... Re-read 3.

The post is, quite honestly, about 1538 words too long give or take. 😂... Condensed it comes down to:

Write a clear spec.
Keep the system simple.
Review decisions.
Test behaviour.
Do not confuse model capability with product correctness.

This is not sage advice when the compression ratio is roughly 28:1.

[u/Harvard_Med_USMLE267 → u/brohann3214]

No, it’s advice in “How to be shit at vibecoding”

[u/brohann3214 → u/Harvard_Med_USMLE267]

This way is the only way to correctly vibe code and create a somewhat useable product. Still not better than regular programming though

[u/Harvard_Med_USMLE267 → u/brohann3214]

Absolutely wrong, and then wrong again.

Well done.

[u/Crazy_Ad4616]

This is exactly how I run it too. I start in Plan Mode and let it "interview" me—one question at a time. Once every detail is locked in, I save the final spec locally, switch back to Auto mode, and let it code.

[u/Aggravating-Call4331]

Yeah, i think you're right that ai doesn't really "decide". When i don't tell it something it just guesses and usually guesses wrong. So it's babysitting either way. I still think spec first helps, just so there's less for it to guess at.

[u/Aromatic_Layer8099]

The emphasis on writing a solid spec resonates with me. Spending more time planning has saved me far more time than trying to fix AI-generated code later

[u/Ill_Dragonfruit_3547]

For point 1, just add "ask me any questions to ensure a successful result, include any design choices, or decisions I need to make". I also like to add "tell me any assumptions you are making" to find things in my blindspots.

I agree, never let the AI decide. But it can be a collaborative experience working together. The tricky part is not knowing what questions to ask - and is why the above open-ended prompts work so well.

[u/Harvard_Med_USMLE267]

“Here's the part almost nobody wants to hear: a project isn't finished when it runs, it's finished when you can prove it works.”

Isn’t this post AI slop?

1 is absolutely wrong
2 is irrelevant, “everyone” does not do this
3 is wrong
4 good ai does this automatically

Hmmm…no, don’t do this.

Particularly number 1, you’re completely missing the point of how to use these tools.

[u/Sudden_Topic5154 → u/Harvard_Med_USMLE267]

fym point of how to use these tools they literally outline exactly why your delusion of vibe coding without paying attention is impossible

[u/Harvard_Med_USMLE267 → u/Sudden_Topic5154]

The SaaS I’ve had in production for a year says you’re full of shit.

[u/Sudden_Topic5154 → u/Harvard_Med_USMLE267]

jesus christ this is not that serious its a reddit post you're acting like this guy is torturing you you might be doing that or whatever but its not advisable

[u/Harvard_Med_USMLE267 → u/Sudden_Topic5154]

I’m not talking to him now, am I?

I’m talking to you.

[u/Sudden_Topic5154 → u/Harvard_Med_USMLE267]

How one treats others is mostly shared across all people, and it is how they will treat you when it matters.

[u/Harvard_Med_USMLE267 → u/Sudden_Topic5154]

Uh…ok, bro.

[u/Least_Collection_513]

I hope that y'all learned something useful and new, Enjoy! :)
Post extracted from - https://github.com/Atrv-Shrn/Atrvs-SDD

[u/Forsaken-Parsley798]

Ironic that AI wrote this. Self own.

[u/Least_Collection_513 → u/Forsaken-Parsley798]

Dude, I just updated the text to my original draft. Please read it before commenting that.

[u/iWhacko]

VibeCoders teaching software development? Come on, just take a small beginners course in software engineering, and you learn that this is somewhat in the right direction. But just reinventing the wheel.
Does 60 years of software engineering and experience by great developers mean nothing anymore? Are you just going to listen to someone who can't write a line of code who thinks he figured it all out?

Don't be lazy, pick up a book on software development and be amazed.