Using Claude Code for embedded work

[Siwastaja]

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.

[paulca]

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.

[peter-h]

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.

[ejeffrey]

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.

[5U4GB]

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".

[SpacedCowboy]

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:

Code: [Select]

  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.

[peter-h]

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.

[aae30]

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.

[paulca]

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?

[Siwastaja]

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

[brucehoult]

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.

[Unixon]

After reading the thread to this point I'm still not getting what kind of work are you trying to offload to "AI".

[paulca]

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

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.

[paulca]

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.

[Siwastaja]

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.

[Unixon]

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".

[Unixon]

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

[peter-h]

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.

[Siwastaja]

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.

[Unixon]

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.

[SiliconWizard]

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)

[Siwastaja]

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.

[peter-h]

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.

[az1]

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.

[peter-h]

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