Learn how to program without AI. Learn about software engineering, including algorithms, data structures, software architecture and design, the lot. Work on projects entirely without AI, and once you have completed some projects, work on some more, also without AI. Continue until you have mastered software engineering.
Only once you can engineer and develop whatever you want _well_ use AI, as you will have to direct said AI to follow your design, understand everything the AI spits out, and clean up after the mistakes it makes -- things that require you to be able to program _better_ than the AI in the first place. Never make the mistake of thinking that the AI can come up with a worthwhile design for you.
Always remember that what AI produces fundamentally cannot be trusted as is -- generative AI 'hallucinates' by its very nature -- and that unlike code you written before yourself you won't truly understand what it is 'trying' to do off the bat. Sure, you may have written natural language directions for the AI, but natural languages are often ambiguous and often do not fully signal intent, so the AI may not have done what you actually intended for it to do.
Never think that quantity equals quality -- while generative AI may easily spit out reams of code, those reams of code will lack the fundamental quality of code you have hand-written yourself. Think of what the AI generates as if it were the output of a beginning junior developer chronically high on meth, with everything that entails.
At my day job (not going to name the company) they have been pushing AI coding, and frankly I have found it to be essentially useless.
As a simple test, I used Claude under GitHub Copilot to develop a simple program to blink an LED using a task under zeptoforth (my Forth implementation for ARM Cortex-M, which is on GitHub so it should have been in their training set) on a Pimoroni Pico Plus 2... which took a few hours to complete because it was constantly hallucinating my API's and getting minor points wrong that I had to tell it to fix... for it to only screw something else up the next time around... repeatedly.
Then the next day they had us do an "agentive AI training" where we were supposed to use "agentive AI" to program example stuff... and I found it worked to a point ─ until it didn't work, and I could never actually make it do what I really wanted it to no matter how hard I "vibed". It just hit a stopping point where no amount of prompting would make it work.
And then there's the actual use cases for AI at my day job ─ I have not seen any that apply to me. I write only limited amounts of code ─ I do not churn out the boilerplate that AI is sold as obviating ─ and the code I do write has to be correct, for values of correct where simply looking correct is not sufficient (and an AI won't know the underlying math behind things or how to avoid things like race conditions).
If I actually used AI I would be spending more time trying to understand its output and having to fix it than I actually spend developing code, and I would have a harder time trusting the resulting code. I know how my code works because I wrote it ─ the same would not be true if I had an AI write my code for me.
Sure, there are people at my day job who have gotten fully on-board with the AI thing, and who see it as being useful for things like, say, changing the C++ standard for a whole project at a time. However, I would not be able to trust the project after that point myself. Yes, it would take much more time to manually update the code, but then it would be much easier to trust afterwards, and would require far less fixing to handle all the cases where the AI screwed up.
I have not had any feedback from Chuck, but from looking at Chuck's work I think he wouldn't consider zeptoforth to be all that Forthy.
As for a zeptoforth-MCP bridge, well, I am not really a fan of LLM's. At work we have GitHub Copilot, and I find its autocomplete to be more of a nuisance than anything, as I never like its suggestions and find the fact that it suggests anything, which I then have to reject, as largely something that interferes with my flow.
I went a completely different route when implementing zeptoforth (https://github.com/tabemann/zeptoforth) -- I went right for implementing a fully-featured system rather than focusing on minimalism, and came out with something that I am extremely comfortable writing non-trivial code with rather than a toy that shows how small of an implementation I can make without regard to being a practical tool. And yes, zeptoforth is very big as Forths (especially microcontroller Forths) go -- because the goal is to make something that can be used to program real systems out of the box with minimal effort on the user's part.
I largely agree with this article's assessment. As a machine the Jupiter Ace was simply too little, too late. Had it been more powerful, with more RAM and better graphics, it could have given the Speccy a run for its money, but rather it was already obsolete, being positioned as a competitor for the ZX81 when the ZX81 was already very dated and where it had little in the way of a cost advantage over the far superior Speccy. Running BASIC rather than Forth would not have saved the Jupiter Ace, and rather if the Jupiter Ace had had specs that compared with those of the Speccy it could have given it a run for its money.
Only once you can engineer and develop whatever you want _well_ use AI, as you will have to direct said AI to follow your design, understand everything the AI spits out, and clean up after the mistakes it makes -- things that require you to be able to program _better_ than the AI in the first place. Never make the mistake of thinking that the AI can come up with a worthwhile design for you.
Always remember that what AI produces fundamentally cannot be trusted as is -- generative AI 'hallucinates' by its very nature -- and that unlike code you written before yourself you won't truly understand what it is 'trying' to do off the bat. Sure, you may have written natural language directions for the AI, but natural languages are often ambiguous and often do not fully signal intent, so the AI may not have done what you actually intended for it to do.
Never think that quantity equals quality -- while generative AI may easily spit out reams of code, those reams of code will lack the fundamental quality of code you have hand-written yourself. Think of what the AI generates as if it were the output of a beginning junior developer chronically high on meth, with everything that entails.