Introduction

As a holiday project in 2026, I decided to experiment with "Vibe Coding"—letting AI lead the entire software development process.

Without writing a single line of code myself, I delegated everything (requirements definition, architecture design, and coding) to AI agents (Gemini, Copilot, ChatGPT / Antigravity, Cursor). In the end, I successfully played audio using an I2S DAC connected to a Pimoroni Tiny2040 (8MB Flash; standard Pico has 2MB)!

The Hardware Setup

📋 Bill of Materials (BOM)

For bench testing, I powered the setup using an LIR2032 rechargeable coin battery (3.7V / 45mAh). It booted cleanly and played sound without issues!

🎬 Demo Video & Repository

How Was the Vibe Coding Experience?

My golden rule for this project was: "Humans do not edit the source code."
My only responsibilities were:

1. Providing requirements
2. Crafting and refining prompts
3. Reviewing AI outputs
4. Verifying operations on physical hardware

I iterated on the prompts by asking Gemini, Copilot, and ChatGPT to review and critique each draft. Once the prompt was refined, I had GitHub Copilot in VS Code summarize the specifications and design. Once I felt the design was solid, I asked it to implement the code.

The Roadblock: Out-of-Memory Infinite Loop

Then came the first major issue.

The original voice samples were in MP3 format, which had to be converted to WAV and stored in the Tiny2040's on-board 8MB flash memory. However, Copilot attempted to write more than 8MB worth of WAV files at once, causing repeated out-of-memory errors.

Instead of identifying that unused audio files could be dropped, Copilot fell into a repetitive loop—trying things like "writing smaller files first" or "changing the file transfer order." It was completely stuck in an infinite loop.

While I paused Copilot and asked it to analyze the converted file sizes in a table, I hit the GitHub Copilot Pro+ monthly limit (7,000 AI credits, $39/mo)!

Breakthrough by Switching to Antigravity

Upgrading to a higher Copilot tier was costly, and it was still going in circles. So I switched development agents to Google Antigravity (Google AI Pro 5TB plan / 2,900 JPY/mo).

With Antigravity, I resumed work and had it analyze the storage footprint. It quickly determined that skipping unused MP3 conversions would keep the total size well within the 8MB limit. It updated the code, and everything started working as intended!
You can view the AI-generated report here.

The entire GitHub repository documentation, including the README, was generated by AI. It was structured surprisingly well. Writing all of this by hand from scratch would have taken days and likely introduced bugs. While there are minor spots where human polishing could help, I kept them as-is to preserve the "100% AI-driven" spirit of this experiment.

Hardware & Sound Quality Evaluation 🎶

I used to think driving a speaker with digital audio had a high barrier to entry. But after discovering I2S, I realized it is quite accessible on microcontrollers like the RP2040.

• Audio Quality: For voice announcements, 16kHz / 4-bit IMA ADPCM provides clear and practical quality.
• Storage Efficiency: IMA ADPCM drastically reduces file sizes. This allows plenty of voice clips to fit inside the Pico's built-in flash without requiring external SD cards or SPI Flash chips.

The Gotcha: Inverted Silkscreen on the PCM5102 Board

While getting sound took only a few hours, I ran into one hardware trap.

I bought two types of I2S modules. One of them, a PCM5102 board, had defective PCB silkscreen printing.

The labels for the configuration jumpers (H1L, H2L, H3L, H4L) on the back were printed upside down (rotated 180 degrees)! I was suspicious at first, but checking online reviews confirmed other users had run into the exact same issue.
Details and wiring workarounds are documented in CONNECTIONS_e.md.

In contrast, the MAX98357A (built-in amplifier) was extremely easy to wire and worked right away. Although mono, it is highly recommended.

AI Quirks & Realities

During development, I added minor features such as adjustable playback speed and volume.

During hardware testing, the playback speed was not changing. When I pointed this out to the AI, it replied confidently: "All unit tests have passed."
I responded: "Can you set the playback speed to 2x yourself and measure the playback duration?"
The AI admitted: "Ah, there was a bug." AI can definitely produce subtle bugs despite green tests!

Another funny incident: I manually adjusted the playback speed to 1.3x in a configuration file. Later, during an unrelated refactoring, the AI quietly reverted it back to 1.0x.
I caught it during code review, but it was a good reminder: it is wise to add an instruction like "Never modify user values in config files without explicit confirmation."

Next Steps

• Prompting Best Practices: Compiling guidelines and patterns for prompt-driven embedded development.
• AI Interaction Strategy: Answering every detailed clarification request from AI quickly leads to human fatigue. When human review gets lazy, AI changes can diverge rapidly, consuming large amounts of AI credits. Striking the right balance of autonomy is key.
• Automated Physical Testing: I am currently setting up automated button actuators with AI computer vision for hardware pass/fail verification.
• Audio Streaming over Wi-Fi: Now that 16kHz / 4-bit audio is verified, the next step is experimenting with audio streaming over Wi-Fi using the Raspberry Pi Pico W (2MB Flash).