Last week on my Deep Dive I went over the #CircuitPython2025 posts from last year including my own. And, frankly, my goal is still pretty much the same: continue moving to Zephyr. However, *how* I code is changing and also how we write CircuitPython will likely change too.
Changing how I code
Large language models (LLMs) when used by a client side “agent” that can run commands and relay back the result in a loop is game changing. The original example of this is Claude Code and all of the other LLM players have introduced something similar. With Claude Code, I type even fewer characters of code than I did before. I’m not creating new blank files and then copying in the license header. I’m not duplicating one common-hal implementation and then removing the implementation guts. Claude can do these tedious things for me and with some context and examples, even take a stab at a first implementation. I’m still coding. But, I’m typing less. I’m still reading code, testing and debugging.
For years, when talking to folks about Python vs C, I’ve encouraged them to try with Python first because it is much faster to iterate. The cost of trying Python is low and the potential is great. If Python ended up being too slow, then they could switch the slow bits to C or throw all of the Python away. “Just try Python. It won’t take long.”, I said. Now with LLMs, I’m telling myself to “Just try it” to see how good the first pass of some large, and probably tedious, task is. For example, I’ve wanted to restructure how resetting the hardware happens after the VM finishes to reduce complexity. But, it is a task that touches most common-hal files in each port. That would take me a ton of time. This year, with LLM assistance. I need to try things like this more often. If the LLM gets it wrong, then I can try again or just leave it be. If it gets it right, then I’ve done something I didn’t think I’d have time to do.
So, to those LLM skeptics, “Just try it” for a variety of tasks, especially the tedious ones. You might be pleasantly surprised. I expect I’ll do things this year that I didn’t think I’d have time to because of LLM first drafts that worked out. It is worth trying.
Changing what I code
Writing tests is tedious. Maintaining hardware-in-the-loop tests is difficult. However, with LLM assisted coding, tests are more important than ever. I learned this the hard way when I made a pull request to add pathlib support and it didn’t actually work. (Thanks again RetiredWizard for testing it.) This year, I need to be better about testing changes I make. LLM generated code often looks plausible, which can be deceiving. Including generated tests can help me spot discrepancies about how the code actually works because tests read differently than the implementation does.
Furthermore, tests guard against regressions when other things change and makes explicit design choices more obvious. Tests are an important way to ensure things keep working. When they are portable, they can be used to test new implementations too. So, now that generating code is fast, I need to focus more on testing, especially automated testing.
Changing how we code CircuitPython
For many CircuitPythonYears I’ve focused on what I call workflow: How do you load CircuitPython code and see its output? CircuitPython started with the CIRCUITPY drive over USB and autoreload on write. We’ve expanded to include BLE and Web workflows. We’ve even embraced the serial-only workflow for boards that don’t have USB. Last year, I didn’t talk about workflows at all. This year, I think LLMs will start to play a role in workflow.
The BLE workflow in CircuitPython hasn’t really found its audience. My belief is that coding from mobile devices like a phone is critical bringing more folks to coding. However, typing on a phone sucks. If only we had something good at typing for us…
It turns out LLMs are excellent at taking human language as input and generating code, including Python code. It removes the need for much of the typing involved in coding. We should explore writing CircuitPython on a mobile device using an LLM. We don’t need to add a new workflow to the CircuitPython core. But, we need to create the “agentic” feedback loop for best results. We let the LLM auto-load code and give it the serial output back. We should also give it context about recent CircuitPython changes and API references so it can correct its knowledge. Both the code written and output should be made apparent to us as well so that we can refine our own goals and learn from reading the code.
Conclusion
LLMs are a new useful tool that I expect will shape the way we all write code for years to come. CircuitPython isn’t exempt from this. In fact, it will benefit from it. We’ll “Just try” to fix issues and implement enhancements just to see how close to done we get and we’ll be pleasantly surprised. So, I’m excited for a year of Zephyr and everything else we can squeeze in.
Folks to follow
If you want to see more about coding with LLMs, then I recommend checking out these blogs and podcasts:
- Simon Willison’s Weblog – Frequent short posts about coding and LLMs. Links to lots of other great stuff. Originator of the “pelican riding a bicycle” test.
- Oxide and Friends Podcast – Especially the first two episodes of Season 6, which just came out.
- Drew Breunig – Especially “A Software Library with No Code” where the code is generated by an LLM in the language of the user’s choice and validated against language agnostic tests.
- The Changelog – Topics vary but the LLM ones are interesting.
#CircuitPython2026 is our annual reflection on the state of CircuitPython. We’d love to hear from you too! See the kick-off post for all of the details. Please post by January 21st and email circuitpython2026@adafruit.com to let us know so we can link to it.
Past posts:
- Dan Cogliano posted to BlueSky suggesting we add QSPI display support.
- Anne Barela posted on GitHub suggesting a few things including thorough support for the ESP32-P4 and finishing CircuitMatter.
- danak posted on the forum that they’d like to see true multiple display support.
- Sam Blenny wrote a Gist about continuing progress on making CircuitPython a platform of interactive uses like gaming and audio synthesis.
- deshipu posted to their blog about bugs hit with their gaming focused boards and the challenges of digging into the core code to fix them.
- retiredwizard posted to the CircuitPython Forum about more home automation features, newer boards and experimenting with edge AI.
- Liz sent in a GitHub Gist for #CircuitPython2026 with a vote for getting CircuitMatter going.
- Anecdata kept it short and sweet on Mastodon and provided test code. Posting, “asyncio support for sockets.”
- Rybec posted on their substack about expanding CircuitPython use with an OS.
- Kick off blog post.
from Adafruit Industries – Makers, hackers, artists, designers and engineers! https://ift.tt/Cp1wP4u
via IFTTT
Комментариев нет:
Отправить комментарий