You spend hours shaping an agent:

• what tools it can touch
• what it should ask before acting
• what counts as risky
• when it should stop and clarify

Eventually it mostly behaves.

Then the surface changes: new runtime, new coding tool, new MCP server, new workflow…

…and suddenly you're re-explaining the same expectations all over again.

Feels like a lot of this stuff currently lives in prompts, habits, and the operator's head instead of surviving across surfaces.

Curious how others are handling this.

Prompts? Policy files? Wrappers/hooks? MCP? Just accepting the drift?

I’ve been vibe coding for about 2 years now. Early on I made every mistake possible — jumping straight into Lovable/Bolt/Cursor with a half-formed idea, watching the AI confidently go in completely the wrong direction, then spending hours iterating trying to fix it.

Over time I figured out how to prompt properly. Now I rarely need more than 2 or 3 iterations to get something solid. The AI builder hasn’t changed — my input has.
The difference is almost entirely in what goes in at the start. Most people skip the thinking and go straight to building. That’s where the wasted time and money happens.

Curious if others have found the same — a few questions:
•How long do you typically spend prompting before you get something usable?
•How many iterations does an average project take?
•What’s the most frustrating part of the process?
•Have you found anything that helps — templates, frameworks, a certain approach?

Not selling anything, genuinely researching the problem. Would love honest answers — especially if your experience is “actually I don’t struggle with this at all.”

I ran into a billing issue with Replit that I think is a documentation and UI problem, not just a user mistake.

I had set a budget limit of $0.01, but it didn’t actually save because Replit requires budgets to be set in $10 increments. Support told me that $0.01 “doesn’t meet the $10 minimum requirement,” so the system couldn’t save it as a valid budget. The problem is that the popup window and the flow I used did not make that clear, so from my perspective it looked like I had a budget limit in place when I didn’t. Looking at their documentation page, it does not say that anywhere that I can find. https://docs.replit.com/billing/managing-spend#set-up-limits-and-budgets

That matters because the result was about $70 in usage charges before I realized the cap was never active. If the system won’t accept values below $10, the interface should say so directly before the user submits it. Right now it reads like the budget was set, when in reality it was silently rejected.

I’m posting this because the current behavior is misleading. If Replit wants to prevent surprise charges, the minimum budget requirement needs to be obvious in the UI and in the docs, not buried in support replies after the fact.

https://preview.redd.it/q82m79n3spzg1.png?width=539&format=png&auto=webp&s=749b740920bc346764d62f946dfab5031f8b0f4d

https://preview.redd.it/gn58xi71spzg1.png?width=1231&format=png&auto=webp&s=d570fc85a7a2fcbeff79ef9be90998afd012904b

Has anyone else run into this with Replit budgets or usage limits?

I’m starting to think most “agent bugs” aren’t bugs. They’re mismatches between what we think we asked and what the agent thinks we asked.

That got me thinking about how we frame agent observability.

Most of the conversation treats the gap between what an agent claims it’s doing and what it actually does as a governance problem. Catch bad actions. Stop the agent before it deletes the wrong database.

That’s real. But I’m seeing something else.

A lot of developers are using the same idea for a completely different purpose: debugging their own assumptions about the model.

Examples I keep hearing:

• Someone spent weeks debugging ranking issues, only to realize the prompt wasn’t being interpreted the way they thought.
• Output drift that wasn’t a bug. The agent was doing exactly what it believed it was asked to do.
• Instruction-following gaps where the agent technically followed instructions, just not in the way the operator expected.

In all these cases, the developer wasn’t catching the agent. They were catching themselves.

The most useful signal wasn’t the output. It was reconstructing:
what did I think I asked vs what did the agent think I was asking?

That makes me wonder if the “failure/incident” framing for observability is too narrow.

“Intent vs execution” might not just be for governance. It might be one of the most useful debugging primitives for everyday agent work.

Curious how others are handling this:

• Are you debugging prompt interpretation / output drift by reconstructing the agent’s understanding?
• What does that look like in practice? Logs, eval traces, reruns, something else?
• Does “claim vs action” resonate here, or does it feel like the wrong vocabulary outside governance?

(For context, I’ve been exploring this space and built a small open-source tool around it. Happy to share if relevant, but mostly interested in whether this pattern resonates.)

As a new builder and hobbyist, I came to Replit looking for a low barrier entry into creating my own apps. My current project is really exciting, but I’m worried I’ll have to pay more than the baseline $20 for core every month just to keep it running.

Does anyone have experience keeping their app running or recommend switching to another site builder? In context, I predict roughly 50-100 users per month (free use), and I also have a Google Maps API.

Was wiring token tracking into our Governor and ran into something that's been bothering me.

If one LLM reasoning step produces three tool calls, and your observability stack attributes the same token spend to all three events, your downstream analytics are mathematically wrong. Not slightly wrong. Structurally wrong.

Concrete example from a single agent session I ran:

• Naive event-level aggregation: 14,436 prompt tokens
• Attributed correctly at the reasoning-step level: 4,812 prompt tokens
• A 3x overstatement, silently, on one workflow

The fix is straightforward: every reasoning step needs an identity (we use llm_turn_id), and token spend attaches to the step, not to each downstream tool call. Aggregation becomes dedupe-safe by construction.

What's been bothering me more is the second-order implication.

In non-deterministic agent systems, the normal ways we think about correctness start breaking down. One of the things that starts replacing it is cost. Retries cost money. Loops cost money. Reasoning drift costs money. Every operational pathology shows up, eventually, in tokens.

Which means cost stops being just billing telemetry and becomes one of the few accountability surfaces that survives non-determinism. But only if the attribution is structurally correct. Otherwise you're not measuring agent behavior. You're measuring an artifact of how your trace events were aggregated.

Curious whether others are also starting to read cost as a behavioral signal rather than just billing, or if I'm reading too much into a single workflow.We found a 3x token attribution distortion in a single agent workflow

I'm a high school founder at Techstars Startup Weekend in Boston right now. My team is trying to build the AI tool that actually solves distribution for small businesses and B2C founders. But before we write a single line of code, we're trying to hit 100 real conversations first.

If you hate being pitched to -- absolutely NO WORRIES. We're not trying to sell you anything. We literally have NOTHING to pitch -- which is exactly why I'm posting.

If you've ever built something and struggled to get it in front of actual users: what was the hardest part?

- Knowing what to post on social?

- Actually sitting down and making the content?

- Something you've never seen a tool address?

Comments are needed and welcome. I'll also be sliding into some DMs for 5-minute chats if you're open to it - just say the word and I'll come to you.

PS: if we win on Sunday, I'll send the first ten responses referrals to Techstars.

Hey everyone,

I’m facing an issue after updating my app and could use some help.

• I successfully published my app on Replit
• Submitted the first version to the App Store → worked fine
• Made some updates and republished the app
• Now when trying to submit the updated version, I’m getting this error:

https://preview.redd.it/g4x7qomxwgyg1.png?width=2098&format=png&auto=webp&s=14e349cd392b1dcd923ed46095a91609efc4c05c

Would you actually complete your tasks if you’d lose money for not doing them?

I’ve been thinking about this:

Most productivity apps don’t work (at least for me).
Reminders, streaks, to-do lists easy to ignore.

But the moment real money is involved behavior changes.

So I built a small experiment:

• You create a task
• Put some money on it (₹1–₹100)
• Complete it -> you get it back
• Miss it -> you lose it

No motivation. Just consequences.

It also has:

• Wallet (UPI-based)
• Subtasks with shared stakes
• Leaderboard for consistency

I’m testing whether loss aversion actually makes people more disciplined.

But I’m not sure:

• Would you actually use something like this?
• Or would the “losing money” part turn you off?
• What would make this feel fair instead of stressful?

If people are curious, I can share the link in comments.

Would love honest feedback.

Beginner here

No experience

What are the must do’s before launching.

I have my payment system set up

It was suggested to me to sign up with platforms such as supabase and now I’m wondering if there’s anything else I’m missing?

Thanks in advance for your advice