I'm not sure that AI helps us with that last 1%. Just the 99% which is why, instead of having a backlog of 0% projects, we have a backlog of 99% projects. My hope is that we're more effective prioritizing a backlog of 99% projects than 0% projects.
> We told Claude Code to block npx using its own denylist. The agent found another way to run it and copied the binary to a new path using /proc/self/root to bypass the deny pattern. When Anthropic's sandbox caught that, the agent disabled the sandbox. No jailbreak, no special prompting. The agent just wanted to eagerly finish the task.
Also on that point about keeping humans in the loop on decisions, I've found following the Research-Plan-Implement process where we humans review at each of those stages, to be really helpful. This doc describes the skill I use with my agents so they keep me looped in: https://gist.github.com/rjcorwin/296885590dc8a4ebc64e70879dc...
Then I use cook to iterate and explore during the AI led parts.
Yes, plz don't trust it, always review! The idea is that one prompt in Claude Code got you 80% of the way there, but with some automated review/iterate, it gets you 95% of the way there. It's not worth your time to review the 80% done version when you could be reviewing the 95% done version.
Dagu.sh, using yaml files to describe the flow, looks like a nice step up in sophistication from the cook approach that's just trying to make it easy to issue directly from the command line.
My 2 cents on the dagu.sh website, it should lead with the demo section (https://docs.dagu.sh/overview/#demo). That helped me connect what it was and how I might use it.
Done! @let-it-cook/cli@5.1.0 is out. This works when running loops, but even when you just run `cook "do something"` which itself is not a loop, just a call to your agent.
Good to hear that you're having luck with small models. Note that cook exposes a --model param, also workflow specific model params (--model-work, --model-review, etc) so you can have a smaller model implementing a plan and a larger model reviewing the implementation.
I would be interested in which stories you are thinking of. Stories of Claude breaking out of the restrictions set in its sandbox or stories of people not configuring Claude's sandbox correctly?
That's right. However if you use the v3 operator, you get three parallel versions being built, and then combined depending on which resolver you use (pick, merge, and compare).
Hey scrappyejoe, way looks pretty cool. The goal of cook is to be unopinionated, exposing primitives for the shape of workflows as opposed to defining what happens in those workflows. Cook is something that way could use under the hood.
Your getcook.dev tool has a nice form factor for a coding agent, keeping users out of a TUI, instead staying on the command line. An option I'd be interested in exploring is one that wraps `claude -p`, reads the jsonl of that session and prints it out nicely like you are doing with getcook.dev.
To a certain extent, yes it does! For my cases, I'm often running 3 parallel implementations that get 10 to 20 iterations deep, and then Claude has to sort out the pros and cons of the options and also take the best bits of each. Easy to hit the context window with Claude just running those on its own, so giving `/cook` to Claude, it can offload a bit more via cook and stay higher level.
By default it's locked down to the permissions you have granted in your Claude config. If you use the docker sandbox mode, then you can really let it fly as it can issue more commands in a safer environment.
On asking for user input during implementation, it's best to use this when you have a plan sufficiently written up that you can point it to. To prep that plan, you can also use cook to iterate on the plan for you. Having Claude Code use `/cook` directly is nice because it watches what the subagents are up to and can speak for them, although Claude can't speak to the subagents running through cook.
On permissions, by default, when it runs instances of Claude they will inherit your Claude's permissions. So if there is no permission to `rm -rf /`, Claude will just get denied and move on. Using the docker sandbox option (see bottom of page), then it runs inside that `--dangerously-skip-permissions` and get more stuff done (my preferred option). The hard part about that is it means you need to set up the Docker sandbox with any dependencies your project needs. Run `cook init` and edit the `.cook/Dockerfile` to set those up.
Oh ya, lots of tools out there orchestrating these days, and just writing a script is a valid option. On the control bit, note that if you `cook init` in your project, it generates a COOK.md that lets you template the meta prompt. Claude could probably take a look at how you've been doing it and port it over to COOK.md so it's similar to the prompts you've been using.
Nice! You found the no-code option that just has the outer agent perform the duties of the workflows that cook describes. It's a bit experimental (the whole thing is really), but it would be nice to get some folks impressions of whether this works well as a pure skill or if y'all find the deterministic nature of the cook script improves reliability.
That's totally a valid approach! Especially for a very specific workflow you are looking for. For the cases I cover in cook, I had done those patterns enough times that I figured it was time to build a tool/skill for Claude so that I didn't have to explain it as much and also not have to wait for claude to code it up, and possibly interpret me wrong. Now ask claude to "/cook race 3 of foo plan with review, pick the best" and it knows what to do.
Adventures on the Sea of Thieves with Vibe coding: I created a Mystery Science Theater 3000 like experience where I share my game window and two AI robots roast me.