[0:00] Judy Warner (Intro) Hi everyone, it's Judy Warner. Welcome back to this week's EEcosystem Podcast. Today's guest is Sergiy Nesterenko, the founder of Quilter, which is an AI PCB design tool. We talk about the AI hype and where we really are in the real world, as Sergiy and his team have worked with real-world, tier-one enterprise hardware engineering teams across the country. We're going to dig into the forward motion that they've made and where we are with a very real-world approach that keeps you, the designer, in the loop. Now, let's jump into our conversation with Sergiy Nesterenko of Quilter. [0:41] Judy Warner Hi Sergiy. Thanks so much for joining me again today. It's been several months, and I'm looking forward to catching up with you and learning where Quilter's been over the last nine months or so. [0:57] Sergiy Yeah, thank you for having me, Judy. Appreciate being here. [1:00] Judy Warner Yeah, well, as a refresher — last time we talked, we talked a lot about how your vision for Quilter was shaped during your time at SpaceX, and the idea of first principles — kind of questioning the foundations of what you're building and how that informed you as you stood up Quilter. One of the things that really stuck with me is you were talking about how engineers are so cynical about AI, and what it means — and honestly, we don't fully know yet. I'm curious to lean back into the conversation we'd started last time, about what parts you're really trying to solve for and which parts you aren't. You had told me before that what you want to do is leave the engineer in the driver's seat for design intent and architecture, but leave a lot of the tedious implementation part up to AI. So let's dig into that — sort of the ways you've kicked the ball further down the field since we last spoke, realizing that vision. [2:22] Sergiy Yeah, yeah, thank you for the question. I think there are two things to mention here. One is what Quilter is tackling in the general workflow of designing circuit boards, and two, how we keep the engineer in the driver's seat for even what we do tackle. To be clear for the audience who maybe didn't join us for the last discussion — Quilter is focused explicitly on the layout problem for circuit board design. We come in when a designer has already completed their schematic, and we assume the schematic to be true and good. We focus on your stackup, how we place components, how we help you floor-plan, how we route, how we generate polygons — all those sorts of things — and then how we validate and check that the layout will actually perform and do what the schematic intended. Then we leave you off there — you go back into your CAD system, run whatever additional checks you'd like, submit to fab, and everything else is out of our hands at that point. Now, layout is a huge problem. It's not at the point where you give your layout to a magic box, it spits out a perfect answer, and you stop reviewing — that's very much not the case. So there's still a discussion of where we focus and how we work with designers. We focus on a medium complexity of boards at this point — typically boards that take humans one to three weeks to design by hand. That's usually on the order of two, three, four, five hundred components, maybe up to two or three thousand pins — that tends to be our sweet spot, where we can really help people go faster. If it's much simpler — say, two connectors and a few traces — there's not much we can do. And if it's much more complex, like a phased-array antenna for a satellite, we can't help there either. But in that middle point, we might be helpful. What we've focused on is retaining control with you while giving you leverage. Over the last nine months or so, we've been shipping features along those lines — in particular, features where, using a combination of the inputs you already have in your CAD system and the inputs you now have as part of Quilter's interface, you express constraints. As a designer, you might still be in control of the floor plan — here are the rooms where I want components to go, here are certain pre-placed components, here are certain critical subcircuits I want to route myself. Now, Quilter, please do the rest while respecting my DRC rules, respecting high-current design, respecting good placement and routing for switching converters, and so on. We've been really leaning into the idea that you, as the designer, set the constraints, and we try to meet them. We're very explicit about which constraints we're aware of, which we've met, and which we've tried to meet but didn't — and we encourage the user to iterate: how can I help Quilter meet the constraints it failed to figure out on its own? That iteration process is where we've been spending our time. [5:25] Judy Warner So — because I'm on LinkedIn, and my former colleague Ben Jordan is at Quilter — some time ago I saw that he'd done a video walking through what that workflow was like. Was that built around a particular capability, Sergiy, or showing the full stack of what you've built? Can you give me some context on that, and on anything specific you've gotten further along on since we last spoke? [6:19] Sergiy Yeah, terrific. At a high level, there are two sides we come at this from. One is a high-level question: what should an automation system for layout look like as a North Star? The second is more practical: where are we and our customers struggling, and what tools can we give them? The two are some distance apart, but we're trying to squeeze them closer together. As a principle for how the North Star should look — how should an automated system that helps you with layout behave? As a precedent, we can take the existing conversation that already happens between a schematics designer and a professional layout designer. That conversation happens inside every company; it's sometimes outsourced, sometimes handled by a professional PCB team, which you know well. If you act as a fly on the wall listening to that conversation, you see the two parties in front of a computer, pointing at the screen, saying "keep these things far apart, put these things close, rotate that, follow the data sheet here," and so on. Ideally, Quilter would feel like that — a rigorous version of that conversation that quantifies the discussion and then enforces it as you route. We don't believe in just talking to a chatbot — Quilter, as you know, is not an LLM. We need something more rigorous, something where we can quantify where a component can go, how it can rotate, what side it can be on, what specific objective functions it's trying to optimize, and so on — but it should still resemble that dialogue a PCB designer has with a schematics designer. The other part is the reality of where we're at. Ideally we'd take all this information immediately from the CAD system and just solve it — but unfortunately, the CAD systems of today, whether Altium, Cadence, Expedition, KiCad, or others, only implement a fraction of what's truly in the designer's head. There's typically a complete rules system that says these nets should be this far apart and this thick — but there's no DRC for a good switching-converter setup, no DRC for a great RF layout, no DRC for how to properly route a FET or an op-amp. The additional context we add in our interface is trying to fill in those gaps. So realistically, we've focused a lot on our own experience and our customers' experience in providing the features we need. Our own experience — we've been public about this for a while — comes from building a new board we used to dogfood Quilter on ourselves. For the audience who hasn't seen this: it's a full NXP i.MX8 computer design that we had Quilter do the layout for, with human assistance, that we then booted and brought up Linux on. There's lots of information if you search for "Project Speedrun" online. A lot of what we learned from this shaped what we built. For example, this board has a couple of BGAs on it — so we needed BGA fan-out, which is something we shipped recently. This board also had a lot of length matching, which we're getting close to shipping for the general public. And it needed variable clearances between different components and nets, which we didn't have the capability for a year ago but have now shipped. So those are the kinds of things we ourselves wished we had control over — and our customers have been telling us they wish they had that control too, which is why we've been adding it. [10:03] Judy Warner Very cool. Well, I've told you this before, Sergiy — but one thing I appreciate about what Quilter is doing is being very transparent about what you are and aren't doing, and stopping with the marketing AI hype. Everybody, including me, is so tired of it — engineers especially, it's an instant eye-roll. So I appreciate that you're saying what you can do, what you can't, and what you're moving toward. I also like that you're working with actual designers who are helping you define where some of those gaps are, across every kind of vertical application. So what are some things you've discovered together — collaborating with real hardware engineers — that really helped move the needle and fill in some of those gaps? [11:13] Sergiy Yeah, I think there are a couple of interesting things here. First, engineers in the field today do not want full automation — they're not asking for it. They want control so they can hand things over at their own pace. So the vast majority of questions we get are around: how can I constrain this? How can I assert this constraint? Can I make my own custom constraints or custom reward functions? These are all valid — they're an expression of the fact that automation isn't ready to fully hold the steering wheel. To be a useful tool, the engineer has to be able to point the steering wheel in the right direction, and we're fully supportive of that. The second interesting thing is that this is ultimately an exercise in building trust. I'm thinking of a particular customer we're working with — different organizations adopt tools and earn trust at different paces, and that's totally fine; we're in it for the long haul. With this one company, I was a little surprised recently, though in retrospect maybe I shouldn't have been. We took a lot of time to do a proof of concept, demonstrate that it works, convince the PCB designers it's there to aid them, and get them to learn the tool. Now they're excited and going a lot faster — they've fabbed boards and are happy with the performance. But what's interesting is that now there's a next level of trust to build: the PCB designer's customer. The PCB designer ultimately hands the board to whoever requested it, and that person says, "Wait — I didn't design this, you did, but you used AI. How do I know it's going to be reliable long-term? How do I know it's designed well? How do I know you're not just being sloppy?" Which is fascinating, because the person driving the tool isn't ultimately the end customer — you have to earn trust all the way down the stack. It's a new kind of problem for us: we've convinced the person doing the work, now how do we convince the next person behind them? [13:22] Judy Warner That really is fascinating. And I'm wondering — thinking of high-reliability or mission/health-critical applications, where people are like, "whoa, whoa, whoa, what do you mean?" — how do you build confidence with that end user? They're used to things they understand more, like industry standards, ISO, or MIL standards. I assume those are baked in, but how do you make that case? [14:06] Sergiy Yeah, I think there's a preceding ladder to earning this trust over time. The first thing is: when we start with customers, we don't start on the board that's going to be mass-produced and shipped into the main product. Point one is to start somewhere you're a little more risk-tolerant — typically R&D, where you're validating a subcircuit or some part. Those applications are great because you can take a little risk, see it work, gain confidence, and build from there. Thing number two: we always ask customers to state clearly what their objective is and what metric they're using to measure whether Quilter is successful. Invariably it's some version of "can we go faster" — can we take a two- or three-week board and turn it into a one-week board? Great goal, big impact for the business, totally achievable within the right parameters. None of them are relaxing their standards — nobody says "I want it faster but with less quality." It's assumed that quality holds. We've had people tell us proudly, "We have a 95% reliability rate on our boards — we cannot afford that to go down." So your Rev 1 success needs to be as high as that. What that means is the designer stays in control — they're still applying the same standards, setting up the same DRC rules, reviewing the circuit the way they would have, being very careful, and budgeting real time for setup and review. But I don't think that's going to be enough by itself for a while. I had an interesting discussion with some folks I'm recruiting out of the self-driving car industry, because they've learned a lot of lessons — both technical and philosophical. One of the big lessons from self-driving cars is that it's not enough to be as good as humans — not even close — because if a self-driving car that's as reliable as a human crashes, it's news. So it has to be much better than humans. Quilter is not designing boards better than humans — not even close. So the final piece we're focused on is: maybe we can't design as well as you, but we can probably validate more than you typically do. On a lot of boards, people don't actually pull up a full-wave simulation and get S-parameters for crosstalk, or measure IR drop and PDN stability. On important boards, of course, people do — but especially on test boards, if you're a confident designer, you look at it and say "this is good" and move on. So if we can provide those validation tools and make them a trivial byproduct of the job you've already run, then even if you're getting a design that's okay — maybe even a bit worse than what you'd have put together — once you as a human come into the loop and contribute, you can use a much higher bar to verify the automated part. That's kind of where we're headed: a higher bar for something new, but with a correspondingly higher bar of verification. [17:48] Judy Warner That makes total sense to me. And again, you're still leaving the designer in the verification seat, just giving them better and deeper ways to verify — against more things than they would have before, for a prototype they know they might spin again anyway. So communicating that in a way that satisfies the lawyers and everybody else — I can see why that'd be a challenge. Very similar to self-driving cars, actually — they can now demonstrate they're more reliable than human drivers, and that's where they're finally getting traction. Let's talk a little more about that verification layer PCB designers haven't had before — but first, mostly for our audience, I wanted to talk about how Quilter is different from other AI PCB companies imagining this workflow differently. What sets you apart? [19:07] Sergiy Sure. I'm very grateful and happy to see there are a lot of new companies in this space. When I started the company in 2019, there really weren't many startups tackling anything in PCB design — we looked to the big established companies to innovate, and there wasn't this kind of ecosystem. Now that there is, a rising tide lifts all boats — it's fantastic. It inspires companies to look at what's out there, and most of the customers I talk to now are also talking to a lot of startups about what's happening in the space. It's never been a better time to be a PCB designer. I bucket the startup ecosystem of PCB design into three major buckets in my head. One bucket is parts and libraries — large language models are quite good at reading data sheets and extracting and summarizing information. They create a nicely searchable index and are good at proximity or similarity between language-based information. So instead of going to DigiKey and scrolling through thousands of possibilities reading data sheets one by one, you can now go to a handful of startups, type in what you're looking for, and get good data sheets close to your requirements. We even see this applied in firmware — people pointing an LLM, even Claude directly, at a data sheet and saying, "write me the firmware to write to these registers and access this functionality." The second bucket where LLMs have made an impact is the schematic side — companies reimagining how to make design entry or schematic capture go faster, maybe expressing it as a hardware description language or code, the way we do in FPGAs and ASICs, but for a PCB schematic. There are companies generating schematics from architecture diagrams and so on — fantastic stuff, though not what Quilter does. Then there's a few of us focused on layout — the geometry and routing, how components connect, how to physically validate the whole thing. This is where, unfortunately, LLMs aren't helpful in my opinion. You need a ground-up approach — your own systems, your own CAD kernel, your own models for predicting what to do, your own physics verification, or off-the-shelf tools where possible. There are fewer players here, primarily because it's really hard — not low-hanging fruit. It takes substantial capital, time, and patience, and you don't get the benefit of the tens or hundreds of billions that have gone into training great LLMs. We sit squarely in that bucket, and of the companies tackling it, I think we're the most forward about being constraints- and physics-based — really trying to understand not just how a human would do this layout, but what physics rules govern whether the layout actually does what the schematic intended. If we can quantify that, we can treat it as a constraint optimization problem and solve it. That's resonated with a lot of our customers — the long-term agreement that this is a quantifiable, physics-driven problem, and that AI can help solve it more quickly, but it's not the crux. The crux is the physics. [23:07] Judy Warner Which makes perfect sense to me. Along those lines — I'd heard through the grapevine that Quilter's been working with Yuri Slepnev, integrating some of the interesting AI work he's doing on the signal integrity side. One thing I've always respected about Yuri and Sim­beor is that it's also physics-based, and disciplined in how it's written. Tell us about the interesting things Quilter can do by putting Simbeor in the loop — maybe as an additional layer for signal integrity. [24:15] Sergiy Yeah, for sure. Simbeor is a terrific tool — Yuri is a fantastic person in this industry, and we look up to him and what he's built quite a bit. Simbeor is a lot more powerful than what we've asked of it so far — hopefully we'll stretch its capabilities someday, but the papers and verification Yuri publishes, up to very high frequencies with lots of detail, go well beyond anything Quilter is currently asking it to do. Which is great, because we can rely on a well-known industry-standard tool and just trust it's been done right. The first thing we did with Simbeor was a pre-layout step: calculating impedance profiles for differential pairs and single-ended nets — a fairly straightforward but still real 2D field solve, where you take a cross-section of the traces, figure out your ground planes and target characteristic impedance, and get the sizing and separation of pairs or single-ended traces. Good first step — it let us build Simbeor into the loop and figure out the logistics, licensing, and runtime. The next thing we're working on is computing the propagation delay of a via in the path of a critical trace. That matters because we're almost ready to release length-matching features, but without that we can't compute propagation delay when we insert a via — and without it, we can't guarantee good length matching, or we'd have to limit it to a single layer. Once that's live, it unblocks length matching. Beyond that, we're aiming to set certain nets on which we want to extract S-parameters — a general way to capture signal integrity as well as crosstalk queries. Using Simbeor under the hood, we can track an insertion port, a load port, a potential crosstalk victim, across multiple sets of pins, and as we generate candidates, verify whether those S-parameters meet requirements within a certain frequency band — and eventually close the loop and optimize for that. That's probably the next step. After that, probably power — starting with IR drop and resistance for arbitrary shapes, then eventually more serious PDN analysis. [27:19] Judy Warner PDN especially is so important right now, so I can see why you'd want to tackle that. Okay, so it's early days for Simbeor, but lots of room to grow — which is great. And again, I appreciate the discipline and physics-based intelligence Yuri's built; he's very intentionally building a context-based model for SI. I'm interested to see how your tools interact as you get further down the road. You'd also mentioned BGA fan-out — have you released that yet? [27:58] Sergiy Yep, that's live. [28:01] Judy Warner Okay, tell us about that feature. [28:01] Sergiy Yeah — it's very interesting, a lot of people think the physics verification side is the hard problem Quilter solves, and that's actually not the case. As electrical engineers, we've known how to simulate most questions about circuit boards for a long time — it's a matter of gathering the right information, setting up the simulation, running it, validating convergence, and quantifying against your constraints. That's a lot of work, and often we don't have time — but it's not an unknown unknown; it's a known process many suppliers and experts already support. Where Quilter — and really all automation efforts in routing — actually struggle is dealing with the density of boards we have to deal with. It turns out the hardest part is essentially a bin-packing and noodle-packing problem: place and route. If you set standard constraints — trace width, spacing, board size — and ask a machine to connect everything to 100% without violating DRC rules, that's the unsolved problem. Humans are still better at that than machines, and nobody's built an algorithm that does it as well as a human — surprising, since you'd think computers would be good at geometry. But it turns out we give ourselves too little credit for how good we are at spatial reasoning — we've evolved in this spatial world and gotten really good at planning and squeezing things down. One place density gets tricky is BGAs — if you naively start routing from a BGA, you'll inevitably block off pins and won't complete the board. You need a strategy for that dense grid, and any professional designer has worked through this: start in a section, pick a strategy, land on the right compromises around blind/buried vias, microvias, via-in-pad, whatever's needed, and go with it once the cost-benefit makes sense. We've effectively taken that as a piece Quilter focuses on and solves independently — it doesn't even have to be a chip; a lot of our customers have super-dense connectors, maybe 5-by-40 pins in a regular grid, with the same fan-out problem. We've built algorithms specifically for those sections, which combine with the rest of Quilter to independently tackle what's happening inside the dense area and how to break out of it, combined with the rest of the board's routing. This came directly from customer feedback — it was one of the top one or two things we heard consistently, regardless of application, whether wearables, networking, or aerospace. There are almost always BGA chips now for one purpose or another. [31:27] Judy Warner Yeah, and some of them are absolutely crazy. [31:31] Sergiy Yeah, I saw Intel's next-gen is going to be almost 10,000 pins on a single chip. [31:39] Judy Warner I'd heard something about 1,500 pins and my mouth was already open — 10,000? [31:44] Sergiy Yeah, somebody please correct me if I'm wrong, but I thought I saw something on LinkedIn about the next gen being like 9,500 pins or so. That's wild. [31:52] Judy Warner Data centers are getting nuts, that's for sure. [31:56] Sergiy They're getting nuts. [31:56] Judy Warner And so it is interesting times, as you said. And anybody who says "I've solved everything for layout" — I don't want to hear it. That's why I talk to you, Sergiy — because I think you're doing real things with real hardware engineers and moving it down the road, not just "we're going to write an LLM and it'll lay out a board for you." I appreciate that. One thing I've heard whenever I post something on social media about AI — interviewing someone about AI and a schematic tool, say — is people coming back with, "yeah, after I spend three years cleaning up my data," or "it's all in the cloud, and we're building missiles — shut up." How do you address that kind of pushback and skepticism? [33:08] Sergiy Yeah, let's tackle the second one first — data security — then we'll come back to training data. On security, we actually have a very straightforward story: we'll simply let you deploy Quilter on-premises, behind your firewall, with no internet access. Just like any piece of software your company might procure — Teams, Slack, Confluence, whatever — your IT team reviews the software, downloads the raw ingredients needed to run it on their servers, runs security vulnerability scans, deploys it internally, air-gaps it so no information can leave, and supports it. This is very standard. I come from SpaceX, which is beholden to ITAR — we did this a lot there. We've since seen it with aerospace companies, medical device companies, and secretive consumer companies too — it's a pretty standard request. So from your perspective, Quilter is a standard piece of software your IT team sets up on your servers, firewalled with no outside access — you give it your boards, and it all stays completely contained. It takes real work, but we've done it, and we know how. [34:45] Judy Warner Oh, that's very cool — that's a really good answer. [34:48] Sergiy Yeah, for sure. I knew from day one this was going to be important — I can't take a guidance system for a rocket and throw it into some online tool and hope for the best. If there's anything SpaceX taught consistently, it's that. [35:04] Judy Warner Yeah, the fear of it is strong with me, that's for sure. [35:12] Sergiy [laughs] There's a meme in there somewhere. Anybody who's worked in aerospace does training on a monthly basis, and they flash really scary things at you — you're going to go to jail for five years, pay millions in fines. It's like, okay, I will pay attention to this training. [35:31] Judy Warner No, I worked at a PCB shop once, and we had lots of locked doors, IT locked down — it's a serious deal. Fun story — this company I worked with made a 42-inch-diameter antenna, for Skunk Works or something, and wanted to show off the accuracy and low drift it could achieve. So I said, "we need to market that capability" — and they made a mockup board, similar but with all the geometries changed. I took a picture, said "hey marketing, let's put this out there" — and I got a call: "you're going to go to jail, total cease and desist." I said "but we changed this" — they said "we don't care, it's too close, take it down." We said okay, sorry. So I relate, at least in part, to what you're saying — and it is important that we protect these things. Okay, so that answers the on-prem and security piece. What about the fact that a lot of AI companies want to take all your data — "clean up your data and then we'll help you" — and if you've been in business for any length of time, your data is not clean, and cleaning it up is too big a task. What do you say to that? [37:32] Sergiy Yeah, that's not important for us — we don't use almost any of the data on your servers. The most naive version of how people think Quilter might work is that you show it a bunch of human examples of boards and, like a typical neural network, it blindly copies whatever humans do. That's not at all how Quilter works — we fundamentally don't believe in that approach. You could reasonably train a neural network to look at how people do layout and just copy it, but I think that's a bad idea, for the same reason a human shouldn't just copy a data sheet or someone else's layout without understanding it — you should know the physics, you should do the math. So Quilter isn't trained to copy blindly — it's trained to do the math, to obey the physics. The way you train it is you give it puzzles: here's a small board with some constraints and physical rules to solve — go try to solve it. It doesn't do well at first, gets feedback, tries again and again, and by process of trying a lot, it gets better and better. You take that experience, in the form of a model, and deploy it with the customer. The customer isn't expected to train on their boards — in fact, we do zero training on the customer side, specifically because we don't want to train on your board and take that model with us; that would violate IP isolation. What we actually do is collect a data set from our free users — people are welcome to use Quilter for free, with the constraint that we can anonymize their data, chop it up, and build synthetic puzzles out of it to help Quilter get better. That doesn't work for an enterprise in almost all cases, but for a hobbyist, free user, or academic, sure — and we get a ton of those. We take pieces — a crystal here, a switching converter there, a microprocessor there — and use them to get better and better at these designs, then take that model with us. So the burden of training the model and cleaning up data is on us, to build the model in the first place. Once we arrive on-premises with you, your burden is only to give us the problem you want solved — the schematic, the layout — plus some entry work. We encourage customers to provide a floor plan, though not everyone knows how to use the rooms features in Altium, Cadence, or Expedition, so we'll ask you to do that. We also benefit from good schematic annotation — for example, I like to place directives on all my high-power nets, so I can just use a net class in Quilter and say "these nets need to be three amps." That's not typical, since designers usually just know which nets are high or low current — depends on the company. But there is some work we'll ask you to do, and it's only on the one design you're giving us, not your entire system of designs. [40:46] Judy Warner Right, right, right, right. I like that it bakes in the best of the design intent and architecture and optimizes what the designer does best, while giving it that physics-based, automated push that makes it faster. Well, you've come a long way since we last talked, and it's exciting. I always really appreciate listening to the way you think about this process. I'm not an engineer from SpaceX, but I appreciate the complexity of the problem — if it were easy to solve, somebody would have done it a long time ago. But the discipline, the physics-based approach, and getting input from real hardware engineers, just iterating and iterating — that seems like the right path to me, Sergiy. Well done, congratulations to you and your team. It's been fun watching you, and thank you for sharing with our audience all this forward momentum — there's a lot of noise in this space, but not a lot of good, solid information, and I appreciate that you always bring that to our conversation. Before I let you go, Sergiy — you mentioned the S-parameters piece. Is there anything else you're looking forward to with your team over the next six to twelve months? [42:20] Sergiy Yeah, I think pushing on the stuff we hope to get out of Simbeor is probably what I'm most excited about. We're physics-first, but we need more physics, so I'm very excited to get as much of that into Quilter as I can. Even if Quilter can't solve some of these problems itself, you'll soon be able to take a completed board and put it through Quilter to run physics verification on your own designs — an interesting side mission alongside the real mission of helping with automation. The other big thing we hear a lot about, that we don't support yet but are actively working on, is blind and buried vias and via-in-pad — huge demand, even for test boards or sparse boards, it comes up in so many conversations. In some sense it actually makes our problem a little easier, because it relaxes some routing constraints, and most customers are quite willing to pay for it because they have no choice — they have to use those features nowadays. So probably between really fleshing out the simulations we'll get from Simbeor, combined with blind and buried vias, over the next six months or so, you're going to see a lot of improvements in what Quilter can do. [43:45] Judy Warner Very good. Well, I browsed through an article your team wrote that was really thoughtful about auto-routers — everybody hates auto-routers, but I thought that was a compelling article, so I want to share that. Where else would you recommend our listeners tap in if they want to learn more? Specific areas on your website? Any shows or webinars coming up? [44:19] Sergiy Yeah, those are all good call-outs. We're doing a webinar with Sierra Circuits on Thursday — by the time this goes live it may already have happened, but go check it out. I think we'll be at DAC, so you can find us there. And for sure, people are welcome to go to quilter.ai and click "get started" — that'll either take you to the free version, where if you're a hobbyist or just want to play around, you can just go, you don't need my permission — or if you're an enterprise, there's a way to contact the team and talk more seriously about a demo and a pilot. And of course, by watching your channel, Judy — that's a great way to learn more. [44:58] Judy Warner Well, thank you, Sergiy. It's been another fantastic conversation — I learned so much from you, and I know our listeners do too. Appreciate your time, appreciate what you're doing, congratulations, and I look forward to talking to you again soon, my friend. [45:14] Sergiy All right, thank you, Judy. Appreciate it. [45:16] Judy Warner For listeners, I'll go put all those links — I'll load the Quilter demo and get all those links Sergiy mentioned, so you can dig in further. Thank you for joining us today on the EEcosystem. Make sure you stay connected to the EEcosystem — we'll see you next time. Until then, remember to always stay connected here to the EEcosystem Podcast.