This content outlines a 10-level progression for embedded systems developers to transition from traditional coding to an AI-assisted "architect" role, significantly boosting productivity by leveraging AI agents for code generation, specification management, and complex development tasks.
Mind Map
انقر للتوسيع
انقر لاستعراض خريطة الذهن التفاعلية الكاملة
The transition from coder to architect
is the biggest productivity jump I've
experienced in 40 years of electronics.
Do you want to join me on my journey?
With my 10 levels, it's much easier than
you think. And no, it's not about chat
GPT alone. We are going to the next
levels. Reality YouTubers, here is the
guy with a Swiss accent bringing you a
new episode with fresh ideas about
sensors and microcontrollers.
If you subscribe, you will always sit in
the first row. Let's start simple. If
you haven't tried this yet, ask JPT,
Gemini, or CL to fix your code or
generate your next Arduino sketch. Copy
paste the error messages or write what
you want in plain language and the
result will surprise you.
Using these chats is okay for tiny
projects, but as usual on this channel,
we want more.
This video's content. Spectdriven versus
wipe coding, chats versus agents,
sandboxed versus full control, data
sheets and libraries, command line
development, GitHub and AI, project
memory and parallel work, moving beyond
Arduino IDE,
and practical examples to get you excited.
excited.
We already started with level zero vibe coding.
coding.
You ask an AI chat for a function or a
complete sketch. Copy paste the result
in your IDE. Test and hope. A common
first step into the new world. But your
control C and CtrlV fingers will
eventually need a holiday.
This is why I suggest a different
approach. Level one, specdriven development.
development.
Now we get serious.
You never touch code directly. Instead,
you write specifications and the AI
writes the code. If something doesn't
work, you update the spec, not the code,
and let the AI regenerate the whole
thing. You still have to copy paste the
new code into your IDE and the
compiler's error messages back to the AI
though and sometimes ask give me the
entire file for copy paste if the AI
only provides corrected code snippets.
This works but the chat window becomes
messy. Time for an upgrade to level two
functional specification documents.
Instead of putting the text in a chat
window, you create a file with your
specification. You can use plain text
files, but they are hard to structure
and not well readable.
You could use office tools like Word,
but unfortunately current AIS do not
like this format. A good compromise is
Markdown. It uses plain text files with
annotations for headings or bold text.
AIS can read and write MD files and they
use this format for their own documents. Perfect.
Perfect.
In a standard text editor, they are
readable but not nice.
You can use programs or web services to
display them in a formatted way because
that is like in the 1980s.
I wanted a what you see is what you get
type of editor. After some searching, I
found Typora. It costs $17 for up to
three computers. Money very well spent
for a start in the new world. I call
these files functional specification
documents and always include FSD in
their file names to make them easy to
find. In chat, you add them with a plus
sign and get the code in the chat window.
window.
If you have more than one project file,
things get a bit hairy. You can add up
to 10 files to a single chat, but the
chat lists all files in a single window,
and copying and pasting different files
isn't pleasant. This is when we need an
afterburner and get to level three agents.
agents.
What we call AI is mostly large language
models. To conveniently work with them,
humans use a chat interface. But this is
only one way of interacting with these
LLMs. We can use many other ways of
interaction. They are conveniently
called agents. So chat is the best known
agent, but by far not the best for programmers.
programmers.
For us, there are better agents offered
by companies like Antropic, Google or
OpenAI. They are called claw code,
gemini cli or codecs and they can be
used in terminals or integrated into
idees primarily based on visual studio code.
code.
What's the difference between a chat
agent and an agent focused on programming?
programming?
Programming agents are designed to
operate on entire project folders rather
than only on whole files at once. Unlike
chat models which usually work with
complete documents, programming agents
can read, edit, and write individual
lines. This allows them to handle very
long program files without overloading
their context windows. No, this is not
Microsoft's next attempt to replace
Windows 11. A context window is simply
the memory space where an LLM keeps
everything it currently knows.
That space is limited, valuable, and
must not be clocked with irrelevant data.
data.
Loading only the necessary parts of a
project into the context window is one
approach. Summarizing or compacting all
the messages is another. And there are
many additional tricks which we will not
cover here partly because these
techniques evolve almost daily.
Installing these agents is
straightforward and can be done in two
ways. Inside Visual Studio Code where
most models provide extensions or even
complete products such as cursor or anti-gravity
anti-gravity
in a terminal window where you find
oneliners to install them directly on
your system. The LLMs then need to be
trained to use these file editing tools
effectively. This is where the
discussion about the best model
typically begins. Every week, one of the
major players releases a new LLM
generation, and this always generates
headlines. The tests people perform are
interesting, but for embedded systems
developers, they are not particularly
relevant. Why? Because we interact with
the LLM primarily through agents and do
not try to produce funny cat videos.
The quality of the agent matters far
more for us. And here I have seen
considerable differences. To my
knowledge, Claude from Antropic was the
first agent explicitly focused on
programming and others followed quickly,
though not always successfully, at least
for now. In my daily work, Clo
outperforms both Google's Gemini and
Open AI's codecs. Of course, this
ranking may already have changed by the
time you watch this video.
One major advantage is that it makes
significantly fewer errors when editing
files. If an AI has ever completely
corrupted one of your main project
files, you know exactly what I mean. And
with that, we arrive at level four,
GitHub. If you start using coding
agents, I strongly recommend managing
your projects on GitHub. First, it
protects you from accidential file
corruption. And second, it provides
history tracking, a feature we will
fully appreciate as we move to larger projects.
projects.
How do we interact with these agents? In
practice, it is not very different from
chat interfaces. We type instructions
into a text window and the LLM responds.
The real difference is where the heavy
lifting occurs. Not in the chat window,
but behind the scenes directly in the
files of your project directory. In the
terminal, you can ask, for example, add
the feature described in chapter 4 of
the FSD. If you selected the right
agent, it simply makes all the needed
changes in your files.
You just can upload and test. Which
brings us to level five.
Who is in charge and who performs the
work. All agents execute commands in
your terminal. Before doing so, they ask
for permission, an important safeguard,
especially on your primary PC. With
their capabilities, they could cause
significant damage if misused.
That's why some agents operate in a safe
sandbox. They can only access the
directory they run in. They cannot touch
the rest of your computer and sometimes
cannot even access the internet. This is
very safe but practically useless for
lazy people like me. The agent says,
"Here is what should be done, but I
cannot execute it. Please copy and paste
this command into another terminal. run
it yourself and paste the output back
here. Terrible. I do not want to become
an employee of my agent.
Always check the latest capabilities of
the agents and verify that they meet
your requirements. Their features change
quickly. For now, Claude Code is the
most capable agent also here. It can
execute a wide range of commands on both
Linux and Windows and it knows exactly
how to use them. And this leads us to
level six, a VM for development.
For most of my projects, I use a small
VM on my Proxmox server and grant the
agent full access to it. This way, it
can do everything necessary while
operating within a controlled isolated environment.
environment.
My main tasks became writing my wishes
in plain English, supervising progress
and verifying the results. During
planning, I can also discuss different
approaches with the agent. Because it
knows the project, its answers are very
focused. In this setup, I remain the
boss and the agent becomes the most
capable and willing employee I ever had.
Of course, it does not work for free.
Its minimum wage is about $20 per month.
The free tiers usually allow only a
small number of conversations, enough
for testing, but not enough for real projects.
projects.
To support this way of working, cloud
code offers a very useful parameter.
Dangerously skip permissions. Gemini and
Codeex provide a similar one humorously
named YOLO or you only live once to save
typing work. Right after installation, I
ask Clo to install a command called
super code which launches clo code with
this parameter enabled.
With this, the agent can execute entire
workflows without having to repeatedly
confirm. You can monitor what it does or
simply grab a coffee or even go for
lunch. When you return, you'll often
find a detailed summary of everything
accomplished. And in many cases, the
entire problem is already solved.
One question remains, which IDE do I
use? None. I prefer a simple terminal
window. Why? Because it's incredibly
lightweight and works on nearly all
machines. Also in headless setups, you
just navigate to the project directory
and type the agent's name. On Windows,
you can even click in the file explorer
path area and type cmd to open a terminal.
terminal.
No need for PowerShell. The agent can
run PowerShell scripts from this terminal.
terminal.
Compared to an IDE, I lose the very
convenient project tree view. That's why
I asked Claude to set up a sambar share
so I can access project files directly
from Windows Explorer. Almost like
working in an IDE.
Level seven, many parallel projects.
A separate VM, a terminal, and a sambar
share are ideal for working on multiple
projects at once.
To give the AI access to documentation,
I store all reference materials inside
the project directory. The agents also
keep their internal knowledge files
there. CLA stores its memory in claude.md
claude.md
while Codex stores it in agents.md.
When returning to a project, I simply
time slashres and the agent restores its
context from the last session. Very convenient.
convenient.
This is not all. We can completely
replace the Arduino IDE or platform IO
and reach a new level of automation.
Level eight, using the command line interface.
interface.
When you develop with the Arduino IDE,
the AI can edit source files but cannot
see compilation errors or locks. It can
also not upload the file. In contrast,
if you work in a terminal and use the
Arduino CLI or platform CLI, the agent
can automatically compile and upload
your projects. In return, it receives
compiler messages and logs and it often
corrects errors on its own. And because
it sees the runtime output in zero, it
can detect whether the program behaves
as intended and adjust the code
accordingly. If you have never witnessed
this, you might think it's impossible,
but it's not. A small example. I wanted
to add wire guard to one of my projects,
but it didn't work. I asked Claude to
implement debugging in the relevant
area. Yes, that's how I talk to my
employee. Not with sophisticated
prompts. Claude added the appropriate
serial print statements, analyzed the
log output and responded, "The problem
is in the library." I asked it to add
debugging there as well. After another
round of analysis, the agent returned
and said, "Work found, implemented, and
tested. It works in Expressive's Wire
library I have never seen before."
Now you understand why I love my agent.
As a final touch, I asked it to prepare
an issue for the library maintainer. It
drafted the issue and asked whether it
should post it under my name.
That is what I call completed staff
work. But we can go further to level 9
reading data sheets.
Another project involved a Modbus proxy.
I wanted an ESP32 to read the smart
meter from my solar inverter. Add the
power consumed by my wall box and send
the updated values back to the inverter.
Not too complicated until you open the
data sheet of the smart meter with its
endless lists of values and
multiplication factors. Traditionally,
you would read the data sheet manually
and copy the required parameters into
your program. Not anymore. I placed the
data sheet into the project directory
and asked Claude to use it for the
proxy. The result is this large block of
definitions, including the entire
library. Produced without me reading the
data sheet or writing a single line of
code. Good enough for the girls I go out
with. So if a new chip lacks an
available library, you can generate one
in minutes.
You see, we are on a roll. So, let's
step up to the last level for today.
Level 10. Leaving the Arduino
environment completely. In another
project, I ask myself, do I still need
the Arduino environment to program an ESP32?
ESP32?
Since I no longer read or write code
manually, I no longer need to understand
the language or the development
framework. the simplicity of the Arduino
IDE which was essential in the pre-AI
times becomes less critical. So I
switched to ESP IDF for the ESP32
projects. The reason is simple, better
support and I did not have to learn
anything new. I only updated my
specifications to say use ESP IDF and it worked.
worked.
Most engineers nightmare is
documentation. Since adopting AI agents,
documentation has become trivial. From
time to time, I simply write update the
FSD and the readme commit and push the
repo or in short update documentation
and push.
So far, everything sounds positive. But
what about hallucinations?
This is one of the standard criticisms
of LLMs and is frequently treated as a
knockout argument. Fortunately,
hallucinations are not a significant
issue in embedded software development.
Compilers do not tolerate hallucinations
because for them they are simply errors
and if a hallucination reaches the
device, it will be discovered during
testing. The second remaining human responsibility.
responsibility.
After specifying what we want, we must
thoroughly test the results.
Fortunately, since I don't spend time
coding anymore, I have more time
available for testing.
This brings me to where I am today. I
wrote this Balloon Hunter app for iOS,
which you can find in the App Store. As
a following experiment, I reused its
functional specification to build a
similar Android app. Here it is. It
looks very similar and its functions are
equal but based on the Google ecosystem.
I also wrote this hornet hunter app
which connects to Kraken STR direction
finding receivers to track invasive
hornets that threaten our bees. We mount
tiny transmitters on the hornet and with
direction finding techniques try to
follow them to their nest.
For development purposes, this ESP32
simulates the flying hornet. It emulates
two Kraken SDRs, computes the correct
direction values, and exposes them via
an API the app can use. Of course, it
was written in minutes by AI.
Since we covered a lot, we quickly go
through the 10 levels.
Level zero, VIP coding. asking an AI
chat for a snippet, then copying and
pasting it into your IDE while hoping
for the best. Level one, specdriven
development, defining requirements in
plain language and letting the AI
generate the code, which you then
manually move to your IDE. Level two,
functional specification documents,
using structured markdown files as a
single source of truth for the AI to
read and update.
Level three, agents. Moving from simple
chats to specialized tools like code
that can see your entire project folder
and edit specific lines. Level four,
GitHub integration using version control
to track AI changes, provide project
history, and protect your files from
accidential corruption. Level five, full
execution control. moving past sandboxed
environments to let agents run terminal
commands, install dependencies, and
execute scripts. Level six, development
VMs, isolating your AI agent in a
virtual machine with YOLO permissions
for a combination of speed and safety.
Level seven, parallel projects. Managing
multiple projects simultaneously, each
in a VM, and allow agents to store and
resume their context from specialized files.
files.
Level eight, CLI integration,
letting the agent compile, upload, and
read serial logs directly to fix bucks
in real time. Level 9, automated data
sheet analysis.
feeding raw PDF data sheets to the AI to
generate a library without manual reading.
reading.
And finally, level 10, beyond Arduino,
moving to professional complex
frameworks because the AI handles the
steep learning curve for you. That's all
for today. As always, you find all the
relevant links in the video description.
If you found this video useful or
interesting, please support the channel.
Thanks for watching and see you in the
انقر على أي نص أو طابع زمني للانتقال إلى تلك اللحظة في الفيديو
مشاركة:
معظم النصوص تصبح جاهزة في أقل من 5 ثوانٍ
نسخ بنقرة واحدة125+ لغةالبحث في المحتوىالانتقال إلى الطوابع الزمنية
الصق رابط YouTube
أدخل رابط أي فيديو YouTube للحصول على نصه الكامل
نموذج استخراج النص
معظم النصوص تصبح جاهزة في أقل من 5 ثوانٍ
احصل على إضافة Chrome
احصل على النصوص فوراً دون مغادرة YouTube. ثبّت إضافة Chrome للوصول بنقرة واحدة إلى نص أي فيديو مباشرةً من صفحة المشاهدة.
