[sdiy] AI code generation

Mon Jul 27 09:41:18 CEST 2026

The Claude Code app is super interesting. I had been using the website to do some glue code for a project I'm working on but the app is something else.

Apon installation it went about setting up a new build environment as my previous one was a bit jank. It dugg through my previous code on multiple projects and summarized, then it went to work on the kicad files. Was able to get netlists and part names, build the framework code and set up a hardware function test.

It then built that framework and gave me a command line to flash it to the device. I wasn't ready for that level of automation TBH, quite scary how knowledge is pretty useless now as long as you have access to LLMs.

________________________________
From: Synth-diy <synth-diy-bounces at synth-diy.org> on behalf of Eric Frampton <eric at ericframpton.com>
Sent: Monday, 27 July 2026 1:23 AM
To: cheater cheater <cheater00social at gmail.com>
Cc: SDIY <synth-diy at synth-diy.org>
Subject: Re: [sdiy] AI code generation

TL;DR I read the schematics, it writes the code. I’m working in chat sessions, not Code or Cowork or anything. We create a FINDINGS thread for each feature/system, then hand that off to a fresh thread to do the actual Z80 coding. We created ongoing build_ledger and build_order docs that are the sources of truth and references to dead-ends, etc.

--

The project itself is a large add-on to the Memorymoog firmware. I’ve been making it up on the fly and learning as I go - and learning a tiny bit about project management and my own problem-solving style in the process. Claude can be quite a mirror to the soul in that way.

Goals are to optimize key-on latency, minimize MIDI key-on latency and tighten up the timing, and add as many of the features from the dBm and LAMM feature lists as I (we) can squeeze into the existing hardware.

I’m working entirely in chat/session mode, no co-work or Claude Code or anything. I came at it with binaries, schematics, the service manual and addenda, PDFs of the dBm and LAMM manuals, various datasheets, and a wish-list, and asked it "what can you do with this?” Turns out, lots.

The general process is, I read the schematics and pinouts, tell Claude what’s going on and what needs to happen, and it does the coding. It answers questions I can’t, and vice-versa. We were able to break my wish list down into sections, and Claude was able to prioritize how the build needed to go, and what was needed to build on what. We ended up working in separate threads for each feature/section: one thread would start with me typing something like, “OK, we need to figure out the cassette dump so we can see how patch memory is handled so we can figure out how to build a sysex routine”, and that might break down into a series of other threads. Claude would create handoff documents so each new thread knew what the last one was doing (memory isn’t moved between threads except what you put into Project Knowledge files).

At that point, if there’s any new code to be built, we’d produce a “FINDINGS” document with what we’d learned and what we’d expect the code to look like, then start a new BUILD thread to do the actual coding. Context space in Claude is very important, and I learned to keep an eye on how long threads were running so Claude didn’t start either forgetting things from compaction, or logic-ing itself in circles. Eventually it learned to keep an eye on context and natural project breakpoints for itself, and would nudge me toward taking a break when it felt like it was getting stuffed.

We figured out a 4-layer protocol for us to check its work as we finished each new build. We also built an emulator in Swift for MacOS to run the firmware enough to test it, and even reproduce bugs in the original (patch chain crash, MIDI out errors). It would do the three tests it could run on its end, and then it would build a Swift test or two (or ten) for me to run in our emulator, since it can’t run Swift. I would cut and paste Terminal output, and Claude would figure out what was happening from that. I could also do simulated real-world testing through a GUI front-end it built in the emulator to see if things like pot moves/SAR updates were fast enough, or the display characters looked weird, or to check out how a new UX/UI decision tree felt in actual use, or whatever.

The emulator never actually made noise, but it didn’t need to - it just needed to show a working GUI, the SAR reading the pots and updating the “DAC”, and voices firing with something resembling correct envelope times. We started trying to bolt a little synth engine on the back of it, but that wasn’t going well so I abandoned it. Maybe when the firmware finally gets done and tested I’ll come back to that.

Errors still slip through, but it’s rare, and it is as much my fault for not being able to keep everything in my head as it is Claude’s for not being able to keep everything in its head, either. In fact, we’re having to go back and re-write a chunk of the MIDI receive routine for that very reason - just too many open threads and one too many hardware revisions (plain vs. Plus) to keep it all straight, and we made a big architectural mistake that came back to bite us.

I’m writing in past and present tense, as this has been ongoing since mid-May, and I’m still slowly working on it while out here on tour with LR. I haven’t had access to my own Memorymoog since January (it’s in storage), and I won’t see it again for a while, so I’m sending fresh .bin files out to a couple of trusted technician friends with a Plus, who then burn EPROMs, run it and bounce back results.

I’m happy to answer anything but I don’t want to waste y’all's time, so feel free to ask me specific questions.

e

> On Jul 26, 2026, at 5:29 PM, cheater cheater <cheater00social at gmail.com> wrote:
>
> On Sun, Jul 26, 2026 at 9:53 PM Eric Frampton <eric at ericframpton.com> wrote:
>>
>> Yes, working on that now. In fact, I wrote a post about it here a few days ago. Guess it got lost in the shuffle.
>> I’m working with Claude on some Z80 code for a beloved old poly.
>>
>> e
>
> Yeah, I saw that. What's your workflow here?
>
>>> On Jul 26, 2026, at 12:17 PM, cheater cheater via Synth-diy <synth-diy at synth-diy.org> wrote:
>>>
>>> regarding AI programming for microcontrollers, I wonder if anyone has
>>> tried using AIs for decompiling embedded code in synths, either old
>>> ones using 8 bit micros or the stuff running on newer DSPs, and then
>>> compiling it again with new features / bug fixes
>>

________________________________________________________
This is the Synth-diy mailing list
Submit email to: Synth-diy at synth-diy.org
View archive at: https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsynth-diy.org%2Fpipermail%2Fsynth-diy%2F&data=05%7C02%7C%7C6ed12d4e54b14d6cc74708deeb6dd8f9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639207054210933895%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kElfQSJ3EO3nRMQm3VVoBysLWNKEjGDsjNGYlzSQyuE%3D&reserved=0<https://synth-diy.org/pipermail/synth-diy/>
Check your settings at: https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsynth-diy.org%2Fmailman%2Flistinfo%2Fsynth-diy&data=05%7C02%7C%7C6ed12d4e54b14d6cc74708deeb6dd8f9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639207054210959710%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1rK1Xi%2BYTgAo3lGmIJFjcHc%2BhvNm7eApA227XVh%2BUvE%3D&reserved=0<https://synth-diy.org/mailman/listinfo/synth-diy>
Selling or trading? Use marketplace at synth-diy.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20260727/284e0ac8/attachment.htm>