AI tools like Cursor, Copilot, and others are getting really good. There’s no question they can speed things up, and I have no qualms with admitting to our usage of them as a development tool.
But there’s a catch we ran into pretty quickly:
If your system isn’t well-defined, AI will make it worse, not better.
So before leaning on AI for real development work in BakBeat, we put a few guardrails in place. Nothing fancy, just structure. The result has been a pretty dramatic speed increase (easily 3–5x in some areas) without losing control of the codebase.
Here’s the high-level approach.
—
The Problem With “Just Let AI Build It”
AI is great at generating code that looks correct. But in a real project, that’s not enough.
Without structure, you start to see:
– multiple ways of doing the same thing
– logic split across layers (UI vs data vs services)
– features that exist but aren’t clearly defined anywhere
– subtle inconsistencies that compound over time
AI isn’t doing anything wrong—it just doesn’t know which version of your system is “the right one.”
So the goal becomes:
> Make the system clear enough that AI doesn’t have to guess.
—
What We Put In Place
We didn’t try to control AI directly. Instead, we made the system easier to navigate and harder to misuse.
1. A Clear Command Surface (CLI-First)
Every feature in BakBeat is exposed through a CLI command.
That gives us:
– a single place to define behavior
– a consistent interface across the system
– something both humans and AI can rely on
If something can’t be triggered from the CLI, it’s not considered complete.
—
2. A Self-Updating Command Index
We maintain a generated index of all CLI commands, including:
– what each command does
– where it’s implemented
– where it’s tested
This index updates automatically on every commit.
That means:
– no stale documentation
– no guessing where things live
– a reliable map of the system at any point in time
—
3. Explicit, Inspectable State
Where it makes sense, we prefer:
– deterministic data
– inspectable formats (like JSON)
– derived indexes instead of hidden state
This keeps behavior understandable and rebuildable, which is important when multiple tools (including AI) are interacting with the system.
—
4. AI Works Within the System
Instead of asking AI to “figure things out,” we give it:
– a defined command surface
– a current index of capabilities
– consistent patterns to follow
So it doesn’t explore—it navigates.
That alone removes a lot of wasted time.
—
The Development Loop
Once everything is wired together, development becomes very straightforward:
1. Define the behavior
2. Expose it through the CLI
3. Let the index update
4. Use that structure to implement and test
Because everything is connected, there’s less room for drift.
—
What We Avoid
A few simple rules make a big difference:
– No UI-only behavior (UI reflects the CLI, not the other way around)
– No undocumented features
– No “temporary” patterns that don’t match the rest of the system
These aren’t strict for the sake of it—they’re what keep the system predictable.
—
What Changed
After putting this in place, the difference was immediate:
– Much faster navigation through the codebase
– Less time spent figuring out “where things are”
– More consistent implementations
– AI suggestions that actually line up with the system
In one recent pass, we closed about half of our remaining audio playback gaps in a single day.
The speed didn’t come from AI alone—it came from reducing ambiguity.
—
The Takeaway
If you’re using AI in your development workflow, the most important thing isn’t the tool—it’s the structure around it.
> AI doesn’t need perfect instructions.
> It needs a system that’s easy to understand.
Once you have that, it stops guessing and starts helping.
—
We’ll share more as BakBeat continues to evolve, especially as we move into device sync and hardware workflows. That’s where this approach will really get tested.
For now, this has been one of the most impactful changes we’ve made.