the problem is not the forward pass, its the control/feedback loop when slop is written in response to the forward pass. Perhaps we should give the LLM 2 specs, one designed for the forward pass and another for the acceptance criteria /backward pass that's focused on tests, best practices and code, so that the output is independently verified?

nobody knows what to build when everything can be built, there is no moat.

Using CRDT gossip to inform scaling is a clever idea. You are on to something there. Perhaps extract it as a core library/concept from the runtime? I feel that would be generally useful!

Thanks! That’s certainly crossed my mind!

I find parallel agents to be an exception rather than a norm. Maybe I’m the problem? For those exceptional cases, opening a few more terminals gets the job done. It’s unclear to me if this needs to be the primary workflow. My brain naturally does better on deep work on one problem..

I have historically not used them but I want to start so that some of the spin up / tear down work of doing any particular task can happen in isolation. For example, drafting a change before I start editing, checking out and setting up code from a branch before I do a review, etc.

I am exactly the same, except I am really excited about this update! It’s not so much “in parallel” but being able to easily jump between threads. It allows me to dive into misc investigations in a side thread without derailing some main context where I’m doing the main editing.

I have a coding agent https://github.com/hsaliak/std_slop where the sessions are in SQL ledger. So /session [new, clone, deletes, undo] are supported and all sessions are persistent. Cloning lets you 'fork' the context and undo lets you roll back, basically solving the problem you state above.

Sessions are linear though, so you cant do this _while_ an existing session is cooking.

That said, I am excited about this update too, I've been playing with ACP support and Zed's UX was bare bones. I want to run my agent with multiple workers now, and see what happens.

I also have this workflow, it’s like you’re on the side quests or on the main story; those are not necessarily in parallel

I made https://github.com/hsaliak/filc-bazel-template bazel target for people who may want to use these two together to make hermetic builds with it.

Clojure had lousy error messages, agents deal with this well. Clojure is capable of producing some of the most dense code I’ve ever seen, so manual code reviews really start to feel like a bottleneck unless your goal is to level up.

> Clojure is capable of producing some of the most dense code I’ve ever seen, so manual code reviews really start to feel like

For me it's the opposite, the dense code is easier to review, because the proposed changes are almost always smaller and more informative. Contrast a change in a typical TypeScript project where changes propagate across tens of files, that you need to jump in-between just to understand the context. In the time it takes me to ramp up understanding what the change is, I've already completed the review of a change in a Clojure program.

Couldn't agree more. And I actually kind of like Typescript, but man, typical Typescript projects are so verbose and sprawling, it's crazy.

Not to mention that Clojurescript often emit safer code than Typescript does. Sounds insane and counter-intuitive, but here's the thing - Typescript actually removes all the type information from the emitted JS. Clojure, being strongly typed retains the strong typing guarantees in the compiled JS code. So all that enormous amount of effort required to deal with complex types, in practice feels like bringing kata choreography to a street fight - it's not utterly useless by itself, but hardly helping in a real fight-or-flight situation. You can impress the attacker with your beautiful dance and even prevent them from attacking you, but that's more like hope than a real strategy.

I would say dense code tends to help code reviews. It just is a bit unintuitive to spend minutes looking at a page of code when you are used to take a few seconds in more verbose languages.

I find it also easier to just grab the code and interactively play with it compared to do that with 40 pages of code.

I've long had the same idea.. this one has legs.

Tool output truncation helps a lot and is one of the best ways to reduce context bloat. In my coding agent the context is assembled from SQLite. I suffix the message ID to rehydrate the truncated tool call if it’s needed and it works great. My exploration on context management is mostly documented here https://github.com/hsaliak/std_slop/blob/main/docs/CONTEXT_M...

This is most certainly vibed with a few optimization focused prompts. Yes - performance is a feature, but so is lack of risk.

My experience so far tells me that the default path with AI tooling is that it lets us create without learning. So the author is right in that they can pay for a seat in this revolution whenever they want.

A practitioner with more experience maybe a few percentage points more productive, but the median - grab subscription, get tool, prompt, will be mostly good enough.

I think this is true at the solo developer scale, but I suspect experience will be much more evident when working with a team.