(Audio) Edge Cases Ep. 01: Reverse Engineering the Rules w/ Alex Klarfeld

Karina Chow This is very exciting. I want to say, hey everyone, thanks for joining. Welcome to Edge Cases. This will be my new X Space interview series where I'll be chatting with interesting people in the realms of entrepreneurship, art, and research. And they're all people who I find are either straddling the edge of innovation or living on the edge between two worlds. So I'm gonna try this out for a few episodes. If it's well received, I'll continue onwards. The format I'm gonna start with is have 1.5-ish hours with questions and chatting with my co-host, and then open it up for questions in the last 30-ish minutes. So it should be a 2-hour thing. The initial thread that this is on, or the latest thread that's on my timeline, You can post questions there and then I'll ask them as well. And the last 30 minutes I'll open the floor and anyone can speak. So that's the format I'm gonna try. We're gonna see how it goes. I would love feedback from anyone who's listening to this. And it will also be recorded and it'll be up on Twitter. Or X, whatever. It's still Twitter to me forever. So cool. This first episode is with Alex Klarfeld. He's a really good friend of mine from when we were wee little computer science majors at Carnegie Mellon. And then after working as a software engineer at companies like SpaceX and Cisco, he jumped into the world of entrepreneurship and is currently at a second startup called Supergood. So we'll jump right into it if that sounds good. Alex, sweet. How did you get into tech? What made you want to study computer science? Alex Klarfeld Small correction. I was not the esteemed computer science major. I was electrical computer engineer. Karina Chow Electrical. That's right. Alex Klarfeld Sorry. I can't claim the same degree, but it was— I actually didn't really understand software when I got into college. I didn't really understand it was a job. I understood engineering as a concept, but I grew up in Northern Illinois and there just wasn't a lot of tech out there, but I was really into space, so I just wanted to work on rockets. So in high school actually, I interned at NASA. I worked on the Ares 1X rocket, which was the precursor to the SLS, but it was canceled back in 2008. And then I ended up working at SpaceX in college on actually something totally different. It was power systems for Dragon, which is the capsule. So that's honestly the world I knew. And then it wasn't until CMU where I just didn't really understand what startups were, what software engineering was, but all my friends— I had just learned about Y Combinator from a friend of mine where these two older guys we knew had just got into Y Combinator in 2010. I thought that was cool because I had no idea what it was. And then I really had not been to California before college and followed some friends out here just because I wanted to see what it was about. And then kicked it off from there. So that's, I guess, how I got into software in general. Karina Chow Nice. And you started off doing obviously electrical engineering, more engineering work, and interned at SpaceX. So what made you want to go more in the software direction instead of staying in that direction? Alex Klarfeld I think it was a skill issue. Hardware engineering is hard. Honestly, I feel like every software engineer eventually wants to go back into hardware, myself included. I'm a hobbyist— that's relatable— electronics engineer. I own all the dev boards. That's the fun stuff I like to hack on. I studied embedded systems, so I was set on writing software for embedded code. And I just thought it was cool. I thought programming was cool, especially when it had the intersection with hardware. And that's also— so I joined, it was called Meraki at the time, and then they got bought by Cisco. But that was the idea where it was, hey, you can write software for hardware. And then your classic first job out of school, they're like, JK, you don't get to touch hardware at all, which is fine. But I got thrown into just regular application development after that by virtue of my first job. And I really enjoyed it. I think of engineering in general, specifically software engineering, as a means to an end. I like building stuff, generally speaking, and it just so happens that software engineering is the tools I have. But yeah, I feel like in a different life I'd be working construction or something. Karina Chow That is such a familiar story though. I've heard that from so many electrical engineers where they end up starting at some company where they're told they're going to do electrical engineering and they say, "Haha, just kidding, it's software." Yeah, that's pretty much it. Alex Klarfeld Because there's basically, I feel like at any of these companies, SpaceX included, there's like 3 people at the entire company that know everything that you need to know about embedded, and everyone else is just supporting them. So I think that's how everything gets thrown together, or how you get thrown into software jobs. Karina Chow And I do think it was funny earlier that you're like, ah yes, not the coveted computer science degree. And I'm like, oh man, but I always found electrical engineering way harder personally. Alex Klarfeld Okay. Karina Chow Go on. Sorry. Alex Klarfeld No, no. It feels like a different skill set. I was pretty— I wasn't great at analog circuits, but I really liked the system level, which is the computer part of the degree. So a lot of the— I wrote a lot of x86 in college, which was fun, I guess. And it was not fun at the time, but it's fun now, I guess. Karina Chow It's that type 2 fun, at the time you hated it and you look back and you say, wow, what a great time. Alex Klarfeld That's right. It sets you up foundationally for everything else you want to build if you get as low as possible in the system. So I really valued the learnings, but definitely kept abstracting as fast as I could. Karina Chow Right. And then, okay, so you end up in software land. And then you also ended up founding a company and then a second company. So how did you go from typical software engineer to doing something that's real estate related and now what you do? Alex Klarfeld Yeah, it's fair. So it was cool. I started Meraki and I really loved the people, but I signed an offer with them. I wanted to work at a startup, but I didn't know what that meant. It sounds weird to say now, but I just truly didn't understand the concept of that. So, I joined Meraki thinking it was a startup. And then 5 days later, after I signed my offer, they got bought by Cisco. And they're already a big company, which is kind of large, but I had this thing in my head that was like, I want to start a company or join an early-stage company. So, I left Meraki after a year. I was in San Francisco, and then tried joining a few small startups that ended up— it was an interesting experience. Again, type 2 fun, but it never went anywhere. And then I decided to venture off on my own. So I had built some apps. I wanted to start a company, but I didn't really know what to do. So I just built some apps or something. This was 2016. And one of my friends from home who worked for a VC— I was like, oh, I hear you're supposed to pitch your apps to VC. So I talked to him and I was showing him some of the stuff I built and he was like, yeah, this stuff's really cool. And I was like, awesome, is it a company? He's like, no, none of this stuff would be a company, but would you wanna work for us? And I was like, you guys have jobs? I don't really understand, but VCs have engineers work for you? And he's like, yeah, we have— They had this startup studio, it was called at the time HVF, and it was run by Max Levchin, who's the co-founder of PayPal. He's also the guy that infamously fired Elon from PayPal. And they offered to hire me as an engineer who worked at the startup studio. And my job was they would have an entrepreneur in residence come in and they had some vague idea. In this case, it was real estate. And my job was to help build and validate the idea. So Brian Ma, who's the original founder of Divi, came in and was like, "I want to do something in real estate." And I was an ambitious engineer, so I'm like, "Sweet." I don't really know the first thing about real estate. So someone threw me a book on mortgages and I read it and I was like, "All right. I think maybe I understand what we're doing." But the idea behind Brian's original idea for Divvy was, is there something between renting and owning a house? Is there some middle ground? Again, this was 2017, early 2017. So none of the stuff that's happened now was even foreseeable, stuff being interest rates and things like that. So we started Divvy out of the startup studio that was run by Max. And we worked out of, Max was CEO, he still is CEO of Affirm. Founder of Affirm, the buy now, pay later company. So we actually worked in a small cube section of desks inside of Affirm's office. And then we built this company Divvy. The original idea was, there's something between renting and owning a house. So we started iterating on that idea in the first version, and we put the founding team together as we went. So it was me, Brian, and my other friend Tiffany, and then added people as we went to the founding team. So the story is fairly interesting as the company grew. And then we started on this idea of fractional real estate, which is trying to ease up into what Divvy is today or what Divvy was. So the idea was, could a couple roommates co-own a house together? And that was the first idea. It was whatever. No one really liked it. And then we landed on this different idea, which was can you help renters buy their first house by essentially letting each part of their monthly payment contribute towards a down payment? So the idea was you find renters who want to get a house and then you help them build up equity in the home over time. And that was what ended up working as we started trying all these different ideas in real estate. So at Divi's peak, we owned between 5,000 and 7,000 houses, we owned the houses outright and we rented them back to our tenants with this side contract. And at our peak, we were buying like 1,000 homes a month, which meant that every day we would buy at least 30 to 40 houses. I think in the end it ended up being like 2,000 renters eventually bought back. I think the story's still going because a lot of those folks are still working towards buying their home back. But yeah, that was a quick way of explaining Divvy, but happy to go into more detail. Karina Chow Yeah. I have two different avenues to go down now too, because I think one is, there's always something really interesting to talk about the experience of being in a startup studio. And all those different ventures. I think there's a lot of interesting stuff there, but obviously there's some interesting stuff about Divi. But let's start with the startup studio thing too. Alex Klarfeld Yeah. Karina Chow What was your— and I think what I would find interesting to hear is what is it like to be an engineer in such a setup where they just give you, hey, you are now a founding engineer of this startup that we already— I mean, they already fundraise, or they already fund it, right? Because it's made within the venture capital firm, right? Alex Klarfeld Every startup studio is different. So Divi actually, it was funded where they paid us, all the founding team got a small salary and we got resources to work on it, but we had to actually raise venture after that. Spun out. And so it wasn't a given that we would raise money out of the startup studio, but the idea is you're set up for success. There's a lot of other companies or a lot of other— not a lot, honestly. There's not really that many startup studios anymore, but every studio has a different model. What's the Mike Spicer one called? It's like, he hits nothing but home runs. They go really deep on an idea like Snowflake was, and I think Observe was their latest venture. And then— Karina Chow Yeah, that was Sutter Hill Ventures, right? Alex Klarfeld Sutter Hill. Yeah, Sutter Hill. That's right. And they just have a totally different model where it's just run by one person where the team would have this very core thesis. And I think there's a couple others in between. I think Sutter Hill is probably the most famous one where— I don't know how many successes they've had, but they're the untouchable in the space and everyone else has different stuff. So we spun out Divvy, which was figuring out something between renting and owning a house. And then there's another company that's still active today called PathPoint, which is wholesale brokerage insurance. I'm going to butcher what it is, commercial insurance. And then another company, it was a bank, spun out called Hellman Bradley, and then a few other smaller projects. But it wasn't always dictated by Max, who was the owner of the startup studio. The ideas came from a bunch of different places, but just a different model. Karina Chow Got it. Yeah. I remember I talked to you a bit last year because I was talking with Sutter Hill Ventures and potentially looking to be an engineer in residence there. And yeah, their model is very much ideas come from within the VC itself or the startup studio itself. And then they give it some preliminary funding and help staff it, right, with their engineers and designers in residence. So it is interesting. There's this whole gambit of a huge gradient of how involved is the venture firm versus they just help you get started, but you still have to vie for funding, which just sounds like what you had to do. Alex Klarfeld Yeah, it is very different. Sutter Hill is really cool. HVF was really cool too. Max is an investor in Supergood too, and I don't think we could have built it now without Nelly and his support. Nelly's his wife. They run the Venture Studio together. Karina Chow Cool. And going back to Divi then, you founded Divi with them. How was that whole experience being an entrepreneur? What were the main learnings from being, previously an engineer at all these— I know Meraki was a startup and then acquired very shortly after you joined by Cisco. So I think you probably got that whole experience of being an acquired company, but from being an engineer to all of a sudden being an engineer but also a co-founder, what was that like? Alex Klarfeld It's— I think what's wild, Divi was a wild story in general, but I think the main teaching that I learned is, trying to figure out how to articulate this properly, but this is a core tenet where you just realize that there's no one else available to figure out or solve existential problems at hand. And it all falls onto you where you're like, if you can't figure something out, if there's something that seems insurmountable, there's not really anywhere to go. So you just have to internalize those problems and run through walls, which was a hard learning. If you're working at someone else's company or an established company, you take for granted not only the resources that you have, but stuff that's already figured out, stuff that just seems impossible. And that was Divi where we were doing something that was pretty weird and there wasn't a playbook on exactly how to do it. So you just had to keep powering through and figure stuff out. For example, one of the things that I was responsible for was buying homes during COVID. So to give you a sense of scale, COVID, the housing market went bananas and we were in the business of buying homes, and we would outright own the homes, and we would rent them back to our tenants with this side contract. And at our peak, we were buying 1,000 homes a month, which meant that every day we would buy at least 30 to 40 houses. So every day I would have standup. It was me, and again, it was a small team. So it was me, our data science lead, who's a good friend of mine, and our entire sales team. And we'd go through the houses one by one to make sure that we paid the right amount of money. But the question of did we buy the house for the right amount of money is an insane question to ask because especially when the market's exploding and there's not really a good answer because you look at what Redfin was doing at the time, Zillow was doing at the time, and no one really has a handle on this. So we had to— there was no answer and we were spending— the cost of buying 40 homes and paying more than we should have was costing us a couple million dollars a day. So we had to get a handle on, are we overpaying for houses? It was that kind of problem that you can't really look up on Stack Overflow. I mean, you can, but the answers aren't very good. You have to figure out an answer yourself, which was fun. Karina Chow I feel like WeWork is the only one I can think of that did something similar where they're just getting all of these leases and being like, wait a minute, is this a good business? Alex Klarfeld Yeah, we were. So that was the cool part of Divvy, I truly think that we bought homes for a fair price and we never got left holding the bag in terms of overpaying for houses to sacrifice stability for growth. But it exposed this wild underlying— I don't want to call it math, but it is. I guess they would call it math of appraisers and homeowners trying to figure out what a home is worth and that being so unscientific that it's actually crazy that our whole economy is basically based on this. Karina Chow Yeah, it is crazy. I think it is always interesting to look at the housing market and with appraisers and everything and just how do people value certain things. Yeah. It's not at all an exact science. Cool. Wait, so from this whole experience, sounds like you didn't necessarily want to do more with real estate afterwards. So how did you end up choosing your next company and what was the inspiration for Supergood? Alex Klarfeld It's funny, I actually love, I still love real estate. I find it very interesting. I don't own a house, but I would like to someday potentially. And I thought the whole real estate economy is very interesting, especially with the agents. And when I say agent, I mean a human, a real estate agent dynamics. And then we catered towards a demographic of folks who were— our primary customer were working class folks, primarily the Midwest and the South that didn't really have the credit score needed to buy a house or to get a mortgage. But they were close and they were— I just thought that demographic of people to work with and to help was very relatable. It was my own family growing up as well. So I actually did want to start a company catering to the same demographic as we were helping at Divvy, maybe not in real estate, but I still loved real estate. So I actually left Divvy with the intent of starting something new again. And I honestly was playing with this idea of how do you— One of the hardest problems is credit score and all these folks had credit scores that are all over the place, but by all other accounts, they were very reliable tenants who were pretty close to homeownership. So I was actually playing with ideas in terms of this concept of what if there was a different way to evaluate credit, which is, to be fair, a little bit of a tired idea now in fintech. Everyone's trying to reinvent the credit score, but I just thought the problem was very interesting. So I played with that a little bit of just trying to figure out what does it mean to solve that problem? And then honestly, Divvy was still growing and I was burning into savings. So I was like, okay, I should probably start a side project as I try to figure out this grandiose idea. So I started this project, it was called SuperGood at the time, and the idea was— It was a problem that we ran into at Divi, which was we had a million API vendors that all charged us obscene amounts of money for various things. And it always broke all the time too. And I would get yelled at for the vendor breaking. And I'm like, obviously I can't do anything about this, but it was super annoying to just instrument every single API and figure out what's charging us too much, what's breaking, that sort of thing. So I started the side project of Supergood that was, the idea was you drop us in and we observe all the outgoing traffic that's going on your system and categorize and classify the network calls to give you a very clear idea of what APIs you're spending money on and what works. So I was playing with this as a joke at night, this side project that I thought maybe would make a little bit of money as I figured out the company I was trying to start. And I just kept building it. And eventually I was telling people all this fourth credit bureau idea and so on. And they were like, yeah, it's cool, I guess, but I don't really know what you're gonna do with it. And then I was like, oh, I actually have this night project that I'm working on that just monitors API calls. And people really liked that. And then I got, unprompted, a term sheet to start a company off of this API observability concept. And I was like, if enough people like it, it might be a viable company. So I took the— I signed the term sheet and then started Supergood. And the original idea behind Supergood was this product you drop in and it monitors and tracks all of your APIs in terms of cost and efficacy. The company's evolved much since today, but that was the original idea that I raised money on. Karina Chow Okay. For, I think no one else in this room is in San Francisco. So I think, who are you talking to that you just get prompted a random term sheet? If you're not even really looking for funding, how can we replicate that success? Alex Klarfeld It was definitely weird. I left Divi and Divi was a rocket ship at the time. Divi eventually was worth a couple billion dollars on paper. Again, this has changed greatly, but the company was growing so fast and I was a co-founder of it and I had left. You just start getting swarmed by venture capitalists when this happens. You just get reached out to a lot where people are like, "What are you doing next? What are you doing next? What are you doing next?" And I was fortunate enough to be in a position where I was like, "I guess I'm working on this thing." to land a term sheet. So it was very weird and very specific to what I was doing, and I can't claim it's always replicated that way, but that's what happened. Karina Chow So have one pretty successful startup and then it's much easier to be a serial startup entrepreneur after you have just one. Is that the— Alex Klarfeld Yeah, it's all about narrative. Divi technically sold for $1 billion, but there's a big asterisk about how it actually went about. So the good news of Divi— I was raising money when Divi was still allegedly headed into the stratosphere. So I think the timing was pretty good. But stuff comes back to earth eventually. Karina Chow That's a good way to put it. Cool. Let's see, when was this first term sheet for SuperGood and what does SuperGood do today? Is it the exact same thing? Alex Klarfeld No, no, actually. The term— I raised money for Supergood in July 2023. The idea was we're going to monitor your APIs and tell you what's wrong with them. So I started building that product more out and hired a few engineers to help me out with it and start trying to sell it to customers, being like, hey, you drop us in and we'll tell you what's wrong with your APIs. And then it turns out that people were like, oh yeah, this is a cool idea. They would say nice stuff when you asked them, but no one actually pulled the trigger and bought the software, which was a huge bummer. No one wanted to buy it. So I realized that pointing out problems with APIs is pretty much a nice to have. I think they call them vitamins, not painkillers in the zeitgeist. But there is value in actually fixing them because we constantly— they drop us in and be like, hey, your API is broken. And they'd be like, okay, so what do we do? And I'm like, yeah, that's a very, very fair question. And I really didn't have an answer to it. We built a really cool observability product, but we weren't adding a ton of value in terms of, what do you do when the API is broken? So I struggled with this existential question for another 6 months of just, what do you do if an API is busted? We had this one customer that really loved us and loved the observability part of it. And we were trying to figure out why they liked us and other folks didn't. And I just rolled up my sleeves and dug in and realized that our observability stuff was monitoring their in-house scrapers and these weird reverse-engineered integrations that just powered their business. So I was like, oh, this is cool. And I just offered— I'm an engineer, so I was like, I'll build more of these for you if you guys want. And they're like, yeah, sweet. So I just manually went in there and was helping this customer build— there were scrapers at the time and unofficial integrations. And we hit the tailwind of code generation just starting to take off. It seems silly now, but this was only about 2 years ago, it was like August of 2024 maybe. And I started to realize that we could do a lot in terms of spinning up these APIs really quickly. But there was a ton of value in the existing observability platform because the hardest part about all these unofficial APIs was actually maintaining them if they broke and had any changes. So what we did was redid the platform so that the premise was we were spinning up these unofficial APIs, and we found this real niche in unofficial APIs that are specifically behind a login in front of enterprise portals, because we were getting a ton of requests for that that folks weren't able to crack. So once we started building that, we realized that the observability platform was super valuable in terms of understanding if the underlying network calls changed or something like that, and we could repair it really quickly. So that's how the idea evolved, was really just rolling up our sleeves and working with whatever few customers we had and growing it from there. Karina Chow Nice. Well, that's always good. It's always good when you have a super fan of a customer that can help shape the direction that your product goes and you're like, yes, this is working. Alex Klarfeld It's really hard, easier said than done. Everyone said no to us, like, this sucks, I don't need this at all, which is very fair, but we learned it too late in the process where you're just like— I think the biggest learning was you can ask people for feedback on your idea and they're probably going to say it's a good idea unless they're an engineer and they're going to say no. But most people are nice and say yes, but the real tell is if they'll actually put their credit card down and actually buy it. I feel like advice is fairly cheap. Folks are always willing to give feedback or something, but the real feedback is when they actually put some skin in the game. And I think we realized that much later than I would've hoped. Divvy was a consumer product and everyone sort of wanted it, but the enterprise sales is very different than what I was used to. Karina Chow Well, what would you think for enterprise sales, right? At what point could you have gotten that feedback earlier? Alex Klarfeld I think you basically push them to pay or install it or do something that's meaningful. With Divvy, this is gonna sound crazy, but the tell was when we weren't getting back to people on time on the phone. So they were like calling us 'cause we weren't getting back to them in time and trying to aim for that similar signal inside of enterprise software where it's like we install something and they keep hitting us up and asking us more features on that. But they have to put some skin in the game first before doing it. Karina Chow And then how do you get them to put skin in the game, though, if you're really early stage and you're still figuring things out? Alex Klarfeld The— this is the simplest answer, which people told me that I didn't really understand. But as an engineer, it's really weird to ask people to pay for the thing that you built. It's very uncomfortable. And I think getting over that fear and asking people to pay for what you built, even if you haven't built it yet, is super powerful. People say, we didn't do this, but I would have done it if I was smart at the time of like, hey, this isn't built yet, but would you pay for it? And are you willing to pay me right now for something that we ship in February? And just getting them to sign something that they would agree to pay you for is huge. It's all the signaling you need. Karina Chow True. What kind of assurances can you give them though? Because obviously no one wants to just part with their money for something that doesn't quite exist, right? Especially in a realm where the vaporware is super real. Yeah. Alex Klarfeld It's pretty straightforward. And we do this today with Supergood, which is just— try it for free and then you basically have an agreement that if it meets all the requirements that you have, then you pay us and if not, you're free to walk away. But even getting someone to agree to that, even if you're giving it away for free for 14 days or something like that, but the agreement is at the end of the free term you pay, that's still huge and it gives everyone the assurances that they need. But asking for that is hard. Karina Chow Oh, yeah. I think as an engineer or any type of builder or maker, all of us have that. We're not salespeople. We don't want to sell things that don't exist yet. We want to make sure our product's excellent, right? Yeah, exactly. I definitely think a lot of us suffer from that. Alex Klarfeld Yeah, getting over it is tough, but it's really important. Karina Chow So now that you've moved from, let's see, more monitoring of APIs and how they're doing, more into the realm of helping develop these APIs for unofficial APIs, for APIs that kind of exist but kind of don't— how has it been working with— what AI tools do you use, or what is it like using AI to help create these unofficial APIs? What are the difficulties that you've had? Alex Klarfeld Yeah. Karina Chow And what will that look like in the future, you think? Alex Klarfeld I think the best— the way I think about the best AI products, including my own, is they're really just codified experts. The best tools are like someone has taken the entirety of something that they're specifically really good at and turned it into— previously it was code, but now it's LLM-powered code. And I think that's the real thing. In our example, we're really good at reverse engineering platforms, both from an authentication perspective, like CAPTCHA solving, MFA, that sort of thing. And it's a little bit of an art rather than a science. And our product basically codifies the act of reverse engineering to make it approachable for any engineer or really non-engineer on that capacity. So I think the best AI products are someone codifying expert knowledge into a tool that's easy to use for the masses. And I think that's how it's going to continue to evolve. I think software engineering is no longer an expert skill, unfortunately, or at least the software engineering that we knew. It's really always been a means to an end, but it's no longer a moat because it's so cheap now. But I do believe that specific types of software engineering end up being moaty, so to speak. I just feel like a lot of the future of a lot of these LLM-powered tools is just taking some expert knowledge— maybe it's embedded software— and building a tool that makes it really easy for anyone to do this without specialized knowledge, I think is where we're headed. Karina Chow Yeah. Well, I like this idea of something being moat-y, like having a moat around it. What kind of software engineering do you feel is more moat-y, if you will? Alex Klarfeld It's biased. It's all the stuff I don't really understand, but I feel like— it's funny to say, and I don't know how big the business is, but COBOL is still a huge part of all of our main systems. So I don't think any— I could be wrong, but I would be surprised if Claude Code or anyone was really proficient at writing COBOL. Similar to embedded systems, that sort of software design. And I just feel like there's these very specific areas of industry where the software engineering combines with the vertical that it's in in order to build this pretty interesting dynamic. And I feel like those are moatier than others. For example, a simple one is I don't even think Claude Code is that good at iOS development right now. There's still some alpha to be solved there. It might get there eventually as the AI flood comes in. But right now I don't really think there's a good specific Claude Code for iOS. I could be wrong, but that's the sort of places that I'd be looking. Karina Chow Well, that was the next question I had too, where they're moaty right now, but seeing how much things have improved in just a few months, really. Like, I feel as though, what would keep a COBOL developer or iOS— what would keep Claude or any other LLM for that matter from being really good at those? And are there others that would be moatier to Claude altogether for some reason? Alex Klarfeld I think it's just the data, the training data that it has. Data was always a moat. So I think specialized knowledge and training data— open-source software has made most web development stuff fully available on the internet. So it's really easy for these LLMs to pick it up and learn from it. But I'd be curious to see the stuff that's not on GitHub, buried elsewhere, that's just hard to get at. And maybe there's also just not that much data on it, so it might be hard for an LLM to be fully trained on it. Outside of COBOL and embedded systems, and I think some even lower level software systems, I think there's definitely room for it. Basically I think anyone could do anything if there's focus in it, but I don't think anyone is truly safe, but I don't think anyone was truly safe from software in general before LLMs. Karina Chow Totally. So I think, in this world where you're in a company that doesn't use COBOL or any of these lower systems— for you, when you're looking to hire engineers, right? It's no longer just a, hey, how great did you do on this random assessment, whatever it might be at the time. What kind of attributes do you think makes for a good engineer these days, given that LLMs can do a lot of heavy lifting? Alex Klarfeld I've been thinking about this a lot. In the world that you and I come from, the way I think about it is there was two tracks, and there was a hybrid third track. There was the IC, and then there was the manager. But there was always this intermediary role that every engineer would do as sort of either assessing— they would go into one of those two tracks, and that was the tech lead, where the tech lead was this engineer who could go really deep on specific technical knowledge, but also had to pseudo-manage the people and the products and the features that they would have to deal with. And so they would have to have good systems knowledge, but they also have solid technical knowledge. And they'd also have to have good product instinct, dealing with requirements coming from product managers and those types of interviews. We're looking for— like hiring a tech lead or even a general senior developer, I would always ask them systems level questions, which is less about— I don't think I really asked too much LeetCode or whiteboard coding. It was more asking them to walk me through a complex system and how they would design it at a high level and then be able to laser in on specific aspects. I feel like the systems design questions are what will distinguish engineers who'll be good at utilizing LLMs and agents versus not. And I think everyone just has to become versed in system design at this point because the way I think about LLMs is just another abstraction. Where it's like, okay, at some point we stopped writing CSS where we had all these libraries and then we stopped writing HTML once we had React. I think we're just at another level of abstraction— given it's a huge abstraction going from React components to fully isolated functional parts. But that just makes the system design and the interconnectedness and being able to dig in and really evaluate these parts so much more important. And I don't know if the abstraction will stop. But right now, it's just another abstraction on top of engineering. Karina Chow Yeah. And I think that brings up the question too of, how does your team at Supergood utilize AI in your workflow, right? And if you're aiming for people who have really good systems thinking, how do you approach using AI with that level of thinking? Alex Klarfeld We're in a fortunate spot where our product— you can think about it oversimplified— is a tool that uses LLMs to generate and then keep code maintained in a system. It's very specific, like reverse engineering code. So all the products we build, we end up having to use as dog food. So we use the Claude Codes of the world and things like that. But most of the stuff that we invest in are the rails around it, which is just— how do you actually build the system manually? How do you implement best practices? And then honestly, throwing an LLM at it is the easy part. The hard part is just ensuring that the LLMs and everything have all the context that they need. So every engineer on my team has to manually reverse engineer APIs before they can even use the tool just so they— and it's a little bit of hazing, but just a way of knowing how this stuff works in the nitty-gritty and where the LLM fails and where it's good. And the parts that it fails, what can we build in order to support it? My favorite, and hopefully vicariously through my team, part of dealing with LLMs is trying to figure out what they're horrible at— and they're bad at a lot of things. And those are the fun parts of trying to figure out what they're inherently bad at that you can then build for in order to make it easier for others. Karina Chow Yeah, actually this is fun. Walk us through what this typical workflow looks like because you're reverse engineering some kind of API and you have no idea what the shape of the API is, how it works, what it even returns necessarily. Could be something totally different, right? And you were saying earlier trying to create an unofficial API that's very usable and for the masses, but I'm curious what kind of heuristics or something you might have that determines whether or not it's very usable. But once you figure out the shape, how much research goes into that? And then what is this process to use AI in your workflow to come out with this unofficial API? Alex Klarfeld Yeah, let me try to break it down. The goal, the end goal, the result is you look at any normal RESTful API that a company puts out, and that's the experience we're aiming for with everything. So it's REST calls, the idea is it's ergonomic enough where you use it. You don't really think about it as an unofficial API. But to get there, the way that— yeah, go ahead. Karina Chow I was gonna say, does Supergood have— do you guys have your own standard of what those unofficial APIs look like? They all kind of feel the same, feel like the Supergood API, it just happens to be for different things or— Michael Fitzgerald Yeah. Alex Klarfeld Yeah, we try to, and it's tricky because every customer has some— if you think about a spectrum of you're just shoving up raw network calls or raw pages to instrumenting full business logic on top of the APIs, we try to stay as close to the raw network calls as we can, but there is an interesting gap of what is a schema that is easy to use. So it varies by customer, but we try to err on the side of atomic endpoints that capture a core function that a normal endpoint would capture. So it's an atomic write or atomic read without any side effects. And we give our customers the full suite of APIs based on these atomic functions. And the way that we do it is— typically a customer will give us, say like, hey, I want to build an API for this enterprise portal. And we say, all right, we have this concept of service accounts where we can generate a user with an email and a phone number for MFA that we ask them to add to that portal to give us access. And that's basically the user that we use in order to API-ify, if you will, that portal. So once they have that user in the portal, we basically ask them to— or we'll do it— log in to that portal. And then what we're doing behind the scenes is essentially recording button presses, network calls, page loads, and trying to map it to a template that's like, what does a login flow look like? And it turns out once you've seen a few login flows, they all match this same paradigm. Everyone builds login flows the same way. And then we generate code that's essentially fully instrumented so that network calls, page loads, everything is logged in the Supergood system when you're making the call in production. That way, if anything changes, it's fully visible to the customer and we can fix it fairly easily. First we tackle auth, that's a big one. And then we're basically reverse engineering auth to figure out what are the credentials that are going on behind the scenes— what are the cookies, what are the headers, that sort of thing. And then we basically ask the customer to perform an action that they want to do in the portal. Maybe it's create a work order or fetch documents. And then it's a similar concept where we record the network calls and the page loads, button presses, that sort of thing. But behind the scenes, we've built a ton of these reverse-engineered APIs. And then the concept is once you've seen one ASP.NET platform, you've kind of seen them all. So the LLM is essentially looking at reference integrations that we've already built in order to construct what a standard API looks like. In order to do this, we had to manually build a lot of these. But basically feeding the LLM examples plus the recording that the customer gives us lets us spin up this API fairly quickly. Maybe there's a few QA steps that we have to do, but nothing usually too crazy nowadays. And then it's instantly deployed into our platform. And then, because every API call is fully instrumented, we basically have a triage bot that's constantly monitoring every network call and every API call that's going through. And if it detects any changes, it figures out, okay, is this a user error, is it a system error, a customer error, and then tries to fix it based on what it sees. And adding more into that observability and maintenance aspect of the product is actually the most important. Reverse engineering's cool and all, but the real value add is how do you actually run these in production in a scalable way? Karina Chow Yeah, no, it makes sense. This is such an interesting workflow because this is so different than what we would have done even just 2 or 3 years ago. Have you found any crazy pitfalls or anything with— and are there certain aspects that you keep trying to improve in this workflow? Alex Klarfeld I think one of the funny things— and I'm biased towards this— is there's a lot of folks out there who are doing something in the same space, but they're all doing it with browser automation, which means that they're trying to accomplish some tasks inside of an enterprise portal, but they're spinning up a browser to do it. And browsers are meant for people and they're really slow and they're really flaky. And so constantly we get a lot of customers of ours who are just like, yeah, I tried using this with browser automation and just doesn't really work. And it will work functionally, but if you're trying to run 20,000 calls a month or something, just doing the same task over and over again, the browser really doesn't make sense. I think it makes sense in the consumer world where you have a browser go off and do some sort of thing that requires decision-making, but in our world, we're really just trying to replicate tasks to perform fast and reliably. And all we're doing is looking at the stuff that populates the browser view that the humans see and cutting out all the chaff around visual loads, CSS, that sort of thing. So it's not a pitfall that we run into because we're solving against that, but most of our customers run into it where they think they can— not even think, but they try this with the browser first and they realize that it's wildly inefficient, and then they come to us. Karina Chow Has there been any— obviously, name no names— but has there been any particular API where reverse engineering it has been an absolute disaster? Or maybe what are some of the most common disasters you see? Alex Klarfeld It's very interesting. I'd say it's not a disaster, but the probably hardest are healthcare portals, like EHRs, electronic healthcare records. It's two things. They're just built with a lot of regulation in mind, which makes sense. Basically every interaction that you perform on an EHR is logged and we don't bypass any of that. Everything is logged as if you were a person, but because they have such strict regulation around it, the reverse engineering aspect is surprisingly interesting, especially in the older systems where certain things will be locked down that you don't really expect. Like session management is managed on the backend instead of the frontend. Weird things that— I think healthcare is the one industry that we've seen that's very different than some of the others, specifically in how the software is built. 'Cause that's all we're looking for is how is the software built? All the other industries are the same in terms of building software because it's much lower stakes. Anywhere from legal tech to prop tech, you're not dealing with someone's medical records. So the software is built as you would imagine a regular web application would be built. Karina Chow Because you get to see so many different— well, you're working with so many different industries, right? You have to— you've seen APIs from, like you said, legal, from real estate, from healthcare. Are there any that, as we're changing the way that we work to utilize AI more and more, are there any there that you see there could be huge gains in how they build their sites and how they build their products? Alex Klarfeld It's so interesting. I don't want to get on too much of a legal rabbit hole, but these massive accompan— there's always a massive piece of software in each industry that Bogarts the entire system. Famously, I'll just, I feel like it's open data, so I'll just talk about it, is the automotive dealership industry. There's this concept of a DMS, it's called a dealer management software. And there's two giant players, two companies that sell dealer management software to every car dealership in America or in the world or something. And this ecosystem is huge. They have so many customers, but they're just not innovating and they're not going to innovate. So the car dealerships are stuck. Anyone that's worked at a large old-school company knows how hard it is to rip and replace a system that is their core core brain and the core operating system. I don't know how many people have walked into a startup and been like, we're not using Salesforce anymore. And then been like, yeah, Salesforce is ingrained. That's the thing with these deal management software. But what ended up happening was they weren't innovating and they were starting to do crazy stuff like charge their customers more for API access, even though they had all of this access to the data. And they actually all got sued for not only charging customers more for API access, but also just blocking API access because all their customers wanted to do was use their software, but automate and innovate on top of it. And these dodgy companies just wouldn't let them. So they got sued and I don't think they admitted wrongdoing in any means, but the settlements were insane. I think the integrators, people like us who were trying to integrate with this dealer management software, settled for $690 million because they blocked access so aggressively. It's a long way of saying it would be cool if these older software companies decided to start innovating, but it seems like they don't want to. They're getting sued for antitrust violation right now because they're blocking innovation by way of API access, which is really just an anti-competition play. So it's going to be really interesting, honestly, from the legal perspective to see how all this stuff pans out, because historically people are like, oh, you can't do this, it's against the terms of service, which is true. But the terms of service is invalid if the company, the software company, is participating in antitrust violations. Karina Chow Dude, that's crazy. I had no idea about that. It makes me think also there's a— I had a client once that was in freight trucking, and there's also a similar monopoly type of situation with the way that truck drivers are allowed to pay for fuel repairs and lumber fees. And I don't think they had settlements quite that huge, but there was something very similar there where they just wouldn't allow any other types of payments and they had to use a certain system. Yeah, all these very hidden systems that, if you work especially in pure tech, you just very rarely see. Alex Klarfeld It is crazy. And we get asked this all the time, is this legal? Isn't this against the TOS? And what I always say is, go to this company and ask for API access, and they're probably gonna say no to you, but then ask them why. And if they don't have a good answer, the reason why they don't want to give you access allegedly is they don't want you to compete with them. But that could be a violation of antitrust law if you're not giving out access of your own customers' data to your customers for any reason that's not for anti-competition. Karina Chow Right. I think people just, a lot of these companies, they know that they are the only answer, so they'll just gatekeep as much as they can. Alex Klarfeld Yeah. And times are changing. There's some massive lawsuits going on right now against some big software companies on the grounds of antitrust in this space. It's pretty interesting to watch. Karina Chow And how does that affect what you're doing? Because you said you can't get access to certain APIs perhaps because of these types of companies. So how does that— I guess you always have to keep on your toes on everything that's happening in multiple different spaces. Alex Klarfeld The way that we work is customer comes to us and is like, hey, our customers want access to their own data. They have all their data in this property management system or something and they just want to use our tool in conjunction with the tool that they pay a lot of money for and they use. That's it. And we turn away anyone that's not doing anything nefarious or potentially nefarious. It's really just— customers come to us because they want access to their own data and they want to automate it or something like that. And we enable that level of access. But the first thing I always ask is, can you get API access? First and foremost. It's usually like, no, they won't let us or no, it doesn't exist. And then it's like, do your customers have a right to their own data? Yeah, obviously in most cases. So all we're doing is enabling our customers' customers or direct customers to be able to automate and adapt to this new age of automation and AI where they're— and still use the central brain that they want, which is these giant software companies. I don't know. I think we're doing them a favor, but obviously, depending on how you look at things, they might not like it. But it's not for any good reason, at least. Karina Chow Yeah, not good for the customers or people using it for sure. Alex Klarfeld These are people who want to pay for it still. They're not trying to switch software providers. They're just like, I wish this giant piece of software that I can't switch off of would do this one thing and they won't do it for me. So I have to figure out some other way to get it done still while playing in the same ecosystem. Karina Chow Yeah, and that's the thing. I think I was just talking to someone earlier this morning about how a lot of development work, especially if you're back in development, is just all API integrations these days. And so people expect that. They know that that's what they have to do and they want to pay for it. It is really interesting that it's gatekept so much. Alex Klarfeld Yeah, they usually call us when they can't get access to those APIs and they don't exist. If there's APIs that are available and they can access them, I'm like, there's no reason to use us. We're really just the alternative if you truly cannot get access to the system programmatically. Karina Chow So what is your hope and dream for Supergood? If you were to look at it 2, 3 years from now, where do you hope to be? What do you hope the platform is to people? Alex Klarfeld The whole goal of Supergood is to make the web fully interoperable. And also caveat with not via browser. So I'm gonna call it efficiently interoperable. And we're working on this right now, but the idea is, make the art of reverse engineering, so to speak, easily accessible to any engineer who's just trying to automate a job or onboard new customers from a walled garden system that won't allow access. So hopefully soon the system becomes more self-service. Right now, today, customers come to us, we'll build the APIs for them through the reverse engineering means, and all the tooling is exposed to them. But really right now we're just dogfooding the tooling and just to make sure that everything is QA'd appropriately. But we're pretty close. I'd say maybe a couple of weeks away from actually letting some of our customers build the APIs on our platform. And I hope that in 2 or 3 years, this is just a given. Any engineer can sign up and reverse engineer some old school platform that they don't want to deal with directly, and then build some cool automation or tool to make their lives or their customer lives easier. Karina Chow When I think of when you and I talked about Supergood just 2 years ago-ish, my first thought was with the mindset of an engineer 2 years ago, right? Where I say, okay, maybe I'm some kind of developer and I have to develop something. Oh shit, this API sucks. I can use Supergood and they take care of figuring out when that other API fails or all these types of things. And then I don't need to worry about that part. I can do whatever feature stuff that I'm doing. In a world of today, I'm thinking in terms of, hey, is Supergood the place to go when you're building an MCP server or something and you want access to a whole bunch of different types of things, right? That's where my mindset is today. So what is the primary customer, I guess, in terms of who's really consuming the APIs and then what type of systems do you foresee? Alex Klarfeld Yeah. So the idea is you come to us when there's absolutely no API, there's nothing there that you can interact with. Right. That is our go-to. And then, maybe there's a hot take. I think MCP is— it's not a bad band-aid, but it is still a band-aid. There's going to be something else outside of MCP that allows people to utilize APIs. It's just a weird way to build things. So if I were to abstract this even further, it's just, if you want to connect to a system that doesn't want you or doesn't let you connect to it, you come to us and we will let you— well, you'll be able to build these APIs for the impossibly connected systems in a really easy and simple way. But it's meant for engineers to power these systems. Karina Chow For sure. Alex Klarfeld Cool. Karina Chow Is there anything else on Supergood you wanted to chat about, or shall we move on? Alex Klarfeld I think I yapped enough, so I'm happy to move on. Karina Chow Sounds good. Alex Klarfeld Okay. Karina Chow I was curious, since you're working a lot with, as we noted already, AI on the workflow— I was curious, one of the things that's on the top of my mind constantly is how do people break into this industry now with LLMs, right? How does anyone ever get past the stage of being a junior developer? So I'm curious, one, do you agree that it's harder to get into tech in some ways, or do you think it's easier now? And then two, how do people go from junior level to the next level? Alex Klarfeld I think it is harder now. But we have early career engineers at Supergood and they all share the same thing in common. It's not really too different from before LLMs. But I think the best way to break into the industry from a developer's perspective is to really build something on your own, and get deep in terms of the technology that you have. That is it. That's always been it from software engineering is there's only so much you can learn in schools or boot camps or that sort of thing. And I really think that you have to be hands-on with the technology outside of— it's like, vibe coding is great, honestly. I think vibe coding is one of the things that makes more engineers, but you have to be able to see a project through. So that also, vibe coding also includes vibe debugging and that sort of thing. And I really think that the hands-on skills are still super valuable. And the way to break in is to build something that is useful to you and really understand the full software lifecycle, including where LLMs can help and where they can't. And I think that just sets so many people apart. Karina Chow Yeah, I think nowadays, at least, I went back to grad school in my 30s and I was surrounded by people who were 22, 23. And it was interesting to see that the approach to just making something when you don't understand the systems at large because you're very junior level, you just allow the LLM go a little wild, but you don't have enough intuition yet to really ask the right questions, understand the systems that it's working by. I even saw people really struggling with the idea of what a server is versus a client, at that level, right? So I'm curious, how do you balance the understanding the systems, like you're saying, understanding how it's built and then still utilizing or not utilizing LLMs to help build, right? How would you suggest to a junior engineer trying to cut their teeth right now, how they can achieve that balance? Alex Klarfeld I think it's, don't shy away from debugging. Debugging is the skill. It ends up being the most valuable thing. And it's one of the weirdest things that you have to learn, at least in skill. I feel like CMU did a— I guess you could call it a good job of beating this into us, which is just, you're always— at least how I felt in school is, you're always failing and you're always trying to figure out how to get out of failing or solve the problems on your own, sort of run-through-walls mentality. And I think the more that you can simulate the fact that you're gonna have to figure this out, the closer you can get to production level skills development. I don't know if that made sense. It's just debugging. If you're a junior engineer, you get stuck from vibe coding, power through and you'll learn so much in just trying to figure out what's going on and actually solving the problem. Versus jamming out a bunch of features. Karina Chow Yeah, and I think that's always the allure, right? Even when I was with people who were not junior level, I think the allure is always just to make more features and just allow the tech debt to accrue. Alex Klarfeld Yeah, you want to lean into the debugging. You just learn so much. Karina Chow Yeah, I would say that is where my biggest learnings have been. Why did this break? How did it break? Okay, shoot, now I have to investigate. So many parts of the codebase I may not have looked at before. Alex Klarfeld Googling is a skill, right? You need to know what to ask, which before we used Stack Overflow and Google, whatever, but now you can ask Claude. You still need to know what to ask it and the right way to guide it. And that's, I don't know, that's the same set of skills that's invaluable. Karina Chow How do you think, we talked about this a little bit already, just— how do you think the— we were talking earlier about how the role of a software engineer would change, but how do you think how we define a junior engineer will change? Alex Klarfeld I think the expert, it's a lame answer, but the expectations are so much higher. Before we thought of junior devs to take on very specific features and very specific IC role. But I think the junior dev must take on complex systems out the gate, so to speak. I think those are the best junior devs I've seen who can keep all the system level complexity in their brain and also be AI native. The other thing that I don't think people are talking about enough is there are a lot of senior devs at our level that can't keep up with entry level AI native junior devs. From a bunch of capacities. And I don't know why there's a lot of senior devs at our level that are very anti-AI, but they're having trouble keeping up with the AI native population, especially the junior devs that really stick it out and go deep on the stuff that they're building. I think they can easily join pretty senior engineering teams. Karina Chow Yeah, I definitely know a lot of people like that who are— I think it comes to how you view and how you view coding, right? I think if you see it as a means of an end, then I think, and you see coding itself as more of a tool to achieve something, I think you take a very different approach. I think a lot of the more senior-level people at our level who are very reluctant to AI are very much, they see code as craft. And in the same way that an artist might be like, oh, I can't, why would I ever— I don't want AI to create art. Art is a very human thing. I think a lot of people I see very resistant think very similarly about coding. Alex Klarfeld Yeah, I think you're right. I'm not going to comment on the art stuff as AI is garbage and I still think there's room for artists. But I don't know, hot take, code is not craft. It is a means to an end. But the end is cool. I think it is worth coding still or understanding these systems because people are building really cool stuff. Karina Chow Do you feel like, now that it's so potentially easy to make a product, do you think it's much easier to get funding from a VC or much harder because the market's so saturated? Alex Klarfeld I think this sort of stuff ebbs and flows based on the economy, but I really think you can't avoid— good ideas are always good ideas and not so good ideas were always not so good ideas. I'm not going to call them bad, but I think people are starting to realize that coding the code was never the moat. A good idea and attacking a problem, solving it in a clever way and getting it into the hands of as many people as you can has always been the most valuable part of any product or company. It's never been how it works, so to speak. And I think that's the reckoning that a lot of engineers are dealing with. Given there's still huge technological innovation that needs to be happening, but it's probably not happening on a social media app. Maybe Facebook, but you know what I mean? It's not happening on these SaaS apps that were a dime a dozen 5 years ago. It's just happening in different ways. Karina Chow Do you feel like— you talk to VCs way more often than I do. So what would you say they're really looking for? Because people love to joke, ah, if you just put AI in your name, they'll throw money at it. But obviously they're a little bit more selective than that. So is it just what you said where it has to be a really great idea, but then are there certain types of ideas, certain types of trends, certain aspects that they're looking for? Alex Klarfeld I think lots of the idea, it just has to solve a real problem that people are having. And I think it sounds cliche to say, but for example, there's a fellow portfolio company of ours, they built this system that uses— it's LLMs on top of X-ray scanners that scan for batteries inside of recycling plants because when a recycling plant processes a lithium-ion battery, it explodes and the whole place catches fire. It's actually a big problem. So they figured out a clever system to make it really easy for recycling operators to scan for batteries. And sure, they're using AI to make stuff easier, but it's a hard problem to solve regardless of AI. And it's a cool industry. And it's stuff like that where I think are getting a lot more interest in funding, because they're solving real problems that people are having. Karina Chow Totally. I think there was such a period where VCs would— you would see some of the companies that would be funded and you say, this isn't solving any real problem, what is going on? And then everyone screams, it's a bubble, right? But I'm here. So you're saying— does this mean you're seeing a little bit of a departure from that back to looking for what is actually practical, or do you think it was always there, but it's obviously not what the media covers? Alex Klarfeld I think it's the latter. I think you just hear about the crazy successes and they all look the same where it's like, how many Lovable clones do we really need? One of them is going to work. And there's definitely some innovation happening of making app development for anyone. But that's all you hear about. But yeah, I think there are folks solving very interesting problems. Not everything is an AI wrapper. I just think those are probably the loudest voices on Twitter. But I'd say most of the companies that get funded are doing something fairly interesting, assuming it's a reasonable VC backing them. Karina Chow I think a lot of people I know, and you and I included in this to some degree, have a little bit of AI fatigue. Do you feel like there are others around us, especially in the VC realm or the top dogs in the tech realm that feel the same? Are we in the minority? Alex Klarfeld No, I think it's happening. I think there's just a lot of information being disseminated and it's really hard to figure out who knows what they're talking about or not. That's what I think is causing most of the fatigue— anyone can share their opinion and it's not necessarily the correct opinions that are making their way to the top of my Twitter feed. And that's causing a lot of fatigue. Karina Chow I think that's pretty much all I got. I guess my last question to you is just, you touched upon this throughout the space, but what's the main advice you would give to others in industry, whether they're junior, whether they're us, whether they're entrepreneurs trying to find their own company? What's the advice for the future of how we're working? Alex Klarfeld I think if you want to start a company or build a product, find something that you're uniquely good at or have unique expertise in or are uniquely passionate about and go after that. And this sounds cliche, but you can turn anything into anything. And the LLMs and the AI stuff in the world are just tools to do so faster and at higher scale. I think that's it. Be different in a lot of ways and really find something that excites you. I love reverse engineering. It's fun. It's also ended up being kind of weird. Not everyone is going down this path and a lot of people thought it was weird and some people still think it's weird, but it works out well. So just don't be afraid to be an expert and go deep in something very specific that is exciting to you and that you don't think anyone else has this sort of expertise in, and go after that. Karina Chow Yeah, that's great advice. I think a lot of times people just fall into hype cycles, they say, oh, this is the hot thing. I gotta figure, I gotta chase what's sexy, but sometimes the best thing is not what's sexy at the moment, you know? Alex Klarfeld And the cool part is you can do what's passionate to you and it just so happens might fall into what is working in the zeitgeist. I think LLMs just have such wide applications where there's a lot of really creative applications we just haven't seen before. Karina Chow Yeah, totally. And I think in some ways the barrier to entry is so much lower, which in some ways makes everything too saturated, but at the same time it's actually very exciting that you can build almost anything very quickly. Scary and exciting. Alex Klarfeld The cool part for me is seeing folks that aren't traditional software engineers that work in these verticals that we just don't know anything about start to build software. That is really cool because they're not— ideally they're not following the zeitgeist. They're solving a real problem that's specific to them. And if it's specific to them, it's probably specific to other people like them. And I think that's the cool part of LLMs. It's just making anyone be able to solve their own problems very quickly with software. Karina Chow Yeah, absolutely. All right, I'm gonna open the floor if people wanted to chat. Let's see, because I saw Fitz in there, although now I don't see Fitz in there. I just said approve. What's up? Can you hear me? Hey, it still says listener online, but yeah, I can hear you. Michael Fitzgerald Welcome to X Spaces. Karina Chow Yeah, I figured open it up, have some people chat if they feel like it, and then just let it naturally close. But thank you so much, Alex, for having this little chat. I'm still playing around with what format makes sense, so I appreciate that you were my— I appreciate that a good friend of mine was my first guest so I can figure it out. Alex Klarfeld Yeah, it was fun. Happy to be your first guest. Karina Chow Fitz, did anything strike your fancy or have any thoughts? Michael Fitzgerald Just want to hang? Yeah, plenty did. First off, thanks, Alex, for the alpha. Of course. Yeah, it seems like Supergood is well on its way to— what did you say earlier? Efficiently interoperable, making the web efficiently interoperable. That's a pretty cool vision to think about, what's going to happen in the future. I actually do have a couple of questions if I may. Yeah. Hit me. Karina Chow Yeah. Michael Fitzgerald So I've been focused on business development lately. And full transparency, I'm sort of looking for work. And I see that there's a position at Supergood. So that might be something to discuss later. But yeah, my background is in software development and then I transitioned into business development in tech. And so that's the nature of this first question. What kind of business development tactics have proven effective for you in attracting early clients and scaling in this AI integration space that you— Alex Klarfeld it seems like you're in? Yeah, I think the best thing that we did was go— we were so proactive and so responsive to our customers on a human level, that really made our first bout of very devoted customers. We responded to every single issue that they had before they even noticed it. And most of the time they're issues with how they use the API, but that human element of just absolutely white gloving every single customer onboarding and their continued engagement helped us a ton. We could have built chatbots, we could have used support like Pylon, but just adding that super hands-on human element was crucial, very, very crucial. Michael Fitzgerald The hands-on human element, is that what you said last? Alex Klarfeld Yeah, yeah, it's basically every customer of ours has a Slack channel with us and we respond to everything within 15 minutes. Michael Fitzgerald Yeah, nice, nice, nice, nice. How big is the Supergood team, if you don't mind sharing? Alex Klarfeld There's only 4 of us, so pretty small. Michael Fitzgerald Nice, nice, nice, nice. I love— I'm pretty, I think Karina can attest to this a little bit too. I've been in the startup world, kind of slipped into it and now I've been wading around in it up in the Seattle area. I'm based out of the greater Seattle area and yeah, I attend a lot of networking events up here. I'm going to this Cerebris event tomorrow. It's hosted by Cerebris and GitHub, I think. Going to be 200+ people. Actually, have you ever heard of a guy named Gregory Kennedy? Alex Klarfeld I don't think so. Michael Fitzgerald So he's a self-proclaimed vibe marketer and he has this company called Vibe Your SaaS. I've been assisting him with some outreach for an event in the San Francisco area. I'll have to shoot you a link to that. Maybe you'd be interested in going to that. That's really funny. Yeah, we basically had lunch and we agreed to do a little bit of gig style work, which was set up a Dripify kind of thing and use my LinkedIn profile to just blast it out. And it's been so funny. My LinkedIn DMs are just now exploded with all these new connection requests and new connections. So I am now connected to a bunch of people in the San Francisco area. So yeah, I'm doing a lot of outreach on social media. But yeah, my other question was more philosophical, just the future of AI. How do you see— because I've been taking a little bit of notes and let me just read this a bit. You highlighted in your recent post— I like using Grok to analyze the X profile of the people that I'm interviewing, right? So it was like, okay, in your recent posts you've highlighted ideas like AI builders as generalists focused on system orchestration, the inefficiencies of making LLMs use browsers instead of direct integrations. And even drawing inspiration from companies like Zipline for agent-based workflows. So how do you see some of these concepts shaping the future of AI? The idea of having unofficial API integrations and maintaining that, if I'm gathering a little bit about what Supergood is trying to do. Yeah, yeah, yeah. Alex Klarfeld I think regardless of how far LLMs take us, if we achieve AGI or whatever you want to call it, there's always going to be builders. I think builders are always going to build. And I think we're just traversing the layers of abstraction fairly quickly of how deep— basically what are the building blocks that are available to builders. Right now, LLMs have abstracted a ton, but now we think in these building blocks that are miniature systems, but there's still a building aspect to orchestrate between these systems. I don't really know what is the orchestrator for the orchestrator, but I still firmly believe that there's a concept of building. As the LLMs become more and more developed, I think we just get more and more efficient at it. I don't really have an opinion of whether or not AGI comes to fruition or not. I just am 100% certain there's going to be still no shortage of problems that need to be solved. Michael Fitzgerald Yeah, nice, nice, nice. No shortage of problems that need to be solved. I agree. There's going to be a whole new wave of problems and issues of things that we're not even aware of, the problems that need to be solved yet. That's my take on it too. Alex Klarfeld Yeah, I agree. Karina Chow Yeah. Michael Fitzgerald People are still going to people, you know, builders are still going to build. Yeah. Like what? Alex Klarfeld It's not going away. That's right. I appreciate the questions. Karina Chow Those were well-researched. You went to the website and everything. Michael Fitzgerald Thank you, Grok, and thank you, internet. It's so easy, it's so easy. It's just like setting it in the mo— I just watched a bunch of the Winter Olympics and the little meme of Team Canada with the little finger on the curling stone. That's what it feels like work is now. It's just one little index finger extended, oh, okay, boom. Thank you, LLM, for doing all that work for me. Karina Chow No, I was gonna say, not with the curling analogy, which is a great analogy, but I was gonna say, I'm having more and more clients, as I mentioned in my space with Ufits, that have almost entirely vibe-coded code bases. And it's very interesting. I'm still trying to formulate my thoughts on what I think the future of work will look like, what future of products will look like, and that's why I was so curious to talk to Alex about how he's— I already knew a little bit 'cause Alex and I just talk outside of Twitter, right? But I think just hearing how his company is working with it, especially a company that is very AI forward. So I'm always curious to hear how it's out in the wild and what everyone's thoughts are of how it will look in the next 2 or 3 years. I definitely feel like it's more hostile to be working in a codebase without AI by your side when it's written entirely by AI. That's how I feel. We talked about this briefly before, but do you feel that way too? Are we going to only, in your eyes, say a year or two from now, are we just going to interface with our code bases solely with AI agents? Using AI agents as a middleman and that is how we interact with the code base and how we write code? Or do you think there's still— what is the percentage? If it's not 100% through an agent, how do you foresee the future of the balance between getting in there down and dirty yourself and looking at the code yourself versus interfacing with an AI agent? Alex Klarfeld I don't see a world where we don't use AI agents. I'm chatting with my engineers about it. I think we're gone. The days are gone of the handwritten code. I just don't see it anymore. Sure, there's gonna be handwritten, hand-debugged stuff, but my days and my engineering team's days just consist of having LLMs write code and then read code and explain code and you're just having a conversation with something or somebody that's managing a team. It's just a very different relationship, but I truly don't see us going back to writing code anymore. And it's crazy to think about, we're just chatting about how surreal it is of 2 months ago I was handwriting code and now that's so silly to do. Karina Chow It doesn't make any sense. I know I fucked up earlier and even though I totally know that you're an electrical engineering major, I forgot for a moment. But how do you think we should be reshaping education at the university level to accommodate this new world? Or should we at all? Maybe it's like, hey, you still need all these basics. But how do you think it should be working in the future to make the most efficient? Alex Klarfeld The basics have to be hammered home even more. I always think it's such a silly example, but in I think Cosby's Intro to Programming, he wouldn't let us use the IDE that had a linter in it because he thought we'd use it as a crutch, which makes sense. You don't learn to spell with the spell checker to start. So I think it just becomes more important that you teach students the underlying basics, and then you keep— I don't know, bias, but going all the way down to assembly might be worthwhile, just making sure everyone understands how computers work on a fundamental level and then building everyone back up to the L1-powered agents. I actually think it's very similar to, and I mean no offense to these folks, but the bootcamp explosion where all of a sudden you had a bunch of folks that were building apps and you're like, what the heck? There's just so many different variants. It's akin to that where it was really just the folks that had very solid understandings and just needed to understand what the modern tools were. That's why I think it's the same with LLMs. You still need to understand what's going on under the hood. Karina Chow And I'm really curious about that too. I was just talking to a friend who went to MIT and we were talking about how when we were in university, right, it was just so much theory, so much discrete math. Then it's like, okay, we had to learn a little bit of object-oriented programming, but it wasn't in so much of making an app that uses it. It was just understanding what it is at a higher level, understanding all these different concepts at a higher level, but not necessarily implementing a whole application. So you end up graduating and feeling like, oh, I have this fancy degree from a Carnegie Mellon or an MIT, but hey, I'm not sure I can actually implement it unless you had a bunch of internships. Versus the years after us at CMU, they made object-oriented programming an elective, which is why I'm picking on it. But they made a bunch of these things electives where you don't have to take them anymore. And then they added more classes about DB admin classes. They added more practical classes. So they graduated with a little bit more practical skill sets, but then they don't have the lower level understandings that we did. So it's always interesting to see, hey, now that they made that shift, is it gonna go more in that direction, or is it going to, now that we have LLMs at our side, go more toward the direction again that we had when we were going through? Alex Klarfeld I agree with you. And it sounds lame to say, but it's definitely a balance. They should teach students both. It's crazy that no one taught us GitHub. At least they didn't teach me that in school. Karina Chow I learned SVN and CVS and Perforce in school, but not Git. Alex Klarfeld Or they never— they didn't teach us Python. That wasn't cool at the time. And I don't know, CME should probably do a better job of a little bit of both, but it did do a good job of the fundamentals, which I hope they continue to make students write malloc by hand and that sort of thing. Karina Chow Even though I got D's on all these things, I hope they continue that as well. Yo, me too. I really think it helps. Alex Klarfeld I think everyone did. That was the point of CMU was just think you get Fs and Ds on everything. Karina Chow Think that you're the absolute worst. And then by the time you graduate, you look around and you say, oh, actually I'm pretty good. I was just against, I just had— I was really in the most difficult environment, but it turns out the real world is easier than that. That's right. Michael Fitzgerald Come on, Fitz. That's so interesting to hear about not learning about things like Git, just versioning, how to work with other people on code, how are we gonna merge conflicts and shit like that? I feel a little fortunate. So I got a bachelor's in math and a master's in software development from this school in Iowa called Maharishi International University. It's this kind of weird school that has a pretty decent computer science department, a lot of ex-Googlers, ex-IBM, ex-Microsoft guys, but they incorporate meditation into the curriculum as well. So they refer to it as consciousness-based education. And it was a pretty interesting time. I'm also of this vein of I was kind of a shit student, getting Cs and just getting by kind of thing. But it was also, I'm learning about myself and developing myself as well, as my intellect. But one of the things I look back on and I'm still very grateful for is the fundamentals, even in the math degree. I had a computer organization class and we messed around with assembly for a little bit, doing jumps and go-tos and stuff, oh, okay. Karina Chow Yeah. Michael Fitzgerald Just playing around with it and learning it. And what is binary math? Actually doing really simple calculations by some of that stuff. But anyways, my question I think that's coming up is, what are the basics now? Right? We have data structures and algorithms that are still probably important. It feels like prompt engineering, just the techniques associated with prompting, they probably should be included in the basics. But I really don't know. I have no desire to go back to school right now kind of thing. I'm trying to work. But what do you think the basics would be in this day and age? Alex Klarfeld Or what are they? I don't think it's changed, to be honest, because LLMs are still running on computers. We're still building web applications on browsers. And I think the basics haven't changed. It's just their importance has changed. And I think the hard part about considering prompting to be a basic is, prompting keeps changing so quickly. I honestly think the basics are probably just the set of things that hasn't changed since the LLM influx, which I think is data structures, algorithms, clock cycles. I don't know if anyone cares about that anymore, but just because the LLM stuff has changed so fast, it's hard to call them the basics because they're continuing to abstract. I would argue that I don't know if prompting is really that useful anymore because it just keeps changing. Karina Chow It's like as soon as you would teach it one year in school, then it's not even one year, the next semester it'll change too. And then it depends on which agent you're using or which LLM you're using. The prompting isn't even the same all the time. I think it's what Alex— you were sorry, you finished your thought. I'm going on with it, but okay. I was gonna say, I think what the basics is, is really what Alex was touching upon earlier in this whole talk, which is whatever gets you to have systems or architectural thinking. I think one of the things I see a lot with junior level engineers today is, it's not an inability, it's a not enough practice thinking of, what are the base cases? What are the edge cases? What are all the possible ways that this could go wrong or what could happen, right? And building around that and really understanding this top level, what is the flow of information? What is the flow of what's going on? I think it's that. And I think with that comes things like, I hate to say it, I actually did think a lot of the discrete math was useful, even though at the time I thought it wasn't. But I think thinking in terms of proofs was really good and really gets you to have logical thinking. Again, not everything is object-oriented, but understanding all these different types of coding, anything from object-oriented to functional, understanding that there's different types of programming and when to use which and which, perhaps even just a small set of which languages use which, so you know that you need to adjust your thinking a little bit depending on what type of system you're in. I think it's just getting these different feels for different systems. And that'll help. Once you learn those basics, it'll help inform your prompting, right? And then you can evolve what your prompting is like as that evolves. But it's all what Alex was saying, it really has to do with, can you form the right questions? Can you form the right plan with Claude and then tackle that? Michael Fitzgerald Yo, jazzed. I am jazzed right now just 'cause I'm like, that's why I studied math. That's why I eked it out and somehow got the degree is, yeah, logic, truth tables, AND/OR gates, NOR gates, stuff like that. That was somehow valuable to me, I guess. Karina Chow Yeah, yeah, yeah, yeah. Alex Klarfeld Nice. Karina Chow But I think my favorite thing nowadays is just, I just spend so much time in plan mode with Clogged Toad. Just developing the plan that I think is going to be the best and really challenge it and it'll come up with some assumption like, here's the plan I decided based on your criteria. I look at the plan really carefully and say, hey, this isn't gonna fit for X, Y, and Z. Okay, let me revise the plan. Okay, but now that you revised to that, it actually doesn't work for this other thing. So really just trying to get the plan as solid as possible. And then working off of parts off of that. And then that's the other thing too. I always personally try to work in parts. So it's like, okay, here's the plan and we know what the plan is, but let's execute it each part and then test each part individually and say, okay, does this work? Okay, cool. Now we're moving to the next part, right? Versus a lot of more junior, and I don't even wanna say junior, but a lot of more junior slash people who don't work in as methodically a way. I see them just saying, okay, here's the end result I want, and they just write one giant prompt and say, okay, go. I'll accept all edits. Then you come out and something doesn't work quite right, but at that point you're like, oh God, which part of this whole process did it break? Did it break in the very beginning and we didn't notice it till now because now we had to wait for 10 minutes for it to finish? Or how do we even debug this at this point? It's just a lot more work in that sense. So more upfront work for a better result in the end is my go-to personally. Alex Klarfeld I agree with that. Awesome. Michael Fitzgerald Cool. Karina Chow All right. I was going to say, this seems like a good stopping point. Thank you so much for being my first edge case. Alex Klarfeld Thank you.