1) OpenCode. Despite its
many shortcomings and constant bugs, it's good enough for basic work. Use the web interface so you can switch around sessions easily, keep it running in the background (on a VPS for example). Add to it MCP servers for other systems you use, like AWS Docs MCP, Atlassian MCP, Linear MCP, SearXNG MCP, Playwright MCP, etc, which basically multiplies the AI's usefulness. Tune config to block all use of /tmp/ because the AGENTS.md instructions to not use that dir are always ignored. Set API tokens in env vars for most services and modern AI models will figure out how to use them (cli, api, etc).
2) OpenCode Go subscription, backstopped by Chutes Plus subscription, OpenRouter with $10 in credit (for very rare use of SOTA models), and various free providers (options: https://codeberg.org/mutablecc/calculate-ai-cost/src/branch/...). I almost never run out of the OpenCode Go subscription so I'm not a heavy user. Use Kimi K2.6 or GLM 5.1 to develop plans or do complex work, DeepSeek V4 Pro for simpler planning or less complex work, DeepSeek V4 Flash for implementing plans or doing simple tasks.
3) Some kind of 'ticketing' system for the AI. At work we use Linear, at home I tried Beads but I didn't like how bloated it got, so I made my own (https://codeberg.org/mutablecc/dingles). Important to have a way to plan work, persist the plan, and work on each item til they're done. In general you're going to use your AI coding agent's Plan Mode to first build a plan around anything you do, and tell it to ask you questions to align on the solution and use question-asking tools for convenience. Then when the plan is correct, have it make all the tickets. If your context window is nearing halfway full, start a new session to begin working on the tickets, and have it commit and close them as it goes.
4) Craft an AGENTS.md (or find somebody else's) that explicitly uses TDD to craft tests. You write the test first, and verify it looks like it will actually check for the expected results; do not continue until your tests look valid to you, the human. Commit them when they look good. Then have the agent write the code to make the tests pass. If you don't do this, it will churn out tests that pass but don't actually identify when things break. You also need end-to-end tests to actually run the app and verify it works, via Playwright, screenshots, running CLIs in Docker containers, etc. This is much harder to do correctly than just generate seemingly-working code.
5) OpenCode does a decent job at balance between not asking you for permissions, and gating things outside the repo. But it's not really "safe". Your best bet is to run a VM (colima) with Docker container (Ubuntu) and run all your AI stuff in the container. This way you can use "yolo mode" to have the AI churn without you and the only thing it can destroy is the Git repos you volume-mount into the VM & Docker container. (I have some of that setup in code here: https://codeberg.org/mutablecc/ai-agent-coding)
6) If you start letting the AI do remote things (like manage remote Git repo, push, make PRs, etc) it is more likely it will do something destructive (like force-push Git repos with destructive changes, create/destroy cloud resources, SSH into boxes and destroy those boxes, etc). So be very careful not to instruct the AI to do anything remote, unless you have set up read-only credentials for the AI, and it can't somehow gain access to the read-write credentials. This is another reason VMs/Docker are good, you can make sure to only volume-mount the credentials you want it to have access to.
7) There is a full walkthrough of AI coding here that is very thorough and battle-tested (https://www.youtube.com/watch?v=-QFHIoCo-Ko). Watch the whole thing (yes it's long) to save yourself a lot of trial-and-error later.
