I’ve been using Claude Code every day for almost a year. Over time, I realized that the real savings come neither from the model you pick nor from a perfect prompt: they come from how you divide the work between Bash scripts and skills.
The “let the agent do everything” trap
When you discover a coding agent like Claude Code, the reflex is to delegate everything to it. Including the most mechanical tasks: discovering a project’s context, asking three scoping questions, creating a folder structure, guessing where a file should go.
The problem is that every one of these actions is billed in tokens and burns reasoning time for a result that needs none. The more repetitive the task, the wider the gap grows:
- Slower: the agent explores instead of executing.
- Pricier: every token spent rediscovering the context is billed.
- More errors: the agent reinvents, every time, what should be fixed.
Handing a deterministic task to a probabilistic system means paying top dollar to introduce uncertainty exactly where you don’t want it.
Bash for the mechanical, the skill for the reasoning
The approach I apply rests on a clear division of labor. Bash handles everything mechanical and deterministic. Skills handle what requires reasoning: interpretation, writing, context-dependent decisions.
In practice, I use two kinds of scripts that map to two different moments in the workflow.
Case 1: prepare the context before launching Claude
The first kind is interactive Bash scripts that prepare the ground upfront.
The script asks the questions itself, collects the business variables, generates the project structure, and writes a pre-filled CLAUDE.md file. By the time Claude starts, everything is in place: it has nothing to discover, nothing to guess. It gets straight to reasoning on a solid base.
The savings are twofold: no tokens spent on exploration, and an identical context on every run. A script’s reproducibility replaces an agent’s improvisation.
Case 2: delegate heavy lifting from a skill
The second kind kicks in during execution. A skill can delegate a costly task to a Bash script, wait for it to finish, then take back control.
A concrete example from my own workflow: a pipeline that transcribes audio to text with Whisper, sorts the transcribed files into the right folders, then sends a Telegram notification. The skill orchestrates, but the scripts do the heavy lifting.
The hand-off mechanism
The technical detail that makes this smooth is simple: the Bash script emits a marker on its standard output (stdout) when it finishes, for example TRANSCRIPTION_DONE: 3 files generated.
#!/usr/bin/env bash
set -euo pipefail
INPUT_DIR="${1:?Usage: transcribe.sh <directory>}"
count=0
for file in "$INPUT_DIR"/*.m4a; do
[ -e "$file" ] || continue
# ... actual transcription here ...
count=$((count + 1))
done
# Completion marker read by the skill
echo "TRANSCRIPTION_DONE: ${count} files generated"
That last line is a contract: the TRANSCRIPTION_DONE: prefix is a marker you choose once and the skill recognizes. You can put a counter, a path, or a status in it — whatever the agent needs to decide what comes next.
The skill reads that marker from the script’s output and automatically chains the next steps, without asking for confirmation. The hand-off happens with no human intervention, and crucially without the agent spending a single token supervising a purely mechanical task.
To adapt it to another use, just replace the script’s contents with your own task — build, export, conversion — while keeping the completion marker. The skill itself doesn’t change.
It’s no accident
This complementarity is far from anecdotal. Boris Cherny, the creator of Claude Code, points out that Bash was the very first language made accessible to a coding agent. That design choice says something essential: a powerful agent needs a deterministic foundation to lean on.
The result of this approach is clear: the agent starts on a base that’s already built, the deterministic stays deterministic with no risk of hallucination, and the token bill melts.
So where do you draw the line?
The question I now ask myself on every task is always the same: does this need reasoning, or just execution? That line, simple to state, radically changes the cost and reliability of an AI-driven workflow.
If you want to structure your own Claude Code or MCP workflows — deciding where to put the deterministic and where to put the agent, cutting cost and latency — I can help you with both architecture and implementation. Let’s talk through my contact page.