Went looking for why a service got slow and found four ways of making an HTTP request in it. A fetch wrapper, axios, and two hand rolled retry loops. Nobody added them in one sitting. Each one arrived in a different session, in a diff that was correct on its own, and I approved all four.

That's the failure mode I didn't see coming with agents. They're good at the task in front of them and they have no opinion about what the repo already does, so every session starts from a blank slate even when the codebase doesn't. Bad code you catch in review. A second correct implementation of something you already have reads fine in a diff, and it only shows up later when a change has to be made in four places.

I ve been building a Chrome extension + website recently with a pretty AI-heavy workflow, and I ve noticed a big difference between vibe coding a prototype and actually shipping something people use.

Getting the first version working is surprisingly easy now.

The harder part starts afterwards:

• figuring out what users actually need

• debugging weird edge cases

• understanding code you didn't write yourself

• keeping the codebase maintainable

• making changes without breaking something else

• knowing when to stop asking AI to just fix it

Noticed lately that most of my prompts to Claude Code or Cursor aren't new instructions, they're me re-stating stuff that was true 20 messages ago and got lost: which file owns this logic, why we chose this pattern over the obvious one, what NOT to touch. Feels like half my typing is context restoration, not task description.

Curious how others handle this. Do you keep a running "state of the project" doc you paste in, rely on the agent's own memory/context features, or just accept the repeated overhead as the cost of doing business? What's actually cut it down for you, if anything has?

I've been building with tools like Claude Code, Cursor, and Replit, and they've dramatically sped up coding.

But I've noticed there are still parts of the workflow that feel surprisingly manual.

For example:

• Finding a prompt that worked a few weeks ago.

• Remembering how a specific feature was generated.

• Keeping architecture and AI context organized across different tools.

• Iterating on AI-generated code without starting over.

I've been building my app for 8 months now, and i ended up having 5 repositories

• nextjs app

• databases

• customer facing API

• node-sdk that wraps the api

• react-sdk, for both reusing shared component and customer facing components

So i thought, it's gonna be great if i create a mono repo with submodules. But it was terrible. I realized that turborepo does not like external packages, and as i tried to reuse my own customer facing libs, the DX became terrible. It was very time consuming to ship a feature. Even when i wanted to use Codex or Cursor 3, it was not able to show git diff properly, also i was not able to use Cursor's cloud agents properly to ship complex features.

Noticed something a few weeks into a bigger project. Early on, a prompt like "add a delete button" just worked, one sentence, done. Now the same size request needs four sentences of context just to not break something else, which auth flow to respect, which of the two similar-looking components to touch, which past decision not to accidentally undo.

That's not classic technical debt. The code itself might be totally fine. The debt is that every prompt now has to carry more context just to stay correct, and that context requirement grows quietly, prompt by prompt, without ever showing up as a line in the codebase you'd notice.

The trap is it feels like the project getting more complex, which is normal and expected. But it's actually something narrower: the AI's working memory of your decisions is shrinking relative to how many decisions exist, so you're the one who has to keep re-supplying context it should already "know." At some point you're basically writing documentation into every prompt just to get back to where a one-line request used to work.

The only thing that's slowed this down for me: treating repeated context as a signal, not a nuisance. If I'm explaining the same constraint for the third time in different prompts, that's not me being thorough, that's a sign the constraint needs to live somewhere permanent (a note, a comment, a doc the agent can be pointed to) instead of being retyped from memory every time.

Vibe coding seems to be everywhere right now, people are building apps just by prompting AI.

But I m curious if anyone here has actually made money from something they vibe coded, especially people who didn t come from a coding background.

Over the last few weeks, I reviewed more than 15 vibe-coded fintech and startup-style web apps.

The surprising part was this:

Even when teams were using AI coding tools, security agents, framework defaults, and modern deployment platforms, I still kept finding serious external security gaps.

Not always one-click hack type issues, but the kind of problems that slowly stack up into real risk:

AI tools can handle basic CRUD apps UI layouts and API integrations surprisingly well these days.

The problems usually start when things get more complicated optimistic UI updates WebSocket disconnects heavy database queries or edge cases that aren't obvious at first.

I was working on a real time collaborative feature recently and the LLM generated the UI components pretty quickly. But when it came to keeping the state in sync reliably, I still had to work through a lot of the logic myself to avoid subtle bugs.

For those using AI coding agents in production, how do you handle this?

The story started in 2019. I wanted to build my own company. Back then, I was running a service-based business as a developer, but deep down, I never felt connected to that model. I wanted to create a product that could grow while I slept. Something truly mine.

So I started building. From 2019 to 2024, I built the product almost entirely on my own. Every system, every architecture decision, every scalable practice, every multi-tenant layer. It was hard, but I always felt in control of the machine I was creating.