Trying out autonomous agents
Last updated: 04.09.2026
Trying out autonomous agents
Audio Narration

Sandcastle is Matt Pocock’s workflow for running Claude Code unattended inside a Docker container. It assigns the agent a GitHub issue in a git worktree, then merges the resulting commits back into the user’s branch. Its init command quickly scaffolds the infrastructure, but useful results still depend on supplying clear, focused tickets. Wayfinder fills that planning gap by breaking an idea that is too large for one session into a map issue and smaller decision tickets. Each ticket addresses a single unresolved question rather than a build segment, producing the self-contained, labeled issues Sandcastle needs. Without this map, vague issues led to equally vague pull requests. Before queueing work, the author uses a grilling skill to challenge assumptions and force difficult decisions. Resolving uncertainty early prevents the agent from making costly guesses during unattended runs. For secrets, the author replaces a plaintext .env file with Varlock and a committed .env.schema. Values are resolved through Doppler and exposed only through process.env during execution, although each secret must still be explicitly forwarded into the container configuration. The author would use the setup again but stresses that ticket quality remains decisive. Every diff is still reviewed, tasks stay tightly scoped, and fully unattended overnight operation remains a future goal.
The setup in one paragraph
Sandcastle is Matt Pocock's loop for running a coding agent unattended. It puts Claude Code in a Docker container, points it at a git worktree, gives it one GitHub issue, then merges the commits back to your branch. The init command scaffolds the whole thing in about a minute. Issues go in, branches come out.
Wayfinder charts the map
The scaffold gives you a loop. It does not give you anything for the loop to eat. That is the part I underestimated.
Wayfinder is a planning skill that takes an idea too big for one session and turns it into a map issue with child decision tickets. Each ticket holds one question whose answer is a decision, not a slice of the build. You work them one at a time until nothing is left to decide.
That output is exactly what Sandcastle wants: small, self-contained, labelled issues. I did not plan the pairing, it just fell out. My first attempt without a map was three vague issues, and I got three vague pull requests back.
Grill me before you commit
Before anything went in the queue I ran the grilling skill against the plan. It asks hard questions and does not accept the first answer. Ten uncomfortable minutes.
Then consider the alternative. A question you did not answer becomes a guess the agent makes at 3am, and you find out over coffee that it guessed wrong. A bad assumption caught at the keyboard costs one sentence. Caught in the morning it costs the whole run.
Varlock so nothing lands on disk
The default is a plaintext .env file next to the config. I did not want credentials sitting on my laptop, so I used varlock instead.
You commit a .env.schema holding the shape of each variable and where to find it, never the value. Mine resolves through Doppler. The loop then runs behind varlock, which puts the resolved values in process.env for the length of the run and nowhere else.
Declaring a secret in the schema does not forward it into the container. That still needs its own line in main.mts. I learned this twice.
Would I do it again
Yes, with the same caveat every time. The loop is only as good as the tickets. Sandcastle is solid infrastructure, and the thinking is still mine. It just moved earlier, into the map and the grilling, before any container starts.
I read every diff. So far that has been easy, because I only gave it small, tightly scoped tasks and sat and watched the runs while they happened. Unattended overnight is the pitch, and I am not there yet. But it did the work I handed it, and I did not have to type any of it.

When the Claude window runs out: my take on T3 Code
T3 Code addresses the frustration of hitting Claude’s five-hour usage limit during focused work. Rather than replacing coding agents, it provides a single desktop interface for tools such as Claude Code, Codex, Cursor, Grok Build, OpenCode, and Antigravity, with users signing in through their own accounts. Each thread remains tied to its original provider, so an unfinished Claude conversation cannot be transferred directly to Codex. However, the surrounding workspace, project, and workflow stay in one app. When a limit is reached, T3 Code identifies the restriction and reset time, allowing the user to start a new thread with another provider and quickly restate the task. The app is free and does not resell or mark up tokens, aligning its incentives with users who want to avoid unnecessary calls. Its MIT license, self-hosting support, public codebase, and more than 21,000 GitHub stars are especially important because it handles provider credentials and repository access. Although founder Theo frequently promotes the product, its transparency makes those claims easier to verify. The Linux desktop app remains young and occasional releases cause problems, but steady improvements and its ability to coordinate separate agents make it a practical solution for maintaining momentum.
Read post
Decisions, not code: a month with Matt Pocock's agent skills
AI agents can generate code quickly, but the real bottleneck is deciding what should be built. Matt Pocock’s skills repository addresses this through tools that clarify requirements before implementation. “Grill me” conducts a persistent interview, mapping an idea into a design tree and identifying the current frontier of answerable questions. It presents numbered questions alongside recommended answers, turning an overwhelming list into a practical review. It researches factual questions itself, leaving genuine decisions to the user, and continues until no assumptions remain. “Grill me with docs” combines this process with domain modeling, recording decisions as ADRs and maintaining a glossary. This preserves reasoning beyond the agent’s context window and gives important terms stable meanings, reducing inconsistency in later work. “Wayfinder” supports projects spanning multiple sessions. It creates a map issue with linked decision tickets, dependencies, and assignment rules that prevent parallel agents from colliding. Tickets resolve decisions rather than represent implementation slices, while the map remains an index. These tools lead to more planning and less rewriting, but they add unnecessary overhead for small tasks. Grilling is most useful for work likely to continue into the following week, while Wayfinder suits only larger efforts requiring a disciplined issue tracker.
Read post