I was told by an exec...once a company or technology implements something and gets mindshare, the community (including companies) moves on.
Competition is essentially dead for that segment given there is always outward growth.
With that being said, AI enables smaller players to implement their visions with enough completeness to be viable. And with a hands off approach to code, the underlying technology mindshare does not matter as much.
> Then you should have no issue with people using LLMs to communicate more clearly.
My raw thought: I wonder how many people are really objecting to the loss of exclusivity of their status derived from their relative eloquence in internet forums. When everyone can effectively communicate their ideas, those who had the exclusive skill lose their advantage. Now their core ideas have to improve.
Same idea, LLM-assisted: I wonder how many objections to LLM-assisted writing really stem from protecting the status that comes with relative eloquence. When everyone can express their ideas clearly, those who relied on polished prose as a differentiator lose that edge. The conversation shifts to the quality of the underlying ideas — and not everyone wants that scrutiny.
Same ideas. Same person. One reads better. Which version do you actually object to?
> LLMs are a cancer on human thought and expression.
LLMs help to express what many people dont have the energy or ability to express. It also has a broader scoped view of protocol...It does not have emotions, which often leads to less than optimal discourse.
In many ways, it help those who are challenged in discourse to better express themselves...rather than keeping silent or being misunderstood.
The pre-submit commit as an immutable baseline is the key design decision — every agent interaction is an atomic transaction with a known rollback point, exactly right.
On the "event → agent" gap: we've been thinking about this as a layered problem.
The bridge is a file write. agent-doc is user-initiated (edit a doc, hit submit), but the diff pipeline doesn't care who writes the file. A watcher process — or any external system — can write to the file system, and the agent sees the change on next poll.
We already do this in a different layer: corky (https://github.com/btakita/corky), our email tool, runs a watch daemon that polls IMAP for new messages and syncs them to markdown files on disk. External event (email arrives) gets translated into a file-system change, which is the agent's native input format. Same pattern would work for session recovery: monitoring process detects flagged session → writes to a task file → agent picks it up.
Dashboard-as-document is something we're actively planning. The idea: a markdown template where a watcher fills in operational fields — session status, health checks, proxy assignments. When the watcher updates "active" → "flagged", the diff pipeline sees exactly what changed. The template gives structure; the diff gives the trigger.
The snapshot diff already works for this — partial support exists today via agent-doc's routing layer (external scripts can trigger submission when a file changes). What we're building next is auto-submit on file change and sectional write-back so the agent can update specific dashboard fields rather than only appending.
For sub-second latency, a lightweight daemon that receives webhooks and writes to the notification file or directly triggers an agent submit. But for most operational tasks, a polling interval (ours runs every 30 seconds) closes the gap well enough.
The gap you're describing — "thing happened" to "agent knows about it" — is really about who writes the event into the file system. Once it's a file change, the diff pipeline handles the rest.
The runtime state logging approach makes sense for browser automation — that's a domain where ground truth literally lives outside your repo. We have a similar dynamic with email state in corky (IMAP sync, draft queues). Same pattern: log the external state separately and let the document reference it.
On concurrent editing — it's handled at two levels:
*Ownership:* Each document is claimed by one tmux pane (one agent session). The routing layer prevents two agents from working the same doc simultaneously.
*3-way merge:* If I edit the document while the agent is mid-response, agent-doc detects the change on write-back and runs `git merge-file --diff3` — baseline (pre-commit), agent response, and my concurrent edits all merge. Non-overlapping changes merge cleanly; overlapping changes get conflict markers. Nothing is silently dropped.
The pre-submit git commit is the key — it creates an immutable baseline before the agent touches anything, so there's always a clean reference point for the merge.
Agent loops also enables the "hard discipline" of making sure all of the tests are written, documentation is up to date, specs are explicitly documented, etc. Stuff that often gets dropped/deprioritized due to time pressure & exhaustion. Gains from automation applies to greenfield & complex legacy projects.
I am now releasing software for projects that have spent years on the back-burner. From my perspective, agent loops have been a success. It makes the impractical pipe-dream doable.
I've been building agent-doc [1] to solve exactly this. Each parallel Claude Code session gets its own markdown document as the interface (e.g., tasks/plan.md, tasks/auth.md). The agent reads/writes to the document, and a snapshot-based diff system means each submit only processes what changed — comments are stripped, so you can annotate without triggering responses.
The routing layer uses tmux: `agent-doc claim`, `route`, `focus`, `layout` commands manage which pane owns which document, scoped to tmux windows. A JetBrains plugin lets you submit from the IDE with a hotkey — it finds the right pane and sends the skill command.
For context sync across agents, the key insight was: don't sync. Each agent owns one document with its own conversation history. The orchestration doc (plan.md) references feature docs but doesn't duplicate their content. When an agent finishes a feature, its key decisions get extracted into SPEC.md. The documents ARE the shared context — any agent can read any document.
It's been working well for running 4-6 parallel sessions across corky (email client), agent-doc itself, and a JetBrains plugin — all from one tmux window with window-scoped routing.
It's part of the messianic end-times fervor that has been with America since the beginning...which is useful for imperial management...As it provides a constant source of existential judgement and dread...that religious/quasi-religious administrators can exploit.
Mr Claude is already on it. He wrote an article titled "How Climate Change Affects the Behavior of Pet Hamsters and How Paying Carbon Taxes Can Help". Game changer!
I think you will mostly get "the west is the best" over here. And "look at those evil authoritarians over there"....Enjoy your "freedom" to participate in the culture wars digital serf...while the standard of living, personal autonomy, wealth, & health may be on the decline...of yours & your loved ones. At least we have many of each other to blame...while a few profit.
Well, the last couple sentences is me paraphrasing. But one thing that many in the West boast about is the ability to criticize the systems to improve said systems. Let's see if actions match the rhetoric.
Roblox has been banned in China since 2021. Perhaps it's something to do with nationalist governments not liking global corporate circumvention of their culture/power.
Harvard received the "worst score ever" clamped at 0.0 in 2023. By the Foundation for Individual Rights in Education. The actual score was -10.69.
They were particularly oppressive on anyone espousing opinions on the political right...Both leaning toward Individual liberty & stateist inclined.
While I believe that freedom of speech is a right not to be infringed on. Their current stance is selective. They have a massive endowment. So Harvard doesn't need subsidies. Since their endowment benefits private parties, Harvard can be funded by private parties.
I see AI as a tool to express creative intent in ways not practical before it came about. It could be naivite full of unintended consequences. But it's hard to not focus on the benefits of the latest tech.
The current crop of tools are improving productivity in developing better software. Which makes me happy.
I want to follow up with a couple more thoughts as Open Source developers, particularly important ones, earning a decent living is important:
The OP author deserves to earn a living for himself & his family. He has put in many hours of hard work & has proven to be selfless in doing so. The question is, if one dedicates one's life to Open Source development, how will one earn a living?
My contention about relying on donations is that donations are not very reliable. They require frequent PR to bring attention & the will of the donators. I'm confident that this post will bring in a rush of donations, but for how long? I hope Mr. Pushkarev can find a sustainable way to earn the living that he deserves. I just don't think relying primarily on donations is going to get him (or any Open Source developer) there. He has a platform & attention & I hope people in a better position than myself can rally around that to offer him sustainable opportunities. Who know where he will take it from here. I'm optimistic that some great opportunities will emerge from this.
Competition is essentially dead for that segment given there is always outward growth.
With that being said, AI enables smaller players to implement their visions with enough completeness to be viable. And with a hands off approach to code, the underlying technology mindshare does not matter as much.