Development-Workflow

For those dabbling with Claude Code subagents: they consume a TON of tokens. Which is fine—if you’re burning them for the right reasons. A blog writer subagent? Maybe that works. You see the final output, judge quality, iterate. But when subagents touch multiple files across your codebase? That’s where things can get problematic. TL;DR Subagents burn 10x more tokens than custom commands. ~50-100K tokens for implementation work vs ~5-10K for the same task with /plan-task. Your mileage may vary, but the difference is substantial. ...

I was watching Miessler demo OpenCode against Claude Code. He fed it a video transcript with 900 lines of custom rules - formatting, content generation, image creation. Complex orchestration. It just… worked. Not because it was simple. The rules weren’t trivial. But because it was focused. One clear task with defined inputs, explicit constraints, specific outputs. It clicked. This is what I’d been building toward with my newly refactored development workflow - breaking work into focused units. Ideation separate from planning. Planning separate from implementation. Implementation separate from testing. Even my shortcut commands in CLAUDE.md follow the pattern: qtest writes ONE test. qfix debugs ONE error. qcom makes ONE commit. ...

I keep hearing that LLMs aren’t good engineers. I think I figured out why, and possibly how to address it. Here’s what I was seeing in my Claude Code workflow. Even with comprehensive specs - detailed HLD, implementation specs, task breakdown - there’s still ambiguity between knowing what to build and knowing the best approach to take when building it. When I’d run /plan-task, Claude would pick a viable path and run with it, without exploring alternatives, because it’s not built to do otherwise. ...