> I usually have one or two tasks running, but I don't feel pressure to maximize parallelism. Most of my brain is already occupied with thinking hard about the shape of what I'm building — and that work can't be parallelized. I can't do more; anything on top would encure a task switching cost.
Maybe there should be new agent UI's that help you get the most out of a singular work stream.
For example being able to spin up an asynchronous agent in a side window that can iterate with you on ideas while the main agent works, and then send any outputs to the main agent easily.
I started testing out with open code a systemd Path processor that runs a opencode command that immediately evaluates the skill and improves it.
It taught me a bit about how non-deterministic these things are, because I started with a skill that was suppose to explain how to make a skill, but ended up with diverging from 'this is a template' to 'implement this text exactly' and the divergence was more about how I described it, what I provided, etc.
However, the overall architecture made a fair amount of value discoverable. Things it needed though were lock files, to prevent constant loops. Trying to get the AI to think and act in series was a crapshoot. Even saying do 1. lock, 2. write, 3. unlock, it'd do #2, then do 1 then 3, because those concepts are tightly related.
Then there was: how to prevent it from looping over the same skill, could lock files work for that? Sure, but not in the same context as the systemd locking, because once I mentioned skill/ locking, suddenly it wasn't locking the skill directory, but the skills/, etc. Again, because the conceptual model is too close. To solve that, I switched to readonly. But this time, the instructions was only, mark the skill as readonly when the evaluation was complete.
So, you could definitely implement a similar system to something like a test/ harness that watches X files and revises & runs X tests, but the complication is opencode's weird directory/project structure. For whatever reason, they do auto-search on working directories rather than explicit locking to a directory. If we could lock opencode to a directory, it'd be pretty easy to launch them and lock them there, then externally, systemd/inotify can launch them.
Which gets to your comment: yeah, if you take the OS as the testing harness, you could device any number of parallel task to be launched based on your axtivity.
I'm running everything locally, and I'm generally exploring where these things excel and where it just wastes time doing things that require intellgence. So far anything I'd do that's basically copy/paste/find/replace, it excels; If there's a Docker build process that needs to be upgraded, that works, and with some babysitting over a day, gets something I'd have done full focus in the same time.
I've been doing similar: analog-ish for deep thinking and its been akin to the 'measure twice, cut once' adage and I've noticed the projects have improved outcomes. PS. If OP sees this: How are you liking the Pentax 17?
> I usually have one or two tasks running, but I don't feel pressure to maximize parallelism. Most of my brain is already occupied with thinking hard about the shape of what I'm building — and that work can't be parallelized. I can't do more; anything on top would encure a task switching cost.
Maybe there should be new agent UI's that help you get the most out of a singular work stream.
For example being able to spin up an asynchronous agent in a side window that can iterate with you on ideas while the main agent works, and then send any outputs to the main agent easily.
I started testing out with open code a systemd Path processor that runs a opencode command that immediately evaluates the skill and improves it.
It taught me a bit about how non-deterministic these things are, because I started with a skill that was suppose to explain how to make a skill, but ended up with diverging from 'this is a template' to 'implement this text exactly' and the divergence was more about how I described it, what I provided, etc.
However, the overall architecture made a fair amount of value discoverable. Things it needed though were lock files, to prevent constant loops. Trying to get the AI to think and act in series was a crapshoot. Even saying do 1. lock, 2. write, 3. unlock, it'd do #2, then do 1 then 3, because those concepts are tightly related.
Then there was: how to prevent it from looping over the same skill, could lock files work for that? Sure, but not in the same context as the systemd locking, because once I mentioned skill/ locking, suddenly it wasn't locking the skill directory, but the skills/, etc. Again, because the conceptual model is too close. To solve that, I switched to readonly. But this time, the instructions was only, mark the skill as readonly when the evaluation was complete.
So, you could definitely implement a similar system to something like a test/ harness that watches X files and revises & runs X tests, but the complication is opencode's weird directory/project structure. For whatever reason, they do auto-search on working directories rather than explicit locking to a directory. If we could lock opencode to a directory, it'd be pretty easy to launch them and lock them there, then externally, systemd/inotify can launch them.
Which gets to your comment: yeah, if you take the OS as the testing harness, you could device any number of parallel task to be launched based on your axtivity.
I'm running everything locally, and I'm generally exploring where these things excel and where it just wastes time doing things that require intellgence. So far anything I'd do that's basically copy/paste/find/replace, it excels; If there's a Docker build process that needs to be upgraded, that works, and with some babysitting over a day, gets something I'd have done full focus in the same time.
I've been doing similar: analog-ish for deep thinking and its been akin to the 'measure twice, cut once' adage and I've noticed the projects have improved outcomes. PS. If OP sees this: How are you liking the Pentax 17?