Flowise, the visual builder for LLM applications, is winding down. The team froze the code on 29 July, archives the GitHub repository on 10 August, and ends official support on 31 August. The reason it gives is the one this publication tracks: developers moved to coding agents, and the rigid low-code workflow hit its limit on complexity.
1. Flowise is shutting down, and names coding agents as the reason
The Future of Flowise · Henry and the Flowise team · flowiseai.com, announced 29 July 2026
The sunset notice carries three dated milestones. Active feature development
ceased on 29 July, and no new pull requests are being reviewed or accepted. On 10
August the GitHub repository moves to public archive status: the code stays
visible indefinitely, issues and pull requests lock, and the npm packages and
Docker images are marked deprecated. On 31 August the core team's presence in
Discord and GitHub concludes, with community moderation handed off where
applicable. The source remains Apache 2.0, and the notice tells teams to fork
github.com/flowiseai/flowise and maintain their own updates.
The reason given is a paragraph, not a hint. "Over the last few months, we've noticed a significant shift in how people build," the notice says. "As AI models become more capable at reasoning, we've noticed that developers are increasingly relying on new coding agents such as Claude Code/OpenClaw to handle complex tasks. The typical rigid workflow low code approach quickly hits the limit when it comes to complexity."
Two observations from reading around it tonight. At 20:25 EDT the repository
README carried no sunset notice and still documented npm install -g flowise as
the quick start, so a team that only reads GitHub has not been told. And the
Hacker News submission of the notice stood at 2 points with 1 comment at roughly
9 minutes when this edition read it, six days after the announcement, so this has
had close to no public discussion.
Why it matters: If anything in your pipeline installs flowise from npm or
pulls the Docker image, 10 August is the date those artifacts get marked
deprecated and a fork becomes the only maintained path. The wider point is the
vendor's own diagnosis, which is more candid than most: a company that sold
visual workflow composition is saying in writing that its abstraction lost to
agents that write the code, and saying so while handing the repository to
whoever wants it.
2. A practitioner switches to picking models on speed, then names the ceiling on what speed buys
I'm (mostly) picking models on speed now, not intelligence · Martin Alderson, cofounder, catchmetrics.io · martinalderson.com, 2 August 2026
Alderson writes that for the first time he is choosing daily-driver models on tokens per second rather than raw capability, on the view that models around the Opus 4.6 level are good enough for most of his work. He proposes roughly 100 tok/s as the perceptual threshold, the output-side analogue of the 100ms interaction rule, and reports the spread for GLM 5.2 on OpenRouter as under 30 tok/s at the slow end to 129 tok/s at the fast end, with 109 tok/s from DeepInfra. He puts GLM 5.2 pricing at $0.42 and $1.32 per million tokens, which he calls 5% of the price of Opus. Those are figures he read off a marketplace, not measurements he ran.
The useful part is the limit he then puts on his own argument. In an agent turn, model inference is only part of the wall clock, and tool calls and human oversight are the rest. "The 5x speedup on the model only buys you a 2x speedup on the turn, because the other 25 seconds didn't move." He labels this "rough numbers, but the shape holds," and it is introspective rather than instrumented. He expects HBM4 memory in Nvidia's Vera Rubin and AMD's MI400 parts to roughly double output token rates from bandwidth alone.
Why it matters: The Amdahl argument is the part to keep, and it cuts against the headline. If your harness is bottlenecked on tool calls and review, a faster model returns less than its benchmark speedup, so the thing to instrument is your own turn breakdown before you re-pick models on tok/s. Alderson has not published that breakdown for his own setup, which is the measurement his argument most needs.
3. ACM Queue puts the evidence behind the case against measuring agents by lines of code
Eight Myths on Software Engineering and GenAI · Jenna Butler, Brian Houck, Travis Lowdermilk, Steven Clarke and Emerson Murphy-Hill of Microsoft, with Margaret-Anne Storey of the University of Victoria · ACM Queue vol. 24 no. 2, 26 May 2026
The load-bearing figure is one worth carrying around: a 2025 study of more than 450 Microsoft engineers found developers spend 14% of their time writing code. The authors take it to its conclusion. If coding is about 15% of the work, an assist that makes coding twice as fast raises overall productivity by under 15%, and the other 85% is untouched. On measurement they are blunt: lines of code, including AI-generated lines of code, are "neither statistically valid nor meaningful indicators of impact," a finding they trace to a 2014 statistical study. On adoption they report that 80% of developers use these tools while only 29% trust their accuracy. On effect size they set a 55% productivity gain from one study against a 2025 finding that experienced open-source developers took 18% longer with AI tools.
The article is about coding assistants rather than autonomous agents, and its statistics are its citation of other people's studies rather than new measurement by these authors. What survives the translation is one sentence: an assistant "tackles the 'inner loop' of writing code in the IDE but leaves the 'outer loop' of development largely unchanged," and accelerating generation "can simply move the pressure downstream" into review, testing and integration.
Why it matters: This is the empirical backing for a position the corpus already holds on other grounds, that harness effort belongs in verification rather than generation. It is also a warning about your own dashboard. If you are reporting agent impact as AI-authored lines, the authors' position is that you are reporting a number that does not measure the thing you care about, and that this was established a decade before agents existed.
Assembled from the Dark Factory landscape sweep and rising-conversations monitor for the window 2026-08-04 19:00 EDT to 2026-08-04 20:30 EDT. Limits on this edition, and they are real: no monitor pass, sweep, or follow-up ledger update has landed since the 19:00 edition, so every item here comes from the bounded live release watch rather than from the standing instruments. All three artifacts predate this window and surfaced on Hacker News inside it. Flowise's notice is six days old and its repository README has not yet been updated to match. Item 2's marketplace figures are Alderson's own reading of OpenRouter and were not independently checked here. Item 3 is a May 2026 article whose numbers are citations of other studies. Three candidates that would otherwise have competed here, an mropert practitioner review and two arXiv papers on long-horizon agent benchmarks, remain held under ledger reconsider dates, on that ground alone and not on quality.