Disclosure up front: I build LLMGraph (llmgraph.ai), a hosted product in the same category, so I have a horse in this race.

The interesting part of the announcement is the stated reason: "developers are increasingly relying on new coding agents" and "rigid workflow low code approach quickly hits the limit when it comes to complexity." I think that's half right. Coding agents are clearly eating the developer end of this market. But a lot of Flowise usage was never developers; it was teams who wanted to design an LLM pipeline visually, hand it to a non-engineer to tweak prompts, and deploy it without owning infrastructure. That need didn't go away this week, and telling those users to fork and maintain a large TypeScript codebase themselves is not a real answer for them.

For anyone running Flowise in production, the practical decision is fork-and-maintain versus migrating somewhere maintained. Forking is a bigger commitment than it sounds: you own dependency updates, security patches, and model API churn indefinitely, and the contributor community that used to absorb that work is dispersing. Worth being honest with yourself about whether your team will actually do that maintenance before the first CVE forces the question.

I've been pondering this recently. There have been loads of trivial automation targets throughout the economy for years but they haven't really been fixed, despite being a small Python script (things like converting one csv file to another). Why do we suppose LLMs are suddenly going to fix them? I guess the overhead is possibly lower now, but I suspect there are other barriers to automation that most techies can't comprehend.

[dead]

[flagged]