Skip to main content

AI-Assisted Programming with Google Antigravity in VS Code

Applicable models

Applicable to the Cubicore Devboard (ESP32-S3 + Semtech SX1262 on RAK3112 module).

Product status

Confirm the current hardware revision, pinout allocations, and supported firmware features in the Cubicore Devboard product documentation before deploying in field production.

1. Introduction​

Developing embedded firmware for multi-protocol platforms like the Cubicore Devboard requires balancing microcontroller registers, peripheral buses, radio parameters, and build toolchains. Once a PlatformIO project is building and uploading successfully, an AI coding agent can help plan changes, generate code, explain unfamiliar files, analyze build errors, and interpret serial output.

An AI coding agent acts as a capable pair programmer inside your development environment. However, an agent assists with engineering work—it never replaces physical hardware verification. Software models cannot physically probe GPIO voltage levels, measure RF impedance, or observe whether an LED actually illuminates.

This guide uses:

  • Visual Studio Code as the primary development environment
  • PlatformIO for project configuration, compilation, firmware upload, dependency management, and serial monitoring
  • The Arduino framework for firmware development
  • The Google Antigravity extension as the AI coding agent inside VS Code
  • The physical Cubicore Devboard for hardware verification
Toolchain Independence

Google Antigravity is an optional productivity tool. It is not required to develop firmware for the Cubicore Devboard. All development, compiling, flashing, and monitoring workflows can be completed entirely with standard PlatformIO tools inside Visual Studio Code. Furthermore, the structured workflows taught in this guide apply equally to other VS Code-compatible AI coding agents.

2. Prerequisites & Hardware Safety​

Before introducing an AI coding agent into your workflow, ensure your underlying development toolchain and hardware connection are fully operational.

Hardware Prerequisites​

  • Cubicore Devboard (V1.3 with RAK3112 module: ESP32-S3 + SX1262).
  • USB Type-C Data Cable (must support USB 2.0 data communication, not a charge-only cable).
  • RF Antennas Attached: A 915 MHz Sub-GHz blade antenna connected to the LORA connector and a 2.4 GHz PCB antenna connected to the BLE/WIFI connector.
Always Connect Antennas Before Powering

Always attach both antennas before powering the board whenever firmware may initialize or transmit through Wi-Fi, BLE, or LoRa. Never transmit without the correct antenna or suitable RF load, as reflected RF energy back into the power amplifiers (PA) can cause severe overheating and permanent silicon damage to the SX1262 or ESP32-S3.

Software Prerequisites​

  • Visual Studio Code installed as the primary editor and workspace.
  • PlatformIO IDE extension installed and verified.
  • Google Antigravity extension for Visual Studio Code, with workspace access enabled.
  • An existing working Cubicore PlatformIO project (cubicore-diagnostic) created in the previous guide.
  • A successful previous build (pio run).
  • A successful previous firmware upload (pio run --target upload).
  • A working serial monitor (pio device monitor --baud 115200).
Complete the PlatformIO Guide First

Complete the PlatformIO with Visual Studio Code guide first. The AI workflow is much easier to troubleshoot after the normal build, upload, and serial-monitor process is already working. If you are new to the Devboard, review Getting Started and Flashing Firmware (Arduino IDE).

3. What an AI Coding Agent Can Do​

Modern AI coding agents combine large language models with editor and operating-system tool interfaces. Operating as an extension inside Visual Studio Code, the agent can read your local files, suggest implementation plans, edit code across multiple files, and request terminal command execution under your supervision.

When paired with a structured PlatformIO project in VS Code, an AI coding agent can assist with:

  • Project comprehension: Read source files, header declarations, and platformio.ini to explain how an unfamiliar firmware project is structured.
  • Implementation planning: Break a feature request down into logical, incremental steps before writing code.
  • Multi-file editing: Implement complementary changes across headers, source files, and configuration files simultaneously.
  • Dependency management: Identify and propose library dependencies to add to lib_deps inside platformio.ini.
  • Command execution: Request PlatformIO compilation commands (pio run) directly in the integrated VS Code terminal.
  • Compiler error diagnosis: Parse verbose GCC/Clang compiler errors, pinpoint the offending file and line number, and propose minimal corrective diffs.
  • Serial log analysis: Analyze serial output streams to identify bootloader resets, assertion crashes, or unexpected state transitions.
  • Code refactoring: Restructure monolithic main.cpp files into clean, modular classes or state machines.
  • Documentation and test plans: Generate inline Doxygen comments, project READMEs, and structured on-device test protocols.
  • Sketches migration: Translate unstructured Arduino .ino sketches into structured C++ files with explicit function declarations.
Capability Scope

Actual capabilities depend on the specific Antigravity extension version, model tier, workspace permissions, and configuration. Not every feature is available in every environment or plan tier.

4. What an AI Coding Agent Cannot Be Trusted to Know Automatically​

AI coding agents are trained on massive corpuses of public software. While they understand C++, the Arduino framework, and generic ESP32 architecture exceptionally well, they have no physical perception and no innate knowledge of proprietary board layouts.

An agent cannot be trusted to know automatically:

  • Cubicore-specific GPIO assignments: The agent does not inherently know that the onboard status LEDs are on GPIO 45 (Blue) and GPIO 46 (Green), or that primary I²C uses SDA on GPIO 9 and SCL on GPIO 40.
  • Antenna port mapping: The agent cannot see which physical antenna is threaded onto the SMA connector versus snapped onto the U.FL connector.
  • Hardware revision differences: The agent does not know whether your board is Revision V1.3 or an earlier prototype unless explicitly told.
  • PlatformIO compatibility target vs. reality: The project uses board = esp32-s3-devkitc-1 as a PlatformIO base target. An agent might falsely assume standard DevKitC pin headers and default peripheral allocations apply.
  • Internal module wiring: The agent cannot know the internal SPI pinout connecting the ESP32-S3 to the Semtech SX1262 inside the RAK3112 module (NSS 7, SCK 5, MOSI 6, MISO 3, RST 8, DIO1 47, BUSY 48).
  • Regulatory radio limits: The agent does not know your country's legal LoRaWAN frequency band (US915, EU868, AS923) or maximum allowable EIRP power limits.
  • External sensor pinouts: The agent cannot verify how you wired an external sensor to the Grove connector or header breakout.
  • Electrical validity: The agent cannot predict if setting an arbitrary pin as an output driven HIGH will cause a short circuit or damage a sensitive input pin.
  • Root cause of runtime anomalies: If a sensor fails to respond over I²C, the agent cannot determine whether the cause is a missing pull-up resistor, loose wire, bad sensor address, or dead silicon.
The Hardware Hallucination Trap

An AI agent can produce code that compiles successfully with zero warnings while still using the wrong GPIO, wrong peripheral bus, wrong radio configuration, or an unsupported library. Always cross-reference agent assumptions against verified Cubicore documentation.

5. Install the Google Antigravity Extension in VS Code​

Google Antigravity functions as an AI coding agent extension inside your Visual Studio Code environment, allowing you to plan, edit, and diagnose firmware directly alongside your PlatformIO workspace.

Installation Workflow​

  1. Open Visual Studio Code.
  2. Open the Extensions panel by clicking the Extensions icon on the left Activity Bar or pressing Ctrl+Shift+X (Cmd+Shift+X on macOS).
  3. Search for the official Google Antigravity extension.
  4. Click Install to enable the extension.
  5. Restart or reload VS Code if prompted.
  6. Sign in with your authorized Google developer account when prompted.
  7. Confirm that the Antigravity agent panel or sidebar icon is visible and accessible inside VS Code.
  8. Open your existing Cubicore PlatformIO project (cubicore-diagnostic) in the same VS Code workspace.
  9. Configure file edits and terminal commands to require manual approval initially.
PlatformIO Remains the Build Toolchain

Google Antigravity assists with planning, editing, and debugging. PlatformIO remains responsible for project configuration, dependency management, compilation, firmware upload, and serial monitoring. The Antigravity extension does not replace the PlatformIO extension.

VS Code Workflow

This guide uses Google Antigravity as an AI coding agent inside Visual Studio Code. A separate standalone Antigravity environment is not required for this workflow. The Cubicore PlatformIO project, PlatformIO toolbar, build commands, upload process, and serial monitor remain inside VS Code.

Availability and Pricing Notice

Google currently lists an individual free plan for Antigravity. Free-plan availability, model access, usage limits, and rate policies may change, so check Google’s current pricing and product documentation before starting.

6. Open an Existing Cubicore PlatformIO Project​

To provide the agent with a clean baseline, open the cubicore-diagnostic project configured in the PlatformIO with Visual Studio Code guide.

The project structure must contain:

cubicore-diagnostic/
├── include/               <-- Header files
├── lib/                   <-- Local libraries
├── src/
│   └── main.cpp           <-- Diagnostic firmware entry point
├── test/                  <-- Unit test suites
├── .gitignore             <-- Ignores .pio, .vscode, build artifacts
└── platformio.ini         <-- Verified Cubicore hardware build flags

Initial Inspection Workflow​

  1. Open Visual Studio Code.
  2. Open the cubicore-diagnostic project folder (File → Open Folder...).
  3. Confirm that both platformio.ini and src/main.cpp are visible in the Explorer panel.
  4. Confirm that the PlatformIO extension is active (the PlatformIO alien icon and status bar items are visible).
  5. Open the Google Antigravity agent panel inside VS Code.
  6. Ask the agent to inspect the project without changing files.

Issue this initial inspection prompt in the agent panel:

Inspect this PlatformIO project and summarize:

1. The selected board target
2. The framework
3. The flash and PSRAM configuration
4. The USB configuration
5. The current source files
6. The configured serial-monitor speed
7. The current firmware behavior

Do not modify any files yet.
Do not guess missing hardware details.
Identify anything that must be verified from the Cubicore hardware documentation.

Review the agent’s response carefully. The agent should accurately report:

  • Board target: esp32-s3-devkitc-1
  • Framework: arduino
  • Flash: 16 MB QIO (default_16MB.csv)
  • PSRAM: 8 MB OPI (qio_opi, -DBOARD_HAS_PSRAM)
  • USB: Native USB CDC enabled (-DARDUINO_USB_CDC_ON_BOOT=1)
  • Monitor speed: 115200 baud
  • Firmware behavior: Hardware diagnostic output printout followed by alternating LED blinking.

If the agent reports anything contradictory or invents missing hardware attributes, do not allow it to edit files until hardware context is grounded.

7. Add a Cubicore Hardware Context File​

The most reliable way to prevent an AI coding agent from hallucinating GPIOs and peripheral buses is to provide a dedicated hardware context file in the project root.

Hardware Context Scope

CUBICORE_HARDWARE.md is project-local context for the AI agent. It should be generated from and kept consistent with the official Cubicore hardware documentation; it is not a replacement for that documentation.

Create a file named CUBICORE_HARDWARE.md in the root of your project:

# Cubicore Devboard Hardware Context

This project targets the Cubicore Devboard.

## Hardware

- MCU: ESP32-S3 (Xtensa dual-core 32-bit LX7, up to 240 MHz)
- Core module: RAK3112 (combines ESP32-S3 and Semtech SX1262)
- LoRa transceiver: Semtech SX1262 (Sub-GHz LoRa/FSK)
- Board revision: V1.3
- Flash: 16 MB Quad SPI (QIO), 80 MHz
- PSRAM: 8 MB Octal SPI (OPI)
- Framework: Arduino (espressif32 platform)
- PlatformIO board target: esp32-s3-devkitc-1 (with custom board_build parameters)

## Connectivity

- Wi-Fi/BLE antenna: 2.4 GHz PCB antenna connected to the BLE/WIFI connector
- LoRa antenna: Sub-GHz (915 MHz) blade antenna connected to the LORA connector
- USB interface: Native USB-C (ESP32-S3 USB Serial/JTAG, CDC on boot enabled, VID 0x303A, PID 0x1001)
- I2C connector: 4-pin Grove connector J6 (3.3V, GND, SDA, SCL)

## Verified pins

- Status LED: Blue LED = GPIO 45 (Active HIGH), Green LED = GPIO 46 (Active HIGH)
- I2C SDA: GPIO 9
- I2C SCL: GPIO 40
- BOOT: GPIO 0 (Active LOW, mechanical switch 'B' on locker plate)
- RST: CHIP_PU (Active LOW, mechanical switch 'R' on locker plate)
- SX1262 pins: NSS = GPIO 7, SCK = GPIO 5, MOSI = GPIO 6, MISO = GPIO 3, RST = GPIO 8, DIO1 = GPIO 47, BUSY = GPIO 48

## Agent rules

- Do not invent GPIO assignments.
- Use the Cubicore hardware documentation as the source of truth.
- Ask for clarification when a required value is unknown.
- Do not change `platformio.ini` without explaining the reason.
- Make one functional change at a time.
- Do not add libraries without explaining their purpose and compatibility.
- Do not expose or request real credentials.
- Provide build and test steps for every change.
- Do not claim that firmware works until it has been compiled and tested on the physical board.

By keeping this file in your project, the agent can reference verified pin definitions whenever you request new features.

8. Establish Project Rules for the Agent​

Before asking the agent to make code changes, instruct it on the engineering rules of your project. You can paste these instructions into the chat prompt or include them in your workspace agent configuration.

You are assisting with firmware for the Cubicore Devboard.

Before changing code:
1. Inspect the existing PlatformIO project.
2. Read CUBICORE_HARDWARE.md and the relevant Cubicore documentation.
3. Do not invent GPIO assignments or hardware behavior.
4. Do not change platformio.ini unless the change is necessary and explained.
5. Prefer the smallest working change.
6. Do not add libraries without explaining why they are needed.
7. Provide the files changed and the reason for each change.
8. Provide the exact build and upload commands.
9. Include expected serial output.
10. Do not claim success until the project builds and the firmware has been tested on the physical board.

9. First Hands-On AI Task​

To test the workflow, start with a small, verifiable change rather than a complex multi-protocol feature.

We will ask the agent to extend the existing cubicore-diagnostic firmware with:

  1. A firmware version string constant (0.1.0).
  2. Printing the firmware version during startup diagnostics.
  3. Including the elapsed uptime (in seconds) in every serial heartbeat message.

Requesting the Change​

Send the following prompt to the Antigravity extension panel:

Modify the existing Cubicore PlatformIO diagnostic firmware.

Requirements:
- Add a firmware version constant: 0.1.0
- Print the firmware version during startup
- Include the number of seconds since boot in each heartbeat message
- Do not change platformio.ini
- Do not add dependencies
- Do not change GPIO assignments
- Do not initialize Wi-Fi, BLE, or LoRa
- Show me the planned changes before editing files
- After editing, provide the build command and expected serial output

The Expected Engineering Workflow​

1. Open Project ──> 2. Open Panel ──> 3. Plan ──> 4. Review Diff ──> 5. Approve ──> 6. PlatformIO Build ──> 7. Upload & Monitor
  1. Open the project in VS Code.
  2. Open the Antigravity extension panel.
  3. Ask the agent for a plan: The agent describes the exact lines it intends to add to src/main.cpp.
  4. Review proposed changes: Inspect the proposed diff in VS Code. Verify that only src/main.cpp is modified. platformio.ini must remain untouched.
  5. Approve only the intended file edits: Do not approve extraneous modifications.
  6. Use PlatformIO Build in VS Code or run pio run: Verify compilation using the PlatformIO toolchain.
  7. Upload using PlatformIO: Flash the binary to the Devboard via the PlatformIO toolbar or terminal.
  8. Open the PlatformIO serial monitor: Monitor output at 115200 baud.
  9. Verify the physical LEDs and serial output: Confirm on real hardware.

10. Review Generated Changes​

Never accept agent code blindly. Use this review checklist before approving file modifications:

Pre-Commit Code Review Checklist
  • Targeted Files: Does the modification affect only the requested files (src/main.cpp)?
  • Config Integrity: Did platformio.ini remain unchanged?
  • No Unwanted Dependencies: Did the agent avoid adding third-party libraries for basic C++ features?
  • Verified Pins: Are all GPIO numbers identical to the definitions in CUBICORE_HARDWARE.md?
  • Radio Isolation: Did the agent refrain from touching LoRa, Wi-Fi, or BLE registers?
  • Scope Match: Does the code satisfy the request without extraneous "bonus" features?
  • Preservation: Does the existing diagnostic startup banner and LED alternating sequence remain intact?
  • Reversibility: Can this change be cleanly reverted using Git (git restore .) if it fails?

Expected Code Diff in src/main.cpp​

The agent should propose a clean modification similar to the following:

/*
 * Cubicore Devboard - Hardware Diagnostic & LED Blink Test (PlatformIO)
 * Hardware Target: ESP32-S3 (RAK3112 Module)
 * Architecture: 16 MB Flash | 8 MB OPI PSRAM | Native USB CDC Serial
 */

#include <Arduino.h>

// Firmware Version Definition
const char* FIRMWARE_VERSION = "0.1.0";

// Onboard User-Programmable LEDs (Active HIGH)
#define PIN_LED_BLUE   45
#define PIN_LED_GREEN  46

void setup() {
  Serial.begin(115200);

  unsigned long startWait = millis();
  while (!Serial && (millis() - startWait < 3000)) {
    delay(10);
  }

  pinMode(PIN_LED_BLUE, OUTPUT);
  pinMode(PIN_LED_GREEN, OUTPUT);

  Serial.println("\n==========================================");
  Serial.println("   Cubicore Devboard (RAK3112) Online!    ");
  Serial.println("==========================================");
  Serial.printf("Firmware Version: %s\n", FIRMWARE_VERSION);
  Serial.printf("Chip Model:     %s (Rev %d)\n", ESP.getChipModel(), ESP.getChipRevision());
  Serial.printf("CPU Frequency:  %d MHz\n", ESP.getCpuFreqMHz());
  Serial.printf("Flash Size:     %d MB\n", ESP.getFlashChipSize() / (1024 * 1024));
  Serial.printf("Free Heap:      %d Bytes\n", ESP.getFreeHeap());
  Serial.printf("Total PSRAM:    %d Bytes\n", ESP.getPsramSize());
  Serial.printf("Free PSRAM:     %d Bytes\n", ESP.getFreePsram());
  Serial.println("==========================================\n");
}

void loop() {
  unsigned long uptimeSeconds = millis() / 1000;

  // State 1: Blue LED ON, Green LED OFF
  digitalWrite(PIN_LED_BLUE, HIGH);
  digitalWrite(PIN_LED_GREEN, LOW);
  Serial.printf("[Status] [%lu s] Blue LED ON  | Green LED OFF\n", uptimeSeconds);
  delay(1000);

  uptimeSeconds = millis() / 1000;

  // State 2: Blue LED OFF, Green LED ON
  digitalWrite(PIN_LED_BLUE, LOW);
  digitalWrite(PIN_LED_GREEN, HIGH);
  Serial.printf("[Status] [%lu s] Blue LED OFF | Green LED ON\n", uptimeSeconds);
  delay(1000);
}

11. Build, Upload, and Test the Agent-Generated Change​

Once you have approved the file changes, validate them through the standard PlatformIO build and test workflow inside VS Code.

1. Build the Firmware​

Compile the project to confirm that the agent's code introduces no syntax or linker errors:

pio run

You can also click the PlatformIO Build checkmark (✓) in the VS Code bottom status bar. If the agent offers to run this command automatically, inspect the exact shell invocation before clicking Approve.

2. Upload to the Cubicore Devboard​

Connect the Devboard via USB-C and flash the compiled binary using PlatformIO:

pio run --target upload

Or click the PlatformIO Upload arrow (→) on the VS Code bottom status bar.

3. Open the Serial Monitor​

Launch the PlatformIO serial monitor at 115200 baud to observe runtime output:

pio device monitor --baud 115200

Or click the PlatformIO Serial Monitor plug icon in the status bar.

Expected Serial Output​

==========================================
   Cubicore Devboard (RAK3112) Online!    
==========================================
Firmware Version: 0.1.0
Chip Model:     ESP32-S3 (Rev 2)
CPU Frequency:  240 MHz
Flash Size:     16 MB
Free Heap:      391824 Bytes
Total PSRAM:    8388608 Bytes
Free PSRAM:     8388608 Bytes
==========================================

[Status] [3 s] Blue LED ON  | Green LED OFF
[Status] [4 s] Blue LED OFF | Green LED ON
[Status] [5 s] Blue LED ON  | Green LED OFF
[Status] [6 s] Blue LED OFF | Green LED ON
Physical Verification Rule

A successful compilation (SUCCESS [env:cubicore]) only proves that the code is syntactically valid C++. It does not prove that the firmware behaves correctly. The task is only complete once you observe the actual LED toggling on the hardware and verify the uptime string in the serial monitor.

12. Debugging with Compiler Errors​

When a build fails, do not attempt to paraphrase the error to the agent. Paraphrased descriptions often omit crucial header paths, template instantiations, and linker symbols.

Providing Complete Terminal Output​

Copy the entire terminal output from pio run and paste it into the Antigravity panel:

The PlatformIO build failed.

Here is the complete terminal output:
[paste the complete error here]

Please:
1. Explain the root cause.
2. Identify the file and line involved.
3. Propose the smallest fix.
4. Do not change unrelated files.
5. Do not add a dependency unless necessary.
6. Show the proposed diff before applying it.
7. Tell me how to verify the fix.

Reviewing the Agent’s Fix​

Ensure that the agent’s proposed fix addresses the actual syntax or type mismatch rather than arbitrarily commenting out code, disabling compiler flags, or adding unrelated third-party libraries.

13. Debugging with Serial Output​

If firmware compiles and uploads successfully but behaves unexpectedly (e.g., an LED fails to turn on, or the board enters a boot loop), report both the expected and actual behaviors to the agent.

Serial Diagnostics Prompt​

The firmware builds and uploads, but the runtime behavior is incorrect.

Expected behavior:
[paste expected behavior]

Observed serial output:
[paste complete serial output]

Hardware setup:
[describe the connected sensor, antenna, or peripheral]

Recent code change:
[describe the change]

Analyze the likely causes. Do not assume GPIO assignments. Refer to the verified Cubicore hardware context and propose the smallest diagnostic step first.

When diagnosing ESP32-S3 Guru Meditation Errors or Watchdog resets, provide the full register dump and stack trace. Modern AI agents can decode stack traces to identify NULL pointer dereferences or uninitialized variables.

14. Working with Peripherals and Radios​

Once the basic diagnostic workflow is reliable, you can use the AI coding agent to assist with more advanced hardware features:

  • I²C bus scanners: Detecting connected sensors on Grove connector J6 (SDA = GPIO 9, SCL = GPIO 40).
  • Environmental sensors: Integrating SHT30, DHT11, or MQ-2 sensors.
  • Wireless connectivity: Setting up Wi-Fi station mode or Bluetooth Low Energy UART services.
  • LoRa Point-to-Point: Transmitting raw RF packets using RadioLib on the SX1262.
  • LoRaWAN telemetry: Joining The Things Network (TTN) or ChirpStack via OTAA.
  • Low-power optimization: Configuring ESP32-S3 deep sleep and SX1262 radio sleep states.
The "One Application" Fallacy

Do not ask the agent to build a complete sensor, Wi-Fi, BLE, LoRaWAN, cloud, and battery-management application in one request. Massive prompts generate unmaintainable code, hallucinated pins, and difficult-to-debug crashes.

Follow this disciplined progression whenever adding new hardware capabilities:

1. Base Build ──> 2. Wiring Check ──> 3. Add Peripheral ──> 4. Diagnostics ──> 5. Connectivity ──> 6. Power ──> 7. Recovery
  1. Verify the base build: Ensure the project compiles cleanly before adding code.
  2. Verify physical wiring: Confirm Grove cables, pull-up resistors, and antenna connections.
  3. Add one peripheral: Initialize a single sensor or module using verified pin definitions.
  4. Print raw diagnostic values: Read and log raw sensor values to serial before writing conversion logic.
  5. Add communication: Layer on Wi-Fi, BLE, or LoRa transmission after sensor data is proven valid.
  6. Integrate power management: Add deep sleep, timer wakeups, and radio shutdown routines.
  7. Test failure and recovery: Verify how firmware handles a disconnected sensor or failed radio packet.

Cross-reference each step against the authoritative Cubicore guides:

15. Secrets and Credentials Security​

Firmware projects frequently require sensitive authentication credentials to connect to local networks and cloud servers.

Never Expose Real Credentials in AI Prompts

Never paste real credentials, private keys, or proprietary network secrets into an AI coding agent or cloud prompt. Prompts may be logged, stored, or processed on remote servers.

Sensitive Data to Protect​

  • Wi-Fi Pre-Shared Keys (WPA2/WPA3 Passwords)
  • LoRaWAN Application Keys (AppKey)
  • LoRaWAN Device EUI (DevEUI) and Join EUI (AppEUI)
  • Cloud API Keys & MQTT Broker Passwords
  • TLS Client Certificates & Private Keys
  • Internal Production Server IP Addresses or Domains

Secure Credential Workflow​

  1. Use Placeholder Constants: When asking an agent to generate networking code, instruct it to use placeholder constants: 
    // Prompt rule: Use placeholder strings for credentials
    const char* WIFI_SSID = "YOUR_WIFI_SSID";
    const char* WIFI_PASS = "YOUR_WIFI_PASSWORD";
  2. Use Git-Ignored Config Files: Store real production keys in a private header (e.g., include/secrets.h) or environment variables, and ensure that file is listed in .gitignore.
  3. Review Context Files: Verify that your .gitignore excludes build directories (.pio/) and sensitive files before granting the agent workspace-wide indexing access.

16. Safe Agent Permissions in VS Code​

AI extensions in Visual Studio Code can request permission to execute shell commands and modify local files. Configure agent permissions intentionally to protect your project and operating system:

  • Require Approval for File Edits: Ensure the extension prompts you to inspect and approve file changes before they are written to disk. Reject any diff that alters files outside the requested scope.
  • Require Approval for Terminal Commands: Never grant an agent permission to run arbitrary, unreviewed shell commands. Always inspect build and upload commands before allowing execution.
  • Require Approval for Dependency Installation: Review any library additions proposed for platformio.ini to avoid installing outdated or incompatible dependencies.
  • Require Approval for External Access: Restrict arbitrary web browsing or external API access where configurable.
  • Work in Small Atomic Steps: Make one functional change at a time so issues can be isolated quickly.
  • Commit a Known-Good Baseline: Commit a verified working state before asking the agent to perform substantial edits: 
    git add .
    git commit -m "Known-good Cubicore PlatformIO baseline"
    If the agent makes an unwanted modification, cleanly discard uncommitted changes with: 
    git restore .
    (Warning: git restore . permanently discards all uncommitted working directory modifications.)
  • Maintain Physical Control: Always retain manual control over board flashing, power cycling, and hardware resets.
Principle of Least Privilege

The exact permission controls depend on the current Antigravity extension and account configuration. Use the most restrictive practical settings while learning the workflow. Give the agent enough access to be useful, but do not give it blind authority over files, credentials, or system commands.

17. Other AI Coding Agents in VS Code​

While this guide focuses on the Google Antigravity extension, the same structured workflow applies to other VS Code-compatible AI coding assistants (such as GitHub Copilot Workspace, Cursor, Claude Code, or Roo Code).

When using alternative AI tools inside VS Code, keep these differences in mind:

  • Interface & Tooling: Some tools operate as sidebar chat extensions, while others integrate through editor inline prompts or terminal bridges.
  • Model Reasoning: Different underlying LLMs have varying levels of familiarity with modern C++ standards, PlatformIO semantics, and ESP32-S3 hardware errata.
  • Terminal Integration: Certain agents can execute terminal commands autonomously, while others require you to copy and run commands manually.
  • Diff Presentation: Side-by-side git-style diff review is essential for embedded development; verify your chosen tool supports manual diff approval before saving.
  • Context Windows: Smaller context models may lose track of hardware definitions across long conversations. Re-ground the agent by re-referencing CUBICORE_HARDWARE.md when starting a new task.

The core discipline remains universal: ground the agent in verified hardware documentation, make small incremental changes, and verify every change on physical hardware.

18. Completion Checklist​

Verify that your AI-assisted embedded development environment is correctly established:

  • Visual Studio Code has both PlatformIO and the Google Antigravity extension active.
  • The agent has access to the verified Cubicore hardware context (CUBICORE_HARDWARE.md).
  • The project builds successfully using PlatformIO before agent modifications.
  • You can review proposed file changes in VS Code before accepting them.
  • The agent can help make a small source-code change.
  • The modified project builds successfully (pio run).
  • The firmware uploads successfully via PlatformIO (pio run --target upload).
  • The expected serial output appears in the PlatformIO monitor (pio device monitor --baud 115200).
  • You understand how to provide compiler errors and serial logs to the agent.
  • No real credentials were included in prompts or source files.

19. Next Steps​

Now that you have established a safe, repeatable AI-assisted workflow inside Visual Studio Code, you can begin implementing real-world sensor monitoring and communication routines:

Closing Recommendation

You now have a repeatable workflow for using the Google Antigravity extension inside Visual Studio Code with a Cubicore PlatformIO project.

Visual Studio Code remains your development environment, PlatformIO remains your firmware toolchain, and the Cubicore Devboard remains the final authority for hardware behavior.

Start with small, testable changes and use the Cubicore hardware guides as the source of truth whenever the AI agent needs hardware information.