All The Machines
← System Log

Escaping the Token Trap: A Pragmatic Approach to AI-Assisted Development

I recently realized I've inadvertently become an AI power user. Leveraging the GSD (Get Shit Done) repository for my workflow, I'm running multi-agent tasks — researching, planning, executing, and verifying — in parallel.

The productivity is undeniable; I've prototyped around ten apps in a few weeks, half of them complex tools. But the overhead is massive. I'm currently maxing out my $200/month subscription. I often start heavy sessions the moment I wake up — before I even have breakfast — and that constant background processing means I frequently hit the weekly limit, making it impossible to work on multiple projects at once.

The issue isn't just cost; it's workflow latency. When you have agents running recursive loops, you aren't just burning tokens — you're bottlenecking your own development.

Here is how I'm re-architecting my setup to move from brute-force token usage to optimized automation.

The "Muddler's" Edge: Reusable Code

I've been a self-taught developer for 20 years, moving from HTML and JavaScript to ActionScript, C#, and Objective-C. I've never claimed to write elegant code from scratch; my strength has always been in adapting existing patterns — finding the right code on Stack Overflow or GitHub and making it work.

AI fits this "assembly" style of programming perfectly. It's the ideal tool for someone who builds by adapting existing solutions rather than writing from zero.

However, this leads to a specific efficiency problem: often, the AI ends up reinventing the wheel for every new project. It re-generates standard code over and over again, which is incredibly token-heavy.

Strategy 1: The "Class" Mentality for VSTs

In traditional programming, you learn to create reusable code. If you use a function twice, you put it in a container or a class so you don't have to debug it in multiple places.

Yet, with AI, we constantly violate this. It is computationally wasteful to ask Claude Code to generate the DSP code for a standard oscillator or envelope follower from scratch. It burns expensive tokens on boilerplate logic.

The Fix: I'm building a local library. I use Python scripts to search and "copy-paste" these proven blocks. You don't need AI for that; you just need simple automation.

Strategy 2: Groundwork vs. "Repairing"

I attempted to mitigate costs by offloading work to cheaper models like DeepSeek or Kimi. The failure rate was too high. The code often broke, requiring me to bring it back into Claude Code to fix it anyway. There was no advantage — just more friction.

The better approach is establishing Base Manuals.

  1. Create a "Base Element" or manual for your specific project type.
  2. Feed that manual to the AI at the start.
  3. This stops the AI from having to "grind" through the basics every time you start a new session.

Strategy 3: Automation over "Hype" Agents

There has been a lot of media noise about autonomous terminal bots (often referred to as "Clawdbot" or "Open Claw" solutions). These are agents designed to run in your terminal and build software for you.

I tried using these tools to build a personal organization system — specifically, a project to automatically transcribe my Telegram audio notes and file them away. It had nothing to do with my core DSP work; I just wanted to automate my "admin" tasks.

The experience was a nightmare. The interface was clumsy — one wrong key press and the session died, or the servers froze due to security blocks. I spent more time fixing the "automator" than I did on the actual project.

I realized I didn't need an unstable AI agent hacking away in my terminal; I needed reliable business automation.

I've since switched to n8n. Unlike the "hype" agents, n8n allows me to build safe, stable workflows for organizing my life. I can automate the research and file management without the risk of an autonomous bot breaking my environment. It handles the organizing so I can focus on the programming.

The Goal: Sustainable Development

My objective is to run concurrent development threads — working on different parts of a project simultaneously — without hitting that $200 wall.

The future of AI coding isn't just about having a smarter model; it's about better strategies. It's about using Python and n8n for the drudge work and saving the creative energy for the music and the machines.

Steve Bolch is the developer behind All The Machines. You can explore his tools and music at all-the-machines.com.

Originally published on Medium