> Since our landing page is isolated from core product code, the risk was minimal. That said, I was constantly sanity-checking what Claude was changing. If I ever “vibed” too hard and lost focus, Claude would sometimes change the wrong files.
> Still, I wouldn’t trust Claude, or any AI agent, to touch production code without close human oversight.
My experience has been similar, and it's why I prefer to keep LLMs separate from my code base. It may take longer than providing direct access, but I find it leads to less hidden/obscure bugs that can take hours (and result in a lot of frustration) to fix.
> My experience has been similar, and it's why I prefer to keep LLMs separate from my code base.
I'm curious how you're managing this - is it primarily by inputting code snippets or abstract context into something like a Claude or ChatGPT?
I found for myself that I usually was bad at providing sufficient context when trying to work with the LLM separately from the codebase, but also might lack the technical background or appropriate workflow.
> ... is it primarily by inputting code snippets or abstract context into something like a Claude or ChatGPT?
I usually provide the initial context by describing the app that I'm working on (language, framework, etc) as well as the feature I want to build, and then add the files (either snippets or upload) that are relevant to build the feature (any includes or other files it will be integrating with).
This keeps the chat context focused, and the LLM still has access to the code it needs to build out the feature without having access to the full code base. If it needs more context (sometimes I'll ask the LLM if they want access to other files), I'll provide additional code until it feels like it has enough to work with to provide a solution.
It's a little tedious, but once I have the context set up, it works well to provide solutions that are (mostly) bug free and integrate well with the rest of my code.
I primarily work with Perplexity Pro so that I have access to and can switch between all pro level models (Claude, ChatGPT, Grok, etc) plus Google search results for the most up-to-date information.
This is great, thank you for sharing. I need something like this for my current project I'm working on... Much easier than trying to build a color palette manually.
Agreed OP. I could see ProductHunt being a place for product-oriented people and founders to form a community and collaborate (constructive feedback, partnerships, etc). Sadly, most of the activity there lately seems to be people quickly creating accounts, launching their vibe-coded app, and then moving on. I've stopped visiting regularly until the maintainers make improvements to foster more of a community and bring people back to the site.
I generally agree with the sentiment of the article, but the OP should also be looking at product launch websites like ProductHunt, where there are tens to hundreds of vibe coded SaaS apps listed daily.
From my experience, it's much easier to get an LLM to generate code for a React/Tailwind CSS web app than a mobile app, and that's why we're seeing so many of these apps showing up in the SaaS space.
It's a bit hard as they're not summing by months but it looks like less to me quickly scanning it.
And as Claude Code has only really been out 3/4 months you'd be expecting launches to be shooting up week-by-week right about now as all the vibe products get finished.
I've been running trixie for a few weeks now and it's been solid, great release so far.
One of the features I'm most excited about is access to Podman 5.4.2, and the ability to use Podman Quadlets. It'll be nice to start transitioning my systemd service units over to the new format for my containers.
Good breakdown of the costs involved. Even if they're running at a loss, OpenAI and Anthropic receive considerable value from the free training data users are providing through their conversations. Looking at it another way, these companies are paying for the training data to make their models better for future profitability.
Taking this approach seems to be effective at surfacing issues that otherwise wouldn't show up in regular testing. I could see this being useful if it was standardized to help identify issues before they hit production.
This is an interesting find OP and could help people transition from Docker to Podman (especially if they're used to deploying with Docker-Compose).
I think the better long-term approach though is to use systemd user units for deployment, or the more modern approach of using Podman Quadlets. There's a bit of a learning curve, but these approaches are more native to the Podman platform, and learning how systemd services work is a great skill to have.
> The more data you give any of the AI services, the more that information can potentially be used against you.
It may seem obvious, but Sam Altman also recently emphasized that the information you share with ChatGPT is not confidential, and could potentially be used against you in court.
Hasn't that always been the case? Phone companies providing records of calls and text messages, etc? Anything stored on someone else's servers is going to be something they have a duty to provide to police/courts, assuming they fall under that jurisdiction.
Thanks for sharing this. It looks like you can also use "systemd-analyze" with the "--user" flag to inspect systemd user units as well ("systemd-analyze --user security"). I've started using systemd more now that I've transitioned my containers to Podman, and this will be a helpful utility to improve the security of my systemd unit/container services.
> Still, I wouldn’t trust Claude, or any AI agent, to touch production code without close human oversight.
My experience has been similar, and it's why I prefer to keep LLMs separate from my code base. It may take longer than providing direct access, but I find it leads to less hidden/obscure bugs that can take hours (and result in a lot of frustration) to fix.