5. it's not just docker, give it playwright MCP server so it can see what it is implementing in UI and requests

6. start in plan mode and iterate on the plan until you're happy

7. use slash commands, they are mini prompts you can keep refining over time, including providing starting context and reminding it that it can use tools like gh to interact with Github

not sure I agree on 1.

2. compact when you are at a good stop, not when you are forced to because you are at 0%

Use agents to validate the code. Is it over engineered, does it conform to conventions and spec, is it actually implemented or half bullshit. I run three of these at the end of a feature or task and it almost always send Opus back to the workbench fixing a bunch of stuff. And since they have their own context, you don't blow up the main context and can go for longer.

chef's kiss right here

> give it playwright MCP server

Or just `$ playwright`. Skip the MCP ceremony (and wasted tokens) and just have CC use CLI tools. Works remarkably well.

> 5. Monolithic with docker orchestration: I essentially 10x'd when I started letting Claude itself manage docker containers, check their logs for errors, rm them, rebuild them, etc. Now I can get an entirely new service online in a docker container, from zero to operational, in one Claude prompt.

This is very interesting. What's your setup, and what kind of prompt might you use to get Claude to work well with Docker? Do you do anything to try and isolate the Claude instance from the rest of your machine (i.e. run these Docker instances inside of a VM) or just YOLO?

Not the parent but I've totally been doing this, too. I've been using docker compose and Claude seems to understand that fine in terms of scoping everything - it'll run "docker compose logs foo" "docker compose restart bar" etc. I've never tried to isolate it, though I tend to rarely yolo and keep an eye on what it's doing and approve (I also look at the code diffs as it goes). It's allowed to read-only access stuff without asking but everything else I look at.

I YOLO and there isn't much guidance needed, it knows how docker and compose etc. works, how to get logs, exec in etc.

"bring this online in my local docker" will get you a running service, specify further as much as you like.

I had success with creating a VERY detailed plan.md file - down to how all systems connect together, letting claude-loop[1] run while I sleep and coming back in the morning manually patching it up.

[1]: https://github.com/DeprecatedLuke/claude-loop

What are some examples of what you've got it to do?

``` # PostgreSQL Web API Project Plan

## IMPORTANT - Use thiserror, create the primary struct ServiceError in error.rs which has all #[from], do not use custom result types or have errors for different modules, all errors should fall under this struct - The error from above should implement IntoResponse to translate it to client error without leaking any sensitive information and so that ServiceError can be used as error type for axum

## PLAN

### Project Setup (Completed) Set up Rust workspace with server and jwt-generator crates (Completed) Create Cargo.toml workspace configuration with required dependencies (axum, sqlx, jsonwebtoken, serde, tokio, uuid, thiserror) (Completed) Create compose.yaml for PostgreSQL test database with environment variables (Completed) Design database schema in tables.sql (data table with key UUID, data JSONB, created_at, updated_at; locks table with lock_id UUID, locked_at, expires_at)

### Database Layer (Completed) Implement database connection module with PostgreSQL connection pool (Completed) Create database migration system to auto-deploy tables.sql if tables don't exist (Completed) Implement data model structs for database entities (DataRecord, Lock)

### JWT System (Completed) Create jwt-generator utility that takes secret key, permissions (read/write), and expiration time (Completed) Implement JWT authentication middleware for server with permission validation (Completed) Add JWT token validation and permission checking for endpoints

### Core API Endpoints (Completed) Implement POST /set endpoint for storing/updating JSONB data with partial update support using jsonb_set (Completed) Implement GET /get/<key> endpoint with optional sub-key filtering for partial data retrieval (Completed) Add automatic created_at and updated_at timestamp handling in database operations

### Streaming & Binary Support (Completed) Implement streaming bytes endpoint with compact binary format (not base64) for efficient data transfer (Completed) Add support for returning all data if no specific format specified in GET requests

### Lock System (Completed) Implement database-backed lock system with locks table (Completed) Create POST /lock endpoint that tries to obtain lock for 5 seconds with UUID parameter (Completed) Create DELETE /unlock endpoint to release locks by UUID (Completed) Add lock timeout and cleanup mechanism for expired locks

### Error Handling & Final Polish (Completed) Implement comprehensive error handling with proper HTTP status codes (Completed) Add input validation for all endpoints (UUID format, JSON structure, etc.) (Completed) Test all endpoints with various scenarios (valid/invalid data, concurrent access, lock timeouts) ```

took 4 iterations (>30 minutes!), everything works as expected. the plan itself was partially generated with ccl since I told it to break down tasks into smaller steps then with some manual edits I got it down to that final product. I later swapped locks to be built on a lease system and it handled that quite nicely as well.

You are the 5% they were talking about lol.

Surprisingly - only averaging $70 a day.

I'm fascinated by #5. As someone who goes out of my way to avoid Docker while realizing its importance, I would love to know the general format of your prompt.

It's the difference between Claude making code that "looks good" and code that actually runs. You don't have to be stuck anymore saying, "hey help me fix this code." Say, "Use tmux to create a persistent session, then run this python program there and debug it until its working perfectly"

Letting Claude manage docker has been really good.

I’m working my way through building a guide to my future self for packaging up existing products in case I forget in 6 months.

At the same time frontier models may improve it, make it worse, or it stays the same, and what I’m after is consistency.

I have the main agent use Opus, and have it always call sub-agents running Sonnet. That's the best setup I've found.

I turn off compacting to be manual, makes it easy to find a stopping point and write all context out to an md file before compacting.

First prompt isn't very important to me.

I haven't found i need special phrases. What matters is how context heavy I can make my subagents.

Where are you hosting those containers? Our serverless/linux cli/browser IDE at https://brilliant.mplode.dev runs on containers in our nascent cloud platform and we’re almost ready to start serving arbitrary containers on it deployed directly from the IDE. I’m curious if there are any latency/data/auth/etc pain points you’ve been running into

Sometimes it's a bit too eager to mess around inside the containers, like when I ask it to understand some code sometimes it won't stop trying to run it inside the container in a myriad of ways that won't work.

It once did a container exec that piped the target file into the projects cli command runner, which did nothing, but gives you an example of the string of wacky ways it will insist on running code instead of just reading it.

How are you using Claude Code 16 hours a day?

If Opus is worse than Sonnet then why did they even release the model? What is it for?