Lee
Basnight

The Problem.

Traditional audio plugin development is a complex, multi-disciplinary process requiring deep expertise in DSP, C++, and platform SDKs. Before AI, this entirely manual workflow typically took 6–18 months from concept to release.

1. Ideation & Algorithm Development (4–12 weeks): Define the plugin's purpose, research the market, and prototype DSP algorithms using mathematical tools like MATLAB.
2. System Architecture (2–4 weeks): Plan the codebase structure, choose a framework (e.g., JUCE), and decide on plugin formats (VST, AU, AAX).
3. Core DSP Coding (8–16+ weeks): Manually translate algorithms into highly optimized, real-time C++ code that runs without glitches on the audio thread.
4. GUI Design & Implementation (6–12 weeks): Design and code the visual interface, connecting UI elements to underlying audio parameters.
5. Integration & Testing (4–8 weeks): Merge the DSP engine and GUI, then test extensively across different DAWs to find and fix bugs.
6. Optimization & Polishing (4–8 weeks): Profile code to eliminate performance bottlenecks, reduce CPU usage, and refine the user experience.
7. Beta Testing & Final Fixes (4–8 weeks): Release to external testers for real-world feedback, then address any remaining issues.
8. Packaging & Release (2–4 weeks): Create installers, digitally sign the code, and prepare all marketing and distribution materials.

The Opportunity.

Can a AI native framework be developed, that allows a small or solo product team to ship audio software, in a fraction of the time? The answer is YES!

The Process (Setup).

The goal was to engage and mold the latest agentic LLMs to create a reusable framework, for the specific purpose of shipping audio processing software to market. However, the fundamentals of this process is applicable and adaptable across any digital product.

Tools Used: Claude and Claude Code (via Google's Antigravity IDE)

1. Provide the agent with a detailed role and career specific data set, including relevant skills/.md files.
2. Discuss and reverse engineer desired user flow, product functions and objectives, with the agent which should create a granular product roadmap and a formal .PRD file for the engineering agent (Claude Code).
3. Based on the PRD, have the agent install the proper connectors, grant permissions (necessary) and create a sandbox for communication with internal systems and resources.

The Process (Engineering).

AI agents can one-shot almost any product/function in minutes; But can it do so correctly while meeting desired specifications? Efficient AI engineering requires guardrails, guidance and communication.

Tools Used: Claude Code (via Google's Antigravity IDE)

1. AI agents are b2c and b2b products, with the ultimate objective of satisfying the customer and client. Because of this, every LLM model has default logic and rationale settings, which is the primary source for hallucinations and error. This default programming has to be undone via custom instructional guides.
2. Install two separate guide protocols. The first, should be a user engagement guide, which includes detailed agent/user instructions (ie, "do not lie or take shortcuts in the code, for the sake of quickly satisfying a request"). The second should be a living .md file, where mistakes will be documented and referenced before every new compile, in order to prevent the agent from repeating mistakes.

1. Human testing. Agents are multi-modal. They can capture and "see" images. They can read text. They can analyze audio waveforms. However, agents can not properly interpret functionality versus objective. Usability testing is crucial when coding with an agent.
2. The bulk of effort with human/agent teams will come from the Product Feedback Loop. The key is to document and cement any positive actions and thought processes into a future "Setup" protocol. This process will singlehandedly reduce execution timelines with every task. Doing so, is how you condense a two month project into a two week project, etc.

The Process (Engineering, Failure).

At the current moment (8/26) AI agents still hit points of failure despite best efforts. These are lessons we can learn from and reverse engineer for future builds. Some roadblocks in this project included…

1. Code architecture deletion. The agent erased a small block of code to solve one problem, which eventually caused another.
2. Visual verification glitch. The screenshot protocol command had to be reinstalled, so that the agent could visually verify updates, before declaring an action complete.
3. The Figma MCP misread component spacing by 1 px, causing a chain reaction, that mis-aligned the entire design.

…All of these errors, we're researched, discussed with the agent and documented in the living .md file, so that they are less likely to occur in the future.

The Process (Design).

Product Designers, who have an understanding of how to collaborate with AI are more important now, than ever. Agents are great at wireframes, but true beauty comes from the human touch.

Tools Used: Claude Code (via Google's Antigravity IDE) and Figma

1. Code editors, will deliver a bare bones visual representation of your product for testing. This is how the software see's the functions of your application, based on the initial PRD. It takes a Design System, UX and UI knowledge to deliver a high fidelity beta or MVP.
2. *You can also reverse this process (depending on scope, complexity and application). Design in high-fidelity, first within a Design System, with all components and features in place. Afterwards, have the engineering agent code the functions via detailed visual notations and process logic.

The Process (Design, Figma + Claude Integration).

The Figma CLI and MCP are standardized tools, but the list of Figma connectors and agent skills are growing daily.

Tools Used: Figma MCP, Claude Code (via Google's Antigravity IDE) and Figma Dev Mode

1. Once the product has been designed in high fidelity to company spec. There are a litany of Figma .md skills, that integrate into Claude so, that each application can speak to the other.
2. Some, (but not all) functions include…
   1. get_design_context — the full design spec of a frame: layout, spacing, colors, typography, component structure
   2. get_variable_defs — pulls your design tokens (colors, spacing scales) as actual variables
   3. get_libraries + search_design_system — inventory what components/tokens exist
   4. figma-generate-library skill — reads your code and builds a matching Figma component library

The Process (Deployment).

Deployment protocols vary depending on application and destination. The Fischer Music Club audio software requires packaging and code signatures, in order to be installed on consumer hardware.

Tools Used: Claude and Claude Code (via Google's Antigravity IDE)

1. Claude was used to research packaging protocols and to create a deployment roadmap.
2. The software was then installed on an air-gapped system, user tested and iterated upon for new version releases and updates.

Conclusion.

Building out the complete Fischer Music Club software framework took roughly one month. Within that time, we standardized protocols for software Setup, The Engineering Process, Design and Deployment. With these systems in place; We've been able to ship thirteen individual pieces of high quality audio software and counting. Each new idea takes around 5 days GTM opposed to the 6-18 months that was previously required for one application.