Loading summary
Transcript20 lines
- [00:00]
Max
The way that I'm judging you as an engineer is like, are you producing the factory that will produce multiplicative outputs B through Z?
- [00:07]
Blake
It's not even 10x is 100x or thousandx. It always has been.
- [00:10]
Claude
Claude or ChatGPT is basically as good as you are in a domain.
- [00:15]
Blake
I would say just waste tokens, save time. Don't look at the tokens either as inputs or outputs. Just look at your time and look at the final output. No matter how expensive these models might seem, they're still way cheaper than a human.
- [00:26]
Max
The models at some point graduated. They used to be junior engineers, now, now they're principal engineers.
- [00:31]
Claude
And now with the agents, you just don't get stuck anymore, which is pretty amazing.
- [00:34]
Blake
Is pure software dead.
- [00:36]
Unidentified Moderator
Blake, how are you applying all this stuff at Boom Supersonic? Yeah, What I found is it completely changes the role of software and hardware developers. The thing that we did from day one was try to take a lot of traditional engineering workflows, and I mean hardware engineering workflows, and turn them into software. And so if you haven't been around hardware engineering, let me make this more clear. There's a lot of engineering, hardware engineering that happens in Excel, spreadsheets on engineers, laptops in a silo, and very complex spreadsheets, sometimes like VBScript code, and all of this is actually software, but it's treated as if it's not software. There's no source control, there's no automated testing. If you want to hand something off from like an aerodynamicist to a structures engineer, that's done manually with like a spreadsheet over email, like it's the 1990s. It's terrible. And so we started building these kind of like software frameworks that can automate and make repeatable hardware engineering flows. With the idea we could reduce the cost of iteration. But it was, it was slow going because we could never get enough, we can never like afford enough software engineers. And what we've gotten into is this mind blowingly different model where the software engineers actually create the architectures because they understand systems and they understand the algorithms. They, they understand, you know, division of concerns. And then the hardware engineers can vibe code their pieces because what they know about hardware engineering and the result is just like mind blowingly different productivity for small teams. Like give an example like, like if you're designing a turbine blade, like classically, so a turbine blade starts like cold, but when it runs it's hot, so it gets bigger. And so you have to design both the aerodynamics and the structural Design of the thing to work with its cold shape and this hot shape. And so you have to convert between cold and hot and you convert between structures and aerodynamics. And this takes like one engineer one day for one blade for one piece of the analysis. And there are like a thousand blades in a jet engine. And so you can't do much. And we literally now, with a combination of software and hardware people created the solution. You, you can change blade geometry, you can see in real time the structures and aerodynamics results. And so it allows two engineers to design an entire jet engine, which is just wildly different.
- [03:01]
Max
One of the things you mentioned is that you have software engineers creating the tools and architectures for the rest of the engineers. That to me is the biggest the cataclysm of enterprise software is that there is no like startup that builds hardware collaboration tools that can sell you anything anymore. Because internally you're just coding the right things that you need at any given time. Even spreadsheets are kind of cooked, right? Because the reason spreadsheets were successful is that no one could build custom software. So the thing that approximates custom software the most is a spreadsheet with a bunch of VBScript functions.
- [03:35]
Claude
I personally have moved almost entirely from Excel to Python models where I can actually get believable simulations of things. Yeah, I mean the thing that, that AI hasn't come to yet, that I think it will within the next year, like probably within 26, that will be very, very exciting, is right now it can generate software, but soon it'll be able to generate step files and PCB layouts. And when it comes for mechanical and electrical engineering, that will be a whole other thing that we haven't seen yet. That'll be very, very cool.
- [04:05]
Blake
Yeah, on the hardware side, I think it's really a boon for like all these little gadget companies and part companies that write really bad software because they can't make great software and now they're going to be able to make good enough software or it may not even software that is a human front end, it might just be completely agentic for an agent to access and you just talk to it through voice and control hardware. And this is why one of the reasons why I think, for example, China is big into open source models, right? They're basically going all in on it because they have hardware superiority. They have these very complex supply chains and component chains and they're basically saying, hey, if I can just generate software on demand, then I don't have this disadvantage anymore against Silicon Valley. So that's not the only reason why they're doing open source. I think they're also behind, they're distilling models, they're catching, you know, they're collaborating resources. But I think the Chinese government has a history of funding efforts that then sort of help their entire ecosystem along, especially in network effect businesses. And so I think they want to like pool all their resources, catch up on AI and use it to give their hardware stuff an advantage. And ironically they're doing all the open source stuff because OpenAI is not open. You know, Grox publishes models, but I think they're a model or two behind. Google has some local models, but nothing really that competitive anthropic to my knowledge. I don't even know of any open source models from them. So all the open source heft is coming from China. It helps all our hardware founders, but it helps their hardware founders and factories and so on that much more. But all the crappy little software that goes with all the little random knickknacks and thingamajigs that you buy off Amazon to tinker with a lazy Saturday afternoon, that software is getting a lot better very quickly.
- [05:46]
Max
I think everyone's had the wake up call that without great frontier coding models you don't have self improvement. And so imagine China as a whole not having the ability to produce frontier everything, right? It's not just producing software is in any piece of this hardware pipeline. Like Blake was saying, like you need to generate software. If you fall behind on your ability to generate software, you fall behind on the ability to generate everything. One thing I'm curious about from you guys is like, because everyone loves to talk about Chinese models, like do you use Chinese models? Do you know anybody that uses Chinese models?
- [06:21]
Blake
This is an argument I had yesterday actually, which is one person at the table dinner was claiming that you'll just use deep seq for 97% of things because it's so cheap. And if you need more intelligence, you'll just run it over and over again the same problem. And you only use the OpenAI anthropic, et cetera models for the most advanced tasks. And I was kind of like, I don't know, I think intelligence is an unalloyed good. You always want more intelligence. And when these models make a mistake, you don't know it and it's always cheaper than a real person in real time. So you just use the most intelligent model available. Which isn't great news necessarily because it means that you know you're going to end up creating a monopoly or oligopoly kind of situation in AI. But I always want the most intelligent programmer. I always want the most correct answer. I always want the best judgment. And given the amount of leverage that I'm going to pour into it through capital and code and people and marketing, I want to make the right decision every time. And often when between two models, let's say like I have one model that I know is a little smarter than the next one and they both give me answers, often I actually don't know which is the correct answer. Right. So if I know one model is a little smarter, I'm going to go with that answer and eventually I'm going to stop asking the model that I think is less intelligent. But I don't know. Have you guys found a use for these, you know, so called less intelligent models?
- [07:37]
Max
We see uses so that, so we have the AI gateways data that basically like every application agents that are goes through. And so there's definitely usage of open models but the top is heavily dominated by the frontier intelligence. And there's a subcategory or there's a caveat to that which is that frontier intelligence at reasonable cost and performance slaps at scale. So people don't get really excited about Gemini, but they put out these models that are super smart at the right performance, cost combination and for a lot of tasks other than coding. Actually, interestingly enough, they're the best models. They're like the best industrial production models. You can throw them at support tasks or browser automation. I would always put a Gemini model there and I would look to Chinese models for those kinds of things. But anytime I'm working to push the frontier, you need the best possible coding model. And that's basically now two or three models and the Chinese are certainly not in it.
- [08:42]
Unidentified Moderator
Hey Max, you're pushing pretty hard into vertical integration and extreme urgency.
- [08:46]
Blake
Do you want to talk about that?
- [08:47]
Claude
Yeah. I mean for many things we maybe you can't buy it, so you got to make it somehow. Our preference would always be to buy something. Like if there's a vendor that offers a service at a great price, it's like for example, like PCBs. Like we don't make PCBs. Like those are, they're basically free. You can buy them in unlimited quantity from Asia. But the closer that our products get to being like a single block of covalently bonded matter, the better they'll be. Lower power, smaller, higher performance last longer. And there's just like they're like the components aren't available. And in order to do that type of integration, be able to actually innovate beyond things, just piecing together things that you can buy off the shelf, which really is very, very limiting. I guess you have to, like, learn to do it yourself. And that shows up as vertical integration. So we own a captive MEMS foundry on the east coast, which we bought because there was really no other way to do the type of packaging and assembly stuff that we wanted to do. And I think that all of this is going to be affected heavily by AI over the next few years. It's not quite there yet. In fact, ironically, one of the biggest impacts that we've seen of AI inside the companies in regulatory interactions, because if we can do things like generate documentation or if we can ask if we want to change, we want to evolve this product, there's thousands of ISO standards that might apply. Which ones do we have to comply with? And trace this through. This used to be you're following a whole regulatory and quality team for several months as they trace this, and now the AI just kind of knows. But when I think about stuff like the surgical program or the MEMS fab, I think ultimately the software still needs hands, like it's going to be smarter than us. But if it can't make things, then like, those are real, real boundaries. And so we've instrumented our foundry as well as many other parts of the company in ways where, as these models get better, that should show up pretty immediately in things like the cell engineering that we're doing and the material science that we're developing.
- [10:40]
Blake
It sort of makes me realize that it's been a while since I've generated a basic legal document using a lawyer, right? I stopped asking lawyers for NDAs and agreement for this and sign that and research this. And all the basic legal tasks are gone too. Because, you know, there's the old joke that law is like spaghetti code. You know, they have this very complicated code that they try to put in English, and it contradicts this code over here and has to fit into that code over here. And there are no real APIs for it. But for just like junior engineers and junior engineering, I should say junior engineers basically got a promotion to senior engineers and junior engineering got taken over by agents. And so the same way, I think, in a way, the downside is you can look at law and say, you know, paralegals just got fired, or you can say paralegals just got promoted to senior lawyers and now they can spend their time thinking about the law.
- [11:29]
Max
It's actually kind of interesting to think about the parallels of how software engineering is evolving with lawyers. Because lawyers, you never know what they put into these documents exactly. You just trust them. Like, hey, lawyer, can you look at this document? Can you tell me if it's legit? Can you do red lines, whatever. Like at the end of the day, you're. What you're valuing in the relationship with a lawyer is that, is that they're a trusted authority, they went to law school and they're putting their reputation on the line. I think there's a parallel with the biggest problem in software engineering today is these mountains of slop that end up as a pr. And then people are saying there's all these memes on Twitter. Way back in the day, we used to read every line of code of a pr. Well, in my world, infrastructure, I want engineers to be able to say, I understand doesn't necessarily mean that you've read every line of the pr. You need to be able to say, I am signing off on understanding the consequences of this pr, or I wrote the test harness the simulations, the proofs, the type checkers, etc. To be able to say, even without reading this, I have confidence I can sign off on it's going to be safe in production. It's interesting because there's a world in which we embrace that everything is going to be spaghetti code and that we don't fully understand it, but we write the basically evaluators that give us confidence. And then we rely on people like the infrastructure, production engineers to say, okay, I'm fine sending this into prod. At the end of the day, someone is going to get paged if your systems go down. I think another thing that people are underestimating is that creating software is really easy, zero to one. But think about 1,000 days from now, what does your software look like? Is it secure? Is it tested, is it production grade, is it performant? And are you still motivated to invest all of those tokens in maintaining it in prod?
- [13:30]
Blake
I mean, humans are becoming verifiers, right? And that's kind of how we train these models with good verification data. And now we need human verifiers. So, yeah, I think a lot of the old function of people, lawyers, engineers, operations people, moved to verifying the stack and saying, yeah, this is roughly correct and I'll roughly stand behind it and I'll support you if it goes wrong.