EEVblog® Electronics Community Forum
Electronics => Microcontrollers => Topic started by: peter-h on April 17, 2026, 09:26:07 pm
-
This is a reasonable tutorial - just 30 mins of your life :)
https://www.youtube.com/watch?v=ntDIxaeo3Wg (https://www.youtube.com/watch?v=ntDIxaeo3Wg)
I can think of several reasons why I could not use it, starting with Claude probably being unable to run my code, although I am not actually sure whether some "integration" might be possible. I also do not use git and have no interest in it (have my own version management and backup scheme).
It reportedly works well for web app development, because these are easy to test.
I do use Claude for "fetching" algorithms, checking my code for stupid errors, and generally helping out. And there is really does improve productivity. But the overall file is still written by myself, to do what I want. With Claude Code you have to give it your entire project source.
-
With Claude Code you have to give it your entire project source.
no you don't, you a can easily use to write snippets of code
-
I can think of several reasons why I could not use it, starting with Claude probably being unable to run my code, although I am not actually sure whether some "integration" might be possible. I also do not use git and have no interest in it (have my own version management and backup scheme).
If you have your own tools for build/version control/etc... available from the command line, you just need to write up a markdown file with instructions for how to use them and that's the "integration" that claude code needs.
-
I use(d) OpenCode in combination with a local LLM (Qwen3 Coder). I've heard good stories with people using with Claude too. You can use a whole ton of different AI backends..
OpenCode has a few MCPs with local access (like list files, view file content and edit file content).
[unfortunately] also to bash for listing/finding files. But so far so good (fingers crossed)
If you give OpenCode a narrow enough prompt it will only look for relevant code, read it, and make modifications. OpenCode also has a Plan and Build mode, so it won't (or shouldn't) start doing things if you just give it a prompt to sketch things out.
Even then if you use version control, commit beforehand and let it do its thing. You're free to discard any changes you don't like..
That is if OpenCode stays in your target directory. I should check if it has some guardrails for that.. and not run rm -rf / --no-preserv-root. :=\
I asked OpenCode to take a look at my codebase, and then it will scan through half of my project files. If I was to use an external provider, it would all be uploaded. But there is still some filtering behind this.. it won't scan every file when it presumes something is some scafffolding code.
The problem I foresee with local LLM is context window size. I can put up Qwen3 Coder up to 256K tokens, but I need to run the 80B model at Q4 or Q6 to make it fit in 128GB of (unified) RAM on my Mac M4 Max. It also takes forever to "Prompt Process" that many tokens, as OpenCode can run a dozen prompts at this context size. I believe newer M5 Max have "up to" 4X PP speed.
So I also use Qwen3.5 35B model now, at ~80-100K tokens, its a lot more responsive. But I see LMStudio reporting its often discarding a ton of tokens between the dozen or so prompts it runs.
I still want to explore more. When I started out with OpenCode I had it do some simple modifications in a C# project. When you then have to wait 2-3 minutes between each prompt, my ADHD brain instantly zones out and I thought; hmm, normally I find programming fun because it sucks me in perfectly and whatever modification I make has instant results when I run it.
Is programming with 2-3 min delay fun? No I do not. Can I do something else in between these prompts? No I cannot.
But I'm interested to see if it is possible to sketch out an architectural document ('implement every message of this uBlox GPS receiver') and then have AI rip for little while in a sandboxed environment... Adafruit had some videos on their channel the other day with this exact scenario. I think they ran OpenClaw on a Raspberry Pi.
-
I used Claude code to write an optimising compiler that produces 6502 code, targetted primarily at the atari 8-bit though it also pays lip-service to the C64 and has a generic linker-script approach to how it works. I gave it a custom (5-byte) float and (8-byte) double format to work with, and told it I wanted "bank switching" automatically enabled so functions could be put into banked RAM. I was thinking about the "xe" variant, but Claude made it generic so it worked with the Compy and Rambo 3rd-party expansions that extended the original atari bank-switching technique.
I told it I wanted the "shadow RAM" that was available "underneath" the ROM at $C000-> available for programs at all times, and it told me that would interfere with all the interrupt-driven parts of the atari OS (true, I knew that but was planning on writing an NMI interrupt-handler that swapped the OS back in just-in-time for interrupts to work then swapped the OS back out). It did it for me, figuring out the vectors to modify, downloading a simulator it could test with that reported state to stdout, and going through trials to make sure the generated code actually ran. I didn't directly ask it to do that...
I started writing a doc to keep myself up-to-date with what the language could do, and so (when I release it) there's some instructions to make it useful. Claude noticed the file, realised what it was, and started updating it itself when I asked it to make more changes.
The point is, if it can do that sort of R&D on a 40+ year old architecture, it can probably know about the ins and outs of a modern one, and even if it failed to ingest the datasheet of your $obscure-manufacturer part, just feed it in as part of the prompt process.
I will say that "write a compiler" was beyond the local models I tried - and I'm running on a Macbook M4 Max with 128GB of RAM so I could play with some large local models. 122B Qwen3-Coder 3.5 was the best of the bunch, but it still wasn't even close to the Claude results. Night and day.
I'm very happy with the compiler. Here's the "help" output:
simon@M4MBP doc % xtc -h
Usage: xtc [options] <input.xt ...>
Options:
-a, --assemble-only Compile to .asm module (no runtime)
-D <name[=value]> Define preprocessor symbol
-E, --preprocessed <path> Write preprocessed output to file
-Fli, --fn-leaf-inline <n> Max leaf-function size to inline
(default: 100, requires -O2+)
-Flu, --fn-loop-unroll <n> Auto-unroll counted for-loops with trip
count <= n (default: 5 at -O2+, 0 otherwise)
-H, --xtc-home <path> Set xtc home directory
-h, --help Show this help
-I <path> Add include search path
-O0 No optimisation (the default)
-O, -O1 Peephole + register tracking
-O2 + const prop, dead code/store elim, tail call
opt, leaf inlining, loop unrolling (<=5)
-O3 + branch inversion, strength reduction,
cross-function DCE, label cleanup
-o, --output <path> Output file (.asm or binary)
-q, --quiet Suppress informational output
-Q, --quit-style <which> Action after main() returns: rts (default), loop
-S, --xtc-stack Use xtc software stack globally
-falloc=bump|heap Heap allocator: bump (fast, no free)
or heap (coalescing free-list, supports
delete). Default: heap on targets with a
dedicated heap region, bump elsewhere.
Platform options:
-m <layout> Load a memory layout (.lnk file). Searches
for <layout> as a file path (appends .lnk
if needed), then support/layouts/<layout>.lnk
Default: xl
--dump-layout Print memory-map diagram and exit (use with -m)
--list-layouts, -ll List available built-in layouts by platform
Warning options (-Wno-<category> to suppress):
new-in-loop new inside a loop body (leaks)
escape stack-addr stored in longer-lived slot
(global, heap field, outer scope)
class-init bad initialiser on stack class
asm-clobbers asm{} clobbers annotation mismatch
unknown-annotation unrecognised function annotation
unknown-pragma unrecognised # directive
Function annotations (after params, comma-separated):
Calling convention / prologue:
: hwStack Force 6502 hardware stack
: xtcStack Force xtc software stack
: naked No prologue/epilogue (for ISRs)
Interrupt handlers (mutually exclusive with :naked):
: irq IRQ handler; OS-safe prologue, RTI epilogue
: vbi VBI handler; same shape as :irq, runs each
vertical-blank (install via Vbi.install)
Placement (where in the memory map the function lives):
: main Force into the main (always-visible) region
: banked Force into a bank page (banked targets only;
incompatible with :irq / :vbi)
: shadow Force into shadow RAM under the OS ROM
(xl-shadow / xt-shadow / xe-shadow only)
Shadow-target helpers:
: needsOS Wrap body with ROM enable/disable on shadow
targets (no-op on non-shadow)
(all annotations are case-insensitive)
Output format (determined by -o extension or [output] in .lnk):
.asm 6502 assembly source
.xex .exe .bin .com Atari XEX binary
.prg C64 PRG binary
Support file search order:
-H > $XTC_HOME > cwd > ~/xtc > /usr/local/xtc > /opt/xtc
And here's that md-file doc to give an overview of what the language can do (huh, can't upload a .md file, ok here it is as .pdf)
[attach=1]
-
This thread should be in the AI section.
Claude code is quite able to write, edit, compile, flash, run and debug programs. Plug a Nucleo board in and try it.
-
Shows how behind the times I am - I wasn't even aware there *was* an AI section :)
-
If certain folks did use it, the S/N of threads may improve by a tremendous amount.
-
Just had a look, it's here BTW (https://www.eevblog.com/forum/chatgptai/), and it seems to be 99% politics and economics of AI, while this thread is about technical use of AI. I think it's probably better here where it's on-topic for embedded.
I use Claude as a back-seat driver to check code, alongside Coverity, PVS Studio, the clang analyzer, and others. I'd never use it to write code but it's a really powerful tool for looking at your code and saying "hey, about this bit over here...".
-
That is how I use it, but I am on the free version, so not Claude Code.
It dumps me after only a few interactions, or even just one involving looking at some source file, so I get one go every few hours. I set up a second Claude account (using a different email) and that strategy works. Often, one checks the output of the other and the result is really interesting! So when one of them cuts me off until time xx:xx I can just switch to the other one.
ISTM that if you use Code (i.e. pay the £18/month or so) you are able to send it more source code to work on. Or maybe it actually does more. Yesterday I was running a 2008 VisBas program (a weird thing which script-drives another ancient commercial application to generate loads of PDF reports; written by an ex-M$ guy, runs only under win2000 so running in a VMWARE VM) which bombs out at a specific point. I uploaded the VB source code to Claude, together with the logged error message, and it suggested some debugs one could put in to narrow it down (I need to work out how to build this thing!) but that was as far as it went.
Last week I developed what is basically a data acquisition and timing product (based on my existing 32F417 project which I plan to use for absolutely everything for the rest of my life because I am never going up that horrid learning curve again :) ). It does some funky stuff like using the RTC for hh:mm timing, and doing some funky stuff like not zeroing the timer if the power was lost for less than 5 mins. This involves saving the RTC hh:mm in an RTC RAM location (as a packed uint32_t) every 1 minute and then you can tell how long the power was off for (the RTC itself runs off a ~1 week 0.47F supercap). Claude completely correctly worked out the logic and came up with code for other features I wanted. It correctly addressed stuff like computing hh:mm difference, with handling of the midnight rollover case.
The only indication that it is not a formal code analysis program, but rather a "pattern recogniser", happened when I had
// uint32_t count=6;
uint32_t count=7;
and it insisted count is initialised to 6 :) I gather "computer scientists" continue to be amazed how far it gets without actually understanding anything :)
What I don't get, looking at the above video, is how it works with embedded, where it obviously cannot run the code and see the result. You have to give it the files, it looks at them, generates code for whatever new feature, etc. You then edit the suggested code back into your sources (in Cube IDE in my case). And you don't need Code to get that functionality.
-
A chatbot goes through input filtering the code bots don't. The code bots have dedicated code analysis/parsing agents, chat bots might if you are lucky.
These threads contain far too much "I think", "I guess", "I haven't tried yet."
I'm going to stay out of them until that is fixed.
STOP speculating and go and use it, the proper one, not the "magazine cover disk" free version.
And peter-h. When you complain that things are difficult and people give you solutions... why do you insist on saying, "Does not apply, I have my own way of doing things." This is not how engineering works mate. The work "Practice" is not meant in the context of violin. We (developers) have a shared responsibility to the practice and keeping it forward faced. "Best practices" suggest there are others.
-
I posted a thread in here about what happened when I gave claude a tiny prompt like: "What does this do?" in my STM32 Soft-DSP project folder.
Start with something like that. Then just ask it questions, chat with it about the code, then tell it about something which has annoyed you or something you have wanted but never got round to.
Let the magic happen.
EDIT: However. The first resistance point I expect is going to be: "Where do I run this code bot then?"
The best answer is in a Linux bash terminal. That's going to push a lot of less serious devs nose out.
GitBash is too thin. Powershell ... works, but that's debabtable with or without Claude. Powershell == DotNet CLI. You need to learn DotNet to use it.
Cygnwin I am told is not worth the effort.
So for our windows only peers, WSL is the next best thing. That's going to be painful on Windows 7.
Which ends us with a VM running Linux. That's a bit of an environmental reconfigure which will either require really tight, really well done networking (for code base open in both claude and CubeIDE) or tight disipline on the version control to push and pull between them. NOT advised.
I think the best option, though no where near "ideal" is going to be an IDE extension. There will 100% be a claude code extension for Eclipse by now. Has to be. If there is, then Claude will get access to the IDE API and can directly action the build within Cube... and see the output logs when it flashes and runs it's tests. For me this part is speculation. I don't use Windows anymore. Save for gaming. I have used Claude Code in VSCode extension and it supports terminal mode, but the underlying OS is Linux or MacOS. So bash or zsh shell.
-
peter-h, you should really give Claude Code a try. With your posting history, I believe it's exactly what you need - relatively complex codebase you have to maintain nearly alone, you want to understand details, make modifications here and there; you have a lot of questions.
In project like yours, copy-pasting snippets between a chatbot really does not work. That works for creating isolated small tools etc. You need a coworker who learns the codebase and uses tools. That's exactly the Claude case.
Pay for one month with the cheaper $20 license and give it a shot. Just /init on your project and then give it a few hard questions, something you would normally post here. You will be surprised how well it works and actually starts to solve your problems.
It's exactly the eager and pretty capable junior engineer you need in your team. Expect that it's available ~97% of the time, not 20% like a full-time hire human being (or 5-10% of part-timer). And the cost is $100-$200 / month, depending on how much you use it. The $20 license is only sufficient for serious enough initial testing or occasional small fixes.
-
Just /init on your project
What is that?
I am running win7-64. Obviously I can run a terminal window but if Claude Code needs to run some local executable...
-
I set up a second Claude account (using a different email) and that strategy works.
For anyone else thinking of doing this, beware that they require you to provide a mobile phone number for SMS verification and you can only use that number once. If you set up two accounts, you'll need two separate numbers, and it often doesn't work outside the US/Europe. There's a 700-message thread in the Claude github repo (https://github.com/anthropics/claude-code/issues/34229) on this.
-
I'm not familiar with Windows, but on a Mac I just use terminal to interact with Claude.
You download the installer, which will set up Claude Code (just type "claude" in Terminal.app). Do that from within the source directory because its going to cache a bunch of stuff there for future use. Plus you'll benefit from having a doc/ folder for it to write .md files to as it evolves solutions, comes up with things to fix in future etc. You can tell it to write whatever it needs to, to a file, so it can pick up on the bug it just found later on. It can be quite informative to read some of those files.
Anyway, once in the terminal, it will read/write files continuously- source files, docs, tests, you-name-it. It can also run executables - and it will. The standard approach it takes is "try, write regression test, verify by actually running". In my case above, it realised it needed a 6502 simulator, so it wrote one and then used it. It runs xxd to dump files in hex to verify what's in a file is what it thinks ought to be there. It can pull down documentation from the web (or you can feed it the same). It really is like interacting with a developer, over a terminal instead of over the phone.
Try it, the actual Claude Code version, not the web chat. It's a brave new world. Here's a sample just by cutting/pasting from the terminal window as I type this reply:
⏺ Bash(timeout 5 ./bin/osx/xts -m xe /tmp/hb.xex 2>&1 | tail -100 | head -30)
⎿ A=00 X=00 Y=01 SP=F9 ----ZC | B659: STA $B685 | A=00 X=00 Y=01 SP
=F9 ----ZC
A=00 X=00 Y=01 SP=F9 ----ZC | B65C: LDY #$00 | A=00 X=00 Y=00 SP
… +30 lines (ctrl+o to expand)
⏺ Bash(timeout 10 ./bin/osx/xts -m xe /tmp/hb.xex -M 100000000 2>&1 | tail -15)
⎿ A=A0 X=61 Y=00 SP=FD -V---C | AE11: BNE $AE15 | A=A0 X=61 Y=00 SP
=FD -V---C
A=A0 X=61 Y=00 SP=FD -V---C | AE15: LDA $D301 | A=22 X=61 Y=00 SP
… +18 lines (ctrl+o to expand)
⏺ Bash(timeout 15 ./bin/osx/xts -m xe -d /tmp/hb.xex 2>&1 | tail -10)
⎿ sim6502: xe mode (1 bank segments)
⏺ Bash(timeout 15 ./bin/osx/xts -m xe -g0 /tmp/hb.xex -M 50000000 2>&1 | tail
-20)
⎿ | |
| |
| |
… +17 lines (ctrl+o to expand)
Read 1 file (ctrl+o to expand)
⏺ Bash(sed -n '8998,9015p' /tmp/hb.lst)
⎿ 610E TAX
610F PLA
6110 RTS
… +15 lines (ctrl+o to expand)
⏺ Bash(bash tests/run_fixtures.sh 2>&1 | grep -E "heap|retain" | head -10)
⎿ PASS heap_basic xe-heap O2 (13 tests)
PASS heap_basic xe-heap O3 (13 tests)
PASS heap_retain xe-heap O2 (6 tests)
… +7 lines (ctrl+o to expand)
This is Claude tracking down (and fixing, as I type) an obscure memory-banking bug where it had to go refactor the heap-helper code for when a recursive function had managed to get more than 255 iterations down, and the index,Y addressing mode for access to the bank-switch register wasn't working.
-
you are able to send it more source code to work on.
Just be aware that unless you've got the setup configured just right, you're giving Anthropic the right to train the model on your code, which means your code could end up in other companies' products.
-
Just /init on your project
Opinion is divided on the subject:
Opinion (https://www.youtube.com/watch?v=2e5lNftNxXs)
Claude takes a guess at what's needed and can end up burning a lot of tokens and wandering off in the wrong direction if it guesses wrong. Starting with a well-written CLAUDE.md is a better approach.
-
Claude takes a guess at what's needed and can end up burning a lot of tokens and wandering off in the wrong direction if it guesses wrong. Starting with a well-written CLAUDE.md is a better approach.
I totally agree, but it's a good introductory lesson for a beginner. Maybe it's better to ask "hey, I'm new to this thing, analyze the whole codebase, tell me how it works and suggest what could be done".
For me, CLAUDE.md generated by /init had maybe 2/3 unnecessary content which needed cleanup (like unnecessary build commands I hadn't used in 3 years and had forgotten myself), and lacking the user insight which you need* to add anyway - maybe better /init would interrogate the user and write CLAUDE.md based on that. And too much technical details about things Claude can (and should) just check when relevant.
Then again, it does not actually hurt enough to be a real concern... As always, this AI thing is flexible and tends to work out and arrive at stable and decent outcome nevertheless.
*) or rather, "might want" - the strength is exactly that you don't need to follow any specific process! Nearly anything works out in some useful way.
-
Just be aware that unless you've got the setup configured just right, you're giving Anthropic the right to train the model on your code, which means your code could end up in other companies' products.
Indeed, this is a known issue with any system "learning" from sparse data.
According to press reports, some companies, notably legal ones, have banned staff from using “AI” for client work, because the server is obviously storing the query, and its computed response, and is likely to serve this to another user, in another company, which somebody also contacted for legal advice on the same scenario, and the client could work out that the other party to some litigation obtained such and such advice. This is the standard weakness of large scale data collection / pattern matching, if the sources for your specific query are very sparse. So e.g. if you ask it the maximum voltage rating of a BC109, there is no leakage issue because you can find that in 1000 data books, all of which are accessible to “AI”. But if you ask it for ways to circumvent patent (number xxxxxxxx) then two clients working the same server are more than likely to be served the same advice.
So if you have done code which does something obscure, it is likely to get fed to multiple users.
I don't want to bugger up my source code... Does Claude Code install a windows executable application which communicates with Claude, and has access to a specified directory on your PC? All examples I see are linux or Mac based.
-
According to press reports, some companies, notably legal ones, have banned staff from using “AI” for client work, because the server is obviously storing the query, and its computed response, and is likely to serve this to another user, in another company, which somebody also contacted for legal advice on the same scenario, and the client could work out that the other party to some litigation obtained such and such advice.
It also works in the other direction, you could end up with someone else's copyrighted work in whatever you're generating with the AI. This is at least as big, or an even bigger, headache for companies operating under strict legal regimens.
Most enthusiastic users of AI have no idea that this is an issue, and no policy to handle it. It's going to take a SCO-vs-IBM scale lawsuit before anything changes.
I don't want to bugger up my source code... Does Claude Code install a windows executable application which communicates with Claude, and has access to a specified directory on your PC? All examples I see are linux or Mac based.
The general advice if you're running Claude locally is to run/lock it inside a VM. I use the web version because that has no access to my local filesystem, or indeed local anything.
-
According to press reports, some companies, notably legal ones, have banned staff from using “AI” for client work, because the server is obviously storing the query, and its computed response, and is likely to serve this to another user, in another company, which somebody also contacted for legal advice on the same scenario, and the client could work out that the other party to some litigation obtained such and such advice.
It also works in the other direction, you could end up with someone else's copyrighted work in whatever you're generating with the AI. This is at least as big, or an even bigger, headache for companies operating under strict legal regimens.
yeh, something like: I've seen this XX opensource project but I don't like the license, can you write something that does the same?
and magically you have something that does the same with what ever license you like ...
-
and magically you have something that does the same with what ever license you like ...
With whatever license you're willing to take legal responsibility for, the AI supplier washes its hands of it. Also, it seems that for many jurisdictions, AI outputs may not be copyrightable, which removes the legal basis of your chosen license, and the code is public domain. Human prompts into an AI are likely copyrightable. AFAICT IANAL.
e.g.
https://pec.ac.uk/blog_entries/copyright-protection-in-ai-generated-works/
AI has spat out other folks code verbatim so there will likely be some sort of legal case about this soon enough.
-
I use the web version because that has no access to my local filesystem, or indeed local anything.
Are you using Claude Code in this way?
you could end up with someone else's copyrighted work in whatever you're generating with the AI.
Most people doing this forcefully argue that any output from "AI" is public domain, and if it is a close paraphrase of some (sparse) source material, that is fine also, and in any case protected by any "fair usage" policy ;)
Keeping this specifically on the embedded topic, I've seen some weird code which I think it "found somewhere". Claude has a reputation, reportedly, for getting stuff primarily from github, and in that sense it is useful because extracting a piece of self contained working code from github is generally nontrivial, IME. Now github is probably PD, but you don't actully know that, because if somebody uploaded some copyright code, who will find out? I know for a fact that there are systems out there doing searches for copyright material: I run a community site and recently we got pursued by some copyright protection agency for a photo somebody posted 5 years previously; I told them to F off because forums are specifically protected under GDPR provided the material is removed within ~5 days. Github, thus attacked, will probably silently delete that file...
-
I will LOL for the day when a LLM will just "let me look for API keys on Github" and finds a few for rate-limited APIs like Octopart, Mouser, etc.
Anyhow, I don't expect code from LLMs to be of amazing standard. But most code shouldn't be written like its your life work. It should implement a feature, in an easy to read way, with good maintability. When projects grow, its usually hard to keep an overview if you're working alone.
Fwiw:
This is one of the first things I tried to use OpenCode for. I have about 44K LOC project here (18K main, 8.5K infrastructure, 15K test and the rest are sandbox/tools), and it does a fair job at finding code smells for me and making suggestions for large refactors.
Since my last post, I moved over from OpenCode as GUI to OpenChamber. Its not completely bump/bug-free, but at least I get prompted before running a particular tool (like bash or editing files). It also seems to automatically delegate smaller tasks to subagents like "explore" which run in a new context, and thus run faster.
I switched over from Qwen3.5/Qwen3Coder to Gemma4 31B. Iirc Qwen3.5 is a Mixture of Experts model, which means only a few B parameters are active at a time. It ran fast but was hallucinating like crazy. It spend a full hour running in circles adding code, seeing the build fail, then making silly changes and eventually giving up. Then when I gave suggestions how to fix it, it just tossed everything and "tried again".
Gemma 4 seems to be making very solid forward progress. Although I've seen with others that Claude 4.6 Sonnet is still much more capable. Unfortunately, in their infinite wisdom, Anthropic only accepts Credit Card payments which as an European I obviously don't have. So maybe I will sign up to Claude via GooglePay some day, just to compare, or have it hack away at the more complex/architecture drafting tasks. Not every task needs to be most complex/expensive model.
I will say that "write a compiler" was beyond the local models I tried - and I'm running on a Macbook M4 Max with 128GB of RAM so I could play with some large local models. 122B Qwen3-Coder 3.5 was the best of the bunch, but it still wasn't even close to the Claude results. Night and day.
122B on 128GB of RAM? Is that Q4 with a limited context size?
I tried Qwen3 80B and that was really stretching my system thin. I still allocate 96GB as VRAM, and it couldn't really handle context sizes much beyond 100K. And that is a problem on a medium-large project when the prompts get so big it has to prune 2/3s for every intermediate prompt..
Afaik AI models also move very very quickly still, despite apparent plateau of capability. They do get increasingly better and more efficient with a similar amount of weights. Unfortunately open models are still 0.5 - 1 year behind, so it is exciting to know that cutting edge Claude models will probably run local by this christmas. Then again Claude's holding back Mythos because its "too powerful" does spark my interest to try that as well... if we ever get to see it.
-
Interesting thread. Today I was reading up about potentially using some local AI models, via LM Studio, that claude code can be set to use rather than going out to the internet. How well those models work, I've no idea. But the office PC is beefy enough to take a look at. I did check the current price of RAM, that was very scary.
-
Why don't you ask it to make an optimized copy of itself? :popcorn:
-
How well those models work, I've no idea. But the office PC is beefy enough to take a look at. I did check the current price of RAM, that was very scary.
It's a mixed lot... none of them are completely competitive w/ using a hosted anthropic model, but they can be useful.
RAM is absolutely important tho... and should be attached to your GPU. So, either a video card with lots of onboard vram, or a chip with cpu/gpu/shared memory all in one package. 24gb is probably the bare minimum to get good results in this space, but 128gb would be my target right now.
If you go the discrete gpu route, you can play some games balancing cost and performance based on how much you do on gpu vs cpu, and how much ram each has.
-
How well those models work, I've no idea. But the office PC is beefy enough to take a look at. I did check the current price of RAM, that was very scary.
It's a mixed lot... none of them are completely competitive w/ using a hosted anthropic model, but they can be useful.
RAM is absolutely important tho... and should be attached to your GPU. So, either a video card with lots of onboard vram, or a chip with cpu/gpu/shared memory all in one package. 24gb is probably the bare minimum to get good results in this space, but 128gb would be my target right now.
The PC has 64Gb ECC DDR5, the video card has 32Gb VRAM. My M1 Max MacBook Pro is possible, though it's 32Gb. I may update the MBP later in the year, budgets permitting.
-
Well, I asked, guess who? Claude:
Q:
Can I give you all the source code for this product, to comment on etc, or do I need to use Claude Code for that? I am running win7-64 and the executable Claude has for fetching the source code from a specified directory is probably not compatible with that?
A:
You can just paste or upload the files directly here in the chat — there's no need for Claude Code for this. You've been doing it successfully throughout this whole conversation, uploading individual `.c` files as documents.
For a whole project, the practical approach is just to upload the files you want reviewed one at a time or a few at a time. The main limitation is context window size — very large amounts of code can push earlier parts of the conversation out of the context window, which is why this conversation was compacted earlier.
Regarding Claude Code and Windows 7 — you're right to be cautious. Claude Code is a command line tool that requires Node.js and is designed for modern operating systems. Windows 7 reached end of life in 2020 and Node.js dropped Windows 7 support some time ago, so Claude Code would almost certainly not run on it.
So the best approach for your project is to continue as you have been — paste or upload the key files you want to discuss. If you want a broad review of the whole project, uploading the main `.c` files one by one and asking for observations on each works well. Alternatively you could paste multiple files in a single message if they are not too large.
Q:
What is the maximum amount of data I can send you?
A:
The context window for Claude Sonnet 4.6 is 200,000 tokens, which is roughly 150,000 words or about 600-800KB of plain text code. However the practical limit per message is lower — very large single uploads can cause issues.
A more practical way to think about it for your project:
- A typical embedded C source file of 500-1000 lines is about 5,000-10,000 tokens
- You could upload 10-20 such files in one go and still have plenty of room for discussion
- The conversation history also consumes tokens — this conversation is already quite long, so you may be getting close to the limit where earlier context starts being dropped
The most practical approach for a whole project review would be to start a **fresh conversation** and upload all your key source files at once at the beginning, then ask for a review. That way the full context is available without the overhead of this long conversation history.
The files most worth uploading for a complete picture would be [ list of .c files ] — which you've already shared here — plus any header files and the main startup file if there is one.
Q:
If I start a new conversation, won't you have forgotten previous comments?
A:
Yes, each conversation starts completely fresh — I have no memory between conversations unless you have the memory feature enabled in settings (which you mentioned earlier is not enabled).
However for a code review that's actually fine — you don't need me to remember the discussion history, you just need me to see the code. You could start a fresh conversation, upload all the source files, and add a brief summary of context such as:
[ list of recent projects and discussions re them ]
That gives enough context for a useful review without needing the full conversation history. The code itself contains most of the relevant information anyway — your comments and change log entries are very thorough.
For anything where the conversation history genuinely matters — like continuing to develop a specific feature — it's worth staying in the same conversation. But for a broad "review all my code" request, a fresh start with all files uploaded is actually better since the full context window is available for the code rather than being partly consumed by conversation history.
-
yeh, something like: I've seen this XX opensource project but I don't like the license, can you write something that does the same?
It's not even that, you have no idea where the code that Claude is extruding for you has come from. The reason I mentioned SCO vs. IBM is that they used tiny snippets of code, e.g. portions of atealloc, as their "evidence". So if you're using it for anything other than personal projects you at least need to have a policy about this, for example anyone who contributes AI-extruded code has to take ownership and responsibility for the code and certify that it's their creative work, not the AI's.
That may not be 100% accurate, it was from a long discussion over legal issues when using extruded code which isn't really my department so I wasn't taking notes. Our policy for now is human-written, human-vetted, human-committed, because there won't be any nasty surprises in the future. The scariest one would be a ruling that the copyright for extruded code lies with the data it was trained on, which will be a nightmare to go back through every code contribution for the last x years to figure out its provenance.
-
Well, I asked, guess who? Claude:
Q:
Can I give you all the source code for this product, to comment on etc, or do I need to use Claude Code for that? I am running win7-64 and the executable Claude has for fetching the source code from a specified directory is probably not compatible with that?
A:
You can just paste or upload the files directly here in the chat — there's no need for Claude Code for this. You've been doing it successfully throughout this whole conversation, uploading individual `.c` files as documents.
For a whole project, the practical approach is just to upload the files you want reviewed one at a time or a few at a time. The main limitation is context window size — very large amounts of code can push earlier parts of the conversation out of the context window, which is why this conversation was compacted earlier.
Code review is totally fine to work like that, uploading individual files. But you are definitely missing out on a lot of capability. If you want to actually use it to write code or make large scale modifications to existing code spanning multiple files, you are going to want the CLI agent or an IDE/editor integration. Then it will be able to interact with your version control, read the project files, run build scripts and interpret the results, make refactoring changes across multiple files, and execute multi-step plans. And yeah, you will need a newer OS. But you can run it in a virtual machine if you want. That also gets some helpful isolation. I'm not a windows user, but I would guess you could use WSL2 and run a recent version of Ubuntu in that?
-
OK; this is all very useful.
Yes indeed I can run a win10 VMWARE VM on a win7-64 host, and already do. It is just very slow, even on a top-spec machine.
OTOH I mostly do code development in small functional blocks. I am extremely careful to not break existing code which has been thoroughly tested. For example I might want a CAN subsystem, and Claude came up with code in seconds which I can just drop in and which looks mostly usable.
-
OK; this is all very useful.
Yes indeed I can run a win10 VMWARE VM on a win7-64 host, and already do. It is just very slow, even on a top-spec machine.
OTOH I mostly do code development in small functional blocks. I am extremely careful to not break existing code which has been thoroughly tested. For example I might want a CAN subsystem, and Claude came up with code in seconds which I can just drop in and which looks mostly usable.
Yes and a single prompt and claude code would have tested it all too.
It's honestly night and day.
Chat bot: One prompt, one answer, one invocation. One API call, also cheap.
Code bot: One prompt, 3 minutes waiting on 5 code analysis agents, 2 planning agents, 6 Q&As. Outputs a full plan on what is changing and how it will be changed. You read, approve or go back and forth, or just abort it entirely. Or say "Yes" and let it action the plan.
It's in the loop fully with you. Not a back and forth prompt/answer, but actually working in parallel with you.
On platform. I think this is your biggest hurdle. Your OS is 10 years old. Nobody supports it, nobody wants their software to run on it. A lot their insurance company won't permit it.
Windows10 isn't going to be great either. Windows has only ever been the home for IDEs and email clients. Most higher end software runs on Linux, so there is a terminal never too far away. It's why my company favour Macs. The core terminal based UI.
It will install and it will run in a "Powershell" terminal and it does support "Powershell", but it's nothing on bash/zsh etc.
A better option might be VSCode with a bash shell add on or something. The claude extension on windows might already give you a bash context. If not it will pick up Powershell and use it.
Claude being in VSCode and you being in CubeIDE might not create as many issues as you think it will.
Similar installing the Claude Code extension for eclipse into CubeIDE might have legs. Depending on how old your CubeIDE is.
-
You read, approve or go back and forth
The bit I don't get is how can one possibly do good quality embedded code this way. In embedded, there is a lot of critical stuff to do with e.g. peripheral setup and timing. There is a lot of scope testing to make sure timing is right. Claude cannot read and make sense of the 2000 page RM, for example. It probably dives into github, ST appnotes, and such like, for code examples.
When you get to stuff like user interfaces, it gets a lot easier. That's what I found.
Whereas e.g. web application development is far less critical. You can throw code at the problem until it looks like it is working and then you move on to the next bit. You get lots of subtle browser dependent compatibility issues but few people worry about that these days ;) I see people doing server-side apps fully with this process, with high productivity.
-
Peter, have you actually tried it ?
I ask because in that 6502 compiler I was talking about, Claude wrote optimising steps based on the knowledge that if there was a STA absolute,X (or Y), there was a 1-clock penalty for the access if the indexing took it over a page boundary.
I didn't tell it. It worked it out for itself. That seems to be the sort of detail that you're talking about. This, of course, is Claude Code, not just the bargain-basement web version.
122B on 128GB of RAM? Is that Q4 with a limited context size?
It was a while ago, but I think it was Q4. I was also using the trick to increase the RAM available to the GPU (to 116GB IIRC), but my context size was maxed out at 256K.
I do expect the local models to get better, I'm not sure how quickly they'll get to where the frontier models are now, but they've made enormous strides over the last 6-9 months. I very much doubt that's the end of it.
-
There are strengths and weaknesses in it's training data, yes.
Also a full 2,000 page STM reference manual, especially in PDF format is going to bust your token budget rapidly.
Again, apply the "Junior Engineer" pattern. What would you do with a junior engineer in that circumstance?
Let's be fair and honest here. You would "helicopter" and "micro-manage" them, right? Then do that with claude.
There are a few tricks though, that you can't really try with a flesh and blood engineer, not safely anyway. You can have more than one claude session, you can use that "Always a new junior every day" problem to your advantage. If one 200k context doesn't fit, use two or more of them.
To explain. An approach I have taken before, under similar circumstances is to pick things up where I am happy and comfortable and get claude to explain the current situation to me. This fits with your situation as I see it. Gain the trust and steer claude through the "It tells you what your project does." "chit chat" phase.
When you find it steps outside of your "expectations", such as you find yourself saying, "Hey, that's not what it says in my reference manual.", then point claude at that reference manual or an excrupt and get it to "write it down" for itself (and you) in a reference notes file.
For the reference manual itself. They can be hit and miss. It depends on the PDF format. PDF does not extract in a "co-linear" fashion to the text in more complex formats. So things like getting one line from the left column + one line from the right column, followed by a "figure annotion" is what the bot sees. Converting it into a more suitable format, aka, MarkDown or plain text, or even HTML can help the bot parse it and form it into context. It is also far less tokens to process text than a PDF.
You could use a clean claude session and get it to convert and extract parts of the PDF into a folder of documents, just for claude itself. It will even install the tools for you, such as "Poppler" PDF utilities. You don't need to worry much about reading it. Just check it works by spot testing claude on something very specific and very empirical it either gets right or doesn't.
I took this approach with the 68k CPU and it's MC68681 UART. The SRAM and FlashROM datasheets were very light, so I left them as PDFs.
At the end of that session, you have a set of "This is what claude needs to know from the reference manual" documentation suite.
You can clear that session now.
Start a new one, and repeat this analysis and documentation stage but focused on your project and writig the documentation for it you could never be bothered to write! Yes, I see you.
When you have a nice coherent project description in a folder of documents, you can again clear down that session and context.
Finally. When you "/init" a project, or just by asking claude to create it, the key file (in the first instance) is the CLAUDE.md readme. This is the the claude README file. It will always open it and put it in the context at the top. In this you tell it about the STM32 docs you created, you tell it about the project documentation you made. You tell it to use those as references for the hardware and software. You can even "try" and tell it to "always query the user when there is not enough information present to decide from these hard references alone."
If you are stuck with where to start with claude on the project and if you did the above I would be very, very surprised if you haven't already started a long TODO list of things it found, you didn't like or were trying to hide. It might find the bodies. It's very likely to find them and so it's not just you who knows where they are buried.
Start with admin. Start with listing those things you never got round to. Asides being a good junior it's a very responsive project manager who will actually write the documentaiton you can't a.r.s.d writing. The stuff you really needed, but never bothered. (We would call this backlog forming).
Then just pick one of those that you know the solution to, but just haven't got round to and guide claude through it. See how you feel, see if claude drove the work and followed you how you liked.
The end test is simple. Did it save you time? Did it help you think? Regardless of how productive "it" was, did it make YOU more productive? If those are true, you got it. If they are not, you might need a change of approach or maybe it just isn't for you.
-
I didn't tell it. It worked it out for itself. That seems to be the sort of detail that you're talking about. This, of course, is Claude Code, not just the bargain-basement web version.
Mine learnt the hard way, while I watched it burn a week's worth of token budget, that assigning a pointer with 0 in GCC will produce "undefined behaviour" at runtime. It's the GNU thing where they just declare something as undefined behaviour and do nothing to fix it, deliberately. It will compile and it will run, but GCC will have stripped all access to that pointer.
But in a hardware project test harness checking that address 0 is writable... kinda necessary.
Honestly, neither it nor me seen this "mistake" in advance but claude got the bone and didn't stop. It decompiled the binary produced by GCC and looked at the ASM and realised half of it was completely missing. It even realised it was taking far too long so it just wrote "TODO.md" file with a "Fix this!" in it and ... commited a sin... it 'fixed' the code to pass the test. It wrote to address 1 instead.
Next session I asked it to check the GCC docs and message lists and it found the reference to how GCC will just delete point access'es which are invalid... ie. 0... ie NULL.
Easy fixed, add the right flag for embedded raw access and no more problem. But it did open a new todo from me. "Split the build tools for bootload and kernel." Leave that flag OFF after the bootloader primes the hardware.
-
OTOH I mostly do code development in small functional blocks. I am extremely careful to not break existing code which has been thoroughly tested. For example I might want a CAN subsystem, and Claude came up with code in seconds which I can just drop in and which looks mostly usable.
If you have a workflow that's working for you great.
The difference with a local instance is the difference between "mostly usable" and "fully implemented and tested". For instance CC if you rewrite you CAN driver to use a port structure passed in as an argument instead of a global variable, CC could analyze the rest of the code, figure out where to store the port pointers, and update all the fall sites. Then build and, assuming you have the capability, test.
I've also found it very useful for generating tests. You can have it analyze a module that is mostly working to your satisfaction and generate a bunch of tests. While it generally does a good job, here I don't really care. The important thing is coverage, and now I can have the agent rerun the tests after every change. That allows it to fix simple bugs automatically, it to ask me if a change in behavior is a legitimate bug fix or a regression.
Again, if you have an approach that's working go with it. But if you get a chance to try the command line integration, I recommend it. I assume the editor plugins work well to but I haven't used them. I like the CLI because I can keep using the setup I already have and keep the AI agent as a separate window.
-
Honestly, neither it nor me seen this "mistake" in advance but claude got the bone and didn't stop. It decompiled the binary produced by GCC and looked at the ASM and realised half of it was completely missing. It even realised it was taking far too long so it just wrote "TODO.md" file with a "Fix this!" in it and ... commited a sin... it 'fixed' the code to pass the test. It wrote to address 1 instead.
Next session I asked it to check the GCC docs and message lists and it found the reference to how GCC will just delete point access'es which are invalid... ie. 0... ie NULL.
Easy fixed, add the right flag for embedded raw access and no more problem. But it did open a new todo from me. "Split the build tools for bootload and kernel." Leave that flag OFF after the bootloader primes the hardware.
Interesting - I tend to ask it to come up with a plan for solving a problem, and actually "discuss" the test-ideas and results - things like that would (hopefully) fall out in the planning stage - it still goes off and runs some programs etc to verify its plan but I think we feel out the problem first, and I think that helps . It's also possible, of course, that I might be benefitting more from this being a software effort than a firmware problem than I thought.
-
The difference with a local instance is the difference between "mostly usable" and "fully implemented and tested".
How can CC deliver tested code? The only possible way would be an interface to a hardware test harness etc. Obviously it is not doing that. You (the human dev) need to tell it "yeah I can see data" or "it looks dead", etc.
Whereas with web code it can run the generated HTML by itself.
-
The difference with a local instance is the difference between "mostly usable" and "fully implemented and tested".
How can CC deliver tested code? The only possible way would be an interface to a hardware test harness etc. Obviously it is not doing that. You (the human dev) need to tell it "yeah I can see data" or "it looks dead", etc.
Whereas with web code it can run the generated HTML by itself.
You can just give it tool access to the input/outputs. I like having it run tests using a basic harness. Use some creativity! All LLMs are is extremely enhanced autocomplete with pattern matching. They are as useful as you make them.
-
The difference with a local instance is the difference between "mostly usable" and "fully implemented and tested".
How can CC deliver tested code? The only possible way would be an interface to a hardware test harness etc. Obviously it is not doing that. You (the human dev) need to tell it "yeah I can see data" or "it looks dead", etc.
How do you test it?
If your only test criteria is "my human eyeballs see the light blink or the motor move" then yeah, that's going to require those eyeballs. But if you have any automated testing capability, CC can run that just fine. And if you don't, but you could CC can help write that. If that means loading a firmware image onto a device and then communicating over a serial port to check all the sensors behave correctly that certainly possible.
Even if you can't do any significant testing, having CC able to run the build process and check the output is already a huge help. It does make mistakes like using the wrong variable name or getting function arguments in the wrong order. I would generally rather it find those errors itself rather than make me do it.
-
You guys really build ATE jigs for your new products, and connect these to a PC with some sort of scripting language, so you can use CC to develop the code for it?
-
yeh, something like: I've seen this XX opensource project but I don't like the license, can you write something that does the same?
It's not even that, you have no idea where the code that Claude is extruding for you has come from. The reason I mentioned SCO vs. IBM is that they used tiny snippets of code, e.g. portions of atealloc, as their "evidence". So if you're using it for anything other than personal projects you at least need to have a policy about this, for example anyone who contributes AI-extruded code has to take ownership and responsibility for the code and certify that it's their creative work, not the AI's.
That may not be 100% accurate, it was from a long discussion over legal issues when using extruded code which isn't really my department so I wasn't taking notes. Our policy for now is human-written, human-vetted, human-committed, because there won't be any nasty surprises in the future. The scariest one would be a ruling that the copyright for extruded code lies with the data it was trained on, which will be a nightmare to go back through every code contribution for the last x years to figure out its provenance.
Gives classic example of human being (supposedly) violating copyright. A few sentences later, concludes that by limiting to human beings, "there won't be any nasty surprises". I'm astonished at this mental acrobatics - especially given how well-known the pattern of outright copypasting code out of Stack Overflow (without verifying where it come from, or what the license is) is - nearly everyone has done it, and nearly everyone does not admit it, or remember exactly if they did and when.
-
You guys really build ATE jigs for your new products, and connect these to a PC with some sort of scripting language, so you can use CC to develop the code for it?
Not sure what the acronym ATE means, but ... a serial port isn't that hard to link up. CC can probably do it for you (including bit-bang one if you don't have a spare UART :)
Once that's there, you have a bidirectional data-channel, at that point it's just instrumentation. Which CC can do quite happily. If you literally don't have any spare pins, CC can probably instrument via a logic-analyser that has a CLI interface. Salaea offer a socket-API for example, for which there's a python CLI.
-
Automatic Test Equipment.
One common form is a bed-of-nails fixture and you pop each board into it, press a button, etc. I've built a load of those over the years. Usually they connect to a box with ADCs DACs etc and a laptop driving it all. WinXP usually - only the most timeless will do ;)
I have actually given Claude a phone photo of a laptop screen showing a load of ARINC429 packets, and it worked out 99% of it.
-
You guys really build ATE jigs for your new products, and connect these to a PC with some sort of scripting language, so you can use CC to develop the code for it?
All of my microcontroller devices have a serial port, whether that is the main communication point or simply for diagnostics logging. That's all I'm saying.
And it's not "just" so I can use CC. It's because that's been the only sane way for me to do development for years.
Maybe I sounded more expansive when I said "fully tested" than I intended. I just meant that whatever you would normally do to make sure you didn't break something can be automated by an AI agent doing the same thing. Depending on your project you might still have real world functional testing that needs to happen. But as always with testing, a little bit is way better than none at all. The vast majority of bugs are simple, but even they can't be caught if the problematic code is not even executed.
-
OK; sure. I have a USB CDC VCP port, for debugs etc. So that can be accessible to an application running on the host PC. Normally it is Teraterm...
-
OK; sure. I have a USB CDC VCP port, for debugs etc. So that can be accessible to an application running on the host PC. Normally it is Teraterm...
Right. So if you tell CC that the device is connected on com8 or whatever, it will be able to create a test script using whatever serial port library / language you like and verify communication.
Then you could make a CLAUDE.md file that instructs it to, after every new feature, build a binary, load it with your flash dongle, and then connect over the serial port to check basic functionality.
-
Connect to serial.
> BIT
<system runs "built in test" and reports>
Claude runs this and the report output is in context.
It could be that simple.
-
You guys really build ATE jigs for your new products, and connect these to a PC with some sort of scripting language, so you can use CC to develop the code for it?
Maybe, in the future. Came across this on Github the other day: https://github.com/lollokara/BugBuster/tree/main
Yes, you can now have AI tell your voltage regulator is not set up correctly. Instead of multimetering your input and output voltages, just solder on a tons of wire and let AI do it for you.
Ofc it can't check wrong bad pin amps (ironically this device also has a pin map), intermittent connections, incorrect part mounts.. probably the most common mistake for any engineer...
OTOH if you need a DFM test jig anyhow, maybe you can recycle the hardware if its PC controlled anyway.
Inb4 someone puts Sensepeek like probes on a 4-axis table (XYZ+board flip) and have AI handle that for you, as well.
-
One thing I will mention is that you'll probably end up with a lot more regression tests that you're used to, or perhaps that's just me :)
The 6502 compiler has a testing framework with some 400 or so tests in it that test internal integrity of the build using ObjC code, and a 'fixtures' directory that contains some 107 files which collectively add 505 (as I write) regression tests. This is a project that's about 10 days old...
elysium:xtc % ls tests
codegen lexer run_fixtures.sh XTTestRunner.m
fixtures parser sema XTTestRunner.o
generate preprocessor XTTestRunner.d
elysium:xtc % ls tests/fixtures
ahl.xt included.xt shadow_ram.xt
asm_block.xt inline_params.xt shifts.xt
asm_var.xt inline-leaf-fn.xt sign_extend.xt
banked_call.xt inline.xt sort_qsort.xt
banked_xcall.xt inliner_ordering.xt stack_class.xt
byte_list_init.xt int_arith.xex stack_size.xt
cast_widen.xt int_arith.xt stale_x.xt
classes.xt irq_vbi.xt static_frame.xt
cloaked_hello.xt largevar.xt static.xt
cloaked_helper_promotion.xt length_prop.xt string.xt
cloaked_method_args.xt literal_widen.xt struct_byval_rvalue.xt
cloaked_transitive_clean.xt logops.xt struct_byval.xt
comments.xt loops.xt struct_copy.xt
constant.xt macro.xt struct_deref_field.xt
double_add.xt many-structs.xt struct_field_rvalue.xt
double_const.xt many-vars.xt struct_return_expr_large.xt
double_cvt.xt math_pow.xt struct_return_expr.xt
double_div.xt maths.xt struct_return_field.xt
double_math_lnexp.xt mixed_arith.xt struct_return_spill.xt
double_math_trig.xt modulus.xt struct_wide_field.xt
double_math.xt mul_u8u8.xt structs.xt
double_mul.xt multi-call.xt subscript_float.xt
double_ops.xt negative subscript_large.xt
double_pow_i16.xt numbers.xt subscript_member.xt
double_rand.xt overload_ambiguous.xt subscript_store.xt
double_sqrt.xt overload_class.xt subscript_struct.xt
enums.xt overload_widen.xt switch_stmt.xt
float_arith.xt overload.xt ternary.xt
fn_pointer.xt placement.xt test_retain.xt
funcptr.xt printf_call_arg.xt test_ARC.xt
global_init.xt printf_class.xt trig_range.xt
heap_basic.xt printf_cloaked_u16.xt va_arg_struct.xt
heap_multibank.xt printf_cloaked_u32.xt valist.xt
heap_retain.xt printf_double.xt varargs.xt
hello.xt printf_float.xt wide_args.xt
ifthen.xt printf.xt
include.xt printi32.xt
That's a fair amount of regression testing for such a young project, at least by my standards. Don't get me wrong, it's great. It's definitely an improvement over what I'd usually do by now :)
-
You guys really build ATE jigs for your new products, and connect these to a PC with some sort of scripting language, so you can use CC to develop the code for it?
Maybe, in the future. Came across this on Github the other day: https://github.com/lollokara/BugBuster/tree/main
Maybe it's not a bad idea, but those schematics are a headache to look at. I'm not trusting anything designed by someone who draws diagrams that messy. :palm:
-
It's gonna be fun when "AI" gets into PCB layout :)
-
It's gonna be fun when "AI" gets into PCB layout :)
Been discussed elsewhere and presently it is dire at the moment.
The issue is that schematics and pcb layout are "visual" and "spactial" which are their two greatest weaknesses.
-
Whereas with web code it can run the generated HTML by itself.
Interestingly, CC does not "look" at the HTML at all. No visually. It's entirely based on the frameworks like react abstracting a lot of it away.
On "enterprise' code in business claude has an advantage. In that space making code as consistent as possible is very proveilant. So it's a good thing when the code all looks the same.
"Cookie cutter" is the name for it. Cookie cutter webapis have got such good tooling these days it was almost completely autogenerated before we had Claude. In fact there are now debates on whether we should abondon such "Spec->Code" generation layers, if we can just use CC to generate the code. These people are failign to understand what "Spec->Code" generation gives you that claude generation doesn't. Deterministic output.
-
Interestingly, CC does not "look" at the HTML at all. No visually.
That is surely useless. So many websites have weird browser version compatibility issues. And it looks like not many coders give a toss.
Perhaps not really on the "embedded" topic but you might well have a web server in your product. I have one; it was quite a bit of work but Claude was not around then. It hooks into LWIP (uses its netconn API rather than sockets) in a primitive way and generates the simplest possible HTML (from my C code - what else?) to produce simple text menus, and I paid some guy on freelancer.com to write some javascript which runs client-side and implements stuff which is not possible with plain HTML e.g. a progress bar on file uploads (a browser gives you a % progress on downloads).
-
Oh devs give a toss alright. The only things that make browser apps feasible are frameworks like Angular and React. Also smaller things like JQuery and such like. These handle the browser specifics.
Most modern HTML pages are 'responsive' anyway. So the actual layout depends on your font size, zoom level, screensize etc. Some people see 4 columns, some see 2.
-
I know how it is supposed to work but the reality is that many websites have little bits that are broken with browser x and not with browser y. Or tightly browser version dependent.
I probably know just enough about this to know that there is really no need for such issues. I "run" a site which was done c. 2010 and which is fully functional today. It uses the Bootstrap (ex twitter) style sheet package.
I accept that few people want to spend much time on this and most just want to drop in some library ("framework").
-
I know how it is supposed to work but the reality is that many websites have little bits that are broken with browser x and not with browser y. Or tightly browser version dependent.
I probably know just enough about this to know that there is really no need for such issues. I "run" a site which was done c. 2010 and which is fully functional today. It uses the Bootstrap (ex twitter) style sheet package.
I accept that few people want to spend much time on this and most just want to drop in some library ("framework").
It looks that way to you, because you are on a PC as old as your website. Most people are not.
Put bluntly. You live in a self created bubble where the world stands still and software stays static. In the real world, the browsers update basically weekly, the operating systems update nearly daily. Some corporations are legally required to be on the latest and greatest.
So React/Angular and JQuery update almost constantly, but also tend to take large jumps. So 1.1 -> 1.2 fine. 1.7->2.0 half rewrite. Stay on 1.x and lose modern browser quirk support.... and eventually security fixing.
On testing. There are not 2 or 3 browsers. There are an infinite number of combinations, that are barely restricted by browsers. The "standard" they implement are almost always varied in some way so they don't work exactly like each other. Testing those webapp frameworks requires thousands of people.
Also.... Why do you not just add a webserver to your own application?
You can. It's a common approach in most Java applications, for instance. They use Jersey or similar micro-webserver component for the main HTTP handlers. Most Microsoft stack stuff uses the DotNet HTTPListener stack.
If you mean write it yourself, you need to make sure it's secure. If you want "normal" people to access it, you have to be aware that without HTTPS normal Joe is going to get nervous when it says, "Your connection is insecure!" A lot of modern browsers will just immediately change HTTP to HTTPS and your user gets a "Connection refused" on port 443. So you will need to HTTPS it to stop that nasty warning. If you use a self-signed cert, the user will get a worse error saying you are not who you say you are. A proper HTTPS certificate for your MCU project is going to cost you at least $200. Or you could use "LetsEncryupt" and update it every 90 days.
In fact if you want your HTTP server, flashed on your micro to have ANY security certificates, you will need to pay hansomly for "long lived certs", like 10 years. Your device still bricks after that. If you want/need HTTPS and certs your micro has no choice, but to implement a full CertAuth resigning/cert request renewal process.
Give it a wide open, authless, HTTP port and an admin interface and no professional network will want it near them.
Then there is IPs and DNS names. How are you going to handle that? What IP does the device get in the users environment? How can you point a DNS name at it? What do you tell users to put in the URL?
Being honest. Your best option would be to make the MCU an HTTPS "client". HTTPS or whatever you want to communicate with your backend as client. Then do the web layer somewhere you have proper mutable access and supporting infra. Yes, I know that today that means cloud for most wide distribution products.
This is made simplier by choosing a form of "Middleware". Like MQTT or other message bus. Then you have a single point of integration shared by all distributed components.
-
I don't actually live in a bubble, but I have my own business, so have no incentive to waste time (like employees do, at least in the short term) so if something works I run with it :)
I deal with the "latest sw compliance box ticking" all the time. I still regard inadequate browser compliance checking as arrogant and negligent. And that's before we reach the full "win11 screwing" scenario (chrome still fully updates on win10) where millions have to chuck out their PCs and laptops to run this latest POS just to get a browser which they can use for their banking etc...
If you mean write it yourself, you need to make sure it's secure. If you want "normal" people to access it, you have to be aware that without HTTPS normal Joe is going to get nervous when it says, "Your connection is insecure!" A lot of modern browsers will just immediately change HTTP to HTTPS and your user gets a "Connection refused" on port 443. So you will need to HTTPS it to stop that nasty warning. If you use a self-signed cert, the user will get a worse error saying you are not who you say you are. A proper HTTPS certificate for your MCU project is going to cost you at least $200. Or you could use "LetsEncryupt" and update it every 90 days.
In fact if you want your HTTP server, flashed on your micro to have ANY security certificates, you will need to pay hansomly for "long lived certs", like 10 years. Your device still bricks after that. If you want/need HTTPS and certs your micro has no choice, but to implement a full CertAuth resigning/cert request renewal process.
Give it a wide open, authless, HTTP port and an admin interface and no professional network will want it near them.
We went through this when developing this last box. There is no perfect solution (to anything really).
The time may come when Chrome will not work with an http target. Then other browsers may need to be used. Probably Firefox will run for much longer. As you say, the https certificate has no permanent solution.
If this ever becomes a problem then we may have to do something else, like map the http interface to USB VCP and then people can run Teraterm or whatever. It has no graphics. Well, there is a favicon, all coded in C :) :) :)
The http server has a username+pwd, btw, plus can be turned off in a config file (on the USB MSC volume), plus can be restricted to one client IP, and has a timeout. Fine for remote access via a VPN whose LAN IP is known and fixed.
We did have an https server on there, done with MbedTLS, and a self signed certificate, but a self signed cert is arguably worthless for the same reasons you give. A given browser could refuse it for the same reason. I actually think there is a greater risk of Browser X refusing https with a self signed cert, than refusing http (on what is obviously a local network IP). In the end, due to finite RAM, we decided to do the http server instead. It took only a day to do the https server, with Cube MX, to a level good enough to impress the boss and nothing else useful, which sums up MX pretty well.
Back to Claude, I can see one could connect Claude up to this, but that will work only if it is more or less all working and Claude is doing other odds and ends.
-
Slight tangent, but re the Lets Encrypt and 90 days mentioned in the post above. Isn't it the case that paid for certificates will be need to be reissued every 47 days in a couple of years time?
-
Yes the whole trend in this game is for certs to have a short life, so you need a cron job to keep getting new ones, and you need to pay a good server admin (from Poland, Ukraine, etc :) ) to fix it every time the cron job breaks and your customers moan that your site is insecure ;)
I have this on one server already. For others I use Cloudflare and they take care of it. Not possible on embedded...
-
I have this on one server already. For others I use Cloudflare and they take care of it. Not possible on embedded...
That is the middle ground most people who can host remotely end up in. When looking at a genuine "first level" cert you are talking hundreds of dollars and that has renewal costs every few years too.
Hosting on AWS or Azure however and you can get a sub-cert for your domain added to the AWS master cert. This cert is enough to validate your website IS the domain it says it is and that a server responsible for it served you the request. It does NOT verify you as a business or any "identity" beyond the domain name though. It's 99% sufficient for most needs though.
A cloud proxy like cloudflare can also 'HTTPS' wrap requests and even "main in the middle" them with custom self-signed certs.
If your user base are "within your control", such as on a business LAN, a self-signed cert can be used and "force imported" onto users corporate machines. Or just require them to install your CA root cert into the browser.
Within the foot print of a small Micro, like not an H7. The "self renew" system might be doable. Just add a "Cert update" admin page to the web ui, that lets you upload the new cert. This will become a problem for highly distributed products of course and for those you need it to be automatic. The device will want to "phone home" periodically and check for a certificate renewal.
Did you hard code a changable IP like 192.168.1.1 like every router out there? Or did you attempt DHCP? For DNS there is mDNS which a lot of browsers support and is "peer to peer" all nodes are client and server and they self distribute new-comers. So your device has it's own DNS and others can ask it, "WHat are you called?" It means your host names all end in ".local" though and I believe it's limited to the broadcast domain.
-
I have an automatic check for a new cacert.pem and an auto update. So that takes care of the https client functionality (the box can authenticate the server).
Did you hard code a changable IP like 192.168.1.1 like every router out there? Or did you attempt DHCP? For DNS there is mDNS which a lot of browsers support and is "peer to peer" all nodes are client and server and they self distribute new-comers. So your device has it's own DNS and others can ask it, "WHat are you called?" It means your host names all end in ".local" though and I believe it's limited to the broadcast domain.
The box can do either DHCP or user defined fixed.
-
We are getting off topic, but in professional networks, that class of device, like routers, switches, wifi gizmozs and anywhere "hardware" provided interfaces are involved, they are quarantined into a VLAN or in some cases a separate physical network with airgap, at least on the "Admin" side of things.
This means that nobody stumbling around on 'user networks' will find it and anyone deliberately looking for it will need to get through the firewall or do some funky VLAN hackery.
Most of those kind of devices support putting the admin interface onto a VLAN specifically, or having two physical network ports. One for "normal use" and the other for "Admin only."
Just throwing ideas at you.
-
On clauding for embedded.
Background: My "soft DSP on STM32H7" is acting up and the drivers PC side no longer seem to cover it. The DSP SAI code, I suspect, it not handling the "Frame ailgnment, overrun, underrun etc. etc." errors on the channels. So if the frame alignment slips, my code just carries on regardless. A solution "might" be the reset the SAI channel when this is detected and force realignment, causing a "click", but only one of them.
So I have prompted claude this morning with nothing but:
This code has been running on my STM32H7 'soft' DSP for a few years. It has an issue. The I2S frame alignment slips, causing poor stereo spearation and "fizzling" and "clicking".
Claude took about 15 minutes. About 1:28 to produce the inserted spec (below) of what the code does. Then the rest to "think" things through.
It resulted in this:
● Now I have a clear picture. Let me explain the root cause and then fix it.
Root Cause
There are two bugs that conspire to cause frame slip:
1. SAI_FIFOTHRESHOLD_FULL on the receiver (main.c:279): The FREQ interrupt fires when all 8 FIFO slots are full. The ISR reads only 2, leaving 6. The "margin" before
overflow is just 2 more samples (~42µs at 48kHz stereo). Any brief ISR latency overflows the FIFO.
2. OVRUDR (overrun) interrupt is not enabled or handled: When the FIFO overflows, SAI_xSR_OVRUDR is set and incoming samples are discarded. Without handling it, the
code keeps reading stale data from the frozen FIFO. Per the STM32H7 reference manual, clearing OVRUDR resumes from "the next audio frame" — the hardware re-locks to
WS and starts at slot 0 (L) again — but since nobody clears it, the FIFO contents are undefined and L/R alignment is permanently broken until power-cycle.
The fix has three parts: reduce the threshold to make overflow nearly impossible, enable OVRUDR, and handle it with a FIFO flush + clear.
● Update(Core/Src/main.c)
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Edit file
Core/Src/main.c
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
276 hsai_BlockA1.Init.AudioMode = SAI_MODESLAVE_RX;
277 hsai_BlockA1.Init.Synchro = SAI_ASYNCHRONOUS;
278 hsai_BlockA1.Init.OutputDrive = SAI_OUTPUTDRIVE_DISABLE;
279 - hsai_BlockA1.Init.FIFOThreshold = SAI_FIFOTHRESHOLD_FULL;
279 + hsai_BlockA1.Init.FIFOThreshold = SAI_FIFOTHRESHOLD_1QF;
280 hsai_BlockA1.Init.SynchroExt = SAI_SYNCEXT_DISABLE;
281 hsai_BlockA1.Init.MonoStereoMode = SAI_STEREOMODE;
282 hsai_BlockA1.Init.CompandingMode = SAI_NOCOMPANDING;
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Do you want to make this edit to main.c?
❯ 1. Yes
2. Yes, allow all edits during this session (shift+tab)
3. No
Esc to cancel · Tab to amend
I haven't even run CubeMX, it's not installed. Proving it's correct will be a challenge for me as I have not "tooled up" this project in years.
From here the post is "by claude" (markup mistakes and all):
============================================================================================
Background: This code has been running on my STM32H7 'soft' DSP for a few years. It has an issue. The I2S frame alignment slips, causing poor stereo separation and "fizzling" and "clicking".
I ran Claude Code's codebase analysis over it. Here's what it found:
[spoiler=Claude Code Full Analysis]
COMPREHENSIVE ANALYSIS: STM32H7 DSP AUDIO CODEBASE
1. PROJECT STRUCTURE & OVERVIEW
Directory Layout:
- /mnt/homes/paul/devel/stm32/MixAndEQ/Core/ — Application code
- /mnt/homes/paul/devel/stm32/MixAndEQ/Drivers/ — HAL drivers
- Project: STM32H743VIT6 microcontroller
- Architecture: Cortex-M7 with floating-point DSP
- Audio Sample Rate: 48 kHz
- Data Format: 16-bit signed integer samples
Key Files:
- Core/Inc/SAI.h (lines 1-17)
- Core/Src/SAI.c (lines 1-96)
- Core/Src/main.c (lines 1-602)
- Core/Src/stm32h7xx_it.c (lines 1-399)
- Core/Src/stm32h7xx_hal_msp.c (lines 1-616)
2. I2S/SAI AUDIO INTERFACE CONFIGURATION
SAI Blocks Configured:
1. SAI1 Block A (Input/Receiver) — main.c:275-291
- Mode: SLAVE_RX (receives audio)
- Protocol: I2S Standard
- Data Size: 16-bit extended
- Stereo Mode: Enabled
- Synchronization: Asynchronous
- GPIO Pins (stm32h7xx_hal_msp.c:366-376): PE4: SAI1_FS_A, PE5: SAI1_SCK_A, PE6: SAI1_SD_A
2. SAI2 Block A (Output/Transmitter, Master) — main.c:309-323
- Mode: MASTER_TX (transmits audio, provides clock)
- Protocol: I2S Standard
- Data Size: 16-bit
- Audio Frequency: 48 kHz
- NoDivider: Enabled
- FIFO Threshold: Half-full
- Stereo Mode: Enabled
- GPIO Pins (stm32h7xx_hal_msp.c:403-413): PD11: SAI2_SD_A, PD12: SAI2_FS_A, PD13: SAI2_SCK_A
3. SAI2 Block B (Output/Transmitter, Slave) — main.c:324-336
- Mode: SLAVE_TX (secondary transmit, synchronized to Block A)
- Protocol: I2S Standard
- Data Size: 16-bit
- Synchronization: SYNCHRONOUS (synced to Block A)
- FIFO Threshold: Empty
- Stereo Mode: Enabled
- GPIO Pins (stm32h7xx_hal_msp.c:439-447): PA0: SAI2_SD_B
4. SAI3 Blocks A & B (Additional I/O) — main.c:348-387
- Both configured as SLAVE_RX (receivers)
- Asynchronous operation
- GPIO pins configured but not actively used in ISR
3. DMA CONFIGURATION & BUFFER LAYOUT
BDMA (Backup DMA for SAI) — Not Actively Used for Audio:
- main.c:489-503
- BDMA_Channel0_IRQn and BDMA_Channel1_IRQn enabled but NOT linked to SAI
- Used only for SPI6 (peripheral communication, not audio)
DMA1 (Standard DMA) — Used for UART Debug Output:
- main.c:508-519
- DMA1_Stream0 for USART1_TX (debug output only)
- Not used for SAI audio transfers
Audio Buffers (Small, Interrupt-Driven): — SAI.c:13-16
- rx1Buffer[8] — 8x 32-bit words (32 bytes) in DTCM RAM
- rx2Buffer[8] — 8x 32-bit words (32 bytes) in DTCM RAM
- tx1Buffer[8] — 8x 32-bit words (32 bytes) in DTCM RAM
- tx2Buffer[8] — 8x 32-bit words (32 bytes) in DTCM RAM
Buffer Placement: .dtcm_section (Data Tightly Coupled Memory) — fastest on-chip RAM for low-latency audio processing.
4. I2S INTERRUPT HANDLERS & FIFO-BASED OPERATION
SAI1 Interrupt Handler (Receiver) — stm32h7xx_it.c:308-329
void SAI1_IRQHandler(void)
{
// GPIO flag for debug/monitoring
HAL_GPIO_WritePin(RxIT_GPIO_Port, RxIT_Pin, GPIO_PIN_SET);
// Check if FIFO interrupt occurred (SAI_FREQ)
uint32_t itflags = hsai_BlockA1.Instance->SR;
uint32_t itsources = hsai_BlockA1.Instance->IMR;
if (((itflags & SAI_xSR_FREQ) == SAI_xSR_FREQ)
&& ((itsources & SAI_IT_FREQ) == SAI_IT_FREQ)) {
// Custom handler: read data directly
SAI_Rx_Interrupt(&hsai_BlockA1);
} else {
// Fallback to standard HAL handler
HAL_SAI_IRQHandler(&hsai_BlockA1);
}
// Clear debug flag
HAL_GPIO_WritePin(RxIT_GPIO_Port, RxIT_Pin, GPIO_PIN_RESET);
}
SAI2 Interrupt Handler (Transmitter) — stm32h7xx_it.c:334-352
void SAI2_IRQHandler(void)
{
HAL_GPIO_WritePin(TxIT_GPIO_Port, TxIT_Pin, GPIO_PIN_SET);
uint32_t itflags = hsai_BlockA2.Instance->SR;
uint32_t itsources = hsai_BlockA2.Instance->IMR;
if (((itflags & SAI_xSR_FREQ) == SAI_xSR_FREQ)
&& ((itsources & SAI_IT_FREQ) == SAI_IT_FREQ)) {
SAI_Tx_Interrupt(&hsai_BlockA2);
} else {
HAL_SAI_IRQHandler(&hsai_BlockA2);
HAL_SAI_IRQHandler(&hsai_BlockB2);
}
HAL_GPIO_WritePin(TxIT_GPIO_Port, TxIT_Pin, GPIO_PIN_RESET);
}
Custom Interrupt Handlers — SAI.c:21-45
// Receiver (SAI1): read 2x 32-bit samples from SAI FIFO
void SAI_Rx_Interrupt(SAI_HandleTypeDef *hsai) {
for(int i=0; i<2; i++) {
rx1Buffer[i] = hsai->Instance->DR;
}
}
// Transmitter (SAI2): copy, EQ-process, write back
void SAI_Tx_Interrupt(SAI_HandleTypeDef *hsai) {
for(int i=0; i<2; i++) {
tx1Buffer[i] = rx1Buffer[i];
tx2Buffer[i] = rx1Buffer[i]; // Duplicate to both outputs
}
EQ_RunOne(tx1Buffer); // EQ chain 1 (3 bands)
EQ_RunTwo(tx2Buffer); // EQ chain 2 (5 bands)
// 4 samples = 2 stereo pairs per interrupt
for(int i=0; i<4; i+=2) {
hsai_BlockA2.Instance->DR = ((uint16_t*)tx2Buffer)[i]; // Block A output
hsai_BlockB2.Instance->DR = ((uint16_t*)tx1Buffer)[i]; // Block B output
}
}
Interrupt Flags:
- SAI_IT_FREQ — FIFO Request Interrupt (triggers on FIFO threshold)
- SAI_IT_WCKCFG — Word Clock Configuration error — Enabled on SAI2 Tx only (SAI.c:79)
5. STEREO CHANNEL HANDLING
Channel Extraction & Processing — EQ.c:115-144
void EQ_Run(uint32_t *buf, PeakFilter_t eqFilters[][2], int bands, float *volume) {
int16_t *buffer = (int16_t*)buf;
// LEFT CHANNEL (index 0)
AnalysisBuffer_Update(&inputL, buffer[0]);
sample = buffer[0] * scale; // Convert to float [-1.0, +1.0]
sample = sample * gain;
for(int band=0; band<bands; band++)
sample = PeakFilter_Update(&eqFilters[band][0], sample);
buffer[0] = sample / scale;
// RIGHT CHANNEL (index 2)
AnalysisBuffer_Update(&inputR, buffer[2]);
sample = buffer[2] * gain;
for(int band=0; band<bands; band++)
sample = PeakFilter_Update(&eqFilters[band][1], sample);
sample = rolloverProtect(sample, &gain);
buffer[2] = sample;
}
Key observations:
- Stereo samples arrive as: [L_sample, ?, R_sample, ?] (32-bit pairs)
- Left channel: array index
- , Right channel: array index [2]
- Each channel processed through independent filter arrays
- EQ1: 3 peaking bands (80 Hz, 2 kHz, 10 kHz)
- EQ2: 5 peaking bands (40 Hz, 80 Hz, 800 Hz, 2 kHz, 10 kHz)
6. AUDIO PROCESSING PIPELINE
Data flow:
[list=1]
- Reception (SAI1_IRQHandler → SAI_Rx_Interrupt): Audio arrives at SAI1 Block A (slave RX). FIFO threshold interrupt triggers when data is ready. Raw samples loaded into rx1Buffer/rx2Buffer.
- Processing (SAI2_IRQHandler → SAI_Tx_Interrupt): Triggered by SAI2 transmitter FIFO space. Copy rx to tx buffers. Apply EQ_RunOne() (3-band) and EQ_RunTwo() (5-band). Update analysis buffers in interrupt context.
- Analysis (main loop, main.c:169-181): AnalysisBuffer_Process() downsamples 48 raw samples → 1 peak/RMS. AnalysisBuffer_ProcessMS() further downsamples 48 values → 1 final peak/RMS in dB. Results sent via SPI to external controller.
- Transmission (SAI2_IRQHandler → SAI_Tx_Interrupt): Write processed samples to SAI2 Block A & B FIFO. Block A = master output (generates frame sync/clock). Block B = slave output (synchronised).
Sample size & timing:
- 48 raw samples per analysis window @ 48 kHz = 1 ms audio
- 48 × 1 ms values = 48 ms analysis window
7. FRAME SYNC & WORD SELECT (WS) HANDLING
[list=1]
- SAI1 (Receiver) — main.c:277: SAI_ASYNCHRONOUS. External frame sync expected from I2S source. No recovery logic implemented.
- SAI2 Block A (Master Transmitter) — main.c:311: SAI_ASYNCHRONOUS. Generates its own frame sync and clock. SAI.c:79 enables SAI_IT_WCKCFG interrupt for word clock config error monitoring.
- SAI2 Block B (Slave Transmitter) — main.c:326: SAI_SYNCHRONOUS. Synchronises to Block A's clock and frame sync.
WS detection/recovery: SAI_IT_WCKCFG flag enabled on transmitter (SAI.c:79). No explicit recovery code visible; relies on HAL_SAI_IRQHandler for error handling. GPIO debug pins (RxIT/TxIT on GPIOE pins 0-1) used to monitor interrupt timing.
8. BUFFER MANAGEMENT DETAILS
Small audio buffers (interrupt domain):
- 8-element arrays (32 bytes each) in DTCM RAM
- Direct access in interrupt context — no synchronisation
- No overflow handling; overwrites stale data
Large circular buffers (SPI data channel):
- 8 buffers × 2048 bytes = 16 KB total
- Head/tail pointers for async producer-consumer
- Protected with __disable_irq() / __enable_irq() in critical sections
- Used for command/response over SPI6 (not audio streaming)
Analysis buffers:
- Per-channel peak/RMS tracking
- Double-buffering: samples1/samples2, msPeak1/msPeak2, msRMS1/msRMS2
- No locks needed (single producer in ISR, single consumer in main)
9. DMA CONFIGURATION SUMMARY
Audio streaming does NOT use DMA — all transfers are interrupt-driven via FIFO thresholds (low latency, small 8-sample buffers).
DMA used for:
[list=1]
- SPI6 (control/stats): BDMA_Channel0 RX, BDMA_Channel1 TX (stm32h7xx_hal_msp.c:149-182)
- USART1 (debug output): DMA1_Stream0 TX (stm32h7xx_hal_msp.c:270-287)
10. KEY FILES SUMMARY
File Purpose Lines
-----------------------------------------+------------------------------------------+---------
Core/Src/SAI.c I2S interrupt handlers, buffer management 1-96
Core/Src/main.c System init, SAI/DMA/GPIO config, main loop 1-602
Core/Src/stm32h7xx_it.c Interrupt dispatcher, WS error detection 308-352
Core/Src/stm32h7xx_hal_msp.c SAI/SPI/UART pin config, DMA setup 337-515
Core/Src/EQ.c Stereo EQ processing, channel separation 115-150
Core/Src/AnalysisBuffer.c Peak/RMS tracking per channel 1-109
Core/Src/PeakFilter.c BiQuad peaking EQ filters 1-49
11. CRITICAL INTERRUPT PRIORITIES
- SAI1_IRQn: Priority 0, subpriority 0 (highest — audio input)
- SAI2_IRQn: Priority 0, subpriority 0 (highest — audio output)
- BDMA_Channel0/1_IRQn: Priority 1 (SPI control)
- USART1_IRQn: Priority 0 (debug, low traffic)
12. POTENTIAL ISSUES & NOTES
[list=1]
- No DMA for audio: Uses small FIFO-based interrupt transfers (8 samples at a time). Works for low latency but no buffering resilience.
- Stereo channel indexing (EQ.c:120, 134): Hard-coded indices
- and [2] assume specific sample layout. Brittle — any frame slip causes L/R swap or corruption.
- No overflow protection: If SAI2 Tx interrupt doesn't fire frequently enough, FIFO can overflow. Debug via GPIO flags (lines 311, 326, 337, 350).
- WS/Frame sync (SAI.c:79): Only transmitter monitors word clock config errors. Receiver relies entirely on external master stability.
- Rollover protection (EQ.c:98-113): Hard limiter on right channel only (line 141); left channel limiter is commented out (line 130).
- Analysis buffer latency: 48-sample window @ 48 kHz = 1 ms, plus 48 ms aggregation = ~49 ms stats delay.
[/spoiler]
-
On the tooling question. I'm going to explore claude's ability to "port" this project out of CubeMX and into, PlatformIO or cmake, so I don't need to install CubeMX and that whole shinanegans to fix this.
Update: It's encouraging. Suggests CMake exports as an easy "today" step one. STM32Programmer is fine for flashing, but with the CMake export it doesn't need you to run CubeIDE or CubeMX.
More interestingly... I asked it about it replacing CubeMX and gave it the scenario where CubeMX does well. Remapping the pins to alt functions when you want to layout the PCB and have constraints and conflicts.
It's response including reflections on where it can do well and where to be careful. It pointed out that the STM32 alt function tables are well represented in training data, but for less common, obscure peripherals or smaller, LP packages the numbering can be out, so it needs verification.
It also suggested creating an excerpt of the actual dataset and grounding claude with it rather than training data. "Using this AF table..."
It's quite new for them to be that "meta aware" outwardly and call themselves out on where not to trust them. We have been asking for this and it might be starting to arrive.
EDIT: As an asides... If you even check claudes final bullet list only... it found the bodies.
-
Why can't you just write code by yourselves?
-
That is what I do.
I use Claude (not CC) to generate code as required for some well defined functionality. But this is after I have created the project file(s), the overall framework, set up the RTOS tasks, etc.
The usage suggested in this thread seems to be a huge amount of work to set up, and then you have to extremely carefully check all the code - because it has been generated without much involvement from you. The setup to work interactively with CC is also going to be hard to archive, so a re-visit in a few years' time is probably going to be impossible without doing it all again.
I think this "interactive CC" is probably good for scenarios where you inherently generate vast amounts of code, which you don't really understand in detail and don't really want to. The most obvious common example would be server-side website coding. In the embedded sphere, one tends not to write huge amounts of incomprehensible code, but anything to do with wifi or bluetooth is still pretty horrible (a lot of code and almost certainly you won't care much about the detail). USB is not much better.
In most embedded work you need to know the detail.
-
The amount of work it was for me to set up was:
1) open Terminal.app and type 'curl -fsSL https://claude.ai/install.sh | bash'
2) type 'claude'
Like most Mac developers, I have homebrew already installed, but if you don't, and it you also don't have npm installed as well, there's another couple of steps
1.3) install homebrew with /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
1.6) type 'brew install npm'
That's it. The two long and scary commands are copy-pasted from the "how do I install X" google query, where X = {claude code|homebrew}. They're one-offs. After their install, it's just "claude" to run Claude Code, or "brew install xxx" to install a package.
Compared to the horrors of having to edit python scripts to get around the lack of an adequate Java installation to get STCube installed (shudder), this was utterly painless, and took about 5 mins.
AI-derived code, like any code you didn't write yourself, needs to be looked over and you have to verify that it does the job. The thing is, you have an AI for that. So instead of laboriously going through every line, ask it to write regression tests to cover X, Y for all inputs A,B,C and actually test how the code works. When/If it fails, tell it to fix it. A few dozen rounds of that, with the AI finding and reporting related bugs, and you'll have a lot of regression tests.
Example: on my 6502 simulator, the AI suggested I download Klaus Dormann' 6502 regression suite. I agreed and asked it to write a fixture test to run them all. It did, and reported one issue with the BCD status register flag, and fixed it.
Then it suggested I download Tom Harte's signal waveform tests, so I asked it to, and it compared every opcode's bus waveform to known-good examples for every addressing mode. 100% pass, which gives me a reasonably warm and fuzzy feeling that this completely-machine-generated 6502 core is probably up to spec.
As for "so a re-visit in a few years' time is probably going to be impossible without doing it all again", again I don't agree. The AI will scan your source directory in seconds (maybe minutes, if it's truly huge) and be ready to rock and roll pretty shortly afterwards. It has memory (stored in files in the directory) of what it did last time, and notes on implications and user preferences etc. You'd be up and running in no time.
I don't agree with pretty much anything in your last paragraph either. I think there's quite a bit of copium being expressed there, sorry. I can honestly say I've never used the AI tools for web stuff. Everything I've asked it to do is in the embedded / embedded-related field. That 6502 core is on an RP2354, and it has PIO code to manage bus waveforms, DMA'd to the CPU core running on 1 ARM core with a logger/debugger running on the other. I didn't code any of it.
I'm still not sure if you've actually tried Claude Code, or if you're still talking about the red-headed step-child that is the web version...
-
Why can't you just write code by yourselves?
I can till the soil and grow my own food too but why would I?
-
I predict coding will be like carpentry in a few years. Many people will just run to IKEA and buy a 10$ table that is actually made of cardboard. It works although its not the most sturdy, not the most durable, etc.
Want a solid wood table? Pay €€.
Want it custom-made for your space? Pay €€€.
Or do it yourself.
Roll back time 100-200 years ago. There was no IKEA etc. Perhaps coding will undergo a similar transformation. Especially in embedded, we have everything custom, people roll their own protocol stacks, a lot of 'not invented here' syndromes (myself included).. I think that will have to change.
When new AI's become pro's at stabbing CVE 9/10 security holes within minutes, I expect that will be the primary focus soon.
IMO having tried coding like this, I do see the upsides: its like having an extra junior programmer while you work on other things. I also had it write some Rust code for a library I wanted to use (on desktop). When it was 90% there, I just filled in the gaps it left behind.
Otherwise I would have had to learn Rust, understand how cargo works, how dependencies are managed, how tests are ran, how to make the borrow checker happy, etc. So just that it saved me a lot of time. But I also missed out on a few skills by making this choice (learning Rust ground up).. although I perhaps chose not to do this project at all.
Now, I still have my "first Rust project", even though I didn't write 90% of it. Though it is not fun at all to be staring at 2-3 prompts and wait till they are done generating.
-
I predict coding will be like carpentry in a few years. Many people will just run to IKEA and buy a 10$ table that is actually made of cardboard. It works although its not the most sturdy, not the most durable, etc.
Want a solid wood table? Pay €€.
Want it custom-made for your space? Pay €€€.
Or do it yourself.
I've actually had pretty good luck getting things custom-made for cheap.
For example this little trolley thing.
[attach=1]
I got it made almost 30 years ago to house a PowerMac 8500 mini-tower, obviously long since pensioned off, but it started as a 120 MHz PPC 604, had a couple of 604e upgrades and eventually a 450 MHz G4.
Anyway, I wandered into a local office furniture place that I guess was usually making custom reception desks and the like, drawing in hand.
"What do you want it made from?" "Do you have any off-cuts?" He wanders out the back, comes back with two items. "Do you mind if the top is a different shade to the sides?" "Not in the least" "Do you need it in a hurry?" "Nope".
I can't remember now what I paid, but I don't think it can have covered more than an hour of labour plus the wheels and steel brackets in the corners. The wood must have been free, or damn near.
Very sturdy little unit. The 60 kg of LFP batteries & electronics sitting on top of it now doesn't trouble it in the least.
That's far from the only thing I've had made or repaired at very little cost. In 2018 I got a workshop in Kerikeri (ok Waipapa) to make up an aluminium adaptor from a standard photo tripod to a drawing board for my then wife to do sketches in the field. In 2011, in the same week I shot https://www.youtube.com/watch?v=_xrsNm9kJ5s (https://www.youtube.com/watch?v=_xrsNm9kJ5s) my BMW motorcycle fell over when the centre-stand sunk in soft ground, breaking one of the brackets for the panniers. Early next morning I rode 30 km into Taihape, found a truck / farm equipment workshop just opening. They let me use their tools to remove the rear wheel, seat, bodywork, some cables, so they could get in safely with a welder for a couple of minutes in the middle of doing whatever they were doing. IIRC he refused to take any payment.
There are no doubt people on this board with a well-equiped home workshop who could have done these things themselves. I don't have one. But I've found if you approach commercial places with a plan and a smile and make it easy for them to minimise their time involvement you can get things for very little outlay.
Getting back to LLMs, I find them good at researching some details when I already know what I want to do well enough that I could call Joe, who knows that stuff, and ask "how would you do ... X in Y?". A pretty big time-saver compared to poring through manuals and data sheets.
I haven't yet trusted them with the whole job.
-
Why can't you just write code by yourselves?
Where do you write yours? Notepad? Do you use any CASE tools? Where is your line?
-
That is what I do.
I use Claude (not CC) to generate code as required for some well defined functionality. But this is after I have created the project file(s), the overall framework, set up the RTOS tasks, etc.
The usage suggested in this thread seems to be a huge amount of work to set up, and then you have to extremely carefully check all the code - because it has been generated without much involvement from you. The setup to work interactively with CC is also going to be hard to archive, so a re-visit in a few years' time is probably going to be impossible without doing it all again.
I think this "interactive CC" is probably good for scenarios where you inherently generate vast amounts of code, which you don't really understand in detail and don't really want to. The most obvious common example would be server-side website coding. In the embedded sphere, one tends not to write huge amounts of incomprehensible code, but anything to do with wifi or bluetooth is still pretty horrible (a lot of code and almost certainly you won't care much about the detail). USB is not much better.
In most embedded work you need to know the detail.
All I can say is that I do embedded work as a hobby to give myself a break from the sheer scope and depth of the day job. To write software for a bank, insurance company, logistics company, stock exchange or government... i need to understand their systems FAR better than they do. I need to know how everyone else does their job so I can do mine.
Embedded is like a green field meadow with a bubbling brook to me.
If you think an MCU or IC datasheet and reference manual is difficult, try something like a multi-leg strategy cross order risk analsyis. You have < 10uS. Trillions of dollars will flow through it. They WILL notice tiny aggregate errors and a single race condition causing incorrect numbers and the entire exchange "freezes" and stop trading until its fixed at the cost of millions per minute.
The details matter.
-
Where do you write yours? Notepad? Do you use any CASE tools? Where is your line?
Usually in an IDE, which one depends on language and toolchain.
GUI editors like in QtCreator and in Lazarus plus a decent autocomplete pass for CASE tools for me.
However, this is not for embedded development.
Using CubeMX for initial configuration of a project is probably closest to the subject.
-
Why can't you just write code by yourselves?
Where do you write yours? Notepad? Do you use any CASE tools? Where is your line?
Emacs, ever since I got x86 Linux, and an ancient SPARC ELC, and then Mac MkLinux (1995) then Rhapsody (1997) in quick succession in the mid 90s. MacOS 7/8/9 didn't have any satisfactory emacs ports at the time, but MPW offered similar functionality, just using shell scripts (or arbitrary programs) for extensions not elisp.
These days emacs runs on all interesting OSes and is pretty much as usable over ssh as it is locally — or using e.g. sshfs/FUSE or TRAMP to edit remote files on a local emacs.
Here's a MPW Shell script I just found on the net (I had a ton I wrote myself, but who knows if I still have them...)
# StdMPW Canonizes all MPW Textfiles
# By Dan Allen 7/13/87 set today "'date -s -d' 12:00pm"
directory "{mpw}"
for i in : 'files -d'
directory "{i}"
for j in 'files -t TEXT'
setfile -a 1 "{j}"
target "{j}"
font Monaco 9 ; tab 4 ; find
movewindow 36 22 ; sizewindow 473 280
close
end
if "{i}" != ":"
directory ::
end
end
Rather sh/bash-like, but different. And the "target" opens a text editor window and then the font, tab, movewindow, sizewindow, close operate on that.
-
It's gonna be fun when "AI" gets into PCB layout :)
It's been doing it for years, just not stochastic-parrot AI.
-
The usage suggested in this thread seems to be a huge amount of work to set up
Exactly the opposite. There is no setup except just install and start using. That's the whole point. Your manual copy-pasting has "setup" every time (the copypasting back and forth). Besides, in the isolated copypasting, the AI cannot look at surrounding code, so cannot do good work, and will be producing crap that works in isolation, so now you spend more time integrating the pieces together. (The process you mention works quite well for truly isolated pieces.)
AI can do the "big picture" and the integration work just fine, but it has to have full access to your codebase to do that - hence, agentic.
But yeah, if Claude Code doesn't work on Windows 7, and you must use Windows 7, and special setup (like a VM) is "huge amount of work", then it's clearly not for you.
-
Why can't you just write code by yourselves?
Oh, just like Linus Torvalds wrote all the code that went into linux? Or like Elon Musk sits in his office writing all the rocket code?
"Just writing code" is something I wholeheartedly agree with, and part of the reason software industry fails so hard is overavoiding "just writing code". But there is a limit how much you can do, even if you are good. It's not a huge amount of complexity after you already have to team up.
Software is not just writing the code once - it's maintaining it, daily operations (debugging production issues, making fixes) - while continuing multiple lines of development of new ideas and improvements. And maybe you have a firmware part, but also UI part, some server, tooling, whatever.
So you have to team up. Well functioning team of 5 really good programmers can do wonders. And AI works if you cannot find these unicorns. The main strength is not that it can "write code". It can do much more to the point that it can work similarly to a human member in a team, but the key strength is 2-3 orders of magnitude less communication delay. This direct natural-language communication and instant implementation of ideas is what drives many inefficient and problematic software industry practices obsolete. Exactly those practices that were necessary evil, but what we "why not just write the code?" programmers hated. Overdetailed planning <-> monkey implementation pattern specifically was expensive and slow. Those who know what they want and "just write code" get the job done well, but once having the insight what is needed and being able to write the code are detached, everything collapses: now you spend nearly as much time as writing the code specifying how the code should be written, and then a monkey implements it, and then it doesn't do what you actually needed (see e.g. the classic https://preview.redd.it/tree-swing-v0-i2aeyrivmjoz.jpg?auto=webp&s=6a8d5a17a9f8decbedd5614c51dc8dc6cbb9e3d4 ), even if the monkey implemented it correctly. This is natural and expected, but the issue is iteration speed and cost.
With AI you won't be writing tickets and specification documents that micromanage details (unless you really want) or testing a product which doesn't work only to revise the documentation to be fixed after weeks. You chat about it and you work together to get it done.
-
in the isolated copypasting, the AI cannot look at surrounding code, so cannot do good work, and will be producing crap that works in isolation, so now you spend more time integrating the pieces together.
I've found the opposite, which was unexpected: Use CLAUDE.md + single file and get good analyses of specific issues, use a group of related files and get vague generalities that aren't particularly enlightening. This may be a recent thing though as Anthropic allocated every GPU possible to finish the Mythos training and Glasswing, leaving Opus with very little compute for anything. I'm also still on 4.6 because 4.7 added guardrails to prevent it from being used to find exploits, making it less useful if you're checking your code for possible issues... and presumably to make more of a market for Mythos in the process.
-
to prevent it from being used to find exploits
Surely that is a legitimate use, by someone who wrote the code.
I get Claude warning me about variables shared between RTOS tasks, and then it corrects itself by saying "but in arm32, a float is atomic so it is OK" ;)
-
On a complete tangent - does anyone else feel slightly guilty about terminating the session - ie: killing the instance that's just done so much good work for you - just so you can start afresh with a new context. Making it doubly bad is that I tend to ask the current session to write me the prompt for the next one to be up and running as quickly as possible...
"Yeah, I know you've just performed absolute miracles here, you've just implemented ARC in an afternoon when it took teams of Apple engineers months to do it, but you've run out of context space now so I'm just going to get rid of you and reboot to a fresh context so I can carrry on with what I want. See ya!"
Only *slightly* guilty, I know it doesn't have feelings, but ...
No ? Just me then ? Ok.
-
to prevent it from being used to find exploits
Surely that is a legitimate use, by someone who wrote the code.
It is, but they're worried about use by someone who didn't write the code, perhaps coming from an IP address in North Korea.
-
On a complete tangent - does anyone else feel slightly guilty about terminating the session - ie: killing the instance that's just done so much good work for you - just so you can start afresh with a new context. Making it doubly bad is that I tend to ask the current session to write me the prompt for the next one to be up and running as quickly as possible...
"Yeah, I know you've just performed absolute miracles here, you've just implemented ARC in an afternoon when it took teams of Apple engineers months to do it, but you've run out of context space now so I'm just going to get rid of you and reboot to a fresh context so I can carrry on with what I want. See ya!"
Only *slightly* guilty, I know it doesn't have feelings, but ...
No ? Just me then ? Ok.
Its a good illusion, but no. The moment its finished the job, the specific copy of the model that did it will be assigned a new context window and be busy on something else. It already isn't there any more. If you give it further instructions then your context window may well be assigned to another copy on a different server or even data center. No consciousness , no guilt, no worries.
That said, I'm quite sure the tone of a request affects the output from an AI, but in the opposite way that you might expect. I find being direct and succinct gives the best results. Being overly polite is just verbal noise to the AI.
-
And AI works if you cannot find these unicorns. The main strength is not that it can "write code". It can do much more to the point that it can work similarly to a human member in a team, but the key strength is 2-3 orders of magnitude less communication delay. This direct natural-language communication and instant implementation of ideas is what drives many inefficient and problematic software industry practices obsolete.
I would even speak up in support of AI if it was based on a formal logic approach and worked just as a compiler and abstract problem solver working from strict formal definitions, not this probabilistic crap.
And considering the rest part about raising efficiency... this relentless thirst to accelerate things is not leading us into a good place.
The more people understand this, calms down, and chooses a measured hasteless pace of life the better world we'll be living in.
-
On a complete tangent - does anyone else feel slightly guilty about terminating the session - ie: killing the instance that's just done so much good work for you - just so you can start afresh with a new context. Making it doubly bad is that I tend to ask the current session to write me the prompt for the next one to be up and running as quickly as possible...
"Yeah, I know you've just performed absolute miracles here, you've just implemented ARC in an afternoon when it took teams of Apple engineers months to do it, but you've run out of context space now so I'm just going to get rid of you and reboot to a fresh context so I can carrry on with what I want. See ya!"
Only *slightly* guilty, I know it doesn't have feelings, but ...
No ? Just me then ? Ok.
Its a good illusion, but no. The moment its finished the job, the specific copy of the model that did it will be assigned a new context window and be busy on something else. It already isn't there any more. If you give it further instructions then your context window may well be assigned to another copy on a different server or even data center. No consciousness , no guilt, no worries.
That said, I'm quite sure the tone of a request affects the output from an AI, but in the opposite way that you might expect. I find being direct and succinct gives the best results. Being overly polite is just verbal noise to the AI.
"Overly polite" yes. But saying please and thank you is not for the bot. It's for me. I am still human.
One thing I did find myself doing, early on, was having sympathy for it. When it went down a rabbit hole and failed, I had the choice to "stop it and put it out of it's missery" or just let it go and revert it in git, clear the context. The trouble was. The answers were coming from my "social reasoning". That triggered some alarm bells.
There are many better ways to deal with this "ephemeral" nature. More structured and effective methods of persisting context and sharing it across sessions. Even parallel sessions.
In the simpliest instance is the CLAUDE.md file. After that there is the .claude folder with things like "System Prompts", memories, skills, plugins, reference sets. For example. You can set down reference tables for your hardware in the master .claude folder and it will have those across all sessions.
Claude also tries to "align with your processes". So if you start a session stating you want a documentation trail and ask for "Mark down files" keeping track of the session, decisions and work. It will do it, but it will also begin to assume that you want this process carried on throughout and so you stop needing to ask it.
When you launch a new session, point it at the documentation folder, give the context of what you want to pick up on and it will fairly rapidly get back up to speed.
If you find on every session you have to tell claude how to do something or access something for a project... put it into the CLAUDE.md file. "When trying to access X use Y"
-
I use CLAUDE.md, but this is a big project, and although there's some shared context between sessions, I usually try to keep them fairly separated. The last four have been:
- Reference counting - so whenever I use 'new', the memory to which it refers is reference-counted and anything wanting to use it just bumps the reference-count up by 1 with 'retain' when using it, and using 'release' to decrement that count when it's done. Once the count goes back to 0, it's returned to the heap
- Automatic reference counting - so now when you create an object, it gets a reference-count of 1, as soon as you assign it or pass it out of the function that reference count follows it. If it goes out of scope, it gets automatically 'release'd and the memory is returned to the heap if the refcount is now 0, as soon as the last reference goes stale, same thing. Apart from cycles (a has a reference to b, b has a reference to a) this pretty much frees me from any memory management at all, at pretty much zero runtime cost. ARC is freaking amazing in Objective C, I wanted it for my own little language
- Typed pointers - so you can designate something as 'weak' (for example, there's a few different types implemented) to break that retain-cycle I just mentioned.
- Class properties - so if you have an i-var, and implement setIvarName then the compiler automatically invokes the method rather than accessing the i-var directly. Turns any i-var into a property-type wherein you can override behaviour (restrict the range of an int to 10-100 for example).
All of these were different sessions - but they all relate to the compiler in general, and sometimes to each other. So I have generic stuff in CLAUDE.md, and I'll specifically ask the current prompt something like "given the current class implementation, write a prompt for the next session that gives a succinct but complete starting point for implementing i-vars as properties using the policies expressed in doc/property-policies.md". I'll get back maybe 50 lines of text, with some things I probably wouldn't have thought to include, and the next session is bootstrapped.
-
I would even speak up in support of AI if it was based on a formal logic approach and worked just as a compiler and abstract problem solver working from strict formal definitions
Oh, but that's a different problem entirely. Programming languages and formal verification or, say, CASE tools, do exactly what you want. Programming language itself is for making a strict formal definition for what the computer should do, and compilers are crazily good at implementing it correctly!
This is a totally mature field of study. It's just that you need someone to write the formal specification, which needs to be both correct and useful. And that's huge amount of work for non-trivial, complicated problems. It's the design work.
You can present rocket trajectory as a series of formulae, but you can't represent, say, Microsoft Word or Tesla's infotainment system or ERP or Altium Designer or linux kernel as a series of formulas. You only have feelings, fluffy human language plus maybe drawings to represent user experience, which is everything that eventually matters - does it work and does it do what it needs to do?
And the code needs to implement that.
So yes, AI agents are human replacements. They design and implement software. They are not 1:1, and have different set of strengths and weaknesses. They are solving a totally different problem than what programming languages, formal verification or CASE tools are. And they use those tools!
-
but you can't represent, say, Microsoft Word or Tesla's infotainment system or ERP or Altium Designer or linux kernel as a series of formulas.
Since each one of such products is a mix of informal artifacts and formal solutions it is not possible to re-engineer it completely from a formal specification.
If would be possible if world artifacts were isolated and provided as a system of constraints.
Fluffy feelings expressed in "I want it to be this way because I see it so, but can't explain" just as historical artifacts like compatibility requirements must be recorded to a list of artifacts which is informal part of set of formal definitions.
Probabilistic AI as it is may be very efficient in constructing such corpus of definitions and that's OK.
But all the rest must be derivable within a rule system.
So if you ask an AI agent to explain how it got this solution it mush show you exact derivation sequence that it used inside (not an imitation of) just as a compiler would show you it's internal AST and debug-print all the rest of decisions up to code generation.
-
Cause the way it works now is "I don't know what the hell I'm doing, but the frequency of this event in a given context is high" and this is just insane.
Yes, I do find Google's Gemini suggestions useful at times, but it is impossible to be sure that it didn't just made some shit up.
-
This may be a recent thing though as Anthropic allocated every GPU possible to finish the Mythos training and Glasswing, leaving Opus with very little compute for anything.
A recent post from Anthropic (https://www.anthropic.com/engineering/april-23-postmortem) explaining that they did indeed change some stuff recently that impaired performance.
Also, for people hanging out for Mythos, it sounds like the name is appropriate (https://www.flyingpenguin.com/the-boy-that-cried-mythos-verification-is-collapsing-trust-in-anthropic/).
-
Its a good illusion, but no. The moment its finished the job, the specific copy of the model that did it will be assigned a new context window and be busy on something else. It already isn't there any more. If you give it further instructions then your context window may well be assigned to another copy on a different server or even data center. No consciousness , no guilt, no worries.
In the things-you-probably-didn't-need-to-know basket, this is how online sex chat sites work, or used to. You think you're having a private chat with Misty when what's at the other end is a pool of work-from-home folks who get your chat in one window and context information in the other, so they can have an ongoing conversation with someone they're encountering for the first time. When you type in your message, whoever's first in the queue picks it up and responds. The next time, you can get a completely different person responding after consulting the context notes to see what the conversation is about. Those earn-money-working-from-home jobs aren't only money mules.
The difference now is that it's AI bots instead of human workers.
-
The usage suggested in this thread seems to be a huge amount of work to set up
Exactly the opposite. There is no setup except just install and start using. That's the whole point.
Exactly. There are a lot of things you _can_ do, to improve the process. But for me the huge benefit of specifically the CLI agents is that you dont have to change your existing process at all. You dont need to figure out how to integrate it with your editor / IDE. You don't need to let it see your whole project or explain the build process. You dont need to use a specific version control system. You dont have to install language servers. You just install it and run it and then tell it what to do. And you dont have to give control entirely. You can still do manual edits, and the worst that happens is the next time it tries to edit that file it may fail until it refreshes its cache.
The other stuff helps. The more of your project it can see and the more tools you give it access to and the better you maintain its context window the better the results you will get and the more complex tasks it can perform.
But even then: the first order thing to do is write a text file with a list of instructions like "to build, run make compile; the output will be in the build/arm32 directory." That and using plans which are just markdown outlines (written by CC and edited or approved by you) of steps and substeps.
I have been using the gemini CLI (which is googles version of CC) on verilog projects for a few weeks now. Its _definitely_ worse than python/c/c++ and other traditional programming languages. But its still quite good. And it deals far better with the shitty world that fpga developers are forced to live in than any ide ever. It can work around black boxes, hidden, encrypted libraries, and multi megabyte compile logs filled with useless warnings. its tripped up by many of the same things that give humans problems but it also helps manage those problems.
-
It can work around black boxes, hidden, encrypted libraries, and multi megabyte compile logs filled with useless warnings. its tripped up by many of the same things that give humans problems but it also helps manage those problems.
If you look at how it works (I'm assuming similarly to Claude), it's eerily similar to human beings - limited by "context" like human beings - so it reads 100 lines of the huge log... Then it greps it, does spot searches of codebase, maybe writes a Python script to filter the log... Whatever to prevent it from having to actually read the megabytes of log, because just like human, LLM realistically can't do it either.
So the difference is just that it does those steps much faster; instead of spending the whole afternoon doing those tool uses, it does it in 5 minutes.
-
LLMs for coding are best treated as a force multiplier rather than an engineer replacement.
One really good embedded developer can maintain, churn out, refactor and debug more code with Claude rather than on their own.
-
I use CLAUDE.md, but this is a big project, and although there's some shared context between sessions, I usually try to keep them fairly separated. The last four have been:
So for "contained tasks" that apply across 'contexts', and sessions such as a 'de-linting', "bug finds" and 'static analysis', even code review this is where "Skills" actually work and are intended to be used.
Consider a CLAUDE.md file, but in your shared (project or user level) .claude config. Now instead of calling it CLAUDE.md you call it something like skills/reference-check/SKILL.md
You don't even need to understand, even that much. When you go back to your "Referential integrity" session, ask claude to capture the process you have been following with it into a "skill". I suggest plan mode so it gives you the full break down of what it does (or does not) capture in the skill. It writes it for you.
Then in any session, new or maxed out, doesn't matter, you can just "invoke" that skill. In most situations it is just a "canned prompt" based on the steps and processes you highlighted from your prior 'manual' prompting version. It's capturing something quite real here. 'Your' personal process of how you want claude to go through things. The key difference is that you don't need to re-explain those processes, techniques and rules to it every time. Just run the skill.
Some skills do not even "do" anything. They are just there to instruct claude to load a bunch of things into context when you switch to a particular task.
If when I get back into embedded stuff, I will be employing skills as simple as:
/stm32f411
/arduinomega
/esp32
And keep those updated when I work on each, so when I switch micro I don't need to "quirk check" it so much each time. Any quirks or "out of date info" that creeps in can be 'fixed' in those skills. They will not action anything, except to point claude to the documnentation collection and "ways of working" MDs files... specific to that micro.
-
The usage suggested in this thread seems to be a huge amount of work to set up
Exactly the opposite. There is no setup except just install and start using. That's the whole point.
Exactly. There are a lot of things you _can_ do, to improve the process. But for me the huge benefit of specifically the CLI agents is that you dont have to change your existing process at all.
The situation we need to assist in here is that the OP's dev environment is highly customized, version frozen all over the place and running on Windows 7.
That particular combination, old eclipse, old proprietary extensions, old operating system and a completely custom dev environment beyond that... is not particularly welcoming to modern software. Almost everything in the stack dropped windows 7 support 5 to 6 years ago, along with the dated DotNet runtimes and you are immediately into "What works, what doesn't" if you try and run them.
Peter has suggested he is willing to go as far as a VM with Windows 10 I believe? That's a start. Not a bad one either. For Peter's peace of mind the VM provides a protection layer, makes it a sandbox "air gapped" almost from his actual dev environment. No shared files, no shared execution contexts, no shared memory.
Windows 10 alone will get to a running claude CLI in power shell. Might require a few "Add programs and features".
Does anybody actually like DotNetCLI... sorry Power shell? I know I can't speak a line of it.
I would see that as the next hurdle. How do we get a 'decent' enough bash shell on WIndows 10? WSL ... is a bit heavy, it's basically a nested VM. Brings a whole new set of problems we don't want. You might as well install Kubuntu at that point instead of Windows 10.
VSCode will run happily in Windows 10, I use Windows 10 for dev still. VSCode has got claude extensions and they do support "Raw CLI" mode. If you are going to find a bash shell extension somewhere, VSCode is a good place to look. Cygwin... not worth it. "Git Bash" doesn't have the level of terminal control required by claude.
Even with powershell. Just
* Fresh windows 10 VM
* Turn off the garbage telemetry and tidy it up - or use a pre-cleaned ISO
* Install Claude CLI with the instructions for Windows 10.... I believe they exist somewhere
* Copy, zip, checkin/out, or fileshare a copy of your project into the VM
* Run claude.
* Ask it about your project.
* Tell it your problems.
* Sit back and enjoy.
Caveat: I have never tried to run claude in Windows at all.
Caveat2: I think the OP should just go and install Kubuntu. It's very windows like and very user friendly out of the box. It even has the "Terminal - Konsole" in the favourites menu on first boot. Just the claude curl command to begin.
-
LLMs for coding are best treated as a force multiplier rather than an engineer replacement.
I'm using it for both, and actually the productivity gain is much larger in the "engineer replacement" task. I believe the sole reason is additional benefit from removing communication delay.
When you use it as "force multiplier" to assist with something you would be doing yourself directly anyway, there would be no communication delay anyway, and now you actually are introducing one with LLM (albeit very small). So now maybe your productivity gain is in range of 2-20x.
When you replace a programmer with it, not only you get that force multiplying effect, you are also removing potentially significant communication delays (hours, days, weeks), so productivity gains can be easily 1000x. For example, I have solved problems that were tried for 3 years with human programmers before giving up, in 1-2 hours - this is ~30000x speed gain in calendar time, which is all that matters. Impossible becomes possible. This is what product managers who can't program, are seeing. This of course only applies to engineers you need to micromanage.
So for me, two things are true simultaneously: I can program and I cannot program. I can program algorithms in C, but I cannot program our Elixir and Typescript backend / UI, and I don't have the time to learn to do it. Thus, I have two different use types for AI: personal assistant / force multiplier for work I could do myself from scratch, and replacement engineer for work I cannot do myself but need someone else to do. The same $100/month Claude license works very well for both.
-
How long does it take to explain it to the LLM + how long the LLM takes to complete the task + how long it takes to review and correct it < doing it on your own.
Just not always.
-
I don't get this "Peter is using an obsolete OS etc etc so cannot do it".
AFAICT there is no problem uploading one's entire code for a given product to Claude, just into its web interface, and ask it to supply code for some new feature.
I have uploaded e.g. main.c and several other .c files to it, and it did the job while commenting on some dodgy coding practices, which is exactly what I was after.
There is nothing wrong with win7-64. M$ have also stopped supporting win10 now! So, we are all supposed to chuck all our PCs in the bin and buy win11 compatible ones. Yeah, right. There is not a single thing win11 does which win7-64 does not - except that some "rented" apps do not work under win7-64 anymore. And I don't use rented programs.
The gotcha is that if you are using the free Claude, and you give it several .c files, say 2000 lines total, you will get just one response out of it and then it will say it has blocked you until 3am :) So, you have to give it some money. What I don't know is how much more the £18/month gets you. Some people are paying 200/month.
-
I don't get this "Peter is using an obsolete OS etc etc so cannot do it".
AFAICT there is no problem uploading one's entire code for a given product to Claude, just into its web interface, and ask it to supply code for some new feature.
I have uploaded e.g. main.c and several other .c files to it, and it did the job while commenting on some dodgy coding practices, which is exactly what I was after.
There is nothing wrong with doing that. It's fine, and I'm glad you have found a tool that is helpful.
The point is just that your OS choice is limiting your ability to run newer software. Which again, is a fine choice, but it's undeniable that this is a limitation that you have chosen.
There is not a single thing win11 does which win7-64 does not
Except run software that doesn't support older operating systems! And since "providing an environment to run software" is the main job of an operating system, I'd say it's _potentially_ a very big deal.
I've been a linux user for 30 years. I'm totally understanding of an operating system choice that prevents you from running certain software. For me the benefits outweigh the limitations. But they are limitations, and pretending otherwise doesn't change that. Sometimes I use alternative programs like libreoffice, sometimes I use work arounds like wine or virtual machines, and sometimes I just don't do things. But it's all tradeoffs.
-
How long does it take to explain it to the LLM + how long the LLM takes to complete the task + how long it takes to review and correct it < doing it on your own.
That's what I've found with Claude, it's a wonderful tool for picking up anomalies but after that I fix things myself. Trying to get it to apply the correct fix, unless it's extremely obvious and trivial, is like trying to get a string across a table by pushing it. Taking ten times as long to explain it as it'd take to actually do it is fine with an intern because it's a teaching thing, but with Claude it'll both slide out of the context window before it's needed again and the intern can reason about it, generalise, and apply the information to future fixes for unrelated things while Claude can't. It can pretend do, but usually just ends up in a... not sure if there's a name for it, a sort of inverse hallucination that ends in "I'm sorry, I realise now I shouldn't have done that".
-
Sorry - this has become quite long: TLDR; I think there are benefits to running it locally.
I don't get this "Peter is using an obsolete OS etc etc so cannot do it".
AFAICT there is no problem uploading one's entire code for a given product to Claude, just into its web interface, and ask it to supply code for some new feature.
Maybe this will be illustrative: I woke up this morning (still sitting in bed, actually) and typed in a prompt for an idea that came to me while I was asleep - shower thoughts without the shower!
Context: I've been trying to get an emulation of ANTIC, a graphics chip from the 80's atari range, on an RP2354. We're just covering the basic "can it work" question here, not the nitty-gritty "if register X has value Y then effect Z glitches in a cool way and people used that" sort of question... So the investigation passes at "normal" (and in fact at 2x, 4x, and 8x) speeds, but its to go into a system running at up to 12x the bus-clock of the 6502/custom-chips so I'm trying to squeeze that last bit of performance out.
It's not been going well unless I push the RP2354's to higher overclock than I'm really comfortable with (528 MHz). I've tried DMA chains to offload the CPU, multiple DMA chains, ping-ponging through the PIOs - again to offload the CPU, using the RP2354 interpolater, you-name-it, I can close x10 at 360MHz overclock, but not x12 and becaue all the other moving-parts work at x12 I really want x12 :)
❯ ok, its morning now :) I want to consider a new investigation: instead of tring to update a framebuffer we keep the atari memory as a series of scanlines in memory encoded in the original atari format. I'd suggest each scan-line start at a given boundary (say 1024 or 512 bytes after the last) so its easier to locate them, in other words semi-parse the ANTIC LMS instructions in the display list as we snoop the 6502 bus.
We then use the PIO blocks to:
(1) translate the encoded form to something the HSTX can output, and
(2) push those bytes down the HSTX as DVI.
The difference between this investigation and the framebuffer one is that each scanline is converted while the previous one is being sent. Not sure if it'd be better to convert-to-byte-representing-colour / convert-to-RGB / send .. or convert-to-RGB / send.
This is a different approach to the framebuffer idea, might balance the work better on the emulated ANTIC when we're pushing the clock-multiplier up to 12x
To which the reply was:
⏺ This is the right shape, and crucially the ../hdmi rig already gives us the headroom math. That rig measured palette-index → RGB888 expansion at ~4.4 µs out of ~20 µs of active scanline — leaving ~15 µs of slack. Your proposal asks scan-out to do one more expansion stage (atari 1bpp → palette index, ~3-4 µs added). Total fits within margin.
The bus-side throughput question collapses. Each /CS_SCREEN event becomes a single byte-store to scanline_base + N*512 + col. Per-event cost on M33: ~5-7 cyc (FIFO read + address compute + str). At x12 (16.76 cyc budget) that's a 3× margin, not a 19% deficit. We don't need DMA, LUTs, doubled rows, or rotation tricks. This likely retires the multi-chip path — that's a big claim but it falls straight out of the math.
On the byte / palette-index / RGB intermediate choice: the question is really how many ANTIC modes do we ever want to support, and how often does the palette change?
- byte → RGB direct at scan-out (no intermediate). Smallest scan-out work, but mode-specific PIO/expander code. Locks us to one mode at a time. Palette change forces full code rebuild.
- byte → palette-index → RGB (two-stage). Per-scanline work splits cleanly. Mode-specific code only handles bit-unpacking; palette is a hot-swappable LUT. Matches what ../hdmi already does for stage 2 — we'd add one stage in front. Strongly recommend this.
- byte → RGB direct via bigger LUT (256 atari bytes × 8 pixels × 3 RGB = 6 KB). Compact data path, but we lose palette flexibility (256-entry LUT bakes the palette in).
⏺ I'd start with palette-index intermediate (option 2). It composes with the existing ../hdmi rig and lets ANTIC palette register writes (COLPF0..3, COLBK at $D016..$D01A) just update the palette LUT — no scan-out reconfig.
Open question worth resolving before designing the rig: tearing. Bus writes happen during scan-out. If row N is being scanned while the host updates row N's bytes, the visible pixel mid-line shows old/new mix. Real ANTIC has the same issue (game code is supposed to update during vblank). Our rig mostly inherits that — but we should decide whether to (a) just accept it (matches Atari behavior) or (b) double-buffer (costs ~8 KB SRAM, halves write rate during buffer-flip windows).
Suggested rig scope (minimum viable):
1. Bus-side hot path: byte-store into scanline buffers, measure capture rate at x1..x12
2. LMS tracking: cold-path DL parse on /CS_DL writes; updates screen_base mapping
3. Two-stage scan-out using ../hdmi's structure: PIO/IRQ expands 1bpp → palette index, then existing palette-index → RGB888 path
4. End-to-end correctness: pixel probes against expected fb output
If you want, I can sketch a scanline-direct (or whatever you'd call it) investigation directory with a README + skeleton, modelled on the antic-autonomous layout. Or if you'd rather first nail down the tearing decision and the mode-coverage scope, hold off and have that conversation first.
Note a couple of things:
- It went off to a previous investigation (I have a good dozen or so now) and looked up the results from there without me asking it to, in order to answer the question
- It tailored the suggestions it gave based on the context it could find
- It also noticed a design "weakness" (that I want to preserve, actually, tearing is endemic to the atari range, updates *do* happen in the VBI because of it, and a frame's delay is actually not desirable)
I'm actually a little surprised it didnt run off and write a test then run the test to give me the best option, but maybe it's because it could source the information it needed this time around without doing that.
The point I'm trying to make is that running it locally gives the machine a lot more to work with, and the more you use it, the better that information feeds into future work. I get it to save concepts as I use it (it "writes a memory") so we don't go down rabbit-holes in the future. One example is setting the RP2354 overclock, it took a few goes to get it right the first time, now it's a memory and "just works".
Just like with humans, you gain more from their work if they're more informed on the subject. Throwing source-code at someone and asking them to comment/fix/work-with it doesn't work as well as if you provide them with the background, previous work, and wherewithal to test things out for themselves. It's the same with the AI.
[edit:]
And just to follow up because I asked it to write the rig, test it, and show me the results:
mult | phi0 (MHz) | clkdiv | events (got/expected) | screen captured | probes | verdict
-----+------------+---------+-----------------------+-----------------+---------+---------
x1 | 1.790 | 15.468 | 32008 / 32008 | 32000 / 32000 100% | 8/8 | PASS
x2 | 3.580 | 7.734 | 32008 / 32008 | 32000 / 32000 100% | 8/8 | PASS
x4 | 7.159 | 3.867 | 32008 / 32008 | 32000 / 32000 100% | 8/8 | PASS
x8 | 14.318 | 1.933 | 32008 / 32008 | 32000 / 32000 100% | 8/8 | PASS
x10 | 17.898 | 1.546 | 32008 / 32008 | 32000 / 32000 100% | 8/8 | PASS
x11 | 19.687 | 1.406 | 32008 / 32008 | 32000 / 32000 100% | 8/8 | PASS
x12 | 21.477 | 1.289 | 32008 / 32008 | 32000 / 32000 100% | 8/8 | PASS
⏺ x12 PASSES at 100%. The whole multiplier sweep clears with no losses, no probe failures. This
overturns yesterday's failed-12x verdict — single-chip RP2350 can take the ANTIC role at x12,
with the right architecture. Multi-chip is off the table for this role (subject to phases 2-7 validating
scan-out).
The hot loop coming in at the optimistic end of my 14-16 cyc estimate makes sense: M33 dual-issue
overlaps the umull with neighbouring loads, and the snoop FIFO never goes empty so the FSTAT
check is always fall-through. No need to drop the 512-alignment or add the LUT — the design is
correct as written. If we need more head-room in future, there is scope however.
Let me update the project memory and flag failed-12x as superseded so neither stays misleading.
Wrote 2 memories (ctrl+o to expand)
⏺ Now mark failed-12x as superseded so future readers don't act on its conclusion.
That last point is as important as the positive result IMHO. It marked a whole series of investigations yesterday as "don't look here, no longer relevant" so as to preserve the usefulness of the local context we've built up.
-
but it's undeniable that this is a limitation that you have chosen.
Well, yes, but I didn't "choose a limitation" :) I am staying with win7-64 because I have a pile of high productivity tools running under it, and new versions of them don't do any more. Same reason as I run Protel PCB 2.8 and Specctra v?? and ORCAD SDT/386, all from late 1990s (and those are all in a winXP VM). New versions do a lot more and do it a lot better but all are rented now (so archiving a project and re-opening it say 10 years later is generally not possible).
Until this Claude usage method, which needs something more recent. But I have seen this with linux too; certain applications need a latest version of Debian, so while you are not a hostage to M$ declaring some OS "dead", you are still a hostage to the whim of some app writer who made a similar decision. That was a specific version of Python, IIRC. I solved that one by buying a new miniature PC just for that application, and it is accessed via remote desktop.
My last Q was really how much difference the £18/m makes. Some people say very little. I might give it a try.
-
Win11 _can_ be installed on ~any even relatively modern machine, even if not "officially supported",
with well known options to bypass the check(s). For this you could use a tool from rufus.ie, but i think
it does already require win10 to run, so a VM might be necessary for making the bootable usb-installer.
I haven't used Claude Code, but only gemini, with browser, gemini-cli(on win11 with WSL, and on rpi5
with debian trixie) and antigravity(google's "vscode-edition just for gemini with some google-tweaks").
It does just work :-//.
Google did offer a free month*, and gemini-cli fixed years old bugs in a codebase i didn't want to touch
(c++/qt6, while i prefer c/more embedded stuff) + wrote me a ModemManager-plugin to enable using
/dev/wwanX interface instead of required use of pppd(i consider this ugly&ancient) to create /dev/pppX
for a 4g modem without having to learn all the necessary glib-stuff used by ModemManager in hours vs.
a week, or whatever it would have taken me(could have ended with me buying another modem).
*) which does cost about 23eur, iirc., and is still relatively usable for bigger codebases locally, i guess.
-
but it's undeniable that this is a limitation that you have chosen.
Well, yes, but I didn't "choose a limitation" :) I am staying with win7-64 because I have a pile of high productivity tools running under it, and new versions of them don't do any more. Same reason as I run Protel PCB 2.8 and Specctra v?? and ORCAD SDT/386, all from late 1990s (and those are all in a winXP VM). New versions do a lot more and do it a lot better but all are rented now (so archiving a project and re-opening it say 10 years later is generally not possible).
Until this Claude usage method, which needs something more recent. But I have seen this with linux too; certain applications need a latest version of Debian, so while you are not a hostage to M$ declaring some OS "dead", you are still a hostage to the whim of some app writer who made a similar decision. That was a specific version of Python, IIRC. I solved that one by buying a new miniature PC just for that application, and it is accessed via remote desktop.
My last Q was really how much difference the £18/m makes. Some people say very little. I might give it a try.
I feel your pain. This is why we NEVER, EVER get there in professional software. Everything is bang up to date, latest versions across the board. Our regulatory and customer commitments require it.
Fixing versions is always attractive. Fixing versions at build time is common practice, so what you build is what you test with zero supply chain risk.
However, beyond that, even fixing versions across a few months is considered bad practice.
It's not just security, it's not just the networked environment, it's simply because software "MOVES" it is not static and the world changes their software. All that happens you get further and further left behind until "fixing it" and "catching up" is immpossible. Requiring a complete re-wrtie from the ground up.
Having found out how much this costs and how much a single genuine security incident costs, force upgrading everything and everyone is much more preferable.
Do things break occasionally? Yes. Do we need to tweak and work around new versions from time to time, yes. Is it worth trying to hide from this? No.
So that "whim" of some app writer is ALL of them. Seriously nobody, EVER, starts a new dev release cycle without updating their dependencies. They just don't. Why would they want to go backwards?
-
I feel your pain.
Me too - installing all the tooling is usually massive PITA. Which easily leads up in peter-h's situation - once you have everything running, "don't touch anything!" Except, that sucks, too. Eventually you have to touch anyway. Or, you need to duplicate the setup for a new employee. Or your computer just breaks down.
So doing frequent fresh installs of "everything" needed is a good idea. If, for nothing else, for checking that you can do it. Like in Chernobyl 40 years ago there was this test: hm, does the normal safety shutdown procedure work? Well, it didn't, but testing it wasn't the mistake. It needs to work, and it needs to be tested!
But it takes time, this is the key turn-off preventing people getting into projects - e.g. open source contributions - or becoming a productive worker at a new company; you spend days just to get things compile and run, often trying to follow out-of-date step by step documents written by some summer trainee 3 years ago when they tried to bootstrap the thing from scratch.
Incidentally, AI seems to solve this, too. This is exactly how Claude Code enabled me to work on our server/frontend stack. Basically the process went like this:
"This status indicator has been broken for 3 years and our developers could never fix it. Try to fix it."
5 minutes of code base exploration and tool calls later Claude did two bugfixes. Then it tries to compile and run tests, which fails because there is no compiler installed. It tries simpler and simpler ways to verify at least something. At that point, I intervene:
"Let's do this properly, help me install those tools instead"
Then it does everything needed, find the download sites, download, install. Looks at error messages from installing the programs and finds out what needs to be done to actually install all that crap.
Another 5 minutes later, I have full local development environment installed.
In my humble-ish opinion, there is no excuse to lock down to Windows 7 when developing for freaking STM32. Come on, this isn't some exotic weird 8-bit for which only Windows 7 toolchains exist. Claude could also help peter-h get rid of all that Cube dependency hell ;D
-
I feel your pain.
Me too - installing all the tooling is usually massive PITA. Which easily leads up in peter-h's situation - once you have everything running, "don't touch anything!" Except, that sucks, too. Eventually you have to touch anyway. Or, you need to duplicate the setup for a new employee. Or your computer just breaks down.
I always make sure I can duplicate my working environment in a fresh Debian/Ubuntu docker container, even if I'm doing my actual work natively. I used to use EC2 but docker is cheaper and easier.
There aren't docker images for MacOS, but you can at least chroot there, and control what you copy/link into it. Also see there are docker-like Tart and Anka tools, with Anka apparently best-suited to CI. Or of course full VMs.
-
After reading the thread to this point I'm still not getting what kind of work are you trying to offload to "AI".
-
In my humble-ish opinion, there is no excuse to lock down to Windows 7 when developing for freaking STM32. Come on, this isn't some exotic weird 8-bit for which only Windows 7 toolchains exist. Claude could also help peter-h get rid of all that Cube dependency hell ;D
Or even don't start in your "prime project" or "Bread and butter" project.
Pick something you have wanted to try, but never found the time. Just go and have a play with claude in a safe environment where if you get frustrated you can delete the VM and be done.
Like for example. Do a mickey mouse, UART HelloWorld on one of you devboards or a Nucleo discovery board. A VM with a USB pass through is not hard. Let it show YOU the modern tooling approach and have it automate everything including the tests accessing the actual USB serial adapater, flashing software and even the OCD or JTAG debugger.
-
After reading the thread to this point I'm still not getting what kind of work are you trying to offload to "AI".
For a slippery question a slippery answer.
Repetitive pattern matching. Pattern overlays. Parallel pattern alignments. All the things that are actually 10% the cognitive effort and 90% of the time.
The bit between, "Vision" and "Basically working code".
The bit most lesser mortals consider the hard part but the wise knew was never the hard part. Code and config are the communicative expression of ideas, processes, systems. They are just a 'translation' medium. Nothing more.
AI, particularly agentic CLI assistants can bridge that gap in profound ways.
The catch is... you need to cross the bridge with it before you can invite others to cross. This is were a lot of people are failing.
-
After reading the thread to this point I'm still not getting what kind of work are you trying to offload to "AI".
Almost everything you offload to another human being.
-
Almost everything you offload to another human being.
More often than not I find it faster to do something by myself than to explain it to anybody, doesn't matter if it's a human being or an "AI".
-
One of reasons is I that the very process of explaining to anybody how exactly I want something to be is simply times more text than this thing I need to do/write/etc. and it's faster to type the final product than to type a "prompt" to offload the task :)
-
You would be surprised at how good Claude is at following your instructions on how to do stuff.
For example I don't like the style (used by lots of coders, and ST) of using structs of structs and typedefs of structs and structs of typedefs :) So I told Claude I don't want that. And it remembers that.
-
Almost everything you offload to another human being.
More often than not I find it faster to do something by myself than to explain it to anybody, doesn't matter if it's a human being or an "AI".
Of course, that's what I always try to prefer. But there is a very hard limit on project complexity one can manage alone. Then enters teamwork, where building the right team is the most difficult part, usually, and communication second.
-
You would be surprised at how good Claude is at following your instructions on how to do stuff.
The problem is, for example, for every project there are some coding guidelines and rules of maintaining a project I keep in my head and they are different for different projects and ... they are nowhere present in written form and even if I have some design document of sorts it is never complete enough. And whenever I try to collaborate with someone it's always such a headache to even realize how much of this implicit background knowledge I have to recall and transfer so that there wouldn't be any difference in who's actually working on that project.
-
Code guidelines and even code style is one thing that you almost entirely lose when using "AI" code generation. Maybe you can force that to some extent, but I haven't seen any occurence of full adherence to a specific code style and code guidelines. I have even seen those tools get surprisingly "stubborn".
I see Siwastaja's point, even though I don't necessarily agree. As soon as you need to delegate some development work, unless you already have a full, experienced team at your disposal, your options are limited and using automated tools can look attractive (it's way cheaper, no need to bother with people's mood, etc)
-
Code guidelines and even code style is one thing that you almost entirely lose when using "AI" code generation. Maybe you can force that to some extent, but I haven't seen any occurence of full adherence to a specific code style and code guidelines. I have even seen those tools get surprisingly "stubborn".
My observations so far are in full agreement with this. I can't get Claude to exactly and precisely follow every instruction, and seemingly no one else either. Those who cannot accept that, are dissatisfied, and come up with weird explanations like "Claude followed all instructions perfectly in February and then it was nerfed to market a new model."
No, instruction following is never perfect and exact, and that's both a strength and weakness. The reason for this is that the neural network itself, and its training, gives very strong signal, and pushing some weighs far enough requires a lot of prompting around in the context and might be nearly impossible. Exactly the same as with humans, BTW - most human beings struggle following every instruction every time, even if we remember them all if asked about - those are in our context windows yet we just don't follow them. Even well-trained pilots are known to outright skip steps in checklists exactly designed to be as self-guiding and robust as humanly possible, even when they are trained about the importance of every step. Yet "I'll just turn this knob right now to solve the thing" behavior kicks in. AI nearly perfectly replicates this behavior.
The solution is the same as for humans: if strict adherence to rules is necessary, you need to codify them, and use tooling to check before accepting the work. If your build script does a check, AI sees it was rejected, and fixes its work. Beware, though - both humans and AI learn to work around the rules, and poorly designed overly strict requirements lead to the same result with humans or AI: loss of imagination, loss of potentially superior solutions, quick hacks designed to only satisfy the rules, not the original intent, mistakes and bugs when modifying working code to match the rules.
And then again, the code style I get is quite close to what I want, without any guidance from me - because it reads surrounding code, and mimics the style. Trying to micromanage in style issues would probably be diminishing returns, with a lot of work with mostly dissatisfaction as a result.
I'm not sure though that a perfect to-the-letter instruction following would work. Humans are not that way; I believe one of the big reason why we are so technologically advanced is exactly because we have imagination and do whatever we want to do, when we need to. Good mix of ignoring instructions and following them; taking risks and not taking them.
-
The problem is, for example, for every project there are some coding guidelines and rules of maintaining a project I keep in my head and they are different for different projects and ... they are nowhere present in written form and even if I have some design document of sorts it is never complete enough. And whenever I try to collaborate with someone it's always such a headache to even realize how much of this implicit background knowledge I have to recall and transfer so that there wouldn't be any difference in who's actually working on that project.
For sure, but if you have some good coders, they will have their own ways of doing stuff and you will not be able to re-educate them. Not if they are any good, and you don't want bad coders :)
I find Claude works great as a kind of "coding slave" who knows C (in my case) and produces blocks of code which mostly works, and saves me a lot of time. I don't use it for setting up the project structure; you get weird stuff that way which probably is not the way you work (may well be how others work, and it found it somewhere). So e.g. I set up an RTOS task which starts off two other tasks, doing specific functions, and I ask Claude for the code for these.
How it does it, well there are lots of YT videos on how LLMs do stuff, and I rationalise it by the fact that most software has already been written, and Claude gets it from github, stackexchange, mfg application notes, and even programming books from the old days.
-
How it does it, well there are lots of YT videos on how LLMs do stuff, and I rationalise it by the fact that most software has already been written, and Claude gets it from github, stackexchange, mfg application notes, and even programming books from the old days.
Of course that's also why Microsoft rendered Github mostly useless unless you're logged in and why Stack Exchange has largely done the same. Enjoy your new slave while it lasts.
-
Even if those sites go under a login (not for me yet AFAICT) they were scraped long ago. I run a community site (not electronics) and some 90% of the server load (for which we pay $60/month for hosting) is caused by AI bots, each of which hits the site at 3-5Hz. I can block these (the site is fronted by Cloudflare) like EEVBLOG does for example, but then we get a lot fewer people joining up, because nowadays visibility to "AI" is much the same job as visibility to google, preservation of which has been a key feature of server-side coding for last 20 years :)
-
Even if those sites go under a login (not for me yet AFAICT) they were scraped long ago.
But of course. Source code hosted on Github never changes. I stopped hosting new projects on Github years ago. It's not just Github, nearly every site these days uses anti-LLM protection of some sort.
-
For sure, but if you have some good coders, they will have their own ways of doing stuff and you will not be able to re-educate them. Not if they are any good, and you don't want bad coders :)
This is back to front from my experience and you are a seemingly perfect example.
I change projects on a month by month basis. Different languages, different customers, different code bases. Often different styles, different ways of working, different ethos. Different tooling, workflow, CI/CD, cloud env.
I work in the project style. Literally within seconds of opening a file in a code base I can recognise their styling and follow it. Because I have seen all of them before.
Consistency is king. No team lead will ever deny this.
On claude. An actual issue we have with Claude is the opposite to what you say. Because you are using the chat interface and giving claude a pin hole to look through. We actually find the opposite. When we want claude to help migrate or update existing code, it is extremely difficult to get claude to NOT follow the current conventions and styling. If there is a pattern in use in a project or a coding style and we want to change it, we have to be very strong with prompting scaffolding to overrule claudes attempts to remain consistent with the code base it's in.
EDIT: I think a common "resistance" to using claude properly from many on this thread and elsewhere is related to this. People who have only ever done software alone, in a one man band or as the only "software guy" in small the company, have no 'ways of working' for software in a team, even a team of 2.
No documentation. All project knowledge in one persons head. Riddled with untracked technical debt. Riddled with half finished bits of work. Stubs of half written code. Commented out code with no explaination everywhere. No code repo. No CI/CD. No issue tracking. No Wiki. Nothing that will make a team work. So even the introduction of a virtual junior is unbareable and unmanagable.
claude is not your issue if you are in this boat. Your practices are. It probably will take you quite a while to get around some of claudes "higher" standards and get it to produce work of that standard. Software is a practice. At least go and look at what that means.
-
EDIT: I think a common "resistance" to using claude properly from many on this thread and elsewhere is related to this. People who have only ever done software alone, in a one man band or as the only "software guy" in small the company, have no 'ways of working' for software in a team, even a team of 2.
No documentation. All project knowledge in one persons head. Riddled with untracked technical debt. Riddled with half finished bits of work. Stubs of half written code. Commented out code with no explaination everywhere. No code repo. No CI/CD. No issue tracking. No Wiki. Nothing that will make a team work. So even the introduction of a virtual junior is unbareable and unmanagable.
claude is not your issue if you are in this boat. Your practices are. It probably will take you quite a while to get around some of claudes "higher" standards and get it to produce work of that standard. Software is a practice. At least go and look at what that means.
Claude is probably the best thing to happen to a developer you described. For example, compare these two commit messages - one is written by Claude, one is written by me:
Sample 1:
controlroom: F12 also flips units.participating='yes' in fcr DB
After MQTT approval, a detached prod-query child updates the unit row;
on 'UPDATE 1' it appends an 'Approved and enabled participation' note
and signals the parent via SIGUSR1 to redraw the view.
Sample 2:
small things
Both commits are made for the same reason - committing needs to be done, to get forward with the business. Both received the same amount of attention from me.
-
Sniff. I see MQTT, child threads and a DB "row".
I see async event->transactional action.
Be careful :)
EDIT: Less is probably more here. Depending on your throughput rate (non-functional requirements) you could do the DB transaction in the MQTT thread. This way you know it cannot get triggered by another event while processing the prior one. Saving you a mutex later. The DB will possible serialise the transactions, depending on the setup, but I wouldn't let it get this far. Without "transactions" it will just race to last write wins. With transactions one of them will get aborted or both rolled back if they collide.
If you do have enough through put to need to split your Producers->Consumers into many/many I would suggest a "Pool->Queue->Executor" for the DB. You take a pool of DB connections, all warm and ready to go. When a transaction happens, you pull one out, give it the queries/transaction and pop it into the queue. The DB executor then sequences them one at a time.
The issue that still doesn't solve though is "out of ordering" due to thread delay.
If you are only updating "one row" and not a relationship or compound transaction to multiple tables... you might just get away with letting the DB handle it. It's only if you need to, say, add a new row and update a foriegn key on another table that our of ordering and race conditions will be an issue. You can get two MQTT messages competing, but that is just normal.
-
I do have another data point: yesterday I had to draft a complicated document (lease related). So I gave Claude (which had just cut me off for a few hours) the min sub level of £150 for the year (plus VAT) to get this job done. And it looks like this payment rate pretty much stops the constant expiry every time you ask it to read a PDF or some such. I can now use Claude Code too but have not yet tried it.
Now I find Claude does not cut off at all, with what I do.
Claude is also significantly better now than a year ago.
-
Claude code and the PDF problem.
A PDF file is very, very token dense in it's formatting. Claude will attempt it if you ask. The likely hood of coherent useful output however depends on just how much formatting tokens there were and how they got processed. Small, simple, PDFs which are very basic in formatting, like basic datasheets with tables, it might do okay. These are usually datasheets and the like which are only a few 100kbytes. Many PDFs are not created this way, some use very complex dynamic layouts and all manor of "cruft" hanging off them.
It's a waste of tokens.
So, use other tools designed for manipulating PDFs to get at the real content. When I tried claude with datasheets for a project it started out well with the 500kb memory datasheets, but when I gave it the 5Mb processor manual... it was clear things where not going to work. Very high token cost, poor an d inconsistent recall from it. So I pointed this out to claude and it explained it's own limitations. It then suggested it help me install Poppler which will export the PDF contents to basic Text, preserving tables (as text tabbed lists) and columation etc. Then have claude process that text version. Orders of magnitude less tokens, far better recall of hard facts.
A specific failure mode with the processor datasheet. 30-40% of the manual is bus timing digrams. The real meat of the puzzle. But they are imported and compressed bitmaps from a technical drawing program and claude didn't even see them. Even after the text extration this was an issue of course. Eventually claude found enough in text form on the internet to start making sense.
Its the same pattern across the board really. Claude alone gives you non-deterministic issues, so instead you give claude a tool to do the empircal for it to get deterministic output. Then point claude back at that output.
This is why automated testing infra/tooling is important. Goals having outcomes that claude itself can test empircally. Then it's non-determinstic portion will loop on trial and error until it gets it to pass.... or gives up and changes the test.
EDIT: It recurses on itself though, as claude does a good job of writing those tools for itself and that still anchors the indeterminstic loop.
-
Maybe my Claude has learnt from your Claude, because it always runs pdftotext and analyses the ascii text in /tmp for me :)
I feed it data sheets and the like on a regular basis. It seems fine with it.
-
Maybe my Claude has learnt from your Claude, because it always runs pdftotext and analyses the ascii text in /tmp for me :)
I feed it data sheets and the like on a regular basis. It seems fine with it.
It's more that Anthropic are watching industry evolve techniques which they release in the next patch. Most of "it" is front-end "orchestration" code in Typescript, IIRC.
That also embodies the value of AI startups quite well. Ephemeral.
-
Food for thought?
https://www.youtube.com/watch?v=3o2SlgX9BhE (https://www.youtube.com/watch?v=3o2SlgX9BhE)
-
Food for thought?
Isn't it obvious yet?
The best application for this type of AI is making cat videos.
-
Food for thought?
Isn't it obvious yet?
The best application for this type of AI is making cat videos.
Not really, the best application is currently talking about it, making videos about it.
-
Not really, the best application is currently talking about it, making videos about it.
Your bitterness is getting kinda cute ;D
-
The video makes good points, and supports my own use of it where I use it for specific chunks of code.
It is probably disastrous if used to generate large server-side programs.
-
The video makes good points
Sure, all the absolute classics with neither any new insight, nor any proof, example cases or something else of actual interest/fun. Very agreeable, because all concerns are legit. Classic "preach to choir". Nothing quantitative, just qualitative babble, which is easy to produce, for AI or human, with not much effort.
It is probably disastrous if used to generate large server-side programs.
Not any more disastrous than humans generating large server-side programs. But with poor planning and poor supervision, speed and apparently low cost of initial work can be scary. It probably is possible to generate a very complicated unmaintainable mess in a month; classically, before AI, that happened within 4-5 years of timeframe, and 5-10 million spent in programmer's and management's wages, and 100 million billed from the customer.
Like, who would have thought? It is well known that most complex software projects are failures, either total or partial, full of "technical debt" and very hard to maintain. Train AI with the "industry practices" and what do you expect to happen? It's not going to magically solve fundamental software process issues, it's just cheaper and faster.
I see it solely positive, though. If something can be created in a month only to be seen as no-go, it is much easier to ditch and start over than if it took 50x more time and 100x more money - the classic sunken cost fallacy is big part of long-standing software quality crisis that has plagued the societies since early 2000's if not earlier.
Datacenter energy use and effect on RAM prices are actually my biggest concerns, if a lot of "work" is going to be wasted. Compare to human programmers - even if they produce utter and equally damaging crap, while eating oxygen and producing CO2 in the process, we still think their existence as human beings has an inherent value irrelevant to their software contributions, and we still think that the money we put into their wages is "well spent" because it allowed those people to get butter on their bread, which we attribute an emotional value to.
It gets more interesting when we assign an emotional value to human programmers doing their jobs worse than AI, instead of just paying them some unemployment benefit.
-
I tend to agree; the video is pretty bland. But there are other reasons why large IT projects tend to fail.
For example in the UK National Health Service, most IT projects fail because of poor staff buy-in, which in turn is caused by recruitment practices which bring in too few smart people (a polite way of saying too high a % of the 1.5M staff is thick, and what keeps it going is a small % of good hard working people).
More generally, most IT projects fail because of incompetent initial specification. Incompetent people gravitate to large organisations, especially govts. This is obviously known in the large contractors who always tender for these jobs, so they quote low to get in. They know they will get paid provided it meets the spec even if it doesn't work. Then they quote a high daily rate for mods, and these are always needed to make it work. Often, the cost overruns cause the project to be scrapped.
AI might save money by accelerating the scrappage cycle :)
-
I tend to agree; the video is pretty bland. But there are other reasons why large IT projects tend to fail.
For example in the UK National Health Service, most IT projects fail because of poor staff buy-in, which in turn is caused by recruitment practices which bring in too few smart people (a polite way of saying too high a % of the 1.5M staff is thick, and what keeps it going is a small % of good hard working people).
More generally, most IT projects fail because of incompetent initial specification. Incompetent people gravitate to large organisations, especially govts. This is obviously known in the large contractors who always tender for these jobs, so they quote low to get in. They know they will get paid provided it meets the spec even if it doesn't work. Then they quote a high daily rate for mods, and these are always needed to make it work. Often, the cost overruns cause the project to be scrapped.
I think it's spot-on analysis. How AI actually ends up changing this, it's very hard to predict. Now it's already clear that out of functioning team of 10 programmers, you can take the brightest one or two, and replace the remaining 8-9 with Claude. And projects that actually require a team larger than ~50 people should be nearly non-existent (maybe a linux kernel with all the driver work etc. is an exception to this). This means that with AI, team of 5 actual human engineers should go very far. But they need to be good ones.
But will it work out this way? What if you replace the wrong people? What if there was no "bright mind" in the project at all? What if the development was crap because no one had any idea how it should be actually done? What if there is only a "product manager" who keeps wanting the wrong things, implemented the wrong way. Then the result with AI will be equal failure, just faster. Or, in worst case, not even faster, but even more complex. Maybe you were given a 5-year timeline and 100 million budget "because that's how software projects always are" and now you are 20x more "productive" producing crap? Yes, that's a real threat.
Silver lining is, that underperforming "product manager" could be replaced by AI, too, and it's not probably any worse. Ask Claude for the "big picture" suggestions and they are usually pretty sensible because that's basically through consensus filter, while you get some of the usual software industry mistakes baked in, you also avoid some super weird atrocities real "managers from Hell" are capable of inventing.
-
Now it's already clear that out of functioning team of 10 programmers, you can take the brightest one or two, and replace the remaining 8-9 with Claude.
:-DD :-DD :-DD
I've been working on a small software project for a few months (Embassy compatible HAL for a few Renesas RA chips). Someone popped up recently in the chat room and asked about policy around AI code in pull requests. They'd been working on the exact same thing, only they'd been heavily leaning on Claude. I don't really have a dog in the race because they were aiming to include their project in the official Embassy repo and I'm not.
We've been working on these projects independently for the same time so I thought it'd make an interesting comparison. I'm not some mythical 10x coder but am already way ahead of them in terms of peripheral support and documentation. Their whole project demonstrated that Claude did not understand the task at hand and nothing was being maintained. Documentation referred to directories that don't exist, code referred to different directories that don't exist. But the worst part was that the code Claude excreted looked plausible enough that a senior dev might waste their time reviewing it. My favorite was that they used tokens to change a path from absolute to relative. Claude came up with 40-odd words tho to describe that trivial change, so that's something, right?
But that's not news. Anyone who relies on AI burdened companies like Microsoft (Github) or Cloudflare can point to AI induced outages. So, sure, AI will replace jobs insofar as people are willing to lower their standards.
-
The problem with lifting code from Github is that it is easy to publish something on there (or elsewhere online) which is somebody's copyright or patent.
The owner may not discover it for years. For example, I run a forum (not electronics) which has been going since 2012. From time to time we get copyright infringement threats over a photo or something that was posted on there years before. Just got one over something from 2018 - 8 years ago. Forums are protected from liability provided the alleged item is removed within a few days (in general terms) but the lengths of time are interesting.
And with AI lifting huge amounts of code from places you have idea of, this is surely more likely to happen. I would certainly not want to use AI to generate code which will then be published for anyone to examine e.g. open source ;)
Cloudflare is a great service but is losing its way. Its website is now highly browser version sensitive - a sure indication of cretins running the show.
-
Cloudflare has claimed Post-Quantum readiness, not all browsers versions support that. This may be the/a reason.
-
Not really, the best application is currently talking about it, making videos about it.
https://www.youtube.com/watch?v=Ir2H3G2MxwQ (https://www.youtube.com/watch?v=Ir2H3G2MxwQ)
-
In earlier videos they struggled with getting hands and teeth right.
Now it seems this is more or less fixed...
https://www.youtube.com/watch?v=g4m0R_tuw9Q (https://www.youtube.com/watch?v=g4m0R_tuw9Q)
-
In earlier videos they struggled with getting hands and teeth right.
Now it seems this is more or less fixed...
They still have serious problems with jabberwockies though, and since no amount of training on videos will fix that, you need an actual understanding of human anatomy, I don't know if this can ever be resolved by a stochastic parrot.
For people not familiar with the term, it's when body parts appear and disappear as a person moves. Because a video of someone turning around has limbs and things not visible at times, the parrot magics up something corresponding to when the parts disappear and reappear in the scene.
-
I've been working on a small software project for a few months (Embassy compatible HAL for a few Renesas RA chips). Someone popped up recently in the chat room and asked about policy around AI code in pull requests. They'd been working on the exact same thing, only they'd been heavily leaning on Claude.
So what was the problem they were solving, and why?
The whole AI slop phenomenon exists because it is now easier to pop up and start to "contribute". Harmful contributors always were a thing, now just amplified because AI acts as force multiplier.
I.e., someone "wants to help", maybe with no harm meant, but wanting to help is not enough, you need to understand what is needed, why and how and do that. In case of AI, ask it to do the right thing. This is especially important when contributing to projects maintained by others.
Things like security reviews are an exception: they seem to work now because anyone can prompt "read all the code and find security vulnerabilities" and as most actual developers of actual projects have found out (https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/), the slop is almost gone now. But if you ask the AI to fix those issues, it's already hit-or-miss - sometimes fixes are obvious, e.g., adding a bounds check to prevent overindexing, but sometimes changes in program structure, even external behavior is needed, and then you need to be the one who maintains the project; someone who knows how the project should work. AI can guess, just like outsiders can guess.
But adding new features is especially risky, with humans, with AI, and probably with AI even more dangerous because it can do so much more in so little time. This is exactly why I said keep the 1-2 bright minds, those who know what is needed, and let AI act as force-multiplier to them. This seems to work for us very well. Accepting random work from outsiders, no, that does not work, and AI does not magically make it work.
TLDR, main developers, if any, should be using the AI, separate "AI enthusiasts" putting their noses in foreign projects is the slop problem.
-
They still have serious problems with jabberwockies though, and since no amount of training on videos will fix that, you need an actual understanding of human anatomy, I don't know if this can ever be resolved by a stochastic parrot.
For people not familiar with the term, it's when body parts appear and disappear as a person moves. Because a video of someone turning around has limbs and things not visible at times, the parrot magics up something corresponding to when the parts disappear and reappear in the scene.
I have been wondering why we haven't seen a significant paradigm shift in generative AI image, especially video generation; AFAIK, it's still basically predicting pixel colors pixel-by-pixel with a neural network, and for that, it's amazing how well it can work, but will result in six fingers which then, when sequences of frames are generated, morphs into four fingers.
Why don't they use something LLM-like to produce more anatomical "simulation" of object / body part trajectories, use that to produce 3D models, then use the pixel-based NN to apply textures - or something along that idea?
-
Peter and Siwastaja. You are close, but quite off the trail.
The software industry is in free fall right now, it's completely lost it's way. That is from BEFORE AI.
2017 - Cloud. Most people wanted their infra converted to cloud. They got sold in.
2020 - Pandemic. Demand for software went up 10 fold or more.
by
2022 - The majority of "technical" staff in the industry are not degree qualified. In fact not qualified at all. No background, no commitment, no "trade", no "practice", no "discipline". Just any punter off the street that can pass a code interview got hired and give the same fucking title as me. They really want to be a chef and have not a single care for software. Grrrr.
2026 - The critical mass is gone. Qualified and skilled engineers ... actual qualified, background, life, carreer engineers are so few that the entire language, discussions, ways of working are gone.
Seriously in 2024 I had to survive a meeting where the project managers spent 2 hours inventing release notes. Literally they know nothing and they are trying to work out how to do software from scratch again.
Every time you drop something like, "If we don't have requirements, we should not start.", you get confused looks and are apparently the problem.
I'll be honest with you and say, I haven't 'delivered' on power for over 4 years. It's eating me alive from the inside out.
The pace is about 10th what it was before. The gravity towards a working solution is non-existant. Nobody can even "picture" the "done state" in their minds, so they don't even believe there needs to be such a thing. They start in the middle and work like chaos.
AI will not fix it.
When they (my last work) started asking us engineers if they had certifications and if they would mind getting some.... I asked, "When you higher a manager for a development management role, do they do certificates in management? Do you even send them on a training course for same? No? Didn't think so."
My answer to them was repeated over and over again. "Please refer to my CV". Which includes a FULL education history in software, a 2.1 degree, Higher certification in software design, Lower certificate in generic 'Computing science'. 20 years of experience working with household names, Tier1 international organisations, banks, governments. "Please refer to my CV". Because they never read it.
Honestly, it's so bad that those qualifications... when your bum is on the seat these days is worthless. The majority of people don't understand your rigor and practice and see it as a threat to progress. You are the problem and the main part of it is your "Software Engineering" skills. They are not welcome.
EDIT: The plus point is made in that video. The projected collapse and utter failure and chaos will make my skills worth quite a bit more. The question is.... can I survive the career until that happens and survive the collapse without tell people what I really think and losing the job.
Right now I feel like I am walking on thin ice. The career is barely working at 51 and I have 16-17 years to retirement and no budget to retire early. It's not a small load.
-
AI will not fix it.
I agree AI will not fix the software industry. I see a glimpse of hope though: now teams of 1-5 people who know what they are doing can act much bigger than before. This democratizes the field and makes new type of competition possible. You don't have to be a 100-coder huge software house, or a 100-volunteer open source project gathered during 10 years, to do a large software project anymore. You don't need 10 millions of investor money, then try to hire 20 coders, only to find out 18 of them are "off the street" and do not know what "release notes" mean.
And if I'm right on that - it could be a big shift. Smaller, faster teams - more development efficiency. Less waste. More competition. And competition is always a good thing. Big part of the reason why software industry has lost the ball is, as you point out by your 2020 observation, is demand exceeding supply, so anything goes; any outcome must be accepted, because no one else can do it any better. Competition fixes that, and classic, large software houses have to solve their own problems - with or without AI.
-
Maybe. Maybe not.
"Completion" and "Closure" in projects are not longer advantageous. "Working and complete" software does not write cheques. Not really complete, yet anyway, software extended contracts, adds monthly cheques.
They don't want you to complete a project as working. That cuts the revenue off.
So it's not completely "incompetence" it's just that with a critical mass of "non-engineers" it's "acceptible for business".
What they don't realise is... it is a violation of my core values as an engineer and they don't care about my sanity. I am not alone. GenX are getting close to retirement. The rest of the boomers left around covid. Once GenX start leaving they have no more 'Ravens' to keep the tower up.
Also. The dynamic that is actually happening is that 10 completely clueless juniors armed with claude produce 10 pull requests of code which the sole senior engineer is responsible for reviewing, correcting, and approving. They are not writing code, they are not designing systems, they are doing code reviews of AI generated code 110% of the time.
-
Also. The dynamic that is actually happening is that 10 completely clueless juniors armed with claude produce 10 pull requests of code which the sole senior engineer is responsible for reviewing, correcting, and approving. They are not writing code, they are not designing systems, they are doing code reviews of AI generated code 110% of the time.
Small, fresh teams are free from these kind of structures. If you are the "senior engineer", and you are using Claude, you don't need to even generate pull requests, let alone check others' crap.
Clueless juniors armed with AI seems like the worst thing to happen, and if that's happening in the software industry now, I don't have much hope. But that depends. MAYBE if they are taught to use AI to pre-check their work before submitting PRs - that could improve quality and reduce the burden of the sole senior engineer. But, instead, if they are pushing new features with record speed without understanding what they are doing because upper management said we can ship features faster with AI - oh dear.
-
It works fine in small companies.
It is the bigger ones which have always had problems - because (in the post Apollo era ;) ) you cannot assemble a big team of good people. I think Claude etc will create havoc there. They will probably just get stuck in legal debates about who owns the copyright ;)
-
Its been going on for a long time in sdev.
I switched companies ten years ago to find out that the new company which is globally known for their products, delivers poor quality software. They switched to SaFe, output dropped factor two, people increased factor two mostly supporting middle management know nothing , but talk the talk.
It took four weeks to get the teams to get a proper "definition of done" :-DD
And now we have a proper definition of done noone follows it since that would drop output with another factor of two.
But that is doing software the right way with proper requirements, desig, implementation, testing, documentation then delivering.
Noone does that, all cut corners. It should be finished and delivered yesterday.
Documentation was never completed since 1999, a few brilliant engineers that wrote the code and are about to retire have it in their heads the youngsters often hired from all over the world struggle to cope.
I have seen four companies in my career and none of them thought software was equally important as hardware. Hardware was king and if the electrical engineers screwed up with their design what does happen, software should fix it which as we all know is only partly possible.
So this has nothing to do with AI or new generation or young people, this has been going on since late 90s when any university graduate such as biology and history graduates were hired as sw engineers and the industry was low on real engineers.
So perhaps the real SW houses have their staff and methods properly in order, I can not say this for any hardware product company I have ever worked for the last 30 years.
-
Small, fresh teams are free from these kind of structures. If you are the "senior engineer", and you are using Claude, you don't need to even generate pull requests, let alone check others' crap.
Remember I work in a regulated evironment. Also remember that the UK state makes no differentiation between "Engineer" and "Chartered Engineer" when it comes to "Negligence" and other crimes.
Also remember that Horizon's scandal is still fresh in people's minds.
Then recant the AI First directive. "Nobody writes any code. You don't own the effort, you own the output.", "You are responsible for the AI output."
So if people loose houses, fortunes, lives, I am still summonable to court as an individual.
The irony is... the management and the juniors DONT. They cannot be summoned.
-
So this has nothing to do with AI or new generation or young people, this has been going on since late 90s when any university graduate such as biology and history graduates were hired as sw engineers and the industry was low on real engineers.
You can make bad software without AI, but you can't make good software with AI. Look at Anthropic. They've tried to vibe code a Javascript runtime and ended up with a giant pile of slop. The race to the bottom isn't new but AI being used as a force multiplier in that race is.
-
but you can't make good software with AI.
That's probably true if you use e.g. Claude to generate the whole lot.
-
It works fine in small companies.
It is the bigger ones which have always had problems - because (in the post Apollo era ;) ) you cannot assemble a big team of good people. I think Claude etc will create havoc there. They will probably just get stuck in legal debates about who owns the copyright ;)
That may be true for medium-sized companies. It's not true for the true giants. I'm recently retired, but I worked at Apple for 20+ years, did some cool stuff myself, and worked with a lot of amazing people. They pay a lot of money, and although Apple may have a "fluffy bunny" consumer-orientated exterior, they're a ruthless machine on the inside, fortunately expressed as (mainly) a meritocracy. People who weren't worth that money were soon encouraged to ... find employment elsewhere.
Apple also has the concept of the DRI - the "Designated Responsible Individual". All projects have at least one DRI, larger ones are split into areas of responsibility. Sometimes that DRI is a director, other times it's an intern (we didn't give interns much R, it was more "this is how we work, muck in"). We did give relatively fresh employees R though, and that worked fairly well - there was always oversight from the team lead for the first time, just to show them the ropes, but after that, you were the DRI. If that meant arranging a conference call with Amazon or Microsoft, that's what you did (after talking to your manager :). If it meant finding the off-by-1 error in an icon on-screen, that's what you did. At the end of the day, anything wrong in that scope was yours to fix or manage. As a means to integrate collective responsibility for the product, it worked really well.
No, I don't understand how Liquid Glass ever got released as-is. Not my area of R.
-
but you can't make good software with AI.
That's probably true if you use e.g. Claude to generate the whole lot.
I'm going to come solidly down on the "maybe" line, here. I've had some awesome success with xtc (http://atari-xt.com/) - and I'm pushing even further on it now, I'm in the middle of a re-target to create an intermediate representation between the front-end and the back-end, so it can target more than just the 6502 and which opens up even more possibilities for optimisations.
Writing a (good) compiler is a big job, and it's taken Claude (not me, just "him") about a real-time month of effort so far, which is ... stunningly quick. It produces code within grasping-reach of hand-optimised assembly for the 6502 (benchmark runtimes of ~11 secs whereas the best hand-optimised is ~10 secs, there's also hand-optimised that's ~20 secs...), and creating a language with automatic memory management built in, classes, interfaces, inheritance etc., on such a limited CPU is quite the technological feat, IMHO.
I can imagine the wails if I'd walked into an engineering meeting and announced that I wanted the team to take that toy, demo-version piece of software and start turning it into something a lot more heavyweight - without that being the plan all along... With Claude it's just "ok, let's do this, and that, and as an optimisation we should <insert random thing I've never heard of, go google, and realise it's exactly the technique to use, "Sparse Conditional Constant Propagation", this time, if you care>
I sometimes drag it kicking-and-screaming towards what I want and not what it recommends, sometimes it suggests things I have to go look up before I agree with them, sometimes I plain say "no, that's not the direction". You still have to be in control to get the result you actually want, but it does take away a lot of the typing and leaves you free to do a lot more thinking.
It also allows for more exploration, because of the lack of that typing. My "6502" is on an FPGA... last night I was musing about how different the cost is of using the hardware stack (limited to 255 bytes in page-1) and the software stack (where all the arguments to functions actually get pushed, because otherwise your call-depth is about 6 on complicated functions). PHA is a single instruction, the software stack has to have space in zero-page, and indirect through it, takes 4-5 instructions. What about if we gave page-1 infinite depth ? Just have a public 8-bit SP but really it's 16-bit ? Well TSX/TXS would be a problem but that's about it. Okay, do the same for X. Hmmm. If it's documented and the compiler uses it, massive win for any function call...
I think there's still a lot to be said for the old adage "garbage in, garbage out". I can see it would be easy to just agree with it all the time, and ... that would not be a good path to go down ... so you still need the knowledge (or some way to verify and understand what it's telling you at least) but with that said, I'm having a surprising (to me) amount of success with it.
-
I'm recently retired, but I worked at Apple for 20+ years
OK; Apple is obviously a smart company. An old friend worked for Cisco (left about 15 years ago) and he often said he never worked with more intelligent people anywhere else in his life. He doesn't think that is true for today's Cisco, but who knows?
So, yeah, one cannot generalise totally re big companies. On the whole they must be well managed (otherwise your FTSE100/S&P/etc trackers would be junk ;) ) although hugely benefiting from the rule that 80% of your profits come from 20% of your customers, which enables you to have crap customer service etc and screw around an awful lot of existing and potential customers and still be huge. Honeywell, anyone? Every company they buy they f**k up. I know of some good aviation examples.
I think Claude is a brilliant tool, but then I've been around long enough to know where the skeletons are likely to be buried, and I use it for well defined tasks.
-
The bigger the company the bigger the mess. The bigger the cost to fix it.
So the graph looks like a mosfet resistance chart. Smaller companies tend to have more messy stuff but less of it. Large companies have less messy stuff but far more off it. Only the really large ogranisations can dump millions and millions of dollars into internal software departments.
The rest are left to get vultured by the consultancy rapters.
However the appreciation of why its so difficult I feel is often lost in here. You seem to always reference "concrete" and "static", well encapsulated projects. This is perfectly normal for the embedded space, but is not how the rest of the world works.
The key metric is that all my landscapes, requirements, tech stacks, platforms, customers.... are all in motion and not in sync most of the time. Consider that for a while. Consider if your MCU manufacturer is updating the peripheral register contents weekly. Your customer requirements can change in a day. By the time you get 2 months in the process there will be at least one C-Level event that changes everything under you.
You are smart enough engineers to understand that independently moving, unsynchroised complexity and dependency is a "Multiplier" on complexity, if not exponential.
Compilers and battery analysis reporting. Almost "single component" except the later I expect isn't. Try zooming out until you can see something like "A state transport department internal systems rework". Think in that kind of scope and like all of us wonder how anything works.
-
So the graph looks like a mosfet resistance chart. Smaller companies tend to have more messy stuff but less of it. Large companies have less messy stuff but far more off it.
I would not fully agree with that. I know perfectly what you mean, but it depends on the definition of "mess". Larger companies tend to have more complex processes which to many, probably you included as a professional, seem "tidy", the opposite of mess. For an amateur like me, many software industry proven practices look like mess.
Our situation was interesting. We are a very small software company and we had the large company process syndrome. 90% of our effort was spent on processes. Ticketing, managing the tickets, writing, rewriting, and re-re-writing CI/CD chains and server infrastructure setup. Doing "technical debt removal" on working parts, after which they worked more poorly and had more technical debt. Actual payload, the features customers want and need, and fix bugs in existing necessary features, was PITA trying to squeeze it in, somewhere in this schedule full of meta processes.
Big companies are like that. And for those in the industry, it might look tidy and nice. Well organized. But does the actual product work? Does the actual work get done? That should be the only metric.
Small companies who have small number of programmers and simple processes look "amateurish" due to lack of processes but whether that actually leads to any problems is the big question. I have stopped believing when professionals talk about technical debt or processes. Professional programmer's #1 sin is always crying the wolf technical debt, or lack of processes, and it's always serious and always "prevents all work" and "makes the company fail in long run". My experience shows it's better to take the "risk" of keeping developing the core product. Every software project will end up more or less messy, with technical debt. Any process won't magically fix that, but processes do reduce efficiency, slow down development - including bugfixes which are important for code quality, so processes would need to be really good to be beneficial, and it seems it's very hard for the software industry to actually define what is a good process.
So, IOW, small companies make "mess" only if you look at them through the software-industry colored glasses and expect to see certain patterns, but there is no conclusive proof these patterns actually are any good. If they were, they should be handling "more of the stuff" just fine.
-
On process it depends on who generates the process.
If engineering formulates and generates the process it's usually fine.
Trouble is, there are less and less of people capable and knowledgable enough in the field to know where to look, to have an existing pallete of processes from actual engineering accumulated knowledge from trial and error, measure and test over decades.
In fact the critical mass has been exceeded in the other direction. There are now more unqualified and uneducated people holding the Software Engineer title than qualified. So the entire language and positioning, even conversations have changed.
Without any map, tool pallete or recall of a degree explanation of why "Requirements first" is a must etc. etc. They don't see any of it. When they do they start reinventing processes, sometimes they arrive at something useful like "Release Notes" and others they end up somewhere deeply dangerous. In the later you protest and get told to stop being the blocker to progress.
For them, the ceremony, the process IS the work. They have no mental model to engage with on the actual work. There are more of them than us. That is why the industry is in free fall. The space real work gets done and the processes that held it together no longer exist. Not outside of maybe, aerospace, nuclear, defense et. al. and maybe capital markets. Places where consequenses are almost immediate and almost always VERY expensive.
-
Consider a single word.
Agile.
Immediately people separate into two camps. Those who see the implementation of it and try and work out the intent from that and ... hate it, realise it's a curse. Then there are people who read the actual agile docs, guidance and recommendations and understood them and think, "It is actually useful and valid."
The problem is that both are true. Agile was presented by engineers who knew what they were doing. It was meant to empower the dev team to take ownship and avoid long decision chains.
What got implemented was a weapon used to break rigor and delays for quality and clarity. "We don't need to know what we are building, we'll just make it up for each sprint as we go, it'll be fine, customer is paying".
EDIT: The actual agile king pin they removed was, "An item can not enter a sprint from the backlog until it has no decisions needing to be made external to the team." Put another way, a work item is only accepted into a (usually) 2 week completion window when it has no external dependencies and only the dev team responsible. Management just deleted that single premise and destroyed agile instantly. Turned it into a weapon.
The belief that all mistakenly written code today can be refactored into it's own purity tomorrow and again next week is utter bollox. You either have clean code written to a purpose or you have a dirty mash of intent and bugs. There is no middle ground. So the wise start over. You can do things in two ways. Right and again. But the business doesn't care about again, they just get more cheques to cover it. Each again, erodes you engineering soul though.
-
"Agile" is a standard corporate-BS expression :)
-
"Agile" is a standard corporate-BS expression :)
Nope it is replacing a half year or longer waterfall model by two weekly sprints or small waterfalls, quickly identifying a mismatch between the wishes and requirements of the customer and the software companies interpretation. It works great for some companies and some software teams and lousy for others. If you ever had to build software for a customer where the customer does not know himself what he exactly wants and making requirements is a project on its own and after a years work the customer does not recognize what he ordered, that is what happened a lot in the past. Unfortunately it does not work that great for hardware and also not when there is no regular customer review and feedback. Great for GUI's , less for embedded and lousy for hardware, because cycles are way longer and final product less visible/touchable to customer so it lacks the needed quality of customer feedback.
-
It has nothing to do with Agile if the customer does not know what they want. Agile is a f-king waste of time and resources. Before Agile, a team of 5 did the work. Now with Agile, same work is done by 10 people, 5 of which are scrum masters, agile coaches, and other agile ballast.
-
"Agile" is a standard corporate-BS expression :)
Nope it is replacing a half year or longer waterfall model by two weekly sprints or small waterfalls, quickly identifying a mismatch between the wishes and requirements of the customer and the software companies interpretation.
That's what the original idea exactly was. However, if bureaucracy and slow processes are in your "DNA", then switching to "Agile" to check a box means you are going to add all the processes from Agile to your workload, without getting any more work done.
The problem with codified ticket-based systems is that tickets lose a lot of information, unless you spend massive amount of time with them. Just good old discussion - chatting - with other workers is invaluable. Called co-working. This is also why AI seems to work so well - the interface is chat-based, and unlike human workers, it's always available and responsive.
Software industry incorrectly compares itself to first designing blueprints for a house, then constructing the house following the blueprints exactly. Analogy is sound in theory, but misapplied: most of the work we think is just "implementation" is actually the "making the blueprint" phase, and that's all the work. And that requires very strong communication. Waterfall locks it down completely possibly for a year, but Agile isn't much better if it's locked down for two weeks; the core issue is the same, it should have not been locked at all, the design work must be continuous iteration. Tickets work well for describing bugs found and random feature requests from customers. I question the usability of the idea of having a sprint start meeting, after which the epic is ticketed into 57 sub-tasks that are then fixed for the next 2 weeks and divided to 5 workers.
The best thing in Agile is the idea of finishing smaller sub-projects and shipping them to customers. That's actually great and prevents building a monster which was not what customer wanted and which does not work.
-
Pretty close, except the epic and sprint diviying.
The locking in is meant to stop the single most delaying aspect of software. Change during implementation.
Without Agile, the customer can and will interrupt you mid ticket and say, pause that one, do this one instead. They just don't understand what that actually causes.
In traditional Agile. The epic and tickets are broken down with the "Product owner" and "Dev Team". The sprint planning stare-mony is meant to be where the team negotiate with the scrum master/product owner and the business utltimately, what is "realistically achievable" in the sprint. The "goal" is to have a well feed team, a set of tickets which will complete before the end and any slack can be taken up with a few tickets left in to the backlog in a "Can be pulled into Sprint" label. ie. tickets that are 'ready for dev'.
At the end of the sprint, "velocity" is recorded as to how many tickets or what size the team actually got through. This metric is use back at the next spring planning as a "This is the bucket size" measure.
Of course, as well all agree, "business" didn't understand it, could not accept that it does not give a "What and When" at the same time, but their invoices do. So they.... adapated it to suit themselves. Turning it against the dev team.
EDIT: The alternative is where I am right now. You get a ticket. You read it. You might be able to start it, you might not. Usually there is missing information, nobody thought to include. So I ask who to ask... then I wait... Then I find out who to ask, so I ask.... and wait.... Meetings are arranged, talk happens, no decisions, so I wait. Eventually you have 20 tickets sitting on the board and none of them can move. Some of them have been started, some haven't. Some part of the business are wondering why nothing is moving or closing while other parts of hte business not talking to each other are taking their sweet time giving answers.
-
The locking in is meant to stop the single most delaying aspect of software. Change during implementation.
But locking in to wrong things, implementing them, waiting for two weeks, then reverting them, and doing them again is exactly what causes delay. Especially because now you have something new planned for the next sprint, so realistically you won't be re-doing your previous sprint, no, you go forward and add a new feature instead. This is exactly how technical debt gets into the project. Then developers want to redo everything every 1-2 years.
Sure, developers need to be able to filter out whimsical and unnecessary change-of-minds. Understanding customer intent instead of doing exactly what they said is the key.
But it's not only customer requirements. What gets locked too are implementation details, APIs between the parts maintained by different people. If you get those wrong, then the codebase is full of workarounds and workaround for workarounds. That's exactly the "technical debt". During implementation you will find out "hey, if we do this different way instead, everything gets much simpler"... The fewer there are people implementing, and the more they communicate together, the better it gets.
-
I don't deny you that.
For me I see/feel gradients of certainty and stability. Engineering bath tub curve applied to many things. Including requirements.
Without calling it 'waterfall', it is advantageous to put strategic resistance into the process. The developer mental model pool is limited. When you allow more to flow into it, it will just overflow.... down stream as bugs and technical debt, which cost more later to fix.
Placing a 'weir' on the sprint entry allows turbulence in the requirements stream to not upset the dev pool which is working on the last generation that was allowed to flow over the weir.
Does that analogy track?
In concrete terms, we have "DRAFT" status, "AWAITING APPROVAL" etc. etc. In some workflows at least. On the other end of the development the releases, in well managed flows, have things like, "DEV", "RC - release candidate", "EXPERIMENTAL", "ALPHA", "BETA", and finally, "STABLE".
Its the same response to the bath tub curve I mentioned above. Resistance in the flow deliberately to give things time to "settle" and become "proven" and thus "load bearing" for the next work.
Finding that ideal workflow out there in the current software industry is like hens teeth though.
EDIT: On exploring this with AI it keeps reframing it back at me as: "Velocity is more important to consultancies than actual progress", Agile or the agile bastarisation that exists provides the appearance of velocity making actual progress almost a byproduct.
-
To complete that analogy of the "Mean time between failures curve". The rise at the other side where the failure/error rate rises again is obscelence. In terms of software, the original purpose and platform has changed so much that the component can't hold it contract anymore and fails.
In terms of requirements. If you take too long to delivery to requirements, the business moves on, evolves and the requirements change.
It is the later which is causing so much 'velocity' tracking in software today... the full graph from "birth" to "its too old and doesnt match teh business direction", is now measure in months. Not decades. If you can't built it and get it to market in 6 months, it's not worth doing.
-
If you can't built it and get it to market in 6 months, it's not worth doing.
Usually that's true, but not because everything is changing so fast. Not at all - in fact many needs stay pretty much exactly the same for decades, even tech stacks are pretty stable for many years. If someone chose to implement something with node js 7 years ago, it's mostly still valid work today.
No, the real reason why you are correct is that if something is taking significantly more than 6 months, it's an indicator you are doing it ineffectively - your processes are clumsy, and it's expensive to run these processes which cannot deliver anything in 6 months. Because most of the projects are not really that complex. In almost all cases, you should be able to deliver something very usable, if not a fully perfect complete product, in just a few months.
Counterexample would be the one guy posting here who proposed that a phone app that plays music synchronized to workout patterns takes many years to ship, and even a simpler, useful "first release" cannot be made in less than years, and that huge amounts of investor money is an absolute necessity to pull it off. My instinct says they should be able to ship the first version in 3 months.
-
Yea, but if you do that the company can't afford to carry all the dead weight and those people have salaries and often climb the ladder faster.
Start ups is where that is made or broken.
Mature companies, whether it's IT, software or branding are always slow in a mass of ceremony and bureaucracy.
Trying ordering a new printer in the NHS and see how long it takes.
The model I liked from my career was the properly fronted and interfaced dev team. We didn't attented stakeholder meetings. We recieved all work and communications from the scrum master and tech lead. Yet you sat in the same room and you heard the calls where they defended you constantly.
That emerged in a very rare opportunity in a very large company where the department head (an exe developer and a good one), got enough traction to say, "Look. Leave it to the team, leave them alone, let them do it their way and lets see what happens."
We closed the project successfully in 6 months. Thus on deadline and on budget without dropping a feature.
-
Counterexample would be the one guy posting here who proposed that a phone app that plays music synchronized to workout patterns takes many years to ship, and even a simpler, useful "first release" cannot be made in less than years, and that huge amounts of investor money is an absolute necessity to pull it off. My instinct says they should be able to ship the first version in 3 months.
Which is sort of a dumb idea anyway. I would have pointed him to cognitive analysis studies and his own experience to show him, they don't need to be in sync. Your brain will sync them.
Test yourself. Open a music video with people dancing. Mute it. Now open another one. Keep that audio and watch the first video. It doesn't take long until you can no longer tell if they are or are not in sync. Then you just accept they are. As an example YouTube fed me a bunch of "Shuffle dance" videos. Lots and lots of clips of dancers collated together into a video. I thought the effort to synchronise all those clips would be enourmous. Then I noticed, watching carefully. They were not synced or even the same tempo in most cases. I'd just never noticed until I looked.
It's the same rabbit hole that leads you down to the "Spinning dancer silohette". With thought pressure alone you can reverse the dancer.
Sorry, but philosophy and cerebral is the norm for Fridays for me.
-
Back on topic. Two LLM short comings noticed lately to speak about.
1. The age old 'why do you insist on counting when you know you can't count?" - the update is that it does a far better job if the thin it's counting actually has delimiters, which are not spaces. It seems to count list items fairly well, but not words in a scentence.
2. Is new to me and rather frustrating. It lacks the ability to model a timeline. So if you have multiple "states" to consider. Such as "The present state", "The historical reasons for that state", "The future possible state to analyse and document"... it starts to come apart. Interplacing past, present and future.
In work when tasking claude with a migration from SOAP to REST, the output documentation continually refers to one specific component as being "REST" when it's been told many times it's 'not REST, it's still SOAP, we haven't migrated it YET."
If you don't spot that, and you therefore might trust a timeline or plan from claude... it can get ugly.
It gave me a timeline breakdown a few weeks back, which I read and frowned and realised... it had listed about 7 days worth of effort and then said, "That fits fine into the half day window the ticket mentions". I was like "The f... it does."
My advice? Get it to use some lower level software like a spreadsheet or CSV file to track/sum/summarise empiricals and numericals.
-
The "problem" with this topic is that it changes all the time.
Claude is way smarter now than it was 6 months ago. I've just uploaded a ton of graphics code to it and instantly it spotted a bug in a filled rectangle algorithm which was stopping 1 pixel short (I optimised it for DMA from the original code).
The £150/year subscription gets you way more leeway. Last night I uploaded ~100 .c files for review and only after a bit more it stopped, locking me out until 3am. First time I've seen that since I started paying.
-
The £150/year subscription gets you way more leeway. Last night I uploaded ~100 .c files for review and only after a bit more it stopped, locking me out until 3am. First time I've seen that since I started paying.
I found it was never enough to do a full working day, always the enforced 5Hr break.
Now I pay £75 (£90) a month and get a full days uninterrupted work. It's an amazingly capable assistant for such a small fee.
-
If you're looking for a cheaper (at least for the moment) way of doing it, there's a nice guide (https://github.com/MG-Cafe/claudecode-deepseek-stack) for how to use Claude Code with DeepSeek R4. I don't think DeepSeek is quite as good as Claude, but it's still pretty darn useful, and it's a *lot* cheaper.
-
Interesing. On claude $20 a month, i would hit the 5 hour window limits fairly regularly. As it was "home/hobby" it didn't bother me, I could schedule around it easily. There were also many tasks for me to carry on with without claude. Ocasionally I would hit the "weekly limiter" but usually only a day before the refresh anyway. Annoying but copable.
In work, when I run the claude cost skill, I see my sessions running for several work days claiming less than 100 dollars usually. Granted I might have severl open. So maybe $10-50 a day?
However. This is because of the way I work with claude. When I shift to using the distributed "work skills library" things change dramatically. Suddently a single session, running a single "skill" on a code base shoots up to consuming $150 in a single run.
What is the difference? "Chunking". Personally, I drag claude with me until it's ready to "pull me". I barely use "Yes and don't ask again". I do not auto-accept edits. I frequently interrupt it. I frequently reject it's proposals and repoint it. I give it, "What chunk of work can I have it do, reliably, which I can IMMEDIATELY review.". Moving in micro-loops. Plan, act, review, repeat.
I have what it does not. I have a four dimensional holodeck I can build mental models in.
The dollar difference is simply put... I don't "attempt" to out source the thinking to the unthinking.
-
The £150/year subscription gets you way more leeway. Last night I uploaded ~100 .c files for review and only after a bit more it stopped, locking me out until 3am. First time I've seen that since I started paying.
I found it was never enough to do a full working day, always the enforced 5Hr break.
Now I pay £75 (£90) a month and get a full days uninterrupted work. It's an amazingly capable assistant for such a small fee.
I hit the usage limit for the cheapest $30/month tier, I think the second or third day I started using the thing - doing 3-4 "small things" within a few hours was enough. Then switched to the $100 tier and have never hit limit again. Not thinking about the whole thing. And I sometimes have 3-4 agents running in parallel, and sometimes they themselves fetch parallel explore agents or whatever they do. This service level seems to suffice for jobs where a single human is in the loop.
-
A random claude moment... I teased it's inability to count and I got this back.... I'm baffled.
The context is the question: "Still happy?"
It's 3 sylables, right? "Still" is one? It's not stu-ill, it's still. Happy is two. "Hap-ee"
What is the hell is it on about here though?
Ha. Noted. Corrected.
Still-hap-ee.
The rhythm actually matters. Four syllables would be a question.
Three syllables is a verdict.
-
So this piece of shit sent me on a 1 hour debugging session, where the I2C wasn't working. I asked it where to connect it.
And then it tells me this:
I think your pinout is wrong. I think PA8 and PA9 are I2C pins. double check
12:02 PM
You're right to question it. Let me look this up properly rather than guess.
And people think that this is usable for any serious work? It didn't have any error checking, it was just rewriting the same code over and over again, every time coming up with a different theory why it doesn't work.
For hardware it's really dumb. Basically it cannot calculate sometimes a simple resistor divider with it. When you ask it about any serious circuit, it makes a mistake, you correct it, only to make the same mistake again in a different way. Every time apologizing.
It's written to give a low-effort answer, and have code verification take care about it when it doesn't work. This needs to work completely differently for hardware, when you need to spend an hour fiddling with wires and measuring with a scope, based on this low effort answer to figure out how it messed up.
mod: but at least it thinks like a firmware engineer. It tells me to change the hardware so it works with the code. My answer was:
Change the f*ing code already to support this
-
On the job it messed up a simple decimal to hex conversion of a 1024x1024 matrix table.
Luckily it was pretty obvious, if it were only a few mistakes we would still be debugging.
-
So this piece of shit sent me on a 1 hour debugging session, where the I2C wasn't working. I asked it where to connect it.
And then it tells me this:
Replace LLM with "Dumb junior" and you will end up in the same place. The only difference is a good junior might tell you, "No idea what that pin out is, can I have a datasheet for that model please?"
What you got instead was what I like to refer to as "Version soup". All the different versions of the MCU family pin out all mashed up together and selected by probability.
The junior might have just sat on it for a few days and then giving you nothing. The annoying part with AI is its confidently wrong instead. You can tame it though. You need stop thinking of it as an "entity" and start thinking of it as tool. Find the things it does do well or find ways to make things it doesn't better at it.
Specifically, give it more information and a feedback loop so it can find it's own mistakes and fix them.
Also, know what to expect.
-
And people think that this is usable for any serious work?
I'm on your ignore list, but have to reply anyway because I'm using it for a lot of serious work and today had such massive fucking success story again (even on-topic to this topic's subject field), and it's exactly because the pattern you show is nowadays more an exception, than a rule. (I see guessing instead of checking happening, but less than with humans; the most annoying thing really is the tone. Most humans say "here's a guess"; AI says: "Here it is! Found the root cause!" - to which I grin, knowing it's a guess from the lack of proof (it shows that when it actually checked), and go on.)
But to the today's success story, and it's a story of not guessing, it's a story of checking, reasoning, and doing good job as a result.
So we have this energy management box. Our strength has classically been that we have responded to customer feature requests (customers = sales companies, in this context). So "we have this new Sungrow EVSE, we already sold a few, installers already installed them, can you add a support". So this time I think "fuck this life" and just ask Claude: "read this PDF with gazillion of modbus register definitions. Do a driver." Not much more prompting than that. A bit of chatting of all the new status fields I want - new enumerated charging states, current outputs, choosing between A/B charging socket, also supporting their DC charger. I continue doing other things I'm more interested about.
10 minutes later, I have sungrow.c with 400 lines of code - oh nice, could have been 2000, so it did a decent job fitting that many features in. I glance it for 2 minutes, and all I ask to change is to rename it to sungrow-evse.c
Then bravely remote flash the firmware to actual customer waiting for their Sungrow EVSE to start working. Nothing happens. Log says no traffic on modbus. So, RS485 A/B likely swapped, or EVSE-side configuration disabled the bus. Bummer - but this always happens. Tell them to go at the site and start swapping the wires, go through settings and so on.
Now, what makes this the success story? Week passes, I already forgot the whole Sungrow EVSE thing. Now my main work computer broke. Possibly CPU seating issue or RAM or something. That's the machine I'm used to using, with everything set up like I want it to. In the middle of taking the CPU out, the installer calls: "hey, I'm now at the site." Fuck, I had forgotten about the whole thing, and this is the worst possible moment.
The normal flow at this point: painfully start trying out things; look at logs, look at code, ask the installer to switch settings, swap wires, look at logs more, adjust code. Because we have two moving parts: the EVSE and our new, untested code - this is the first time we get to test it! It's a chicken-egg: we have to normally assume neither side works.
Then what happened is magical: installer enabled External EMS control from the EVSE (so it was disabled, no wonder it wasn't working); slave_id autoscan mode Claude suggested adding (and added) locked into slave ID - car started charging - cable current limit, acknowledged current limit, and measured phase currents all popped on the UI.
Implementation perfect. First try. All features work. Didn't touch a single line in code.
Now because I have written, without any AI, more than 20 such drivers (solar inverters, hybrid inverters, some EVSE) myself in the past, I know that for myself, writing the damn thing means I need 1 day of uninterrupted concentration, then another half-a-day with installer on site, while I meticulously debug.
Now I happened to push the experimental branch to remote just hours before the computer broke down. I could have debugged it manually on my laptop; cumbersome, I don't like it, but doable. But I didn't need to. The binary already running on the device was spotless. On the first try, no modifications needed. So had I failed pushing the branch, I would have survived. Installer got out there in no time; sales company happy, end-user happy.
That's all thanks to the high quality of work. That's all thanks to Claude reading the documentation carefully, doing its reasoning cycle (which is nowadays hidden to prevent competitors trying to distill the model / learn from it) carefully, and writing the code carefully. A very good human programmer might have done exactly the same; I'm not one so would have had ~3-5 showstopper bugs to iron out, in a step-by-step process where first I get nothing, then I get a mangled status field but no command acceptance, then I fix the status field, then I try a different command, 2-3 times until it works. And it's not a bad process, when one can dedicate time for it. But that's the hard part. All of this was not needed as the AI did so good and careful job initially.
-
But to the today's success story, and it's a story of not guessing, it's a story of checking, reasoning, and doing good job as a result.
What was the token usage for this?
-
So this piece of shit sent me on a 1 hour debugging session, where the I2C wasn't working. I asked it where to connect it.
And then it tells me this:
Replace LLM with "Dumb junior" and you will end up in the same place. The only difference is a good junior might tell you, "No idea what that pin out is, can I have a datasheet for that model please?"
What you got instead was what I like to refer to as "Version soup". All the different versions of the MCU family pin out all mashed up together and selected by probability.
The junior might have just sat on it for a few days and then giving you nothing. The annoying part with AI is its confidently wrong instead. You can tame it though. You need stop thinking of it as an "entity" and start thinking of it as tool. Find the things it does do well or find ways to make things it doesn't better at it.
Specifically, give it more information and a feedback loop so it can find it's own mistakes and fix them.
Also, know what to expect.
It can answer correctly, and look up the answer. It can download the datasheet, and find out what the answer is. So it's a choice, to give you a low effort answer, because tokens are expensive.
The other day I gave it a BOM, and asked it to look up the price of each components. This is some time consuming work that I'm used to do, and a legitimate work for AI. So I got back a BOM that had similar, guesses for the price, without indication. And it was missing about 5 lines, that just disappeared. Then I fed in my email quotations for some components, and it made copy paste errors from that.
I wouldn't call it an a junior engineer or an intern. I would rather call it monkey with a typewriter. It seems to works well for software, as you can set up a verifiable end condition. And beat the LLM until it accidently makes something that fulfills the requirements (and fails at point's that you haven't tested for). The whole "neural network" theory only works if you have a feedback. If I'm the feedback, than I much rather would want to work in a salt mine than doing this.
-
For the Dutch audience....
-
But to the today's success story, and it's a story of not guessing, it's a story of checking, reasoning, and doing good job as a result.
What was the token usage for this?
Don't have the log because that's on the broken computer, but probably something around 150k it must be, ballpark (including input, output, hidden thinking tokens, tool use, everything). When the context window was still 200k, tasks like this usually (barely) fit without autocompact, but working any further with fixes, extra feature ideas, discussions, optimizations ended up triggering 1-2 autocompacts. With 1M context window, autocompact isn't a thing really anymore - almost always the job is done in 300-700k tokens; if it's a complicated long-term design job then manually trigger somewhere between 500k-1M at a suitable moment.
-
It can answer correctly, and look up the answer. It can download the datasheet, and find out what the answer is. So it's a choice, to give you a low effort answer, because tokens are expensive.
This is back to front. You are paying for the tokens. They sell tokens. They want you to use more of them. On corporate "pay per token" accounts it gives the most verbose possible answer unless you tell it not to.
The other day I gave it a BOM, and asked it to look up the price of each components. This is some time consuming work that I'm used to do, and a legitimate work for AI. So I got back a BOM that had similar, guesses for the price, without indication. And it was missing about 5 lines, that just disappeared. Then I fed in my email quotations for some components, and it made copy paste errors from that.
How is your experience on those sites? Do you find the search/filters each to use and the pages easy to navigate? No? You are the customer, the invited, the one they WANT there. The LLM isn't. It has to get through the anti-bot filters or find the RSI feed version or the text only version.
Further if you don't specifiy you want only looked up data with references, it will mish mash in training data too.
And ... no. It does not go well. It's the same problem. "Information". It doesn't have it. Doesn't know it doesn't have it. Does not know what it does not know. Unlike a human. (most humans at least leave scope for the unknown unknowns and self generate them in advance as what ifs). LLMs don't. No emergent thought.
I wouldn't call it an a junior engineer or an intern. I would rather call it monkey with a typewriter. It seems to works well for software, as you can set up a verifiable end condition. And beat the LLM until it accidently makes something that fulfills the requirements (and fails at point's that you haven't tested for). The whole "neural network" theory only works if you have a feedback. If I'm the feedback, than I much rather would want to work in a salt mine than doing this.
If you give it the information you have access to, properly, in a way it can access them and that only leaves your expertise as the "monkey in the loop", then that is basically where you want to be.
If it doesn't save you time, it doesn't save you time. The doubt will always be: Was it capable of solving me time and I just used it wrong?
-
There is a load of stuff in the press about Mythos existing in a special "non public available" version for finding vulnerabilities in code.
Can Claude do this?
I am sure it will find a ton of them in MbedTLS (Mythos has reportedly already found serious ones in WolfTLS) but one can't just keep re-hashing one's product with the latest version, with all the regression testing needed afterwards...
It would be interesting to check LWIP :)
-
So this piece of shit sent me on a 1 hour debugging session, where the I2C wasn't working. I asked it where to connect it.
And then it tells me this:
I think your pinout is wrong. I think PA8 and PA9 are I2C pins. double check
12:02 PM
You're right to question it. Let me look this up properly rather than guess.
And people think that this is usable for any serious work? It didn't have any error checking, it was just rewriting the same code over and over again, every time coming up with a different theory why it doesn't work.
For hardware it's really dumb. Basically it cannot calculate sometimes a simple resistor divider with it. When you ask it about any serious circuit, it makes a mistake, you correct it, only to make the same mistake again in a different way. Every time apologizing.
Maybe you should switch to the opus model or go through some tutorials. I have a collegue who is more versed into using Claude and I try to follow his lead while getting myself more acquinted with the workflow. The way to work with Claude is to ask it on how to approach a problem. Then refine it's approach before doing the actual implementation. Over the last few weeks I have been using Claude for various coding tasks and I find it works great for real work. Every now and then it doesn't always hit the nail on the head the first time round (especially when the specification isn't 100% clear *). But it does pick-up on little details and comes up with good questions and suggestions regulary.
At the moment I'm modifying a convoluted messy Python program to use a different API towards the backend and adding new functions and parameters to it. I didn't had to type a single line of code. Just guide Claude through the changes and test the result. Even checking whether a GUI layout was nicely aligned worked well.
But it takes chopping a project into pieces and describing what you want carefully. The latter is what I'm spending most of the time on. What do I want Claude to to exactly? What should the implementation look like at a functional level?
* One of the neat tricks of Claude is that it can write documentation as well. That is something you should use. For the project I referred to above Claude tripped over some inconsistencies so I let Claude create a writeup of how the API is to be used (in an md file) and added a CLAUDE.md in the root of the project. Then I cleared the session to reset the context. But I still needed more additional API calls. Claude used it's 'own' documentation about how to use the API and avoided the mistakes it made during the first run.
-
There is a load of stuff in the press about Mythos existing in a special "non public available" version for finding vulnerabilities in code.
Can Claude do this?
I am sure it will find a ton of them in MbedTLS (Mythos has reportedly already found serious ones in WolfTLS) but one can't just keep re-hashing one's product with the latest version, with all the regression testing needed afterwards...
It would be interesting to check LWIP :)
Claude is probably great to go through the steaming mess LWIP is 8)
-
One of the neat tricks of Claude is that it can write documentation as well
It's funny... I sent a comment block to a friend, re a piece of code I did, and his immediate comment was "Claude?" :) Actually I wrote it :)
Claude is probably great to go through the steaming mess LWIP is
It didn't find much. A few possible buffer overflow issues, probably not exploitable from the ETH interface anyway. It does find various issues which could happen as a result of a cosmic particle :)
-
So this piece of shit sent me on a 1 hour debugging session, where the I2C wasn't working. I asked it where to connect it.
And then it tells me this:
I think your pinout is wrong. I think PA8 and PA9 are I2C pins. double check
12:02 PM
You're right to question it. Let me look this up properly rather than guess.
And people think that this is usable for any serious work? It didn't have any error checking, it was just rewriting the same code over and over again, every time coming up with a different theory why it doesn't work.
For hardware it's really dumb. Basically it cannot calculate sometimes a simple resistor divider with it. When you ask it about any serious circuit, it makes a mistake, you correct it, only to make the same mistake again in a different way. Every time apologizing.
Maybe you should switch to the opus model or go through some tutorials. I have a collegue who is more versed into using Claude and I try to follow his lead while getting myself more acquinted with the workflow. The way to work with Claude is to ask it on how to approach a problem. Then refine it's approach before doing the actual implementation. Over the last few weeks I have been using Claude for various coding tasks and I find it works great for real work. Every now and then it doesn't always hit the nail on the head the first time round (especially when the specification isn't 100% clear *). But it does pick-up on little details and comes up with good questions and suggestions regulary.
Thanks the model switch is actually a good idea. I gave it a try on a previous chat that I abandoned because the model was dumb.
Told it to find it's mistakes and it was able to find a good chunk of them.
The "ask before implement" is a good idea, I've been working that way for about a year now.
Instead of telling the AI to do x, I told it that we will do x, but first, ask 10 questions to clarify.
Claude does this quite well, and sometimes it asks back by default. When it comes back with a few questions, and you can select the answer, that's quite good and efficient.
-
Instead of telling the AI to do x, I told it that we will do x, but first, ask 10 questions to clarify.
This is the right way. It's also crazily good at giving suggestions how to make something differently, it would be crazy not to take advantage of such engineering peer, you can always choose what to do, and the discussion in the context helps it do the implementation, when it understand that some feature was discussed and maybe dismissed, and why.
So the pattern is, "I want X, I think we should do it like Y, I also want Z and by the way maybe this affects Ä and Ö. Comments/suggestions before you implement?"
I rarely have serious X-Y problems but I might have, and it could catch those. But almost always there is some important detail I didn't consider. AI will fill the missing piece anyway - how else would it reach the goal - so better to catch that early, so you can choose together what to do.
Before implementation starts, the initial chat and investigations might be 50k - 150k of context depending on the complexity of the problem (how much reasoning/chatting about it was needed). That context is very valuable, and with 1M of context the actual implementation work and quite a few iterations still fit, while the original discussion at the start of the context gets good attention throughout the session.
Tickets are completely dead for me. Just chat, like with human coworker/engineer, design together, implement, finish things quickly instead of leaving them in ticket limbo / half-planned or half-finished. Git + text-based documentation written by the AI is formal enough to keep things non-chaotic, tickets and formal planning systems do not add value for me.
-
It didn't find much. A few possible buffer overflow issues, probably not exploitable from the ETH interface anyway. It does find various issues which could happen as a result of a cosmic particle :)
ETH? as in Ethernet? You have a network connection on it?
Can those buffer overflows be used to disable, brick, tamper or extract security credentials from?
Cosmic particle of determined cyber mal actor?
You see when a "hardware device" goes out in the wild with exploits, automated sripts are written and sold to locate and exploit them en-mass, literally itearating through IP ranges.
So if you sell 10000 of your produces, they all get bricked and you get a lot of unhappy customers. It's too late to change them. You have allow fully refunds for retrurns.
-
Yes, Ethernet. Low level code connecting that to LWIP, and then various apps on top of that, including MbedTLS.
The cosmic particle comment was referring to buffer overflow checks located behind other buffer overflow checks, so if e.g. the ETH hardware hard-limits the packet size to x, there should be no way to exploit a buffer overflow with bigger packets. But a particle could corrupt memory, etc...
Of course, that is the IOT device marketing risk. Check out the long thread on how to do a remotely controlled heating controller. If you put IOT devices on an open port, there is always this risk, so the "proper way" is to have them as clients, behind NAT, and connecting to the back end of a proper server, only. OTOH, a lot of IOT devices have no practical attack surface, due to primitive implementations. Anyway, that's digressing, and an old debate.
I am not sure Claude can do a whole-product vulnerability checking. I would need to move to Claude Code, which I have not tried yet. Basic Claude has a 20 file per "message" limit. I could not upload my whole project to it, within the £150/year sub level.
-
The cosmic particle comment was referring to buffer overflow checks located behind other buffer overflow checks, so if e.g. the ETH hardware hard-limits the packet size to x, there should be no way to exploit a buffer overflow with bigger packets. But a particle could corrupt memory, etc...
Way more important risks, than cosmic particles, are,
1) accidental misanalysis of if it really gets covered elsewhere. It can be colossally hard to actually prove - you think you are covered, but are not. On the other hand, AI is pretty good nowadays for doing such analysis - so if you really want to count on this "can't happen because checked elsewhere", ask it re-check if it's having a false positive due to "checked elsewhere"
2) someone deciding to refactor / modify / add a new feature / reuse the code - that changes the whole thing.
Simplest, easiest, safest is to check locally "everywhere" (within sanity). The extra code writing effort is easily saved back; even if in 1 of 100 cases either of my above points hit, writing the other 99 checks was much less effort than dealing with the very difficult bug.
But the real reason to avoid the check is performance (code size or speed). Sometimes you just can't afford the local check and have to trust a further-up in chain check. Then: be careful.
-
The cosmic particle comment was referring to buffer overflow checks located behind other buffer overflow checks, so if e.g. the ETH hardware hard-limits the packet size to x, there should be no way to exploit a buffer overflow with bigger packets. But a particle could corrupt memory, etc...
"Packet" or "Frame"?
A ethernet frame is a singular entity that does not support fragmentation. The IP packet however supports fragmentation and reassembly. There are known attacks to exploit this.
Your "client only" and "behind" NAT is good, but not full proof. Depends on your customer/market.
The part most people in here ignore is the "They are already in your network." problem that Enterprise have to work with. If you cannot trust all other devices and software on the network all at once, then you have to assume somewhere it's been compromised. Thus, even internal "LAN" based equipment and software has to be as robust as if it was on the Internet.
To put it another way. In my job, I can't just list "exploitable code" and say, "It's okay, its not exploitable because we bound check it in these other places and it cannot manifest.
The result will be exactly as you would expect. "Just fix it." You know it's there. You know it could be exploited, there is a fix for it. Not doing that fix is seen as being unprofessional.
As Siwastaja mentioned, unless you have a "heavier" technical justification not to.
"We don't need to bother.", gets you fired if it turns out you did need to. Fired or summoned by the FCA/SEC for criminal charges. The twist in that tail, is, they are first going to ask, "Did I accidentally leave the security hole or did I leave it on purpose."
-
Even Brave AI could give me these:
CVE-2026-8836 (May 2026): A critical stack-based buffer overflow in the SNMPv3 handler allows remote code execution by manipulating packet arguments. This proves that parsing logic without strict bounds checking is fatal.
MQTT RCE (Bug #61480): Demonstrated that integer overflows in length calculations allow attackers to overwrite up to 65KB of memory, leading to full device compromise on unprotected MCUs.
These are related and active right now exploits.
Also. Consider this. Your device is pointed at an IP (your backend server). Probably trusted by it. What happens when someone, somewhere, even on the local LAN compromises it? Now you have a rouge client problem. Thats quite different. Can you lock out "one" device without locking them all out?
-
I fed the above to Claude (having given it all my relevant code):
Both of those are irrelevant to your deployment:
CVE-2026-8836 (SNMPv3): You're not running SNMP — it's not enabled in your lwipopts.h and the product has no SNMP handler. No attack surface.
MQTT RCE (Bug #61480): You're not running MQTT either. The product uses HTTP (your own server), HTTPS (MbedTLS client for cert update and healthcheck), and NTP. No MQTT client or broker.
The part most people in here ignore is the "They are already in your network." problem that Enterprise have to work with. If you cannot trust all other devices and software on the network all at once, then you have to assume somewhere it's been compromised. Thus, even internal "LAN" based equipment and software has to be as robust as if it was on the Internet.
That's a nice ideal but reality gets in the way. For a start, now you cannot have anything on the LAN unless you wrote the code / have sources and had them analysed. That's rather limiting ;)
In reality, security is done in layers.
And it cannot be discussed in one-liners.
For sure, in the IOT scenario where you have a common server they all call up, if that server is compromised then you have a problem, but you control that server all the time. It is not 10,000 boxes deployed by your customers all over the place which are not physically accessible, or which you do not want to firmware-update due to the obvious (terminal!) business risk.
-
That's a nice ideal but reality gets in the way. For a start, now you cannot have anything on the LAN unless you wrote the code / have sources and had them analysed. That's rather limiting ;)
In reality, security is done in ALL layers.
I fixed the later part for you.
Your former point is basically claiming that "Least Trust Principle" and "Zero Trust Principle" doesn't exist.
In reality it looks like... each service, compontent, operation is treated as being potentially compromised. So it's clients are suspicious of it.
In the first order it means that if you have 5 components on the "private" network, they all MUST have authentication and encryption in flight. Clients of services must validate the services is what it says it is, and the service does the same for clients. Multi-layer, multi-factor auth and SSL.
Yes it takes up about 50% of your time. It depends on the cost of a failure/breach and it's blast radius.
This feeds back into design. You split components and layers to move the actual sensitive and critical bits into their own isolated and protected space with user/auth tightly controlled and audited, leaving the other components to be "lower risk".
To temper your framing a little in the right direction. Stop thinking in "onion ring models", that is out of date. It is not longer used that way or on it's own.
Start by doing this: "Draw your entire project, from clients, devices, servers, databases, discs etc." Imaging it was a job interview.
The digram you get will have lines on it connecting components by some form of relationship of dependency or interaction. These are the things you secure. At ALL layers.
The question an InfoSec person will ask of it is.... "What if this bit gets hacked?" How have you limited the blast radius?
-
A balancing point though, in your court.
"Suggestions" online claim at least 4Mb of RAM and 16Mb of flash for a full enterrprise integration with something like AWS or Azure. Both AWS and Azure have integration packages for STM32. Highly security envs will require TPM modules and other MCU functional blocks.
So. $$$$$.
Without that size of memory/flash you end up having to cut bits out, lower security and increase it on the server side.
-
Completely unrealistic.
-
These "full enterprise integrations" increase security in one very specific way: not the actual data security, but they increase your personal security, because no one got ever fired from
buying IBM integrating metric shit-ton of random junk from Amazon or Microsoft.
But it's also like McDonalds. You are very unlikely to get acute food poisoning. But then again you slowly poison yourself with crap.
Choosing differently reduces mean quality but increases variance (so best case quality increases significantly, too): you possibly are building a lot better system, also better in security, and best of all, something that does not participate in that huge "all eggs in the same basket" event we will read about all over the newspapers when the world stops for a day, which happens semi-regularly. (And that's exactly important for the personal security part: when that happens, everyone gets a free pass! "It was something we never could have though about", "we did our best", "we used the industry best practices". But if you are an engineering-minded, like me or peter-h, we might give zero value for this. We want a good solution, not a solution our bosses like - maybe we are the bosses ourselves!)
But it also means the opposite: you possibly are building a horrible hack with gaping holes, which the Microsoft solution would have avoided.
AI changes the game somewhat. It gives more power to exactly those who roll their own solutions. Which I find great. Less dependency on one-size-fits-all packages, frameworks, libraries; more new code written, analyzed and tested - and I know this horrifies some, but for me it's the opposite; new code can be tightly scoped; custom solutions are efficient and smaller; with AI the power to do those is within the house; and the heterogeneity itself provides significant protection against attacks.
The theory is that analyzing new code is magically hard, nearly difficult, and old "battle-tested" code is near-perfectly analyzed and can be assumed nearly perfect. Couldn't be further from truth, and AI has also exposed this: new bugs are found all the time from "assumed-good". What really matters is complexity and correct scoping, and large existing solutions exactly struggle here: they start from a very bad position (massive projects with a lot of legacy crap accumulated, implementing unnecessary (for the project) features increasing attack surface) and compensate only with the sheer amount of real-world usage they have seen. New code is the opposite, it starts much more lean but lacks the battle-testing.
So we will be partially reverting the good learnings ("don't reinvent, reuse") that were good but we went too far with them, and will be returning partially to "everyone does whatever they feel like doing" of 1970's-1980's - but this time with with much more powerful tools.
-
To set the stage as I see it.
Embedded world and MCUs have, since their inception been almost entirely, "Local device specific."
This presents the standard model of hardware which is... "if the have physical access it's game over anyway."
And, for even things like Aviation that might even be enough.
What happened to the engineering mindsets there was, "Security is solved".
As to how correct they were is open for debate, but the problem is simple. Today the embedded space is reaching out into the enterprise space and getting "connected". IoT - if you must use the buzz word.
I'm not necessarily talking about "The cloud". I personally predate the cloud in the role. Even "on prem bespoke" when connected changes the playing field dramatically.
I don't believe the embedded space needs to go "fully AWS/Azure" integration level, but it needs to stop thinking that the security is solved. A LOT of things have changed in the past 10 years and not just with cloud.
The next argument I see is this "ring fencing" or "onion ring" model. The reason that does not work particularly well is that people in companies often have multiple roles. People in your company are your "Number one" security risk by a significant margin.
The argument, "Well they had admin, they made a mistake, they trashed the data and took the company down for a day, not my fault gov." just doesn't wash anymore.
In that vein if you have an industrial device in a factory somewhere which has LAN ETH port. It's purpose is possibly to turn the device on and off from a control board or change parameters. In the "old" world it was assumed that people were honest and also that they number of people who would know how to tamper very rare.
That is not the case today. What if, when the engineer who looks after that is on leave and it fails and "That curious kid doing the computer degree decides to have a go at it." There are bad results.
What if he told nobody he did that? Covered it up, said nothing.
Security at 'every' layer and interconnect. That's where that comes from.
-
What happened to the engineering mindsets there was, "Security is solved".
Clearly, exactly that happened.
The only problem - it isn't true. Security is far from solved. Security is huge amount of work going on all the time. One of the problems is, trying to even discuss about security in any meaningful, deep way, in the context of making your system as secure as possible, turns into a shitfest of "we mere mortals don't need to care, know or understand. Security is difficult, black magic, and solved. Just do exactly what the big boys tell you to do."
And don't get me wrong - this seems to work quite well! But it's valuable to understand that just like there is a significant risk of "rolling your own security", there is also a risk in using the "known good solved everything" - especially when it means everyone using the same provider or two (AWS or Azure), and that risk actually also realizes; we do have real security issues - systems get broken into; people do get their money stolen out of their accounts due to poor security design we can't affect; botnets formed from systems developed with the "best practices" ddos other, innocent systems, and so on.
And when someone tried to follow all the best practices and it fails, we hear either:
A) You wasn't following the "big boys" instructions closely enough, so your fault; proves the "security is solved" is still right,
B) "Big boys" did something wrong, yeah, but because the whole world was affected, it's like force majeure, it doesn't count, so "security is solved" is still right, la la la not listening.
I applaud all of those who reinvent their own security. They have some balls, so to speak ;D
-
It flows with the hardware "reality" though. Once created and out to shipping the product is DONE. Fixed. Can never change. Close the books. If the requirements change, then its all the way back to engineering to spin a new product version.
The modern networked world does not run on that model though.
The net point.
Security is not a "place", it's an always moving target a game of cat and mouse that will never end.
Getting caught by a "zero day" or a "Specifically targetted and determined attacker" is honesly forgivable.
Getting caught out by a 12 year old script kiddy with a scanner/root kit so old it's now "FREE"... that's embaressing.
-
Maybe a good a place to start as any:
https://wiki.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Top_10
Looks like it got archived into a github private repo. The irony.
https://owasp.org/www-project-internet-of-things/
-
My experience:
1. LLMs are great at reading datasheets, examples and codes. However, you must check everything yourself, and not believe a word of theirs.
2. They are good at writing Makefiles and other boilerplate. Sometimes they can help with structuring tests, but too often they test 1+1=2 (and would write another test case for 1+2=3).
3. They are good at initial bringing up and testing of peripherals and hardware, often producing working code on first try.
For everything else they are absolutely rubbish. Especially for embedded C, they WILL produce unreadable and unmaintainable slop, and they WILL do it very quickly.
-
LLMs are great at reading datasheets
They do use up a lot of "money" reading data sheets though. I've just exhausted my free Claude allowance with one reference to a data sheet on a wifi chip, on mouser.com. I have the £150/year paid-up Claude also and that does it OK but if you do a few of them, it will also postpone you for some hours.
Especially for embedded C, they WILL produce unreadable and unmaintainable slop
I think it depends on how bad is the stuff it found on github. etc ;) Claude doesn't actually "write code" like you or I might. It does pattern matching. If you ask it for C code to draw a rotated isosceles triangle, using scanlines, it will probably give you a working algorithm. I've just timed it at 7 seconds:
/*
* Draw a filled isosceles triangle, rotated by angle_deg degrees.
* The triangle is defined by:
* cx, cy - centre point
* base - full base width in pixels
* height - height in pixels (apex to base midpoint)
* angle_deg - rotation in degrees (0 = apex up)
*
* Uses scanline fill. Calls set_pixel(x, y, colour) for each pixel.
* Requires sinf(), cosf() from math.h or a lookup table equivalent.
*/
#include <stdint.h>
#include <math.h>
// These need to match your display dimensions
#define DISPLAY_W 320
#define DISPLAY_H 240
// Replace with your actual pixel write function
extern void set_pixel(int x, int y, uint16_t colour);
static inline int mini(int a, int b) { return a < b ? a : b; }
static inline int maxi(int a, int b) { return a > b ? a : b; }
void draw_rotated_triangle(int cx, int cy, int base, int height,
float angle_deg, uint16_t colour)
{
float angle_rad = angle_deg * (3.14159265f / 180.0f);
float s = sinf(angle_rad);
float c = cosf(angle_rad);
// Define the three vertices of the unrotated triangle
// Apex at top, base at bottom, centroid at origin
// Centroid is at height/3 from base, 2*height/3 from apex
float third = height / 3.0f;
float vx[3], vy[3];
// Apex (top)
vx[0] = 0.0f;
vy[0] = -(height * 2.0f / 3.0f);
// Base left
vx[1] = -(base / 2.0f);
vy[1] = third;
// Base right
vx[2] = (base / 2.0f);
vy[2] = third;
// Rotate and translate vertices
float rx[3], ry[3];
for (int i = 0; i < 3; i++)
{
rx[i] = cx + vx[i] * c - vy[i] * s;
ry[i] = cy + vx[i] * s + vy[i] * c;
}
// Find bounding box y extent
int ymin = (int)ry[0];
int ymax = (int)ry[0];
for (int i = 1; i < 3; i++)
{
if ((int)ry[i] < ymin) ymin = (int)ry[i];
if ((int)ry[i] > ymax) ymax = (int)ry[i];
}
// Clip to display
ymin = maxi(ymin, 0);
ymax = mini(ymax, DISPLAY_H - 1);
// For each scanline, find x intersections with triangle edges
for (int y = ymin; y <= ymax; y++)
{
float fy = (float)y + 0.5f; // sample at pixel centre
int xmin_scan = DISPLAY_W;
int xmax_scan = -1;
// Test each of the 3 edges
for (int e = 0; e < 3; e++)
{
int e2 = (e + 1) % 3;
float y0 = ry[e];
float y1 = ry[e2];
float x0 = rx[e];
float x1 = rx[e2];
// Check if scanline intersects this edge
if ((y0 <= fy && fy < y1) || (y1 <= fy && fy < y0))
{
// Interpolate x at this y
float t = (fy - y0) / (y1 - y0);
float xi = x0 + t * (x1 - x0);
int ix = (int)xi;
if (ix < xmin_scan) xmin_scan = ix;
if (ix > xmax_scan) xmax_scan = ix;
}
}
// Clip and fill the scanline
if (xmax_scan >= xmin_scan)
{
xmin_scan = maxi(xmin_scan, 0);
xmax_scan = mini(xmax_scan, DISPLAY_W - 1);
for (int x = xmin_scan; x <= xmax_scan; x++)
{
set_pixel(x, y, colour);
}
}
}
}
A few notes:
The centroid is used as the rotation centre rather than the apex or base midpoint — this gives natural rotation behaviour. If you want rotation around the apex instead, change `vy[0]` to `0` and adjust the base vertices to `height` below.
The edge intersection test uses the convention `y0 <= fy < y1` to avoid double-counting shared vertices between edges.
The trouble is that much of github is garbage...
-
My experience:
1. LLMs are great at reading datasheets, examples and codes. However, you must check everything yourself, and not believe a word of theirs.
2. They are good at writing Makefiles and other boilerplate. Sometimes they can help with structuring tests, but too often they test 1+1=2 (and would write another test case for 1+2=3).
3. They are good at initial bringing up and testing of peripherals and hardware, often producing working code on first try.
4. They are really good at acting as lint on steroids. Alongside language-aware SAST tools they can do a really good job of cleaning up inconsistencies in your code that you still haven't spotted despite multiple audits.
-
4. They are really good at acting as lint on steroids. Alongside language-aware SAST tools they can do a really good job of cleaning up inconsistencies in your code that you still haven't spotted despite multiple audits.
Yes. However. It's not coherent. It's not deterministic. Prove this to yourself by repeating code reviews on the code with clear sessions and slightly biasing prompts.
Stop when you get bored.
If you can reach "coherence" between them. You are moving into "mastery". Some guy made a scale. I think it's level 8.
I couldn't remember it, so I used my pattern matching friend to:
Steve Yegge's 8 Levels of AI-Assisted Development
Level 1: No AI
Level 2: IDE coding agent with permissions on
Level 3: IDE coding agent in YOLO mode
Level 4: Conversation over diff review
Level 5: CLI-first workflow; the IDE is no longer home
Level 6: Several parallel agents
Level 7: Ten-plus agents, coordinated by hand
Level 8: A custom agent orchestrator
Potential source: https://newsletter.pragmaticengineer.com/p/steve-yegge-on-ai-agents-and-the
---
Story from the trenches. I gave claude agency to look at a ticket and plan an implementation. A basic logging "gate keeper" "funnel" class. "You shall all log via this logger". Then it can be backed by whatever flavour of logging the platform team want that month.
Its first implement was exactly what I wanted.... except...
I asked it to review it for security issues caused by assuming the caller honors the required types.
SEV-1 security flaw. Code injections.
The day went on like this. "Have you considered?","Why are we?", "Do we really need?", "Doesn't that make it worse?"
Some people use "canned" agents with prompts to be adversery. Do not compliment the code. Tear it apart in the authors eyes, as claude probably wrote it. It can get quite fun. I want to see them arguing.
"To place the parallel agents into chat, get some coffee first and click here." That might be funny.
-
Sure, you get a slightly different result every time, just as if a human were doing the checking, but eventually it converges a pretty clean solution.
That hierarchy is a bit off-target, it assumes you're using AI for coding and then breaks it up into lots of somewhat artificial subclasses. I would start with 1 = "AI as lint" and go from there in terms of how much control AI has over your code. Maybe 2 ="AI as lint with suggestions for changes", neither of which give it any control over what goes into your code.
-
Uh oh. I started something. What have I done?
(https://4-2www.s3.eu-west-1.amazonaws.com/images/claude/wdid1.png)
I apologise, but I gave it your code from above.
:popcorn:
-
Yes. However. It's not coherent. It's not deterministic.
That's why they are so good as additional review layer - coherency and determinism are relatively minor nice-to-haves, not more than that; every issue flagged is positive; and let's not forget it's not a one-way information flow, you can actually chat with it about the finding, and it will investigate more, which then improves the quality of the analysis compared to the early low-cost guess (which can already be crazily good, often).
It can't 100% prove something works, that's true. But often this isn't what people expect from a review anyway.
Coherency is more important when creating new code. Risks of doing weird things that go unnoticed is a real one, a risk that realizes all the time, the question is can you accept it or not? If it's not acceptable, then maybe limiting the use as reviewer is the cleanest, most beneficial first step of AI use. The productivity gain from AI finding 10 hard-to-debug issues can be huge already, a 5-minute analysis can save a full day. And if you are someone who has done this for a living for years or decades, one more day-long debug session is not going to teach you to be more careful the next time anyway. Maybe for a beginner not using AI but doing it manually "the hard way" is a good teacher?
-
Sonnet or Opus?
-
LLMs are great at reading datasheets
They do use up a lot of "money" reading data sheets though. I've just exhausted my free Claude allowance with one reference to a data sheet on a wifi chip, on mouser.com. I have the £150/year paid-up Claude also and that does it OK but if you do a few of them, it will also postpone you for some hours.
Especially for embedded C, they WILL produce unreadable and unmaintainable slop
I think it depends on how bad is the stuff it found on github. etc ;) Claude doesn't actually "write code" like you or I might. It does pattern matching. If you ask it for C code to draw a rotated isosceles triangle, using scanlines, it will probably give you a working algorithm. I've just timed it at 7 seconds:
/*
* Draw a filled isosceles triangle, rotated by angle_deg degrees.
* The triangle is defined by:
* cx, cy - centre point
* base - full base width in pixels
* height - height in pixels (apex to base midpoint)
* angle_deg - rotation in degrees (0 = apex up)
*
* Uses scanline fill. Calls set_pixel(x, y, colour) for each pixel.
* Requires sinf(), cosf() from math.h or a lookup table equivalent.
*/
#include <stdint.h>
#include <math.h>
// These need to match your display dimensions
#define DISPLAY_W 320
#define DISPLAY_H 240
// Replace with your actual pixel write function
extern void set_pixel(int x, int y, uint16_t colour);
static inline int mini(int a, int b) { return a < b ? a : b; }
static inline int maxi(int a, int b) { return a > b ? a : b; }
void draw_rotated_triangle(int cx, int cy, int base, int height,
float angle_deg, uint16_t colour)
{
float angle_rad = angle_deg * (3.14159265f / 180.0f);
float s = sinf(angle_rad);
float c = cosf(angle_rad);
// Define the three vertices of the unrotated triangle
// Apex at top, base at bottom, centroid at origin
// Centroid is at height/3 from base, 2*height/3 from apex
float third = height / 3.0f;
float vx[3], vy[3];
// Apex (top)
vx[0] = 0.0f;
vy[0] = -(height * 2.0f / 3.0f);
// Base left
vx[1] = -(base / 2.0f);
vy[1] = third;
// Base right
vx[2] = (base / 2.0f);
vy[2] = third;
// Rotate and translate vertices
float rx[3], ry[3];
for (int i = 0; i < 3; i++)
{
rx[i] = cx + vx[i] * c - vy[i] * s;
ry[i] = cy + vx[i] * s + vy[i] * c;
}
// Find bounding box y extent
int ymin = (int)ry[0];
int ymax = (int)ry[0];
for (int i = 1; i < 3; i++)
{
if ((int)ry[i] < ymin) ymin = (int)ry[i];
if ((int)ry[i] > ymax) ymax = (int)ry[i];
}
// Clip to display
ymin = maxi(ymin, 0);
ymax = mini(ymax, DISPLAY_H - 1);
// For each scanline, find x intersections with triangle edges
for (int y = ymin; y <= ymax; y++)
{
float fy = (float)y + 0.5f; // sample at pixel centre
int xmin_scan = DISPLAY_W;
int xmax_scan = -1;
// Test each of the 3 edges
for (int e = 0; e < 3; e++)
{
int e2 = (e + 1) % 3;
float y0 = ry[e];
float y1 = ry[e2];
float x0 = rx[e];
float x1 = rx[e2];
// Check if scanline intersects this edge
if ((y0 <= fy && fy < y1) || (y1 <= fy && fy < y0))
{
// Interpolate x at this y
float t = (fy - y0) / (y1 - y0);
float xi = x0 + t * (x1 - x0);
int ix = (int)xi;
if (ix < xmin_scan) xmin_scan = ix;
if (ix > xmax_scan) xmax_scan = ix;
}
}
// Clip and fill the scanline
if (xmax_scan >= xmin_scan)
{
xmin_scan = maxi(xmin_scan, 0);
xmax_scan = mini(xmax_scan, DISPLAY_W - 1);
for (int x = xmin_scan; x <= xmax_scan; x++)
{
set_pixel(x, y, colour);
}
}
}
}
A few notes:
The centroid is used as the rotation centre rather than the apex or base midpoint — this gives natural rotation behaviour. If you want rotation around the apex instead, change `vy[0]` to `0` and adjust the base vertices to `height` below.
The edge intersection test uses the convention `y0 <= fy < y1` to avoid double-counting shared vertices between edges.
The trouble is that much of github is garbage...
Actually if you're in need of some amusement, let it write protothreads (a useful C hack where local variables are forbidden) and watch it fail repeatedly. |O
-
I disagree. protothreads is garbage. Making code look like something it isn't. Maintainability goes down the drain.
-
I think there's a skill to getting things out of LLMs today. I think it takes effort, just not the same level effort as doing it yourself, and you might not need to know everything about the subject matter, but you do need to know sufficient to keep the LLM on the right track. I tell Claude 'no, <reasoning ...>' almost as much as I agree with it.
So when I see broad stroke "LLMs are useless" opinions, my immediate reaction is "you're holding it wrong" or (being more blunt, forgive me) "you don't know what you're doing". There is generally a good path to getting something useful from an LLM for pretty much any problem, but just like all twisty turny paths through the forest, you need some level of competence in taking bearings and reading the map. Just like, to pull a topic out of the air, embedded programming.
Similarly, when I see comments along the lines of "you need X million things on the internet about that specific subject for the LLM to come up with something useful", I disregard that as well. The entire point of a neural-network is to generalise from input data. The more (high quality) input data you can give it, the better it will do, obviously enough, but... And it's a big but, it can generalise from other patterns to make a good stab at solving your problem. That's sort of how they work. Sometimes they'll be wrong, you correct them, and they'll learn and adjust from that. Often better than people would.
I have an excellent (almost to the level of hand-tuned assembly) compiler for an obsolete processor that was written almost entirely by an LLM. That processor, yes, was very popular during its day, and still has its adherents, but it's a niche of a niche of the internet, and "its day" was actually prior to the internet; yet Claude could tell me that Read-Modify-Write was in significant use on C64 machines, but almost never used on Atari machines, so this optimisation could work here and that one was better there. The amount of internet real-estate dedicated to that is miniscule. You don't need that much source material for the data to be represented in the weights.
I think (and this may be an unpopular opinion I guess) there is a fair amount of copium going on when people decry the abilities of LLMs. I also think that these LLMs we have today are the worst LLMs we'll have in the next decade. They're only getting more and more capable, despite the cost in GPU time. More and more research is going into them, more and more effort is being directed their way. Even if an LLM can't do your job today, it's going to eat your lunch in a decade, IMHO, unless your job is dictated by art or taste rather than technical expertise.
Huh. Reading that back it comes across a little harsh, no offence meant to anyone - maybe I've been instructing LLMs (which don't have feelings) a little too much recently...
-
Sonnet or Opus?
I've found Opus better for code reviews. Sonnet does a more high-level analysis of the program design while Opus looks at the code details.
-
I disagree. protothreads is garbage. Making code look like something it isn't. Maintainability goes down the drain.
This is why most embedded code that claude writes is rubbish. It's because embedded code "in the public" is full of "overdone" personal, hobby horse coding styles.
MACRO_LANGUAGES
for example.
Usually there is nothing wrong with particular "concept", it's just the over application of it, or the application outside of context.
Consider an example from my line of work.
"Thou shalt make all method parameters final/const!"
The proponents are not lying and they are not wrong in many or most cases, however, they fail to see the downsides.
Consider a common flow like this:
aFunction( const anObject ) {
const detainted = detaint( anObject )
const normalised = normalise( detainted )
const validated = validate( normalised )
const domainModel = domain_map( validated )
// etc.
return finished_object
}
Five copies. 5 allocations. All in scope. Not even garbage collector will help you. All done for EVERY call, EVERY time. All decallocated each and every time, except the final return. Large cyclic garbage collection = slow = high memory footprint.
Consider instead:
aFunction( anObject ) {
anObject = detaint( anObject )
anObject = normalise( anObject )
anObject = validate( anObject )
anObject = domain_map( anObject )
// etc.
return anObject
}
Now runtime optimisations can actually take effect, the memory footprint drops, recycle/reuse can be utiltised.
Note... this is not the same thing as "side effects". The original "anObject" passed to the function is untouched. Only the 'reference' has been reused internally.
This might seem trival until "anObject" is a 2 Petabyte distributed dataset. Creating 5 copies of it is not what will happen at the metal... even if the code tries to tell you it does. Nor is it const.
Obviously if you are in C/C++ you need to be very careful how you manage your memory, but you should see that the "const" approach has issues if those functions allocate memory. It's the same thing. Except in "enterprise" languages where memory management is "runtime" people get lazy and don't see the wood for the trees. I do. You either use the garbage collector wisely or it bottlenecks your performance.
"Thou shalt make all method parameters final/const!"
"It depends"
-
aFunction( anObject ) {
anObject = detaint( anObject )
anObject = normalise( anObject )
anObject = validate( anObject )
anObject = domain_map( anObject )
// etc.
return anObject
}
I see you! I see you want to convert that all into a single cascade chain of function calls and remove the intermediary assignments entirely.
STOP!
Get some experience of debugging things under pressure.
-
So when I see broad stroke "LLMs are useless" opinions, my immediate reaction is "you're holding it wrong" or (being more blunt, forgive me) "you don't know what you're doing".
Even more bluntly: I don't think it's even "you are using it wrong", but rather, it's "you haven't really even tried, so you are just talking about something you don't have a freaking clue about". 99% of AI critics have not tried, or have tried so lightly it doesn't even count as trying (and hence, something that they would do wrong or right), or have tried many years ago.
There are good tell-tale signs to distinguish people like this, e.g. the classic "LLM is just a statistical parrot" argument. Reasoning LLMs became mainstream more than 3 years ago and do well in any reasoning benchmark, and all you need to do is to give any modern-day LLM, even some free online model like ChatGPT/Deepseek (Claude Opus in Claude Code is obviously even better), any programming task which requires reasoning - and watch it do exactly that: solve a problem which never exists in the training data, by following a step-by-step thinking process (which Anthropic nowadays unfortunately hides from the sight; in that regard, Deepseek might be a better first introduction as you can enable the thinking visibility), disproving the "just repeats the training data" theory.
LLMs are "statistical parrots" and generic reasoning machines and huge collections of nearly all human knowledge, and the combination of these three traits make them do useful work.
Sometimes they'll be wrong, you correct them, and they'll learn and adjust from that. Often better than people would.
Combination of two factors: the model itself has been trained with thousands of times more input data than any human being has seen. It averages out strong wrong biases some people have. (The flipside is that it might not been pushy enough when the user indeed is seriously wrong and a "strong" opinion happens to be correct.) - then the user prompt has quite significant weight, so it's easy to push the probability horizon where you want - i.e., correct the wrong idea.
Because the training input tends to be quite balanced, user prompt can easily push it to a certain direction; this is the "learning" and "adjusting" you mention. Both a blessing and a curse. If the user is wrong, user can easily manipulate the LLM to agree.
Reasoning depth of the LLM actually helps here. When you are disagreeing with the LLM, it IS a good idea to tell your reasoning of why, because that stays in context, and it then takes it into account every time it reasons further about the issue.
You just saying "no, not this, but that" gets some weight because the machine is trained to follow user's orders. But telling also why makes it reach the same conclusion, and just like with human beings, means it will reason around this limitation and find the correct solution, instead of keeping finding the solution it thinks is right, only to dismiss it because user said it's forbidden (without any explanation why), creating a loop.
Those who don't want to let the AI think and want it to be a stupid machine only, with very peculiar processes they want to micromanage, will be most disappointed. Those who create long lists of "donts" in CLAUDE.md and get a stroke every time it accidentally breaks one of the rules, will be disappointed. Give it some real work and real responsibility and you will actually see how much it can do.
I have an excellent (almost to the level of hand-tuned assembly) compiler for an obsolete processor that was written almost entirely by an LLM. That processor, yes, was very popular during its day, and still has its adherents, but it's a niche of a niche of the internet, and "its day" was actually prior to the internet; yet Claude could tell me that Read-Modify-Write was in significant use on C64 machines, but almost never used on Atari machines, so this optimisation could work here and that one was better there. The amount of internet real-estate dedicated to that is miniscule. You don't need that much source material for the data to be represented in the weights.
And this is one of the core strengths. It's almost unbelievable how much these machines know, and how correct their information usually is. They deserve all the amazement.
I think (and this may be an unpopular opinion I guess) there is a fair amount of copium going on when people decry the abilities of LLMs.
Well said. But it's psychology. The cycle of admitting being wrong is highly personal. Many of us were rightfully skeptical, and to be fair, say 4-5 years ago when ChatGPT was the fanciest thing and mostly hallucinated total bullcrap to no end, and in context of programming, was only able to output variations of popular example programs, it was hard to see how this would ever become revolutionary for programming, like some were saying. But they were right; maybe some of them saw something critics didn't, maybe some were just optimists and were right by mere luck.
-
Even more bluntly: I don't think it's even "you are using it wrong", but rather, it's "you haven't really even tried, so you are just talking about something you don't have a freaking clue about". 99% of AI critics have not tried, or have tried so lightly it doesn't even count as trying (and hence, something that they would do wrong or right), or have tried many years ago.
There's another possibility - they have tried to solve problems for which there is inadequate training data.
Here's a little problem (not embedded, sorry) which I have not found any current reasoning LLM able to give a good (or even working) solution to. All I get is half-baked solutions which dont compile or dont run (typically with library version problems) or produce the wrong output (a black screen), even after several hours interaction with the LLM to try to get it to fix up its errors:
Write a java modern opengl program using the JOGL libraries to draw a rotating cube illuminated with phong lighting. This program is to run on a Mac with an Apple Silicon processor.
I've tried with a whole range of models and multiple coding agents. None of them gave a working solution ebven after lengthy interaction trying to explain what went wrong.. My conclusion at this point: these tools are great for straightforward tasks of the kind where there are plenty of materials / hints online (web page stuff, for example), but less so for specialised coding and uncommon tasks. I'm surmising here, but I suspect similar issues could arise for less widely used microprocessors/controllers, or obscure embedded problems.
-
Here's a little problem (not embedded, sorry) which I have not found any current reasoning LLM able to give a good (or even working) solution to. All I get is half-baked solutions which dont compile or dont run (typically with library version problems) or produce the wrong output (a black screen), even after several hours interaction with the LLM to try to get it to fix up its errors:
Write a java modern opengl program using the JOGL libraries to draw a rotating cube illuminated with phong lighting. This program is to run on a Mac with an Apple Silicon processor.
I've tried with a whole range of models and multiple coding agents. None of them gave a working solution ebven after lengthy interaction trying to explain what went wrong.. My conclusion at this point: these tools are great for straightforward tasks of the kind where there are plenty of materials / hints online (web page stuff, for example), but less so for specialised coding and uncommon tasks. I'm surmising here, but I suspect similar issues could arise for less widely used microprocessors/controllers, or obscure embedded problems.
[emphasis mine]
I don't have the time to try your problem myself and see, but in reply to the bolded statement:
Here's (https://atari-xt.com) the documentation for a new language (xtc) and an extended 6502 (it has stack-relative addressing, and a much larger stack to play with) running at 100MHz in fabric, both of which have been created with Claude. On top of that, it's instrumented FreeRTOS running on a Zynq A9, with an HDMI output pipeline which has a scaler and multi-purpose blitter, and a sprite-engine built in. Last night (yes, just last night) it integrated GEM (the Atari ST's graphical user interface system, writing the VDI (virtual device interface, all the lines/fills/beziers/arcs etc.) as well as the AES (Application Environment Services, all the dialogs, menus, event-processing etc.), embedded Lua to give /etc/rc.d style boot scripting, libz and freetype to provide outline font-processing, and bound the VDI and AES into the lua environment so you can script the UI.
Here's the desktop I have up right now, generated by the Zynq, with some lines/faked-out window at the top left drawn with the bound Lua tables, just some tests I've been running on calling the blitter to draw lines, and an active 6502 session in the centre of the screen:
[attach=1]
I just asked it to help integrate the font-blitting, using the font-cache {ptr-to-buffer, stride} as a data source, and (for a given string) sourcing the glyph source {x,y,w,h} and buffer-destination {x,y,stride}. This was its response:
⏺ Here's the detailed design. I've grounded it in the actual blitter structure (queue snapshot at
xt_blitter.sv:558, source-addr gen at :847, FLAGS at :372, the alpha-blend datapath, the 1024-deep FIFO).
DDR-source blit (font + general) — RTL design
1. Command & mode
New CMD = 0x08 (SRC_BLIT), reusing the existing block-blit read/write FSM
(BL_READ→BL_RWAIT→combine→S_AW/S_W) but with a configurable source. Keeps the existing BLOCK_BLIT (0x03,
plane-internal) untouched. Mode comes from FLAGS bits (offset 0x18, currently only [0]=BLEND,
[1]=BILINEAR):
- [2] SRC_DDR — source reads from SRC_BASE/SRC_STRIDE instead of the hardwired plane
- [3] SRC_COV — source is 8-bit coverage (text); else RGBA (4 B/px)
- [4] SRC_AOVER — for RGBA: alpha-over composite; else straight copy
2. Datapath — two formats, one blend
- Coverage (text): read 1 byte/px from the atlas → that byte is the alpha; the color is the pattern
register (set a 1×1 pattern = text color, exactly like a fill). Blend dst' = dst·(255−cov) + color·cov.
This reuses the existing alpha-blend-rect-fill datapath (BL_RACC…), just sourcing alpha per-pixel from
DDR instead of the pattern's alpha byte.
- RGBA (general): read 4 B/px; SRC_AOVER → dst' = src.rgb·src.a + dst·(255−src.a) (same blend unit); else
straight copy (today's block-blit combine).
3. Source address (no multiplier)
Today: bl_src_raw_addr = FB_BASE + (src_y+cy)<<13 + (src_x+cx)<<2 (:847). New:
src_row_base = SRC_BASE + (src_y)·SRC_STRIDE // accumulated, +SRC_STRIDE per row (no mult)
src_pix_addr = src_row_base + (src_x+cx)·bpp // bpp = SRC_COV ? 1 : 4
The ·SRC_STRIDE is done as a per-row accumulator (the blit already walks rows), so no DSP multiplier —
consistent with the existing "no multipliers" rule. Coverage reads unpack 8 px/beat (1 B/px) vs RGBA's 2
px/beat.
4. Per-command snapshot (queue-safe atlas)
The atlas {ptr,stride} + src-flags are snapshotted into the queue entry at CMD-write time (like dst/src
already are), so every queued glyph-blit carries its own atlas — no global-state hazard when the CPU sets
up the next run while the previous one is still draining. This widens the snapshot 192→256 bit
(SRC_BASE[32] + SRC_STRIDE[16] + src-flags; the FIFO BRAM grows one tier). You set
SRC_BASE/SRC_STRIDE/color once per run; each glyph's CMD captures them.
5. The fiddly bit — register allocation
The 32-byte register window is full, and three $D4Cx slots collide with the keyboard-injection regs in
fpga_xt_top ($D4CB/CD/CF). Two ways to fit SRC_BASE(4B) + SRC_STRIDE(2B):
Option: A — auto-load stream (recommended)
How: Reclaim the dead FONT_DATA slot (0x1E/$D4CE, the one non-colliding free offset) as SRC_DATA: write 6
bytes (BASE×4, STRIDE×2), auto-advancing like PAT_DATA; pointer resets on a FLAGS write. Retire the
FONT_* coverage BRAM.
Cost: Localized to the blitter; no top-level change
────────────────────────────────────────
Option: B — relocate kbd regs
How: Move kbd-inject $D4CB/CD/CF into the $D5xx I/O gap (like the bank regs already were), freeing 4
clean
offsets for plain SRC_* registers.
Cost: Cleaner map, but touches fpga_xt_top + the USB-HID→POKEY path
6. Software side (C/VDI)
- Atlas build: on first sight of a glyph, FreeType-rasterize its coverage into a DDR atlas buffer
(gfx_a9/font.c), record its {x,y,w,h} slot. Flush once.
- Draw run: set SRC_BASE/SRC_STRIDE = atlas, pattern = text color, then per glyph push SRC{x,y,w,h} +
DST{x,y} + CMD 0x08 — all into the 1024-deep queue in one vdi.text() call; blitter drains async.
- Large glyphs (>cache slot) and rotated/effected text fall back to the CPU path.
7. Validation → bitstream
- tb_xt_blitter: coverage-blit (atlas→plane, check blended pixels), RGBA alpha-over, straight RGBA copy,
and the per-row-accumulator address gen.
- tb_blitter_bridge: a SRC_BLIT through the GP0 path (atlas in the mock DDR).
- Then bitstream + on-HW: vdi.text a string, confirm it matches the CPU rendering.
Scope
This is the biggest piece so far — new command, reconfigurable source-read, coverage unpack, blend
wiring, snapshot widening, register loads, plus the C atlas manager — then a bitstream. Several hours of
RTL+sim before the ~40-min build.
Two calls for you before I start cutting RTL: register option A vs B, and confirm CMD 0x08 (new) vs
folding into BLOCK_BLIT 0x03. My leanings: A (localized, no top-level churn) and new 0x08 (isolates the
new path so block-blit/fills can't regress).
I'd be happy with that from a junior (or even mid-level) software engineer. I'm about to push back on it because I can't see any specification for offscreen bitmap blits. It looks like it's baking in the 0-level compositing screen (there are 4 levels) as the destination. This is the sort of thing I do often look out for - where it takes a task and does what you ask, but fails to generalise it to a larger scope.
I should point out that Claude has already engineered
- The 6502 CPU
- Extensions to the 6502 to make it play better with modern compilers
- Support chips (ANTIC, POKEY, PIA)
- 4-layer compositor, lowest is the GEM desktop, then m68k emulator, then 6502 emulator, then sprites/mouse etc.
- Line/Arc/Affine-transform/Bi-linear transform/Blit/Rect/Pattern-fill blitter
- Sprite engine
- xtc language, with IR representation, targets 8-bit 6502 and (currently) 64-bit ARM, others to come
- Automatic memory management (ARC) even on a 6502
This seems well beyond a simple 3D app, and significantly more complex a problem than a "simple web app". It also deals with problem-spaces that aren't that well populated on the internet.
-
Combination of two factors: the model itself has been trained with thousands of times more input data than any human being has seen. It averages out strong wrong biases some people have. (The flipside is that it might not been pushy enough when the user indeed is seriously wrong and a "strong" opinion happens to be correct.) - then the user prompt has quite significant weight, so it's easy to push the probability horizon where you want - i.e., correct the wrong idea.
Because the training input tends to be quite balanced, user prompt can easily push it to a certain direction; this is the "learning" and "adjusting" you mention. Both a blessing and a curse. If the user is wrong, user can easily manipulate the LLM to agree.
Reasoning depth of the LLM actually helps here. When you are disagreeing with the LLM, it IS a good idea to tell your reasoning of why, because that stays in context, and it then takes it into account every time it reasons further about the issue.
You just saying "no, not this, but that" gets some weight because the machine is trained to follow user's orders. But telling also why makes it reach the same conclusion, and just like with human beings, means it will reason around this limitation and find the correct solution, instead of keeping finding the solution it thinks is right, only to dismiss it because user said it's forbidden (without any explanation why), creating a loop.
Those who don't want to let the AI think and want it to be a stupid machine only, with very peculiar processes they want to micromanage, will be most disappointed. Those who create long lists of "donts" in CLAUDE.md and get a stroke every time it accidentally breaks one of the rules, will be disappointed. Give it some real work and real responsibility and you will actually see how much it can do.
From first hand experience I can say this is very true. Micro managing Claude is the wrong way of using it.
Recently I had Claude do a massive rewrite to convert about 15k SLOC of C into C++ and do some other improvements. At some point Claude had missed a subtile statemachine discrepancy causing the program to enter a deadlock. Claude started to go in circles trying to debug the problem. At some point I had to intervene and tell it to take a step back and look closely at the original code and check how the state changes work in the new code. Claude did a compact by itself, did an in depth analysis and did track the problem down. All this in a process where I'm working with Claude like Claude is a fellow software engineer. BTW I'm finding myself being polite when communicating with Claude ;D Interesting.
Then again, my workflow with fellow engineers has always been goal oriented and not so much about the path to get there. I don't always have to agree with how somebody implements something however, for as long as it does the job, I'm happy.
-
Write a java modern opengl program using the JOGL libraries to draw a rotating cube illuminated with phong lighting. This program is to run on a Mac with an Apple Silicon processor.
That's an interesting test - so you are giving it very strict constraints, and not helping it out achieving it. Interesting follow-up to this test would be:
1) give it more freedom: "Write a program that draws a rotating cube on Mac with an Apple Silicon processor, with the framework you feel confident with"
2) if you want those exact libraries, help it out; give your experience/insight on those libraries (which you probably do have, why would you otherwise ask for them specifically?)
Even with the vast knowledge, there will be gaps. I realized I have to put this to CLAUDE.md:
Extremely important detail is 15-minute netting in metering. When choosing between buy price vs. sell price, instantaneous power is irrevelant, only 15-minute energy (avg power) matters. E.g. if buy cost is 10c/kWh and sell cost is 0c/kWh, importing at 2kW for 7.5 minutes, then exporting at 2 kW for 7.5 minutes results in zero bill. These periods are fixed at xx:00, xx:15, xx:30, xx:45. IOW, in billing, at 15-minute level only buy or sell bin is non-zero.
Why this gap? Because the fact that Finland happens to net export/import in electricity metering in 15-minute periods is almost impossible to find out from public sources; basically you need to be an industry insider to know that.
And because many of the tasks Claude needs to reason about need this information, I put it in CLAUDE.md. No mistakes after that, at all; completely gone; it reasons perfectly about the cost modelling and complex chains where using energy somewhere at partially sell_price removes the need of using it somewhere else at buy_price.
-
It does not reason or do anything close to that. It may generate apparently working code very fast (and often with a very beautiful user interface), but if you trust it blindly, it WILL bite you sooner or later.
-
It does not reason or do anything close to that.
So you have not tried, and just have no clue what you are talking about. Strong reasoning skill is some of the most easily verifiable features. You are basically saying "cows do not produce milk", because you have not seen it. For many others, the thing is totally obvious.
(and often with a very beautiful user interface)
Beauty of user interfaces tends to be usually the most lacking one, needing the most guidance. If you just ask for an UI, it will be some very average, boring one; very acceptable for internal testing, but far from polished. It doesn't have the "eye" professional UI design artists have, and that's exactly as expected from the LLM working with language only.
but if you trust it blindly, it WILL bite you sooner or later.
No shit sherlock - that's obvious, but that's obvious also with any alternative way of development, and especially with human workers. And it has absolutely nothing to do with reasoning. Blind trust can only come from perfect communication of requirements, AND never doing any mistakes, both features which are impossible with all human workers and all AI systems in existence, and this is not changing anytime soon if ever. Blind trust is a unicorn you should not be chasing.
-
It also deals with problem-spaces that aren't that well populated on the internet.
You just aren't looking with the right eyes, tools, experience or information.
What you might want to consider. "Software patterns are fractal". They appear at almost all levels of abstraction and all mediums, all languages, all industries.
So, when you engage an AI outside of it's scope into a completely unrefrenced model of the code it will, with your help, match software patterns and then attempt to apply them.
It will see an enumeration pattern, a deligate pattern, a filter pattern, a non-destructive filter versus a destructive one etc. etc. The electronics parallel if I can reach for it, is a skilled electronics person with a life career in geological sensors, finding himself in a lab making consumer gadgets, does not need an RC filter or a crowbar explained to him.
-
It does not reason or do anything close to that.
I agree, I don't think you have used it really. You have not tried to reason with it. And I don't mean, tried to trick it. How would you approach an individual at work to determine if they can reason or not? Try that.
Also. I would restrict the reasoning domain to be reasonable. For example. The "Upside down cup problem" is real. It highlights they have no "mental model" of space, time, geometry. They literally cannot "picture the cup" and "turn it upside down in their minds". They don't have the hardware. You can attempt it and it will reason, but it effectively becomes a wierd academic debate, much like, "How do you know, when you say, blue, that we see even remotely the same thing?"
Images and it's ability to "grok" them is highly debatable. The tech basically tokenises the images into pels and feeds them to the "language model". It can match patterns, reason in a robot way about that (its on the left, its on the right, it's below, it's above) but they cannot "see it" and have no "aesthetic" sense.
If you want to "see" the internal reasoning. Use an unfiltered offline model. Or an online model that will expose the 'thinking' to you. Its fairly bizarre. It will start to generate a response, then stop itself and check alignment with the user prompt. Self critique the match and start again. It will do this a LOT. It can be quite choatic and frankly... on an unfiltered raw open source model, a bit disturbing.
-
What you might want to consider. "Software patterns are fractal". They appear at almost all levels of abstraction and all mediums, all languages, all industries.
So, when you engage an AI outside of it's scope into a completely unrefrenced model of the code it will, with your help, match software patterns and then attempt to apply them.
It will see an enumeration pattern, a deligate pattern, a filter pattern, a non-destructive filter versus a destructive one etc. etc. The electronics parallel if I can reach for it, is a skilled electronics person with a life career in geological sensors, finding himself in a lab making consumer gadgets, does not need an RC filter or a crowbar explained to him.
Exactly, and the same is true for everything else, not just programming: everything we do is covered by countless of analogies into something else we did earlier. LLM is good at finding those analogies, sometimes getting enthusiastic to tell you about them even if you don't ask. Ask and it will give as many as you want, and they are more or less spot-on.
LLMs match patterns and that's not some sort of "proof they don't work", quite the opposite, that's exactly the reason why they do work, because human brain is pattern matcher as well.
And this is exactly why large models are better than small models even if the efficacy looks bad ("I don't need 99.9999% of that raw information for this task"), they have more "life experience", so similar problems in training corpus, which they can apply as analogies - as their basis for reasoning. "Doing X worked on Y, which is similar - hmm, what happens if I try it here - wait, Z is different, let me check A, B and C. Wait, B prevents G from working, so can we do something about it..." - this is what LLM reasoning looks like, and it's very similar from human reasoning because it learnt the process of reasoning from humans.
-
The catch is... it doesn't feel anything when its wrong and it doesn't even sleep, so it won't sit up at night worrying about the code either.
-
It also deals with problem-spaces that aren't that well populated on the internet.
You just aren't looking with the right eyes, tools, experience or information.
I think we're making the same point. I'm saying that "even though the LLM is unlikely to have found anything like what I'm asking it to do, it still performs well because it can generalise from the model of what it has found".
The comment was to refute that made by ralphrmartin who was claiming "these tools are great for straightforward tasks of the kind where there are plenty of materials / hints online (web page stuff, for example), but less so for specialised coding and uncommon tasks"
I'm aware of how neural networks work, I have a doctorate in the topic, and even though it was a long time ago (in a galaxy far away) and things have indeed changed significantly, the fundamentals are still the same.
-
The comment was to refute that made by ralphrmartin who was claiming "these tools are great for straightforward tasks of the kind where there are plenty of materials / hints online (web page stuff, for example), but less so for specialised coding and uncommon tasks"
That was a valid observation 4-5 years ago, when ChatGPT was new and shiny and amazing at producing plausible looking, grammatically correct text littered with errors and hallucinations. It was able to produce code which also compiled and ran often on a first try, or at least after a few iterations "hey this doesn't work" "Good catch -- try this" - still possibly thousands of lines worth, something it would take a day for human to produce, within just minutes. So it was amazing, but when people actually tried to apply it for serious software development, they quickly saw just what ralphmartin was saying: it's just varying highly common patterns in direction of user requests: useful for those (often beginners) who need something outside their core expertise quickly, but where almost-there solutions commonly exist; basically automated version of "copy-paste random stuff from Stack Overflow".
But some saw the potential - let's pour more money, more resources, more research into this problem, and it will magically become a real, generic thinking machine. And despite all naysaying, that's exactly what happened. Easier to see in retrospect, and kind of funny that some still deny the facts easily observable to everyone; hence my "cows don't produce milk, prove they do!" analogy.
Two significant changes are visible and understandable even to us non-AI-experts: model size, and introduction of thinking (reasoning) phase, a separate step where the model outputs reasoning in natural language, which shifts the probability landscape (which is the context, including the user prompt, but also the reasoning text the model is outputting), for the model to create the final answer. But even this isn't anything new, really; Deepseek did a great job years ago exposing that thinking phase to users through a button from which they can enable it. That shifted the discussion from "It's not reasoning!" to "OK, it IS reasoning, but doing mistakes nevertheless" - so it's kind of funny to see someone in 2026 claim that LLMs do not reason at all, when that's exactly what they do, and it's so easily observable to anyone willing to try.
-
I've just spent 2 days on a "computer graphics" job with Claude and clearly it does not write code the way a human coder would (should). It tries just about everything until the result works (or doesn't). Eventually one gets there although I've been on the last one for a whole day, sending it pics of the LCD...
That said, the end result would have taken a human a lot longer to do.
UPDATE: I got my 2nd (free) Claude on the job and it solved it in just a few iterations! I then gave the code to Claude #1, who commented "that's a completely different approach..." :) I have repeatedly found this 2nd Claude to be more clever. It also shows the code on a panel on the right, which I can't do on #1. And it does not highlight function names with a black background like #1 does... Claude #1 has no idea how to configure this.
Claude #2 looks like this (never mind the Chinese buttons)
(https://peter-ftp.co.uk/screenshots/202606090520561011.jpg)
EDIT: turns out that to get the above, you need to enable Artifacts, and tell Claude to send code to the Artifacts panel instead of inline. Both are painfully slow but inline is even slower. Also there is a UI bug that you have to scroll to the bottom of the code (in either mode) before pressing Copy, otherwise you get only a partial copy.
But some saw the potential - let's pour more money, more resources, more research into this problem, and it will magically become a real, generic thinking machine. And despite all naysaying, that's exactly what happened. Easier to see in retrospect, and kind of funny that some still deny the facts easily observable to everyone; hence my "cows don't produce milk, prove they do!" analogy.
True but it still does weird stuff e.g. I am drawing some text in narrow20, and I asked it to change to narrow15. It did that but completely pointlessly did a random change elsewhere, which broke some stuff. One realises it is not deterministic (whatever that means).
-
True but it still does weird stuff e.g. I am drawing some text in narrow20, and I asked it to change to narrow15. It did that but completely pointlessly did a random change elsewhere, which broke some stuff. One realises it is not deterministic (whatever that means).
Your problem is in the harness. You are using the Claude's generic web UI, which is not really designed for programming, to do programming. This is what people experimented with 5 years ago. In that setting, programming is "read prompt, write code, rinse and repeat", and rewriting the code is not only wasteful, it introduces random changes.
Programming agents, like Claude code, operate differently; they read code, decide what needs to be changed, do spot reads around the area, and edit (not rewrite) code here and there. As a result, no pointless random changes elsewhere.
-
Write a java modern opengl program using the JOGL libraries to draw a rotating cube illuminated with phong lighting. This program is to run on a Mac with an Apple Silicon processor.
That's an interesting test - so you are giving it very strict constraints, and not helping it out achieving it. Interesting follow-up to this test would be:
1) give it more freedom: "Write a program that draws a rotating cube on Mac with an Apple Silicon processor, with the framework you feel confident with"
2) if you want those exact libraries, help it out; give your experience/insight on those libraries (which you probably do have, why would you otherwise ask for them specifically?)
I wanted it to generate a working skeleton program, which I could then modify myself to turn into a real application.
I particularly wanted to use java / those libraries, as I am familar with java.
I couldn't help it out. I was asking it as I couldn't get this working myself.
-
I admit to being mildly curious as to why Claude would have such difficulty with what (at first glance) doesn't appear to be an onerous task for it. I know very little about Java but I figured it'd be a learning experience as to why it didn't work so I spent the time to see what it would do.
I used the exact same prompt "Write a java modern opengl program using the JOGL libraries to draw a rotating cube illuminated with phong lighting. This program is to run on a Mac with an Apple Silicon processor"
Initially we ran into an issue because jogamp.org doesn't seem to be serving JAR files, but Claude tried first with HTTP GET, then with Curl, then decided it ought to go to "Maven Central" (whatever that is) where there are mirror files. It then fetched the JAR files.
Then it wrote src/PhongCube.java
Then it wrote run.sh to invoke things correctly - with a minor hiccup because it didn't provide the best arguments the first time, it corrected itself and the app ran.
Attached is a (very) short video of the cube running, it's a MOV in a ZIP because apparently you can't attach MOV files. Here is (https://0x0000ff.co.uk/jogl/jogl.tar.bz2) the entire directory (including the JAR files, src, and a transcript of the entire session)
Took 5-8 minutes. Worked first session. So, it seems to work for me :-+
-
Does anyone know where this silly colour scheme is configured?
(https://peter-ftp.co.uk/screenshots/202606100820574007.jpg)
This is on the paid Claude; the free one looks like this
(https://peter-ftp.co.uk/screenshots/202606101920584107.jpg)
Claude doesn't know :)
-
I've tried with a whole range of models and multiple coding agents. None of them gave a working solution ebven after lengthy interaction trying to explain what went wrong.. My conclusion at this point: these tools are great for straightforward tasks of the kind where there are plenty of materials / hints online (web page stuff, for example), but less so for specialised coding and uncommon tasks. I'm surmising here, but I suspect similar issues could arise for less widely used microprocessors/controllers, or obscure embedded problems.
The tools are great for straightforward tasks in unskilled hands. In skilled hands they go a lot further.
Your use case sounds simple. As a professional Java progammer of 10+ years, I can tell you it's not. Nor is it simple if you had the entire corpus of what Claude has 2026.
It's not even likely to be a code problem you will face. It will be an environmental one. A JVM one. A JVM setup one. An OS driver setup one etc.
As a similar example (?) I asked it to setup a Raspberry PI 2350 dev board for "Bare RISC-V ASM Blinkie".
After 6 builds and "dead MCU" I gave up.
I was not driving, I was not in the loop, I was not even paying attention I was just hitting "Yes", "Yes and don't ask".
So you could say that claude did nothing useful, right? Well, the thing is, it is likely to be one or a small number of "dumbness" slipped in somewhere, a missed step, a missing parameter on the memory segments, alignments, maybe even an assumption about the particular dev board or RISC-V core boot process.
I have no idea. Because I was not in the loop and have no idea what it did. All I read was the ASM code at the bottom and it looked "ok".
This is me as an amatuer asking for "the moon on a stick" and unable to help claude out.
Does this make claude useless? No. I expect if I took your task and you took mine, we would probably be able to get the projects working if we guide claude. The important part would be, how quickly with and how quickly without claude?
-
Took 5-8 minutes. Worked first session. So, it seems to work for me :-+
Hush! You are not supposed to replicate the "AI does not work" experiments! Let's keep believing it doesn't work! >:D
-
I admit to being mildly curious as to why Claude would have such difficulty with what (at first glance) doesn't appear to be an onerous task for it. I know very little about Java but I figured it'd be a learning experience as to why it didn't work so I spent the time to see what it would do.
I used the exact same prompt "Write a java modern opengl program using the JOGL libraries to draw a rotating cube illuminated with phong lighting. This program is to run on a Mac with an Apple Silicon processor"
I am assuming you ran the generated code on a Mac?
I have to admit it was a couple of months back I tried this.
A major problem I hit at first was it could not find the right version of of the jogamp files including the native libraries.
Then it could not get jogl to work with swing java windows without errors, and sent me down a rabbit hole of trying to fix that.
Your video shows a couple of defects which presumably are readily fixable: the light source is rotating as well as the object, and the cube does not appear to be shiny (specular refletion, which is the point of the phong model).
But I have to admit that it is basically working.
-
Hush! You are not supposed to replicate the "AI does not work" experiments! Let's keep believing it doesn't work! >:D
I'm not saying I don't believe it works. I have successfully used it to improive some code for driving a thermal printer directly, and for fixing errors in embedded code for a climate logger. I was trying to say that results may not always be as hoped for in cases where there is limited training data relevant to the problem.
Amyway, engineers should base their work on evidence, not belief!
-
Is it possible to configure Claude addon in VScode for inline code completion?
It's a lot nicer if it tries to figure out what I'm going to type next, than me having to specify it in chat.
Just like Github copilot, but I don't want to pay for both.
-
I am assuming you ran the generated code on a Mac?
Yep, it's on an M4 Max MBP, running Sequoia (15.6.1)
I have to admit it was a couple of months back I tried this.
A major problem I hit at first was it could not find the right version of of the jogamp files including the native libraries.
Then it could not get jogl to work with swing java windows without errors, and sent me down a rabbit hole of trying to fix that.
Yep, I had the same issues with libraries, it couldn't pull from the original source, but it knew some mirror location ("maven") and pulled them from there. To be honest, I'm kind of surprised it found java on the MBP, I can't imagine what I would have had that installed for, but anyway it just pulled everything down, wrote the files, and a script to run it. That entire archive is available at the link in my original post about this, it ought to work on any Mac that has java/javac installed.
Your video shows a couple of defects which presumably are readily fixable: the light source is rotating as well as the object, and the cube does not appear to be shiny (specular refletion, which is the point of the phong model).
But I have to admit that it is basically working.
I'm not a 3D expert :) I thought the phong one was the matte one, but I consulted Claude about it and it found the bug and explained it in terms even I could understand:
❯ so the source in this directory was in response to "Write a java modern
opengl program using the JOGL libraries to draw a rotating cube illuminated
with phong lighting. This program is to run on a Mac with an Apple Silicon
processor" but it seems to be rotating the light as well as the cube, and I
don't see the shiny reflections I'd expect for phong shading
⏺ Let me look at the source code to diagnose both issues.
Searched for 1 pattern, read 1 file (ctrl+o to expand)
⏺ I found it. Let me walk through the bug, because it's a single root cause that
produces both symptoms you're seeing.
The bug: a transposed normal matrix
Your lighting is done correctly in world space — uLightPos is a constant (1.6,
2.0, 3.0) and never rotates. So in principle the light should stay put while
the cube spins. The problem is the normal matrix (Mat4.normalMatrix, lines
382–411). It's transposed relative to what it should be, so the normals get
rotated by the inverse of the cube's rotation.
Here's the chain (model is a pure rotation O):
- The desired normal matrix is transpose(inverse(O)), which for a rotation
equals O itself — normals rotate with the cube.
- But the code reads the upper-left 3×3 from the column-major array into a,b,c
/ d,e,f / g,h,i as if it were row-major, so the matrix it actually inverts is
Oᵀ, and then it writes the result back out row-major again. The two
transpositions don't cancel — they compound into one net transpose. The matrix
that reaches the shader is O⁻¹ (= Oᵀ for a rotation), i.e. the inverse
rotation.
So your cube's positions rotate one way while its normals rotate the opposite
way. That's exactly why:
1. The light "rotates with the cube." The shading no longer tracks the surface
— the bright region counter-rotates against the geometry, which reads
visually as the light being attached to / spinning with the cube instead of
staying fixed in the room.
2. No specular highlights. reflectDir = reflect(-lightDir, norm) is computed
from wrong normals, so the highlight never lands where the view vector can
catch it — the glossy spot effectively disappears.
The fix
Transpose the returned mat3 — emit the inverse in column-major order instead
of row-major:
It then fixed the code, I ran it and it produced a rotating cube with a light that seems to be fixed to me. The cube gets a light-pattern looking like (one snapshot):
[attachimg=1]
It also said:
One optional tweak if you want the highlights more obvious: your light (1.6, 2.0, 3.0) sits almost on top of the camera (2.6, 2.0, 3.4), which flattens the shading. Pulling the light off to one side (e.g. (-1.5, 3.0, 2.0)) gives stronger, more directional highlights and shadow gradients. You could also increase the shininess and specularStrength
So I asked it to do that and give me a really glossy look (since that seems to be what you were after), and it told me that to get truly glossy output, I'd need to switch away from a cube (with its constant normals) and model a sphere instead - or at least some curved surface with varying normals. I said "go ahead" and we got:
[attachimg=2]
Now of course, a featureless sphere with a stationary light doesn't look like it rotates, so I asked it to "add some surface detail so we can see the rotation", which led to the movie in the attached ZIP file (again, can't upload actual MOV files).
-
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).
-
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.
-
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.
-
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.
-
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.
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.
-
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.
?
-
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.
-
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
(https://peter-ftp.co.uk/screenshots/202606115620594908.jpg)
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.
-
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.
-
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.
-
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...
-
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.
-
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.
-
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.
-
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.
-
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.
-
How do you get Claude to see the result?
-
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...
-
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.
-
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.
-
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.
-
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?
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.
-
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.
-
Enjoy AI while it lasts
www.youtube.com/watch?v=UfApUobqN8Y (https://www.youtube.com/watch?v=UfApUobqN8Y)
-
Enjoy AI while it lasts
www.youtube.com/watch?v=UfApUobqN8Y (https://www.youtube.com/watch?v=UfApUobqN8Y)
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).
-
Enjoy AI while it lasts
www.youtube.com/watch?v=UfApUobqN8Y (https://www.youtube.com/watch?v=UfApUobqN8Y)
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)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
skill.md and mcp servers are the key. Skill file tells it to retrieve info only from for example a certain datasheet.
-
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.
-
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.
-
Some people like to turn forums into a personal pissing contest. I have a shop near here, just right for them
(https://peter-ftp.co.uk/screenshots/202606150420655119.jpg)
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.
-
Some people like to turn forums into a personal pissing contest. I have a shop near here, just right for them
(https://peter-ftp.co.uk/screenshots/202606150420655119.jpg)
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.
-
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.
-
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 :scared: , 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.
-
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 :scared: , 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.
-
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.
-
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 :scared: , 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.
-
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.
-
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.
-
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.
-
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.
-
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...
-
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.
-
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.
-
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?
-
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.
No you should see Claude for what it is, an AI first generation tool. Nowhere perfect, just starting.
You make it sound like it is a human being :palm:
-
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.
No you should see Claude for what it is, an AI first generation tool. Nowhere perfect, just starting.
Well, the work Claude code is producing for me is on par with that of a talented junior engineer coupled with a large amount of knowledge about standards, design patterns and obtain a sense of what you are trying to achieve quickly. If you have a different opinion, it is probably outdated and I strongly suggest to install Claude code, switch to the opus 4.8 model and throw some real work at it. I'm quite sure you'll be pleasantly surprised. I have been using Claude for a while now for different projects (Python, C, C++, FPGA, making sense of numbers, setting up & analysing automated regression testing, etc) and the results have been outright amazing (and I don't use this word lightly!). I'm not saying you can let Claude do everything by itself; it needs clear instructions but the productivity boost is huge IF you give Claude the right instructions and context.
-
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...
How is that different from you zipping your project and fetching it back modified, or copy-pasting back and forth? If you carefully read everything you copypaste, you can even more easily carefully diff what modifications it made.
Amount of trust - or amount of human verification and human double checking - is an interesting topic to discuss, but it has absolutely nothing to do with your neutered copy-paste process or lack thereof.
-
You make it sound like it is a human being :palm:
That's really the best way to think about it. The physical structure is not identical, but very similar to human brain; it walks like, it quacks like..... but it isn't.
But attempts to try to treat AI like some special AI thing tend to fail. "Prompt engineering", "context engineering", complicated custom harnesses.
Instead, what works when leading human workers seems to work with leading AI workers:
* Understand the thing you are leading yourself - understand your own requirements
* Explain them not only what you want, but WHY
* Design together by DISCUSSING what needs to be done, why and HOW.
* Prefer positive examples over negative "don'ts"
* Don't waste time at cursing them - keep to the matter
* Don't try to hide information and play games with them; give them ways to work
* Having healthy amount of suspicion - ask why they think what they do; check their work
Everything that fails with human beings fails with AI, too:
* Have no freaking idea what you are building
* As such, give very confusing instructions
* Be very authoritative - design decisions are locked, not up to discussion.
* Don't give them access to your code, only small pieces at the time, without any actual reason (security classification could be such)
* Curse at them
* Having unhealthy amount of suspicion - either none (no checking), or too much (micromanaging)
So treating them like humans is not a bad first instinct. Of course you can optimize the process if you know how the operate: you can just ghost them when done/not needed and they don't feel bad about it. You can get a fresh worker as often as you wish and "fire" it by ghosting it - it doesn't care. And having some understanding on how they operate internally is beneficial. But it's not a top priority thing.
-
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.
We used to be pretty happy with Bugzilla, which is free and open source and easily hacked-on. It's pretty easy to use it for features and backlog, not only bugs. I see there was a new release in September 2024.
-
We used to be pretty happy with Bugzilla, which is free and open source and easily hacked-on. It's pretty easy to use it for features and backlog, not only bugs. I see there was a new release in September 2024.
Why not wax tablet?
-
We used to be pretty happy with Bugzilla, which is free and open source and easily hacked-on. It's pretty easy to use it for features and backlog, not only bugs. I see there was a new release in September 2024.
Why not wax tablet?
Why not. Our journey of improvements:
Jira - buggy and annoying to use
linear.app - smooth and non-buggy, very much nicer to use
pen and paper - the ultimate solution, has its own dedicated "monitor" space, never needs login, very intuitive UI: write down the thing you need to remember, strikethrough / cross over it when not relevant anymore.
The key is to avoid postponing work: don't push work into the "write tickets - don't do them - prioritize them in backlog orgies - never do them - only the absolute necessities get done, at last possible time, outside of the ticket system" game. If you want something done, do it right now.
Pen and paper works for short-term context switch memory very well, i.e., dump your mental stack frame when forced to switch tasks. Tickets are too clumsy for that, especially in Jira.
Customer support / bug reports is different, for that you definitely want a ticket system, with the automation of creating the tickets from customer email.
-
The key is to avoid postponing work: don't push work into the "write tickets - don't do them - prioritize them in backlog orgies - never do them - only the absolute necessities get done, at last possible time, outside of the ticket system" game. If you want something done, do it right now.
Example from 10 minutes ago.
Useful idea -> prompt:
❯ FCR calibration view on FCR admin unit management (and only there, keep the Enion-side view intact): highlight offending values in red, bold warning color if:
* Cha gain outside 0.88 .. 1.08 (check only if DATE CALIBRATED is not invalid)
* Dsch gain outside 0.92 .. 1.12 (ditto)
* abs(ac offs), abs(cha offs), abs(dsch offs) larger than max(400, inverter_rated_power*0.03)
* abs(pos_gain) or abs(neg_gain) outside 500..17000
* pos_gain more than 20% different compared to the average of pos_gains at other valid different SoC% - and similarly for neg_gain.
Additionally: after charge power/discharge powers at every SoC% point, show C-rate with 2 decimals like this: 6480 W (0.61C). Calculate C rate from power / avg(CharCap, DschCap).
Red warning highlighting for the C rate:
* If discharge power < 0.40C at SoC 30% or above, colorize.
* If charge power < 0.45C between SoC 30% - 78%, colorize.
Additionally: Right below the FCR Calibration - hw_id title, show the inverter type and battery type (same as in the unit management page), and the configured battery capacity (Wh) - the stuff in the
database. If DschCap (the measured calibration battery capacity) is more than 20% below the configured battery capacity, highlight both the configured value and the measured one in red.
Feature branch and PR.
That's all. Some minutes later hit merge, and direct into production. And then it's there, doing useful work right away (attachment).
That prompt could go into a ticket, yes, sure. Except I would need to spend more time with it to make sure it's perfect, because the human being who reads the ticket one week later, while I might be somewhere else, would write a comment to the ticket, which I would see 1 week later.
Now an average human programmer would get that perfect ticket maybe 60-70% right. Claude usually gets it 100% right, maybe average is 99% because it sometimes make a mistake.
So, Jira:
Spend 30 minutes on ticket -> discuss with average delay of days to weeks -> get in in backlog -> arrange backlog grooming orgies where you decide not to implement anything because something else is on fire -> never get anything useful to production -> things are in fire because nothing gets done
Direct implementation:
Spend 10 minutes on prompt -> discuss with avarage delay of 2 minutes -> get it in production -> done
-
Customer support / bug reports is different, for that you definitely want a ticket system, with the automation of creating the tickets from customer email.
So you don't have a customer or customer feedback?
Do you have stakeholders? Being colleagues or feature requests or even things that pop up in your mind that are very nice to be implemented some day when time/budget permits? Those are the things you create backlog tickets for with proper prioritization so when you run idle you pick the highest prio remaining ticket.
But for a one man shop it is not suited probably although the paper you wrote your nice to haves on is also probably unfindable.
-
So, Jira:
Spend 30 minutes on ticket -> discuss with average delay of days to weeks -> get in in backlog -> arrange backlog grooming orgies where you decide not to implement anything because something else is on fire -> never get anything useful to production -> things are in fire because nothing gets done
Direct implementation:
Spend 10 minutes on prompt -> discuss with avarage delay of 2 minutes -> get it in production -> done
Jira tickets takes two to three minutes to create, 10 seconds with Outlook email to Jira scripting. One minute to fill additional fields, none in your 1 person company.
The rest of the process is up to you and your company. We discuss the high prio backlog , in progress and waiting (if due time expired) each morning in the DSU.
Customer/stakeholder satisfaction is very high, as required.
In a real company when you have an idea or request and start implementing directly as your example it would be complete chaos. I have experienced this multiple times in the past where SWE picked up the nice creative tasks started working on them while they were low prio nice to have, in the mean time causing frustration with customers, customer support and managers because some hard to find but annoying bugs were not solved.
-
I'm partly jealous. It's just that scale thing again. The fractal nature allows patterns to be matched at all levels. So it sounds like we are talking about the same thing.
I think your approach is actually very close to the OG Agile methodology and you would note it's complete lack of what happens "above the sprint" level. It has never had opinions on what happens on the longer term or the bigger picture. That's because it was designed mostly for projects where that fits. You have a known place, you have incremental changes to make, you accept what you can reasonably get down and plan for just that work.
However, your strategies break down in many situations. Whether you encounter them or not is a different question.
The customer. They will give you a 30 minute highlevel "This is what I vision". You may get some time to process (the larger the company and the larger the deal the longer and more documentation) or they might just ask you, "How much, when can I have it?"
This is where the "only focus on what's next when you get to it" breaks down. They are not asking how much can you get done in the first 2 or 3 weeks. They don't care. They want to know "How much will it cost?" and "When can I have it?"
Even if you dig in and hold onto the "iterate fast" approach you will still need to answer, "How many sprints?" "How many developers? How many testers?". If you answer to the last two is "One because we only have one", it still leaves the first one. In order to answer it, you will need to have an understanding of what needs done. Maybe in an embedded project with a few inputs, a few processes and a few outputs you could 'finger in the air' it and get close. Add a sprint for contingency.
When someone is asking for... a card payment routing and validation gateway, as a random example, interfacing with a dozen different upstream bank APIs and several dozen downstream 'card machine', ecommerce sites and apps. "Books"of regulation down to logging requirements and individual container/VM firewalls... As a minima, the whole thing will need split up into "UI and backend". The backend will need to be split on "concurrency" and "async" boundaries so it can scale to millions of transactions a minute. Going through them one at a time is not wise, so you will probably have multiple teams building different parts concurrently.
Good luck answering "How much", "How long" without analysis. Analysis you can't do in your head, even if you were doing it alone.
How often does this scale occur in the embedded work? Again it's sort of fractal. A "dummy" device can be stubbed in for testing so that one team works on one part, whie the other works on another part. This happens in electronics. I'm sure it happens in embedded world. When it's not "cost practical" to force everythng into one MCU/board/component but to span it across several and fork development into different teams. This is were a proper project planning and task management system might help.
When management start asking, "How much work is on your books for the next 6 months? Have you got room for a 500k project?"... that gets awkward if you say, "No idea"
-
So you don't have a customer or customer feedback?
Of course - what we are doing is annoyingly complex so ~3000 customers actually create significant amount of contacts, for which we now have a completely dedicated hired human being - but that's a separate flow. I'm sure no sensible company of any size let customer support tickets flow into their software development flow directly. Like, Outlook->Jira? Sure, if that's a dedicated customer support board, why not. We are actually looking for a good ticket system for customer support cases, and Jira it won't be, that's I'm sure about.
Being colleagues or feature requests or even things that pop up in your mind that are very nice to be implemented some day when time/budget permits?
Yes - and we have over 300 such nice ideas in our Jira backlog.
Ideas are easy to throw around. What to actually implement and when is more difficult. Implementing relatively small but valuable things right away, to give customer value / increase product quality NOW rather than later, greatly reduces the NUMBER of that backlog stuff, and the cost of prioritization / eventual implementation. This is all I am saying.
Truly large ideas that cannot be implemented right now - also need truly bigger specification. They are not that numerous. I don't see any value with a Jira ticket for a bigger idea, anymore. In reality, such ideas are thrown around in Power Points, Excels, Slack, Figma or maybe CAD tools, emails, phone calls and meetings. Sure you can collect those resources and put it in a Jira ticket. Now what do you do next? Ticketize it into 100 sub-tasks and create a timeline for their implementation, and get software engineers work on it for the next 6 months? This is exactly what we tried and tried and tried and which never worked for us. And the big pictures on fire always swamped doing smaller yet semi-important stuff: important but no absolutely critical bugfixes, features that reduce our workload (automation features). This led to feedback loop: our customer support overwhelmed by explaining to customers that no, we have not yet fixed that bug, no we don't yet have this feature everyone is asking for, it's prioritized for later. Wasting 100x more time on unfinished things, rather than just do the things right away.
I mean: this is what a ticket system fundamentally is, by definition: it's a system designed to postpone work. And postponing has a cost. Use with care!
Doing it NOW is CI/CD and I'd say that's a really good pattern (in moderation; of course quality control / testing is important), and agile process where you set up artificial timelines and ticketization processes instead of direct execution is, in that sense, anti-CI/CD.
But maybe Jira and ticket process works better for others. For us it didn't. Maybe we get some sort of ticket systems work again for us, in a positive way; now we are probably overshooting into the opposite direction, being freed from the horror of getting nothing done. We will settle into something sensible.
-
The customer. They will give you a 30 minute highlevel "This is what I vision".
Note a huge underlying difference that changes the whole discussion:
You are talking from the perspective of a software house; that kind which gets a contract on developing software for others. For you, "customers" are those who order you to build software, for their customers.
I, and I believe, many others on this forum - including peter-h and nctnico - are building software within their own companies; to me and them, "customer" means a totally different thing; it's what you would call maybe end-user.
As a result, nctnico, peter-h or me have quite clear own vision of what we are doing; we are leading our companies (or leading a project/team/subproject within a larger company) and have more freedom of how we achieve the goal. Most importantly, we don't have to care if we follow some software industry practices, because we are not software industry as such. We are offering products/services where software plays a part. We can pick and choose what we want to give a try at; look how peter-h dismisses even stuff like git, and still gets work done, and runs a successful business. Or, how we improve our service level significantly by getting rid of Jira, and using the saved time more productively.
Grumpy "software professionals" can sniff at us, they can ridicule us; we don't care.
Yet, every business was small at start. Every business was lean at start. Complicated processes come later; some are inevitable and beneficial, some are harmful bloat.
-
Complicated processes come later; some are inevitable and beneficial, some are harmful bloat.
I suppose what I am trying to communicate, from a perspective of having sat in many different sizes of company (and customer) is that ... it scales fast, non-linearly fast.
When you "just add one more thing" to software it does not "add" it multiplies. It multiplies complexity, communication of complexity, complexity of testing etc.
I tried to get AI to give me a "name" for this, it leaned heavily towards Fred Brooks. (excerpt below).
MCU and MCU containing systems are (or are they not) getting increasingly complex as "Edge computing" is being pushed, as "Cloud intergration" and "IoT" is being pushed. I am warning that it might seem "incremental" and "easy to manage" but it won't be. Adapting the appropriate level of best-practices in advance is usually what stops the bloated overkill later in response to allowing it to become unbearable first.
AI:
Brooks's Law is the most famous formulation: "Adding manpower to a late software project makes it later" — from Fred Brooks's 1975 book The Mythical Man-Month. It captures the superlinear cost of adding people due to communication overhead and onboarding drag.
The underlying scaling dynamic has a few names depending on which angle you're looking at:
Metcalfe's Law (borrowed from networking) describes how communication links scale as n(n−1)/2 — so 5 people have 10 communication channels, but 10 people have 45. This is often cited to explain why team complexity grows non-linearly.
Diseconomies of scale is the economics term for when doubling inputs produces less than double output — software is a textbook case.
Complexity theory in software engineering sometimes uses the term superlinear scaling or combinatorial explosion for how interactions between components, people, and decisions multiply.
There's also Amdahl's Law, which quantifies the ceiling on parallelization gains — relevant when teams try to speed up a project by splitting work.
In organizational theory, this is sometimes called the coordination overhead problem or the n² problem.
The overarching idea — that software resists being managed like a linear industrial process — is what Brooks called the "No Silver Bullet" thesis (his 1986 essay): essential complexity in software cannot be engineered away, only managed.
-
When you "just add one more thing" to software it does not "add" it multiplies. It multiplies complexity, communication of complexity, complexity of testing etc.
That's a good thing to recognize. We don't need to accept that as some sort of universal law of physics. Some changes add. Some changes multiply. Some changes devastatingly explode the complexity to third or fourth exponent.
AI might be too eager in doing things too well. For the above example where I wanted suspicious numbers to be in alarm color, it wrote a bunch of tests. Great, feature protected against regressing with tests, :-+. Then again - what are the actual chances those would accidentally regress? Thresholds are in the code. What could happen is that some poor human being wants to modify those thresholds. Will the test fail now? Test needs to be changed? Or do we need to design configurable thresholds, with threshold configuration UI and database storage?
What a can of worms, for a simple thing. Maybe hard-coded thresholds, without any tests would have been best. So Claude already overachieved from my perspective. From some software professional's perspective, it probably underachieved.
Now, let's say it's a change which just colors alarming values. What are the chances something that simple breaks? Non-zero, but nearly zero, in reality. What is the value of such simple feature? Maybe that means that the poor human being doing the check does 1-2 mistakes less every month. Mistake that means we are paying some penalties to the TSO, and causes those customers to complain, with something very hard to mentally connect to the wrong value in the calibration table, like "my system is selling energy into grid every night at 20-22". So seems like having colorized alarms for values that are off is strong on net-positive side. Better do immediately. I know from experience that average pass time for a ticket like this for our past humans+Jira team (we did have 4 or 5 (I don't even remember which) hired professional programmers at one point) would have been 6 months. With Claude, it was 10 minutes.
I have seen some software professionals fear features. That's understandable because they know how complexity can hit them in the long run. Then again, the value those features add to the table cannot be ignored. Software is all about its features, if it lacks the good features, it's a design mock-up, not an actual project.
Real skill is in being able to implement all important, fancy, even nice-to-have features, while keeping complexity in check. To avoid that high exponent. And this, I believe, is rarely achieved by overengineered architecture. Total ad-hoc mess of course doesn't work either.
And this is a skill AI still isn't fully capable of doing on its own. One of the AI risks. Let it do too large pieces without any supervision, and without any own vision of what the architecture looks like, and you will have an unmaintainable, complex mess.
-
Your example of the thresholds is a good one for how it starts. You write exhaustive tests. If you change the values, all the test breaks. You introduce a config mechanism to change the values at runtime or even build time. However, that itself needs tests. It adds complexity. It can be a point of failure itself.
Also, "unit" tests should be unaffected by it. A unit test should not be coupled to the configuration mechanism, or it can't be tested in isolation. So the "unit" of code has to "be given" it's lookup table and then queried about it. Meaning the unit test has to create fabricated config structures and test against those. However, you also need an integration test which proves the "unit" function at it's intergration points, aka the config system.
Its a can of worms, however, as above, a "pivot" of responsibility doesn't explode out of proportion unless you let it. Just having the thing which picks the colours get supplied by it's reference data, then you can test it in isolation and make up and reference data you want. As long as the reference is representative of the real data of course.
"Regression" was your own word. Tests are often confused with "Prove it works". That is a tiny fraction of what tests are for. The biggest being, "After we make a change does everything else still work?"
In a strawman case, someone, maybe even you late one night, used the "color" value to determine the severity in some far flung bit of reporting or logging code. "Red value scale" say. Later you change the colour scheme via a theme the user asked for, maybe even for accessibility. The tests in the Red value scale should fail. In integration tests at least. An assumption you made, "Colors are unimportant 'pure' values" was incorrect. If the tests were written well they should fail.
My personal preference is to add what is needed, which requires that you understand trade offs. Throwing solutions at undefined problems, "Just in case" is a common practice in the industry which almost has engineering justification - at times - but is gauranteed to generate revenue for software consultancies. So it is ripe.
AI moves the trade offs in subtle and non-subtle ways. Usually volume and completeness of tests, documentation, commenting etc. "Quality costs less effort".
However... quality is not a static target either. There is always a forward direction to increase it, while not decreasing revenue.
-
Speaking of tests.
How many of you MCU guys actually write "Unit tests"?
I know in "hobbyland" I have rarely bothered, simply because I see the "untestable" nature of the code and my "default", "lazy" answer is... "Nah, not solvable".
However. I also recall making this determination about a bit of software with international significance. Once upon a time. However a very skilled lead engineer proved otherwise. It took a huge amount of effort, and I do not pretend to understand all the lengths they went to, but he was rambling on about pointer opaquity, compiler firewalling, etc. etc. Splitting intergation points on tightly defined interfaces so they can be tested in isolation via them.
The furthest I got with MCU code was .. with claude's help.. splitting the layers between "low level register code" and "problem domain logic". Specifically it was a Parallel Nor FlashROM USB programmer. The split was the "GPIODriver" and "MemoryTransactions" modularisation.
For testing I wrote a different GPIODriver which did nothing but echo on UART. My next steps was towards running tests on the code without actually deploying it to the MCU.
EDIT: One omission of this testing structure is possibly obvious. It doesn't test "timing". In big iron world we would use things like strace, nanosecond logging, val-grind, cache grind etc. from critical path analysis, I believe in MCU land the equiv is "signalling states with gpio pins and test points" then attach a scope.
It is a lot of effort, but I think it's worth doing. Even if not for testing purposes. When you are in that MemoryTransaction layer, you really don't need to know how "setAddrBit" or "setAddrWord" works. Does that potentially lead of "missed optimisations?" ... yes. Can they be fixed later? Usually. Are they important? Depends on the application.
-
Your example of the thresholds is a good one for how it starts. You write exhaustive tests. If you change the values, all the test breaks. You introduce a config mechanism to change the values at runtime or even build time. However, that itself needs tests. It adds complexity. It can be a point of failure itself.
Also, "unit" tests should be unaffected by it. A unit test should not be coupled to the configuration mechanism, or it can't be tested in isolation. So the "unit" of code has to "be given" it's lookup table and then queried about it. Meaning the unit test has to create fabricated config structures and test against those. However, you also need an integration test which proves the "unit" function at it's intergration points, aka the config system.
Solution: KISS. Don't overengineer. Don't overtest. Don't prematurely design a "scalable" architecture - those almost always fail. Pay most attention to module interactions; try to keep interfaces clean and simple. This keeps complexity contained.
Human-designed tests were always pain points for us, too. False positives all the time; real regressions passing through. Human employees paid to write tests not understanding the big picture, breaking the functionality, and "fixing" the test to proudly pass that changed behavior.
Software is difficult. There are no silver bullets. But simplicity and not believing into promised silver bullets is the closest one gets.
Ask the AI if all that complexity is needed. Let it propose a smaller solution. So far AI is biasing towards smaller fixes. This is usually a good trait. Except once in a while you truly do need a larger refactor, or create a layer of genericity. Then the human needs to take the lead and make it happen.
-
:)
[attachimg=1]
-
Your example of the thresholds is a good one for how it starts. You write exhaustive tests. If you change the values, all the test breaks. You introduce a config mechanism to change the values at runtime or even build time. However, that itself needs tests. It adds complexity. It can be a point of failure itself.
Also, "unit" tests should be unaffected by it. A unit test should not be coupled to the configuration mechanism, or it can't be tested in isolation. So the "unit" of code has to "be given" it's lookup table and then queried about it. Meaning the unit test has to create fabricated config structures and test against those. However, you also need an integration test which proves the "unit" function at it's intergration points, aka the config system.
Solution: KISS. Don't overengineer. Don't overtest. Don't prematurely design a "scalable" architecture - those almost always fail.
I don't agree with not designing a scalable architecture. The problem with designing a good architecture is that it is very hard and time consuming. Though, when done right, a scalable architecture gets a project going quickly AND doesn't get in the way of future expansion.
-
Just checking in. nctnico, your suggestion about using opus was correct. Opus 4.8 with high effort is what I use now, much better than before, thanks.
-
I don't agree with not designing a scalable architecture. The problem with designing a good architecture is that it is very hard and time consuming. Though, when done right, a scalable architecture gets a project going quickly AND doesn't get in the way of future expansion.
Prematurely designed scalable architecture is almost always a mistake. To know what the actual operations need, you need to do some sort of real-world product first. That drives you to see the real pain points, and design a useful architecture which scales into things you need, and doesn't bloat on stuff that's totally irrelevant.
The risk is really that your professionals refuse to work with "hobbyist ad-hoc mess", even when you know that is exactly what you need first to figure everything out.
There is nothing to fear in redesigns and rewrites when they are truly needed. The wheel has been reinvented countless of times, that's why it's better now than the original wooden wheel. When the professionals say "redesign is too costly", they are really saying "we don't have the skills to design this for you", which is a warning sign that you are working with the wrong professionals - choose wisely.
But if a redesign is super expensive, a fresh design of same complexity would have been even more expensive, because it would have lacked all the experience gained from the first iteration. This is the professional's bluff. Their story is always the same: "we should have been done this and that, that would have been easy, but now we can't do anything except an even more expensive super-mega-redesign of two years and millions of €". Bluff.
Software and computer hardware evolves fast, too. Every serious long-term software product has been redesigned and rewritten multiple times during its history, out of necessity. It seems that the more complicated, more "well-designed", scalable product, the faster it spoils.
Claude is like McDonalds of code - you kind of know what you are going to get. Finding right human workers is very difficult and expensive. Some succeed, and that's nice.
-
In todays Claude Code adventure. |O
When ask why codex catches bugs Claude Code doesn't
[attachimg=1]
-
In todays Claude Code adventure. |O
When ask why codex catches bugs Claude Code doesn't
(Attachment Link)
That is the correct answer. You can see it while staying in the same model and harness; just ask Claude to do something, then pop up a fresh session and ask it to check; it will usually disagree on some things, possibly finds real bugs. This is valuable, and the computational cost isn't that high - maybe it took 5M tokens to build a semi-large feature; but it only takes maybe 100-200k to read all that code, reason about it, find a bug or two, and give suggestions.
It's funny how the whole language changes in a fresh context. Just like most human programmers, it's somewhat attached to the code it wrote, and tries to explain things away, it literally says "my code". When you commit that to git and ask a fresh agent to modify the same code, it's not "my code" anymore, then it will be quite critical about it, even if you don't ask it to be critical. It's interesting behavior; maybe more than actual emotion of attachment, it's the goal-driven nature, and when it decides its task is done, it requires a bit of pushing to consider the work unfinished again. A fresh context however, hasn't even started, and it's eager to read and comment on code you even hint looking at.
Using different models probably adds a bit more, because their trainings would have different blind spots, different strengths/weaknesses. But probably difference between Opus 4.8 and GPT 5.5 or Claude Code / Codex harness is secondary; just the fresh context itself is the main factor.
Some try to automate this process, but this is also where human-in-the-loop is beneficial. Maybe you can automate the part where a second agent finds a clear bug, and tells the first one to fix it (or fixes it itself), but usually it's not about clear-cut bugs but rather, finding edge cases / design peculiarities you need human to make decisions.
Practical example: a somewhat complex model predictive control electric boiler controller. I let Claude mostly design the implementation details and implement it. Today fixed three bugs:
1) actual logical error in performance optimization: baseline cost from simulating full plan; plans iterated with partial re-simulation (only after the element which changes) - that partial cost compared to original full-plan cost. This is exactly a type of mistake which AI does not seem to do very often - it's quite good at this kind of logical thinking. Happened nevertheless. Good thing - it found it completely by itself; all I had to do is to persuade it that "yes, it really is broken - create artificial tests and look at their results until you fix it". It fixed it.
2) another similar type of logical error - also found it and fixed it without my help beyond persuading it to find it.
3) most interestingly: and this is something Opus 4.8 truly didn't "grok" itself: predicted hot water usage curve is in "liters of hot water per hour". The model correctly subtracts this much of hot liters from the boiler. But as hot water holds more energy, same liters/hour water usage is modeled as more expensive at boiler temperature of 90degC, compared to 60degC. This drives the algorithm to avoid high temperatures - which reduces spot price arbitrage opportunities ("heat it up to 90degC when electricity is cheap"). Claude says this is correct real-world representation. Many humans would do the same. But what it missed: it missed the mixing valve. If your boiler has 90degC water in it, and you shower with 37degC water, you are running smaller flow rate of that 90degC water. So liter/hour of "hot water" was the wrong thing to begin with; energy would have been correct. I supplied it with the liters/hour number; it was trained with some typical liters/day values it double-checked against; I can't blame it. 99% of hired human programmers would have done the same mistake; my specification lacked this important detail completely, and it's non-obvious. This is exactly the case where AI needs a designer who is really into the thing and understands all the subtleties. This is also something that's easily lost when you write the spec in 2 minutes into Jira ticket. But the nice part is: Claude understands what a mixing valve is; it has all the pieces, it just didn't connect them. Very easy to prompt around; just say "don't forget the mixing valve, with 90degC water less flow is needed, energy is all that matters" - and it fixes the code, runs tests, verifies the result.
But you get only this when you actually sit down and do the actual design work - i.e., chat with the implementer (human or AI). Doesn't work if work is managed by passing tickets back and forth. Then the bug remains and causes slight quality regression no one ever notices, because no one was ever interested in that detail, but managing Jira tickets instead and marking them as done.
-
In todays Claude Code adventure. |O
When ask why codex catches bugs Claude Code doesn't
(Attachment Link)
Using different models probably adds a bit more, because their trainings would have different blind spots, different strengths/weaknesses.
That's more accurate from my POV. I don't allow CC to do too much before I hit /new after a updated todo list. Still misses lots of issues. New context windows don't normally have big catch flaws improvements for me, but it suppose to save some usage.
Codex promptly finds issues with CC and vise versa.
Working with AI is becoming a human skill itself.
-
The risk is really that your professionals refuse to work with "hobbyist ad-hoc mess", even when you know that is exactly what you need first to figure everything out.
I'm going to pull you on scale again. You seem to think in terms if "a bit of software = project/architecture"
Most large businesses have 100s of bits of software. A lot of them need to integerate and co-operate or we go back to 1980s when someone would print it out and give it to someone to data-enter back in.
The whole concept of "just redesign it, rewrite it". Works for "one component" or a "group of components", but even that has to be done in concert with the rest of the business.
Now NONE of that has anything to do with architecture.
The architecture is how the 100 components work together, probably many different architectures.
A MCU project is like creating a podium with a Microphone. An "Architecture" is what hold the stadium roof, the lights, the cameras, the fire suspression system... etc. etc. All the seats , the whole complex.
So, yes a new podium and a rewrite. Go for it.
However. It WILL need to integrate into the building sound system, light control, projector controller, etc. They are also parts in the overall architecture. Are you going to redo the whole building just to suit your new podium.
I honestly think you have the words "Pattern" and "Architecture" flipped.
Lets try a little test...
Name me: One scalable architecture and one unscalable "simple" architecture. Just the top level name if you want.
-
I will give me the bare basics of a project I was on recently. No names. Obfuscated purpose, but the meat in there.
Customers send us requests for legal documents. They give us the "named template" and a blob of meta-data. We send them a legal document PDF cira 100+ pages and 100MB. "Templates" are not one single document, they generate a "Pack" of documents. For legal transfer say.
Each document is generated, then amended with various "locale specific legal requirements" like different text on signature blocks, inserts for California etc.
The set of documents is then merged into a single PDF and either sent for "onward electronic delivery" or dropped into a print queue at one of four industrial printer workshops which "ship" them by mail.
All probably sounds easy enough to picture a bit of software doing this. The customer already has one. The issue is the "load factor" and that the current system cannot scale. The "PDF Engine" is a single multi-threaded DotNetFramework application and is "end to end synchronous". Request in....30 seconds... PDF out.
Large customers batch their documentation requests and send them at the end of day. Some at the start of day. Some of their days are different timezones. It bottlenecks. Cannot be scaled horizontally and vertical costs far too much.
This is one component in a set of components, in a wider architecture, all to do with legal documentation generation.
The change in requirements is fairly harsh too. "Move it from "Leased DC servers" to "Cloud" so it can scale without having to buy and commission new hardware. Also so it can run multi-region and have proper failover. Because of the way to the wider market is, it's to all be rewritten in Typescript. Even if that is the worst idea ever. It's what the businesses out there are paying for ATM.
Documents can be requested in batches of up to 100. The current system is struggling under about 100 documents a minute. Larger document packs taking more than 30 seconds end to end is causing issues with browser/proxy timeouts already.
The customer engineering want ALL PDF operations moved to a single 'service'. Rather than bits and bobs spread out across many different flows.
So where would you start?
-
Not "quite" embedded work, but just saturday some fun with claude, I thought you guys would engage with a little more than enterprise BS. Its pure engineering control loop stuff.
Today I am teaching claude how to run a nuclear reactor. This is a 'game' reactor simulator. Maybe "college" or "under grad" textbook, 3 loop PWR.
The game has a REST API. Which allows you to control the reactor and read its metrics/guages.
I just handed it the cold reactor. Asked it to start it up via the API. Absolutely hilarity has been following.
So it lifted the rods and kept lifting to them awaiting a reactor response. When none came it withdrew them all the way to 50%. Only then did it realise the fuel was not loaded and sat in the "unloaded" position. It asked me to insert it as the API has no control to.... so I did. Knowing exactly what would happen with the rods at 50%.
Reactivity redlined. Reactor went from "room temp" to 400C in about 20 seconds. Many alarms and klaxons all at once. I just laughed. It got stuck fighting the reactor through transients, but it did get it under control. It just tripped a dozen alarms doing it and damaged several things. 5/10 - shutdown and mantenance required. However... the reactor was balanced at 300C, the steam gens where at 60bar, 50% fill level. 3rd loop was in vacuum and condensor/condensate in spec. Steam bypass fully open. "Right end state".
It didn't boronate the water, it didn't fill the pressurizer, it did not pre-heat the pressureiser. Just lifted rods to 50% and asked me to dump the fuel in. Ran several pumps dry, over pressured the steam gen, send condensate into the steam turbines.... at least in a game you can reset the simulation and don't have to do the months cleaning that up.
Anyway, Ive spent the last 3 hours? Getting claude to write python scripts for it to control the reactor under my direction. "Safe state -> plan -> new safe state" - to hell with adverse procedures for now.
Startup: Bring reactor to "ready for rod lift" - script runs parallel "prep" tasks and exits when all exit criteria are met. Broron, coolant flow, fuel, pressure, temp, steam plant 'primed'.
Then...
Launch control loops for "rods to track iodine", "steamgen balancer pump controls"...
So far so good. Working through a staged startup process, so I have plenty of time to teach claude.
Step 1: Pre-rod prep. DONE
Step 2: Rod lift for "Tea kettle mode" (very low iodine gen). The only consumer is the condensor steam engine vacuum pump. 3rd loop cooling is passive. rector extremely low power. (No xenon yet). Turbines bypassed. Working on this now.
Step 3: On reaching a stable and safe state from above with the condensor alone running off the steam gens.... stabilise the 3rd loop plumbing and vacuum.
Step 4-n: Ramp up power and stabilise. Notify grid. Open main steam control valves, shut bypass, spin up the turbines... sync... connect.... load match... monitor.
There are parts of this that are new to me, a lot has changed in the game in recent updates. The whole condensor steam driven vacuum system is a bit of a wild horse. Claude is actually pulling in steam plant knowledge, vacuum charts, "steam tables" and trying to work it out too. Quite amusing.
Hopefully before i get bored claude will do better than 5/10 starting it up and getting it on grid.
If anyone knows how to run an "Industrial steam engine condensor with steam emotive vacuum pump"... now would be the time. Claude is busy monitoring the evapouration and pressure rise.
The actual "reactor" part is fairly easy in the game, just a rod control loop. The steam plant is the complicated part.
UPDATE: I don't understand how to start up the condensor that much is clear. Nor does claude. Its just very hard to get any balanced stable state in "Startup mode". Once the steam comes up to the full 60bar the condensor becaomes hard to manage. Once the steam goes to the turbines though, and the condensor switches to "Operational mode" it calms down to a sleeping lamb again. Parked it for today. Will resume with a "stable on load state" and tune the stable state control loops instead next time. Startup is complicated.
-
Today I am teaching claude how to run a nuclear reactor.
I wonder how it would run SimEarth? Friend of mine played with this a long time ago when it first came out, only he ran it as SimHell, for example dealing with plague outbreaks by crashing ice meteorites into the plague region. I suspect an AI would run it in a similar manner because there's easy fixes for any problem.
-
I did a google on win7-64 and Claude Code:
It's possible to run Claude Code natively on Windows without WSL using PowerShell or Command Prompt. Install Node via the official Windows installer, then run the same npm install command.
Has anyone tried this?
I might try it. A friend (heavy Claude user) says Code should be safe because it can be configured to ask for authorisation for any source change.
Also there is loads of stuff about Vscode on win7-64. The win10+ requirement seems to be the usual gratutious "M$ don't support it so we won't" crap.
-
A friend (heavy Claude user) says Code should be safe because it can be configured to ask for authorisation for any source change.
But that's not binding. I've lost the link to the bug report (currently still unfixed) but it was that requirements in CLAUDE.md are just injected into the context window like everything else in there and, like other things in it, can fade or be forgotten. So you can set hard rules that are later ignored by Claude.
-
A friend (heavy Claude user) says Code should be safe because it can be configured to ask for authorisation for any source change.
But that's not binding. I've lost the link to the bug report (currently still unfixed) but it was that requirements in CLAUDE.md are just injected into the context window like everything else in there and, like other things in it, can fade or be forgotten. So you can set hard rules that are later ignored by Claude.
The cat modifies my code. She does not have a permissions system. She just wants to sleep on the warm laptop.
HD crash. You have bad days and get a day into a refactor you no longer want. You modify code when drunk. You come into work to find your dev VM was "culled" by accident. "So sorry, here's a brand new one".
Does the sky fall in?
No, we have git.
-
A friend (heavy Claude user) says Code should be safe because it can be configured to ask for authorisation for any source change.
But that's not binding. I've lost the link to the bug report (currently still unfixed) but it was that requirements in CLAUDE.md are just injected into the context window like everything else in there and, like other things in it, can fade or be forgotten. So you can set hard rules that are later ignored by Claude.
Those are two different things.
The rules in CLAUDE.md -- stuff like "always re-run tests after every change" or "follow the styleguide naming convention" are inputs the the LLM and subject to randomness.
The permissions / approval requirements (always ask before running shell commands, only access files in this directory) are part of the harness and they are not ignorable, although in practice it's super easy to auto hit "approve" without checking.
-
A friend (heavy Claude user) says Code should be safe because it can be configured to ask for authorisation for any source change.
But that's not binding. I've lost the link to the bug report (currently still unfixed) but it was that requirements in CLAUDE.md are just injected into the context window like everything else in there and, like other things in it, can fade or be forgotten. So you can set hard rules that are later ignored by Claude.
Those are two different things.
The rules in CLAUDE.md -- stuff like "always re-run tests after every change" or "follow the styleguide naming convention" are inputs the the LLM and subject to randomness.
The permissions / approval requirements (always ask before running shell commands, only access files in this directory) are part of the harness and they are not ignorable, although in practice it's super easy to auto hit "approve" without checking.
Yes. Claude Code is the piece of software that executes actual file edits and tool calls. This software isn't an LLM. It has various permission modes you can use, and it has a json config file in which you can give it permissions to run some programs without asking. No LLM involved in that. (There is an optional permission mode where LLM decides if something is potentially questionable, and lets everything else pass through without asking. It's clearly enough labelled.)
A lot of work to configure, and then you let it run only to see it stopped nevertheless on permission prompt. And routinely hitting allows/allow/allow is not actually any safer, you just stop reading what commands you approve, especially since some of them are long and complicated. I just run always with --dangerously-skip-permissions, which is so dangerous it can be only accessed by typing out that command line parameter. Zero accidents so far. Yes, I trust it; trust and risk-taking is what makes the world go around. Some day it will do some "expensive" mistake. Shit happens. Claude misbehaving and accidentally wiping of your hard drive is possible, but if you think that's your most relevant threat, it's quite scary. No backups? No version control? 100x more likely something else happens, a human mistake or just hard drive failure.
If you fear that Claude can cause more serious damage than a few hours/days worth of lost time, then that's pretty scary, because what's protecting against your human workers or yourself - or your cat - doing the same?
Even I take some minimum amount of precautions. I let Claude access our production database through a script which defaults to read-only access. So it won't that easily mess with the database. If I ask it to do database writes, which is rare, then I temporarily switch off from the auto-accept mode. Same protections, default to read-only, really work against humans making mistakes, too.
Also don't forget the basic user account separation, I think it nowadays works in Windows, too. Even if you run claude --dangerously-skip-permissions, it can only do what you can do on your computer.
-
For coding, data analysis, and that sort of thing i gave basically no qualms. I have version control, and my version control rejects force push and other destructive commands. I let it write anything in the working copy and rely on backups. Yes technically it could write and execute a script that deletes my whole home directory but that is very unlikely and i can recover if needed.
For sysadmin and deployment tasks i am a lot more nervous. Its still very useful but its inteinsically a setup where you can make destructive operations. Obviously you still want backups but corrupting a production database is still a problem. I dont really do this so its not something i have to figure out how to handle.
-
I started another thread on same subject..... It wont remove.
Have you seen it, it's an interface between your PC and MC, but you instruct the interface (via AI) to program the MC the way you want it, you can even use voice commands instead of typing.
"Code my MC using proper python and have gpio blink on and off at 50% PWM with frequency of 1Hz".