Tutorial 06 — Putting It All Together

Tutorial 06 — Putting It All Together
AI and PicBasic Pro Tutorial Series — Post 6 of 6
Content produced with AI assistance and reviewed by the forum administrator.

What You Have Built

If you have followed the series from Tutorial 01, you now have three layers working together to make AI assistance with PBP3 reliable and repeatable.

Layer 1 — Profile Instruction
Set once in your AI account settings. Applies to every conversation. Establishes baseline behaviour: complete code, explicit calculations, annotated changes, backup before modification, audit before fix.

Layer 2 — Workspace
A named workspace for PBP3 development. Contains the compiler manual, your device datasheet, a targeted register reference, and working code samples. The workspace instruction tells the AI to use these documents as authority rather than relying on memory.

Layer 3 — Structured Workflow
The three-prompt sequence that forces the AI to understand before it audits, and audit before it fixes. Used when debugging or reviewing code.

Each layer adds precision. The profile sets general behaviour. The workspace adds device and compiler context. The workflow structures the reasoning process for any given task.

A Typical Session — What It Looks Like in Practice

You have a PBP3 source file that compiles with errors or behaves unexpectedly on hardware. Here is the sequence:

Open a new conversation in your PBP3 workspace

Send Prompt 1 with your code — the AI explains what the code does

Send Prompt 2 with the code block from step 2 — the AI produces a numbered fault list

Review the fault list — you can correct it if anything is wrong before proceeding

Send Prompt 3 with the fault list and code — the AI produces annotated corrected code

Review the corrected code — compare changes against the fault list

Compile and test — if errors remain, paste compiler output into a follow-up

Test on hardware — compile-clean is not the same as hardware-correct

The key discipline throughout is that you stay in the loop. You review the fault list before fixes are applied. You review the corrected code before compiling. You test on hardware before trusting the output.

What This Approach Does and Does Not Do

What it does:

Reduces the class of errors caused by the AI not having the right reference material

Structures the AI's reasoning so it cannot skip from "code exists" to "fixed code" without an intermediate audit

Ensures every change is annotated so you can understand what moved and why

Preserves your original code in every response so you never lose a working version

Produces compile-clean code more consistently than an unstructured single-prompt approach

What it does not do:

Guarantee correct hardware behaviour — a clean compile is not a working device

Replace your knowledge of the device — the AI can still make logical errors

Remove the need for hardware testing — that step is irreplaceable

Work perfectly first time on every project — it improves output quality, it does not make AI infallible

Building on the Foundation

The workspace and workflow described in this series are a starting point. Over time you will find things that work better for your specific devices, projects, and coding style. Some suggestions for expanding the approach:

Add more working examples to your workspace
Every hardware-verified example you add gives the AI a better calibration baseline. Over time the workspace accumulates a body of known-good code that the AI can reference when generating new examples.

Expand your device reference document
As you work with a device and discover its quirks, add them to your reference document. Notes on peripheral interactions, common configuration patterns, known pitfalls — these improve every future conversation.

Create separate workspaces for different device families
A workspace optimised for mid-range 16F devices should not be mixed with 18F work. The CONFIG syntax, memory banking model, and peripheral architecture are different enough that keeping them separate prevents cross-contamination errors.

Refine your profile instruction
When the AI does something that surprises you or produces output in a format you did not want, add a line to the profile instruction that covers it. The instruction improves with use.

Contributing to This Forum

This tutorial series covers general principles. The community's collective experience — specific devices, specific peripherals, specific failure modes and how to prompt around them — is more valuable than any generic guide.

If you develop a prompt template that works reliably for a specific device or peripheral, post it in the AI Prompts and Code Examples forum. If you find something in this tutorial series that is wrong, incomplete, or could be explained better, post a reply. This forum improves with contributions.

When posting code examples, please follow the guidelines in the forum welcome post:

Include the prompt that generated the code

State the target device and compiler version

State whether the code compiles

State whether it has been tested on hardware

The distinction between compile-tested and hardware-verified matters. Readers need to know which they are looking at.

Series Summary

Tutorial 01 — Why AI gets PBP3 wrong and what causes it

Tutorial 02 — Setting up a workspace with the right reference documents

Tutorial 03 — Writing a profile instruction for consistent behaviour

Tutorial 04 — A structured three-prompt debugging workflow

Tutorial 05 — Working efficiently with complex documents

Tutorial 06 — Putting it all together (this post)

Previous: Tutorial 05 — Working With Complex Documents
This tutorial series was produced with AI
The prompts and instructions in this series are starting points. Adapt them to your device and workflow before use. Hardware test all AI-generated code.