Connect with the Product Hunt community

Years ago, devs understood memory, protocols, and performance. Today, half our job is fighting version mismatches in node_modules.

Importing a 15MB package just to format a date string isn't engineering it's stitching together black boxes we don't fully understand.

How much actual CS knowledge do you use daily versus just gluing third-party libraries together?

Every dav team claims they care about clean code. Until a deadline hits. Then hacky workarounds become permanent architecture.

"Later" never comes. We just stack patch after patch on Friday afternoons, burning out the team on bugs that shouldn't exist in the first place.

At what point does "moving fast" just become bad management?

I spent hours last week re-checking an agent's work because it skipped core steps from a spec I explicitly approved.

Having to manually audit thirty different file changes completely defeats the point of automating the build.

Now I write a separate reference file directly from existing code and force the runner to compare against it before marked complete.

How do you handle automated coding tools going off-script without spending all your time reviewing PRs?

I spent hours last week re-checking an agent's work because it skipped core steps from a spec I explicitly approved. Having to manually audit thirty different file changes completely defeats the point of automating the build.

Now I write a separate reference file directly from existing code and force the runner to compare against it before marked complete.

How do you handle automated coding tools going off-script without spending all your time reviewing PRs?

Been running a research agent (LangGraph + GPT-4o + Playwright) for competitive analysis. The pattern that kept hitting me:

• Hop 1: works fine. Agent searches, gets results, moves on.

• Hop 2: usually fine. Agent finds a reference, chases it.

• Hop 3: this is where it falls apart.

What I'm seeing at hop 3+:

• The agent re-queries with slightly different phrasing, gets near-identical results, doesn't recognize the overlap

• Context window is now 40k+ tokens of raw search results and the model starts ignoring its own instructions

• It either loops (same query, rephrased) or gives up and synthesizes from whatever's in the window, including irrelevant stuff

• When it does find a new source, it loses track of which claim came from which URL

When an AI agent creates a pull request, I usually want to check the diff, tests, error handling, and whether it followed the existing project patterns before merging. I m curious how other developers handle this. Do you review AI-generated PRs differently from code written by another developer?

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:

I'm a solo founder. I make an LED light therapy mask, and I decided early that I wanted FDA 510(k) clearance rather than selling it as a generic beauty gadget. Many LED masks sold online aren't FDA-cleared at all, which tells you something about how painful the process is.

Twelve months. Roughly $140K. One person.

The single most expensive mistake I made was assuming a testing lab is a testing lab.

I picked one based on price and turnaround. Their reports looked professional. What I didn't check was whether their accreditation actually covered the specific standards my submission needed. It didn't. The data was unusable, and I had to run the testing again somewhere else months gone, and a large chunk of that $140K was just paying twice for the same tests.

I was testing an app recently that relied almost entirely on text prompts to navigate and edit settings. While it made initial onboarding really fast I quickly lost track of what the tool could actually do because there were no menus to explore.

I feel like prompt bars are great for complex execution, but visual layouts are still essential for checking data accuracy and seeing your workflow at a glance.

Where do you draw the line when deciding which features belong in a chat box vs a standard screen layout?

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?

Plan mode in coding agents sounds great on paper but actual implementation almost always deviates from the approved scope. Unwanted refactoring and premature "task finished" triggers are huge productivity killers.

Some developers use a second agent instance purely as a linter/checker, while others restrict execution to ultra strict prompt specs.

For those running agentic workflows daily: what setup has actually worked to keep implementation locked strictly to your initial plan

I ve noticed coding assistants sometimes suggest a library for something that could be handled with the existing stack. That can slowly add unnecessary dependencies to a project. Do you have a rule for deciding when an AI suggested package is actually worth adding?

Setting up custom domains and polished copy gives a quick psychological win but it does not validate whether a problem is worth solving.

On the flip side launching with broken branding or a generic domain can sometimes lower trust for early signups.

Where do you draw the line between looking professional enough to test an idea and burning cash on a product nobody wants?

I ve found AI can build a React component quickly, but the difficult part is checking edge cases around loading states, empty data, validation, and responsive layouts. Do you have a specific testing workflow you follow before putting AI generated components into production?

I ve been comparing the workflow of using React Server Components with a more traditional client rendered React setup. Server Components can reduce the amount of JavaScript sent to the browser, but they also change how I think about data fetching and component boundaries. For people building production apps, which approach has fit your workflow better and what tradeoffs have you noticed?

I went back through my DMs with early users recently. Messages from a year ago, when the product was rough and I was excited about everything.

Reading them was strange. The enthusiasm was real. Mine and theirs. They were actually rooting for me. They gave detailed feedback. They said "can't wait to see where this goes."

Almost all of them are gone now. Not angry. Just gone. No goodbye messages. Just silence.

I don't know what happened. Maybe the product didn't deliver. Maybe life got busy. Maybe they were just being nice in the beginning. I'll probably never know.

I spent weeks convinced I was spending most of my day writing code and talking to customers. Decided to log everything in a sheet for a month, and the numbers proved I was completely lying to myself.

Half my time went to emails, organizing task boards, and watching tutorials I didn't need yet.

Has anyone here confronted bad time habits with real data? Curious what changes you made that actually stuck.

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?

Hi everyone,

I have been researching and building a mobile utility for field contractors and service workers. During the development process, one major architectural decision came up: Cloud vs 100% Offline.

Many field professionals (contractors, technicians, inspectors) work in areas with poor or zero cellular coverage. Cloud-based SaaS tools often freeze or fail to sync in these conditions.

On the other hand, an offline-first approach keeps all data, documents, and photos strictly local on the device, ensuring instant speed and complete privacy.

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?

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.