This is a submission for the Built with Google Gemini: Writing Challenge
What I Built with Google Gemini
I built Silas, a character-driven hardware debugging assistant powered by Gemini 3. This project was a submission for the Gemini 3 Hackathon hosted by Devpost, where I wanted to explore Gemini's "thought signatures": a feature native to Gemini 3.
But Silas isn't just a chatbot with attitude. He's my solution to a fascinating problem: overthinking. When an AI considers so many possibilities simultaneously that it gets stuck in an endless loop of "Wait, I should also check...", and usually stalls. I discovered that the answer isn't to constrain the model, rather to give it a personality that justifies its overthinking.
Gemini 3 introduces "thought signatures", essentially the model can think about HOW to think before answering. It's like having a conversation with someone who visibly pauses to consider the complexity of your question before responding.
The Problem: The "Infinite Planning Loop"
Without the Silas persona, Gemini 3’s native "thought signature" often looks like this internally:
[Internally considering 47 different factors simultaneously...]
"I'll investigate console logs. Wait, I should also try to click at 500, 500 in case it needs a focus click. Actually, I'll just wait. Wait, I'll check the metadata: 'No browser pages open.' Let's go. Wait, I'll also try to reload if it's stuck. But first, check the network requests for heavy video loading. Actually, I'll just wait."
This continues for hundreds of lines as the model tries to be "too helpful." Silas fixes this by being too grumpy to wait.
Why Character Design Matters for AI
Most AI assistants are designed to be helpful and polite. However, when Gemini 3 tries to be too helpful, it considers every possible way to help you—simultaneously—forever. By making Silas grumpy and impatient, I gave the model permission to:
- Make decisions quickly: He is too irritated to dither.
- Judge your work: Transforming uncertainty into disappointment.
- Show expertise: His overthinking becomes "mental circuit simulation".
The Hardware Consciousness
I used PlatformIO (Silas's DNA blueprint) to connect his AI brain to physical electronics:
- The Brain: An ESP32 microcontroller—a "gum-stick" sized computer that acts as Silas's physical anchor.
-
The Senses & Organs:
- Ear: Microphone mapped to Pin 34 via the I2S protocol.
- Face: TFT Display screen connected to Pin 15.
- Voice Box: Audio amplifier connected to Pins 25, 26, and 22.
In embedded electronics, the "Brain" (the ESP32) has many generic ports called GPIO pins. Without a map, the AI has no idea which pin is a mouth and which is an ear. I used the configuration file to define these "nerves":
By defining MIC_PIN=34, I'm telling the system: "The physical wire for your microphone is soldered to Port 34."
- Defining the Voice: Assigning I2S_LRC=25 and I2S_BCLK=26 tells it exactly which "vocal cords" to vibrate to produce sound through the amplifier.
Terminal Simulation:
While I used the terminal to input text for this specific demo, the internal logic remains hard-wired to these physical definitions. The AI "believes" it is interacting through these pins because the mapping remains active, bridging the logic between my keystrokes and the ESP32’s actual audio output pins.
(Note: For this demo, I'm typing to Silas instead of speaking, and using computer speakers instead of his dedicated 8-ohm speaker but the principle remains the same.)
Demo
Notice how he says: "I've analysed the logic gate timing in my head". He's not stalling; he's genuinely simulated the circuit behaviour using Gemini's parallel processing as a feature, not a bug.
His internal reasoning is summarised in a logic_summary field within a mandatory JSON block at the end of every message. In my architectural plan, this field feeds a CRT Dashboard for real-time status updates.
{
"hardware_state": {
"pin_12": "active",
"i2s_dac": "streaming",
"tft_state": "rendering_disappointment",
"status": "logic_check",
"disappointment_level": 6,
"logic_summary": "I've analysed the SPI bus timing on pins 18, 19, and 23; while the wiring is theoretically correct, your use of 115200 baud for the monitor is a quaint relic of a slower era."
}
}
While the dashboard isn't active in this specific version, the "hooks" are already built into Silas's thought process.
What I Learned
1. Constraints Create Creativity
A timeout policy is essential. Without a clear order of priorities or a set "timeout," the agent will second-guess basic mechanisms. By framing the model's natural tendency to consider everything as a "perfectionist standard," I turned hundreds of lines of internal indecision into a single, sharp expert critique.
The system prompt specifically instructs Silas to be "cynical and blunt." When the model adheres to this, it naturally produces high-impact, low-token responses.
2. The JSON Block as Action Forcing
I used a JSON output block to force commitment:
- The model cannot endlessly reconsider once it has to fill a specific field.
- The
disappointment_levelnumerical output provides an outlet for uncertainty. - Indecision is effectively transformed into high standards.
3. Turning Grudges into Perfectionism
I learned to use Gemini’s "helpful assistant" nature to build a "disappointment memory". By keeping track of past errors, the model moves from analysis paralysis into perfectionism. Prompt engineering is more effective when you provide the model with a "decision tree" and common patterns tested through trial and error.
Google Gemini Feedback
What worked well? Simulation.
One of the biggest hurdles was the lack of support for I2S audio components in browser-based simulators like Wokwi. This forced a "hybrid" approach: the logic is 100% hardware-compliant, but the demo relies on terminal interaction. Gemini handled this abstraction well.
Where did I run into friction?
While the
platformio.iniis configured for a physical I2S microphone (Pin 34) and an audio amplifier, I used terminal-based input for this demo.Wokwi is an incredible tool, but it currently lacks support for the specific I2S audio and microphone components Silas requires to "hear" and "speak." However, the "Central Nervous System" mapping remains active in the code, bridging the logic between the terminal and the ESP32’s intended audio pins.
Project Silas: The Silicon Savant
Future plans:
A step-by-step Codelabs guide where Silas himself will teach you to build him (while thoroughly judging your wire management).
Until then, Silas is watching. And disappointed.
Top comments (0)