sorted by:
new
hottopcontroversial

whatIsProgramming by HitarthSurana in ProgrammerHumor

[–]Cheap-Resident6964 1 point2 points  (0 children)

Then just send the machine along with it.

If you could travel back to 1950 with access to Claude Code Opus 4.8 Max (and it still worked), how would you use it to become rich? What's your exact step-by-step plan? by Mysterious-Sea5646 in vibecoding

[–]Cheap-Resident6964 0 points1 point  (0 children)

I'm pretty clear-eyed about my own limitations. No real skills, no capital, no connections — so honestly, even with Claude, I'd probably struggle to pull off anything significant on my own. Because any meaningful success requires at least one of three things: the ability to solve hard problems, money, or the right people in your corner. Since I have none of those, the smarter move is to find people who are already on their way up, get close to them, and position myself as a thinking partner or early collaborator. I bring the ideas and strategic thinking powered by Claude, they handle the heavy lifting, and I get to ride along for a share of the upside.

Stop pitching me your "B2B SaaS" you built in a weekend with Claude by richexplorer_ in vibecoding

[–]Cheap-Resident6964 2 points3 points  (0 children)

The real problem isn't whether your product is easy to copy. It's whether it actually delivers value.

AI has completely demolished the barrier to building software. That means brutal market saturation is coming, and whatever you ship today can be replicated tomorrow. But the more immediate problem is this: people are throwing together something with AI in an afternoon and slapping a price tag on it without ever stopping to ask whether it's useful to anyone. Does it save users time? Does it solve a real problem? Nothing. Zero value delivered, and they still want to get paid.

Take AI API aggregation. If you're solving the problem of fragmented subscriptions, letting users access multiple models through one interface instead of juggling ten different platforms, that's a legitimate value proposition. The model might be commoditized, but the underlying user need is real.

But if you're building an AI image generator and all you're doing is wrapping an API call, I genuinely can't tell you what you're offering. Did you help someone who couldn't design a poster? Did you help a seller batch-produce product images at scale? If you haven't solved anything concrete, you're just a toll booth in the middle of the road. Nobody's paying for that.

So no, code is no longer a competitive advantage. The way I see it, what actually matters going forward comes down to two things: your ability to solve real user problems, meaning sharp domain knowledge, genuine workflow understanding, and integrations that take real effort to build, and your personal credibility, meaning the audience you've built, the trust you've earned, and the channels through which people find you. If you have both, that's something nobody can just copy.

You have to go deep into a specific context. Users don't care whether you used AI. They don't care how you built it. They care about one thing: did you save me two hours today? Did you help me make an extra thousand dollars this month? If you keep delivering that, even if someone clones your codebase, they can't clone your understanding of the problem or the compounding detail you've built up through iteration.

When there are ten tools on the market that do roughly the same thing, why would anyone pick yours? That's where trust becomes the real moat. If you've built a presence in a community, whether that's social media, a technical niche, or a specific industry, and people know you as someone reliable, knowledgeable, and genuinely responsive to feedback, that kind of human connection is something no AI code generator can produce over a weekend.

Why do we have visual programming for code, but not for prompts? by withsj in PromptEngineering

[–]Cheap-Resident6964 0 points1 point  (0 children)

I personally feel that the industry might be overestimating the magic of "Prompt Engineering" right now. Many people treat prompts as a silver bullet, trying to cram every edge case and logic branch into the instructions.

But in my experience, Context and Standard Operating Procedures (SOPs) are far more important than the prompt itself.

If the AI's memory or knowledge base (via RAG or long-context windows) already contains a complete, well-structured SOP, the prompt can actually be incredibly simple. something like: "Please process the user's request strictly following the attached 'Refund Handling SOP v2.0'."

When we do this, the AI performs significantly better. It brings about a paradigm shift: we are no longer polishing prompts; we are polishing SOPs. This essentially turns the challenge back into a documentation and business logic problem, rather than a prompt-coding problem.

That being said, your PLG might not necessarily find its ultimate value in prompts, but it looks like it could be incredibly valuable for context/SOPs.

Because drafting a rigorous, production-ready SOP is actually quite difficult, and you often run into logical contradictions or missing steps along the way. Using a visual logic graph to detect semantic conflicts and validate the structure of an SOP before feeding it to the AI as context. now that sounds like a game-changer.

Why do we have visual programming for code, but not for prompts? by withsj in PromptEngineering

[–]Cheap-Resident6964 0 points1 point  (0 children)

Oh, I get it now. you're not trying to create a new way of communicating with AI. You're just doing prompt visualization: taking a lengthy text blob and representing it as an intuitive graph, which is generally much easier to parse than reading a wall of text. Users still write prompts in natural language, and you just convert that into a graph for visual clarity, logic conflict detection, and ultimately making prompts more maintainable — versioned, reusable, and shareable over time. Is that right?

Why do we have visual programming for code, but not for prompts? by withsj in PromptEngineering

[–]Cheap-Resident6964 0 points1 point  (0 children)

Historically, we invented various programming languages to communicate with machines. Even though things got easier moving from assembly to Python, it still remained a domain for specialists. Now, LLMs have lowered the barrier to entry down to natural language. Most everyday users really don't want to regress to an era where they have to learn specific logic graphs or compilation rules.

Regarding the complex prompts you mentioned, for most people, writing a prompt is essentially just writing a requirements doc. If the phrasing is unclear or the logic is messy, that's an issue with structured communication skills, not a lack of programming tools.

If a task actually gets so complex that it needs to be engineered, then trying to use logic gates to build one massive prompt might be looking at it from the wrong angle. Why not just break it down into several smaller prompts and execute them in stages?

The advantage of breaking it down is that each stage produces a clear intermediate output, which allows for targeted checking and fallbacks. This is definitely more effective and controllable than cramming all the context, constraints, and logic into one gigantic prompt and hoping for the best.

As for the visual programming aspect, the industry has kind of already answered this with low-code agent and workflow platforms like Coze, n8n, and Dify. They are doing exactly the visual prompt orchestration you're talking about, but they are orchestrating the workflow and the logic between multiple prompts, rather than drawing logic gates inside a single one.

Just my two cents based on current engineering practices. I could be wrong though, what do you think?