Just FYI, those discussions might be ending because your analogy comes across as a threat to punch them in the mouth, rather than because it convinces them.
My interpretation of the concern is that propagate implies that the new value is being pushed out to other resolvers, when in fact those other resolvers pull the new value (once their cached value expires).
I started using this today and am really enjoying the notifications when agents are awaiting input, and the status indicators!
But it feels odd to have it outside of tmux. I've got everything else in tmux, but I have to switch to another terminal tab to get to my agents, and then back to my normal shortcuts. I find that a bit jarring... Is that what other folks are doing?
Does this mean adding instructions to AGENTS.md saying to end everything with the bell character? Or do harnesses have this in their settings somewhere?
Forgive me if I'm being naive, but can't you just tweak the compaction prompt to differentiate? Presumably that's what you would do in the separate prompt anyway, right?
Can you say more about how this applies to long-running conversations? I've been thinking about them as well, but can't write wrap my head around how this would be better than (or even different to) standard compaction.
Came here to say the same thing. How could the author possibly illustrate the point of the book without at least 4 case studies and a reference to prehistoric humans?
I've tried most of the tools out there but have used cursor most consistently. Sure, some of the UI quirks get in the way sometimes, but I've found its auto complete predictions to be unparalleled. More importantly, these days I mainly use its Ask mode, Plan mode, and Agent mode. I like that I can use Opus via subscription pricing without Claude Code's wild and buggy harness. And I find cursor's plan mode to perform better than Claude's, but that may just be my personal preferences. I know cursor stopped being the cool thing a few months back, but I genuinely feel most effective with it!
But I'll stop using it now, for the same reason I wouldn't buy a Tesla, or support that maniac in any other way. And I'm sad about that :(
I read this article and was surprised when I reached the end because the whole thing felt like it was setting the stage for some announcement or new thing. But nothing came..? Forgive me if I'm being thick but what was the takeaway?
We have some enterprise customers who require all data be processed in the UK or AU. We've been limited to using Azure OpenAI, which only has older models in those regions (eg 4o, 4.1-mini). I was hoping we'd see the newer models in those regions once they got to AWS, but it looks like the newer models are only available in the US at the moment :(
Rails has several database-backed job backends, but the convention is always to make jobs do one thing, and ideally be very short-lived. This makes building workflows a bit contrived: we end up enqueuing the second job on the last line of the first one, enqueuing the third one on the last line of the second one, etc. The job backend treats these as independent jobs rather than showing them as a connected workflow, and you have to read through a bunch of job classes to wrap your head around the workflow at even a high level
Rails recently introduced a 'continuable' concept, allowing you to checkpoint and resume steps within a job, but it still feels like the convention is too keep jobs with a single responsibility, so it feels odd to use them for true workflows.
Has anyone else experienced this or found a solution to it?