Something happened the other day that left me genuinely concerned. I happened across a diagram going around LinkedIn at the moment that was showing an agentic firmware workflow, ten stages arranged in a wheel, spec goes in at one end and a proof comes out at the other, and a person is nowhere in that loop. For someone like me who does the work, because I enjoy doing the work and having the joy of learning and growing rather than just the outcome at the end, can see the dangers, this sparked something in me, the post is here:

Jacob Beningo's Agentic Firmware Workbench post

And the workflow he published looked something like this: 

In this "embedded agentic loop" the agent reads the specification, retrieval pulls the right page out of the reference manual, a skill writes the change, the agent builds it and then tools flash the board and read the console. The agent then captures the waveform, another skill checks it against the acceptance criteria, the agent fixes whatever failed, and round it goes again.

Skills this and skills that, all "agentic" and very AI utopia looking. The original author of the post is Jacob Beningo, a well known name in the embedded industry, and someone whose work I follow closely. He published it and it is a good piece of work, cleaner than most of what gets proposed for this. When I asked him in the comments how students are supposed to learn in a world where that is the workflow, he said straight out that it is the same thing worrying him and that he is rebuilding his teaching material because of it.

So this is not an argument with him. He and I are looking at the same hole. This is about what I think we do about it, and it is coming from a place that changes which part of the problem looks urgent. You see in 2020 I wrote an article for Thomas Edison State University on how you can bridge the gap between a Computer Science education and embedded IoT systems How to Bridge the Knowledge Gap Between Computer Science Education and IoT Development | Thomas Edison State University because that is where the focus was 6 or so years ago. While the information itself is not exactly dated, the world has DRAMATICALLY changed in that time, and no graduate has been impacted more than persons who work in Computer Science and related technical fields. What is changing most rapidly in my perspective is the way society (and big tech) is trying to push change in how people learn. 

I work out of Trinidad and Tobago, I am an embedded engineer and I have written four published books on this stuff (pre-ai era) to help people wanting to learn first principles and "break in" to the glorious world of embedded systems.

I did not learn any of it in a lab with somebody senior sitting next to me, because there was nobody senior sitting next to me, I learn through trials and error, blown boards and upset customers. Where I am there is no embedded industry here to apprentice into and I didn't have internet when I first started my journey. So what I had was datasheets, cheap parts, a multimeter, eventually a 25 MHz bandwidth scope (that I still use to this day) and an enormous amount of time spent being wrong about things. Together with reading any book, article, or fragment of information related to embedded systems.

That is the entire education, while I did go on to formal education after, it was mainly a personal validation goal for me than a gateway into industry, cause after the first 2 years or so, education matters much less than a body of work you can point to, I'm going fully cycle again as I am considering a formal course of study in Philosophy of all things because I think despite being under fire and the subject or ridicule, in a post AI era, fields like arts and philosophy will become more relevant, because its our thoughts, questions and innate consciousness that makes us human. It's funny because the late Steve Jobs being the visionary he was said this:

“It is in Apple’s DNA that technology alone is not enough, it’s technology married with liberal arts, married with the humanities, that yields us the results that make our heart sing.”

- Steve Jobs

Believe it or not that quote led me to double major in Computer Science and Liberal Arts for undergrad. Because of that I always prided myself on high output, people first systems and spend most of my free time helping persons who want to get into technology and want simple explanations and a human touch. The opposite of the corporate "sink or swim" "trial by fire" style of learning. Thing is even that is being eroded, because as someone who naturally outputs a high amount work, we are in an era where breadth of output gets the "oh AI did it" hand wave. 

Now to bring about this point consider this. I have 16 years in industry, and as a hobby since I was 8 years old making light bulbs and motors, then when I was 9, I got one of these bad boys for Christmas:

In fact I still have the book around, I took a picture of it a few years back:

I went from that to my "50 in 1" kit to eventually mastering everything from building systems with 8-bit PICs with bytes (yes the first ever PIC I used had 25 bytes of ram, and its still made to this day! PIC16F54 | Microchip Technology) all the way up to now configuring cloud based Kubernetes systems that serve national populations and actively seeking out new RISC-V silicon to find bugs and create an ecosystem around it. Despite all this, a student with less than a year work experience looked at my Rovari project I have been spending the last few years building and all the components and demonstration of my hard earned years of breadth of expertise said this to me on Reddit: 

Despite me relentlessly checking everything I put my name next to in the ecosystem I'm working on, giving out my personal email where anyone with concerns or questions about my work can reach out to me, we live in an era where my polished work, is attributed to AI, rather than my years of experience, and being lectured that "AI can make mistakes" despite spending the better half of the year writing a book on how AI works from the inside from first principles I Trained GPT on a RISC-V MCU with No FPU in 37KB of Memory.

I think I better than most know first hand that yes AI does make mistakes, hence my aversion to projects that are clearly vibe coded and have 0 human checks on the output, and the person who "prompted" the system also can't tell you major components of the system much less how to begin to troubleshoot it.

Personally, I'm waiting for the technical debt fallout, but in the mean time my focus more and more on physical systems. The time we are in now if it's too polished is said to be AI and too sloppy is well AI slop. 

You see when I build, if nothing goes wrong I get worried because its the natural order, and I rather catch the failure than a customer somewhere. So I try to put a little extra effort into the things I do to understand every nook and cranny. After all it's my name thats going next  to it.

All of that so say this. 

We are in an era where my entire cumulative life experience is not being held against a workflow or on its merits. We are heading toward a dangerous age where "stage nine" is labelled "fix" what failed and the label underneath it says AGENT. The person who ran the loop gets a pat on the back and becomes more dependent on the machine as his own skills that he either built dwindle away or worse, he never had them in the first place. 

What The Loop Takes and Borrows

Now I want to be very clear on something, not every stage in that wheel matters the same and I do not want to be the guy who romanticises toil. Nobody's judgment was ever built by typing make and watching a progress bar. Having a tool flash the board is fine, in fact right now I'm working on the Rovari project and got a few contributors starting this week, my AI policy with them is "AI is a tool, if you do use it I don't want to know, what I do what is that you comment stuff yourself and when me or anyone asks why X does Y you should be able to answer because you own the output". You see having retrieval find the right page in a two thousand page manual is mostly fine, though I have a small private worry about what happens to your feel for a part when you never have to hunt through its documentation and accidentally read the three pages either side of the one you wanted.

I discovered errata in chips and documents exactly that way, because the doc said one thing and working with the parts I discovered another, sometimes the unintentional reading comes back up when you do something later on. In my RISC-V works which is where I concentrate now, I have found half of what I know about the CH32 family from reading sections of the datasheet I didn't intend on reading. 

Now before we stray too much let's get back to the "utopia" AI workflow. Two stages are different, and they are different in kind rather than in degree. Let's say I do bring myself to terms with AI is here to stay, there are people who will use it and you can't put a genie back in a bottle or unpop the cherry. There are two stages I will not accept us as an industry to adopt. 

Stage seven captures a waveform and hands the trace to the machine, not a person. Reading a scope trace is one of the very few places left in this work where the physical world gets to contradict you directly and without negotiation, like I was explaining above. What you see when working with a part matters more than what a document says. You have a model in your head of what that bus is doing, you put probes on it, and the screen shows you something that does not match, and that mismatch is not an obstacle in the workflow, it is the mechanism by which you learn and build experience... It is the ONLY mechanism that drills experience into you, cause your brain forms these connections with a tangible step. I remember hearing about old engineers who were so in tune with their system that in the dial up era they could look at blinking lights on a modem and tell you what your network was doing and what was causing it. I have written four traditionally published books and several self published, and I will tell you plainly that no book, mine or anybody else's, can put into a reader what ten years of being surprised by an oscilloscope puts there. Don't get me wrong books and tutorials are a guide, but only you can apply whats in them to learn. 

Moving on we see that stage nine diagnoses the failure. To be honest, this was the part the disturbed me the most. Diagnosis is the highest value thing a human does in that entire loop, because it is the one act that forces you to hold a model of the system, put it against evidence that says the model is wrong, and work out which part of your understanding broke. It's what builds intuition, you know that gut feeling you get sometimes in the future that it's X part of the board? This is the process by which that gets built. Implementation I believe, you can hand off and lose relatively little. Diagnosis you cannot, because that diagnosis is what the understanding is made of. Take that away and you still get working firmware, and you get an engineer who cannot tell you why it works, which in this field is giving me Toyota Acceleration Incident case study Toyota Sudden Acceleration: A Case Study of the National Highway Traffic Safety Administration - Recalls for Change that another well known name in the embedded industry Mr. Michael Barr testified on. 

Why This Lands Harder Where I Am

Here is the part that I suspect does not occur to people writing about this from inside a functioning industry. If you are an engineer in California and your judgment quietly erodes over three years of approving agent output, you are still employed. You have a title, a company on your CV, a network of people who know your name, colleagues to cover the gaps, and an industry that will keep you moving on reputation and proximity for a long time before anybody checks what you actually know.

I have none of that. Nobody in this business knows Trinidad. There is no local industry vouching for me, or alumni network, and  there isnt an employer name that opens a door. The only thing I have ever had to trade on is that I actually understand the machine, and that I can prove it by building something that works and explaining exactly why it works. That understanding has helped me get clients and worked with teams not only in my region but across several continents. Understanding is the only credential that travels out of a small island, because it is the only one that does not need anybody's permission to be recognised.

So when I look at that wheel, I am not looking at a productivity question. I am looking at the thing that got me out of a place with no path, being quietly removed from the workflow of everybody who comes after me. And it will be removed from them first, because they will never have had it. I got mine the slow way, by being wrong at three in the morning with a scope and no help, and no Google to look up, before there was anything that would do it for me. The student who starts tomorrow with that loop already built will get correct firmware on day one and will never once be forced to be wrong about anything, and the thing I traded on will simply not exist in them.

And Yet I Am Not Telling Anybody To Switch It Off

Before I get the "yes but X Y Z", I want to state my position and be honest other half, and I would be lying if I skipped it.

Regardless of voices like myself begging and pleading for understanding and the importance of learning and understanding output, more and more we are being looked at as dinosaurs. We are being drowned out by billion dollar marketing budgets, managers and customers who want a PCB in 15 minutes because "I saw ChatGPT Super Latest Greatest AGI model design a PCB in 15 seconds GPT-6 Astra: A new generation of intelligence | OpenAI" and scores of people who have very little experience some students building "web connected ESP32 super IoT AI RTOS Zephyr gadget in 10 minutes" and cannot explain a mutex from a semaphore much less a BLDC drive or MOSFET power circuit that won't blow up, without looking it up and running to an AI model, while I'm here fiddling with RISC-V systems for days. Like earlier this year when I ported NuttX to the CH32V307 I spent days inside the PFIC finding out exactly how wrong my model of that interrupt controller was, and the writeup I published is literally titled after everything that went wrong. I wrote the C SDK for the Dabao board and just this week I bricked 3, lol. 

So back into it. We can't pretend that AI doesn't exist and people won't use it, because they will. I use tools to check grammar and spelling when I write books, but not blogs and posts cause the mistakes and bad grammar add an air of authenticity that Grammarly corrections "edit" away.

The thing is, that this is not an AI only problem though, before the AI era, I had a book deal fall through with No Starch Press some years ago cause I felt like the editor wanted me to rewrite my manuscript to match some "tone" they were looking for, rather than my voice and way of speaking. So beyond spelling errors (which any book hundreds of pages long had before tools could do a giant sweep) I was at a point where they had me rewriting chapter by chapter to match some "voice" that was a bit too polished for a beginners book in my taste. So it fell through and since that I decided to now move to self publishing.

My point I'm making is that despite tools like grammarly being around for years before LLMs, they are all now "AI" aka "LLM" powered, so to sit and pretend that we either will intentionally or unintentionally due to enshittification shoving it down our throat encounter AI by force is delusional. Some manager, some company or client or co-worker will use AI. In fact I had a customer tell me outright "ChatGPT said your method won't work"  to which I responded with a video demoing my solution. 

It's sickening for people with experience.

But you see one of the things being a police officer for more than a decade (yes I wear multiple hats) taught me is that sometimes you need to look at things from the perspective of the other side. Let's go back 15 years. I loved electronics, so when I left school, I wanted to take on work and literally stared into the void. The closest thing I had to help was a copy of "So You Wanna Be an Embedded Engineer: The Guide to Embedded Engineering, From Consultancy to the Corporate Ladder", that had nothing to do with what I needed to learn or how things worked in my region. I needed a senior engineer and there was none. 

Fast forward into 2026 and that agent is the senior engineer I never had, and hallucinating or not I would have been grateful for something like that 15 or so years ago. It answers at two in the morning, it never makes the user feel stupid for asking like StackOverFlow and even Reddit was infamous for, and it does not care that my country is not in anybody's list of markets. For somebody self teaching out of a place with no industry, that is not a convenience, it is the removal of a wall that has kept people like me out of this field forever.

The same argument I made about RISC-V that I did in response to Dmitry Grinberg's criticism of the architecture A Third World Embedded Engineer Responds to "RISC-V: They Should Have Known Better", that winning on price and availability decides who is in the room, applies here in full. Anybody who tells a new engineer, or one from the "developing world" to forgo agents to preserve his purity is telling him to compete with one hand tied against people who never had the wall in the first place.

So the answer cannot be abstinence, and it cannot be nostalgia, and it definitely cannot be some senior guy telling juniors that they should suffer the way he suffered. It has to be a way to keep the automation and keep the engineer, and it has to cost little enough that nobody drops it the first time a deadline shows up.

Cognitive Tether Engineering

So that is what I have been thinking about over the past few days, it's a concept that I've been casually reminiscing on in the back of my mind, and seeing a total agentic loop thats "spec in, proof out"  (or as us with a CS background will say "Garbage in, Garbage Out") lit a fire under my nether regions to at least document it. I am calling it, Cognitive Tether Engineering, CoTE, and the whole principle is one line. Before you think its just another thing like "agile" or "story points", bear with me a bit to understand my reasoning. The whole idea of the premise is this: 

Automate the work without automating away the engineer.

The definition I am working to is that CoTE is a way of designing human and agent workflows in which selected cognitive obligations are deliberately kept by the person, placed at defined points in an otherwise automated process, carried out before the corresponding agent output is shown, and recorded as durable evidence of the judgment that was applied. Essentially the "tether points" are enforced by an interlock, in the ordinary safety engineering sense of something that will not let an action proceed until a condition is met. In CoTE, the condition here is that the engineer has already committed a position.

That ordering requirement is the entire thing and I want to be blunt about why it matters more than anything else in this article. If you show an engineer the agent's answer and then ask him to justify it, he will justify it.

Every. Bloody. Single. Time.

What you get is a workflow that feels rigorous, produces a signed off record, and does no cognitive work at all, which is worse than having no method, because it manufactures confidence that nothing was lost, the "illusion of due diligence". A tether that discloses before it asks is not a tether. It is theatre, and the industry is going to produce an enormous amount of that theatre over the next few years because it is cheap and it looks responsible. Theatrical clowning has been around a lonngg time, it may differ from traditional circus tricks, but in the end its all a clown show. 

This Is Not The Old Deskilling Argument

Now when I propose my methodology to combat this, somebody is going to tell me Lisanne Bainbridge said all of this in 1983 with the paper "The Ironies of Automation" PII: 0005-1098(83)90046-8 and they are partly right. So let me concede it before it gets used against me. Ironies of Automation is the canonical statement, automate the easy parts, leave the human the hard parts, and simultaneously take away the practice that kept them able to do the hard parts. Mica Endsley gave us the out of the loop performance problem The Out-of-the-Loop Performance Problem and Level of Control in Automation - Mica R. Endsley, Esin O. Kiris, 1995. Aviation lived the whole thing in public after Air France 447 Chaos in the Cockpit: A Medical Correlative - PMC and answered it with policy requiring pilots to hand fly the aircraft now and then so the skill would still be there when the autopilot handed them a problem at altitude in the dark.

None of that is new and I am not claiming to have discovered it. What I am claiming is that the mechanism underneath has changed, and the old fix does not transfer, especially in the field of embedded systems. 

Every one of those precedents is about supervisory control, a human watching a machine execute a bounded task inside a known envelope, holding a mental model of the process and stepping in when reality drifts from what its "supposed" to be. The operator still owned the reasoning and a reactor never built an argument about its own state and handed it over for approval.

The agentic loop we are discussing, turns that inside out, because what is being handed off is no longer the execution but the reasoning itself, and what comes back is not a state to monitor but a conclusion with a justification already attached to it. You are not modelling the system any more, you are grading an argument somebody else constructed, and that is a much weaker cognitive act than constructing one, which anybody who has ever nodded along to a plausible sounding explanation in a code review already knows in their bones (ask me how I know). 

That is also why the aviation answer does not save us. Hand flying works because flying is stable and repeatable and can be practised on its own. Judgment is not like that. Judgment only exists against the specific situation in front of you, and in an agentic workflow the "agentic system" gets to that situation first and returns a verdict on it before you ever engage with it. There is no drill you can run afterwards, because the case you would have practised on has already been closed.

Think about how dangerous that is for a minute. 

It reminds me of during covid back in 2020 when I put out an article warning people about building a safety critical system without the necessary knowledge of safety systems and tried to share a bit of safety critical mindset when designing such systems, I wrote that article for FreeCodeCamp How to Improve Your Arduino Ventilators: Intro to RTSs and SCSs for Makeshift COVID-19 Ventilator Designs and it got taken up by Hackaday Making An Arduino Ventilator? Read This First | Hackaday. Sometimes I wonder if having AI in that era would have produced better designs, or just lowered the bar for more people to build poor quality ones. 

All in all, with a "I can do the work for you button" existing, it makes teaching the fundamentals harder, which is the answer Jacob is building and which I think is correct and necessary, will not be enough on its own. Picture the engineer who goes through a good programme, learns properly, and is then dropped into a "spec in, proof out" "no knowledge necessary" loop for three years. Nothing in that loop ever asks him to commit a position, he reviews well built arguments and approves them, and he is sharp on day one and quietly less so on day nine hundred. The danger with this is that nothing anywhere in his organisation registers the change, because the loop kept producing correct output the whole time. The decay happens in the workflow, so  my humble suggestion is that the fix has to live in the workflow.

What It Looks Like On The Agentic Loop

Take that ten stage wheel, since it is the best articulated version of the pattern out there and there is no point testing a method against a weak example.

Before the change gets implemented, you commit what the change should be. Not a full implementation, just the shape of it, which register you expect to touch, or part of the system you plan to build or modify and what approach you expect to take. That will take you 90 seconds, but will over time build intuition that will last you 90 years. 

Before the console gets read and the waveform gets captured, you commit what they should show. Write down the edge you expect, the timing you expect, the value you expect in that register.

Then look. I mean LITERALLY use your own brain and thoughts and look.

Despite large AI companies wanting to make intelligence into a commodity we pay for, you already have cognition and intelligence, for free, that runs on a cup of coffee as opposed to gigawatts of power, and doesn't cost a dime. This one matters more than the other two put together, because a prediction committed before the trace appears is the closest thing to real hardware intuition that a tethered workflow can preserve. Because the surprise is, when you are wrong, it still lands exactly the way it always did at three in the morning and builds up your "mental toolbox". That way not only the machine has skills but you have skills also.

My take is that use your own brain power whenever you can because it builds experience, but if you are one of those in favor of agentic workflows, before the agent fixes what failed, you commit a diagnosis. Whatever the acceptance criteria caught, you say what YOU think caused it before the agent tells you. Three tethers on a ten stage loop, costing maybe five minutes inside a cycle that otherwise runs for an hour while you do something else. That way we get "spec in, proof out" but the engineer intact, so that in 100 years from now when the guys like me are all dead and gone, engineering of embedded systems won't be a lost art that only machines understand. Or worse, stagnant. You see if you don't do the work yourself, you dont get experience. experience brings insight and cumulative insight and methods are what propel a field forward.

The Part That Makes It Engineering And Not An Opinion

Everything above is an argument, and people have been making arguments about deskilling for forty years without ever producing an instrument. What makes this worth building rather than just writing about is that a tether throws off an artifact for free, as a byproduct of normal work.

Every tether produces four things: 

1. The position you committed.

2. The position the agent produced.

3. The divergence between them.

4. How the disagreement got resolved.

Log that and you have a record doing three jobs at once. It is an audit trail showing a human applied judgment at consequential points, which is going to matter enormously the first time a certification body asks who actually made a decision inside an agentic workflow, and if you work anywhere near safety critical firmware you already know that question is coming. Even if you're building your own thingamabobs at home, ask yourself, are you building it because you want to learn and get the accomplishment of understanding how it works? or are you just building to solve a problem? 

In industry its different. The goal is ship, ship.ship. Profit matters more than what the engineers understands and from the perspective of a CEO or marketing department and the paymaster, they don't care if the engineer knows or not.

Ship it now.

The engineer is there mostly to point fingers at when it fails and it will be very embarrassing to go to court as an expert witness for your company or yourself and you are unable to explain how the thing you built works. To make it worse imagine being crossed by someone who DOES understand how these systems work and puts questions to you that you are unable to answer, or even having to work with another engineering team or contractor from another company who does. Funny thing is I had a similar experience less than two weeks ago with someone who did not have a clue about the system they supposedly built and is responsible for, I knew more about it than him! and I only had an hour with it!

Let me tell you, if you meet a guy like me who loves building and you push the "build it in 2 minutes button" and dont have a CLUE what's going on inside there, you will walk out of that room without a professional leg to stand on. When you walk out, the same marketing team of manager pushing you to ship faster with "AI" will recuse themselves from the technical bits because as an engineer that's your job. 

Before I wrap this up I want to say this. Even if we do build up agentic systems, and you do use them, I'm advocating that we treat it as a personal training corpus made up entirely of the cases where your model of the system was wrong. I would argue that is the highest value study material that exists and which right now nobody captures at all. And it is a portfolio, which is the part that matters most to somebody in my position, because a log of calls you made before the answer was visible proves far more about you than any amount of shipped code that an agent may or may not have written. When I come in as a contractor or consultant or to help you finish your project, that will matter to me a lot more than being forced to read something that you won't read yourself. 

The divergence is the piece I care about most, because it is a number, something you can actually write down and measure. Track it across months and you can tell the difference between the engineer whose predictions are converging on reality and the engineer whose output is climbing while his predictions drift further off from reality. You can do that without an assessment event, a certification body, or a manager's impression of anybody to be honest. Right now the worry about competence in the agentic era is a "vibe". Divergence turns it into a reading.

Where This Goes

Over the next month or so, I plan on writing the specification up properly and putting it on prepublish site with a DOI, and the record schema and a reference implementation are going up open source, because a methodology with no specifiable format and no tool is an essay with headings and I have read enough of those, and frankly I'm tired of them especially in our "generate an article in 10 seconds" era, I see guys claiming to have written books in a single day while I take months to finish a title. But, if the format is open then anybody can emit tether records, including people building tools who have never heard of me, and divergence becomes something you can measure across an industry rather than inside one company's product. I think it's something that will benefit the most silent and ubiquitous part of society our embedded systems. Microcontrollers are like spiders, you're always a few feet away from one, you just don't know it and even the more powerful SBCs are becoming more prevalent. 

The thing that decides who gets to be in this field is not elegance and it is not pedigree, it is access, and what I am trying to protect here is the one route into embedded systems that was ever open to somebody from a place like mine. You could not buy your way in and nobody was going to hand you a job on a name, but if you understood the machine well enough to prove it, that counted, and it counted everywhere.

Competence. 

I am not willing to watch that get automated away one convenient stage at a time, least of all from the people who are only now getting close enough to reach it.

Armstrong Subero is an embedded systems engineer and published author with Apress/Springer. He builds the Rovari RISC-V education platform from Trinidad and Tobago.