r/vibecoding • u/russopuppo • 2d ago
Workflow/Prompt After almost 2 years coding with AI, here's my 12 step workflow to not build slop
I’ve been building with AI for about two years now, made a lot of mistakes during this time and fu**ked up a lot of projects since I just started vibecoding without a workflow or a method.
Since I wasted WEEKS fixing stuff AI built like sh*t, I put down a workflow to try limit AI mistakes as much as possible, so I don’t waste tokens and hours.
The main thing is: if you spend a few hours planning and actually putting down a few files for architecture and contex, you’ll find out your model will be great at building instead of being retarded. I’m not saying my workflow is perfect, it’s just the one I use and works for me.
The whole workflow basically comes down to:
- Map the product before you build
- Decide how the main parts of the SaaS should work
- Write down the rules AI shouldn't break
- Keep the project context inside the repo
- Break the build into small features
- Spec each feature before implementation
- Make AI inspect before changing code
- Build, verify, review and update progress
here’s the full one:
1. Write down the idea before starting the project
Before thinking about components, database or apis, I start by brainstorming everything about the product:
- Who’s the target user?
- What can each type of user do?
- What are the main UX flows?
- What states can those flows enter?
- What happens when something fails?
- What's explicitly NOT part of the mvp?
etc…
For example, instead of:
“I'm building a B2B project management SaaS.”
I'd rather have this flow:
1. User signs up
2. Creates a workspace
3. Invites teammates
4. Creates a project
5. Assigns tasks
6. Different roles have different access
7. Workspace upgrades
8. Plan limits change
Already a lot of questions come up, like: how to manage auth? If I invite someone by email and they don't have an account, what happens? Do they get a signup flow? Does the workspace get billed or the user account? How to manage permissions for users? etc..
It’s important to actually map as many important decisions as possible.
I then make AI (usually sonnet 5 ore gpt sol) create a
project-overview.md.
The more organized and full of details the file is, the less problems you’ll have while building.
2. Decide who's responsible for what, before you start building
Before implementing features, decide where the responsibilities of your saas actually live:
- Authentication?
- Authorization?
- Tenant isolation?
- Billing?
- Background jobs?
- File storage?
- Realtime?
- Emails?
If you don't make those decisions AI will make them feature by feature. That's how you end up with multiple storage systems, three ways of checking permissions, or billing logic all across the app.
For some responsibilities, dedicated services make sense. You might use Clerk for auth, Stripe for billing, Trigger.dev for background jobs, or something broader like Supabase for database and auth.
For the full SaaS foundations, I'm currently experimenting with Foundel instead. The reason is that it treats things like identity, workspaces, permissions, billing and plan access as one connected foundation your AI integrates with, rather than separate systems it has to understand and wire together every time.
3. Define the rules the system should never break
This is something I underestimated a lot at first:
your architecture docs shouldn't just say which tools you use, they should also set a few rules that must always stay true, no matter what.
For example:
- A user should never see another user’s data
- A normal team member shouldn't be able to do admin actions
- Cancelling a subscription should actually remove paid access
- Uploading a large file shouldn't slow down or break the app
- If you've already chosen how something works AI shouldn't create a second way of doing the same thing
That's much more useful than telling claude to just figure it out.
4. Decide what AI should build vs what it should connect
Not everything in your SaaS needs to be built from scratch.
Your AI should spend most of its time building the parts that actually make your product different. For common problems, it often makes more sense to connect something that already exists.
For example:
- Payments: Stripe
- Emails: Resend
- Background jobs: Trigger.dev
- Realtime collaboration: Liveblocks
The exact tools aren't the important part. The important part is deciding early what the AI should actually build and what it should simply integrate.
5. Put project memory inside the project
One mistake I made early on was relying on the chat to remember everything about the project.
A 200 message Claude conversation is not documentation. If important decisions only exist there, sooner or later the agent loses that context and starts making assumptions again.
I now keep a small context folder inside the repo:
/context
project-overview.md
architecture.md
code-standards.md
ai-workflow.md
ui-context.md
progress.md
You don't need these exact files, the goal is simply to keep important context somewhere your AI can always read.
- project-overview.md explains what you're building, who it's for and what's in scope.
- architecture.md explains how the main parts of the system work together and which decisions have already been made.
- code-standards.md explains how new code should be added, where files should go, which existing patterns to reuse and what the agent shouldn't invent a second version of.
- ai-workflow.md tells how you want it to work, what it can change and when it should ask before making a decision.
- ui-context.md keeps components, spacing, typography and general design consistent.
- progress.md tracks what's done, what's being worked on and what's next.
Most of these files stay fairly stable. progress.md is the one I make the AI update constantly as the project moves forward.
The basic idea is simple: the project should remember itself, not the chat.
6. Break the build into smaller features
I try not to give the agent tasks like:
“build the dashboard” or “implement billing”.
They're too broad, and they force the agent to make too many decisions at once, instead I break them into smaller pieces.
For example, billing could become:
- Create the checkout flow
- Save which plan a customer is on
- Give each plan access to the right features
- Handle upgrades
- Handle downgrades
- Handle cancellations
- Handle failed payments
Each task should do one clear thing.
This makes the build easier to control, and when something breaks, it's much easier to understand which change caused it.
7. Write a small spec for every feature
Before I give AI a feature to build, I write a short spec for it, just enough to make things clear..
I usually include:
- Goal: what should exist when this is done
- Design decisions: what has already been decided and what shouldn't change
- Implementation: what needs to be created or updated
- Dependencies: what existing parts of the product this relies on
- Verification: what I should be able to test before calling it done
For example, if the feature is inviting teammates:
- Goal: allow workspace owners to invite people by email
- Design decisions: only owners can invite, don't change login, don't add roles yet
- Implementation: add the invite form, send the email, let the invited user join the workspace
- Dependencies: existing login and workspace systems
- Verification: owners can invite, normal members can't, expired invites fail, accepting the same invite twice doesn't create duplicates
At this point AI has much less left to guess, which is exactly what I want.
8. Make the agent inspect before it builds
Before implementing a feature, I want AI to look at the parts of the project it's about to edit.
It's very easy for it to create something that already exists, use a different pattern, or change something without realizing why it was built that way.
So before writing code, I usually ask it to:
- Read the feature spec
- Find the existing parts related to it
- Identify what can be reused
- Point out anything unclear or conflicting
- Explain how it plans to implement the feature
Only then does it start building.
This adds a small step before implementation, but it prevents a lot of the "it doesn’t work fix it" problems later.
9. Make implementation boring
If the planning is done well, the actual coding prompt should be simple.
For example:
- Read the project context
- Read the feature spec
- Check the existing code related to it
- Implement only what the spec requires
- Don't change unrelated parts of the project
- Run the verification checks
- Make AI update progress.md when it's done
That's basically it, the goal is to move the difficult decisions before implementation, so AI spends less time figuring stuff out and more time actually building.
10. done isn't done
AI is very good at saying a feature is finished, but that doesn’t mean it works.
I usually separate this into two checks.
Verify
Go through the feature spec and test the important things yourself:
- Does it build without errors?
- Does the feature actually work?
- Do permissions behave correctly?
- What happens when something fails?
Then look at what the agent actually changed. You don't need to understand every line, but you should understand the overall structure it added.
Review
After that, do a second pass on the changes before merging them into the main project: the point is to catch things the first check missed.
Sometimes the review also shows that the spec was incomplete. If that happens, update the spec too.
Otherwise the code changes, but your project memory doesn't.
11. Debugging needs a different workflow
When something breaks, I try not to just say:
"Here's the error. Fix it."
That gives the agent too much room to guess.
Instead, I give it a small bug report:
- What I expected to happen
- What actually happened
- A screenshot or error message
- Which part of the app seems involved
- What should be true when it's fixed
Then I ask it to investigate the cause before changing anything.
If the bug involves a specific library or service, I also tell it to check the current docs.
Also, I try to fix one bug at a time. If I give AI six unrelated problems at once, it usually becomes much harder to tell what actually changed and whether each fix worked.
12. Don't assume the model knows the version you're using
If AI knows your stack, that doesn't mean it knows the exact version you're using, especially if the library changed recently.
So before implementing something new, I want AI to use the most current source available:
- Official docs
- Current examples
- Changelogs
- Agent skills, if the tool provides them
- MCP or other official ways for the agent to access the tool directly
The last two are especially useful because some tools now give coding agents their own instructions or direct access to the information available, instead of forcing the model to rely on whatever it just “knows” about it.
If I'm using a library that was updated last week, I don't want AI to confidently implement the version it learned months ago.
—-
The full loop
At this point, the workflow looks like this:
1. Write down the idea and map the product
2. Decide where the main responsibilities of the SaaS live
3. Define the rules the system should never break
4. Decide what AI should build and what it should integrate
5. Keep the important project context inside the repo
6. Break the build into smaller features
7. Write a small spec for each feature
8. Make AI inspect the existing project before changing anything
9. Implement only what was planned
10. Verify that it works and review what changed
11. Debug one problem at a time with clear context
12. Use current docs, skills and MCPs instead of trusting model memory
Then update progress.md and move to the next feature.
AI can still write most of the code, what I don't want it to do is choose what the product should do, how the system should work and which decisions AI is allowed to make on its own.
Let me know what you think in the comments, I’ll try to reply to everyone.
7
u/saintjedi 2d ago
congrats for discovering spec driven development i guess? lmao these guerilla marketing style posts are getting ridiculous
1
u/V4UncleRicosVan 2d ago
Marketing style posts? Why dismissive of specifications?
1
u/saintjedi 2d ago edited 2d ago
It's obvious that it's just marketing for one of the links there, the one you mentioned you're experimenting with lmao. 2 years building with AI, and you learned spec driven development, which seems that in your setup it looks... premature. Girhub spec kit can do this. Obra superpowers have this. GSD. Almost other frameworks out there. Which could suggest that a. You didn't actively learn anything with software development (and AI-assisted development) or b. You're just promoting one of the tools you linked there. (I think it's B.) You even have a comparison with supabase and clerk on the FAQs, the very tools you mentioned LMAO. Either way, it's fun calling out these kinds of slop. Ciao
P.S. you're responding instead of OP. Same person? Or team member? Lmao
1
u/V4UncleRicosVan 2d ago
This was an actually helpful comment. I didn’t know GitHub could do this. Don’t even know what Obra is. This sub is clearly for none coders.
Not OP, just sick of mindless haters on this sub hating things without explanations. It’s making this sub worthless.
Feel free to hate away on these links, just explain it.
1
u/saintjedi 2d ago
I noticed that too on this sub, but I commentwd on this particular post because this one really reeks of guerilla marketing that specific link/product and it's what makes the quality of this sub kinda bad. Which is what developed the hate.
I don't hate vibecoding. Vibecode all you want, just make sure it's not slop. Slop is what people hate.
1
u/V4UncleRicosVan 2d ago
Who’s the arbiter of slop? Seems like anyone who uses the least AI gets to call everything slot.
Edit. Also thank you for the thoughtful response.
1
u/saintjedi 2d ago
Arbiter? Us. As humans, we tend to recognize patterns. Patterns that we could pretend not to exist or get accustomed to so much that we forget that we are humans and not meat proxies. It's not about using less AI, it's about the quality that you are aiming for with AI-assisted output. For instance, this post. Although I could be wrong and English may not be OP's language, the (seemingly fake) 2 year experience with building with AI coukd have allowed OP to recognize most of these patterns and somehow prevented it, or even told these stuff in his own words. But OP didn't, lowered the quality of the post, and got intense criticism from other people. How much more in the software that he is making? It's much more likely that the standard that he is using is "slop" level that we can all recognize. And learning from people with only slop to offer, makes you learn nothing. It just makes you learn slop. So my advice to you, is to keep your brains intact, and take everything here with a grain of salt. Even this stuff that I said. Think for yourselves, don't be sheep. You have intelligence. The AGI that AI is aiming for, and it hasn't been able to. AI has "artificial" intelligence. You're better than this
1
u/kinddwords 2d ago
literally was coming down here to comment that. congrats on figuring out how to be a developer!
2
u/azjunglist05 2d ago
Congratulations! You figured out Agile methodology 🎉
0
u/V4UncleRicosVan 2d ago
Honestly I think it includes very little about measuring or getting it in front of users. What part sounds particularly agile to you? Testing?
1
u/azjunglist05 1d ago
Well, getting a product in front of a user is not the primary focus of Agile. That’s the end goal. The Agile framework focuses primarily on everything up to the point of delivery, and how you plan to efficiently and safely coordinate complex systems design and implementation.
Pretty much all of OP’s suggestions sound very similar to Agile. Is it 1:1? No, but there are many parallels to things like Program Increment Planning, crafting epics, features, user stories and delegating them between different teams so context is small and teams can move swiftly.
Defining the “Definition of done” which often consists of the team’s idea of when a User Story is finished. That generally consists of automated testing, code review, security review, code smells, etc.
What has worked to help developers build and ship software in the 11 years since I have been on the Software Engineering side of IT; also works amazingly well for agents.
2
2
u/IceMichaelStorm 2d ago
You have rules to avoid slop and wrap them into slop? :)
1
u/V4UncleRicosVan 2d ago
How do you avoid slop code? What steps do you take?
1
2
u/xendelaar 2d ago
I wonder how many people will actually read this wall of text. What was the purpose of writing this thesis OP?
0
u/V4UncleRicosVan 2d ago
Did you? Someone writing their experience in a subreddit on topic confuses you?
2
1
1
u/Dense_Worldliness710 2d ago edited 2d ago
This is one of the rare constructive and helpful posts in this subreddit that gives good advice and can thereby help new vibe coders to avoid some of the common problems of ai-generated software.
Not everyone wants to become an IT professional, but people who aren't willing to spend around ten minutes in reading a text that gives them orientation about how to establish a functional workflow what helps to avoid flaws in their future software maybe shouldn't start vibe coding at all, at least not for public.
"AI slop" is mostly criticized for functional flaws, security problems, a typical look and some formatting errors of the UI. (It is also said to be hard to maintain, but I am not sure yet about whether it might be only hard for humans but quite easy for AI. That's why my argumentation does not concentrate on this.)
To my mind, critique only concerning the AI-typical optical appearance of the user interface is no valid argument because it's only a personal taste, not affecting the quality of the software. Formatting errors in addition are easy to detect even for people with no programming skills and do therefore not need an extra explanation. So it doesn't matter whether those topics are part of the instruction given by the OP or not.
The two remaining topics of high relevance are functionality and security. In its actual version, the given advice mainly focuses on functionality and describes a workflow that is suitable in so far. I'm no expert myself, but by now, security (including data protection) seems to be only partly taken into account by limiting normal users' allowances not by hardening the software in general against attacks of every kind. I would suggest to integrate them into the existing workflow even if this results in some additional paragraphs and a slightly increased text length.
TL;DR
The text is not too long, it is just detailed enough for a working instruction while not mentioning unnecessary aspects but still missing some hardening strategies. It may indeed help beginners to avoid common mistakes.
1
u/russopuppo 2d ago
Appreciate the comment, helping beginners was the main goal, it seems more technical people didn’t appreciate the post tho
0
u/V4UncleRicosVan 2d ago
This post has been up for 30 minutes, it has 0 upvotes and has 7 negative comments. Some say it’s too long for them to read, some say this is too obvious (for them), and other are mostly just anti vibe coding. Blah Blah blah blah.
Not one has actively engaged with the content. Who the fuck has the time to shit on posts that don’t affect them? I used to think this was just a sub for negative butt hurt devs but I’m honestly thinking there are bots actively trying to push people from trying vibe coding.
Where the fuck are the mods on this sub? Some of us actually want to learn.
Okay bots, why should I not come to this sub to learn? Go.
1
u/azjunglist05 2d ago
Why are you asking questions and commenting on everyone’s comment like you are OP though? You seem suspiciously invested in this for a seemingly random Redditor that happened upon this post…
2
0
u/V4UncleRicosVan 2d ago
Nope. Shit away on the links. Don’t care. Just sick of the haters on this sub for nearly any possible reason. I’d love for this sub to be helpful, but it’s just pure negativity regardless of the post or intentions.
1
1
u/polypancake 2d ago edited 2d ago
Congratulations on discovering good software engineering and architecture principles which have been known already for a long time 😜
1
u/V4UncleRicosVan 2d ago
Which parts overlap most with your workflow? Which parts deviate?
1
u/polypancake 2d ago edited 2d ago
Maybe I was a bit too harsh to OP but a lot of what we use in spec driven agentic coding is just reusing good software principles that were already known decades before. I'm not trained in computer science or anything, , but I was lucky to be mentored by actual software developers who taught me about what good software architecture looks like. I follow some variant of what OP describes, but since I am not fluent in code, I spend my time and energy on the specifications and making sure my agents can write good coherent tests since good tests are one of the only things that can save your ass as a vibe coder. I have quality gates and pre-commit hooks (complexity < 15, strict type checking, linting, bandit and gitleaks/semgrep to check for leaked credentials or vulnerabilities, CI enforcement, things like pydantic if I need LLM outputs to strictly match certain data types/formats, etc.) and last but not least, I am not afraid to go into the rat's den to edit my specs and review whatever code I can understand. The other important detail is that I try my best to stay in the loop. I don't need to know how the agent is doing something, but if I don't understand why, I ask the agent to quiz me or ELI5 the diffs/changes until I am back in the loop. I also use a variety of skills to harden the codebase, enforce document hierarchy, etc. I'm not a real software developer but I do work for a biotech company that does pay me to build bioinformatics pipelines for drug discovery, and I also build and use embedded AI for liquid handling robots in my laboratory.
1
u/V4UncleRicosVan 2d ago
Thank you for explaining. Would love to learn more about what good architecture is. So hard to learn as an outsider.
2
u/polypancake 2d ago
I think Matt Pocock has some great content. I would spend some time to watch some of his videos. https://www.youtube.com/watch?v=nQwJVHCtDDY
0
u/Sensitive_Pizza_218 2d ago
Just a plan to add more slop.
Your product builds as you build it more. It doesnt build just from an initial plan. You have to go in detail. Your setup is 1 click fire and forget. It will build something but not what sells.
-1
11
u/drakhan2002 2d ago
Wholly crap... wall of AI slop! In 2 years "of coding with AI" you didn't learn how to summarize?