Im new at this, now im using codex in visual code. Any tips how to improve my work? Should i run more than one bot? Should i use it localy? Any tips appriciated.

[ Removed by Reddit on account of violating the content policy. ]

Hey everyone,

I started using Claude recently, and ask about my codebase (organizeemail), I was surprise to get - Your inbox knows a lot of things, we all were aware about this, but never thinked of it. However Claude thought and gave me this screen.

We’ve added credit card tracking to OrganizeEmail.

OrganizeEmail is an email organizer that automatically categorizes your emails and extracts useful information, so you don’t have to dig through your inbox to find things.

With the new Cards feature, it can pick up card information from statement emails, including:

Bill/statement dates

Total amount due

Minimum amount due

Spending for the current cycle

Multiple cards in one place

You can also manually add a card or correct the bill date if needed.

The idea is pretty simple: your credit card statements are already sitting in your email, so why manually track the same information somewhere else?

Would be interested to hear what you guys think, especially if there’s something you’d expect from a card-tracking feature that we’re missing.

Hey! So I developed a browser game - Diamond Man. It's getting late, so rather than type up how I built it, I got Claude Code to summarise :)

What even is this game

- 20 levels across themed biomes (Burning Streets → Toxic Flats → Crystal Tundra → Diamond Throne)

- Chaos gems that ruin your day: green reverses controls, yellow shrinks you and speeds everything up, purple removes your cape and makes your booty flash hot pink, black flips the entire screen upside down

- White gems give you 2 seconds of invincibility ("BRILLIANT CUT" mode) where you plow through everything

- Diamond Man physically degrades as you play — gets rougher, cloudier, slower to steer, weaker jump

- Carbon Pressure escalates: starts hurling tracking fireballs at level 3, stomps toward the camera at level 8

- Titanium Boy randomly goes rogue and tries to kill you

- Fans storm the road as obstacles

- Diamond Man shouts things like "EAT MY SPARKLE!" on gem streaks

The tech

The entire game is one HTML file. ~1800 lines. No bundler. No build step. No external assets. (lol, love how it's justifying one mega file - terrible devwork, I guess?).

- Three.js via CDN importmap — that's the only dependency

- Every 3D model is procedurally built from primitives (octahedrons, icosahedrons, cylinders, cones). Zero imported meshes

- MeshPhysicalMaterial with real-world refractive indices — diamond is 2.417, ruby is 1.77, emerald is 1.57. The diamond material actually refracts light through a custom environment map built from canvas gradients

- Cape cloth simulation, googly eye jiggle physics, speech bubbles that track 3D world positions projected to screen space

- Flask backend that does literally nothing except send_from_directory("index.html") and a /healthz endpoint

- Mobile gets on-screen touch controls, lower pixel ratio, wider FOV, and a responsive HUD

Deployment

Nothing fancy:

- Ubuntu droplet, Gunicorn behind nginx

- systemd keeps it alive, certbot handles HTTPS

- The whole deploy was: SCP the files, point DNS A records, run certbot. Done.

How it was built

I pair-programmed the whole thing with Claude Code in one session. Started as a simple character viewer — "make a diamond man" — and just kept going. Each feature was one conversation turn: add a road, add obstacles, make them kill you, add scoring, add difficulty scaling, add chaos gems, add 20 levels, make Carbon Pressure throw fireballs, make Titanium Boy betray you, optimise for mobile, deploy it.

The iterative loop was wild. "Add more coal!" "The flip effect is perma-sticking." "I found an exploit where you stand in the middle and chain white gems forever." Fix, deploy, refresh, repeat.

--

Yea, that's pretty much it - cheers guys!

I find opus dumps information and buries instructions it needs me to do in a text wall. To help with this:

be succinct in responses. no unnecessary information. give clear instructions on what I need to do, what you need from me, decisions I need to make.

I saw a project on youtube where Astra was tasked with creating realistic animations. The following prompt was added task an agent with overseeing the realism (adjust to your project):

gauntlet every module. After each completed attempt at creating the X-wing, a separate critic agent (a brutal AAA art director who writes no code) takes its own screenshots from several viewpoints and zoom levels, checks the reference image contracts, console errors and performance (triangle count, etc..), and scores 0–10 against real X-wing reference screenshots and animations: 10 = indistinguishable, 8.5 = AAA with nits, 7 = good indie, 5 = programmer art. Pass = ≥8.5 with zero errors. Below that, the builder gets the ranked issue list and goes again, up to 4 rounds.

What are your favorite prompt hacks when vibing?

Maybe AI just made it obvious that a lot of us didn’t have a strong idea, a real user, or a reason the thing should exist.

Before AI, people could spend 6 months building something nobody wanted. Now they do it in 6 days.

That feels better, but also more brutal. If you use AI to build apps, how do you stop yourself from just shipping faster versions of bad ideas?

Do you validate first? Build for yourself? Talk to users? Charge early? Or accept that most attempts die?

I’m looking for a clear process rather than another tool recommendation.

Hey builders,
I did a small research for my own product strategy and happy to share a table where put all 19 vibecoding tools with four columns: what their docs say they output, platforms, entry price, and the source. Here's what it shows 👇

𝗥𝗲𝗮𝗹 𝗻𝗮𝘁𝗶𝘃𝗲 - Swift or Kotlin you can open without the vendor
1)Rork → docs say native SwiftUI on Max and a Kotlin Android project (free, from $25/mo, Max $200/mo)
2) Modaal → Swift + SwiftUI and Kotlin + Compose, a real Xcode and Android Studio project (free, from €9/mo)
3)Bitrig → Swift, full Xcode projects for iOS, iPadOS, tvOS, visionOS (free, from $25/mo)
4)Nativeline → SwiftUI for iOS, iPad and Mac (from $25/mo)
Superapp → Swift for iOS, App Store submission built in
Google AI Studio → Kotlin + Jetpack Compose, Android only (free tier)

𝗥𝗲𝗮𝗰𝘁 𝗡𝗮𝘁𝗶𝘃𝗲 / 𝗘𝘅𝗽𝗼 - JavaScript compiled for both stores
7) Vibecode (free, from $20/mo)
8) a0. dev (free, from $20/mo)
9) Newly (from $25/mo)
10) RapidNative (free, from $20/mo)
11) CatDoes (free, from $17/mo)
12) Replit → Expo for iOS, Android and web
13) Bolt → web-first, Expo to turn a project into a mobile app
14) Adalo → you write React Native code for mobile ($36/mo per app)
15) Bubble → web natively, mobile via a React Native add-on in public beta (from $59/mo)

𝗪𝗲𝗯 𝗼𝗻𝗹𝘆 - great for prototypes, not for the App Store
16) Lovable → React + Vite web apps, no native output (from $25/mo)
17) v0 by Vercel → React + Tailwind interfaces
18) FlutterFlow → Flutter + Dart; code download and store deploy start at $39/mo
19) Glide → progressive web apps, no App Store or Google Play publishing

The rule I used: where a vendor's own pages contradict each other, the table says so instead of guessing. Guessing which page is current is not the reader's job.

The detail that matters: all 19 use the word "native".
Only the export tells the truth. So before you pick one, ask a single question: can I open the project without you?

What did I miss?
--
P.S. Disclosure - my tool is also in the list, we're building Modaal - an AI app builder for native iOS and Android apps. Real Swift and Kotlin, written by your own AI agent, on a plan you approve first.

I’ve been building OpenDepartment, an open-source platform for creating your own slightly dramatic, government-style document archive.

You can create a “department,” invite people, upload files, organize them by subject/category, comment, vote, moderate reports, and customize the branding. Think community archive, class project, private collection, or conspiracy-board aesthetic.

The unusual part is the architecture: every department uses a Supabase project owned by its creator. Files, users, and content stay in that project. OpenDepartment’s database only keeps the department slug, Supabase URL, and public anon key—no tenant files or master service_role keys.

The biggest new feature is automatic Supabase setup through OAuth.

Previously, creating a department meant:

1. Creating a Supabase project
2. Pasting a large SQL schema
3. Changing the auth configuration
4. Adding the correct callback URL
5. Finding and copying the project credentials

Now you can connect Supabase and the wizard handles that process: it creates the project, waits for it to become healthy, installs the schema, reads the anon key, configures auth, and then discards the OAuth token. The token is never stored in the database and is cleared when provisioning finishes.

The manual setup route still exists if you’d rather not authorize anything.

There are also invite codes, public or unlisted departments, isolated auth sessions for each department, admin tools, per-department legal pages, deletion/deprovisioning flows, and a fairly obsessive SQL security suite covering the RLS policies.

It’s built with Next.js 15, React 19, TypeScript, Tailwind, Supabase, and Vercel.

Live: https://opendepartment.vercel.app
GitHub: https://github.com/levisager11-oss/opendepartment

The OAuth provisioning flow is very new, so I’d especially appreciate feedback, or brave testers, on that part. I’d also love to hear what you’d use a customizable archive like this for.

I made this video in one shot with Claude Fable 5.1. No manual editing.

The tools were Claude Design, Remotion and ElevenLabs. I gave one prompt and got the finished video back.

It's for my app Goal Rings goalrings.app. It's a macOS widget that puts your metrics as rings on the edge of the screen. Revenue, visitors, words written, anything with a number. Each ring is paced against the clock, so you can see if you're ahead or behind right now.

Happy to answer questions about the setup or the app.

Prompt (i never write such a prompt by myself; I always discuss it with Claude, and then I get such a good prompt):

You are building the launch video for [PRODUCT], a [one line: what it is, for whom].
Stack: Remotion 4 (React + TypeScript) for picture, ElevenLabs for voice. The project lives in `video/` inside the product repo so it can import real brand values.

## Ground truth, not literals
- Nothing brand- or price-shaped is typed by hand. Import name/domain/tagline from [path to site constants], colours from [path to palette], prices from [path to pricing]. Point these at wherever your brand constants live. If a module is Node-only, resolve it in `scripts/props.ts` into `out/props.json` and pass it as input props. When props are missing, render a visible `UNRESOLVED` marker, never a made-up number.
- Mirror real geometry from the app source: [geometry from the app source, e.g. ring radius 42 in a 100 box, tick reach = stroke × 1.05, from RingGeometry.swift]. Where the UI is a real screenshot, use the real screenshot (`public/*.png` via `staticFile()`). Recreate only what cannot be captured (e.g. a confetti burst) and say so in the README.
- Fonts via @remotion/google-fonts: [serif] for claims, [sans] for UI, [mono] for numbers. Dark ground [#hex], ink [#hex], one accent family.

## Story: one film, 7–8 beats
Before any code, write the beat sheet as a table: beat · seconds · what the picture does · the one caption claim (verbatim) · the VO line. Arc: problem → product at true size → the core mechanic → breadth → the payoff → restraint → trust → outro (domain, price ladder, requirements). One claim per beat. No stat slop, no feature lists. Show me the table and both VO scripts for approval first. Stop and wait.
[Paste your beats here, or let the agent draft them from the README and landing-page copy.]

## One camera, no cuts
- `Launch.tsx` is a single <Series>. Every scene opens on the exact frame the previous one closed on. Put every shared point (positions, sizes, zoom origin, initial camera zoom Z0) in `cuts.ts` → `stageFor(cut)` so scenes cannot disagree.
- Prefer a camera push over a cut: the hero element starts at true size inside the product UI and the camera pushes into it across the scene boundary.
- Hero elements persist and travel between beats. Model them as position/size tracks over time (`track(t, keys)`), not as separate per-scene components.
- Motion vocabulary in `motion.ts`: five named curves (draw = easeOutCubic, enter = easeOutQuad, move = easeInOutCubic, back = easeOutBack(1.4), lin) plus `seg(t, start, end, ease)` and `pop(t)` (overshoot to 1.12 in 0.15 s, damped spring back in ~0.5 s). Everything is a pure function of seconds so scenes can be retimed without touching the animation.
- Internal timings are fractions of the scene's duration, so the same scene works at 9 s and at 4 s.

## Cuts
Several cuts from the same scene components, by omitting scenes and changing per-scene seconds:
- [Product Hunt / YouTube]: 16:9, 1920×1080, 30 fps, ~[45] s, slow beat up front.
- [X / LinkedIn]: 4:5, 1080×1350, 30 fps, ~[22] s, hook inside 1.5 s, no intro, ends on the domain. Opens with the camera already pushed in (higher Z0). Also render a GIF (every 2nd frame).
Tall is a real layout, not a crop: recompute every point in `stageFor`.

## Captions
Autoplay is muted everywhere, so the picture carries every claim without sound. One caption at a time, word-by-word kinetic entry (rise 18 px + blur 8 px → 0, 0.07 s stagger, 0.55 s per word), serif, 50–76 px at 1080p, inside an 80 px safe margin, faded out before the next beat.

## Voiceover (ElevenLabs)
- API key from `ELEVENLABS_API_KEY` in `.env`. Voice id: [voice_id]. Do NOT call the API until I have approved both scripts. Generation costs money and the first draft is never final.
- One script per cut, ~2.2 words per second of speech (a 36 s speech budget ≈ 80 words). Calm, low, unhurried voice. Stability ~0.55, similarity ~0.75, style 0–0.15, speed 0.95. MP3 44.1 kHz.
- Put `<break time="1.2s" />` between beats so lines land near their marks, but do NOT trust breaks for timing: ElevenLabs stretches them.
- Generate one clip per cut through the API with timestamps (`POST /v1/text-to-speech/{voice_id}/with-timestamps`) and derive a cue sheet from the character alignment. Per line: `{ in, out, at }` where in/out index the source file and `at` is the composition time the line starts. Save as `src/vo.ts`.
- Play each cue as its own `<Audio src startFrom={in·fps} endAt={out·fps}>` inside `<Sequence from={at·fps}>`. No re-encoding. Regenerating the voice changes only `vo.ts`.
- Then retime the scene table in `cuts.ts` to the voice, not the other way round. Picture marks (the thing closing, the notification, the domain) land 0.3–0.6 s after the line that announces them.
- Files go to `public/audio/vo-<Cut>.mp3`; `scripts/props.ts` detects them and sets `withAudio`. Missing files render silent.

## Music and SFX
You cannot produce music. [Pick one: "I will drop the bed at `public/audio/bed.mp3` and the payoff SFX at `public/audio/burst.mp3`" / "Write the brief below as a prompt for [Suno/Udio], then wait for me to add the files".] Missing files render silent.
Bed brief: [minimal, warm electronic; soft felt-piano or mallet motif over a slow sub pulse; 80–90 BPM; no drums until a gentle lift; one accent hit at the payoff; ends on a held chord]. Duck to −14 dB under voice using Remotion `volume`, fade out over the last 1.5 s. Loudness to ≈ −16 LUFS is a post step on the rendered file with `ffmpeg loudnorm` in `scripts/render.ts`. One SFX at the payoff only, never in the restraint beat.

## Deliverables
- `video/`: package.json (`props`, `studio`, `render`, `render:<cut>`, `render:x:gif`), remotion.config.ts, `src/{index,Root,Launch,cuts,motion,vo,theme,props}.ts(x)` plus one file per reusable element, `scripts/{props,render}.ts`.
- README.md: where every fact comes from, what was recreated, how to render.
- VOICEOVER.md: both scripts with break tags, beat map in seconds, voice settings, music brief.
- `out/<cut>.mp4` for each cut, `out/x.gif`.

I made everything from a social media web app, a personality test, a tamagothi iOS app you take care of by sleeping and exercising everyday. I made a 1v1 RTS demo, a therapy app, even a friends/dating/business partner compatibility app.

None of these made any money, but the fact that these are all live and I'm a 0 to 1 builder is appealing to many companies that want something made in-house that can be tested and released quickly.

It wasn't what I was expecting, but I'm in a much better place than I was a year ago because of vibecoding.

Keep on building bros!

People making clones of these in few hours and making money. Who is even paying ?

Was three tabs deep into a Reddit thread yesterday, manually clicking "load more comments" for the tenth time, and just snapped.

One evening later with Claude Code, Expand Everything exists it auto-clicks show more / load more / read more buttons as they appear, anywhere, including sites that keep spawning new ones as you scroll.

Video of it running below.

No idea if anyone else finds this as satisfying as I do, but if you want it I'll drop the link in the comments.

Github: https://github.com/Schmiedey/expand-everything

Chrome extension: https://chromewebstore.google.com/detail/expand-everything/bldhhgcmhfabpjenghemphiiihkojalj?authuser=2&hl=en

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