Using Claude Code for embedded work

[Siwastaja]

Enjoy AI while it lasts

Nah, usual horror story. 15k worth of usage is the top 0.1%. Equivalently, bottom 20-30% or even more pay but don't use it at all. All that matters is the average, and my gut feeling, which is 100x better than that random youtuber, is that Anthropic pricing model is pretty sustainable here, at least compared to some competitors who give access to their largest models for even cheaper than $100-200 per month.

And those API rates, which create those huge 15k bills for those who don't care as they can afford to pay, surely includes a decent profit - exactly because companies who don't care are willing to pay.

The "I only pay $200 and used $15k worth" is a fallacy. How do they know what their compute actually is worth? Probably closer to $5000 than $15000. And then most others don't use it like that (throttled against usage limit 24/7/365)

[peter-h]

Yes this is nonsense, for code development.

The sort of level I am seeing, if using Claude flat out 8hrs/day, might be 1k/year.

I've found that image and PDF uploads really eat up the money, maybe 10x faster than just having it generate code.

[Dazed_N_Confused]

I've found that image and PDF uploads really eat up the money, maybe 10x faster than just having it generate code.

 Why upload anything? Claude Code via terminal works on your local machine/folder. You just need to setup a read PDF MCP server, or am I missing something.

[Siwastaja]

I've found that image and PDF uploads really eat up the money, maybe 10x faster than just having it generate code.

 Why upload anything? Claude Code via terminal works on your local machine/folder. You just need to setup a read PDF MCP server, or am I missing something.

You are missing the fact peter-h is unwilling to use Claude Code, because it won't run in deprecated Windows 7, which peter-h is unwilling to update.

Using an agent which can edit the code instead of copy-paste or upload/download cycles, run commands instead of copy-pasting the commands, is the huge leap in capability peter-h is still missing.

[peter-h]

You are missing the fact peter-h is unwilling to use Claude Code, because it won't run in deprecated Windows 7, which peter-h is unwilling to update.

No, you are missing the fact that by choice I use Claude for self contained functions, with a defined interface and behaviour, because I keep control of the overall architecture myself.

The copy/paste from the "code terminal" window on the RHS of the screen is trivial.

Win7 is nothing to do with it. As I write this, I am using a win10 PC for running FreeCAD, for example.

[Siwastaja]

because I keep control of the overall architecture myself.

That's another, orthogonal question. By giving Claude access to your files and tools - including it ability to write tools and execute them - you can do fancy stuff like nctnico mentioned:

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.

If you want to control the overall architecture, then do that. Don't ask it to redesign your architecture. Let it discover what your architecture is and work within it - no special prompting needed, this happens automagically.

That's the whole reason to use AI agents - you think it's "fast" to copy-paste between the LLM and your computer, but it's REALLY REALLY slow, it only feels fast to you because you limited the amount of what Claude sees and what it can do to match your copy-paste pattern.

If you let it look directly, it can do 50 look-ups within 5 minutes on its own. Having AI request you to copy paste results back and forth for 50 times gets old really quickly, and models understand this, so they try to work around; they ask you to copypaste less, they try to work blind. They have to assume because you are denying them access to your work. It's exactly analogous to hiring a worker to whom you don't give an access to your code, and not even a computer.

But worst of all, and THIS is what you are missing: your AI is of much lower quality, equivalent to ~2 years back in development: you are basically downgrading the model by not letting it check, so it has to assume.

If you try a modern AI like Opus 4.8 in a modern harness like Claude Code and ask it to do a mundane thing, you can see it is verifying its assumptions even if you don't ask - it's doing spot reads on your codebase, it's running tools to see how they are used, doing a small test run first, reading the result - just like a sensible human being, with access to a computer and the project files, works. The result is: a huge reduction in number of mistakes. And it finds the solution by itself in a few minutes. No copy-pasting back and forth.

[nctnico]

I second the recommendation to use Claude code locally. Just make sure to have the project in Git so you can revert back or create a branch just to try things. Claude knows how use Git like Liberace knew how to play the piano  Using Claude locally give Claude the ability to understand your project and give solutions which fit the project. Nevertheless, Claude can miss things so it is important to start in plan mode and execute once the plan is to your liking. And sometimes it takes going back & forth a few times. If that starts to go in circles, it it time to intervene and steer Claude firmly into a certain direction. But even then, you'd have to write very little code yourself and have you mind available for the tough problems and keeping track of the architecture.

[Dazed_N_Confused]

   skill.md and mcp servers are the key.  Skill file tells it to retrieve info only from for example a certain datasheet.

[abeyer]

If you want to control the overall architecture, then do that. Don't ask it to redesign your architecture. Let it discover what your architecture is and work within it - no special prompting needed, this happens automagically.

That's pretty optimistic in my experience... it's been equally likely without (and occasionally even with) prompts/instructions to the contrary to attempt to significantly re-architect a system to support some new feature requested if it gets stuck doing so without.

[Siwastaja]

   skill.md and mcp servers are the key.  Skill file tells it to retrieve info only from for example a certain datasheet.

Actually MCP is secondary - the first step is the tool use. Command line tools cover nearly everything. Compared to that fundamental addition of tool calls (arbitrary shell commands), MCPs just enable a small subset of some remaining access types which are hard, inefficient or impossible through command line tools: for example, opening a web page in an actual web browser, and moving a virtual mouse cursor in that web browser, which could be important e.g. when testing/debugging a specific web UI; possible to theoretically do over command line, but that would be cumbersome, so MCPs were invented to close this gap.

But the key - no, I disagree, compared to the fundamental concept of running commands / tools on your computer, what peter-h is missing, MCPs are just the final cherry on top. For example I still haven't found any use to set any MCP up, but that depends heavily on what you are exactly doing, some will find that email / calendar integration or direct browser control through MCP are important for their use cases.

But for example, Github or AWS integrate just fine through their command line tools, which any developer using them "seriously" would have installed anyway.

[peter-h]

Some people like to turn forums into a personal pissing contest. I have a shop near here, just right for them



I've developed literally hundreds of products, micro based since c. 1980. None of them were buggy. All worked and some even made money. We all have ways of doing stuff and ways to use tools at our disposal.

[paulca]

Some people like to turn forums into a personal pissing contest. I have a shop near here, just right for them



I've developed literally hundreds of products, micro based since c. 1980. None of them were buggy. All worked and some even made money. We all have ways of doing stuff and ways to use tools at our disposal.

The "It works for me", does not however give you any credence to "pissing" on other tools and techniques you have never tried.

The "How do I do this?", provided with, "You could try this industry standard OS, Tooling, Workflow and Methodology." being replied to with, "Gosh, no, I know better than that!"

I come back to a simple premise.  If you have tried claude code properly, then we welcome your opinion, but  while you hide behind an insecure OS and platform in fear new technology could topple it onto you, it might be better than you hold your opinions until you have some evidence and experience to speak with.

The underlying feeling... or is it a smell... is of someone afraid of their own code.  I suspect you are not a master of your own code base, but a slave to it.  Same for your build environment.  The pattern matches and it's very common.  We have already discussed ways to alieviate this, but you rejected those too.  Version control.  Version control allows you extremely sharp tools for maintaining  code base in a safe way where all changes (commited ones) can be reversed, replayed, split, merged, reordered.  Your build environment should be scripted, so it can be recreated in hours.  Once you can do that, an LLM destroying your code base or your build env, is just Monday morning.

[Siwastaja]

I've developed literally hundreds of products, micro based since c. 1980. None of them were buggy. All worked and some even made money. We all have ways of doing stuff and ways to use tools at our disposal.

I'm sure. You are successful because you have a decent mix of conservatism and trying out new things, and you have persistence. And long experience.

Note though this is a public forum where we are also giving advice to others - therefore pointing out what you are missing, how, and why, is beneficial to everyone, even if you want to choose your path differently. It's not a pissing contest.

Note the Subject line says "Using Claude Code for embedded work", and you discuss your workflow, which does NOT involve Claude Code, without clearly saying so - this missing piece can be recovered by reading enough of your posts, but it does not repeat in every post, which confuses other people, like Dazed_N_Confused. I was merely filling in the missing context - that you don't use Claude Code, but discuss a non-Claude-Code process in a thread titled "Using Claude Code". It really is a surprising thing worth mentioning - not a pissing contest.

[nctnico]

The underlying feeling... or is it a smell... is of someone afraid of their own code.  I suspect you are not a master of your own code base, but a slave to it.  Same for your build environment.  The pattern matches and it's very common.  We have already discussed ways to alieviate this, but you rejected those too.  Version control.  Version control allows you extremely sharp tools for maintaining  code base in a safe way where all changes (commited ones) can be reversed, replayed, split, merged, reordered.  Your build environment should be scripted, so it can be recreated in hours.  Once you can do that, an LLM destroying your code base or your build env, is just Monday morning.

This is kind of the clash between software engineers and electronics engineers who do software engineering. Being primarily an electronics engineer myself who spends most of his time writing software  , I'm not too fond on all things like Agile, CI/CD, docker, automated test scripting, etc. For me that is just extra stuff on my plate. And I typically delegate that to others. I think peter-h is in the same boat as I am; primarily an electronics engineer who keeps getting sucked into software development.

[paulca]

The underlying feeling... or is it a smell... is of someone afraid of their own code.  I suspect you are not a master of your own code base, but a slave to it.  Same for your build environment.  The pattern matches and it's very common.  We have already discussed ways to alieviate this, but you rejected those too.  Version control.  Version control allows you extremely sharp tools for maintaining  code base in a safe way where all changes (commited ones) can be reversed, replayed, split, merged, reordered.  Your build environment should be scripted, so it can be recreated in hours.  Once you can do that, an LLM destroying your code base or your build env, is just Monday morning.

This is kind of the clash between software engineers and electronics engineers who do software engineering. Being primarily an electronics engineer myself who spends most of his time writing software  , I'm not too fond on all things like Agile, CI/CD, docker, automated test scripting, etc. For me that is just extra stuff on my plate. And I typically delegate that to others. I think peter-h is in the same boat as I am; primarily an electronics engineer who keeps getting sucked into software development.

I hear you.  I'll be honest and say, at it's modern day finest, Enterprise software has lost it's way.  It is entirely "business driven", there is no "engineering isolation" and thus no automony, private "truth" or protection of values/rigor/disipline.  That proper layering only really still exists in financial infra, aerospace, defense or in places where code mistakes costs are immediate and eye watering.

The goal is to use prior software engineering to simply new software engineering with the goal being, software engineering not being required at all.  Software solutions become more like "join the dots", "paint by numbers", the solution already dictated by platform, ditated by business and what they got sold.  Engineering get almost no say in the mater.

There are many problems with this.  It's "borrowing progress" for one.  It creates a world where "software engineering" is deprecated entirely and replaced with "cookie cutter IDEs".  Look at gaming for a parallel.  The vast majority of games run on one of 2 or 3 game engines.  90% enterprise software runs on 2 or 3 cloud providers, using one of half a dozen primary components and frameworks.

If you want to get into the career, all you need to do now, starting from zero qualifications, is get a "bootcamp" in one of those frameworks/compoents etc.  And  you can get a software engineering role at 40K+ in the UK.  At what point did this person get taught all the other stuff?  They didn't.

However.... the contrast to the electronics "firmware" problem is getting starker and starker and you do not need to go as far as the above madness.

The key point I keep returning to is a question, literally the first question I would ask when someone floats a project by me in work.  "How many people, how quickly?"

The answer to that will decide what tooling, what processes, what structures, what admin, what management etc.  Before we even get to "Tech stack" or language.

CI/CD?  It's nothing more in spirit to an IDE "auto build on change".  The enterprise stack is split up for many reasons, but you don't need to that far.  For one you are unlikely to need to run containerised test harnesses, PR environments etc.  So most enterprise "CI/CD" systems would be completely wasted.

However.  The principles and disciplines that come FROM using a CI/CD structure apply even with the simpler cases.

* Separation of development and build environments - your windows crashes and needs reinstalled does not stop the production line.
* Centralising build and quality control - no idiot forgetting to switch OFF disable_tests and releasing a build.
* Automating build and deploy.
* Integration to the "work tracking systems"
* Forcing "single point truth" in the code repo.  If it's not committed, it doesn't exist.
* Simultaneous parallel version builds with parallel dependencies.  (support legacy devices/customers)

There are probably others... more related to team and competing teams and multi-environments.  Although  that later one applies. 

One point is that builds are reproducable.  A valid "failure mode" point is what happens when the "infra" running the CI/CD gets corrupted or "broken".  That one is addressed by making everything that can be made ephemeral, ephemeral.  The entire CI/CD stack install/deploy can itself be scripted.  Just don't lose the descriptors and scripts!

Consider.  You need to support builds for 3 different MCU platforms, which have sutble build changes and branches.  A CI/CD style system can help you automate things like; "Commit code, push code.  Tag code with MCU_1_v1_deploy and wait.  If you didn't break the build the MCU test harness in the corner beeps and runs the tests.  Or... you go into a queue because your peer is already running tests on it.  Even if these MCUs are in a different country.  Nobody leaves their desks.

What that looks like for a small one dev, versus a small team, versus a large set of teams, is different.  The value of it is also different.

Agile is/was great.  What is currently being "called" agile is a velocity over progress management system used to maintain perpetual work streams and revenue.

[paulca]

To put it far more simply.

If you are "okay" with your entire development->release->deploy/sell/ship process stopping dead for days or weeks because of a random "IT failure"...  you probably don't need to do anything except carry on suffering what works.

If you are in a team of 20 people billing $40,000 a day.  "Build outages" rapidly become unacceptible.  Money, time and effort suddenly gets employed to make it not fall over and to recover faster.

[Siwastaja]

The underlying feeling... or is it a smell... is of someone afraid of their own code.  I suspect you are not a master of your own code base, but a slave to it.  Same for your build environment.  The pattern matches and it's very common.  We have already discussed ways to alieviate this, but you rejected those too.  Version control.  Version control allows you extremely sharp tools for maintaining  code base in a safe way where all changes (commited ones) can be reversed, replayed, split, merged, reordered.  Your build environment should be scripted, so it can be recreated in hours.  Once you can do that, an LLM destroying your code base or your build env, is just Monday morning.

This is kind of the clash between software engineers and electronics engineers who do software engineering. Being primarily an electronics engineer myself who spends most of his time writing software  , I'm not too fond on all things like Agile, CI/CD, docker, automated test scripting, etc. For me that is just extra stuff on my plate. And I typically delegate that to others. I think peter-h is in the same boat as I am; primarily an electronics engineer who keeps getting sucked into software development.

Spot on, and the challenge is finding, recognizing and absorbing those technologies which are beneficial (and popularity itself is an advantage) - but popularity alone is not sufficient.

For example, version control definitely is something every project larger than 500 lines in 1 source file probably should use, and git is one of the best choices (even with its flaws). And actually Claude Code (not the copy-paste process) makes using git much easier. It can sometimes even solve those git problems properly where we mere mortals just take backups of our modified files, delete the repo and clone it again from the origin; I consider this one of the greatest achievements of AI. (Though, for me, even Claude couldn't completely undo accidental addition of large binary file in the repo. That I consider an impossible task. No human has ever succeeded. Maybe Mythos could have done it!)

"Agile" itself is pretty much dead with AI, you don't need any of that crap. Agile exists because you don't have enough time to do everything yourself, so you need to hire 10 substandard or, at best, average programmers, who don't know what you want and how, and then you are spending your time writing perfect tickets your team doesn't implement correctly. Now you can just ask Claude Code to implement what you need and what you don't fully know how to do yourself (or know, but don't have time). Tickets are useless. Mid-level planning (ticketizing ideas) is mostly useless.

But git is as useful as it always was, if not more! Claude Code's internal rewind mechanism is no replacement. Git is actually even more important now with the AI, as probably your one-man-team becomes "one man and three Claudes" team. So you will be branching, merging, reviewing diffs, more than ever. And Claude will be writing better commit messages than you ever did. And do more frequent commits, if you so wish, and you should.

Your whole collaboration can revolve around git, code and plain-text human-readable design documents. Ticket system only gets in the way. Big picture is in your head.

[paulca]

Big picture is in your head.

What about when it's not "your" picture let alone "in your head".  What if it its only really fully contained in:

* The code that exists - tells you what each part does currently.
* Not the other code that exists - multilple failed/partial rewrites have already been attempted.
* Partially spread out through time in incomplete and obsolescent documentation.
* In Bob's head.  Bob left 2 months ago.
* In Alice's head.  Alice left 3 years ago and nobody had touched that area since.

On workflow and work assignment ... how do "you" solve giving people 'ownership and agency' when the problem is large enough to require more than one person or more than one team of persons?

EDIT: Don't want to put words in your mouth, but there is a proposed pattern of "Solution Architect made God by AI".  No lower teir engineers or testers, no project managers.  Just direct conversion of "business intent" into "working software" employing AI.

That would not only make a LOT of people redundant.  I just dont' think it will get that far.  I hope.

[paulca]

Afford me an aside.  A different perpspective on this entirely.  I am currently "out of the banks", have been for a few years, but I have contacts and I have asked about the big players and AI usage in development.

Typically browser based AI tools for development are provided.  However, as usual in those environments, it has no websearch ability, and very limited webfetch abilities, mostly pointed to internal sites or "Denied" pages from proxies.

Even when a terminal based AI is permitted, the AI is read only and runs in a sandbox, as a sandbox "nobody".  It as no executive function beyond that sandbox and the sandbox is effectively firewalled such the only way to "actually action" anything the bot says or use it's code requires you copy and paste it yourself.

The moment you do that.  The moment you copy and paste code or a command and paste it outside the sandbox, you inherit the immediate criminal and civil liabilities of it.  You own it.  You did it.

[Siwastaja]

Big picture is in your head.

What about when it's not "your" picture let alone "in your head".  What if it its only really fully contained in:

Don't forget the context - it was people like peter-h, me or nctnico who are engineers and do not work in massive multi-employee software projects. For us, tickets in Jira do not work. For us, AI does work, however, and with that, we want Jira tickets even less than before. But we do benefit from some other things also used in the software industry - like version control. Recognizing what to use is the key.

In large enough projects keeping the big picture in the head of one individual is not sufficient, of course, you are right. Then again, AI has pushed the size threshold up.

[Kjelt]

For us, tickets in Jira do not work.

In general I agree with your statement above but this part iI find doubtfull.
I know a company of three persons that really benefit from Jira, if only to keep track of the backlog and progress of ongoing tasks and tasks that are on hold due to waiting for some constraint to be fullfilled.
Keeping track of your todo, in progress and on hold tasks/stories could benefit even small companies, heck even individuals that do not have other ways of keeping track of their progress.

To pay big for it or having the multi team interoperability experience is ofcourse overkill in these situations, but the basic functionality it is a really nice tool.

[peter-h]

Don't you guys think there is "just a little risk" with having some 3rd party tool editing your source code??

Claude does make mistakes...

[ejeffrey]

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.

?

1) the $20 / month subscription is really limited for programming purposes. I use it for hobby projects but it would never be enough if i were using it for full time work.

2) it is definitely possible to use a lot of tokens without doing much worthwhile.  At my wifes company their bosses were really encouraging them to use AI.  Then they got freaked out when they saw rhe bill.  One of her coworkers was using AI to do things like produce reports from massive data sets from the database they work with.  There were two problems with this: most importantly the reports were not needed or useful.  They never would have spent time on the reports if they had to do it manually since it would take too much time from their actual work.  When they could just let the AI do it in the background, it didn't feel like a big expense.  The second problem was that they were having the AI process the data and create the report rather than have it write a script to do that.  So every time it was taking millions of tokens (and probably halucinating the output because the data was too big).  This is because the person was not a SWE and didn't understand the difference but its also a problem with the tools. The AI tools are being presented as "can be used by anyone" but there are lots of traps like this.

[nctnico]

Don't you guys think there is "just a little risk" with having some 3rd party tool editing your source code??

Claude does make mistakes...

That is why you test the results along the functional requirements. But that is necessary no matter who writes the code. Claude is also very focussed on testing it's own work. Everything is a step-by-step process. Nothing is kept hidden. Just see Claude as a very knowledgeble engineer producing code. You have to judge for yourself whether you trust someone else to work along you.

[Kjelt]

Don't you guys think there is "just a little risk" with having some 3rd party tool editing your source code??
Claude does make mistakes...

That is not the only worry.
At our company the code will be reviewed with at least 3 SWE and testing sunny day and rainy day scenarios is one thing, checking if the code is readable and human maintainable another.
We rejected a 1300+ line state machine code since we were not able to validate it.
Maintanability in the future should always be in scope, if a bug is found next year, who is going to fix it?