---
title: 'In the News: August 4, 2026, Extra'
description: 'Flowise is winding down and names coding agents as the reason. Code frozen 29 July, repository archived 10 August, npm and Docker images deprecated.'
canonical_url: 'https://darkfactory.dev/news/2026-08-04-extra'
markdown_url: 'https://darkfactory.dev/news/2026-08-04-extra.md'
collection: news
date_published: '2026-08-04T20:30:00-04:00'
date_modified: '2026-08-04T20:30:00-04:00'
---

# In the News: August 4, 2026, Extra


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](https://flowiseai.com/sunset)** · 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."

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](https://martinalderson.com/posts/speed-vs-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.

He then limits 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 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](https://queue.acm.org/detail.cfm?id=3807963)** · 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

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:** The evidence supports a position the corpus already holds on
other grounds, that harness effort belongs in verification rather than generation.
It also warns against a common dashboard measure. 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.