TinyGo
TinyGo Programming – Using Artificial Intelligence for Code Generation #5535
Replies: 2 comments 5 replies
|
I think AI is a great tool, but should not be indispensable. I've made heavy use of AI these past few weeks to develop libraries I've always wanted to have but were so far off in the distance due to the speed I could write code at. Thanks to AI I've developed:
So these are fruitful endeavours of developing with heavy dependence on agentic nature of AI. Worth mentioning some of these hit the mark on the first try. Such is the case for ports like the littlefs port which more or less was up to my quality standards out of the first iteration (with some AI introduced bugs). I then put FATFS and littlefs ports through the ringer in the filesystem tests which ironed out bugs present in the original FATFS implementation(!!). Which leads me to the next point: Knowing how to drive LLM tests is Key. Write Red Tests before the implementation and have them fail, then write the actual implementation. After the implementation is done it may have failed due to a bug in the implementation or an incorrect suposition in the test. This is a very productive way to get things done and has let me develop above libraries very effectively. There are other places where I'd never merge a AI driven commit without checking every single line it writes. The abstraction and style of my networking library is something the AI still does not catch on to. This is likely due to there not being high quality, well abstracted networking libraries out there- most of what one finds is just what people could churn out and work and a product of multiple decades of bugfixes upon bugfixes leading to a melding of layers of abstraction when bugfixes cross the layer they correspond to. Similarly LLMs absolutely cannot do 3D design as I've observed in https://github.com/soypat/gsdf, and worse, it's like a black-hole for your tokens. They consume thousands upon thousands of tokens and take many minutes to arrive at a lackluster solution you could have done better in less time. Maybe a more 3D oriented AI model could improve this fact, but LLMs are terrible at this (Claude, ChatGPT, Grok, etc.). Most importantly, write libraries, not applicationsAI is a resource and may not be here forever in the availability and quality we have it today. Leverage it to write libraries that you reuse in the future. Avoid just writing applications and programs that do not allow reusing of the new functionality of value you add to the world. I can't stress this enough, we have the power to basically create an operating system if we so wanted to- but what use is it if we just put all the code in a single repo making it highly unshareable. Build your code library infrastructure and improve the Go ecosystem by adding libraries that were not there for you before. Modularize everything. |
Your post demonstrates one of the biggest problems with LLMs -- no one with an LLM wants your libraries -- someone with an LLM will just do what you did and create one for themselves without asking what exists in the ecosystem or how they can improve what exists in the ecosystem. There's probably some in-between layer where someone without an LLM will maybe trust your library, population of users, you, and give it a shot. Then there are developers who will take one look and refuse to use it seeing it is entirely LLM generated. They will look for other metrics and try and find the libraries crafted not vomited onto the page by agentic AI. If you have access to an LLM then, my 2 cents is that what you generate is a YOU thing. Communities will need to reject wholesale "efforts" like yours just to survive, let alone maintain code quality and assurances. Anyway... not sure what the question is for TinyGo @Gustavomurta are you just asking TinyGo for an AI policy? |
I am by no means suggesting an AI usage policy. I think the licensing regulators will do this soon. For example (my assumption): MIT license - AI 1 = 100% AI-generated |
In my case, libraries are important, and I use them a lot, since I am not an experienced programmer. |
|
The issue is the same that has existed in open source since my inception to the scene. People will always prefer well tested, popular libraries over a zero star new library. It's common sense and unrelated to LLMs. I think LLMs tend to worsen the issue because there's just so much slop that has been generated since LLMs started to be a thing people will tend to be even more hesitant to adopt new libraries, especially if they've been created with LLMs since the pattern follows: LLMs are a reflection of the average of code in the world, and the average is mediocre, by default. The other issue is one of trust. If all you do is generate code and merge without looking at it you might expect (I would expect too) no one is going to use your library for the reasons you've laid out: Why trust their LLM when I know my LLM is good and I trust my own self to drive it. This is the issue I've seen with some projects like go-gpu. The go-gpu owner does not even answer comments and questions personally instead taking a 100% AI driven approach to both coding and social interaction. And incredibly there are still people excited about using go-gpu. To be clear, I don't think that approach is sustainable yet and I am not vouching for it. Take it at face value: there are people out there that do not care if an AI writes the code and answers their question, they'll happily use that proxy. In the end, people will always find a reason to use/not use a library. I plan on writing high quality libraries and being in charge of the design and being honest and direct with my users to build trust. I believe this path will yield high quality codebase and a ecosystem of users that value the same thing as I do. |
|
I was (and still am) an AI skeptic (although I prefer to call myself a "realist"). AI is a tool - just like IntelliSense and autocompletion removed the need to keep the entire libraries and API definitions in your head, just like high-level language compilers removed to need to know assembly. The way use use the tool is the true differentiator. Agentic tools are not goind anywhere - they are here to stay and we have to adapt to the new reality. However, for hardcore software engineering writing code was never the slowest part. Knowing WHAT to build and HOW to build it is the real challenge. Yes, AI lowered the bar for creating the taiored thing, but as with any automation it is fully compliant with the GIGO (Garbage In - Garbage Out) principle. Yes, it will create something plausible, but the engineer at the controls, is what determines the quality of the output. You either know or you don't know what you're doing. Any automation (including AI) will help you go faster. My personal litmus test before contributing AI-generated code to some project is very simple. I ask myself one simple question - Am I willing to stake my reputation on this code just as if I typed every character myself? Or in other words - Do I really know what I am doing? |
|
Last year, I had an interesting experience that really encouraged me to use AI. Years ago, I decided to build my own dual-slope ADC using a Raspberry Pi Pico and TinyGo. I lost patience and decided to turn to AI. And with AI, I managed to successfully complete the project! Digital Voltmeter with 4 ½ digits - Raspberry Pico |
Uh oh!
There was an error while loading. Please reload this page.
We are experiencing a new technological revolution in which artificial intelligence is changing the way programming is developed, as well as many other sectors.
In recent days, new advancements and features for artificial intelligence—specifically regarding ChatGPT—have been announced.
As a technology enthusiast who really enjoys testing new features, I decided to try out ChatGPT - CODEX.
I’m not here to promote anything, and I know people have other preferences when it comes to AI.
I am developing a power inverter using TinyGo and the Raspberry Pi Pico, with the help of AI.
https://en.wikipedia.org/wiki/Power_inverter
A power inverter is a power electronic device or circuitry that changes direct current (DC) to alternating current (AC).
After providing my specifications to CODEX, I received a ready-to-use program containing all the project details within just a few minutes. From the initial tests, I could see it was running exactly as I had requested. To my surprise, it even suggested additional key features for the project.
The next phase of the project will be hardware development and testing. I will share updates as soon as I can.
My view on AI is that we are embarking on a new path of no return, where those who don't use AI risk being left behind.That is my perspective. I’m not trying to stir up controversy, but I do think it’s important to discuss this.
What do TinyGo developers and users think about this?
All reactions