[abxyz]

Looks very good, I believe this type of product is the future (instead of vibe-coding that produces heaps of junk new code). A few thoughts:

* Flowcode is a clever name but since you are positioning yourself as an alternative to code ("Code is messy and complex") the name is contradictory, just call it "Flow" (or "flows" or "Flower" something)

* You are replacing the legacy of code with something new, embrace new ideas that get out of the "one running process" paradigm, e.g: durable functions. There are a bunch of companies in the space (inngest, DBOS, trigger.dev) who are doing very interesting things, copy/steal/leverage all the great things they're doing -- your product's value is the visual programming

* Most developers today are already writing code so getting out of their code flow to do something visual might not fit well, whereas there are lots of non-developers who would love a product like this (see: the success of Make.com, Zapier etc.) because you're offering the AI integration for creating workflows which gives them confidence to go beyond what Make, Zapier etc. offer

If I were marketing this product, my pitch would be reframing programming as something anyone can do when it doesn't involve code, i.e:: your users can become a developer without writing code, AI-assisted visual programming builds production-ready systems without a single line of code. Code is archaic, (visual) programming is the future. Vibe coding is faster horses, AI-assisted visual programming is flying cars.

[orlevco]

Hey, author's co-founder here.

You're right that getting developers to switch to visual programming will be tough. But we believe that: 1. In the right use case (standalone API/workflow, multiple LLM calls, concurrency etc.) working visually is going to be 10x better than code 2. There's a growing segment of non-developer-but-technical people: Self-taught builders, Product Managers, IT/Automation specialists. We think these people are currently stuck with existing tools that are very limiting. And once they're able to deploy real products with visual programming it will be a gamechanger for them. 3. Collaboration - Even if developers prefer textual code when on their own, when they're working with non-developers (product teams, clients etc) there's a big benefit for being able to share and present how things work.

[abxyz]

> In the right use case (standalone API/workflow, multiple LLM calls, concurrency etc.) working visually is going to be 10x better than code

I completely agree but I think that's a very hard sell. People who write code are often years deep in their preferred workflows and asking them to reconsider how they build things is a very big ask.

> Even if developers prefer textual code when on their own, when they're working with non-developers (product teams, clients etc) there's a big benefit for being able to share and present how things work.

The problem here is that developers lead implementation. The ideal implementation for a stakeholder is rarely the implementation that is delivered, because developers are taking requirements and translating them into the things they want to build. That's why so many products end up bad: developers have too much power by virtue of code being seen as some sort of magic spell that only a true genius can master. Can you imagine a non-technical person successfully dictating that the solution must be built with visual programming?

Low code / no code is powerful because it turns the relationship between product owner and developer on its head, it puts the product owner back in the driving seat (instead of a passenger begging the developer to go in the desired direction and accepting they'll probably end up somewhere... nearby, hopefully). Hiring the wrong developer(s) can be very bad for a company because of how much a developers choice's influence the product and business.

The proliferation of low code / no code in business often comes from outside engineering, many developers, regrettably, love to write code. Often you'll find that non-technical departments of companies have secretly started using things like Make and Zapier and n8n without telling the engineering department because they feel like they finally have the opportunity to make technology work for them.

Developers that exist in service of product are already using platforms like Make and Zapier and n8n because they understand how much value there is in programming without writing code, but for them visual programming probably isn't that much of a differentiator because they already have a vision in their head of how programming works.

Anyway, your product is great, I am sure you'll succeed regardless of the approach you take :)

[Vegenoid]

Agree that these tools are enormously useful for non-programmers to automate things. I think the biggest area where all visual programming languages is in scalability, flexibility, and speed compared to a skilled (text) programmer. There is absolutely space for these tools, but I think that the wide majority of people who spend enough time programming will prefer text.

The tradeoff between visual and text programming feels like a classic learning curve vs. skill ceiling tradeoff.

[muaz]

Devs may take time to adopt visual programming, but SME will more readily try this to improve execution. Visual programming will be the way SME and LLM build consensus on execution.