What if the most repetitive part of development just ran itself?
A discussion — not a proposal. No decision required. Just something worth thinking about.
A familiar problem
Every project starts the same way. Device configuration. Initialisation routines. First compile. Errors. Fix. Compile again. More errors. Fix again. This loop is not engineering — it is administration. It is necessary, time-consuming, and largely identical from one project to the next.
For PicBasic Pro specifically, a significant portion of every project's early hours goes here. Getting the CONFIG block right for the target device. Verifying DEFINE OSC against the actual hardware clock. Working through the compiler's complaints before any real problem-solving begins.
The question worth asking is how much of an engineer's time goes to solving the actual problem — and how much goes to everything that surrounds it.
What already exists
This is not a discussion about research or future technology. Everything needed to change that workflow exists today.
- AI code generation — already used in software development worldwide. Capable of generating syntactically correct code when given the right reference material to work from.
- Knowledge retrieval — technology that stores verified examples and retrieves the most relevant one for a given query. Proven, available, and straightforward to configure.
- Compiler integration — the PBP3 compiler produces structured output. Reading that output and acting on it is a solved problem. Automated build pipelines have done this for decades in other environments.
- Workflow orchestration — connecting these components together requires configuration, not invention. The plumbing is standard.
Systems like this have been built for mainstream languages. Python, JavaScript, C — all have AI-assisted development workflows that draw on large bodies of verified code. PicBasic Pro has not had one built for it. That is a gap. It is not a technical barrier.
How it would work
The engineer's role does not change. They direct the work, review the output, and make the decisions. What changes is what happens between those moments.
Step 1 — Engineer describes the requirement
Plain language. Target device, what the code needs to do, any constraints. The engineer sets the direction.
Step 2 — System retrieves verified examples (automated)
A library of hardware-verified code examples is searched for the target device and requirement. Code generation is grounded in what is known to work — not in general AI knowledge, not in memory.
Step 3 — Code is generated and compiled (automated)
Code is generated and passed to the compiler. If errors are returned the system reads the output, identifies the cause, and corrects it. This loop runs until the code compiles cleanly. The engineer does not watch it.
Step 4 — Engineer reviews compile-clean code
The engineer receives code that has already passed the compiler. They read it, adjust if needed, and decide whether to proceed. Nothing goes to hardware without their approval.
Step 5 — Engineer tests on hardware
Hardware testing is always with the engineer. A compiler passing code is not the same as correct behaviour on a device. This step is not automated and never would be. The engineer's hardware knowledge is irreplaceable here.
Step 6 — Engineer approves and commits
Hardware-verified code is approved and added to the example library. The next project starts from a richer foundation. The system improves with every project that runs through it.
What actually changes
- The compile loop runs unattended. The engineer does not watch compiler output and manually correct errors. That loop runs while they do something more useful. They receive the result.
- Output is consistent. Code is generated from the same verified library regardless of who made the request. Configuration patterns do not vary by individual habit or by how recently someone last worked with a particular device.
- Knowledge is retained. Solutions that currently live in individual engineers' experience are captured in the library. That knowledge does not walk out the door when someone moves on.
- The system compounds. Every approved example makes future generation more accurate. Unlike a tool that performs the same regardless of use, this one gets better. After a dozen projects the library reflects accumulated hardware-verified experience.
- Errors surface earlier. Configuration errors and register conflicts are identified before the engineer sees the code — not during hardware testing when they are more expensive to find.
The honest questions
Does a clean compile mean correct code?
No. The compiler accepts code that is syntactically valid. Whether it does the right thing on hardware is a separate question that only testing answers. Hardware verification stays with the engineer. That does not change.
What if the library contains an error?
Only hardware-verified code approved by an engineer enters the library. The quality of what comes out is determined by the quality of what goes in. The human gate before commitment is the control mechanism. This is why the engineer's hardware knowledge matters more in this system, not less — they are the quality filter.
Does this reduce the need for engineers?
It reduces the time engineers spend on mechanical work. The hardware knowledge, the judgement, the ability to recognise when something is wrong on a device — that is unchanged. The system handles the repetition. The engineer handles everything that requires actually knowing what they are doing.
How long to get started?
A working system covering two devices can be operational in weeks. It runs alongside existing workflow, not instead of it. If it underperforms, nothing has changed. There is no dependency on it.
A point for the sceptics
The concern raised in this thread — that you cannot trust AI-generated code unless you know the hardware well enough to catch what it gets wrong — is correct. That concern does not go away with this approach. It becomes the foundation of it.
The engineer's hardware knowledge is not bypassed. It is the gate. Hardware-unverified code does not enter the library. The system is only as good as what the engineers who use it have verified on real devices. An engineer who does not know the hardware cannot operate this system effectively. One who does gets their time back from the mechanical loop and spends it on the work that actually requires them.
The broader picture
The PBP3 community is small. The amount of publicly available verified PBP3 code for modern PIC devices is limited. AI tools that work well for mainstream languages perform inconsistently for PBP3 because the training data simply is not there.
A shared library of hardware-verified examples, built by the community and continuously improved through use, would be a different kind of resource. Not documentation. Not forum posts that may or may not be tested. Verified working code, retrievable by device and function, that feeds directly into generation rather than sitting on a wiki somewhere.
That library does not exist for PBP3. It could.
This is not a proposal. No decision is being asked for. It is a description of what is possible today with existing technology, put here for consideration and discussion. Whether it is worth doing is a question for the people who do this work.
