The simplest mainstream options for tools:
1) Claude Desktop which includes Claude Code for Anthropic: https://claude.com/product/claude-code (alternatively the terminal based version; either way get the subscription)
2) Codex for OpenAI: https://developers.openai.com/codex/app (same as above, subscription preferred instead of paying per token)
3) OpenCode for a variety of models: https://opencode.ai/ (they also have a subscription, but this in particular also makes it really easy to connect to OpenRouter)
4) KiloCode is essentially the above, but for VSC derived editors: https://kilo.ai/ (I personally liked RooCode more, but that got retired)
More niche tooling options:
1) Zed is pretty good, though I saw some issues with their LSP Edits and found that connecting them to OpenCode through ACP worked better, still a cool editor: https://zed.dev/
2) If you have to pay for tokens and can't get subscriptions, look at DeepSeek as a provider (V4 Pro with Max reasoning): https://api-docs.deepseek.com/quick_start/pricing
3) I'm also writing a launcher to make running Claude Code with 3rd party providers earlier, early days still: https://ccode.kronis.dev/
Note: for anyone on Windows, if you install the terminal versions of the tools (Claude Code, Codex, OpenCode, ...), you probably want them inside of WSL so there's less confusion with file paths etc. that some models have.
In regards to actually using the tech:
- version control and maybe worktrees
- sub-agents are pretty nice to have, Claude Code also introduced support for longer running workflows
- throw as much tooling as possible at the project, like Oxlint, Oxfmt etc., for Python it might be Ruff and ty or Pyright or whatever
- throw as much testing as possible at the project, maybe require certain coverage or just have CLAUDE.md that nudges the models to write and run tests
- throw as many additional scripts at the project as you want, e.g. how you want the architecture to be laid out, max file length limits etc., whatever common tools don't cover
- some tools also support LSP, use those when possible
- pretty much all models will still output slop, though making fresh instances (even of the same model) review its output, e.g. 3 parallel sub-agents looking for critical/serious issues works pretty well, I just have a review loop that I make the models run before commits
- ideally you'd also test local instances of whatever you build (e.g. real PostgreSQL instance etc.), just so the dev loops are tighter and faster