T-25-010 : Ioannis Papamanoglou and Narayan Powderly - Engineers transforming how we design, test, and build hardware with atopile
We tried to build this internally at Tesla. We actually pitched this to our director, like, hey. It'd be really cool if we could have a little side team and
Chris:Well, we're gonna cut all this
Narayan:out. That's that's allowed. We talked to a lot of lawyers about it.
Nate:I trust you guys.
Chris:Nate, do you really want me to post?
Nate:I mean, that would be exciting. That meant I hit a career milestone.
Ioannis:That's funny.
Nate:I'm in. You're listening to TRADEOFFS, a podcast about the trials and tribulations of designing, building, and manufacturing hardware, and the people that make it. Each month, sit down with founders, engineers, and other hardware professionals to understand the unique trade offs inherent in building a business that makes physical products. I'm Nate Padgett, hardware community guy and founder of Informal, a freelance collective that helps companies of all sizes design, build, and ship world class hardware.
Chris:And I'm Chris Rill, startup founder, engineer, and fractional CTO, where I help hardware and software companies build and scale their products. TRADE OFFS captures the best of these conversations so you can learn about the numerous skill sets needed to successfully bring physical products to market. For this episode, Chris and
Nate:I sat down with the founders of Atapile, a command line circuit design tool that's getting a lot of attention since their launch back in 2023. Hope you enjoyed this conversation as much as we did. Thank you so much for joining. Really appreciate this. Why don't I kick things off?
Nate:I first got to know the Atapile team because they were members of Studio forty five, the hardware coworking space I run-in San Francisco. I think you guys were some of our first members when you got into Y Combinator. So I've kind of been able to see a couple evolutions of the business, which is really cool. But why don't you guys give an intro about each of you, your roles within Outapile, and then about Outapile itself.
Narayan:Sure thing. So my name is Narayan, one of the co founders. Co CEO is my current title, I suppose. So I'm Australian originally, half American. But yeah, I moved to The Bay five years ago.
Narayan:I got a job working at Tessa as an electrical engineer and been building stuff most of my life. Started with, I guess, Legos when I was two and been building stuff in the shed sort of ever since. I did, mechatronics engineering, then came over to Tesla as a intern actually. And then it was like 2020. COVID hit.
Narayan:It was kinda like in a weird spot, so I decided to stick around. My director offered me a full time job, so I've actually never graduated.
Nate:Wow. It's kind of a classic startup story. Drop out, go work for some badass company going really fast.
Narayan:Yeah. Definitely. Yeah. So I was I was at Tesla for a couple years, and one of the things that really struck me is I had in my head this picture of what it would be like to go work for one of these, like, big tech companies, like full speed all the time, shipping a bunch of stuff, building stuff faster than I ever had. And I found it really to be the opposite.
Narayan:Like, my hobby projects progressed much faster than these, like, big vehicle projects that we're working on. You know, it would take us, like, months and months to ship aboard and a long time to do all the testing and found myself pretty frustrated by that.
Chris:Elon wasn't in the design review meetings?
Narayan:I mean, he's frustrated by it too. Believe me. But, you know, I spent quite a lot of my time there building tools to make things go faster. I spent a lot of time making our test infrastructure a lot faster, things like that. And then, you know, just sort of found, like, there is this unpenetrable boundary once you got to the design of it's a piece of paper, like a a schematic.
Narayan:How can I automate this process? How do I tie this into my test system? How do I tie this into my requirements generation? There was just sort of this unpenetrable box, which is the core of your design. And that was how we got to the idea of why do we make this something that you can automate, you can, you know, apply these, like, modern software tooling to.
Narayan:Awesome. Yeah.
Nate:I was reading through the Hacker News launch that you guys had, and I thought that the commentary on there was really good. And Narayan, I thought your responses were really good. Like, you could see it in the way that people were replying to it. Anyway, I don't wanna get too ahead of ourselves. Jani, did you want to introduce yourself?
Ioannis:GREGORY Yeah. So I'm Greek, grew up in Germany, studied there, lived the last six years in The Netherlands. So just all over the place, but-
Nate:That's that accent.
Ioannis:Yeah, exactly. It's unidentifiable. But I was always like congenital to hardware, basically started out hacking around with consoles. I like this PlayStation portable that like to disassemble and just put LEDs in there and blow up my speakers because I connected big box speakers to the small drivers and stuff. And So it was just more like, I kind of find it fun, but I have no idea what's going kind of was more often to the software side of things.
Ioannis:Was programming little apps and this whole homebrew thing back on the PlayStation hiking scene. And from there on, Minecraft kind of got popular. And I found my love back for hardware stuff with redstone circuits Because it's such a nice abstraction level to think only about logic and things. So you have the same concept of modular things that kind of still interact as a big system because you have latency and everything involved. But you don't have to think about low level physical properties of electrical engineering.
Ioannis:But from then on, it was more always like the software side driving me. I was building Minecraft plugins. And from then on, I went to study computer science in Germany. Did my master's degree and I specialized in operating systems, kind of the lowest side of software you can be. And my first actual interfacing with hardware was when I started my first job at a smart mobility startup, where we were building smart bicycle locks for the Dutch government.
Ioannis:Dutch government owns like a 50% stake in the national railway provider, and they have 20,000 shareable bicycles because the bicycle infrastructure in The Netherlands is actually good. You don't have to nearly kill yourself when you're trying to go to the wrong street like here in San Francisco. But Wait.
Nate:The rail authority manages their own bike share program?
Chris:Is that
Ioannis:what you're the idea is basically that at every station, you have like end to end mobility. So you use the train to go to your destination across the country, but then you still need to solve the last mile problem, right? So what they figured out is why don't we just put a bunch of shareable bicycles into the bike station that people can use the same We have the equivalent of a Clipper card, for those who are familiar, like a little NFC card that you give an operator, and he just unlocks a bike for you, gives you the key, and then you can use bike for like twenty four hours, pay like $5 for it.
Nate:Super cool. Wait, so is there no private micro mobility market? Like are there players like Bird and Lime and
Ioannis:There's a bunch that are coming up, but those are like targeting in different markets, more like Gav casual within the city transport. You're already in a major city, I want to get from one point to the other point and there's no public infrastructure, then those are used mostly. While the shared bicycles from the railway provide are really about end to end, door to door mobility.
Chris:And this is across the entire country. Right? So you'll have Yeah.
Ioannis:But that was just tiny.
Chris:So No. I know. But I guess the point though is you see the bike ecosystems in major cities. Right? But I imagine you have cities that wouldn't be able to have a private company invest in the bike system, but because it's at the national level, they can deploy this infrastructure even into some small towns that would not necessarily attract
Narayan:private people. Exactly.
Ioannis:It's basically like the M Track works here. Like, There's a lot of stations that M Track doesn't make any profit on, but it kind of averages out to having net profit because there's a lot of very profitable stations. It's like a charity project to have some stations making a profit. The same in The Netherlands. If you deploy a homogenous infrastructure across the country, make it predictable, they still turn a profit on bicycles even though they're in cities with only 1,000 people living there.
Ioannis:And it really varies among stations like Utrecht, which is exactly in the center of The Netherlands, like a huge transport hub, has by itself 2,000 bicycles in one station. They're every day completely rented out. My girlfriend lives in Utrecht, and she has to go like an hour earlier to work because now she can't rent a bicycle. And if you think like traffic jam with cars is fun, like traffic jam with bicycles is even more fun. Like, it's it's hilarious to see those people, like, in the streets are, like, jabbing up and people just, like, ringing their little bicycle bells.
Ioannis:Oh, look at all of the way.
Nate:Oh, yeah. I went to UC Santa Barbara, a big bike culture to get around. And in the morning during the rush hour, there was always crashes and people ringing their bells and all those kinds of things. So what side of the locks were you on? Were you designing the hardware?
Nate:Like, how integral were you?
Ioannis:Yeah. I'm not sure how it is here in The US, but basically the government, anytime they wanna do something, companies can apply for solving the problem. The bicycle locks used to be like typical XR locks behind the rear wheel. They had a big problem that most people are losing their keys. They would bring me their bikes and they have lost their keys and it's super expensive because you need to open the lock every time that someone does that.
Ioannis:So we're like, why don't we just use the same NFC card that you unlock the gates at the station to also unlock the bicycles? And the company that I worked at, we were like a 20 person startup of which 17 people were doing something completely unrelated. It was media agencies, so doing advertisements and stuff. So we won this contract for some crazy reason because we built this prototype of the smart bicycle lock with the NFC reader. It was based on an NRI52.
Ioannis:And I got hired just after the contract was won. And we were back then a hardware engineer, product designer, and a back end engineer. There was not really anybody doing embedded firmware. I was hired straight from my operating system specialty. And this was my first proper commercial interfacing with hardware.
Ioannis:If they think, Oh yeah, it's just electronics. Just going to write some microcontroller code and everything works. In an operating system, you're not expecting it. There's no single source of truth. Just all distributed.
Ioannis:There's quirks in the firmware. There's quirks in the hardware. Hardware. There There was was quirks quirks in in the mechanical stuff. We were having this dual switch thing to detect where the ring of the lock is in, and it would be way too expensive to redesign and remanufacture because there was already 20,000 bicycle locks already made.
Ioannis:The firmware has to deal with the shortcoming of the mechanical system. So that was the first time I was like, Okay, actually abstraction layers don't exist in such an embedded product.
Nate:Obviously, was probably frustrating to you, were there functional trade offs that that required you to make within the business? Just because you didn't have the single source of truth? Were you guys having just like insane amounts of meetings? Like how did you guys ultimately deal with that problem? I guess we can tie into how does that apply to solve it?
Ioannis:So the biggest insight back then was we were a very small team. We had like for every type of engineering class, basically one person. And what it enabled us to do is that we didn't have any abstractions that you have in a bigger company. Since we were all in the same room and building this bicycle lock for the Dutch government with four people, we could make design decisions together across the stack. So we had this product and we had to work from it.
Ioannis:But we could make decisions that were transcending software or electronics or backend designs. Everything was fully designed as one whole thing. We designed the bicycle lock. Didn't design firmware or mechanical systems. And this is basically what Atopile tries to motivate.
Ioannis:It's about that you create one single source of truth, one design document that describes your intention of what you want to try to build that integrates the layers.
Nate:Interesting. So you guys see it more as a product tool. Right? It's appealing to the electrical and the firmware side of things, but you're really wanting to see it more as part of the larger product.
Narayan:Yeah. I mean, I would say, most accurately, we're starting with electronics. See this as something that applies generally across all engineering disciplines. It's been done well in software, and we're trying to spread the good word.
Nate:Yeah. It does seem like this is a direction the zeitgeist within hardware is going. We just heard the example of a really tight team working as a pro integrated product team to build this lock. Tesla, huge company, big teams, I imagine. Right?
Nate:And you were talking about how slow they were moving. Were there, like, a lot of layers you had to go through for approvals and stuff? What were some of the things that were gunking up the process?
Narayan:Yeah. I mean, personally, to be fair to Tesla, I haven't worked at other places. Apparently, it's much worse. But, you know, over my time there, I think engineering team tripled or so. I was there during, like, you know, I guess, when the stock 10 x or whatever, and we hired a bunch of people.
Narayan:And I definitely noticed that it was manageable in the beginning, like our team meeting. We could fit everyone in a conference room, but by the end of it, it's 200 people on a call. And so I noticed when you have a bunch of people working on something where you have now, like, a schedule, Engineers have this, like, bad habit of making their project fill the time that has been allocated, and it takes 1.5 times longer than you thought. And so if you have, like, 30 people doing the same thing, things take a really long time. If I'm given four weeks to work on my board, oh, there's a bunch of cool things that I wanna try to implement there.
Narayan:And time. You know, budget. Yeah. Yeah. I'm waiting on this guy.
Narayan:I'm not the latest person.
Nate:My business partner, Sam, describes industrial designers in a similar way. He says they're like a gas. You give them the room, they're gonna fill the room. Sure. You know?
Nate:Yeah. Don't laugh at it, Chris. You know it's true.
Chris:I feel like that is the way for anyone who believes in the craftsmanship of what they're doing. Right? They always want to maximize the time they have so they can create the best possible outcome. I don't fault any two designer engineer. If you're proud about what you do, you're gonna try to maximize the time you have to do it.
Chris:But ultimately, you can't estimate well and problems will arise and that's where you blow up schedules.
Narayan:The the other side is you have this line. The executives and the program managers push you to go faster and you want more time. The things that end up getting cut are actually the exciting parts. You know, we spent so much time doing boilerplate work, the thing we'd done 10 times before. And schedule just sort of continued to compress as we had to ship more products such that we didn't get a huge amount of time to be working on the cool new stuff, which is kind of like what I went to Tesla to do, to build something cool and new.
Narayan:And, yeah, there just wasn't a lot of time for it.
Chris:And I guess why is is that? To pull that back?
Narayan:Yeah. I mean, I think there is a a few things. Like my team, we were maintaining something like 17 separate products.
Chris:That'll do it.
Narayan:There are, like, five of us. So we're spending a whole bunch of our time dealing with supply chain stuff. Like, you know, a couple of years there, I don't think I shipped a new product. We were just making sure everything floated.
Nate:Yeah. Were there 2021, 2022.
Narayan:Yeah. 2020 through to late twenty twenty three. So like, right in the middle of supply chain. Right the middle crunch. Of Yeah.
Narayan:Yeah. Yeah. So simple stuff. Like, literally a diode is out of stock and I've got to go spin a whole new board, make sure it works, do all this validation and testing, bring it up with the supplier. Like, you're crazy how long it takes to do these really simple tasks because everything is super manual.
Narayan:If it wasn't my design, I've got to understand it, read all the little notes on the make sure I'm up to speed with what the product's supposed to do and how it's supposed to operate, dig up the, like, previous test results and compare those. Yeah. When when you just have a whole bunch of products to maintain, it takes a huge amount of time just to keep the ship afloat.
Chris:Totally. For your time at Tesla, did you have other teams you could depend on for supply chain or task where you were more of a supporter in those functions as opposed to, like, owning the design soup to nuts?
Narayan:Tesla puts a lot of onus on the engineer, but there's a lot of great surrounding teams that do great work. And what happens as an engineer is you are the keeper of the source of truth. Right? And so your day fills up with meetings, talking to supply manufacturing tests, talking to the validation engineers, and keeping this whole project afloat. There might be several of these going on at one time.
Narayan:It was pretty common for me to just do my nine to five, and that was just, like, meetings, and then I would do my actual work in the evenings.
Nate:And so time is back to Atapile obviously, right? Like the idea is if you could have this kind of single source of truth for all the intent for hardware and the endpoints you're connecting the firmware to, you can cut down on those meetings, maybe even reduce team sizes. Yeah.
Narayan:Yeah. Mean, I like, if the supply chain folks see on their dashboard that we're gonna run out of stock of this component, they say, this design needs a new diode. In our tool, instead of just capturing the part number of the diode, we say like, here's all the specs. They can find 10 parts, find the ones they can stock. Instead of that email coming to me being sort of two steps backwards of like, hey, this diode's running out of stock.
Narayan:Like, what is this thing? What do we need it for? Can you find some me other part numbers? They can come to me and say, like, hey, this part's running out of stock. We found these three alternatives that seem to meet your criteria.
Narayan:And we're, like, already two steps further in the process. But you can imagine there's nothing to stop them ordering the board if it's just something where they say, hey, here's the alternatives. Order the board, run it through the automated test, which we have. Like, we we have end of line testers. We have internal validation testing.
Narayan:I think that's a really exciting future where we're not trying to automate away the creativity of the job. We're trying to automate away the drudgery. The annoying meetings you don't want on your calendar, it's basically just how do we delete this compare numbers on a data sheet for an afternoon.
Nate:It'll mean like intent behind decisions too. Right?
Narayan:Yeah. Yeah. Exactly.
Chris:Can you dig into some of the tools you enable? Right? So you have that Saleh header that you can put on board so you can automatically plug it into like a logic analyzer. I know you've got components, APIs that have all libraries, but can you repeat the different elements of your stack and how it can help the product development process? I think that will give context for the listener because what you enable is quite remarkable.
Narayan:Yeah. So at a very high level, we're creating a language to capture your design intent. So a simple example being instead of you put two resistors down on your schematic and you specify the values, you say, I need a resistor divider and I need the ratio to be x. Or I have this input voltage and I want this output voltage. So you've captured one more layer of abstraction upon what you're trying to build such that it could be fulfilled in a number of ways.
Narayan:We haven't specified part numbers. We haven't specified anything else. But from that, we can create a complete design if that's all that you want. We have an API that will look up available components. So we take the input you have, being, say, the ratio or the input output voltage, whatever it might be.
Narayan:We calculate those resistor values, and you can give us tolerance, like within 1%, this output voltage. And my input voltage has this tolerance on it. And so then we take those requirements. We run those through a solver. So in normal engineering, this would be like an Excel spreadsheet that gets buried away somewhere or a scrap of paper on your desk.
Narayan:And so we've now like captured those requirements. We can then take results from our solver run and go query a database of components. This could be from your local quick term manufacturer or it could be your internal library of components that you've validated, have confidence in, etcetera.
Nate:You can import any library of components you want. Is that the idea? Like very
Narayan:Yeah, exactly. So it's like a very flexible interface. You could attach to your internal library or a generic one. We find those components that fulfill the role and, like, place those on the board for you. Another, like, really interesting part is as an electrical engineer, you spend a huge amount of your time starting from scratch, looking at some data sheet, finding the reference implementation, and then implementing that yourself.
Narayan:So something we've implemented is a package manager. So you start from the reference design. You can tweak it to meet your requirements. But for example, if you need a buck converter, you can just look up in our package manager, find something that looks about right for your application, and then everything's parameterized. So you can just say, here's my input voltage, here's my output voltage.
Narayan:So this information is not strewn around. It's in your design. So if that chip goes out of stock, we still know the goal here so you can capture all those requirements and automatically pick all the parts for you.
Chris:So, Jani, you want to add anything? Because I have a comment.
Ioannis:Yeah. So like, that's already a really miss them
Chris:Through English.
Ioannis:Through language. Yes.
Chris:Well, you guys have created Well, it could be German. Right? The reason I say this is because you guys have created a domain specific language, a DSL, that describes electrical intent. Right?
Nate:Yes.
Chris:And you then compile that into a schematic. Right? Design. A design. Fair enough.
Narayan:You ordered around there.
Chris:What's that?
Ioannis:Schematic's dirty word around here.
Chris:Why is it dirty?
Narayan:I think it's important to touch on schematic is the place where people gather around to like understand the design. What we would want people to understand is that it's just one view of the design. And we try to attach a bunch of extra information, some of which is not well represented in a schematic. You see it covering all these little notes and stuff like that. But it is just showing connectivity, and it's showing all the connectivity.
Narayan:For example, a power tree is another view. An I squared c like tree is another view of your design. There's nothing inherently special about the schematic. We're trying to capture a superset of that information. A schematic is something we can generate out, but it's just projection, one view of your design.
Chris:Would you like to think of a schematic as a two dimensional view of a design? You like to think of the world in three or four dimensions. And so a schematic is inherently less information dense.
Ioannis:The best equivalent is database just captures the data itself and you can represent it in multiple different forms. And the thing is you can't from a database generate a spreadsheet because there's more information in the spreadsheet in specific regards, but less information because this information density is gone. And we think like this with our designs, like from a high level of abstraction with an editor, you can't generate a schematic because there's a lot of information about how the designer laid it out in a way to make it presentable to someone. And this information is obviously not encoded, but it also means you don't have to encode it anymore. You're thinking of purely from the design perspective.
Ioannis:And then instead of having this one size fits all representation of your data, which is the schematic, now you can generate what Narayan was saying, like you can generate a PowerTreeViewer, can generate whatever else. And it's never going to be like this refined thing that a human has presented as a document. But you can still do that if you find it valuable. But we make it now optional that you have to make this.
Narayan:I think like another maybe just quick interesting one there is schematic is assuming a specific implementation. You know, capturing intent, we could use 10 different converters to fulfill this role. It doesn't really make sense to represent one of those on the design. That's just a projection of a way you can build this. But if you're one one step back, like, it it doesn't really make sense to draw it out.
Chris:I think it's really interesting because it converts this into a schematic is the rendering or processing of the intent. So it's more of an output versus, like the output of work because usually you'd start with the schematic and then work into more fidelity in terms of implementation and component. You're saying you don't need the schematic at all.
Ioannis:We're thinking of that schematic. It's a documentation
Nate:How much of your version of the word schematic is marketing driven? Obviously, there's a lot of philosophy there too, but how much of that was also marketing driven?
Narayan:Yeah. We do intentionally poke when people say schematic because we we think it does hint at, like, a bit of a misunderstanding of what we're trying to build. As we're saying, it's a, like, a slice of the problem to represent it in this form familiar to engineers or technicians. But as we're saying earlier, we're really interested in the full stack here. How do we interact with the firmware team?
Narayan:They don't care about a schematic. They want a header file. They want to understand the addresses of all the I squared c devices on the board. They care about a different projection than the schematic. They will sift through a schematic to get the little crumbs of information that they need.
Narayan:And the same for a really good supply chain person or something, they'll look for the part numbers on there. But it's not helpful to everybody. It's a bias that the schematic is the most important view. That's how we feel as electrical engineers, but there's lots of other people working on the design.
Nate:I like the document artifacts analogy. I think that's really cool. Chris, did you have another question? Sorry. I just kinda dove over marketing questions.
Chris:I mean, there's so many different places we could drill in here. Because
Narayan:you
Chris:said that the schematic is an implementation. Right? So it's not necessarily the ideal. It just happens to be a way to solve the problem. And I do have noticed that in some of your sample code on GitHub, you have Windsurf and cursor and other sort of artifacts that provide context to LLMs.
Chris:How do you see vibe coding or vibe hardware creation? I don't even know. Do you have a term for it? What would it be like? What what I Vibtronics?
Chris:Well, Vibtronics.
Nate:How are you guys fitting into the new software development tech stack? It's Cursor and such.
Ioannis:I think we were lucky because we started before LLMs were a huge thing. And our goal was like, let's make a unified way of thinking of it electrically and software engineering. Because the software industry is just so much bigger than the electronics industry, right? That's why tools for hardware engineers are just worse because it makes sense. There's just been less money and attention to it over the years, and we have in software figured out so many things like Git version control.
Ioannis:That there's nothing comparable like this in electronics. Right? Like, the the virtual machines, you can reset the way of collaboration, the PRs, everything.
Nate:We interviewed Valentina Ratner from Allspice. Right? They're trying to thread that needle with hardware.
Chris:They seem to be working
Nate:well, but they even admit that they've moved upstream. Right? They're really trying to go after enterprise clients. And I wanna talk about target customers with you later. Finish your thought,
Ioannis:but I just wanna point out that
Nate:you are trying to do the Git side.
Ioannis:We want an easy path and not rebuilding the whole hardware tooling industry by bringing all the investments that have been done in software and all everything that we have understood to hardware. The easiest way was to make it look similar. Just have a language as you express yourself, name things, bring abstraction to electrical engineering. And this idea of like, let's bring everything that has existed to hardware engineering has put us in this lucky spot of like, actually, we also get everything that software will do in the future to hardware engineering. And it paid off with LLMs being really good in the software tooling framework because they understand language and can work with it.
Ioannis:Suddenly, have brought tools from the past, but also the tools from the future, which is LLMs, into electronics. And we actually, in the company, used quite a lot. One of the little projects we've dabbled in is like, you have this Adafruit product catalog that have like the 150, 200 little small designs. And we just the LLMs rip through them and be like, let's rebuild this in Attober. And they were good at it.
Ioannis:Because in the end, how you build software in any form of engineering product is through abstraction. You just say, I have this small little block. I name my concepts. I put them together in little modules, and I stack them up to the top. And that's in electrical, same as in software.
Ioannis:And we have found really positive results with it. LLMs actually understand electronics extremely well. It's sometimes pretty scary. There's
Nate:a big move within OpenAI and all these guys to try to crack the nut of how to make these useful for hardware development. Effort.
Ioannis:We really saw that the thing is LLM is like crazy good at electronics. They're very bad at schematics because they're not visual like humans are. But here, the thing is that not only the schematic understanding is what makes our tool very valuable to LLM, it's also the self validation. In a schematic, you can connect whatever you want. Can take a 10 volt power array, connect it to three volt, Have luck with that.
Ioannis:Enjoy your smoke. But in R2, since every voltage rail has its own constraint of like this is between nine and eleven volts and the other one is between two and four, if you connect them together, the two is going to be like, I think you're going have a bad You might reconsider this. And that really closes the loop on the LLMs. Because before that, our loop was like, you make a schematic, you route your PCB, you send it off to the manufacturer, you wait two weeks for it to come back, you connect, and then you're probing the thing, and then you go back into the drawing board. And one thing that resonated for me, I'm not sure whether you read their emails from OpenAI between Elon Musk, Ioannis, and Sam Altman.
Ioannis:One of the things that struck me was that Ioannis was talking a lot about that it's not that we have found anything new with AI as it didn't exist in the 90s. Most concepts are similar. What has changed is that the hardware has gotten good enough that the iteration cycles for AI researchers has gotten so small that this fits within a fast research cycle. There's like apparently for humans an optimum amount of time where you can keep enough context and you can actually keep on cracking at the problem. And hardware was just too slow.
Ioannis:If you have to work on three months scale, it's just very difficult to keep the problem pushing, while with the new hardware, you're within a weak scale. And we're thinking the same with electrical engineering. Having to wait two weeks for your board every time to come back to iterate on it just loses out so much of the context for the engineer, or in this case, the LLM. And by making the cycle small, you get 90% of the errors you would get later immediately. Like all those rules that electro engines have in the back of their head, you can just capture in the tool and let the tool give feedback for those small little mistakes back to the LLMs and the human designer.
Ioannis:And that's why we have seen the biggest difference because they're good at understanding electronics, but bad at being 100% correct the first time. And by having those little feedback mechanisms, they suddenly get a lot more useful for actually building viable electronics compared to just spitting out the schematic in your orders and you're like, Well, nothing works here.
Nate:You're playing a role in helping make these LLMs more effective for working with electronics.
Narayan:Yeah. I mean, the same thing applies to human designers. Like, fallible makes silly mistakes, and having more robust checks makes a huge difference. And a lot of these are like hard one little checks. I'm like, oh, no.
Narayan:Like, I set the same address on my ISPOFFS. Like, that's super annoying. Let's add a check for that. Actually, we spend a lot of time building hardware with it as well. We have a number of projects that we're constantly building, validating the tool.
Narayan:We find it really important that we use our products actively. We spend one day a week, the whole team works and like builds stuff with our tool, which sounds like a crazy amount of time to commit to something that is not directly moving the needle forward. But we are so much faster because of it in the other four days of the week.
Nate:It's all being quality assured, make sure that this thing actually works. Right? I Any product team, especially hardware teams, you get so obsessed with getting the product out the door that you cut corners, right? And you didn't focus on what it's going be like when people are actually using it at scale.
Ioannis:GREGORY What's even more important is that we build what makes sense. The surface is basically infinite. You don't want to rebuild all the tools, like 1,000,000 other things that are currently urgent for making this product feel better. We're not just using the tool to build actually PCBs, but we really make products ourselves. This really helps to be like, Oh, I can make my PCB in half a day, but my bring up still takes like a week.
Ioannis:So it's like, Well, we're barking up the wrong tree.
Nate:Right. And I know at one point there was an ambition to partner with PCB Fabs so that you could do quick turn board production so someone could, like, do the schematic and then quickly get a schematic.
Chris:We don't talk about that.
Nate:Sorry. Not schematic. Design. Design. Is that something you're still doing?
Nate:Is that something that you're
Chris:actually building hardware with it? Right?
Narayan:I I think exactly as as, you know, was saying, we're constantly looking at the long pole in designing stuff where are the pain points. We use some quick turns that are pretty good. Currently, not our biggest problem. We use JLCPCB for our super fast spends.
Nate:Oh, yeah.
Narayan:We get bores back in, like, five days. As soon as that's the biggest problem in hardware engineering, we'll care about that. But at the moment, found there's just a lot of other things are more important first than the actual manufacturing. The US, for example, has its own challenges. It's, like, unfortunately, a much more antiquated way of making PCBs.
Narayan:It's not just like an API where you can set your board off. There's a lot of pain points there. I have an unfortunate amount of experience dealing with the way that it's currently done here and definitely is a lot of work.
Chris:Yep. How do you guys deal hallucinations just because it sounds like a good circuit? It doesn't necessarily mean that it is. So how does the tool maintain functionality while not literally going off the rails?
Narayan:Maybe we're taking a step back on how we imagine people approach building a project with our tool. Firstly, that you're not gonna be starting from scratch on every part of the circuit. You're going to be reusing modules. These modules, with our language, can be designed in such a way that you configure them for your application. So, you know, for example, like the the power converter is a really easy example.
Narayan:I can't set the input voltage to 24 volts when it's only able to go up to 12 volts. It'll throw a compiler error. So we've already put a bunch of guardrails in place in these circuits that have been validated before and get you close to a place where you're just communicating what you actually to achieve with the design. You're just in a space of valid solutions, and I think that gets us a long way. The other part is, as Gianni was talking about, we have rigorous checks where we're checking things in your design and able to get those quick iteration loops back to whoever is actually building it and hopefully catch a lot of those mistakes.
Narayan:And we're continuously adding to that. So yeah, we're really just trying to look at where are the most common mistakes, how can we add checks to make those happen with much less frequency. And we're working our way through that list from the most common to very rare. As our tool improves, it's going to be super rare that you can find yourself making a mistake that our tool didn't catch.
Ioannis:Think of asking an LLM or like Codex to write your web application using FastAPI or to just tell it, go bare metal and just write it yourself. It's like, you use fast API, obviously it's going to be just a way higher chance that it works out of the box. If it writes a web server from scratch, where there's so much more surface where it can make mistakes. That's kind of the same with us. We choose modules and abstraction and validation inside those high quality modules, and that will prohibit a lot of the mistakes LLMs make when it becomes big.
Chris:No, that makes sense. You've got constraints in your domain specific language that allows it to be quite powerful in understanding when it is functional or not. So that totally makes sense.
Nate:You were talking about trying to
Chris:get into more
Nate:enterprise applications, and we were talking about some other tools that are kind of playing in a similar space like Allspice. How do you guys integrate into the development stack for existing enterprise teams? I thought I saw in the Hacker News discussion that you guys have some integration with KiCad. Is that true?
Narayan:Yeah. Yeah. For sure. We're starting and just finding sort of like how can we build this up from ground level forward. We currently don't do the layout, so we're focused on the intent captures, like schematic, sorry, side of the design.
Nate:Just say design.
Narayan:We rely on KiCad for the layout. We integrate quite closely over
Chris:KiCad or KiCad? Like GIF and JIF?
Ioannis:KiCad. It's it's Ki? It's how the original founder intended it.
Chris:KiCad. Isn't he a founder of JIF? He said that JIF, not GIF. He's just flat out wrong.
Ioannis:I think it's such a large community that he has lost any rights to make decisions over it. Fair enough. Narayan says something that struck with me, is if the majority of people say it wrong, isn't it right?
Nate:It becomes like a silky
Chris:cat. Fair enough.
Nate:So you you work with that tool. Right? Are you integrated with Altium two? Or
Narayan:We're not at the moment, and it's something we will likely have to do to work with bigger enterprises. We've looked at it as something we can definitely support, but there is a cost to supporting a bunch of different ways to do something. At the moment, we're really focused on the tool and pushing it forward as fast as we can. So we're very intentionally not supporting a bunch of ways to use our tool.
Chris:This changes topic a little bit, but it does drill down into open versus closed. Right? So
Nate:Can we get into that in a sec? I did wanna ask real quickly, like, how are teams incorporating out of pile into their stack? Right? Like, you wanna prioritize. Right?
Nate:So you're not approaching this from an extensibility mindset because you want the tool to be as fast and effective as possible. So how is it working into an enterprise team's stack?
Narayan:We found that we're not selling to enterprises. We're not, like, actively seeking them out, but quite a number of people have just picked it up on their own and they're using it. Mostly, you think when designing a product, there is the board, but then there's all the test equipment around it. There's a bunch of infrastructure like adapter boards, connectors, test boards. As a designer, have a lot more freedom into your stack.
Narayan:And you're just going to use whatever is fastest for you, which might be the tool you're most familiar with. But we found a number of people that have found Adapile through Acronose, whatever else, and picked it up at work. So they're just sort of renegade off using it in a corner somewhere shipping boards directly, which is cool. But, yeah, we we haven't really put any energy at all into making it something easy to, like, adopt into your full mainline engineering stack yet. That's something that we're sort of moving quickly towards by the end of this year.
Narayan:At the moment, it's just people who have found it and just use it without asking.
Ioannis:Yeah. Like, people love it for quick prototyping because you can reuse your layouts, can reuse your designs, and you don't have to make any footprints yourself anymore because if you order from JLCPCB, you get the footprint directly generated for you by the tool. And that means that if you want to just not a quick board where you don't have to think about ordering constraints, manufacturers, supply chain stuff, that's where people currently see the tool the most valuable and just early adopted it.
Nate:Yeah, trying to move really fast. And this will get into the open source questions Chris was starting to ask, but it does seem like you guys are starting to strike a note with software developers that wanna get into hardware. Right? Because it's a tool that works in a way they're already thinking. I've loved seeing Reddit discussions about people creating their extensions and additions for Autopilot.
Nate:It's cool to see a developer community, not just users, building tools for it, which I guess is one of the benefits of having an open source core. Right?
Ioannis:I wanna take a little tangent here of the love of open source. Like, I really think so understated how important open source can be in having an open ecosystem, because your moat is most of the time not the 99% of code that you have to churn out and write boilerplate for. It's really this top 1% of application or idea. So giving away the bottom is not a barrier to entry. Everybody can write like this same churned out code.
Ioannis:There's like whole companies selling you that stuff. And open source benefits that enables you are just like far, far, far transcending of all the barrier to entry that you have for small companies. And for us specifically, it's very much at the core of a company because actually we met through open source. As we were saying earlier in the origin story, some friends started at Autopilot originally, and I was independently starting a company in The Netherlands, Fabric, which was trying to solve the same problem. And we found each other on GitHub after one and a half years of working independently on our project.
Ioannis:We're like, Hey, you're solving a similar problem as us. Should we chat? So we each other from The Netherlands to The US. I kind of liked you guys. They were like, You're pretty cool.
Ioannis:So I just flew out to San Francisco, met Narayan here. I was like, Wow, it feels like I've known this guy my whole life. Was one of the beautiful things of open source and the internet. Now so close to be like co CEOs next to co founders. It's just like, would have been not possible if we would be both be building hidden away somewhere.
Ioannis:So open source has like so many benefits, but even can go all the way down to actually for discovering like minded people that try to solve the same problem.
Nate:Very cool. I love it. So you well, actually, I don't want to get off the topic if you had more questions on the open source side of things, Chris.
Chris:No, I mean, I've got spicy questions that we like because you know, like, for instance,
Nate:Let's go. Let's go.
Ioannis:Let's go. We love spicy questions.
Chris:Mhmm. No. So like there are some companies that are open core that have pulled back capabilities from the open source.
Ioannis:Good old little rug pull. Good stuff.
Chris:Yeah. Yeah. I mean, I mean, it's it happens in crypto and now it's happening in open source. How are you preventing your future selves and the capitalist nature of organizations from changing the culture of the community in the future?
Narayan:I think a really big trust. We're trying to put out a standard that people can build on top of and feel comfortable building on top of. We're going to benefit by the ecosystem growing massively here. You know, if every company that's building hardware is building on top of this Atafile language, then we're positioned to be massively advantaged. But if we're doing shady stuff and trying to sort of short term benefit ourselves, people are gonna feel rightfully nervous in having all of their IP in something that is moving underneath them.
Narayan:You know, we're a young company. For them to take this on, they need to feel like this is gonna be around for a while. People are gonna maintain this. Even if Adapal goes bankrupt, it needs to exist. We're really putting that out for our future customers.
Narayan:It's important that it's stable, available, and something they can use into the future.
Chris:Ultimately, they can fork it if they disagree with the direction of the organization.
Narayan:Totally. Yeah. I mean, every engineering company today has a bunch of stuff locked into some proprietary format that they would much rather it not be. And it's hard to convince them to shuffle into the next proprietary format. We don't think that's going to be a winning strategy.
Nate:Totally. What are you going say, Yami?
Ioannis:TRADEOFFS Name one closed programming language that is being used. It's like languages shouldn't be closed. This is one out of a 100 business models, but this is the one that relies the most on being open.
Nate:So can we talk about kind of founding story and you two as cofounders? I love that backstory about you working in parallel on similar concepts. Narayan, I know you had another set of cofounders you'd worked with. Jani, did you as well, or were you solo with your project?
Ioannis:I did have a cofounder, and he's actually gonna join us soon.
Chris:So did you guys merge companies, or was this more of, Jani, you joined Atapile and now you're bringing the former team into the fold?
Ioannis:It was actually pretty handy because I was just at the beginning of fundraising. So, like, conceptually, it is a merger, but in terms of formalities, it was more like taking everything I've built on in myself and my team basically and merging it into EtherPile.
Chris:Was that before Y Combinator?
Narayan:About a year after, I think.
Nate:When did you go through Y Combinator again? Was it early?
Narayan:We were winter twenty four. Okay. Alright.
Nate:So wait. Is winter in the beginning or the end of
Narayan:the year? The beginning of the year.
Ioannis:It's it's confusing.
Nate:I don't understand these things.
Narayan:So it's in, like, January.
Ioannis:Dutch winter starts in September, so it's really confusing to me.
Nate:Yeah. Totally. California must be very weird for you.
Ioannis:Very weird.
Nate:So when when I got to know Adapile, I my first introduction was Timothy, your your previous cofounder, Narayan, and then I think I interacted with Matt most of the time. And I know things have kind of evolved there. Timothy and Matt are no longer in the company, or are they both still involved in some capacity?
Narayan:No longer in the company. Yeah.
Nate:I don't wanna pry too much because I know it's sensitive. But one of the one of the things that we like to kind of unearth through these podcasts is kind of the reality of being a cofounder, and the human piece is really key to that. Right? So I am curious. You know, Timothy and Matthew, was it an amicable parting?
Nate:You know, what ultimately led to them leaving?
Narayan:Yeah. Like, Simon, on on Tim, like, I I guess a number of reasons. You know, a big one, like, he was he was Swiss and you know, family and being away from friends and all that, I think, was a big part of it for Tim on top of sort of the, yeah, uncertain future that is being a startup cofounder. So for for Matt, you know, he left, about end of May.
Nate:Was that after you'd already joined Yanni?
Narayan:Yeah. Yeah. Yanni. Yanni had been here for, like, six months or so.
Nate:Okay.
Ioannis:And for Matt,
Narayan:it was a little bit different. It was, you know, a bit more of a disagreement in how we wanted to approach building it. You know? So for Matt, very much focused on, like, early revenue. Let's do more sort of the consulting direction.
Narayan:Let's use our tool ourselves and work with customers and show them how to use it more directly. Kind of a more sort of, yeah, I and I were interested in let's just go all in on the tool here. We think it's gonna be faster to use it internally, use it ourselves, not have this overhead of dealing with customers. And ultimately, Matt decided that he couldn't be on board with what we wanted, but our number one to move on. Yeah.
Chris:I would say, like, this seems like a a trade off. It I know, but it sounded like he was trying to optimize for revenue as opposed to growth. Yeah. Like, there was uncertainty within the business and getting consulting dollars would reduce perhaps some of the risks that Matt may have seen.
Narayan:I think it it feels scary when you have some money coming in the door, but it's not something that scales really well. I think, like, reflecting back on it, you know, both Matt and Tim, you know, played a really important role in the beginning of all of this. Like, Adapai wouldn't be here without Matt and Tim. And so definitely grateful that they were here. It was a really hard time and we're in a in a great place now and definitely have them to thank for it.
Ioannis:I think, like, on Matt's character, Matt is a great, great guy. Super smart, very dedicated. The reason why it ended up like this is actually that he suggested it. We didn't vote him out. Matt realized himself our directions, our visions are not aligning very well anymore.
Ioannis:We were talking with the three of us what makes us excited and what we want to build on. And we have just realized together, okay, it is not necessarily the same direction. We were pleading for Matt to stay with us and find a compromise of where we want to go to. He himself was like, I personally think the company is going to be better off if you just take this energy that you both have and fully send it behind that instead of making compromises with me. And that's also why the breakup has not been super disruptive to operations because we've just kept on doing what we were doing.
Ioannis:And there was not really a co founder breakup, but it was really more like, hey, guys, I think you got this company working perfectly with the two of you. I'll just step back and watch from the sidelines. He's still involved in that. Supports us and gives feedback. It's great to have him in the community.
Nate:Kudos to Matt. Matt, if you're listening to this, kudos to you for not letting ego get in the way and ultimately thinking about the project first and the team and the product, which ultimately, that's what you need when you're building anything that's got an open core, right, or has any elements of open source to it. So that's really awesome, and it says a lot about the DNA of your business.
Narayan:Yeah. We think everyone that's been involved really deeply cares about the problem. It's something I didn't touch on that Jani hinted at. It was like our nights and weekends for a year and a half before we did YC, Matt, Tim, and I, and, you know, Jani, of course. But we've been working on this together for a long time.
Narayan:It wasn't some origin story of like, hey. We wanna start a company. What do we do here? We tried to build this internally at Tesla. We pitched this to our director, like, hey.
Narayan:It'd be really cool if we could have a little sub team and
Chris:Well, we're gonna cut all this out.
Narayan:That's allowed. You know,
Chris:I've heard a number of stories about people who pitch their company internally. They went and they were successful, and the company comes out later on and starts suing for the intellectual property because they heard about it first.
Narayan:They were We talk to a lot of lawyers about it. We got lots of bits of paper signed.
Nate:Yeah. And I I feel like yeah. I trust you guys.
Chris:Nate, do you really want be deposed?
Nate:I mean, that would be exciting. That meant I hit a career milestone. You know? I'm being deposed. I'm in.
Chris:That's funny.
Nate:I I mentioned the talent network that I run-informal and how my business partner and I were both doing consulting work, running projects with clients. And it took two years for me to pull myself out of that. When I was able to do that and just focus on the business, things accelerated like crazy. Though I think I think you guys made the right move, especially though if you're trying to set a standard. Right?
Nate:And it worked out well.
Narayan:Honestly, it's really important for people thinking of starting a company to hear, you know, it is it is hard. I've been friends with Matt for sixteen years, and we couldn't figure it out. It's tough. I can't imagine trying to do it with some stranger you just met on the street.
Nate:You met Yani on the Internet, and
Narayan:we just had
Chris:it together now.
Narayan:Definitely a dice roll there. Very unlikely it came up our way.
Ioannis:Yeah. I think alignment with another person is the most driving factor. You don't want to join forces on what you want to build, but more like who you are and the reason that you want to build it. That more important than the actual product.
Chris:I think you're talking about shared values. Right? I think the two of you sound like you very shared values and alignment around vision, and I imagine that helps you stick together and drive the company forward. Mhmm. So who do your investors call when there's a problem?
Chris:Because you guys are co CEO. Right? So who's the neck that they're choking when there's a problem? Great question.
Nate:Both necks. You got two hands. Two hands.
Ioannis:Two hands. Yeah.
Narayan:Mean, I I think Yani and I share the responsibility of interfacing externally to the company. I think it's really important as a leader in the business that you understand how the business works and the different aspects of it. Talking with investors is a very important part of that. Keep your monthly updates rolling out and they're typically pretty happy. We just sort of alternate who's communicating out what's going on.
Narayan:Crimp on calls, we like to be on it together.
Ioannis:Yeah. Like one of the things that people talk to us a lot about with the co CEO stuff is if you don't have one person at the end that calls the shots, you get decision paralysis. And I think this is exactly the thing that we're trying to avoid, but just like trusting each to the fullest. Just because we are sharing the role doesn't mean we do everything together. I trust Narayan 100% that all the shots he's calling are the right shots, and I'm not questioning them if they're not open for debate anymore and the other way around.
Ioannis:And sometimes it's just really good to have another person you reflect your emotions and your thoughts on.
Narayan:Yeah. And we found that this hierarchical structure of authority in what is an open source sort of distributed idea of how to how to work and how to build stuff. There was, like, some incompatibility there. We're trying to maximize agency in people that work for us, and we see hierarchical structure as the opposite of that. Like, for 99% of the day, Yami and I are just engineers who work at this company side by side with everyone else.
Narayan:We're not telling everyone what to do. We keep our finger on the pulse, but we expect everyone else to do the same. We think that you get so much more productivity out of people if they really learn and care about what they're working on and believe it's the right thing to do.
Nate:Can you talk about your team composition? What does the team look like these days?
Ioannis:It's actually a really interesting question because we are also like slightly unorthodox with how we structure our team. So as Narayan already mentioned, we try to avoid specific titles or responsibilities. So everybody is just an agent behind the vision. We don't make tech leads or hardware engineer versus software engineer. So we also don't try to split those roles.
Ioannis:It's very important that from sales to hardware to software, everybody sees what currently has to be done to fulfill our vision, tries to do that thing that has the most impact. So we try to not make a difference between the domains that someone has an education in, but more that you see what the problems are, you suggest what you could work on, and from there you try to execute upon. And we're currently a small team, so we try to keep the graph very interconnected so that everybody knows each other very well and understands each other very well because that avoids like this communication overhead. And we think if everybody knows each other and can predict each other, you can get rid of 90% of the overhead of the communication. And that will help scale the company better.
Ioannis:So we really try to hire people that have good intuition for each other and understand each other very well and have, like Narayan said, like this very high feeling of agency.
Nate:Very cool. And how big is the team now? How many people do
Narayan:you It's five of us at the moment.
Chris:Still a two pizza team. Still a two
Nate:pizza team. Well, exactly. Chris. Right? Amazon famous for the team sizes should be big enough so you can have, like, a a one to two pieces for all of them.
Nate:Do you guys see this kind of no hierarchy flat structure? Do you see yourselves keeping this as you go, or do you see eventually adding in layers? You're at this stage right now where you're so small where the priority is speed. Right? Everybody can tap each other on the shoulder and communicate with each other and, like, that's possible.
Nate:But in my experience, it gets really unwieldy when it gets to board in '25. Yeah.
Narayan:If we're not gonna have a completely flat structure with a thousand people, it's probably not gonna work.
Nate:Your ambition might not be to get to a thousand people. With AI and automations, you can create massive companies that are still fairly lean. Right? Like WhatsApp when they got acquired for 13,000,000,000 or whatever that was, and they only have like 50 people or something?
Narayan:Something crazy like that. Yeah.
Nate:And it was a decade ago.
Ioannis:Yeah. Hyper alignment is really, really core to our DNA of how we want to do this. And if hierarchy is compatible with it, with a bigger team, we're going to find out a way how to do it with more people.
Nate:How are you aligning the team? Or is it distributed, or is everybody in San Francisco?
Narayan:All in person every day, very intentionally.
Nate:Is that a big part of what's allowed you guys to stay aligned?
Narayan:I couldn't imagine trying to build a startup with a bunch of people. Some people manage
Ioannis:to do it,
Narayan:but having tight alignment if you're not in the same place. There's just so much that is not the actual work that helps with alignment. It's the conversations over lunch. You know? All of these things you'd miss if you're
Ioannis:not Yeah.
Narayan:In person together.
Nate:Well, and the ability to be like, you look haggard. Let's go get a drink. Let's figure out what's going on here. You know? Yeah.
Nate:Yeah. Do that when it's all virtual.
Narayan:Mhmm. I mean, we we do a lot of things to try to maximize alignment. We try to do activities together. We're all into music, so we do that together. Yeah.
Narayan:Is quite a good drum and bass DJ. He's been teaching us that, which has
Ioannis:been super fun. I had a life before COVID, which looked very different from my current life. Let's say it like this. Love it. Now this also goes back into like open source stuff.
Ioannis:A lot of people think that all the companies out there that exist and that try to do code to electronics are competitors, but it couldn't be further away from that. Like we are such a small niche, we try to convince the world of like this is the way to do it. We actually very close and are trying to support each other as much as is reasonable. Our competitors is not alacode to electronics. Competitors are the dinosaurs out
Narayan:there. Well,
Nate:well, not just that. Like, your main competitor is just legacy ways of working. Legacy ways of building hardware. Tool agnostic. Right?
Narayan:I think a really good point. We're definitely not trying to one to one replace LTM. That would be trying to shove a round peg in a square hole. It just wouldn't make sense. To maximize the value that you're gonna get out of this, like, next generation of tools, you're gonna need to work differently.
Narayan:It's gonna be much faster, but not if you try to do it in exactly the same way. The way of work needs to change too.
Nate:Totally. I love what you were saying about how there's so many people working on this problem and doing things that's creating a lot of collaboration. I've experienced that in San Francisco. It's a really exciting time to be working in hardware in SF because of how many people are focused on making the whole process better. You guys are at the core of that.
Chris:When you think about the next year, two years, three years for where this industry is going, how do you think Adapayo fits into that?
Ioannis:My intuition is that in Germany, electrical and mechanical technician roles have merged together into mechatronics, they're called over there, and it has created a huge improvement in efficiency in those teams there because you can just merge two people in one and understand the full stack. And I feel like the more integration between electrical engineering and firmware is empowering in the same direction. There's a full stack engineer owning the stack from electronics to firmware to integration into edge or back end.
Chris:And what is at the root of that? What tools and technologies are bringing that all together so a single engineer can do all of those different roles?
Narayan:I mean, I would because
Chris:it's not as familiar.
Nate:Simple as being a full stack software engineer. Mechanical, electrical, firmware. Those are pretty disparate disciplines, different tool kits.
Ioannis:Yeah. I mean, there's still back end and front end engineers. It's about 99% or 90% of the time you don't need deep domain expertise. If you do some hardcore analog stuff, you definitely want a trained electrical engineer who owns that. But most of the times, if you have a master's in electrical engineering, you're going realize that building PCBs requires 5% of that knowledge.
Ioannis:That's the same with full stack software engineers. Writing a database from scratch, that's really difficult, but you just don't do that. You just rely on abstraction and reusability. Most software engineers are system integrators. Currently, electric engineers do a lot of low level stuff, and that's my personal opinion.
Ioannis:That's going to be this job of someone who just, like, clicks them together, and that will enable all those benefits you get from having a full view of your product. You design the hardware for the software. If you have the full stack in your head Mhmm. You can do things way more efficiently without the meetings.
Chris:I used to say that software engineering today is just digital plumbing. You're just connecting tubes together. Right?
Ioannis:It's a very well paid Lego.
Chris:Yeah. Exactly. Agree with you with respect to full stack engineering being more than just front end and back end software engineering. And I think one of the main drivers here is LLMs. Right?
Chris:If I'm vibe coding lots of things, I could hand code myself. That's not a good use of my time. I can coax the prompt to get the output I want and go to building something else. One of the things I've told myself for the last couple of years is I'll just learn KiCad. Like, I've it's been, like, over ten years KiCad.
Chris:The Dittaboard. KiCad. Whatever. KiCad.
Nate:Oh. Come on, Chris. We already know
Ioannis:that one.
Chris:KiCad. But it like, for me, learning about these tools, it almost seems like that's the wrong tool to learn right now. I should learn Atapile's language driven through an LLM and then dig into the parts of KiCad for board layout and things like that. I'm imagining in the next five years, a prompt alone will likely derive some electronics that I need, and I just need to understand the why.
Narayan:There's a good reason that we've started with the definition, the language rather than the order routing. Order routing is a really hard problem if the order router doesn't know what you're trying to do. If you have a schematic that doesn't say anything about the current flowing through each trace, the voltages on adjacent traces, the signals running through them. And this is all something you need to further encode into the autorouter for it to understand and give you an even remotely good result. But if that's something we're all capturing in our language, it's going to make it a much simpler problem to add automation to this process.
Chris:So it sounds like Eskimos have like 13 words for snow. Right? So if your language doesn't encapsulate the full intent of the design, it's really hard to derive a layout for a board. So you guys are really refining the language such that future designers will have a robust and verbose language that derives everything within the hardware, not just Yeah. The boogeyman schematic.
Narayan:Yeah. Exactly. There's gonna be like some small spatial information that language might not be the best way to convey that. For example, here's the shape of my board. That might be annoying to write in code, but we wanna capture everything that's reusable.
Narayan:I don't wanna have to write the rules from scratch about how to route Ethernet on a board. We know how to do that. I just wanna capture and reuse that information. The same for thermals and all these other bits and pieces. You know, a lot of these tools exist, but they're cumbersome to link together and use cohesively, particularly that aren't linked well to the auto routers that exist today.
Chris:Are you guys hiring at all? Where can you find you guys?
Ioannis:We are passively hiring. It's like we have filters for who we like to work with. So it's more like come hang out with us and that can develop into hiring.
Narayan:That is how we've hired everyone so far.
Ioannis:Yeah. We are always looking for people that are just fun to be around and love the problem that we're trying to solve. And now there's a lot of ways to interact with us. If you love drum and bass and electronics, hit us up. If you just like after years of software trying to get into electronics and you couldn't come into our Discord, try to build something cool.
Ioannis:We like to support you guys. We're on a bunch of socials.
Nate:We'll drop it into the description. Guys, thank you so much for this. Thanks for being so candid with us and unfurling the story even though you were asking some sensitive questions.
Narayan:Yeah. Was great. Thanks, guys. Thanks for having us.
Chris:Thank you for the time, guys. TRADEOFFS is hosted and produced by Chris Rill and Nate Padgett. Editing done by the illustrious Alex Michael. Our logo is designed by the talented pixel alchemist, Tanya Shica. If you'd to be a guest on the show, reach out to us on our website at tradeoffs.fm.
Chris:If you made this far, please rate and subscribe to the pod. Nate and I appreciate your support.
