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:

  1. Open a new conversation in your PBP3 workspace
  2. Send Prompt 1 with your code — the AI explains what the code does
  3. Send Prompt 2 with the code block from step 2 — the AI produces a numbered fault list
  4. Review the fault list — you can correct it if anything is wrong before proceeding
  5. Send Prompt 3 with the fault list and code — the AI produces annotated corrected code
  6. Review the corrected code — compare changes against the fault list
  7. Compile and test — if errors remain, paste compiler output into a follow-up
  8. 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

  1. Tutorial 01 — Why AI gets PBP3 wrong and what causes it
  2. Tutorial 02 — Setting up a workspace with the right reference documents
  3. Tutorial 03 — Writing a profile instruction for consistent behaviour
  4. Tutorial 04 — A structured three-prompt debugging workflow
  5. Tutorial 05 — Working efficiently with complex documents
  6. 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.