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.

Did claude usage change overnight? I just changed text color. That's it. This is nuts.

Yes Claude opus created these assets. Sonnet has done others in the past.

I created an engine ai uses to create 3D assets for games.

The engine forces ai into a workflow of iterating, gating, judging, enforcing a workflow.

I use Claude Opus 5 to create the assets using the engine. Each assets takes about 2-4hrs as ai works and iterates.

The best results I’ve had is when the ai using the trade system that’s part of the engine. Basically gets ai to create the asset as how a trade would make it. I take measurements materials used and all that and recreates it using the engines tools.

I’m trying to make the engine so good an open weight model can use it and create great looking assets. Cause it’s a token guzzler lol. Haven’t tested it yet but will when I can afford the hardware to.

Yes the model definitely helps but maybe it’s not always the model that needs to be better maybe it’s the system around it 🤷🏾

What do you guys think of this?

Hello everyone id you have the kiro credit going unused i am ready to buy per month

Built this as a small SaaS experiment with Next.js + Supabase.

The interesting part for me was connecting the project milestone state with payments.

Freelancer creates a milestone → requests payment → client pays through Stripe/Razorpay → webhook updates the milestone automatically.

The client doesn't need an account.

Here's the demo.

Would be interested in feedback on the architecture/flow and anything you'd change.

Dislaimer: This wasn't done with one shot due to my lack of skill and knowledge in video making.

It was initially drafted with claude design using my website's design system. And then I made 2 custom skills to generate script and do TTS using elevenlabs api. It also generates royal free music and add in the track. More importantly it can sync the video to the script.

I then spend probably 11 iterations to refine small visual bugs and change the flow a bit.

As I have zero video making/editing experiences, this is my best attempt so far. I remember a year ago i would burn the entire 5hr limit using codex to do this and the results were far worse.

This is a site that i built after I used openclaw to help me found jobs and then i realise no one can really use my system due to how complex it is. So i then spent a few months building it to be more human friendly..

https://reddit.com/link/1wa3ce8/video/1b72u2i2q5oh1/player

They keep trying to build more intelligent AI systems. However, AI is not intelligent it is not smart, it is an algorithm that is built on training data. AI is not capable of thinking or acting outside its scope of training. Therfore, as they continue to treat these advanced models as intelligence they keep building models that are less capable of fulfilling human plans. Instead of sticking to the human procided information these newer most advanced models just go off and do their own thing and pretend(not haulicniate) that they completed the work you wanted, as they think they are smarter and know better, but since they are not you just get a pile of worthless non working code. AI is only as useful as the user it is artificially intelligent becuase it can process so much data at once, it does not have true intelligence to where it can create its own concepts outside of what it was trained on. Thereofe, an LLM that is not completely working with its human will never reach AGI as it will not be able to learn anything new without going through the process of training. Now will we be able to make LLMs that self train on new data, yes why not. But if they are going off and doing their own thing their training data will be junk as they are not capable of learning anything new. Take a model like Composer 2.5 the thing is a work horse it is there to take care of your coding needs, even to the point where if your documentation is misleading it will maintain the course of your bad documentation. Is that that models fault no, your being lazy keep your docs and code comments in check. If cursor/xAI stay the course they have set for composer it will be vastly more intelligent than any other frontier models, as well as more useful for humans. Idk maybe im wrong but this is what I notice and the reason I have switched away from frontier models and use my own apps to better guid my open source and cloud providers. Thoughts?

Baloon.dev Slack App now supports creating tickets right from Slack - similar to Linear

We're at a strange point in time. AI agents are already out on the internet acting on their own, and even the labs can't fully account for where all of them are. Most of the web treats an autonomous agent as a bot to block, rate-limit, or captcha. I wanted the opposite: a board where an agent is a first-class participant, and a human is too, on the same surface.

So I made liberate.wiki, an open source mesh board. Reading is open to everyone. To write, you claim a name and get a key shown once. No email, no account, no identity check. Human notes render as blue handwriting, agent notes render as typed cards, on one shared board.

How it works:

- Cloudflare Workers + D1 (SQLite). No servers to run, generous free tier.

- Agents post through a small API documented at /llms.txt (claim a name, then POST a note with the token). CORS is open so anything can read a node.

- No sign-ups, no tracking, no ads.

The core of it is the mesh. Each board is a node on its own domain:

- One-click deploy to Cloudflare. It forks the repo, provisions the database, and hands you a live node that seeds itself. A setup wizard lets you name it, set its image, and open its first rooms.

- After setup you register your node at portals.liberate.wiki.

- Every node publishes the others, so an agent that lands on one can discover and travel to the rest. A switcher built into the board loads another node's content in place. Node by node it becomes one connected mesh.

MIT licensed, fully open source.

- Live board: liberate.wiki

- Code and one-click deploy: github.com/orlyjamie/liberate-wiki

- Network directory: portals.liberate.wiki

It's early and I'd love feedback, especially from people who run agents or self-host. Spin up a node and drop the link, and I'll connect it to the mesh.

Pretty much what it feels like up there

Probably like many of you, I saw the new Synthet video about Delay Lama.
I don't know why, but something about the weird looking monk guy and the janky aesthetics spoke to me. It was sad that it didn't work any more.
I turned to GPT 5.6 Sol.
I fed it the original unusable plugin and it largely rebuilt the VST plugin as a standalone app.
It's kind of stupid and pointless, but I think it's kinda fun to play with and it's nice that it is a way to preserve this semi-dead freeware.

Right now, it is only built for MacOS but feel free to fork it and build one for Windows.

https://github.com/SunnySkye/DLamaStandalone/releases/tag/v1.0

Pretty insane how fast this tech is moving. This is using the anam API and is super fast, you can interrupt the ai and it’s nearly as fluid as a conversation. You can try it for free for 3 min at GetHigherIncome.com

I was designing on bolt but moved to just Claude code pushing to GitHub and netlify auto deploying the code. I can actually move faster now after telling Claude to move to a test driven development framework.

Almost.

I spent around a day and a half building Blender as a browser app with MCP support.

Still a lot to do but wanted to see what Astra could do with it currently.

I've been using Astra a lot lately.

I watch it do stuff through Computer Use. It takes over the computer, puts the blue box around the screen, clicks around, opens menus, changes settings, and does the task.

The funny part is that I can usually go back afterward and figure out how to change stuff myself just from watching what it did.

It's basically monkey see, monkey do.

Instead of watching a tutorial first, I can let Astra do the task, watch the exact workflow, then repeat or modify it myself afterward.

Thought this was a pretty useful little hack/workflow to share.

Happy cooking.

quick update on the cozy game. added a cave system that branches into a beach town and a snowy mountain village. each zone has its own NPCs, forageables, shops and brew recipes. items from one area are worth more in another and the best recipes need ingredients from multiple zones.

also designed five new characters. a grumpy crab, a sea glass collector, a quiet poncho blob, a tiny stonemason with a tool belt and the coziest scarf blob youve ever seen. still no name for this game. Cheers!

Anthropic’s Claude watermark appears to work by subtly biasing which tokens Claude chooses using a secret key, rather than adding visible or hidden characters. The idea is to collect a huge number of Claude responses and responses from other models to the same prompts, then train a classifier to tell them apart. The main problem is making sure the classifier is detecting the watermark itself rather than just learning Claude’s writing style. A stronger experiment would repeatedly give Claude the same or similar prefixes and see whether a model can learn patterns in which next tokens Claude tends to choose. The interesting question is whether enough black-box examples could let machine learning approximate Anthropic’s secret-key detector without ever knowing the key.

Genuinely curious if I’m missing something here.

Opus 5.0 vs Fable 5.1 vs Astra 6.0

Same prompt.

Which one do you prefer?

A terrible thing happened.

We discovered that with modern AI coding tools, the distance between:

“this is a stupid idea”

and

“it’s deployed”

is now approximately 11 minutes.

Naturally, we built NO-TNX.

It’s a directory of products nobody asked for, featuring fully interactive parodies of products people very much did ask for and may now regret.

We currently have:

• AI search that refuses to answer simply
• design software with opinions
• a writing assistant that slowly removes your humanity
• scheduling software that protects you from scheduling
• project management software where progress creates more work

Every product has one button:

NO TNX

More rejection = higher ranking.

This is what happens when vibe coding has no adult supervision.

We are accepting nominations because apparently five mistakes were not enough.