One participant led a discussion on Claude Code best practices from a developer perspective, followed by open conversation across the group.
Claude Code interfaces and the CLI — The group compared the different ways to use Claude: the web interface, the desktop app’s co-work mode, and the CLI. The CLI remains the most capable option for multi-agent workflows and file system interaction. Sessions can be transferred between local and cloud environments, though cloud-based sessions currently have fewer multi-agent capabilities.
Managing sessions with cmux — A participant demonstrated using cmux to manage multiple concurrent Claude Code sessions. Workspaces with audible and visual alerts help track when agents return responses, and side-by-side panes make it easier to monitor parallel work. This was highlighted as a key workflow pattern for anyone running several CLI agents at once.
CLAUDE.md: less is more — Three months ago, verbose CLAUDE.md files with detailed specs were standard advice. The group consensus is that Claude has improved enough that minimal configuration works better. Overloading the file — especially with negative instructions (“don’t do X”) — can degrade performance by cluttering the system prompt context. Irrelevant instructions compete for attention with the actual task. Planning tools like Spec Kit were mentioned but seen as less necessary now that built-in plan mode exists.
Multi-agent role separation — One participant described running dedicated agents for distinct roles: developer, tester (using Playwright for UI validation and Salesforce-native tools for backend), product manager, and designer. Agents write findings to a shared directory committed to GitHub, and the developer agent is configured via CLAUDE.md to prioritize responding to PM and designer feedback. The goal is removing the human as execution bottleneck — reviewing and steering rather than doing.
Work trees and parallelization — Git work trees enable parallel agent work on isolated branches, with a conflict remediation agent handling merges. A tool called Conductor Build was mentioned for managing work tree lifecycles with Claude Agent SDK integration. The main limitation is shared infrastructure: agents needing the same database or services break the isolation model. Native iOS development was cited as another case where work trees don’t apply well. Running agents in Docker containers was raised as a partial solution.
Security scanning — The Snyk MCP integration was recommended for scanning dependencies for known vulnerabilities, checking packages on every code change. One participant also built a custom pen testing tool after noticing agents pulling in packages of unknown provenance — enough of a concern to warrant automated auditing of what ends up in the repo.
Iterative prompting over incremental patching — A common workflow: write a good prompt or plan, run it end-to-end, evaluate the result, then discard everything and restart with a refined prompt rather than trying to fix bad output incrementally. Pre-training memory (providing context from prior sessions) was noted as significantly improving first-attempt success.
Agent granularity tradeoffs — The group debated whether many small specialized agents risk becoming brittle in a microservices-like way. Arguments for fine-grained agents: dedicated context windows, model selection per task, and workload identity assignment for zero-trust security. Arguments against: startup latency and human management overhead at scale. Model routing — assigning Sonnet, Haiku, or Opus per sub-task — was discussed but no one had validated it was actually working as configured.