I've been using Claude code 12-16 hours a day since I first got it running two weeks ago.
Here's the tips I've discovered:
1. Immediately change to sonnet (the cli defaults to opus for max users). I tested coding with opus extensively and it never matches the quality of sonnet.
2. Compacting often ends progress - it's difficult to get back to the same quality of code after compacting.
3. First prompt is very important and sets the vibe. If your instance of Claude seems hesitant, doubtful, sometimes even rude, it's always better to end the session and start again.
4. There are phrases that make it more effective. Try, "I'm so sorry if this is a bad suggestion, but I want to implement x and y." For whatever reason it makes Claude more eager to help.
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.
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.
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"
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.
## 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.
> 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.
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.
1. Immediately change to sonnet (the cli defaults to opus for max users). I tested coding with opus extensively and it never matches the quality of sonnet.
2. Compacting often ends progress - it's difficult to get back to the same quality of code after compacting.
3. First prompt is very important and sets the vibe. If your instance of Claude seems hesitant, doubtful, sometimes even rude, it's always better to end the session and start again.
4. There are phrases that make it more effective. Try, "I'm so sorry if this is a bad suggestion, but I want to implement x and y." For whatever reason it makes Claude more eager to help.
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.