The Amp Hour #722 - AI Tooling with Matt Liberty and Luke Beno

This is the FR podcast. Released April 22nd, 2026. Episode 722. AI tooling with Matt Liberty and Luke Pino. Welcome to the AMP Hour. I'm Chris Gamble of Contextual Electronics. I'm Luke Pino with Tundra Labs and We're Wolf.us. And I'm Matt Liberty of JetPurch and Julescope. Welcome back guys for an in Piedens matching episode. We're going to be talking about AI tooling here today for hardware and firmware people. This is actually comes out of a quasi meetup group I did for the consulting forum. You guys have been very active participants there and we're really just kind of, I don't know, we've been trading notes. I'm a lot, I asked you to come on and explain some of it here. But I'm trying to figure out what I should be doing. It's kind of like this consistent FOMO I think I mentioned on the show before. I feel like I could be doing more. And you guys are doing so I thought, "Wag, have Luke and Matt on to talk about it." Definitely. Well, thanks for having us on. We're also figuring it out. We've been playing with AI in a bunch of different areas. But it's changing so fast. And the way that I can actually apply it is changing so fast that you're always missing out on something. Yeah, and I completely agree. It's just get started somewhere and keep playing with it until it becomes useful in a way that's meaningful to you. Yeah, I was reading some like, I was reading hacker news thread about like open claw, you know, I talked about open claw one or two episodes ago and just like, you know, I've been trying it out and playing with it and then I'm throwing it out and then I'm like, "Oh, I'm going to do it." And then I'm like, "Oh, I'm going to do it." And then I'm like, "Oh, I'm going to do it." It was fine. But it is interesting like the psychological aspects of the building things has changed a little bit as well. Yeah. And I feel like to like engineer your engineer bring kind of handicaps what the AI may or may not be capable of doing. And a lot of times you don't even think to try it just simply because you just say it would be too good to be true for that outcome to happen. And then you try, sometimes it's real. So that's, yeah. Well, let's step back and give people, so you guys have both been passed guests to the show. Let's give people a quick look at where you've been, what you've been doing in the meantime. So Luke, why don't you go first and met you go? Sure. So I run a company called Tundra Labs. It's about been doing it for about seven years, maybe coming up on eight soon. So we built hardware. Our first product was a Kickstarter for a virtual reality device called Tundra Tracker. That's been really successful and learned a lot about creating a business selling products, fulfilling products, doing all of the business like things in addition to the hardware engineering. And then over the past two years, we've been investing in a new product and a new brand called We're Wolf, the website is We're Wolf.us. And we're trying to solve shortcomings of the USB-C ecosystem in the power specifically, empowered delivery. And so this time around, we're working on building our own manufacturing line. I'm really focused on high volume production in the United States, particularly of modular electronics. And so the first product that we're bringing to market in that category is a product called V Flex. And it's essentially a configurable USB-powered delivery sink that can be programmed for any output voltage and any adapter cable that can connect to traditional things like DC barrel jacks and legacy products. So I founded a company called Jet Perch. LinkedIn just told me it was 15 years ago, which is kind of crazy. Initially as a consulting company, but then in 2019 launched the first Julescope JS110. That went on to sell until I couldn't build any more due to COVID shortages. The JS220 launched in 2022, currently working on the JS320, our third generation. So product that allows people to design things with lower energy and better battery life, that makes it super easy to measure energy consumption and high dynamic range current. And now I'm figuring out how to run the business more effectively and easier for development and testing and robustness all using AI and new ways of approaching problems. Yeah, and I mean, from what I've learned from you guys as well, it does seem like Luke's doing a little bit more on the operational side and even into the physical test and Matt, you've been doing more on the code side firmware FPGA, but maybe also some logistical stuff as well. Yeah, also created a ERP system as well. So that's one of the things that we have in common. Right, yes, that is what we started talking about and you guys give a demo of that is pretty cool. Maybe we start with that. So like ERP generally, you know, there's what like arena is one of the one that's known as PLM. See, I always get this stuff confused to PLM and then ERP and like what, so like, give us what it was an ERP. Yeah, and I kind of view all those tools as kind of like one big massive thing in the, there's no like defined lines between them. And my interpretation of an ERP is kind of all of the business functions that you have like keeping inventory, recording orders and fulfilling orders, doing planning where like inventory of parts that you need in order to do a certain build or something like that. It's all of the like organization around operating your business ERP means enterprise resource planning. So any resource that you need to use within your business, the ERP will help you to coordinate that. What are the big ERP providers, I suppose is that like I can think of it. I can't think of that. ERP has been around in the big gorilla for decades. There are tons of different solutions. You know, but the thing is like with SAP, if you even want to sit down at the table, you're spending a million dollars to customize it. You know, it's meant for big companies. And I think it's important to say that Luke and I both run small companies. So previously I was using a tool called parts box, which is great. If you don't want to roll your own, it's an off the shelf solution that has served me well of all what four or five years now. But for me, an ERP is really about managing and predicting and ensuring that my builds all come off right. So it's on the engineering side, taking your design and entering into a way that you can track it, then purchasing components and making sure that you're going to have the components you need when you need them. Also integrating with suppliers so that I can purchase parts easily and then track when they're going to be coming in. Things like change orders. Another thing in the fact I actually have worked with my contract manufacturer to track parts through the factory. We had an issue over the last few years where parts kind of went missing. I have enough parts that it's hard to find if you just stash them in some random box, where that those parts are without a three hour search. So now we're organizing things much more carefully, not carefully as far as time, but carefully as far as tracking so that if someone needs to get a specific part, they can just look it up in the ERP system and know exactly where it is. It's just a young who does it does parts box was also on the show back on 522 and that started kind of like lab management, but also then I did expand into more of a and you also expanded it right. I mean, you guys had also like done add-ons to their, but now it's kind of turned into this more of a bespoke system. And it is interesting to because like it could pull into these other these other ecosystems as well, like PLM is product life management. That's like that's like drawings and things like it you mentioned manufacturing tying into that it seems like it's like this ties to this times is that it's just like so many different pieces that are in there. I think isn't I think Michael was also Michael core was also on the show at one point talking about Duro like that's you know like all of these different tools that are in in this space. And so now it's like, well, the relational databases. things that that's like something that AI does, another of them tool does really well actually, I feel like, so it does seem like a good target. >> Yeah, it certainly is. In every use case is so unique that you wouldn't be able to find this Goldilocks system that checked all the boxes for your one specific company. That was the great thing that the AI development unlocked for I think for both Matt and I is like to be able to build the exact system that we wanted, nothing more and nothing less. >> What's something you would need there that, like a SAP might not have even if you did pay the million dollars? Like what are some of the things that you guys put in there that makes it more useful, I guess? >> So I would say that for us because we have manufacturing in-house, we bring in some of the PLM type stuff where you have release management, tracking of, like say, manufacturing files for a given pick and place machine. We can develop, I call it like a cam workflow, computer-rated manufacturing where we can have tools integrated into the ERP that analyze like Gerber files, pick and place files and actually create the programs that we run on our specific juki pick and place machines. So like it gets really long tail when you start to compound all of those different things into a single tool. Say for example, running test pictures where you want to run this specific programming operation and then have the programmer upload an archive of like a record that you program that. That can all be one giant monolithic system that does exactly the business practices that you want to do for your specific business. >> Yeah, maybe we should also say, like what is the alternative? I guess so like in the case of like the juki machine and things like it, so like what would it have been prior to all this stuff? Like what are the flows on a factory floor like yours in-house? >> Yeah. Like you're stitching together a lot of disparate software that's been developed on different platforms over time with different user interfaces, you know, might need to run on a specific Windows machine. All of these different like Hodgepodge. >> Chinese characters that were maybe, you know. >> Exactly. >> Maybe give you license errors. >> Yeah. >> So you know, oftentimes you know, like one thing is, I've bought used equipment so like maybe that software is not updated, it's out of maintenance, it requires Windows 7 or something like that. Like it gets really fragmented really quickly with just all of the different pieces that you're putting together or something like that. >> Got it. And then what about on the CM side, Matt? So you're doing now working with the CM as well. You're handing off like just a bomb and they're doing all that kind of back of house translation to work on their machines. >> So as far as integrating into the pick and place machine, that's still all on them. And they have a, they're small CM, they do a lot of that manually. >> And when you say manually, do you mean like a USB stick sort of thing or like they actually like drop box or share a Windows share drive kind of thing or doesn't even know? >> So I'm not as much of a part of that, but I see them literally at the machine entering in parts information and footprints so that it places it correctly. So I'm not entirely sure of their process, but as far as my process to integrate to them, it's giving them, they have a bomb, they have the pick list of stuff that they need to get and they now know where to go to get each of those things and that it's actually there, which makes it much more effective for my inventory to live there at the CM and have them pull it, do the run, then put it back if there's any left for the materials. One of the problems that I had over the years, Juleskopes have been around for seven years now. And as you have attrition and things get lost or not ordered correctly, you kind of get out of a sink unless you do a full audit at a regular basis and that was getting challenging and we had some mistakes were made. So this is all helping us stay on top of things. So as they use like a full reel, they scan that they use it, we know where it is in the build and we know at that point, it's a checkpoint of inventory. So we can stay on top of making sure that all the inventory is on order for the future. From my perspective, before I did this, I was using PartsBox with a bunch of custom Python scripts that would help me forecast my builds and what I need to order when. I think PartsBox is starting to extend into some of that. I'm not sure. I know it's on one of the feature lists, items that Yano's considering. But for me, it was all custom Python. Now all of that's integrated into one thing, also with a better barcode scanning for the way that I want it. And this is something, again, that PartsBox just implemented at the end of last year, the barcode scanning stuff. So there are definitely alternatives out there that are meant for small businesses. I had gotten to a place where there is enough clooge together that it relied on me being disciplined enough to run it, which means it didn't get run. So having a website that's just working all the time and I just look at it, it removes that one frictional point that makes it so much easier for me just to stay on top of things. Yeah, it is interesting too. I feel like the engineer way is almost like pushing towards the Tesla method of like, well, I'll just do everything. Not like how hard could it be, but I just want to get my arms around this whole problem. And it does seem like some of this is actually enabling some of that. Of course, there are the known downsides of it all as well, more to manage, more tech debt, all that sort of thing. And unknown bugs that might be under the hood, there's always that sort of thing. But it does seem like what I'm hearing from you guys, as a third party, is like, this is literally money in your pocket or not. So like, parts left or parts lost is like, you paid for those parts. Those get found two years later. It's like, oh, shit, like this is-- I really could have saved some money there. And some of the parts you use, Matt, I know, are not cheap. For sure. Yeah. And just being able to stay on top of all that really helps me be more confident about the business. So yeah, there is definitely time. But there are certain areas where AI is really good because there are tons of examples. An ERP system that is web-based is kind of in that sweet spot, because there's tons of web things that are out there really easy to create a website. My tech stack is just SQLite with Python running and SQL Alchemy to make things pretty standard. So it's not going crazy off the rails in any direction. And an ERP system's done a thousand different ways by a lot of people. So it's a known thing. Now, obviously, we are customizing it both of us. But it's not like it's something that's invented. It's like that we're creating from scratch as something that's never been done before. It is very much out there. And AI is, if nothing, a great pattern recognizer and replicator. One thing I wanted to call out was actually back in episode 299. I mentioned this to you guys when we did the last AI hangout thing is Jonathan Herschmann, who was on the show. He did PCBNG, which was kind of like a small version of what Luke's talking about as well. Where it's basically like, they reverse engineered all the tool commands. They then set up this kind of verticalized mini factory system. Then they got bought by Altium. And I don't know what the hell happened. But I haven't heard from Jonathan a long time. I hope he's on a sandy beach somewhere enjoying a fruity cocktail or something like that. But to me, this is my kind of reference point for this sort of thing. It does sound like, Luke, you're kind of moving in that direction as well. Where you might be able to reverse engineer or push more stuff direct in the machines and really find efficiencies that way. Where then you'll also run into the problems Matt talked about. Or it's like, and I probably hasn't scanned a lot of Windows 7 tooling from Juki or whatever, right? Right. Well, that's pretty interesting actually, too, because isolated use case, but the clawed specifically, what I'm using for this task is really, really good at protocol analysis and diving into wire shark dumps of communication between-- I'm interested, like, say, the Juki software and something else. So actually, it's extremely skilled and diligent at sorting through mounds of data. More than any human can have stamina to do, right? Like, none of us on the call would a want to or be physically capable of reading a million lines of wire shark dumps and comprehending it at the level that the LLM is capable of. So actually, that turns into an actual very easy task for a clawed to reverse engineer over the wire protocol that's exchanged between the proprietary Juki software and the pick and place machine itself. That's a major unlock. It is kind of at the level, though. That's still kind of at the level of inducing movement in a hand by electrostimulating the nerve of the arm sort of thing, right? It's like maybe a little bit more than that. But still, it's not direct control. And it's a work around. But I remember you saying, Luke, you said too that these tool makers, like Juki and Simmer, they are so good at mechanical and precision and even control systems. But the software is just the last thought. And so it's like, actually, you could find a lot of opportunity in that space if you did get into the guts of this thing. Yeah, definitely. I think that's like, The older the machine, the more elegant the hardware is, the mechanics. >> It's a margin. >> The more the software is. >> Exactly. >> Everybody who's used software that is for a particular machine or whatever knows that it can be very unuser friendly. It has features that are named weird things and they're located in weird places. The institutional knowledge that people who have experience with this is they just know the hiding places for all of these specific knobs to turn. >> It is really interesting to -- I'm going to fund the article now, but Jeff Bezos is currently investing in a big fund that's basically -- the things we're talking about right here, basically reversing and implementing protocol hijacking if you don't mind the term. That is basically like there's a new $200 plus billion fund in order to bring this same kind of idea into the factory. So like industrial control and similar and like finding efficiencies in the factory. I think we could all imagine across the space being able to find more places that basically LLM tools could in theory make things more efficient. So they're kind of chasing that stuff right now. I'll drop that link in if I find it. >> For sure. When you're building a factory, you don't buy all of your equipment at the same time. So it's just a lot of different isolated systems that get stitched together basically by people and by people's workflows. This is kind of replacing that with like actual structured code. >> I did misspeak it was $100 billion. Only $100 billion guys. If you want a piece of that, it's only smaller now since I said it. And just keeping on the pattern recognition side of things. So like Luke, you're using it to do protocol analysis. One thing that I've found, it doesn't matter where that massive amount of data as long as it's structured. And it has some sense to it. The LLMs are really good about figuring out how to parse it. In my case, I had an issue with the gateway. So Verilog code where an FPGA implementation of a FIFO was not treating the read flag correctly in one case. And then the empty flag was also not working. So two different errors in the same area, which is how things work. But I ended up having the Cloud Code instrument everything, captured all with the salier logic analyzer. And I had this huge trace of where every buffer that was going through these set of FIFOs was being pushed and popped, pushed and popped, pushed and popped. Sometimes it would pop the same one twice, which it shouldn't do ever. Because it has to be pushed on in order to be repopped. So that indicated what was wrong. Cloud Code just iterated with hardware in the loop, found the issue. The first one, which was the empty flag and fixed it. Until a few months later that I actually came across the other one, because it was so rare. But again, it was like the same setup, just put it through all this data. And it even wrote Python scripts to go through, which it then interpreted so that it knew when these pushpops happened. I mean, this was a trace of millions and millions and millions of pushes and pops. And it was able to parse through all of that and fix the issue, commit it and build it and prove that it was working all with hardware in the loop too. And the hardware in the loop piece of that was the salient. So this is actually like programming a new image, pushing the bitfile to the FPGA, measuring the output using the salient. That's the that's the hardware in the loop there. The only caveat is I was also human in the loop for the salient. So it would tell me when I had to capture it. Because I couldn't figure out how to get the salient to interpret the data using the analyzer correctly. Sayley now has an experimental MCP server that was working, but it couldn't figure out how to get the analyzer data out of it. So I don't know if there's something I was doing wrong or if the if the salient code is not quite there yet. But I had to then dump all that out to a CSV file that it would then interpret. So almost almost complete. Hardware in the loop as a, you know, as like a catch all term is like something that I've seen. I think experienced I've seen I've seen the workflows and stuff like it never actually implemented myself directly. But it does feel like one of those things that like we all felt like it should be possible like we all know like, okay, I'm going to program this new board and then I'm going to plug into my scope. And then I'm going to look at the trace on this on the scope screen is like and wouldn't it be easier if there was something that just did all this stuff and hooked it all together and it's like, yeah, yeah. And actually we're kind of moving in that direction, but now some of the tooling is also capable there are other tools that are that you find are like, you know, even just like Seger and J links and stuff like it like hooking in open OCD things like that. Yeah, definitely. I saw I'm using Seger with piling dash square, which is a way of interfacing through Python also pie elf tools so that it can go directly to the the elf image that you build that's debugging. So it knows exactly where all the symbols are and then it can inspect one thing that I found so I'm using an STM 32 H seven s I had to break up the data sheet. It's like a 3000 some page PDF data sheet. So I broke it into pages just using PDF TK blast. So PDF TK is the program last is the command within it or sub command and it just splits it out into single pages. And then I also ran that through forget which tool, but it's one of the ones that does PDF to mark down so the now the LLM has access to the pds and the mark down by pages so it doesn't get overwhelmed in its context and can go through everything also had the SVD file, which is arms way of, you know, saying where registers are at that it could look at to. And with all that it's done remarkably well in a few things I actually had it right the driver for doing signature validation so it has some crypto crypto block and I had I pushed down to the bootloader encrypted images that are signed and it you know I worked with the cloud code to actually figure out how to configure this correctly for the crypto mechanisms I was using which you know a yes and. It's the one that thinks used by Bitcoin actually is the one I end up selecting but yeah I could do a bunch of different ones and I the with that again it's one of those cases where you can set up a feedback loop you know what the crypto method is you encrypt it and you know what the decryption or in the signature validation is supposed to be and with when you have that type of feedback loop if you can set it up so that there is a clear pass file criteria. So cloud code can do really well at just iterating until it figures it out what about you look on the iterative side of things that that's one thing that I've struggled with personally I remember you guys talking about it but yeah just one example quickly that's kind of in the same vein is what that was talking about when we were reverse engineering a certain part of the. In place stuff there was a binary file that had a lot of critical data encoded into it and actually just fed it a screenshot of the windows GUI that led to that encrypted data that was enough hint for it to like so take a screenshot of the GUI take the output file that was like a proprietary binary blob format and it was actually able to find those values those key values inside of the binary data and match them up to reverse engineer that. So like you can feed it some pretty just doing like text search the spaces to like OCR and text search then based on the the found care and then also just like looking at the encoding of like binary integers are floats and then matching it it I honestly I don't know how it worked but it actually it worked quite well so I was that was one of those things where I was just like a little bit out of body experience like while this is more powerful than what I would have expected. But in general I'm sorry what was the original question. Well actually I was talking about feedback loops and stuff like it but I was asking about like you know basically going towards a validated solution and having having feedback based on like a set outcome sort of thing and we should definitely like touch on process a lot more like how to engage with a tool like cloud code or open claw. I use it in two different ways like sometimes you're doing like major feature development where you're more like a planning and documentation mode and then sometimes you're kind of having more of a conversation with the AI where you're trying the nudge it in a particular direction to like refine a feature that's developed. Most of the time I'm not hardware in the loop like this but like if you're working on a user interface and you don't know how to describe it specifically like in one fell swoop with a document you know you can piece me a chat with the tool to say like I want this button located in this location and you know have this function and kind of implement it piece by piece and that's where the feedback loop is like you curating what it should do next almost like if you were a pair programming with the tool. If you're a pair programming with with someone or like it the interaction is very similar to how you would interact with the software developer you know who is working on a project with you. Yeah so like less of a less of a like a written down define goal it's more like in your head you know where it is and then you're kind of helping to shape the direction of the table was in your head at least. It's really hard to like from the onset to write like this super verbose document that captures all of your requirements you generally know broad strokes but you want. But then there's that step in between where you kind of that's more the vibe coding piece of it so it's not all vibes and it's not all documentation you have to find the right. What right combination of two? - Yeah, and I do feel like some of this, some of this stuff like within the process side too, like kind of like the coming in my own experience of like being frustrated with it, be like, well, I know what I want, right? And I know that this tool is supposed to be great, right? Everybody says, oh, like log code's great, whatever, like, Gemini's great or whatever's out there. And then I try it and I'm like, hey, make me a program and it doesn't do it. And I'm like, oh, this sucks. And I move on, right? And that's one of the things where it's like, you know, learning from you guys, learning from other people on the forum, and really just like having some reference points on like, what the hell do I do? So someone pointed me at the superpowers skill, have you guys used that one? - Mm-hmm. - That one specifically. - Okay, so it's like a framework, Matt's used it. I've used it. It's actually written by a past guest of the show, Jesse Vincent, who does keyboard-y-o. He is the author of that and incredibly famous now as a result of that. But it's basically just like a set of like tasks that are in there, a set of skills that are there, and then kind of overarching like detection of when you're in different stages of planning. And then it is setting up that full document. So like the other side of the, instead of just doing the one thing and guiding it yourself, it's literally like, I'm gonna write a full spec on what this thing should be, and then go through planning and testing and all that other stuff. And basically it, it lives as like a meta layer on top of the other stuff, right? Is that, have you experienced Matt? - Yeah, I've definitely got confused by it. I'll say honestly, it kicked in sometimes. So when I knew I was doing it, asking the super-paraske to do things, it made more sense. But then sometimes it just stepped in when I had it installed. And I didn't use it long enough. I've kind of now uninstalled it and I wanna try another thing. I just couldn't quite wrap my workflow around it because I think a lot of what I'm doing is not as much of the planning as it wanted to take on. So a lot of what I, the way that I've been using AI is much more like I'd use an intern or new grad, kind of say, do this little teeny bit. Don't think too much. - Yeah, I don't trust you enough. - Yeah, here's the piece. - Don't bite off too much. - Exactly. Now when I did the ERP system, things were different. - Well, and also it's just like, I don't know what to tell it to do until I see the result. - There's also that, right? Exactly. Truly the iterative product approach, it's like, yeah, I don't know. I have one in good example where it worked really well. I was making like a documentation generator thing that I needed. And like this was like, I knew I was working to a spec. I didn't make docs that fit that spec. I basically said, hey, like I need to do all the things to fulfill this requirement. The fulfillment was already there. I pointed to all the different pieces that it needed to like do. And in that case, it was great, right? It was multi-tiered development. It was web-based like we talked about. So some things are very well defined. I kind of didn't care about the architecture, how it was built, whatever. And that is my like best success story with it yet because I was firm on the end goal. I didn't care as much about the architecture and kind of what I would do whatever is the strongest there. And I was just guiding it to for some of the preferential stuff like Luke mentioned as well. Like, well, this looks stupid or this interaction is not how I expected it. That's more like a product manager than it is like a directing of intern. Director of intern, I suppose. - And it's just where I've been right now with my development cycle. I'm finishing things up rather than starting new things with the exception of that ERP system. - And even the ERP system, like you're not gonna know that you might say like I've used other ERP systems. I do want it to have this or this or this, but it's like, you guys have been talking about adding stuff on as you go. Like Luke, I'd love to talk about how you've integrated the chat element too as like a, whereas I normally thought of like a chat in a site is like this hindrance. You've actually developed a really interesting use case. - Yeah. So in that changed a little bit also with some of the changes too. - Yeah, I bet it did. - So one major unlock for me in the ERP system in something that, so there's two different things. The first is that I wanted the ERP system to be agentic from the beginning. So or call it agent first. What that means is that it doesn't have a traditional user interface where you have a whole bunch of form and text entry elements or buttons to click, but instead you chat with an agent who manipulates the data for you and enters it for you. So like a good use case is that I can upload a Gerber files, build materials, pick and place file and a step file of a board that I want to load into the ERP and it has a skill that will like extract all of the parts find them in the ERP if they exist, create them if they don't. Go out to digikeanlcsc and match it to manufacturer part numbers and generate pricing information for it. It'll actually extract the individual component step files from the master step file so that I could know like the footprint information. So all of these things would be like probably 10,000 button clicks if you had the manually transcribe the data into the ERP, but since it's in chat, it's literally just uploading the files and say, hey, go do this. And I guess the difference is that corner cases are handled much more elegantly because if the agent runs into some problem along the way, it can ask you questions or you can again kind of help it with more supplemental information so that it can actually digest the data instead of it needing to be perfect on both ends so that some, just dumb script could go and extract the data necessary. Yeah. I do feel like there is always this like reading kind of criticisms of all of these tooling systems out there. It is like, well, a script could have done this, right? That is pretty much like a script, a cron job, an n8n flow. All of these things are like tools that have existed. And so like, well, okay, then why is something else important? Why did your story, both of these stories resonate with me? It's because there actually is additional value here that would not have been with a script or even a person in the loop, right? There's no added value in some of these cases. It's literally, it's all downside to not use it. So then the upside is more clear, I feel like. Yeah, but anybody who's written those scripts quickly realizes that they get on some rabbit hole of some corner case of someone using a time zone thing or whatever, right? Like all of these different little things that happen. So the LLM is self-healing in that way where it can read between the lines in a way that, you know, it's not just explicitly executing code. It's smart like that. Like a human would be, but a human that has infinite patience and yeah, like really a lot of diligence. I don't know. I've seen a lot of board files that look very similar to like JLC or similar. And they're just like, yeah, you know, we're just pros and it's sending back. Yeah, got wrong again. Chris got it right. JLC is a Gen Tech 2. They just put a human in the loop there. They have the ability to see it. It's the same. Yeah, except there's 12 hours to live, which is like, you know, if I can get past the 12 hour delay, then I'm in better shape. For sure. And then the second benefit of adding the chat previously was that I could do like core feature development inside of that in app chat too. So like, if I saw a feature that I wanted to add to the chat, I could just write in app, you know, ask it to add this feature. It would do the planning and implementation of it. And then it would just magically appear when I hit refresh on the app. That to some extent has been diminished now because of the anthropic not allowing their subscription plan to be used with OpenClaw, which was the tool that I was using. And that's specific. I should say as well. I think I mentioned, I referred to it in the last episode or whenever I was talking about OpenClaw. But basically, Luke and Matt talking about this specific element and probably the chat element being built into an app is like, that's what finally got me to be like, oh, I want that. Like, that's what I want. Yeah. Because you're not just using the app with the chat. You're adding features in-- it's a closed loop in that way where you're adding features to the app while you're using it. And it is always additive as well, right? I feel like another piece-- well, we probably didn't get far enough down the line. Well, you didn't get far enough down the line or really any of us have where it's like, eventually, features conflict, right? You bolt enough stuff on. And then eventually, it's like, well, you got 25 databases and all this data lived in this database, but not this database. And that's why the future thing didn't work. It's probably not at that level yet. I'm sure any product manager listening right now is screaming at their podcast app. But at the same time, who cares? It's like-- well, I say it as a casual user of this stuff. From an ERP perspective, that could have been an eventual downside, right? Yes and no. It is a downside, and it is a risk, for sure. But you also now have a new think of it like a human that's extremely diligent that can pour through all of your old legacy data and figure out a plan for migrating it from point a to point b. It's just more tokens, which is costly today, but won't be costly in the future. So we tend to try to prevent events that would cause a lot of human pain in the future. But if it's an LLM that's incurring the pain instead, the consequences of those mistakes are substantially reduced. But that's interesting, because you said you stopped doing it when they got more expensive as well. So-- Yeah. I mean, it's a mind-beam, right? Sure, totally. Yeah. Yeah, and I think about like the stuff that you guys have been talking about too. It's like the psychological barrier is just different, right? Like you might have been able to go on up work and hire someone to build any RPS system 10 years ago, right? That is exactly your strategy. You could send a send them this thing and it was not necessarily part of the the plan, right? Just because as well, there's cost and there's a lot of hassle. And now those barriers have been reduced quite a bit. So that's where it ultimately gets interesting. I always think about like the psychological barrier just to getting started with a project too, as much lower than it used to be. You know, whether or not we get ourselves into QuackMars as a result day. That's a future Chris problem, you know? Right. Yeah. At the end of the day, if you're more productive, you can pursue more QuackMars. I'll have so much time. Yeah. I'll be saving more time, but you'll have more work output, whether it's good or not. Yeah, that's more that's that's a question for the site of this philosophers, right? Well, and like on the on the cost piece of things, you know, say that you did hire someone from upwork, I think that you would be prepared to spend probably thousands if not tens of thousands of dollars to develop this software. And so like I have to I said it's a mind game earlier. It's like, well, then theoretically, I should I should be willing to also spend tens of thousands of dollars with anthropic for tokens. But for some reason, I'm super hesitant to do that, right? Even though it makes logical sense, it's like I use the analogy of like paying a dollar for an iPhone app. It's like there's just that once things don't cost zero or $200, then there's just a big wall. Yeah. And well, just to put things in perspective, I just did a stats on my ERP project for non-comment lines of code. It's 22,000 lines of Python, 12,000 lines of JavaScript, 5,000 lines of CSS. You know, so almost about 40,000 lines total. And that is years, a couple years of work. I mean, that I did in nights and weekends using Claude and it just, you know, pumped it out. So the cost, the lines of code is kind of an older, you know, that is going to be a thing that will be claimed at some point, right? It is, it is, it's never been a good metric, but it does give you a sense of scope. It's not a thousand lines of code and not, you know, for these lines of code, I actually, I was not vibe coding everything. There's the Python side. I was paying very close attention to the database structure. The JavaScript, I did not keep on top of as much, but it's reasonably good code as far as code quality with the unit tests and everything. That doesn't include the unit tests. So it's, it's a lot of code. I wouldn't have, without some type of tool like this, I would not have taken on my own ERP system. That would have been crazy. It would have been 10, 10 developers working for two to three years to get the same amount of output, right? And that would be untenable. Oh, yeah, I would, I would still be on parts box, which is, you know, still great. It's just now I have, you know, everything that I can think of in an ERP system that I want, I can sit down in an hour or two and have that feature, whatever, whatever new feature I want. Yeah, you said that you put in your own bar of code scanner. That was like an hour, right? Didn't you say like that was, that was a photo-based one or that was an actual bar, like a shooter, like a laser one. So for mine, I'm actually using barcode scanners. So I actually have both like Zebra, like when you'd see at a grocery store, I also have one of the key, the fully integrated, it's an Android phone, really. That's also a barcode scanner. And I have it locked so that it displays the ERP system. So you're scanning in and you have different things like you can transfer or receive or say you consume this and you just, you know, select that as the Android app, if you will, which is just the locked in website. And then you scan and it does whatever action you've selected. So yeah, adding that in was all given to your, your CM though is the Android one. Yeah. Is that right? Yeah. Yeah. Yeah, super cool. Yeah. And actually now to like the agents are, they have, I think, very good image recognition and OCR. Yeah. So we actually, when we check in parts, we just snap a picture of the part package in chat and send it to the agent in it. You can do this with with any agent just testing in a chat, send it a picture of a real of parts and extract all the information and put it back to you in structured format. So like even barcode readers are, I mean, I think they're still useful because they're extremely fast and deterministic, but they're, they're kind of optional even because the, the agents are so good at reading images. They're trained on billions of these images. Yeah, they'd work well with the adnet labels, which are terrible. Digikean mouse are now with the 2D barcodes are, you know, have a lot of information that just comes right in. Yeah. How about the tie-in to the, to the various distributor systems as well? So you guys, Luke had mentioned digikean LCSC, but like I actually learned from then that there's API access to digike. I always thought that that was locked down for some reason, but it's been hest from digikey. But like, do you guys actually tie in all the APIs or is it more like scrappy kind of stuff? What's work in there? Yeah. So my ERP ties into digikey, mouse, and TI, all at different varying levels. You mean some suck more than others? Is that what you wanted to say, but you didn't say it out loud? If you needed a Chris. No, I mean, they don't always give you the full access. It depends upon who you are and where you're at. So I ended up getting a backlog account with TI, which was a huge win for my business. And I thought that as part of this, I would need a way of placing an order through their API, because that's how they advertised it. Well, they had recently just introduced a way you can kind of do this upload halfway in between thing. The integration with the ERP system for some reason, I could not get working. They didn't really want to support me and uploading works fine. So I can still generate my PO and just upload that PO and it works. So there's varying levels of integration with the APIs, same with mouse or digikey. But for the most part, I can go in, see what I have to order, select where I want to order it from, build up the PO, and then say go, and I can place an order. So I think rightfully so distributors are trying to, like, they're trying to authenticate what is API calls coming from humans versus what are API calls coming from other AI tools or scrapers. So there's a little bit of this back and forth of this API might be blocked for an agent because they're trying to prevent malicious use of it. But then if you want to have, you want to have use like Matt is talking about where you're just using it to get work done. But sometimes they can't tell the difference. And so oftentimes the agent gets sworted by one of those countermeasures for scraping. So I've encountered that a lot where we have to redo how that interface works because of new countermeasures that digikey or LCS are putting in place. Yeah. And just so we define for people as well, scraping is when it's like you're going to pay, this is what all the, a lot of the elements have done to build up their data sets as well. But also like scraping's been happening on Digikey Mouser for years just to have third-party sites that offer the same information that might be on Digikey without actually having like the, you know, for price shopping similar. And so they wanted to prevent that and then have people come to their site to also do upsells and all the other things too, which is very. I'm sure it's very taxing on their servers to continuously be servicing all of these different scrapes or whatever. So yeah, I mean, I, you know, knowing what I know about Digikey, like they have people internal as well that like validate data, like that they're extracting from data sheets and similar or working with vendors. I have to say, if one thing came out of this AI era was the death of the PDF data sheet, like, let's bring it on. Like I don't know how we do it guys, but like, how about Markdown? That's fine with me. I don't care. Really? I love a PDF data sheet actually. Why? What about it? I mean, like it's, I don't know. Because the data is like properly formatted on a page. Like when you load a markdown, it's like, I don't know, I'm just the side rant, but like, you know, I like take TI, for example, they've always taken such great care of making sure that like graphs line up on the page and stuff like that. That's kind of lost. Yeah, but that's done with like an intern and a word document. Yeah. I don't know. I'm, I'm all in school in that way. I guess so. I guess so. This is the great divide right here. Yeah. Yeah. Pick aside everyone. Pick aside. Well, I'd love if all the specs, the actual number parts were in some structured format that was shared across the industry. That would be awesome. For sure. So that the AI can ingest it easier. Please offer a full format, PBS for humans and something else for everyone else. Yeah. One thing that's been noticed, the absent from our conversation here is kind of like the, you know, Matt kind of got into this a little bit, but like the making of things, right? So like the, we're talking about the testing of things, but also like the hardware side. I personally still haven't touched it. This might just be, you know, what I'm been working on and things like it, but like the, you know, I don't, I don't particularly want to give up that side of it yet. I'm sure there is, there is surely a time down the line where that's coming, right? But like maybe people started listening to the show and they're like, well, what about all the various CAD tools and things like it? Like what about that side of things? I'm extremely, well, I know that in the long term, I'll eat my words on this, but I'm super bearish about AI for specifically for hardware design, especially layout. I think there are useful pieces that could be used for like DRC or. like creating certain parts of the schematic, but I very much view those things as an art form where there's not like one particular way to do something, but like it comes down to like your preference in the way that you like to have something done. And like it's just like when I see these layouts from like the AI tools, it's like nails on a chalkboard. Like I, and now it's even hard to know like in social media, people are just posting it for like rage bait or like just to get engagement by like trolling people, but like I saw on LinkedIn a board that like was designed by AI and the circuit was wrong. The USB connector was facing internal to the board instead of external and like the LED was, I think that that was rage made, but like, like no, just no. - Yeah, I don't think any job is actually secure in this way. Like don't get me wrong, you know. But like we've been talking about here too, it's like the, what is the happiest path for an LLM right now? It's like it's not been training on that stuff yet. So, okay, fine. - But like solve all the other problems and I'll gladly do a PCB layout manually. - Yeah, just be there for the foreseeable future. - Click the traces. - Yeah, yeah. - If you can just take away all the other stuff that I have to deal with on a daily basis to make more time for that, that's perfect to me. - I was talking to a younger engineer the other day and we were talking about like design and you know, he's interested in like doing more design and trying to find that kind of stuff. And it's like, man, it's so little of the, not so little, but it depending on what kind of role you have, you know, it might be 10% of your time, right? Like the fun stuff might be 10% of your time and the 90% is the everything else and what you guys are talking about is potentially the everything else being LLM enabled. It's like, take it, take it, take it. - Right. - You know, I don't want it. - Yeah. - But there's also value there too, you know. If an AI wants to go and stub out like this whole like complicated but very reproducible DDR interface or you know, something along those lines where it's just not conducive to human brain but then like leave the analog schematic to like a human, leave the layout of like power mats and stuff like that to a human like do everything else first. Don't touch that, that's my, that's my opinion. - It'll be coming. I mean, the process of schematics and layout, you know, I can take my, my head design rules that I kind of use and dump them onto something. And if I can do that, then eventually they'll be able to be applied by AI. But so far, for me, the hardware side of things are actually doing schematic capture and layout. Percentage wise is just so much smaller than everything else that's on my plate. It's not, you know, optimizing 100% means I still have 98% of my work to do. So I haven't even really tried the hardware. It's also kind of where I am in this current design cycle. A lot of the hardware was, you know, mostly, you know, air quotes done last year or so before things really started picking up with cloud code. So I really haven't had as an opportunity to even want to apply it other than, you know, minor fixes which, you know, are so fast that doesn't matter. But have had a lot of time with gate ware, so a varialog with, you know, hooko TV with the test bench side of that with firmware, software, and all of that. It's dramatically accelerated. What was the test bench again? The cocoa TV? Coco TV. Yeah, it's a Python. It's a Python based way of writing unit test test benches for a varialog code. Oh, cool. OK. And that you have been using to help construct test benches and stuff. Oh, yeah. Yeah. OK, crank out unit tests like no tomorrow. So way more-- so I tend not to write enough unit tests because they just take long time to go through everything. And I say, you can kind of look at your code and say, I think all this needs to be covered. And the LOM will just go and bang out tests that, you know, they're at least there. And then you can inspect them and see if you think it's covering the right thing. They will make it so to pass. Passing unit test doesn't mean it's working. It just means the unit test passes, right? So it's up to you as the engineer still to be responsible for saying, yep, that looks right or no, that's a false positive or false pass. And it's actually-- and I've had this happen where it will make the test pass, but the actual design is flawed. So it's up to you still as the engineer to know what's right or provide that full hardware and the loop feedback loop so it can figure it out on its own. Yeah. Kind of like I was referred to like eating your vegetables, like doing test benches and stuff like that. It's something that's healthy to do, but not something that like gives you like tremendous satisfaction a lot of time. So AI can eat the vegetables. You should eat your vegetables, Luke. Come on, man. Fiber. Fiber's-- we're not spring chickens, guys. Yeah, it's very-- One other thing on the AI design hardware thing, let's say that you said design medical electronics and they were extremely complex systems. And you'd be in an EMC chamber debugging something that would be a total mystery as to what's going on because it's such a complex system. But when you spend time embedded in the layout or you spend time just staring at the schematic and bumping those traces around and organizing them, it's soaking into your brain how this thing works and you're developing a mental model for how it'll work. That knowledge is extremely valuable when you're in those hardcore debug sessions where you get confronted with those issues that are just super hard to resolve. So if you just depend on AI to generate those things, you won't have that context to be able to debug those issues nearly as much. That's a great point. Traditional in that way. Well, I mean, how do people that are younger listeners, how do they go and develop that sort of thing? In this age of AI as well, where people are getting pushed to do this at the work as well, how do they go and develop the intuition? That feels like one of the struggles of the future of just like when it's the 2am problem you're at the bench, you're like, what the hell is actually happening? Like sometimes actually going back to the physics is the answer, right? And if you don't have that tie back and that mental model, I don't know, man. I mean, fully delegating your thought process to AI is not going to be a winning strategy, right? So we have to have value to add. And it gets really easy. Oh, AI, I just go do this, right? And if you're not diligent about staying on top of things, about being responsible for your designs, then you're only going to be as good as the current AI model, right? Which means you replace it. Exactly. You're going to be replaced by the next version of OpenClaw or whatever. I don't have a lot of great advice, but as far as learning skills, it's so different now just because there's so many things that are almost free, that are cheap, that are easy just have an LLM do. Building skills in those is very valuable because you need to be able to know when it goes wrong and correct things. But actually spending the time to develop those skills is harder and harder because it's not really what you're being asked to do as a new engineer. That training time is just not the same as what it once was. I mean, I still build Julescope prototypes by hand, just one. And it takes the better part of a day to build a Julescope by hand. But in doing that, you know where everything is. And that's a huge benefit towards debugging, just like what Luke was saying. But those type of exercises are going to get harder and harder to justify as far as your time. So the future of fully understanding things, if you're working in backend and front end servers with load balancers, you don't know what's going on anyway. So maybe it's just because I'm in the embedded space that I still cling on to trying to make sure I know what's happening. I find as well for understanding how to even guide stuff. So again, just to go back to my one example of this documentation builder, I only knew to guide it because I had built other websites. I was using Cloudflare primitives on stuff. Like the other reason I knew that is because of other stuff I'd built. And it turned out as my coworker told me that even that stuff was overloaded and too much, it should have been simpler than that. So like having all of these, you have to kind of know the universe of problems. And then you have to be able to pick and choose successfully from there. And that's to be effective to construct a solution let alone to the debugger solution. Right? It's like those things are very different skill sets on their own as well. Well, you have like fundamental knowledge. And then you have like, I don't know what to call it, but like understanding the minutia of like how Cloudflare works is kind of like a synthetic knowledge. It's a meetup, you know, whatever that's not bounded to physics or anything. It's just a context that they do. It's a traditional knowledge almost, right? It's like, yeah, versus like, oh, it's a law that is the law, right? So you have to have that fundamental knowledge from the Gekko and how you learn that with just constructing a simple circuit or whatever is timeless, I believe. There are certain fundamentals that matter even in the world of AI, no matter what always I feel. Yeah. Yeah, it's almost like advising younger people to just be like, push back on their boss, be like, I just need to build stuff to so I know more. Yeah, it's like, I need to be building stuff in order to not get stuck with crap. You know, like, all right, maybe I'll have to use my, you know, some tooling 20, 30% of my time, but like, make sure that's effective by letting me build the stuff the rest of the time, right? It's like, yeah. Yeah, it's therapeutic. You still have to care for that side of your thinking. Yeah. You still have to dedicate time to learning whatever that form of learning ends up being, but it's not just driving an LLM. Right. You can't just listen to the amp hour, folks. You have to also solder while you listen to the amp hour. Right? I've done that many times. Many, many times. Yeah. Well, what else should people know before we go? I mean, like, what are the things that you guys are, the things that are missing from your workflow currently that you're like, I need to do this. I need to do XYZ. Like Luke, I remember you said you're doing some vision stuff, maybe. Yeah. Yeah. One of the things about scaling, manufacturing is that very quickly, you need a lot of inspection machines. So, like, in a, in a perfect SMT world, you'd have three inspection machines, one after solder paste printing, one after placement before parts go into the oven, and then one afterwards to know that they baked out right. So, like, in each machine is quite expensive, but we're doing some experiments to mount a camera to a six-daw for robot and have that, that do. First, we're doing post placement inspection. And that's still really early. Like, unfortunately, I haven't had much time to work on it, but it's a key area where it's like, if I could have that capability in-house instead of purchasing it, it would allow me to scale my manufacturing much better and have us have much better quality. Because right now, we just don't have that capability because we didn't invest in that machine yet. So, that's something I'm looking at, but I don't really have a lot of knowledge to share about it. Yeah. Well, in the six degrees of freedom robot, as well, is not like, that's not a standard thing from the things you can buy off the shelf either, right? I mean, that's usually it's like a fixed camera multi-angle sort of thing, right? Or it's on like a Cartesian XY. Yeah, right. Maybe Z-type gantry, but being six-daw allows you to get multiple perspectives to do some quasi-3D things. Like, what's the old sort of thing, almost? Right. Even if you could just look at the side of a part sometimes, that's important. Even if it's just a 2D image, like getting that oblique view of it to see the pins would be helpful for inspection. So, yeah, I'm really excited about that, but again, we haven't gone through all the steps to do that yet. Perhaps some enterprising listener will write into you. We'll be contacted for a dinner. Yeah. What about you Matt? So, for me, the next thing, I have an agent computer that has hardware in the loop now with my Julescope JS320, and it's been running, but I am still babysitting it. So, the goal is to get away from the babysitting. I did not, you know, I kind of played with Cloud Code or with OpenClaw briefly, but I want to figure out a solution that requires less babysitting that is not dangerously running with scissors either, which came up in one of our chairs. You guys did keep using that terminology running with scissors. I really like that. I was using that after we, after I heard that from you guys, because you were explaining with that is real quick on the running list. So, with Cloud Code, it's dangerously disabled all permissions or whatever the flag is. Basically, Cloud could do whatever it feels like, and there's no security. Yeah. I would love to have the auto mode come to the normal subscription plans. So, it sounds like they're still trying to make it work well enough before they deploy it, but it's basically another layer of the other LLM inspecting the output of what the first LLM is saying to do to your system so that you're, it's essentially gauging the security of this command that is about to be issued rather than me sitting there in the loop just saying, okay, it looks good, said good. I thought I enabled all SEDs. Come on. What about Grab? I enabled all those too. So, that's the frustrating part right now about security. So, getting that agent thing running, and then the second thing that I have is I have a bunch of machines, Windows, Mac OS Linux, ARM, and X86, 64, all variants for doing Juleskope UI testing. I would love to have that fully automated so that when I push up get commit, it will go and dispatch to all of those automatically run run unit tests. And if there are any issues look into them, you know, figure out what's going on, triage if necessary, if it knows enough, or at minimum, just write an issue that we then can work from. So, that's the next thing on my list. Yeah, that should be relatively approachable with code work actually. Well, yeah, TACO, Matt, too, is like, Quad Code. It has this mode where it asks permission for like everything, and it's really frustrating, and there's like memes about like making custom keyboards that just have this one button that you press over and over again to like permit it. So, like, hopefully that gets resolved soon, because that's one of the most maddening things about it. We actually didn't talk much about local models or like the difference in different models, which is a huge topic, probably a separate podcast. And then, yeah, just like the alphabet soup of all, it changes so every day, there's a new model, there's a new optimization of a model that you can run locally, but in the end, like, five years from now, I assume that we're all going to be running pretty capable local models on some pretty beefy hardware that that's going to be a big, big thing in the future. Going to the cloud is cumbersome. But we're not trying. Yeah, I've been trying, and my, my open client's instance, I had like the new Gemma 4 on there. That's the Google one that had like that reduction, 6X reduction. And it's still, it's like the expectation is like, this is how I figured out that my open client's instance was sending 13,000 tokens every time I said hi, it was sending 13,000 tokens. And when you have a thing that outputs like, you know, even 100 tokens a second, or that digested like that, it's just like, you know, it's very very slow. Your perception changes on like how fast the model is when you want to take seven tokens together. Right. It makes me realize how much energy is being spent on the internet, the cloud side of things. It's, yeah, we'll see. We'll see how that goes. I've tried and, you know, having my open client agent use Gemini Flash now, and you could definitely see a step down in the intelligence of it, but it's still able to do some tasks. So like, now I'm switching to a hybrid model where like, I use cloud like a state of the art model to do like script development and skill development. But then I try to have it make skills that the less capable models can operate just to control like the those operational costs like you're talking about. Right. Right. Yeah, I do think we're heading into an era of, not an era, but like a slight flattening of the, you know, it's no longer Moore's law, but whatever it is, it's, you know, I think we're reaching some power limits. And obviously some scaling limits thanks to the DRAM makers and this cost DRAM. And so it's like, okay, well, now I might get a little bit more efficient, and that's good for costs and one thing to energy up. Incredible. There's this company called Talis. I don't know if you've seen this before. They've basically baked older models into ROM instead of using RAM. And then they're able to access them like super fast and yes, all on chip. And so they can run like a Lama 3 AI model at like 2000 tokens per second or something. So and that's like a, it's like a four nanometer chip or it's in that way like deep sub-micron space. So like, if anyone was to ever make a custom chip that had like Opus 4.6 in it fit on one or 10 chips, oh my gosh, I would, I would, I would buy one of those for sure. We're heading on it's plan just come on. What are you even doing? Yeah. All right, guys, where can people find you reach out to you, get in touch, ask you more about your experiments? So for me, I'm on LinkedIn, Matt Liberty. And julescope.com, jou.joul.com, scope. And it's Matt Liberty, all one word at LinkedIn.com. Feel free to reach out, love to chat more about AI or power consumption. Yeah. And Luke Bino at LinkedIn as well. And best website is where wolf.us and specifically, guys can check out. And I think a lot of engineers would find our new product be flexed very useful. Basically get any output voltage from a USB-C power supply in any, any adapter cable that you need. We, we have on our site. It's really handy, especially in the lab. I can also link in the, I think Mr. Jeff Girling has been using some of those. Yeah, secret preachers, but I saw a recent one. Words problem, not the cables problem. I know that. Highly encouraged blowing upwards. Yep, exactly. All right, guys, well, hey, thanks for thanks for coming here and talking about this stuff. I'm sure we'll have more to talk about in the very near future. Appreciate being here. Yeah, thank you. Thanks for having me on the show. (upbeat music)