Author Topic: Using Claude Code for embedded work  (Read 26219 times)

0 Members and 3 Guests are viewing this topic.

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 517
  • Country: gb
    • Me
Re: Using Claude Code for embedded work
« Reply #250 on: June 10, 2026, 07:41:25 pm »
OK, I had another go with this today, using LM Studio and gemma4-31B. After a lot of messing about with libraries, and it putting files in wrong directories, and various compilation errors due to type mismatches, I did finally get it to work (taking about an hour of interaction). One thing I dont like with the way the model responds is that often it "checks" its solution, and goes off at a tangent "fixing" things unrelated to the user's request. Ultimately, whether the code is correct is simple to visually check in such a simple case as this, but it becomes a matter of faith as to whether the code is correct or reliable in other cases. In my book this is not really satisfactory in an engineering context....

Question for all of you AI coding fans there - would you be prepared to sign off a design generated by an AI, if you would be held personally liable for any consequences (e.g. your licence to practice being revoked, etc).
 

Online SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 416
  • Country: gb
  • Aging physicist
Re: Using Claude Code for embedded work
« Reply #251 on: June 10, 2026, 08:05:23 pm »
To be honest, that sounds like you familiarising yourself with a new tool. No knowledge comes free, there's always a price to pay. Engineering is the art of paying cheaper prices for more value.

As for your last question, I've left Apple now, but I have friends there still. It's now a "friendly chat with your manager" if you're *not* using AI to help your daily workflow. Those chats often get less and less friendly as time goes by, if "progress" is not being made...

Edit: on re-read, you’re trying to do this with a local LLM. The gap between local models and frontier (subscription, cloud-based) models is ‘significant’. In the same way as the Grand Canyon is ‘deep’. Note that it took me 5 minutes with Claude, using *your* prompt.
« Last Edit: June 11, 2026, 06:16:21 am by SpacedCowboy »
 

Offline mzzj

  • Super Contributor
  • ***
  • Posts: 1376
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #252 on: June 10, 2026, 08:07:32 pm »
OK, I had another go with this today, using LM Studio and gemma4-31B. After a lot of messing about with libraries, and it putting files in wrong directories, and various compilation errors due to type mismatches, I did finally get it to work (taking about an hour of interaction). One thing I dont like with the way the model responds is that often it "checks" its solution, and goes off at a tangent "fixing" things unrelated to the user's request. Ultimately, whether the code is correct is simple to visually check in such a simple case as this, but it becomes a matter of faith as to whether the code is correct or reliable in other cases. In my book this is not really satisfactory in an engineering context....

Question for all of you AI coding fans there - would you be prepared to sign off a design generated by an AI, if you would be held personally liable for any consequences (e.g. your licence to practice being revoked, etc).
From everything what I have read local LLM's are maybe same level as cloud services 3 years ago. Not worth my time, you need to be LLM enthusiastic who is interested to fool around with the tools instead of actually doing something usefull. 
 
The following users thanked this post: Siwastaja, woofy

Offline uer166

  • Super Contributor
  • ***
  • Posts: 1263
  • Country: us
Re: Using Claude Code for embedded work
« Reply #253 on: June 11, 2026, 05:42:14 am »
OK, I had another go with this today, using LM Studio and gemma4-31B. After a lot of messing about with libraries, and it putting files in wrong directories, and various compilation errors due to type mismatches, I did finally get it to work (taking about an hour of interaction). One thing I dont like with the way the model responds is that often it "checks" its solution, and goes off at a tangent "fixing" things unrelated to the user's request. Ultimately, whether the code is correct is simple to visually check in such a simple case as this, but it becomes a matter of faith as to whether the code is correct or reliable in other cases. In my book this is not really satisfactory in an engineering context....

Question for all of you AI coding fans there - would you be prepared to sign off a design generated by an AI, if you would be held personally liable for any consequences (e.g. your licence to practice being revoked, etc).

 :horse:, the AI is a tool, I feel comfortable signing off on something that it generated during a session of me using it as a tool and doing the requisite reviews/tests/checks. It's no different than writing code on your own and you doing the due diligence to verify and validate the system really.

Now would I be comfortable giving it a prompt, getting 3000 LOC of code, and signing off on that as black box code? At this moment in time of course not! It's like giving an intern or junior engineer a task and blindly accepting their work for something critical. Note that also, there is generally no "software engineering license", you're almost never personally liable when you work for an LLC; it doesn't mean that any less due diligence is required, this is only to comment on the above statement about the possibility of losing a license.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 11016
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #254 on: June 11, 2026, 07:11:22 am »
OK, I had another go with this today, using LM Studio and gemma4-31B.

So you found out the same as everybody else - tiny local models are not good for complex real-world programming tasks involving multi-step reasoning, complex tool use, researching library options, etc. Note the size difference - this is roughly 1/100th of what people actually use to do programming.

It's equivalent to putting a 1 horsepower engine to a car and then wondering why the car doesn't move, and instead of getting a normal car everyone uses to do car things, ridicule car fanboys. Great for agenda - not so great if you want work done.

The cost for frontier models is so small (e.g. $100 / month for Claude) that of course you would want to maximize the available capability, because your time as a programmer is worth much more.

Quote
would you be prepared to sign off a design generated by an AI, if you would be held personally liable for any consequences

Of course, with the same caveats as signing off work done by humans - so far everything I have seen points to much lower rate of errors than any human being who have worked for my projects. It's still non-zero, of course, and to be taken as seriously as always before, no change there, except that now we can afford being more careful as we are wasting less time to micromanage and correct the huge amount of human errors large part of which are nearly gone.

Taking responsibility of something you didn't do completely yourself was always scary and tricky, and remains so.

The problem isn't mainly in reasoning errors or bugs, but rather, hidden higher-level assumptions and ideas the worker (AI) thought would be a good thing to hide somewhere within the code. Some weird conditional mode somewhere, reasoned and implemented in a locally coherent way, but something which you didn't want in the bigger picture. But this also isn't some new weird failure mode, but what human workers also do.
« Last Edit: June 11, 2026, 07:21:30 am by Siwastaja »
 
The following users thanked this post: woofy

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 6284
  • Country: nz
Re: Using Claude Code for embedded work
« Reply #255 on: June 11, 2026, 07:25:38 am »
The cost for frontier models is so small (e.g. $100 / month for Claude) that of course you would want to maximize the available capability, because your time as a programmer is worth much more.

Why am I hearing about either

1) you've used all your tokens, go away for 6 hours, OR

2) companies spending more on Claude than on salaries.

?
 

Offline uer166

  • Super Contributor
  • ***
  • Posts: 1263
  • Country: us
Re: Using Claude Code for embedded work
« Reply #256 on: June 11, 2026, 07:38:16 am »
The cost for frontier models is so small (e.g. $100 / month for Claude) that of course you would want to maximize the available capability, because your time as a programmer is worth much more.

Why am I hearing about either

1) you've used all your tokens, go away for 6 hours, OR

2) companies spending more on Claude than on salaries.

?

If I were to guess based on personal work experience:

1) People who have no business doing software development using agentic loops to attempt to have the LLM develop a full "working" black box solution, instead of taking it a step at a time and architecting it.

2) Exactly same issue as #1, except with companies that have unlimited tokens credits that get charged as-you-go.
 
The following users thanked this post: Siwastaja, paulca, 5U4GB

Online peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 5919
  • Country: gb
  • Doing electronics since the 1960s...
Re: Using Claude Code for embedded work
« Reply #257 on: June 11, 2026, 07:42:48 am »
Quote
you've used all your tokens, go away for 6 hours, OR

Either free Claude does that more and more, or my free one is jealous that I am using mostly the £150/year one ;) Because it has suddenly got very tight.

The 150 quid one is very good, Opus 4.8 on High setting. It has just done a ton of graphics code, and it is actually very good. In 2 days I managed to do a few weeks' work.

I had to top it up with £35 just once, yesterday.

I suspect uploading jpeg pics of the LCD uses up a lot of money.

I managed to get the code display on the RHS but still no solution to the black-highlighted function names posted earlier. The config UI is crap.

This was done in a few hrs of me working with it



and the code is almost as good as I could have written it. Anyway, 95% of the time is the SPI speed bottleneck. It's all done in floats, too.
« Last Edit: June 11, 2026, 07:51:44 am by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 11016
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #258 on: June 11, 2026, 07:48:03 am »
The cost for frontier models is so small (e.g. $100 / month for Claude) that of course you would want to maximize the available capability, because your time as a programmer is worth much more.

Why am I hearing about either

1) you've used all your tokens, go away for 6 hours, OR

2) companies spending more on Claude than on salaries.

?

I also don't get it. Seems like some mythological creature - I have also heard about it, but can't see it. I haven't hit the usage limit at $100/month tier, not even once, and I often work with the thing the whole day, and sometimes leave it doing some stuff unsupervised for the night. And I still have the $200/month fixed-price tier to go to, which gives 5x the usage, which seems like a ridiculously huge amount given that I can't apparently hit even the 5x smaller limit. (The even 5x smaller limit from the $30 tier I did hit quite easily.)

I am truly baffled what people do to hit the limits on the $200 tier, or pay tens of thousands for pay-per-use (API cost). Probably some farm of tens of agents doing uncoordinated, unsupervised throwaway work 24/7. If so, their own fault. Like, if that's what you want, then why not - do it, and pay for it? It's an expensive brick wall to bang your head on, though.

In any case, this doesn't make any sensible argument for local inference. If your problem is that you don't get enough compute from Anthropic, then doing the same in your own hardware would have cost closer to hundreds of thousands - and significant energy cost, too. Those complicated multi-agent workflows are especially those that need the most capable models; in fact I suspect the whole reason people waste resources doing throwaway work is that even something like Opus 4.8 simply isn't good enough yet to do large unsupervised agent farm projects properly.

Local inference would be the sweet spot for low-complexity but high duty cycle tasks - something which uses relatively little compute (not Claude-level), but use that all over the clock.

Looking for local inference to save money would be probably the most ridiculous idea one could have. Other reasons - data security, research on AI, hobby, general interest, availability you can control - seem much more viable, but high cost and/or low model quality are tradeoffs you need to accept.
« Last Edit: June 11, 2026, 08:00:57 am by Siwastaja »
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6214
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #259 on: June 11, 2026, 08:23:14 am »
How do you spend $600 in a single day?

Easy.  Use a corporate "Agentic OS" to do a non-benign ticket.

They tend to start by reading the Jira ticket, then launching parallel analysis agents for each related ticket/epic.  Each produces a summary.  The agents output is then compared by another agent and used to produce a description of the work.

A dozen parallel agents are then send off to analyse the code base, pull in strategically placed documentation, produce analysis docs for claude.

When they get back, the planning agents start up.  Probably multilples.  Producing different plans, which are then again, run through more "compare, review, contrast" and "pick" parallel streams.

and so on and so forth.

Multiple parallel sub loops of "Analyse, Decide, Do, Review".

The output is a pull request.

What do you do?  Review it.

What if you don't like it?  At the moment, they honestly expect you to go back to the start and run the whole loop again.

"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 
The following users thanked this post: Siwastaja

Online SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 416
  • Country: gb
  • Aging physicist
Re: Using Claude Code for embedded work
« Reply #260 on: June 11, 2026, 09:15:43 am »
I also don't get it. Seems like some mythological creature - I have also heard about it, but can't see it. I haven't hit the usage limit at $100/month tier, not even once, and I often work with the thing the whole day, and sometimes leave it doing some stuff unsupervised for the night. And I still have the $200/month fixed-price tier to go to, which gives 5x the usage, which seems like a ridiculously huge amount given that I can't apparently hit even the 5x smaller limit. (The even 5x smaller limit from the $30 tier I did hit quite easily.)

I am truly baffled what people do to hit the limits on the $200 tier, or pay tens of thousands for pay-per-use (API cost). Probably some farm of tens of agents doing uncoordinated, unsupervised throwaway work 24/7. If so, their own fault. Like, if that's what you want, then why not - do it, and pay for it? It's an expensive brick wall to bang your head on, though.

I think it depends on what you're doing. I have (infrequently) met the $200/month limit, but only on the last day of the week. If I have 4 or 5 concurrent tasks going, I can sometimes hit it, depending on the tasks. For example this week, I:

  • had it working on the arm64 side of the xtc compiler, making it write code in C/C++ and cross-bench it with xtc, then examine the assembly to see if could deduce generic rules for what to do better
  • had it working on the hardware side of the 6502 system, currently rewriting the blitter to minimise the DRAM fetches in order to show a hardware-composited display rendering across 4 levels (UI, XT overlay, ST overlay, mouse/sprites)
  • am building a two-story garage/workshop, and wanted it to write a report for the building inspector and builder about how to optimised the second-story roof for headroom inside, contrasting things like warm-roof / cold-roof / truss support / steel vs wood / lowered-floor etc.
  • have built a roll-off-roof observatory, and I wanted its take on how to automate the rolling aspect, linear rails with linear actuators won out over garage-door-opener-style or chain-drive because of the geometry of the roof
  • other, smaller jobs. I tend to just "ask Claude" if I'm not sure about something these days

I have these running concurrently  - I usually do one Claude session per virtual desktop, and I have about a dozen virtual desktops on the main display right now :)

Now usually that would have pushed me into the 40-50% usage by this stage of the week (mine refreshes every monday). I rarely leave it unused during the day, and often (at least 4 nights a week) I go through the "I'm going to sleep, I want you to push through any times you would usually pause unless its absolutely critical" dance to get it to do some work for me overnight as well. As it happens this week is one of the (seemingly many, recently) times that Anthropic has released something new, so my usage totals got reset to 0, and I'm only at 14% used.

So it's possible, but I think only if you're really pushing it. I'm not shy of throwing JPGs at it either, a lot of the time debugging the display that the hardware produces means taking a photo, highlighting the bit I'm concerned about and dropping it into the console with a question.

Anyway, I'm about to swap over my two large PCs in the corner (one running windows, one running linux) to a Minisforum MS-A2 that can fit under my monitor, to the side of the KVM. I asked Claude about it all, obviously, so I'm confident that Altium and Electra can run under Windows via Proxmox, meaning I can have everything up and available, on faster CPUs, in something the size of a mac-mini...
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 11016
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #261 on: June 11, 2026, 09:26:00 am »
They tend to start by reading the Jira ticket

That's where everything starts to crash already. We never got Jira tickets working. The vision, the experience, the gist disappears when you ticketize a complex real-world issue. It's a one-way information flow which prevents people from communicating. Then comes some who starts to write code, blind, based on infromation on ticket alone. Jira's bugginess and poor UX is just a cherry on top - doesn't actually make it significantly worse, but makes you hate your life even more, underlining the futility of writing and implementing Jira tickets.

Humans implementing these "Jira tickets" results in a serious disconnect from actual project reality (what the customer actually wanted and needed?), so result is some random hallucinated piece of crap software component everyone hates and which remains a liability for the next 30 years. After 100 more bugfix Jira tickets, it works well enough it can be forgotten. Until it bites again.

Replacing the human in that process (but keeping the broken process!) with something 20x faster and 20x more "productive" is scary!

What you actually needed was: chat with the damn Claude, discuss the problem together while implementing it. The core strength is exactly that it's ~always present (you don't have to sync calendars to find an hour to discuss).

And the idea of increasing AI quality by increasing number of parallel workers working on the same problem is exactly the "infinite number of monkeys" response. It's the "too many cooks spoil the broth" case. Why do we want to do that mistake deliberately?

Huge Anthropic bill is just a warning sign. The problem is not Anthropic being too expensive, or AI inference being too costly. It's people using AI to do the same mistakes they already did with human beings, but now on steroids.

Do I have an actual solution to propose? No, except, maybe smaller is better. Let small startups with less legacy development process weight/debt do their magic with AI. This paradigm shift saved us. We were a small company using enterprise processes because someone thought Jira tickets give us strength. In reality it sucked all the energy from us. Chatting with Claude and letting it do what needs to be done, commit to git and deploy saved us. Now it's normal sensible co-working again instead of Jira tickets, one of the workers is a machine, but it behaves more humanly than many human workers.
« Last Edit: June 11, 2026, 10:33:58 am by Siwastaja »
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6214
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #262 on: June 11, 2026, 01:00:10 pm »
Do I have an actual solution to propose? No, except, maybe smaller is better. Let small startups with less legacy development process weight/debt do their magic with AI. This paradigm shift saved us. We were a small company using enterprise processes because someone thought Jira tickets give us strength. In reality it sucked all the energy from us. Chatting with Claude and letting it do what needs to be done, commit to git and deploy saved us. Now it's normal sensible co-working again instead of Jira tickets, one of the workers is a machine, but it behaves more humanly than many human workers.

I think the problem they are trying to solve is not a lot of "two men teams", claude+dev, what they are trying to do is create "shared" workflows.  Re-usable workflows.  Interconnection between multiple 6-9 member teams in the same project etc.

The issue I see is, this is an endeavour seeking consistent output when the technology is categorically incapable of such by design.  The more you add, the worse it gets not better.  Compounded "losey" summary of summary.  Inattention in the middle and all that stuff.

Anthropic for their part certainly aren't stopping their attempts though.  They are supporting it through and through, feeding them even more expensive ways to spend tokens faster.

People are almost gloating in work.  A higher token count = clearly you are busy.  A low token count and ... they are going to start asking me "What are you doing?".  However, there is hope that when the former finally get through honeymoon and start to question, they are in a good position to start "making bills" until the milk soars.  So to speak.  There are emerging examples of "resistence" to AI in some rather interesting places.  Aka:  Use the tool, make it expensive, allow the output to be bugged/rubbish, blame the AI, say they were complying by using it as instructed.

Asides:  3blue1brown has a new series on YouTube.  In the first part he touches on a premise that "Information Theory" through LLMs is starting to ask, "Is compression intelligence?"

The ability for a brain to "compress" information accurately into a memorisable form, requires understanding the actual meaning of it. This is very co-adjacent to LLMs and some of their "latent space" behaviours.

Fascinating stuff.

One thing though....

In work, when they propose (and they are), that ALL tickets must be run through the "Full LLM Agentic Loop"... I am going to ask one simple question:

"Can I have a claude user account on GitHub so that claude pushes code as claude and does not have my name on it?"
That will get attention.
« Last Edit: June 11, 2026, 01:09:07 pm by paulca »
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 30021
  • Country: nl
    • NCT Developments
Re: Using Claude Code for embedded work
« Reply #263 on: June 11, 2026, 03:18:57 pm »
One thing though....

In work, when they propose (and they are), that ALL tickets must be run through the "Full LLM Agentic Loop"... I am going to ask one simple question:
If that means getting rid of tickets which are incomplete (or can not placed into any meaningfull context), that would be a good thing. In my own experience I see Jira backlogs being filled with tasks which are actually mental notes. On their own these mean very little without knowing their context. A first iteration of AI would be to come up with a decent task description (input / output), local context and validation within the big picture which then turns into an actual task or gets discarded.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 11016
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #264 on: June 11, 2026, 04:32:12 pm »
One thing though....

In work, when they propose (and they are), that ALL tickets must be run through the "Full LLM Agentic Loop"... I am going to ask one simple question:
If that means getting rid of tickets which are incomplete (or can not placed into any meaningfull context), that would be a good thing. In my own experience I see Jira backlogs being filled with tasks which are actually mental notes. On their own these mean very little without knowing their context. A first iteration of AI would be to come up with a decent task description (input / output), local context and validation within the big picture which then turns into an actual task or gets discarded.

That would be clean-up of a mess; a valuable thing, sure, but you need to correctly recognize it's about cleaning up a mess, not some kind of pinnacle of good development process.

The whole issue with that backlog of mental notes is that it lost all that valuable information: what the ticket author was actually thinking when they wrote it. Unfortunately, part of that lost information is so deeply lost that even best of AIs, or even best of human beings, cannot recover it. This leads to exactly what I described above: blind "implementation of tickets", instead of solving the actual problem.

The necessary information can be extracted by process of interrogation: chatting. Works with humans and AI.

Good mental notes / tickets are something no one can decipher; possibly not even the original author of the note / ticket. They act as crude reminders only, not specifications. That forces going through the actual design work. For which getting together, chatting and implementing together is some of the best forms. Works with humans, works with AI. Humans are present with maybe 15-30% duty cycle, AI is at 99% duty cycle. One of the key distinctive feature of successful startups was that they always consisted of enthusiastic workaholics doing long days, basically, near 40-50% duty cycle. Small teams, high concentration, minimization of processes, maximization of payload workflow. Implement NOW, not later. Implement yourself, if possible; handing out work is inefficient and difficult.

AI is perfect force multiplier; handing out some tasks to it is much easier to handing them out to most human workers.
« Last Edit: June 11, 2026, 04:33:51 pm by Siwastaja »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 30021
  • Country: nl
    • NCT Developments
Re: Using Claude Code for embedded work
« Reply #265 on: June 11, 2026, 05:57:14 pm »
Question for all of you AI coding fans there - would you be prepared to sign off a design generated by an AI, if you would be held personally liable for any consequences (e.g. your licence to practice being revoked, etc).

This is the same question as 'would you signoff work created by an intern'. But your question also implies 'without checking'. No professional should allow him/herself to sign off on work which hasn't been checked one way or another. Using AI or delegating work doesn't change that.

However, AI can also make a huge difference where it comes to testing. As I'm typing this, Claude is testing firmware for me with hardware in-the-loop while collecting data and creating summaries as it goes along. Based on test cases I provided and test cases Claude added, the testing itself is very thourough and even uncovered some edge cases. BTW, I'm using one Claude session for development / bug fixing and one session for testing. I'll probably add more test cases once the project reaches a more mature stage but once those are in place and all tests are completed succesfully, I have a very high confidence the product will work in the field.

« Last Edit: June 11, 2026, 06:02:15 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Siwastaja, SpacedCowboy

Online peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 5919
  • Country: gb
  • Doing electronics since the 1960s...
Re: Using Claude Code for embedded work
« Reply #266 on: June 12, 2026, 02:39:24 pm »
How do you get Claude to see the result?
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Online SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 416
  • Country: gb
  • Aging physicist
Re: Using Claude Code for embedded work
« Reply #267 on: June 12, 2026, 02:59:21 pm »
For me, I just link it up to a serial-out. There's enough stuff printed out that it can tell what's working, where it failed, and it knows the context of what was just altered, so...
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 30021
  • Country: nl
    • NCT Developments
Re: Using Claude Code for embedded work
« Reply #268 on: June 12, 2026, 03:51:47 pm »
How do you get Claude to see the result?
It reads the status over SSH through a tool which can get data from the software and by reading the log files. More precise: Claude created a testbench using Python (based on the pytest framework) which executes the actual tests. Claude interprets the summary once the tests are done. But Claude can also go through the results to answer questions about why certain things have failed and the surrounding conditions.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6214
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #269 on: June 12, 2026, 04:17:17 pm »
Remember kids.  :P Making it work is the easy part.  Proving it works...  that takes you start before you begin to write it.

I would suggest that is how you tackle these LLM code agents.  Start with "proof" work backwards.
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 11016
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #270 on: June 12, 2026, 06:48:25 pm »
Remember kids.  :P Making it work is the easy part.  Proving it works...  that takes you start before you begin to write it.

I would suggest that is how you tackle these LLM code agents.  Start with "proof" work backwards.

Proving something works probably benefited the most from AI/LLM, because it's a lot of hard work, including a lot of scaffolding, tooling, test scenario setup, whatever you call it - and that's exactly what LLM coding agents shine at. So even if we didn't want to let the AI to assess its own results and pass its own work, or even do the actual payload work at all, it would be still tremendously helpful - then the trusted magical human would write the actual code, and another trusted magical human analyze the results, with the heavy lifting of tooling setup and analysis tools being made much easier.

This is the quality increase, rather than speed increase, I am seeing with AI. Not only it makes fewer bugs and mistakes than most human programmers, it's excellent for increasing test coverage and visibility into systems. Ask for any custom special tool, say, a data visualizer which reads your logs and emphasizes the important things, you get it in minutes.

Really the thing to be careful with is letting it do architectural or algorithmic design choices without checking and direction. State-of-the-art AI is not yet ready for that completely on its own. It sometimes surprisingly succeeds, sometimes not.
« Last Edit: June 12, 2026, 06:52:09 pm by Siwastaja »
 
The following users thanked this post: nctnico, uer166

Online peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 5919
  • Country: gb
  • Doing electronics since the 1960s...
Re: Using Claude Code for embedded work
« Reply #271 on: June 12, 2026, 08:46:32 pm »
Quote
I just link it up to a serial-out

So you have a prog which accepts RS232 or whatever, and sends it to Claude as emulated keyboard input?

Quote
Really the thing to be careful with is letting it do architectural or algorithmic design choices without checking and direction

Indeed. I am finding that I need to give it "top level" direction. It doesn't really get the big picture, but then one could argue it was never given it :) I am very happy using the tool for generating specific functions.
« Last Edit: June 12, 2026, 08:48:14 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 30021
  • Country: nl
    • NCT Developments
Re: Using Claude Code for embedded work
« Reply #272 on: June 12, 2026, 09:20:26 pm »
Quote
I just link it up to a serial-out

So you have a prog which accepts RS232 or whatever, and sends it to Claude as emulated keyboard input?
Not as emulated keyboard input / output. Claude will just write a harness using Python or use a tool like minicom to talk with whatever is attached to the serial port. From there it will analyse the output versus input.
« Last Edit: June 12, 2026, 09:25:08 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6733
  • Country: nl
Re: Using Claude Code for embedded work
« Reply #273 on: June 15, 2026, 09:00:52 am »
Enjoy AI while it lasts

 

Offline uer166

  • Super Contributor
  • ***
  • Posts: 1263
  • Country: us
Re: Using Claude Code for embedded work
« Reply #274 on: June 15, 2026, 09:07:51 am »
Enjoy AI while it lasts



I've seen that video, but I'm not really worried as a user, even $15k a month can be a steal for a professional SWE. If anything it'll weed out wasteful usage for no good reason which should happen anyway, the current prices are crazy low given the resource hog that it is.

The real reason that I'm not worried though is that those huge token counts are often the result of agentic loops as discussed, even local models that I can run on my PC prove to be quite useful for embedded development (though not nearly as comprehensive as Claude Sonnet, FWIW I have never tried Opus yet).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf