Connect with the Product Hunt community

Noticed a trend where letting agents work on whole features solo usually ends in a mess. They start tweaking low priority edge cases adding random bloat, or refactoring stuff that was working fine.

It seems like giving them complete freedom actually tanks the quality of the output.

What kind of rules or limits do you set so your coding tools don't end up going in circles?

Try it on your own product without using its name: ask ChatGPT, Claude or Gemini the question a buyer would ask. "What are the best tools for X?" Then see whether you are in the answer, and who is.

Two things we keep seeing:

We ve all been there: an agent makes a mistake, you paste the error, it "fixes" it, introduces a new error, and 5 turns later it reintroduces the original bug you started with. It gets trapped in a cycle of surface-level trial and error instead of stepping back to analyze the root cause.

It feels like the model loses critical reasoning capacity once the context turns into a wall of error logs.

What s your hard rule for stopping an agent mid loop? Do you wipe the chat context drop to a lower tier model, or force a specific step-by-step diagnostic prompt?

Quick question for frontend devs using tools like v0, Claude, or Cursor. When you get a new Figma design, what's your actual entry point now?

I used to start by setting up component state, props, and styling manually to keep things clean. Last week I tried just feeding screenshots and exported SVGs directly to the AI to spin up the UI instantly. It got me 80% there in 5 minutes, but the generated CSS was a messy soup of arbitrary Tailwind utility classes that took an hour to clean up. Curious how many of you are fully automating the UI handoff vs manually building the core markup first and then using AI for the logic.

I had a realization this morning that I can't shake.

Every single day, I apologize to someone. "Sorry, that feature isn't ready yet." "Sorry, the onboarding is confusing." "Sorry, I haven't replied to your email." "Sorry, the pricing page is broken on mobile."

I don't remember anyone telling me that 60% of building a product would be saying sorry to people who are kind enough to still care.

And here's the thing: I used to think "founder" meant vision, strategy, talking to users about the big picture. But most days, it's just managing a long list of small failures and trying to make sure the people who believed in you don't walk away before you fix them.

When your coding agent finishes a change and you ask it to look the change over, what is in the reviewer's window? If the answer is the whole session, the review is the author re-reading with its own notes in front of it: every file it opened, every dead end, and the moment it declared the change done. It knows why each line is there. A reviewer should not.

We wanted evidence that moving the review out of that window matters when the model stays the same. One small controlled study did exactly that: thirty artifacts with five planted errors each, one model, four review setups. The fresh window given nothing but the artifact caught the most, F1 28.6% against 24.6% for the full session and 40% of the critical errors against 29%, while a second pass inside the same session came last. Two agent vendors already build it that way: one CLI's guide puts it as a fresh context helping because the model "won't be biased toward code it just wrote", and the other vendor's team says one model does both jobs and was trained separately for each, with the reviewer running on the pull request.

Our own version reviews articles using a cold reviewer agent, handed that day's source material as ground truth. Each piece comes back with somewhere between one and twenty-three items we have to fix, usually four to six, and the hard ones were caught against the pasted sources.

If your agent reviews its own change, what does the reviewer get to see: the diff alone, the diff plus the task, or the whole transcript? And who has put two of those side by side on the same change?

Every team I talk to has more feature requests than they can act on, and most of it doesn't come with clean data attached, just a support ticket or a Slack message from a customer. For those running product teams here, what's your actual process for turning scattered feedback into a prioritized roadmap? Curious whether people are doing this manually in spreadsheets, using a dedicated PM tool, or something else entirely.

As an early founder I would really value advice from makers who have built momentum from the ground up.

I am specifically attempting to learn in three areas:

1. Growth and distribution: What early growth channels, habits, or experiments have actually helped you get your product in front of the right people? What would you focus on before spending money on ads?

Solo dev here. We hand-made 137 animation groups per species, six species, 5,242 frames, for a habit app where the progress bar is a pixel pet.

Then our founder said: we made all those special animations and I never see a single one.

I assumed he was wrong. He wasn't. signature_move_played had fired once in the app's entire history. The cause was arithmetic, not art: a pool weight of 8 out of 108 with a selector ticking every 7 seconds meant a ~90 second expected wait. Our median session is 59.5 seconds. We had built twelve animations that a typical session could not reach.

Fixing it surfaced four more defects. But the one that still bothers me is meta: our own detectors produced ten false alarms during the work.

I ve been thinking about this while working on a product involving transactions between people who may not know each other.

A seller can complete 30 successful transactions, but the next customer may still know almost nothing about that history.

The obvious answer is to show completed transactions, ratings or reviews.

But that creates another problem.

I realized today that my main downloads space has turned into a digital graveyard. It s got everything from old tax forms to random setup files I used once and forgot about.

Sorting through thousands of files by hand takes way too long, but I'd rather avoid adding another monthly software subscription just for file management.

I have come along a lot of examples where web apps require login and use server-side rendering.

I get that it s better for SEO, but how would that apply if the app is login protected (different story for a marketing website)?

Just realized my mobile conversion issue had nothing to do with copywriting.

On slightly smaller phones, the main sign-up button was getting pushed down so far that people had to scroll just to see it.

Because it looked fine on my phone, I assumed everyone saw the same thing. I only spotted the issue when I happened to look at my site on someone else's screen.

Curious how others handle this do you use browser testing tools, or do analytics usually give away these layout problems first?

I used to skip writing down anything because it was just me and i had everything in my head. But then i took a short break recently and completely forgot why i made certain decisions in the code. Spent hours trying to figure out my own stuff.

Now i just leave quick notes on things that aren't super obvious. Nothing fancy just a line or two so future me doesn't get stuck.

Where do you draw the line between useful notes and just wasting time on docs?

I always thought documenting things was useless if you re building alone

But after stepping away from my app for a couple weeks I came back and had no idea why I set up parts of the product the way I did.

Lately I started taking 30 seconds to write down the reasoning behind tricky decisions. It already saved me a bunch of headache this week.

Curious how other solo builders handle this do you bother writing stuff down or just rely on your commit history?

I ve been testing AI coding agents on React projects, especially for issues involving state management, broken API calls, and unexpected UI behavior. They can identify the problem quickly, but I still find myself checking whether the fix actually addresses the root cause. How reliable have AI agents been for you when debugging React or Next.js projects?

It s super annoying when an assistant tries to fix a tiny issue and ends up rewriting whole files.

After a couple tries, you end up with brand new errors and the original bug is still right there.

Do you guys set hard limits in your prompts or do you just revert to clean commits as soon as it strays off track?

Asked an agent for a basic date formatting function and it literally tried to pull in a whole external library instead of just using vanilla JS.

It seems like these tools always jump to installing third party packages for tiny tasks that only take a few lines of code.

How are you stopping them from cluttering package.json without having to spell it out in every single prompt?

I ve been testing AI coding agents on React projects, especially for issues involving state management, broken API calls, and unexpected UI behavior. They can identify the problem quickly, but I still find myself checking whether the fix actually addresses the root cause. How reliable have AI agents been for you when debugging React or Next.js projects?

I spent an entire weekend last month rebuilding my personal tracking dashboard from scratch using all kinds of linked tables and automated rules.

A week later I noticed I was actively avoiding opening the app because taking a two line note required filling out four different property tags.

I ended up wiping the whole workspace and moving back to basic text pages with bullet points.

Removing all the fancy automation made updating my notes feel effortless again.

My main task list is getting super laggy on mobile because of thousands of old entries.

I just want done items to disappear from my main view once they hit the 30 day mark without paying for extra automation tools.

Anyone using a smart database filter setup or formula trick that hides old stuff without breaking the workspace?

Focusing on signup momentum is fun but customer cancellations quickly shift your focus once revenue is involved.

A lot of cancellation reasons boil down to routine integration rather than minor feature requests. Fixing how a product fits into someone's workday is a much tougher challenge than just shipping another update.

Do experienced founders eventually get used to churn or do you just build faster ways to analyze and act on user cancellation reasons?

Clients always ask for "just one more thing" in a project scope an extra report, another revision, or an additional strategy call. If you keep saying yes, your core service loses focus and efficiency.

It's tempting to add more to justify a higher price, but usually, less is more.

And I assume it s similarly tricky for software builders. Users constantly request new settings, integrations, and custom options. But adding every requested feature turns a clean tool into a complex, confusing mess.

How do you decide when to say "no" to feature requests to protect simplicity?

Getting a prototype up and running takes virtually no time now but getting random people to actually stay around is still a struggle.

I can push out a working app over a Saturday night but then it just sits there with zero traffic unless i constantly push it manually.

Where are you guys spending most of your daily energy if you aren't stuck fixing code all day?