Until recently, I thought that the AI LLMs were just sort of fancy, souped-up search engines. Google on steroids. But then they started getting simple things wrong. And they seemed to understand that that our April 1 stories were just sarcasm. There seemed to be more to them than fancy search engines.
This MIT article explains what is going on with the LLMs.
https://www.technologyreview.com/2026/01/12/1129782/ai-large-language-models-biology-alien-autopsy/
What do you folks think of this?
Like many, I have turned to AI for circuit ideas. And like many, I have been surprised by how many of these ideas just don't work. I have found relatively simple circuits that don't work when built in the real world, and don't work when built in LTSpice. I have already described how AI failed when I asked it a simple question about how many 330 ohm resistors to put in parallel to get 50 ohms. Mike WU2D had found that a lot of AI provided circuits just don't work. (Go to the 10 minute point in his video. )
I was wondering why this is so. So... I asked AI! For those who are sure that their AI is smarter than my AI, let me specify: I just wrote the question into the Google search box and looked at the "AI Overview" in the response.
Here is what AI said:
AI-recommended circuits often fail in the real world due to gaps between simulation and reality, such as a lack of real-world data (noise, rare conditions), AI's inability to grasp complex physical nuances like heat dissipation or component aging, and poor integration with physical prototyping, leading to brittle designs that don't account for manufacturing tolerances or environmental stresses, despite being mathematically sound.
Key Reasons for Failure:
Data Limitations (Garbage-In, Garbage-Out): AI relies heavily on training data; if it's incomplete (missing extreme temperatures, noises, aging effects) or biased, the AI generates designs that work in simulation but not in messy real-world conditions.
https://www.cnn.com/2025/11/16/business/video/internet-archive-wayback-machine-church-digvid
More interesting computer history.
-- Visicalc and importance of spread sheets. (I remember when I first learned to use one).
-- Amazing that the guy who wrote the DOS program for IBM can't get a job today.
-- Sad that the guy who was in the garage with Jobs never got stock options. (Was this ever corrected?)
-- I liked the observation that the most powerful guy in the room is usually the most poorly dressed guy in the room.
And, of course, about the IRF510.
https://www.youtube.com/watch?v=lNypq1XuZRo
Really interesting. Why the design of the analog portions of chips is so much harder than the design of the digital portions.
Great channel.
This book is especially important to the SolderSmoke community because its title has led to one of the most important concepts in our community and our lexicon: That we put "soul" in our new machines when we build them ourselves, when we make use of parts or circuits given to us by friends, or when we make use of parts (often older parts) in new applications. All of these things (and more) can be seen as adding "soul" to our new machines. With this in mind I pulled my copy of Tracy Kidder's book off my shelf and gave it a second read. Here are my notes:
-- On reading this book a second time, I found it kind of disappointing. This time, the protagonist Tom West does not seem like a great person nor a great leader. He seems to sit in his office, brood a lot, and be quite rude and cold to his subordinate engineers. Also, the book deals with a lot of the ordinary stupid minutia of organizational life: budgets, inter-office rivalry, office supplies, broken air conditioners. This all seemed interesting when I read this as a youngster. But having had bosses like West, and having lived through the boring minutia of organizational life, on re-reading the book I didn't find it interesting or uplifting.
-- The young engineers in the book seem to be easily manipulated by the company: They are cajoled into "signing up" for a dubious project, and to work long (unpaid) hours on a project that the company could cancel at any moment. They weren't promised stock options or raises; they were told that their reward might be the opportunity to do it all again. Oh joy. This may explain why West and Data General decided to hire new engineers straight our of college: only inexperienced youngsters would be foolish enough to do this. At one point someone finds the pay stub of a technician. The techs got paid overtime (the engineers did not), so the techs were making more money than the engineers (the company hid this fact from the engineers). The young engineer who quit probably made the right move.
-- The engineers use the word "kludge" a lot. Kidder picks up this term. (I'm guessing with the computer-land pronunciation that sounds like stooge.) They didn't want to build a kludge. There is one quote from West's office wall that I agree with: "Not everything worth doing is worth doing well." In other words, don't let the perfect be the enemy of the good. Sometimes a kludge will do.
-- Ham radio is mentioned. One of Wests lead subordinates was a ham as a kid. Kidder correctly connects this to the man having had a lonely childhood. Heathkit is also mentioned once, sarcastically.
-- The goal itself seems to be unworthy of all the effort: They are striving to build a 32 bit computer. But 32 bit machines were already on the market. The "New Machine" wasn't really new.
-- Kidder does an admirable job in describing the innards of the computer, but even as early as the 1978 models, I see these machines as being beyond human understanding. The book notes that there is only one engineer on the hardware team who has a grasp of all of the hardware. The software was probably even more inscrutable.
-- I found one thing that seemed to be a foreshadowing of the uBITX. The micro code team on this project maintained a log book of their instructions. They called it the UINSTR. The Micro Instruction Set. Kidder or the Microkids should have used a lower-case u.
-- The troubleshooting stories are interesting. But imagine the difficulties of putting the de-bugging effort in the hands of new college graduates with very little experience. I guess you can learn logic design in school, but troubleshooting and de-bugging seem to require real-world experience. We see this when they find a bug that turns out to be the result of a loose extender card -- a visiting VP jiggled the extender and the bug disappeared.
-- Kidder provides some insightful comments about engineers. For example: "Engineering is not necessarily a drab, drab world, but you do often sense that engineering teams aspire to a drab uniformity." I think we often see this in technical writing. Kidder also talks about the engineer's view of the world: He sees it as being very "binary," with only right or wrong answers to any technical question. He says that engineers seem to believe that any disagreement on technical issues can be resolved by simply finding the correct answer. Once that is found, the previously disagreeing engineers seem to think they should be able to proceed "with no enmity." Of course, in the real world things are not quite so binary.
-- This book won the Pulitzer prize, and there is no doubt about Kidder being a truly great writer, but in retrospect I don't think this is his best book. This may be due to weaknesses and shortcomings of the protagonist. I think that affects the whole book. In later books Kidder's protagonists are much better people, and the books are much better as a result: for example, Dr. Paul Farmer in Kidder's book Mountains Beyond Mountains.
-- Most of us read this book when we were younger. It is worth looking at again, just to see how much your attitudes change with time. It is important to remember that Tracy Kidder wrote this book when he was young -- I wonder how he would see the Data General project now.
-----------------------
Here is a book review from the New York Times in 1981:
https://archive.nytimes.com/www.nytimes.com/books/99/01/03/specials/kidder-soul.html?CachedAug
Here's one about a fellow who also re-read the book and who provides a lot of good links:
https://auxiliarymemory.com/2017/01/06/rereading-the-soul-of-a-new-machine-by-tracy-kidder/
Wow, that bank vault in the basement is really intriguing. We need to find more of those.
The Usagi guy's 6AU6A T-shirt is pretty cool. I also liked his reference to Tracy Kidder's book "The Soul of A New Machine." I happen to be re-reading that book now. I'm struck by the complexity of even the computers of the late 1970s. At one point Kidder notes that there is only one guy on the hardware team who has a complete grasp of how the hardware in the new machine actually works. The software was probably even more inscrutable. And of course, things have gotten a LOT more complex. This is the big reason that I have decided to stick with simple, analog, discrete component, HDR rigs that I can understand. To each his own. One look at the wiring on some of those old computers tells me that this is not for me.
Wow. That is the method that they stored computer memory for the moon missions. When they were satisfied with a program they would say it was time to "put it on the rope."
Here's an article on the women who built the rope memory (and the integrated circuits used in Apollo). This reminded me of the women's collective in Hyderabad that "wove" the ferrite core transformers for Farhan's BITX rigs:
Here is a Wikipedia article on core rope ROM memory with some great illustrations:
https://en.wikipedia.org/wiki/Core_rope_memory
-- Not long before the fatal Apollo 1 fire, an MIT colleague of Don Eyles had a drink with Astronaut Gus Grissom. Grissom unloaded about the poor state of the spacecraft, saying that, "What we have here is a Heathkit." Grissom died in the fire.
-- Eyles mentions the use of 6L6 tubes in analog audio amplifiers.
-- MIT's Doc Draper used a Minox camera.
-- When the Apollo 11 astronauts came back and were living for two weeks in an isolation chamber, NASA had bulldozers on standby to bury the whole thing ("astronauts, staff and all") in case some dangerous moon bug was detected. (Is that true?)
-- At one point soon before an important missile test, engineers realized that they needed an isolation transformer. They did not have enough time to order one. So they took an isolation transformer out of one of their soldering stations and used it in the missile. It worked. Sometimes you just use what you have on hand.
-- As a kid, Eyles took a summertime shop class with W4LRO. Eyles himself went on to get his ham license -- he was K4ZHF and was active for a while on the 40 meter and 6 meter bands.
-- He writes of how the Apollo software acquired more "juju as labor and logic were poured into them." Juju.
-- He describes the electronics lab in the MIT Instrumentation Laboratory: "If you had a private project you could sometimes get some simple milling done for a smile, and you could scrounge the odd resistor or capacitor... On the second floor there was a small "hackers shop" with a drill press, metal shear, a bending brake, and a few hand tools which was open to anyone, including software engineers. That was the first use of the term "hack" in a technical context, that I can recall hearing. I took the term as referring to the sometimes messy process by which perforations of suitable sizes were made in the aluminum boxes, or chassis, that were used for constructing electronic devices." Indeed. We hack.
-- After describing the first integrated circuits, Eyles looks back at high school and notes that he and a friend, "after learning about truth tables, James Chambers and I had experimented with similar devices composed of relays mounted on a piece of plywood." Plywood.
More to follow on this book.
