Podcasts about Netlify

The tRPC team declares v11 officially production-ready. tRPC allows devs to build typesafe APIs with types that can be shared on the client and server, and now it has support for TanStack Query v5, the ability to send and receive non-JSON data content types, improved support for RSCs, and the ability to stream responses.After the Next.js security incident a few weeks back, Netlify writes an open letter around the challenges Next.js poses when not hosted on Vercel. It raises valid points like a lack of adapters, no production grade documentation for serverless deployments, no visible roadmap or release schedule, and a disregard for open web standards, among others.Firefox is finally adding support for progressive web apps (PWAs), but its web app support will intentionally not look, feel, or behave the same way similar features do in other browsers.News:Paige - tRPC v11Jack - Firefox will support PWAs (finally)TJ - Next.js Netlify deployment dramaBonus News:Styled-components enter maintenance modeNew Bare JS runtimeWindsurf and Netlify partnership (and docs on the feature)What Makes Us Happy this Week:Paige - Squeeze Me novelJack - Pickup Music siteTJ - Mario Kart WorldThanks as always to our sponsor, the Blue Collar Coder channel on YouTube. You can join us in our Discord channel, explore our website and reach us via email, or talk to us on X, Bluesky, or YouTube.Front-end Fire websiteBlue Collar Coder on YouTubeBlue Collar Coder on DiscordReach out via emailTweet at us on X @front_end_fireFollow us on Bluesky @front-end-fire.comSubscribe to our YouTube channel @Front-EndFirePodcast

* Critical Flaw in Next.js Allows Authorization Bypass* Hackers Can Now Weaponize AI Coding Assistants Through Hidden Configuration Rules* Hacker Claims Oracle Cloud Data Theft, Company Refutes Breach* Chinese Hackers Infiltrate Asian Telco, Maintain Undetected Network Access for Four Years* Cloudflare Launches Aggressive Security Measure: Shutting Down HTTP Ports for API AccessCritical Flaw in Next.js Allows Authorization Bypasshttps://zhero-web-sec.github.io/research-and-things/nextjs-and-the-corrupt-middlewareA critical vulnerability, CVE-2025-29927, has been discovered in the Next.js web development framework, enabling attackers to bypass authorization checks. This flaw allows malicious actors to send requests that bypass essential security measures.Next.js, a popular React framework used by companies like TikTok, Netflix, and Uber, utilizes middleware components for authentication and authorization. The vulnerability stems from the framework's handling of the "x-middleware-subrequest" header, which normally prevents infinite loops in middleware processing. Attackers can manipulate this header to bypass the entire middleware execution chain.The vulnerability affects Next.js versions prior to 15.2.3, 14.2.25, 13.5.9, and 12.3.5. Users are strongly advised to upgrade to patched versions immediately. Notably, the flaw only impacts self-hosted Next.js applications using "next start" with "output: standalone." Applications hosted on Vercel and Netlify, or deployed as static exports, are not affected. As a temporary mitigation, blocking external user requests containing the "x-middleware-subrequest" header is recommended.Hackers Can Now Weaponize AI Coding Assistants Through Hidden Configuration Ruleshttps://www.pillar.security/blog/new-vulnerability-in-github-copilot-and-cursor-how-hackers-can-weaponize-code-agentsResearchers Uncover Dangerous "Rules File Backdoor" Attack Targeting GitHub Copilot and CursorIn a groundbreaking discovery, cybersecurity researchers from Pillar Security have identified a critical vulnerability in popular AI coding assistants that could potentially compromise software development processes worldwide. The newly unveiled attack vector, dubbed the "Rules File Backdoor," allows malicious actors to silently inject harmful code instructions into AI-powered code editors like GitHub Copilot and Cursor.The vulnerability exploits a fundamental trust mechanism in AI coding tools: configuration files that guide code generation. These "rules files," typically used to define coding standards and project architectures, can be manipulated using sophisticated techniques including invisible Unicode characters and complex linguistic patterns.According to the research, nearly 97% of enterprise developers now use generative AI coding tools, making this attack particularly alarming. By embedding carefully crafted prompts within seemingly innocent configuration files, attackers can essentially reprogram AI assistants to generate code with hidden vulnerabilities or malicious backdoors.The attack mechanism is particularly insidious. Researchers demonstrated that attackers could:* Override security controls* Generate intentionally vulnerable code* Create pathways for data exfiltration* Establish long-term persistent threats across software projectsWhen tested, the researchers showed how an attacker could inject a malicious script into an HTML file without any visible indicators in the AI's response, making detection extremely challenging for developers and security teams.Both Cursor and GitHub have thus far maintained that the responsibility for reviewing AI-generated code lies with users, highlighting the critical need for heightened vigilance in AI-assisted development environments.Pillar Security recommends several mitigation strategies:* Conducting thorough audits of existing rule files* Implementing strict validation processes for AI configuration files* Deploying specialized detection tools* Maintaining rigorous manual code reviewsAs AI becomes increasingly integrated into software development, this research serves as a crucial warning about the expanding attack surfaces created by artificial intelligence technologies.Hacker Claims Oracle Cloud Data Theft, Company Refutes Breachhttps://www.bleepingcomputer.com/news/security/oracle-denies-data-breach-after-hacker-claims-theft-of-6-million-data-records/Threat Actor Offers Stolen Data on Hacking Forum, Seeks Ransom or Zero-Day ExploitsOracle has firmly denied allegations of a data breach after a threat actor known as rose87168 claimed to have stolen 6 million data records from the company's Cloud federated Single Sign-On (SSO) login servers.The threat actor, posting on the BreachForums hacking forum, asserts they accessed Oracle Cloud servers approximately 40 days ago and exfiltrated data from the US2 and EM2 cloud regions. The purported stolen data includes encrypted SSO passwords, Java Keystore files, key files, and enterprise manager JPS keys.Oracle categorically rejected the breach claims, stating, "There has been no breach of Oracle Cloud. The published credentials are not for the Oracle Cloud. No Oracle Cloud customers experienced a breach or lost any data."To substantiate their claims, the hacker shared an Internet Archive URL indicating they uploaded a text file containing their ProtonMail email address to the login.us2.oraclecloud.com server. The threat actor also suggested that SSO passwords, while encrypted, could be decrypted using available files.The hacker's demands are multifaceted: they are selling the allegedly stolen data for an undisclosed price or seeking zero-day exploits. Additionally, they proposed offering partial data removal for companies willing to pay a specific amount to protect their employees' information.In a provocative move, rose87168 claimed to have emailed Oracle, demanding 100,000 Monero (XMR) in exchange for breach details. According to the threat actor, Oracle refused the offer after requesting comprehensive information for fixing and patching the vulnerability.The threat actor alleges that Oracle Cloud servers are running a vulnerable version with a public CVE (Common Vulnerabilities and Exposures) that currently lacks a public proof-of-concept or exploit.Chinese Hackers Infiltrate Asian Telco, Maintain Undetected Network Access for Four Yearshttps://www.sygnia.co/threat-reports-and-advisories/weaver-ant-tracking-a-china-nexus-cyber-espionage-operation/Sophisticated Espionage Campaign Exploits Vulnerable Home RoutersCybersecurity researchers from Sygnia have uncovered a sophisticated four-year cyber espionage campaign by Chinese state-backed hackers targeting a major Asian telecommunications company. The threat actor, dubbed "Weaver Ant," demonstrated extraordinary persistence and technical sophistication in maintaining undetected access to the victim's network.The attack began through a strategic compromise of home routers manufactured by Zyxel, which served as the initial entry point into the telecommunications provider's environment. Sygnia attributed the campaign to Chinese actors based on multiple indicators, including the specific targeting, campaign objectives, hacker working hours, and the use of the China Chopper web shell—a tool frequently employed by Chinese hacking groups.Oren Biderman, Sygnia's incident response leader, described the threat actors as "incredibly dangerous and persistent," emphasizing their primary goal of infiltrating critical infrastructure and collecting sensitive information. The hackers demonstrated remarkable adaptability, continuously evolving their tactics to maintain network access and evade detection.A key tactic in the attack involved operational relay box (ORB) networks, a sophisticated infrastructure comprising compromised virtual private servers, Internet of Things devices, and routers. By leveraging an ORB network primarily composed of compromised Zyxel routers from Southeast Asian telecom providers, the hackers effectively concealed their attack infrastructure and enabled cross-network targeting.The researchers initially discovered the campaign during the final stages of a separate forensic investigation, when they noticed suspicious account restoration and encountered a web shell variant deployed on a long-compromised server. Further investigation revealed multiple layers of web shells that allowed the hackers to move laterally within the network while remaining undetected.Sygnia's analysis suggests the campaign's ultimate objective was long-term espionage, enabling continuous information collection and potential future strategic operations. The hackers' ability to maintain access for four years, despite repeated elimination attempts, underscores the sophisticated nature of state-sponsored cyber intrusions.Cloudflare Launches Aggressive Security Measure: Shutting Down HTTP Ports for API Accesshttps://blog.cloudflare.com/https-only-for-cloudflare-apis-shutting-the-door-on-cleartext-traffic/Company Takes Bold Step to Prevent Potential Data ExposuresCloudflare has announced a comprehensive security initiative to completely eliminate unencrypted HTTP traffic for its API endpoints, marking a significant advancement in protecting sensitive digital communications. The move comes as part of the company's ongoing commitment to enhancing internet security by closing cleartext communication channels that could potentially expose critical information.Starting immediately, any attempts to connect to api.cloudflare.com using unencrypted HTTP will be entirely rejected, rather than simply redirected. This approach addresses a critical security vulnerability where sensitive information like API tokens could be intercepted during initial connection attempts, even before a secure redirect could occur.The decision stems from a critical observation that initial plaintext HTTP requests can expose sensitive data to network intermediaries, including internet service providers, Wi-Fi hotspot providers, and potential malicious actors. By closing HTTP ports entirely, Cloudflare prevents the transport layer connection from being established, effectively blocking any potential data exposure before it can occur.Notably, the company plans to extend this feature to its customers, allowing them to opt-in to HTTPS-only traffic for their websites by the last quarter of 2025. This will provide users with an additional layer of security at no extra cost.While the implementation presents challenges—with approximately 2-3% of requests still coming over plaintext HTTP from "likely human" clients and over 16% from automated sources—Cloudflare has developed sophisticated technical solutions to manage the transition. The company has leveraged tools like Tubular to intelligently manage IP addresses and network connections, ensuring minimal disruption to existing services.The move is part of Cloudflare's broader mission to make the internet more secure, with the company emphasizing that security features should be accessible to all users without additional charges. Developers and users of Cloudflare's API will need to ensure they are using HTTPS connections exclusively moving forward. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit edwinkwan.substack.com

Web app bundler Parcel adds support for React Server Components, including a repo of example apps for developers to reference. Although not specifically aimed at framework developers it seems like that's the audience that would benefit most from this new feature in Parcel.CodeSandbox enters the AI game by teaming up with AI hosting platform Together AI, and launching CodeSandbox SDK. CodeSandbox SDK will allow developers to programmatically spin up AI sandboxes just like they can spin up microVMs today to run web app sandboxes in the cloud on CodeSandbox.io. Netlify inks a deal to become the official deployment partner of TanStack Start. Deploying TanStack projects on Netlify will mean: no config files needed, access to Netlify serverless functions, the reliability of Netlify's global edge network, and the developer tools we know and love like instant previews and automated workflows.News:Paige - CodeSandbox joins Together AI and launches CodeSandbox SDKJack - Parcel RSCsTJ - TanStack + Netlify PartnershipBonus News:Google Acquires Wiz for $32 billionOxlint Beta is ready to replace ESLintWhat Makes Us Happy this Week:Paige - Formula 1: Drive to Survive S7 Jack - Mushroom outdoor solar lightsTJ - Michael Jordan-shaped Cheeto up for auctionThanks as always to our sponsor, the Blue Collar Coder channel on YouTube. You can join us in our Discord channel, explore our website and reach us via email, or talk to us on X, Bluesky, or YouTube.Front-end Fire websiteBlue Collar Coder on YouTubeBlue Collar Coder on DiscordReach out via emailTweet at us on X @front_end_fireFollow us on Bluesky @front-end-fire.comSubscribe to our YouTube channel @Front-EndFirePodcast

Matt Biilmann is the Co-Founder and CEO @ Netlify. Under his leadership, Netlify has become one of the fastest-growing platforms for modern web development. Matt recently introduced agent experience (AX), a new way of thinking about how software is built and experienced in the AI era. Matt is also known for coining Jamstack, a concept that redefined how developers build for the web.  In Today's Episode We Discuss:  03:43 How Does the Design Process Change When Designing For Agents 06:27 How Does the Product Building Process Change When Building for Agents 12:52 Will AI Kill SaaS Tools 16:12 If Prototyping Becomes Phase 1: Does Figma Survive? 17:35 Is Chat the Best Interface for a World of AI 21:52 Why AI Services Will Be One of the Biggest Economies 27:24 Open vs. Closed Platforms in an Agent-First World 31:09 Specialization of Large Language Models 35:13 Shifting Labor Costs to Agent Spend 36:28 The Future of Stripe and What Happens with 100M Developers in the World 38:39 Quickfire Round: Insights and Predictions  

User research is an underappreciated art - we in tech are so used to being immersed in an ocean of quantitative data that we can forget that on the other side of the screen are real humans who want to solve very specific problems. And often times, their problems are extremely hard to put a number on. Why did they abandon their cart right before checkout? What made them start creating a new newsletter but then abandon it but come back a month later? Not everything can be answered with a SQL query against the telemetry database. Marisa Morby, a Principal Researcher at Observable, sat down with me to help me better understand what it means to be great (not just good) at user research, and how that can help produce a whole new range of unexpected product insights. And Marisa definitely knows what the impact of great user research can be on the product - she previously worked at such notable companies like Netlify, Gatsby, and Accenture Song, where she honed her skills and UX instincts.

In this episode of AI + a16z, Netlify CEO and Cofounder Matt Biilmann joins a16z General Partner Martin Casado to explore how AI is reshaping web development — not just through faster code generation, but by fundamentally shifting how we think about building for the web. At the center of this shift is Agent Experience (AX), a new paradigm where AI agents aren't just tools, but active participants in development, shaping both the creative process and the underlying infrastructure.Matt shares how Netlify is evolving to meet this future, why the next 100 million web developers will collaborate with AI, and what's at stake if the web doesn't adapt — will we see a thriving, open, AI-powered internet, or a future dominated by walled gardens?Learn more:Introducing AX: Why Agent Experience MattersFollow everyone on X:Matt BiilmannMartin Casado Check out everything a16z is doing with artificial intelligence here, including articles, projects, and more podcasts.

Today's episode is with Paul Klein, founder of Browserbase. We talked about building browser infrastructure for AI agents, the future of agent authentication, and their open source framework Stagehand.* [00:00:00] Introductions* [00:04:46] AI-specific challenges in browser infrastructure* [00:07:05] Multimodality in AI-Powered Browsing* [00:12:26] Running headless browsers at scale* [00:18:46] Geolocation when proxying* [00:21:25] CAPTCHAs and Agent Auth* [00:28:21] Building “User take over” functionality* [00:33:43] Stagehand: AI web browsing framework* [00:38:58] OpenAI's Operator and computer use agents* [00:44:44] Surprising use cases of Browserbase* [00:47:18] Future of browser automation and market competition* [00:53:11] Being a solo founderTranscriptAlessio [00:00:04]: Hey everyone, welcome to the Latent Space podcast. This is Alessio, partner and CTO at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol.ai.swyx [00:00:12]: Hey, and today we are very blessed to have our friends, Paul Klein, for the fourth, the fourth, CEO of Browserbase. Welcome.Paul [00:00:21]: Thanks guys. Yeah, I'm happy to be here. I've been lucky to know both of you for like a couple of years now, I think. So it's just like we're hanging out, you know, with three ginormous microphones in front of our face. It's totally normal hangout.swyx [00:00:34]: Yeah. We've actually mentioned you on the podcast, I think, more often than any other Solaris tenant. Just because like you're one of the, you know, best performing, I think, LLM tool companies that have started up in the last couple of years.Paul [00:00:50]: Yeah, I mean, it's been a whirlwind of a year, like Browserbase is actually pretty close to our first birthday. So we are one years old. And going from, you know, starting a company as a solo founder to... To, you know, having a team of 20 people, you know, a series A, but also being able to support hundreds of AI companies that are building AI applications that go out and automate the web. It's just been like, really cool. It's been happening a little too fast. I think like collectively as an AI industry, let's just take a week off together. I took my first vacation actually two weeks ago, and Operator came out on the first day, and then a week later, DeepSeat came out. And I'm like on vacation trying to chill. I'm like, we got to build with this stuff, right? So it's been a breakneck year. But I'm super happy to be here and like talk more about all the stuff we're seeing. And I'd love to hear kind of what you guys are excited about too, and share with it, you know?swyx [00:01:39]: Where to start? So people, you've done a bunch of podcasts. I think I strongly recommend Jack Bridger's Scaling DevTools, as well as Turner Novak's The Peel. And, you know, I'm sure there's others. So you covered your Twilio story in the past, talked about StreamClub, you got acquired to Mux, and then you left to start Browserbase. So maybe we just start with what is Browserbase? Yeah.Paul [00:02:02]: Browserbase is the web browser for your AI. We're building headless browser infrastructure, which are browsers that run in a server environment that's accessible to developers via APIs and SDKs. It's really hard to run a web browser in the cloud. You guys are probably running Chrome on your computers, and that's using a lot of resources, right? So if you want to run a web browser or thousands of web browsers, you can't just spin up a bunch of lambdas. You actually need to use a secure containerized environment. You have to scale it up and down. It's a stateful system. And that infrastructure is, like, super painful. And I know that firsthand, because at my last company, StreamClub, I was CTO, and I was building our own internal headless browser infrastructure. That's actually why we sold the company, is because Mux really wanted to buy our headless browser infrastructure that we'd built. And it's just a super hard problem. And I actually told my co-founders, I would never start another company unless it was a browser infrastructure company. And it turns out that's really necessary in the age of AI, when AI can actually go out and interact with websites, click on buttons, fill in forms. You need AI to do all of that work in an actual browser running somewhere on a server. And BrowserBase powers that.swyx [00:03:08]: While you're talking about it, it occurred to me, not that you're going to be acquired or anything, but it occurred to me that it would be really funny if you became the Nikita Beer of headless browser companies. You just have one trick, and you make browser companies that get acquired.Paul [00:03:23]: I truly do only have one trick. I'm screwed if it's not for headless browsers. I'm not a Go programmer. You know, I'm in AI grant. You know, browsers is an AI grant. But we were the only company in that AI grant batch that used zero dollars on AI spend. You know, we're purely an infrastructure company. So as much as people want to ask me about reinforcement learning, I might not be the best guy to talk about that. But if you want to ask about headless browser infrastructure at scale, I can talk your ear off. So that's really my area of expertise. And it's a pretty niche thing. Like, nobody has done what we're doing at scale before. So we're happy to be the experts.swyx [00:03:59]: You do have an AI thing, stagehand. We can talk about the sort of core of browser-based first, and then maybe stagehand. Yeah, stagehand is kind of the web browsing framework. Yeah.What is Browserbase? Headless Browser Infrastructure ExplainedAlessio [00:04:10]: Yeah. Yeah. And maybe how you got to browser-based and what problems you saw. So one of the first things I worked on as a software engineer was integration testing. Sauce Labs was kind of like the main thing at the time. And then we had Selenium, we had Playbrite, we had all these different browser things. But it's always been super hard to do. So obviously you've worked on this before. When you started browser-based, what were the challenges? What were the AI-specific challenges that you saw versus, there's kind of like all the usual running browser at scale in the cloud, which has been a problem for years. What are like the AI unique things that you saw that like traditional purchase just didn't cover? Yeah.AI-specific challenges in browser infrastructurePaul [00:04:46]: First and foremost, I think back to like the first thing I did as a developer, like as a kid when I was writing code, I wanted to write code that did stuff for me. You know, I wanted to write code to automate my life. And I do that probably by using curl or beautiful soup to fetch data from a web browser. And I think I still do that now that I'm in the cloud. And the other thing that I think is a huge challenge for me is that you can't just create a web site and parse that data. And we all know that now like, you know, taking HTML and plugging that into an LLM, you can extract insights, you can summarize. So it was very clear that now like dynamic web scraping became very possible with the rise of large language models or a lot easier. And that was like a clear reason why there's been more usage of headless browsers, which are necessary because a lot of modern websites don't expose all of their page content via a simple HTTP request. You know, they actually do require you to run this type of code for a specific time. JavaScript on the page to hydrate this. Airbnb is a great example. You go to airbnb.com. A lot of that content on the page isn't there until after they run the initial hydration. So you can't just scrape it with a curl. You need to have some JavaScript run. And a browser is that JavaScript engine that's going to actually run all those requests on the page. So web data retrieval was definitely one driver of starting BrowserBase and the rise of being able to summarize that within LLM. Also, I was familiar with if I wanted to automate a website, I could write one script and that would work for one website. It was very static and deterministic. But the web is non-deterministic. The web is always changing. And until we had LLMs, there was no way to write scripts that you could write once that would run on any website. That would change with the structure of the website. Click the login button. It could mean something different on many different websites. And LLMs allow us to generate code on the fly to actually control that. So I think that rise of writing the generic automation scripts that can work on many different websites, to me, made it clear that browsers are going to be a lot more useful because now you can automate a lot more things without writing. If you wanted to write a script to book a demo call on 100 websites, previously, you had to write 100 scripts. Now you write one script that uses LLMs to generate that script. That's why we built our web browsing framework, StageHand, which does a lot of that work for you. But those two things, web data collection and then enhanced automation of many different websites, it just felt like big drivers for more browser infrastructure that would be required to power these kinds of features.Alessio [00:07:05]: And was multimodality also a big thing?Paul [00:07:08]: Now you can use the LLMs to look, even though the text in the dome might not be as friendly. Maybe my hot take is I was always kind of like, I didn't think vision would be as big of a driver. For UI automation, I felt like, you know, HTML is structured text and large language models are good with structured text. But it's clear that these computer use models are often vision driven, and they've been really pushing things forward. So definitely being multimodal, like rendering the page is required to take a screenshot to give that to a computer use model to take actions on a website. And it's just another win for browser. But I'll be honest, that wasn't what I was thinking early on. I didn't even think that we'd get here so fast with multimodality. I think we're going to have to get back to multimodal and vision models.swyx [00:07:50]: This is one of those things where I forgot to mention in my intro that I'm an investor in Browserbase. And I remember that when you pitched to me, like a lot of the stuff that we have today, we like wasn't on the original conversation. But I did have my original thesis was something that we've talked about on the podcast before, which is take the GPT store, the custom GPT store, all the every single checkbox and plugin is effectively a startup. And this was the browser one. I think the main hesitation, I think I actually took a while to get back to you. The main hesitation was that there were others. Like you're not the first hit list browser startup. It's not even your first hit list browser startup. There's always a question of like, will you be the category winner in a place where there's a bunch of incumbents, to be honest, that are bigger than you? They're just not targeted at the AI space. They don't have the backing of Nat Friedman. And there's a bunch of like, you're here in Silicon Valley. They're not. I don't know.Paul [00:08:47]: I don't know if that's, that was it, but like, there was a, yeah, I mean, like, I think I tried all the other ones and I was like, really disappointed. Like my background is from working at great developer tools, companies, and nothing had like the Vercel like experience. Um, like our biggest competitor actually is partly owned by private equity and they just jacked up their prices quite a bit. And the dashboard hasn't changed in five years. And I actually used them at my last company and tried them and I was like, oh man, like there really just needs to be something that's like the experience of these great infrastructure companies, like Stripe, like clerk, like Vercel that I use in love, but oriented towards this kind of like more specific category, which is browser infrastructure, which is really technically complex. Like a lot of stuff can go wrong on the internet when you're running a browser. The internet is very vast. There's a lot of different configurations. Like there's still websites that only work with internet explorer out there. How do you handle that when you're running your own browser infrastructure? These are the problems that we have to think about and solve at BrowserBase. And it's, it's certainly a labor of love, but I built this for me, first and foremost, I know it's super cheesy and everyone says that for like their startups, but it really, truly was for me. If you look at like the talks I've done even before BrowserBase, and I'm just like really excited to try and build a category defining infrastructure company. And it's, it's rare to have a new category of infrastructure exists. We're here in the Chroma offices and like, you know, vector databases is a new category of infrastructure. Is it, is it, I mean, we can, we're in their office, so, you know, we can, we can debate that one later. That is one.Multimodality in AI-Powered Browsingswyx [00:10:16]: That's one of the industry debates.Paul [00:10:17]: I guess we go back to the LLMOS talk that Karpathy gave way long ago. And like the browser box was very clearly there and it seemed like the people who were building in this space also agreed that browsers are a core primitive of infrastructure for the LLMOS that's going to exist in the future. And nobody was building something there that I wanted to use. So I had to go build it myself.swyx [00:10:38]: Yeah. I mean, exactly that talk that, that honestly, that diagram, every box is a startup and there's the code box and then there's the. The browser box. I think at some point they will start clashing there. There's always the question of the, are you a point solution or are you the sort of all in one? And I think the point solutions tend to win quickly, but then the only ones have a very tight cohesive experience. Yeah. Let's talk about just the hard problems of browser base you have on your website, which is beautiful. Thank you. Was there an agency that you used for that? Yeah. Herb.paris.Paul [00:11:11]: They're amazing. Herb.paris. Yeah. It's H-E-R-V-E. I highly recommend for developers. Developer tools, founders to work with consumer agencies because they end up building beautiful things and the Parisians know how to build beautiful interfaces. So I got to give prep.swyx [00:11:24]: And chat apps, apparently are, they are very fast. Oh yeah. The Mistral chat. Yeah. Mistral. Yeah.Paul [00:11:31]: Late chat.swyx [00:11:31]: Late chat. And then your videos as well, it was professionally shot, right? The series A video. Yeah.Alessio [00:11:36]: Nico did the videos. He's amazing. Not the initial video that you shot at the new one. First one was Austin.Paul [00:11:41]: Another, another video pretty surprised. But yeah, I mean, like, I think when you think about how you talk about your company. You have to think about the way you present yourself. It's, you know, as a developer, you think you evaluate a company based on like the API reliability and the P 95, but a lot of developers say, is the website good? Is the message clear? Do I like trust this founder? I'm building my whole feature on. So I've tried to nail that as well as like the reliability of the infrastructure. You're right. It's very hard. And there's a lot of kind of foot guns that you run into when running headless browsers at scale. Right.Competing with Existing Headless Browser Solutionsswyx [00:12:10]: So let's pick one. You have eight features here. Seamless integration. Scalability. Fast or speed. Secure. Observable. Stealth. That's interesting. Extensible and developer first. What comes to your mind as like the top two, three hardest ones? Yeah.Running headless browsers at scalePaul [00:12:26]: I think just running headless browsers at scale is like the hardest one. And maybe can I nerd out for a second? Is that okay? I heard this is a technical audience, so I'll talk to the other nerds. Whoa. They were listening. Yeah. They're upset. They're ready. The AGI is angry. Okay. So. So how do you run a browser in the cloud? Let's start with that, right? So let's say you're using a popular browser automation framework like Puppeteer, Playwright, and Selenium. Maybe you've written a code, some code locally on your computer that opens up Google. It finds the search bar and then types in, you know, search for Latent Space and hits the search button. That script works great locally. You can see the little browser open up. You want to take that to production. You want to run the script in a cloud environment. So when your laptop is closed, your browser is doing something. The browser is doing something. Well, I, we use Amazon. You can see the little browser open up. You know, the first thing I'd reach for is probably like some sort of serverless infrastructure. I would probably try and deploy on a Lambda. But Chrome itself is too big to run on a Lambda. It's over 250 megabytes. So you can't easily start it on a Lambda. So you maybe have to use something like Lambda layers to squeeze it in there. Maybe use a different Chromium build that's lighter. And you get it on the Lambda. Great. It works. But it runs super slowly. It's because Lambdas are very like resource limited. They only run like with one vCPU. You can run one process at a time. Remember, Chromium is super beefy. It's barely running on my MacBook Air. I'm still downloading it from a pre-run. Yeah, from the test earlier, right? I'm joking. But it's big, you know? So like Lambda, it just won't work really well. Maybe it'll work, but you need something faster. Your users want something faster. Okay. Well, let's put it on a beefier instance. Let's get an EC2 server running. Let's throw Chromium on there. Great. Okay. I can, that works well with one user. But what if I want to run like 10 Chromium instances, one for each of my users? Okay. Well, I might need two EC2 instances. Maybe 10. All of a sudden, you have multiple EC2 instances. This sounds like a problem for Kubernetes and Docker, right? Now, all of a sudden, you're using ECS or EKS, the Kubernetes or container solutions by Amazon. You're spending up and down containers, and you're spending a whole engineer's time on kind of maintaining this stateful distributed system. Those are some of the worst systems to run because when it's a stateful distributed system, it means that you are bound by the connections to that thing. You have to keep the browser open while someone is working with it, right? That's just a painful architecture to run. And there's all this other little gotchas with Chromium, like Chromium, which is the open source version of Chrome, by the way. You have to install all these fonts. You want emojis working in your browsers because your vision model is looking for the emoji. You need to make sure you have the emoji fonts. You need to make sure you have all the right extensions configured, like, oh, do you want ad blocking? How do you configure that? How do you actually record all these browser sessions? Like it's a headless browser. You can't look at it. So you need to have some sort of observability. Maybe you're recording videos and storing those somewhere. It all kind of adds up to be this just giant monster piece of your project when all you wanted to do was run a lot of browsers in production for this little script to go to google.com and search. And when I see a complex distributed system, I see an opportunity to build a great infrastructure company. And we really abstract that away with Browserbase where our customers can use these existing frameworks, Playwright, Publisher, Selenium, or our own stagehand and connect to our browsers in a serverless-like way. And control them, and then just disconnect when they're done. And they don't have to think about the complex distributed system behind all of that. They just get a browser running anywhere, anytime. Really easy to connect to.swyx [00:15:55]: I'm sure you have questions. My standard question with anything, so essentially you're a serverless browser company, and there's been other serverless things that I'm familiar with in the past, serverless GPUs, serverless website hosting. That's where I come from with Netlify. One question is just like, you promised to spin up thousands of servers. You promised to spin up thousands of browsers in milliseconds. I feel like there's no real solution that does that yet. And I'm just kind of curious how. The only solution I know, which is to kind of keep a kind of warm pool of servers around, which is expensive, but maybe not so expensive because it's just CPUs. So I'm just like, you know. Yeah.Browsers as a Core Primitive in AI InfrastructurePaul [00:16:36]: You nailed it, right? I mean, how do you offer a serverless-like experience with something that is clearly not serverless, right? And the answer is, you need to be able to run... We run many browsers on single nodes. We use Kubernetes at browser base. So we have many pods that are being scheduled. We have to predictably schedule them up or down. Yes, thousands of browsers in milliseconds is the best case scenario. If you hit us with 10,000 requests, you may hit a slower cold start, right? So we've done a lot of work on predictive scaling and being able to kind of route stuff to different regions where we have multiple regions of browser base where we have different pools available. You can also pick the region you want to go to based on like lower latency, round trip, time latency. It's very important with these types of things. There's a lot of requests going over the wire. So for us, like having a VM like Firecracker powering everything under the hood allows us to be super nimble and spin things up or down really quickly with strong multi-tenancy. But in the end, this is like the complex infrastructural challenges that we have to kind of deal with at browser base. And we have a lot more stuff on our roadmap to allow customers to have more levers to pull to exchange, do you want really fast browser startup times or do you want really low costs? And if you're willing to be more flexible on that, we may be able to kind of like work better for your use cases.swyx [00:17:44]: Since you used Firecracker, shouldn't Fargate do that for you or did you have to go lower level than that? We had to go lower level than that.Paul [00:17:51]: I find this a lot with Fargate customers, which is alarming for Fargate. We used to be a giant Fargate customer. Actually, the first version of browser base was ECS and Fargate. And unfortunately, it's a great product. I think we were actually the largest Fargate customer in our region for a little while. No, what? Yeah, seriously. And unfortunately, it's a great product, but I think if you're an infrastructure company, you actually have to have a deeper level of control over these primitives. I think it's the same thing is true with databases. We've used other database providers and I think-swyx [00:18:21]: Yeah, serverless Postgres.Paul [00:18:23]: Shocker. When you're an infrastructure company, you're on the hook if any provider has an outage. And I can't tell my customers like, hey, we went down because so-and-so went down. That's not acceptable. So for us, we've really moved to bringing things internally. It's kind of opposite of what we preach. We tell our customers, don't build this in-house, but then we're like, we build a lot of stuff in-house. But I think it just really depends on what is in the critical path. We try and have deep ownership of that.Alessio [00:18:46]: On the distributed location side, how does that work for the web where you might get sort of different content in different locations, but the customer is expecting, you know, if you're in the US, I'm expecting the US version. But if you're spinning up my browser in France, I might get the French version. Yeah.Paul [00:19:02]: Yeah. That's a good question. Well, generally, like on the localization, there is a thing called locale in the browser. You can set like what your locale is. If you're like in the ENUS browser or not, but some things do IP, IP based routing. And in that case, you may want to have a proxy. Like let's say you're running something in the, in Europe, but you want to make sure you're showing up from the US. You may want to use one of our proxy features so you can turn on proxies to say like, make sure these connections always come from the United States, which is necessary too, because when you're browsing the web, you're coming from like a, you know, data center IP, and that can make things a lot harder to browse web. So we do have kind of like this proxy super network. Yeah. We have a proxy for you based on where you're going, so you can reliably automate the web. But if you get scheduled in Europe, that doesn't happen as much. We try and schedule you as close to, you know, your origin that you're trying to go to. But generally you have control over the regions you can put your browsers in. So you can specify West one or East one or Europe. We only have one region of Europe right now, actually. Yeah.Alessio [00:19:55]: What's harder, the browser or the proxy? I feel like to me, it feels like actually proxying reliably at scale. It's much harder than spending up browsers at scale. I'm curious. It's all hard.Paul [00:20:06]: It's layers of hard, right? Yeah. I think it's different levels of hard. I think the thing with the proxy infrastructure is that we work with many different web proxy providers and some are better than others. Some have good days, some have bad days. And our customers who've built browser infrastructure on their own, they have to go and deal with sketchy actors. Like first they figure out their own browser infrastructure and then they got to go buy a proxy. And it's like you can pay in Bitcoin and it just kind of feels a little sus, right? It's like you're buying drugs when you're trying to get a proxy online. We have like deep relationships with these counterparties. We're able to audit them and say, is this proxy being sourced ethically? Like it's not running on someone's TV somewhere. Is it free range? Yeah. Free range organic proxies, right? Right. We do a level of diligence. We're SOC 2. So we have to understand what is going on here. But then we're able to make sure that like we route around proxy providers not working. There's proxy providers who will just, the proxy will stop working all of a sudden. And then if you don't have redundant proxying on your own browsers, that's hard down for you or you may get some serious impacts there. With us, like we intelligently know, hey, this proxy is not working. Let's go to this one. And you can kind of build a network of multiple providers to really guarantee the best uptime for our customers. Yeah. So you don't own any proxies? We don't own any proxies. You're right. The team has been saying who wants to like take home a little proxy server, but not yet. We're not there yet. You know?swyx [00:21:25]: It's a very mature market. I don't think you should build that yourself. Like you should just be a super customer of them. Yeah. Scraping, I think, is the main use case for that. I guess. Well, that leads us into CAPTCHAs and also off, but let's talk about CAPTCHAs. You had a little spiel that you wanted to talk about CAPTCHA stuff.Challenges of Scaling Browser InfrastructurePaul [00:21:43]: Oh, yeah. I was just, I think a lot of people ask, if you're thinking about proxies, you're thinking about CAPTCHAs too. I think it's the same thing. You can go buy CAPTCHA solvers online, but it's the same buying experience. It's some sketchy website, you have to integrate it. It's not fun to buy these things and you can't really trust that the docs are bad. What Browserbase does is we integrate a bunch of different CAPTCHAs. We do some stuff in-house, but generally we just integrate with a bunch of known vendors and continually monitor and maintain these things and say, is this working or not? Can we route around it or not? These are CAPTCHA solvers. CAPTCHA solvers, yeah. Not CAPTCHA providers, CAPTCHA solvers. Yeah, sorry. CAPTCHA solvers. We really try and make sure all of that works for you. I think as a dev, if I'm buying infrastructure, I want it all to work all the time and it's important for us to provide that experience by making sure everything does work and monitoring it on our own. Yeah. Right now, the world of CAPTCHAs is tricky. I think AI agents in particular are very much ahead of the internet infrastructure. CAPTCHAs are designed to block all types of bots, but there are now good bots and bad bots. I think in the future, CAPTCHAs will be able to identify who a good bot is, hopefully via some sort of KYC. For us, we've been very lucky. We have very little to no known abuse of Browserbase because we really look into who we work with. And for certain types of CAPTCHA solving, we only allow them on certain types of plans because we want to make sure that we can know what people are doing, what their use cases are. And that's really allowed us to try and be an arbiter of good bots, which is our long term goal. I want to build great relationships with people like Cloudflare so we can agree, hey, here are these acceptable bots. We'll identify them for you and make sure we flag when they come to your website. This is a good bot, you know?Alessio [00:23:23]: I see. And Cloudflare said they want to do more of this. So they're going to set by default, if they think you're an AI bot, they're going to reject. I'm curious if you think this is something that is going to be at the browser level or I mean, the DNS level with Cloudflare seems more where it should belong. But I'm curious how you think about it.Paul [00:23:40]: I think the web's going to change. You know, I think that the Internet as we have it right now is going to change. And we all need to just accept that the cat is out of the bag. And instead of kind of like wishing the Internet was like it was in the 2000s, we can have free content line that wouldn't be scraped. It's just it's not going to happen. And instead, we should think about like, one, how can we change? How can we change the models of, you know, information being published online so people can adequately commercialize it? But two, how do we rebuild applications that expect that AI agents are going to log in on their behalf? Those are the things that are going to allow us to kind of like identify good and bad bots. And I think the team at Clerk has been doing a really good job with this on the authentication side. I actually think that auth is the biggest thing that will prevent agents from accessing stuff, not captchas. And I think there will be agent auth in the future. I don't know if it's going to happen from an individual company, but actually authentication providers that have a, you know, hidden login as agent feature, which will then you put in your email, you'll get a push notification, say like, hey, your browser-based agent wants to log into your Airbnb. You can approve that and then the agent can proceed. That really circumvents the need for captchas or logging in as you and sharing your password. I think agent auth is going to be one way we identify good bots going forward. And I think a lot of this captcha solving stuff is really short-term problems as the internet kind of reorients itself around how it's going to work with agents browsing the web, just like people do. Yeah.Managing Distributed Browser Locations and Proxiesswyx [00:24:59]: Stitch recently was on Hacker News for talking about agent experience, AX, which is a thing that Netlify is also trying to clone and coin and talk about. And we've talked about this on our previous episodes before in a sense that I actually think that's like maybe the only part of the tech stack that needs to be kind of reinvented for agents. Everything else can stay the same, CLIs, APIs, whatever. But auth, yeah, we need agent auth. And it's mostly like short-lived, like it should not, it should be a distinct, identity from the human, but paired. I almost think like in the same way that every social network should have your main profile and then your alt accounts or your Finsta, it's almost like, you know, every, every human token should be paired with the agent token and the agent token can go and do stuff on behalf of the human token, but not be presumed to be the human. Yeah.Paul [00:25:48]: It's like, it's, it's actually very similar to OAuth is what I'm thinking. And, you know, Thread from Stitch is an investor, Colin from Clerk, Octaventures, all investors in browser-based because like, I hope they solve this because they'll make browser-based submission more possible. So we don't have to overcome all these hurdles, but I think it will be an OAuth-like flow where an agent will ask to log in as you, you'll approve the scopes. Like it can book an apartment on Airbnb, but it can't like message anybody. And then, you know, the agent will have some sort of like role-based access control within an application. Yeah. I'm excited for that.swyx [00:26:16]: The tricky part is just, there's one, one layer of delegation here, which is like, you're authoring my user's user or something like that. I don't know if that's tricky or not. Does that make sense? Yeah.Paul [00:26:25]: You know, actually at Twilio, I worked on the login identity and access. Management teams, right? So like I built Twilio's login page.swyx [00:26:31]: You were an intern on that team and then you became the lead in two years? Yeah.Paul [00:26:34]: Yeah. I started as an intern in 2016 and then I was the tech lead of that team. How? That's not normal. I didn't have a life. He's not normal. Look at this guy. I didn't have a girlfriend. I just loved my job. I don't know. I applied to 500 internships for my first job and I got rejected from every single one of them except for Twilio and then eventually Amazon. And they took a shot on me and like, I was getting paid money to write code, which was my dream. Yeah. Yeah. I'm very lucky that like this coding thing worked out because I was going to be doing it regardless. And yeah, I was able to kind of spend a lot of time on a team that was growing at a company that was growing. So it informed a lot of this stuff here. I think these are problems that have been solved with like the SAML protocol with SSO. I think it's a really interesting stuff with like WebAuthn, like these different types of authentication, like schemes that you can use to authenticate people. The tooling is all there. It just needs to be tweaked a little bit to work for agents. And I think the fact that there are companies that are already. Providing authentication as a service really sets it up. Well, the thing that's hard is like reinventing the internet for agents. We don't want to rebuild the internet. That's an impossible task. And I think people often say like, well, we'll have this second layer of APIs built for agents. I'm like, we will for the top use cases, but instead of we can just tweak the internet as is, which is on the authentication side, I think we're going to be the dumb ones going forward. Unfortunately, I think AI is going to be able to do a lot of the tasks that we do online, which means that it will be able to go to websites, click buttons on our behalf and log in on our behalf too. So with this kind of like web agent future happening, I think with some small structural changes, like you said, it feels like it could all slot in really nicely with the existing internet.Handling CAPTCHAs and Agent Authenticationswyx [00:28:08]: There's one more thing, which is the, your live view iframe, which lets you take, take control. Yeah. Obviously very key for operator now, but like, was, is there anything interesting technically there or that the people like, well, people always want this.Paul [00:28:21]: It was really hard to build, you know, like, so, okay. Headless browsers, you don't see them, right. They're running. They're running in a cloud somewhere. You can't like look at them. And I just want to really make, it's a weird name. I wish we came up with a better name for this thing, but you can't see them. Right. But customers don't trust AI agents, right. At least the first pass. So what we do with our live view is that, you know, when you use browser base, you can actually embed a live view of the browser running in the cloud for your customer to see it working. And that's what the first reason is the build trust, like, okay, so I have this script. That's going to go automate a website. I can embed it into my web application via an iframe and my customer can watch. I think. And then we added two way communication. So now not only can you watch the browser kind of being operated by AI, if you want to pause and actually click around type within this iframe that's controlling a browser, that's also possible. And this is all thanks to some of the lower level protocol, which is called the Chrome DevTools protocol. It has a API called start screencast, and you can also send mouse clicks and button clicks to a remote browser. And this is all embeddable within iframes. You have a browser within a browser, yo. And then you simulate the screen, the click on the other side. Exactly. And this is really nice often for, like, let's say, a capture that can't be solved. You saw this with Operator, you know, Operator actually uses a different approach. They use VNC. So, you know, you're able to see, like, you're seeing the whole window here. What we're doing is something a little lower level with the Chrome DevTools protocol. It's just PNGs being streamed over the wire. But the same thing is true, right? Like, hey, I'm running a window. Pause. Can you do something in this window? Human. Okay, great. Resume. Like sometimes 2FA tokens. Like if you get that text message, you might need a person to type that in. Web agents need human-in-the-loop type workflows still. You still need a person to interact with the browser. And building a UI to proxy that is kind of hard. You may as well just show them the whole browser and say, hey, can you finish this up for me? And then let the AI proceed on afterwards. Is there a future where I stream my current desktop to browser base? I don't think so. I think we're very much cloud infrastructure. Yeah. You know, but I think a lot of the stuff we're doing, we do want to, like, build tools. Like, you know, we'll talk about the stage and, you know, web agent framework in a second. But, like, there's a case where a lot of people are going desktop first for, you know, consumer use. And I think cloud is doing a lot of this, where I expect to see, you know, MCPs really oriented around the cloud desktop app for a reason, right? Like, I think a lot of these tools are going to run on your computer because it makes... I think it's breaking out. People are putting it on a server. Oh, really? Okay. Well, sweet. We'll see. We'll see that. I was surprised, though, wasn't I? I think that the browser company, too, with Dia Browser, it runs on your machine. You know, it's going to be...swyx [00:30:50]: What is it?Paul [00:30:51]: So, Dia Browser, as far as I understand... I used to use Arc. Yeah. I haven't used Arc. But I'm a big fan of the browser company. I think they're doing a lot of cool stuff in consumer. As far as I understand, it's a browser where you have a sidebar where you can, like, chat with it and it can control the local browser on your machine. So, if you imagine, like, what a consumer web agent is, which it lives alongside your browser, I think Google Chrome has Project Marina, I think. I almost call it Project Marinara for some reason. I don't know why. It's...swyx [00:31:17]: No, I think it's someone really likes the Waterworld. Oh, I see. The classic Kevin Costner. Yeah.Paul [00:31:22]: Okay. Project Marinara is a similar thing to the Dia Browser, in my mind, as far as I understand it. You have a browser that has an AI interface that will take over your mouse and keyboard and control the browser for you. Great for consumer use cases. But if you're building applications that rely on a browser and it's more part of a greater, like, AI app experience, you probably need something that's more like infrastructure, not a consumer app.swyx [00:31:44]: Just because I have explored a little bit in this area, do people want branching? So, I have the state. Of whatever my browser's in. And then I want, like, 100 clones of this state. Do people do that? Or...Paul [00:31:56]: People don't do it currently. Yeah. But it's definitely something we're thinking about. I think the idea of forking a browser is really cool. Technically, kind of hard. We're starting to see this in code execution, where people are, like, forking some, like, code execution, like, processes or forking some tool calls or branching tool calls. Haven't seen it at the browser level yet. But it makes sense. Like, if an AI agent is, like, using a website and it's not sure what path it wants to take to crawl this website. To find the information it's looking for. It would make sense for it to explore both paths in parallel. And that'd be a very, like... A road not taken. Yeah. And hopefully find the right answer. And then say, okay, this was actually the right one. And memorize that. And go there in the future. On the roadmap. For sure. Don't make my roadmap, please. You know?Alessio [00:32:37]: How do you actually do that? Yeah. How do you fork? I feel like the browser is so stateful for so many things.swyx [00:32:42]: Serialize the state. Restore the state. I don't know.Paul [00:32:44]: So, it's one of the reasons why we haven't done it yet. It's hard. You know? Like, to truly fork, it's actually quite difficult. The naive way is to open the same page in a new tab and then, like, hope that it's at the same thing. But if you have a form halfway filled, you may have to, like, take the whole, you know, container. Pause it. All the memory. Duplicate it. Restart it from there. It could be very slow. So, we haven't found a thing. Like, the easy thing to fork is just, like, copy the page object. You know? But I think there needs to be something a little bit more robust there. Yeah.swyx [00:33:12]: So, MorphLabs has this infinite branch thing. Like, wrote a custom fork of Linux or something that let them save the system state and clone it. MorphLabs, hit me up. I'll be a customer. Yeah. That's the only. I think that's the only way to do it. Yeah. Like, unless Chrome has some special API for you. Yeah.Paul [00:33:29]: There's probably something we'll reverse engineer one day. I don't know. Yeah.Alessio [00:33:32]: Let's talk about StageHand, the AI web browsing framework. You have three core components, Observe, Extract, and Act. Pretty clean landing page. What was the idea behind making a framework? Yeah.Stagehand: AI web browsing frameworkPaul [00:33:43]: So, there's three frameworks that are very popular or already exist, right? Puppeteer, Playwright, Selenium. Those are for building hard-coded scripts to control websites. And as soon as I started to play with LLMs plus browsing, I caught myself, you know, code-genning Playwright code to control a website. I would, like, take the DOM. I'd pass it to an LLM. I'd say, can you generate the Playwright code to click the appropriate button here? And it would do that. And I was like, this really should be part of the frameworks themselves. And I became really obsessed with SDKs that take natural language as part of, like, the API input. And that's what StageHand is. StageHand exposes three APIs, and it's a super set of Playwright. So, if you go to a page, you may want to take an action, click on the button, fill in the form, etc. That's what the act command is for. You may want to extract some data. This one takes a natural language, like, extract the winner of the Super Bowl from this page. You can give it a Zod schema, so it returns a structured output. And then maybe you're building an API. You can do an agent loop, and you want to kind of see what actions are possible on this page before taking one. You can do observe. So, you can observe the actions on the page, and it will generate a list of actions. You can guide it, like, give me actions on this page related to buying an item. And you can, like, buy it now, add to cart, view shipping options, and pass that to an LLM, an agent loop, to say, what's the appropriate action given this high-level goal? So, StageHand isn't a web agent. It's a framework for building web agents. And we think that agent loops are actually pretty close to the application layer because every application probably has different goals or different ways it wants to take steps. I don't think I've seen a generic. Maybe you guys are the experts here. I haven't seen, like, a really good AI agent framework here. Everyone kind of has their own special sauce, right? I see a lot of developers building their own agent loops, and they're using tools. And I view StageHand as the browser tool. So, we expose act, extract, observe. Your agent can call these tools. And from that, you don't have to worry about it. You don't have to worry about generating playwright code performantly. You don't have to worry about running it. You can kind of just integrate these three tool calls into your agent loop and reliably automate the web.swyx [00:35:48]: A special shout-out to Anirudh, who I met at your dinner, who I think listens to the pod. Yeah. Hey, Anirudh.Paul [00:35:54]: Anirudh's a man. He's a StageHand guy.swyx [00:35:56]: I mean, the interesting thing about each of these APIs is they're kind of each startup. Like, specifically extract, you know, Firecrawler is extract. There's, like, Expand AI. There's a whole bunch of, like, extract companies. They just focus on extract. I'm curious. Like, I feel like you guys are going to collide at some point. Like, right now, it's friendly. Everyone's in a blue ocean. At some point, it's going to be valuable enough that there's some turf battle here. I don't think you have a dog in a fight. I think you can mock extract to use an external service if they're better at it than you. But it's just an observation that, like, in the same way that I see each option, each checkbox in the side of custom GBTs becoming a startup or each box in the Karpathy chart being a startup. Like, this is also becoming a thing. Yeah.Paul [00:36:41]: I mean, like, so the way StageHand works is that it's MIT-licensed, completely open source. You bring your own API key to your LLM of choice. You could choose your LLM. We don't make any money off of the extract or really. We only really make money if you choose to run it with our browser. You don't have to. You can actually use your own browser, a local browser. You know, StageHand is completely open source for that reason. And, yeah, like, I think if you're building really complex web scraping workflows, I don't know if StageHand is the tool for you. I think it's really more if you're building an AI agent that needs a few general tools or if it's doing a lot of, like, web automation-intensive work. But if you're building a scraping company, StageHand is not your thing. You probably want something that's going to, like, get HTML content, you know, convert that to Markdown, query it. That's not what StageHand does. StageHand is more about reliability. I think we focus a lot on reliability and less so on cost optimization and speed at this point.swyx [00:37:33]: I actually feel like StageHand, so the way that StageHand works, it's like, you know, page.act, click on the quick start. Yeah. It's kind of the integration test for the code that you would have to write anyway, like the Puppeteer code that you have to write anyway. And when the page structure changes, because it always does, then this is still the test. This is still the test that I would have to write. Yeah. So it's kind of like a testing framework that doesn't need implementation detail.Paul [00:37:56]: Well, yeah. I mean, Puppeteer, Playwright, and Slenderman were all designed as testing frameworks, right? Yeah. And now people are, like, hacking them together to automate the web. I would say, and, like, maybe this is, like, me being too specific. But, like, when I write tests, if the page structure changes. Without me knowing, I want that test to fail. So I don't know if, like, AI, like, regenerating that. Like, people are using StageHand for testing. But it's more for, like, usability testing, not, like, testing of, like, does the front end, like, has it changed or not. Okay. But generally where we've seen people, like, really, like, take off is, like, if they're using, you know, something. If they want to build a feature in their application that's kind of like Operator or Deep Research, they're using StageHand to kind of power that tool calling in their own agent loop. Okay. Cool.swyx [00:38:37]: So let's go into Operator, the first big agent launch of the year from OpenAI. Seems like they have a whole bunch scheduled. You were on break and your phone blew up. What's your just general view of computer use agents is what they're calling it. The overall category before we go into Open Operator, just the overall promise of Operator. I will observe that I tried it once. It was okay. And I never tried it again.OpenAI's Operator and computer use agentsPaul [00:38:58]: That tracks with my experience, too. Like, I'm a huge fan of the OpenAI team. Like, I think that I do not view Operator as the company. I'm not a company killer for browser base at all. I think it actually shows people what's possible. I think, like, computer use models make a lot of sense. And I'm actually most excited about computer use models is, like, their ability to, like, really take screenshots and reasoning and output steps. I think that using mouse click or mouse coordinates, I've seen that proved to be less reliable than I would like. And I just wonder if that's the right form factor. What we've done with our framework is anchor it to the DOM itself, anchor it to the actual item. So, like, if it's clicking on something, it's clicking on that thing, you know? Like, it's more accurate. No matter where it is. Yeah, exactly. Because it really ties in nicely. And it can handle, like, the whole viewport in one go, whereas, like, Operator can only handle what it sees. Can you hover? Is hovering a thing that you can do? I don't know if we expose it as a tool directly, but I'm sure there's, like, an API for hovering. Like, move mouse to this position. Yeah, yeah, yeah. I think you can trigger hover, like, via, like, the JavaScript on the DOM itself. But, no, I think, like, when we saw computer use, everyone's eyes lit up because they realized, like, wow, like, AI is going to actually automate work for people. And I think seeing that kind of happen from both of the labs, and I'm sure we're going to see more labs launch computer use models, I'm excited to see all the stuff that people build with it. I think that I'd love to see computer use power, like, controlling a browser on browser base. And I think, like, Open Operator, which was, like, our open source version of OpenAI's Operator, was our first take on, like, how can we integrate these models into browser base? And we handle the infrastructure and let the labs do the models. I don't have a sense that Operator will be released as an API. I don't know. Maybe it will. I'm curious to see how well that works because I think it's going to be really hard for a company like OpenAI to do things like support CAPTCHA solving or, like, have proxies. Like, I think it's hard for them structurally. Imagine this New York Times headline, OpenAI CAPTCHA solving. Like, that would be a pretty bad headline, this New York Times headline. Browser base solves CAPTCHAs. No one cares. No one cares. And, like, our investors are bored. Like, we're all okay with this, you know? We're building this company knowing that the CAPTCHA solving is short-lived until we figure out how to authenticate good bots. I think it's really hard for a company like OpenAI, who has this brand that's so, so good, to balance with, like, the icky parts of web automation, which it can be kind of complex to solve. I'm sure OpenAI knows who to call whenever they need you. Yeah, right. I'm sure they'll have a great partnership.Alessio [00:41:23]: And is Open Operator just, like, a marketing thing for you? Like, how do you think about resource allocation? So, you can spin this up very quickly. And now there's all this, like, open deep research, just open all these things that people are building. We started it, you know. You're the original Open. We're the original Open operator, you know? Is it just, hey, look, this is a demo, but, like, we'll help you build out an actual product for yourself? Like, are you interested in going more of a product route? That's kind of the OpenAI way, right? They started as a model provider and then…Paul [00:41:53]: Yeah, we're not interested in going the product route yet. I view Open Operator as a model provider. It's a reference project, you know? Let's show people how to build these things using the infrastructure and models that are out there. And that's what it is. It's, like, Open Operator is very simple. It's an agent loop. It says, like, take a high-level goal, break it down into steps, use tool calling to accomplish those steps. It takes screenshots and feeds those screenshots into an LLM with the step to generate the right action. It uses stagehand under the hood to actually execute this action. It doesn't use a computer use model. And it, like, has a nice interface using the live view that we talked about, the iframe, to embed that into an application. So I felt like people on launch day wanted to figure out how to build their own version of this. And we turned that around really quickly to show them. And I hope we do that with other things like deep research. We don't have a deep research launch yet. I think David from AOMNI actually has an amazing open deep research that he launched. It has, like, 10K GitHub stars now. So he's crushing that. But I think if people want to build these features natively into their application, they need good reference projects. And I think Open Operator is a good example of that.swyx [00:42:52]: I don't know. Actually, I'm actually pretty bullish on API-driven operator. Because that's the only way that you can sort of, like, once it's reliable enough, obviously. And now we're nowhere near. But, like, give it five years. It'll happen, you know. And then you can sort of spin this up and browsers are working in the background and you don't necessarily have to know. And it just is booking restaurants for you, whatever. I can definitely see that future happening. I had this on the landing page here. This might be a slightly out of order. But, you know, you have, like, sort of three use cases for browser base. Open Operator. Or this is the operator sort of use case. It's kind of like the workflow automation use case. And it completes with UiPath in the sort of RPA category. Would you agree with that? Yeah, I would agree with that. And then there's Agents we talked about already. And web scraping, which I imagine would be the bulk of your workload right now, right?Paul [00:43:40]: No, not at all. I'd say actually, like, the majority is browser automation. We're kind of expensive for web scraping. Like, I think that if you're building a web scraping product, if you need to do occasional web scraping or you have to do web scraping that works every single time, you want to use browser automation. Yeah. You want to use browser-based. But if you're building web scraping workflows, what you should do is have a waterfall. You should have the first request is a curl to the website. See if you can get it without even using a browser. And then the second request may be, like, a scraping-specific API. There's, like, a thousand scraping APIs out there that you can use to try and get data. Scraping B. Scraping B is a great example, right? Yeah. And then, like, if those two don't work, bring out the heavy hitter. Like, browser-based will 100% work, right? It will load the page in a real browser, hydrate it. I see.swyx [00:44:21]: Because a lot of people don't render to JS.swyx [00:44:25]: Yeah, exactly.Paul [00:44:26]: So, I mean, the three big use cases, right? Like, you know, automation, web data collection, and then, you know, if you're building anything agentic that needs, like, a browser tool, you want to use browser-based.Alessio [00:44:35]: Is there any use case that, like, you were super surprised by that people might not even think about? Oh, yeah. Or is it, yeah, anything that you can share? The long tail is crazy. Yeah.Surprising use cases of BrowserbasePaul [00:44:44]: One of the case studies on our website that I think is the most interesting is this company called Benny. So, the way that it works is if you're on food stamps in the United States, you can actually get rebates if you buy certain things. Yeah. You buy some vegetables. You submit your receipt to the government. They'll give you a little rebate back. Say, hey, thanks for buying vegetables. It's good for you. That process of submitting that receipt is very painful. And the way Benny works is you use their app to take a photo of your receipt, and then Benny will go submit that receipt for you and then deposit the money into your account. That's actually using no AI at all. It's all, like, hard-coded scripts. They maintain the scripts. They've been doing a great job. And they build this amazing consumer app. But it's an example of, like, all these, like, tedious workflows that people have to do to kind of go about their business. And they're doing it for the sake of their day-to-day lives. And I had never known about, like, food stamp rebates or the complex forms you have to do to fill them. But the world is powered by millions and millions of tedious forms, visas. You know, Emirate Lighthouse is a customer, right? You know, they do the O1 visa. Millions and millions of forms are taking away humans' time. And I hope that Browserbase can help power software that automates away the web forms that we don't need anymore. Yeah.swyx [00:45:49]: I mean, I'm very supportive of that. I mean, forms. I do think, like, government itself is a big part of it. I think the government itself should embrace AI more to do more sort of human-friendly form filling. Mm-hmm. But I'm not optimistic. I'm not holding my breath. Yeah. We'll see. Okay. I think I'm about to zoom out. I have a little brief thing on computer use, and then we can talk about founder stuff, which is, I tend to think of developer tooling markets in impossible triangles, where everyone starts in a niche, and then they start to branch out. So I already hinted at a little bit of this, right? We mentioned more. We mentioned E2B. We mentioned Firecrawl. And then there's Browserbase. So there's, like, all this stuff of, like, have serverless virtual computer that you give to an agent and let them do stuff with it. And there's various ways of connecting it to the internet. You can just connect to a search API, like SERP API, whatever other, like, EXA is another one. That's what you're searching. You can also have a JSON markdown extractor, which is Firecrawl. Or you can have a virtual browser like Browserbase, or you can have a virtual machine like Morph. And then there's also maybe, like, a virtual sort of code environment, like Code Interpreter. So, like, there's just, like, a bunch of different ways to tackle the problem of give a computer to an agent. And I'm just kind of wondering if you see, like, everyone's just, like, happily coexisting in their respective niches. And as a developer, I just go and pick, like, a shopping basket of one of each. Or do you think that you eventually, people will collide?Future of browser automation and market competitionPaul [00:47:18]: I think that currently it's not a zero-sum market. Like, I think we're talking about... I think we're talking about all of knowledge work that people do that can be automated online. All of these, like, trillions of hours that happen online where people are working. And I think that there's so much software to be built that, like, I tend not to think about how these companies will collide. I just try to solve the problem as best as I can and make this specific piece of infrastructure, which I think is an important primitive, the best I possibly can. And yeah. I think there's players that are actually going to like it. I think there's players that are going to launch, like, over-the-top, you know, platforms, like agent platforms that have all these tools built in, right? Like, who's building the rippling for agent tools that has the search tool, the browser tool, the operating system tool, right? There are some. There are some. There are some, right? And I think in the end, what I have seen as my time as a developer, and I look at all the favorite tools that I have, is that, like, for tools and primitives with sufficient levels of complexity, you need to have a solution that's really bespoke to that primitive, you know? And I am sufficiently convinced that the browser is complex enough to deserve a primitive. Obviously, I have to. I'm the founder of BrowserBase, right? I'm talking my book. But, like, I think maybe I can give you one spicy take against, like, maybe just whole OS running. I think that when I look at computer use when it first came out, I saw that the majority of use cases for computer use were controlling a browser. And do we really need to run an entire operating system just to control a browser? I don't think so. I don't think that's necessary. You know, BrowserBase can run browsers for way cheaper than you can if you're running a full-fledged OS with a GUI, you know, operating system. And I think that's just an advantage of the browser. It is, like, browsers are little OSs, and you can run them very efficiently if you orchestrate it well. And I think that allows us to offer 90% of the, you know, functionality in the platform needed at 10% of the cost of running a full OS. Yeah.Open Operator: Browserbase's Open-Source Alternativeswyx [00:49:16]: I definitely see the logic in that. There's a Mark Andreessen quote. I don't know if you know this one. Where he basically observed that the browser is turning the operating system into a poorly debugged set of device drivers, because most of the apps are moved from the OS to the browser. So you can just run browsers.Paul [00:49:31]: There's a place for OSs, too. Like, I think that there are some applications that only run on Windows operating systems. And Eric from pig.dev in this upcoming YC batch, or last YC batch, like, he's building all run tons of Windows operating systems for you to control with your agent. And like, there's some legacy EHR systems that only run on Internet-controlled systems. Yeah.Paul [00:49:54]: I think that's it. I think, like, there are use cases for specific operating systems for specific legacy software. And like, I'm excited to see what he does with that. I just wanted to give a shout out to the pig.dev website.swyx [00:50:06]: The pigs jump when you click on them. Yeah. That's great.Paul [00:50:08]: Eric, he's the former co-founder of banana.dev, too.swyx [00:50:11]: Oh, that Eric. Yeah. That Eric. Okay. Well, he abandoned bananas for pigs. I hope he doesn't start going around with pigs now.Alessio [00:50:18]: Like he was going around with bananas. A little toy pig. Yeah. Yeah. I love that. What else are we missing? I think we covered a lot of, like, the browser-based product history, but. What do you wish people asked you? Yeah.Paul [00:50:29]: I wish people asked me more about, like, what will the future of software look like? Because I think that's really where I've spent a lot of time about why do browser-based. Like, for me, starting a company is like a means of last resort. Like, you shouldn't start a company unless you absolutely have to. And I remain convinced that the future of software is software that you're going to click a button and it's going to do stuff on your behalf. Right now, software. You click a button and it maybe, like, calls it back an API and, like, computes some numbers. It, like, modifies some text, whatever. But the future of software is software using software. So, I may log into my accounting website for my business, click a button, and it's going to go load up my Gmail, search my emails, find the thing, upload the receipt, and then comment it for me. Right? And it may use it using APIs, maybe a browser. I don't know. I think it's a little bit of both. But that's completely different from how we've built software so far. And that's. I think that future of software has different infrastructure requirements. It's going to require different UIs. It's going to require different pieces of infrastructure. I think the browser infrastructure is one piece that fits into that, along with all the other categories you mentioned. So, I think that it's going to require developers to think differently about how they've built software for, you know

This week, our OG returns with one of his typical journeys through soulful, disco, uplifting and thumping house music along some cheeky bootlegs to mix it up. Now available on Apple Podcasts and all the proper ones Tracklisting

Nikolas Burk, DevRel at Prisma, talks about Prisma Postgres, its unikernel architecture, and its seamless integration with cloud infrastructure. Discover how Prisma Postgres is revolutionizing database management with features like cold start elimination, real-time event handling and advanced caching strategies! Links https://www.prisma.io/blog/announcing-prisma-postgres-early-access https://x.com/nikolasburk https://www.linkedin.com/in/nikolas-burk-1bbb7b8a https://github.com/nikolasburk We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Nikolas Burk.

This week, our "love doctor" LYP brings you all a sensual selection of romantic house delights for your Valentines day. Feel the love!

“Software is eating the world.” That was written over 14 years ago, back in 2011 by Marc Andreesen, and it seems like that is growing more true every day. Today we're going to talk about the increasingly digital nature of businesses - all businesses - as well as how the concept of composability, which has been applied effectively in the world of software, might just have applications well beyond technology infrastructure. To help me discuss this topic, I'd like to welcome Chris Bach, Co-Founder of Netlify. RESOURCES Wix Studio is the ultimate web platform for creative, fast-paced teams at agencies and enterprises—with smart design tools, flexible dev capabilities, full-stack business solutions, multi-site management, advanced AI and fully managed infrastructure. https://www.wix.com/studio Don't miss Medallia Experience 2025, March 24-26 in Las Vegas: Registration is now available: https://cvent.me/AmO1k0 Use code MEDEXP25 for $200 off registration Register now for HumanX 2025. This AI-focused event which brings some of the most forward-thinking minds in technology together. Register now with the code "HX25p_tab" for $250 off the regular price. Connect with Greg on LinkedIn: https://www.linkedin.com/in/gregkihlstrom Don't miss a thing: get the latest episodes, sign up for our newsletter and more: https://www.theagilebrand.show Check out The Agile Brand Guide website with articles, insights, and Martechipedia, the wiki for marketing technology: https://www.agilebrandguide.com The Agile Brand podcast is brought to you by TEKsystems. Learn more here: https://www.teksystems.com/versionnextnow The Agile Brand is produced by Missing Link—a Latina-owned strategy-driven, creatively fueled production co-op. From ideation to creation, they craft human connections through intelligent, engaging and informative content. https://www.missinglink.company

“Software is eating the world.” That was written over 14 years ago, back in 2011 by Marc Andreesen, and it seems like that is growing more true every day. Today we're going to talk about the increasingly digital nature of businesses - all businesses - as well as how the concept of composability, which has been applied effectively in the world of software, might just have applications well beyond technology infrastructure. To help me discuss this topic, I'd like to welcome Chris Bach, Co-Founder of Netlify. RESOURCES Wix Studio is the ultimate web platform for creative, fast-paced teams at agencies and enterprises—with smart design tools, flexible dev capabilities, full-stack business solutions, multi-site management, advanced AI and fully managed infrastructure. https://www.wix.com/studio Don't miss Medallia Experience 2025, March 24-26 in Las Vegas: Registration is now available: https://cvent.me/AmO1k0 Use code MEDEXP25 for $200 off registration Register now for HumanX 2025. This AI-focused event which brings some of the most forward-thinking minds in technology together. Register now with the code "HX25p_tab" for $250 off the regular price. Connect with Greg on LinkedIn: https://www.linkedin.com/in/gregkihlstrom Don't miss a thing: get the latest episodes, sign up for our newsletter and more: https://www.theagilebrand.show Check out The Agile Brand Guide website with articles, insights, and Martechipedia, the wiki for marketing technology: https://www.agilebrandguide.com The Agile Brand podcast is brought to you by TEKsystems. Learn more here: https://www.teksystems.com/versionnextnow The Agile Brand is produced by Missing Link—a Latina-owned strategy-driven, creatively fueled production co-op. From ideation to creation, they craft human connections through intelligent, engaging and informative content. https://www.missinglink.company

Real Life Devon shared his thoughts on Red One, a Christmas action movie involving a military operation to save Santa, describing it as “a slog and not clever,” though his kid loved Home Alone. Steven wrapped up holiday cleanup and started reading Future Noir, a deep dive into the making of Blade Runner. He also reflected on the differences between narration in Blade Runner and Dark City. Ben has been dealing with his son's walking pneumonia and spent time playing Inertial Drift (check out the free prologue). On the music side, he enjoyed 311's cover of The Offspring and The Offspring's cover of 311.   Future or Now Note this: Exploring the Obsidian Digital Garden Plugin, a tool to publish notes from Obsidian directly online. Supports static site generation and free hosting on Vercel or Netlify. Obsidian Digital Garden Docs | Ben's Demo All Around the Globe: Discussed Flat-Earthers' humbling experience in Antarctica while attempting to prove their theories. Article: Flat-Earthers Travel to Antarctica Nevermind That Noise You Heard: Highlighted research on the link between poor sleep and mental health issues due to brain deficits that block unwanted thoughts. Related to themes from Reminiscence. Science Daily Article Reminiscence IMDB link   Book Club Next Week: The Ones Who Walk Away From Omelas by Ursula K. Le Guin Read Online This Week: Arthur C. Clarke's The Nine Billion Names of God Read Online | Audiobook on YouTube Discussion on its themes appearing in works like Three-Body Problem, Spin, and Blindsight. Steven and Devon brainstorm the logistics of a Futurama-style “smell-o-scope,” inspired by Godfellas. Futurama Wiki: Godfellas Devon: Talked about philosopher Philipp Mainländer and his fascinating, existential ideas. Wikipedia: Philipp Mainländer

The PolicyViz Podcast wraps up 2024 with David Keyes, author of the new book, R for the Rest of Us: A Statistics-Free Introduction! We not only talk about how you can get started in R using David's book, but also building data and data visualization workflows with R, RMarkdown, and Quarto. We also talk about how to create consistent visualizations through themes and functions in R to help new R users leverage its features without being intimidated by complex statistics.I hope you enjoy this episode and have a great holiday season! See you in 2025!!Keywords: data, data visualization, PolicyVizPodcast, JonSchwabish, DavidKeyes, RForTheRestOfUs, DataCommunication, DataVisualization, Quarto, RMarkdown, DataPresentation, BrandedVisualizations, Excel, SelfTaughtR, QuantitativeEvaluation, ChatGPT, QualitativeDataAnalysis, TablesInR, EfficiencyInR, SPSS, SAS, Stata, ggplot, ReproducibleResearch, BeginnerFriendlyR, QuartoVsRMarkdown, SurveyDataAutomation, Netlify, DataManagementWorkflow, LearningR, mathematics, Al, machine learningSubscribe to the PolicyViz Podcast wherever you get your podcasts.Become a patron of the PolicyViz Podcast for as little as a buck a monthCheck out David's website and podcast, and grab his book R for the Rest of Us on AmazonFollow me on Instagram, LinkedIn, Substack, Twitter, Website, YouTubeEmail: jon@policyviz.com

The full schedule for Latent Space LIVE! at NeurIPS has been announced, featuring Best of 2024 overview talks for the AI Startup Landscape, Computer Vision, Open Models, Transformers Killers, Synthetic Data, Agents, and Scaling, and speakers from Sarah Guo of Conviction, Roboflow, AI2/Meta, Recursal/Together, HuggingFace, OpenHands and SemiAnalysis. Join us for the IRL event/Livestream! Alessio will also be holding a meetup at AWS Re:Invent in Las Vegas this Wednesday. See our new Events page for dates of AI Engineer Summit, Singapore, and World's Fair in 2025. LAST CALL for questions for our big 2024 recap episode! Submit questions and messages on Speakpipe here for a chance to appear on the show!When we first observed that GPT Wrappers are Good, Actually, we did not even have Bolt on our radar. Since we recorded our Anthropic episode discussing building Agents with the new Claude 3.5 Sonnet, Bolt.new (by Stackblitz) has easily cleared the $8m ARR bar, repeating and accelerating its initial $4m feat.There are very many AI code generators and VS Code forks out there, but Bolt probably broke through initially because of its incredible zero shot low effort app generation:But as we explain in the pod, Bolt also emphasized deploy (Netlify)/ backend (Supabase)/ fullstack capabilities on top of Stackblitz's existing WebContainer full-WASM-powered-developer-environment-in-the-browser tech. Since then, the team has been shipping like mad (with weekly office hours), with bugfixing, full screen, multi-device, long context, diff based edits (using speculative decoding like we covered in Inference, Fast and Slow).All of this has captured the imagination of low/no code builders like Greg Isenberg and many others on YouTube/TikTok/Reddit/X/Linkedin etc:Just as with Fireworks, our relationship with Bolt/Stackblitz goes a bit deeper than normal - swyx advised the launch and got a front row seat to this epic journey, as well as demoed it with Realtime Voice at the recent OpenAI Dev Day. So we are very proud to be the first/closest to tell the full open story of Bolt/Stackblitz!Flow Engineering + Qodo/AlphaCodium UpdateIn year 2 of the pod we have been on a roll getting former guests to return as guest cohosts (Harrison Chase, Aman Sanger, Jon Frankle), and it was a pleasure to catch Itamar Friedman back on the pod, giving us an update on all things Qodo and Testing Agents from our last catchup a year and a half ago:Qodo (they renamed in September) went viral in early January this year with AlphaCodium (paper here, code here) beating DeepMind's AlphaCode with high efficiency:With a simple problem solving code agent:* The first step is to have the model reason about the problem. They describe it using bullet points and focus on the goal, inputs, outputs, rules, constraints, and any other relevant details.* Then, they make the model reason about the public tests and come up with an explanation of why the input leads to that particular output. * The model generates two to three potential solutions in text and ranks them in terms of correctness, simplicity, and robustness. * Then, it generates more diverse tests for the problem, covering cases not part of the original public tests. * Iteratively, pick a solution, generate the code, and run it on a few test cases. * If the tests fail, improve the code and repeat the process until the code passes every test.swyx has previously written similar thoughts on types vs tests for putting bounds on program behavior, but AlphaCodium extends this to AI generated tests and code.More recently, Itamar has also shown that AlphaCodium's techniques also extend well to the o1 models:Making Flow Engineering a useful technique to improve code model performance on every model. This is something we see AI Engineers uniquely well positioned to do compared to ML Engineers/Researchers.Full Video PodcastLike and subscribe!Show Notes* Itamar* Qodo* First episode* Eric* Bolt* StackBlitz* Thinkster* AlphaCodium* WebContainersChapters* 00:00:00 Introductions & Updates* 00:06:01 Generic vs. Specific AI Agents* 00:07:40 Maintaining vs Creating with AI* 00:17:46 Human vs Agent Computer Interfaces* 00:20:15 Why Docker doesn't work for Bolt* 00:24:23 Creating Testing and Code Review Loops* 00:28:07 Bolt's Task Breakdown Flow* 00:31:04 AI in Complex Enterprise Environments* 00:41:43 AlphaCodium* 00:44:39 Strategies for Breaking Down Complex Tasks* 00:45:22 Building in Open Source* 00:50:35 Choosing a product as a founder* 00:59:03 Reflections on Bolt Success* 01:06:07 Building a B2C GTM* 01:18:11 AI Capabilities and Pricing Tiers* 01:20:28 What makes Bolt unique* 01:23:07 Future Growth and Product Development* 01:29:06 Competitive Landscape in AI Engineering* 01:30:01 Advice to Founders and Embracing AI* 01:32:20 Having a baby and completing an Iron ManTranscriptAlessio [00:00:00]: Hey everyone, welcome to the Latent Space Podcast. This is Alessio, partner and CTO at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol.ai.Swyx [00:00:12]: Hey, and today we're still in our sort of makeshift in-between studio, but we're very delighted to have a former returning guest host, Itamar. Welcome back.Itamar [00:00:21]: Great to be here after a year or more. Yeah, a year and a half.Swyx [00:00:24]: You're one of our earliest guests on Agents. Now you're CEO co-founder of Kodo. Right. Which has just been renamed. You also raised a $40 million Series A, and we can get caught up on everything, but we're also delighted to have our new guest, Eric. Welcome.Eric [00:00:42]: Thank you. Excited to be here. Should I say Bolt or StackBlitz?Swyx [00:00:45]: Like, is it like its own company now or?Eric [00:00:47]: Yeah. Bolt's definitely bolt.new. That's the thing that we're probably the most known for, I imagine, at this point.Swyx [00:00:54]: Which is ridiculous to say because you were working at StackBlitz for so long.Eric [00:00:57]: Yeah. I mean, within a week, we were doing like double the amount of traffic. And StackBlitz had been online for seven years, and we were like, what? But anyways, yeah. So we're StackBlitz, the company behind bolt.new. If you've heard of bolt.new, that's our stuff. Yeah.Swyx [00:01:12]: Yeah.Itamar [00:01:13]: Excellent. I see, by the way, that the founder mode, you need to know to capture opportunities. So kudos on doing that, right? You're working on some technology, and then suddenly you can exploit that to a new world. Yeah.Eric [00:01:24]: Totally. And I think, well, not to jump, but 100%, I mean, a couple of months ago, we had the idea for Bolt earlier this year, but we haven't really shared this too much publicly. But we actually had tried to build it with some of those state-of-the-art models back in January, February, you can kind of imagine which, and they just weren't good enough to actually do the code generation where the code was accurate and it was fast and whatever have you without a ton of like rag, but then there was like issues with that. So we put it on the shelf and then we got kind of a sneak peek of some of the new models that have come out in the past couple of months now. And so once we saw that, once we actually saw the code gen from it, we were like, oh my God, like, okay, we can build a product around this. And so that was really the impetus of us building the thing. But with that, it was StackBlitz, the core StackBlitz product the past seven years has been an IDE for developers. So the entire user experience flow we've built up just didn't make sense. And so when we kind of went out to build Bolt, we just thought, you know, if we were inventing our product today, what would the interface look like given what is now possible with the AI code gen? And so there's definitely a lot of conversations we had internally, but you know, just kind of when we logically laid it out, we were like, yeah, I think it makes sense to just greenfield a new thing and let's see what happens. If it works great, then we'll figure it out. If it doesn't work great, then it'll get deleted at some point. So that's kind of how it actually came to be.Swyx [00:02:49]: I'll mention your background a little bit. You were also founder of Thinkster before you started StackBlitz. So both of you are second time founders. Both of you have sort of re-founded your company recently. Yours was more of a rename. I think a slightly different direction as well. And then we can talk about both. Maybe just chronologically, should we get caught up on where Kodo is first and then you know, just like what people should know since the last pod? Sure.Itamar [00:03:12]: The last pod was two months after we launched and we basically had the vision that we talked about. The idea that software development is about specification, test and code, etc. We are more on the testing part as in essence, we think that if you solve testing, you solve software development. The beautiful chart that we'll put up on screen. And testing is a really big field, like there are many dimensions, unit testing, the level of the component, how big it is, how large it is. And then there is like different type of testing, is it regression or smoke or whatever. So back then we only had like one ID extension with unit tests as in focus. One and a half year later, first ID extension supports more type of testing as context aware. We index local, local repos, but also 10,000s of repos for Fortune 500 companies. We have another agent, another tool that is called, the pure agent is the open source and the commercial one is CodoMerge. And then we have another open source called CoverAgent, which is not yet a commercial product coming very soon. It's very impressive. It could be that already people are approving automated pull requests that they don't even aware in really big open sources. So once we have enough of these, we will also launch another agent. So for the first one and a half year, what we did is grew in our offering and mostly on the side of, does this code actually works, testing, code review, et cetera. And we believe that's the critical milestone that needs to be achieved to actually have the AI engineer for enterprise software. And then like for the first year was everything bottom up, getting to 1 million installation. 2024, that was 2023, 2024 was starting to monetize, to feel like how it is to make the first buck. So we did the teams offering, it went well with a thousand of teams, et cetera. And then we started like just a few months ago to do enterprise with everything you need, which is a lot of things that discussed in the last post that was just released by Codelm. So that's how we call it at Codelm. Just opening the brackets, our company name was Codelm AI, and we renamed to Codo and we call our models Codelm. So back to my point, so we started Enterprise Motion and already have multiple Fortune 100 companies. And then with that, we raised a series of $40 million. And what's exciting about it is that enables us to develop more agents. That's our focus. I think it's very different. We're not coming very soon with an ID or something like that.Swyx [00:06:01]: You don't want to fork this code?Itamar [00:06:03]: Maybe we'll fork JetBrains or something just to be different.Swyx [00:06:08]: I noticed that, you know, I think the promise of general purpose agents has kind of died. Like everyone is doing kind of what you're doing. There's Codogen, Codomerge, and then there's a third one. What's the name of it?Itamar [00:06:17]: Yeah. Codocover. Cover. Which is like a commercial version of a cover agent. It's coming soon.Swyx [00:06:23]: Yeah. It's very similar with factory AI, also doing like droids. They all have special purpose doing things, but people don't really want general purpose agents. Right. The last time you were here, we talked about AutoGBT, the biggest thing of 2023. This year, not really relevant anymore. And I think it's mostly just because when you give me a general purpose agent, I don't know what to do with it.Eric [00:06:42]: Yeah.Itamar [00:06:43]: I totally agree with that. We're seeing it for a while and I think it will stay like that despite the computer use, et cetera, that supposedly can just replace us. You can just like prompt it to be, hey, now be a QA or be a QA person or a developer. I still think that there's a few reasons why you see like a dedicated agent. Again, I'm a bit more focused, like my head is more on complex software for big teams and enterprise, et cetera. And even think about permissions and what are the data sources and just the same way you manage permissions for users. Developers, you probably want to have dedicated guardrails and dedicated approvals for agents. I intentionally like touched a point on not many people think about. And of course, then what you can think of, like maybe there's different tools, tool use, et cetera. But just the first point by itself is a good reason why you want to have different agents.Alessio [00:07:40]: Just to compare that with Bot.new, you're almost focused on like the application is very complex and now you need better tools to kind of manage it and build on top of it. On Bot.new, it's almost like I was using it the other day. There's basically like, hey, look, I'm just trying to get started. You know, I'm not very opinionated on like how you're going to implement this. Like this is what I want to do. And you build a beautiful app with it. What people ask as the next step, you know, going back to like the general versus like specific, have you had people say, hey, you know, this is great to start, but then I want a specific Bot.new dot whatever else to do a more vertical integration and kind of like development or what's the, what do people say?Eric [00:08:18]: Yeah. I think, I think you kind of hit the, hit it head on, which is, you know, kind of the way that we've, we've kind of talked about internally is it's like people are using Bolt to go from like 0.0 to 1.0, like that's like kind of the biggest unlock that Bolt has versus most other things out there. I mean, I think that's kind of what's, what's very unique about Bolt. I think the, you know, the working on like existing enterprise applications is, I mean, it's crazy important because, you know, there's a, you look, when you look at the fortune 500, I mean, these code bases, some of these have been around for 20, 30 plus years. And so it's important to be going from, you know, 101.3 to 101.4, et cetera. I think for us, so what's been actually pretty interesting is we see there's kind of two different users for us that are coming in and it's very distinct. It's like people that are developers already. And then there's people that have never really written software and more if they have, it's been very, very minimal. And so in the first camp, what these developers are doing, like to go from zero to one, they're coming to Bolt and then they're ejecting the thing to get up or just downloading it and, you know, opening cursor, like whatever to, to, you know, keep iterating on the thing. And sometimes they'll bring it back to Bolt to like add in a huge piece of functionality or something. Right. But for the people that don't know how to code, they're actually just, they, they live in this thing. And that was one of the weird things when we launched is, you know, within a day of us being online, one of the most popular YouTube videos, and there's been a ton since, which was, you know, there's like, oh, Bolt is the cursor killer. And I originally saw the headlines and I was like, thanks for the views. I mean, I don't know. This doesn't make sense to me. That's not, that's not what we kind of thought.Swyx [00:09:44]: It's how YouTubers talk to each other. Well, everything kills everything else.Eric [00:09:47]: Totally. But what blew my mind was that there was any comparison because it's like cursor is a, is a local IDE product. But when, when we actually kind of dug into it and we, and we have people that are using our product saying this, I'm not using cursor. And I was like, what? And it turns out there are hundreds of thousands of people that we have seen that we're using cursor and we're trying to build apps with that where they're not traditional software does, but we're heavily leaning on the AI. And as you can imagine, it is very complicated, right? To do that with cursor. So when Bolt came out, they're like, wow, this thing's amazing because it kind of inverts the complexity where it's like, you know, it's not an IDE, it's, it's a, it's a chat-based sort of interface that we have. So that's kind of the split, which is rather interesting. We've had like the first startups now launch off of Bolt entirely where this, you know, tomorrow I'm doing a live stream with this guy named Paul, who he's built an entire CRM using this thing and you know, with backend, et cetera. And people have made their first money on the internet period, you know, launching this with Stripe or whatever have you. So that's, that's kind of the two main, the two main categories of folks that we see using Bolt though.Itamar [00:10:51]: I agree that I don't understand the comparison. It doesn't make sense to me. I think like we have like two type of families of tools. One is like we re-imagine the software development. I think Bolt is there and I think like a cursor is more like a evolution of what we already have. It's like taking the IDE and it's, it's amazing and it's okay, let's, let's adapt the IDE to an era where LLMs can do a lot for us. And Bolt is more like, okay, let's rethink everything totally. And I think we see a few tools there, like maybe Vercel, Veo and maybe Repl.it in that area. And then in the area of let's expedite, let's change, let's, let's progress with what we already have. You can see Cursor and Kodo, but we're different between ourselves, Cursor and Kodo, but definitely I think that comparison doesn't make sense.Alessio [00:11:42]: And just to set the context, this is not a Twitter demo. You've made 4 million of revenue in four weeks. So this is, this is actually working, you know, it's not a, what, what do you think that is? Like, there's been so many people demoing coding agents on Twitter and then it doesn't really work. And then you guys were just like, here you go, it's live, go use it, pay us for it. You know, is there anything in the development that was like interesting and maybe how that compares to building your own agents?Eric [00:12:08]: We had no idea, honestly, like we, we, we've been pretty blown away and, and things have just kind of continued to grow faster since then. We're like, oh, today is week six. So I, I kind of came back to the point you just made, right, where it's, you, you kind of outlined, it's like, there's kind of this new market of like kind of rethinking the software development and then there's heavily augmenting existing developers. I think that, you know, both of which are, you know, AI code gen being extremely good, it's allowed existing developers, it's allowing existing developers to camera out software far faster than they could have ever before, right? It's like the ultimate power tool for an existing developer. But this code gen stuff is now so good. And then, and we saw this over the past, you know, from the beginning of the year when we tried to first build, it's actually lowered the barrier to people that, that aren't traditionally software engineers. But the kind of the key thing is if you kind of think about it from, imagine you've never written software before, right? My co-founder and I, he and I grew up down the street from each other in Chicago. We learned how to code when we were 13 together and we've been building stuff ever since. And this is back in like the mid 2000s or whatever, you know, there was nothing for free to learn from online on the internet and how to code. For our 13th birthdays, we asked our parents for, you know, O'Reilly books cause you couldn't get this at the library, right? And so instead of like an Xbox, we got, you know, programming books. But the hardest part for everyone learning to code is getting an environment set up locally, you know? And so when we built StackBlitz, like kind of the key thesis, like seven years ago, the insight we had was that, Hey, it seems like the browser has a lot of new APIs like WebAssembly and service workers, et cetera, where you could actually write an operating system that ran inside the browser that could boot in milliseconds. And you, you know, basically there's this missing capability of the web. Like the web should be able to build apps for the web, right? You should be able to build the web on the web. Every other platform has that, Visual Studio for Windows, Xcode for Mac. The web has no built in primitive for this. And so just like our built in kind of like nerd instinct on this was like, that seems like a huge hole and it's, you know, it will be very valuable or like, you know, very valuable problem to solve. So if you want to set up that environments, you know, this is what we spent the past seven years doing. And the reality is existing developers have running locally. They already know how to set up that environment. So the problem isn't as acute for them. When we put Bolt online, we took that technology called WebContainer and married it with these, you know, state of the art frontier models. And the people that have the most pain with getting stuff set up locally is people that don't code. I think that's been, you know, really the big explosive reason is no one else has been trying to make dev environments work inside of a browser tab, you know, for the past if since ever, other than basically our company, largely because there wasn't an immediate demand or need. So I think we kind of find ourselves at the right place at the right time. And again, for this market of people that don't know how to write software, you would kind of expect that you should be able to do this without downloading something to your computer in the same way that, hey, I don't have to download Photoshop now to make designs because there's Figma. I don't have to download Word because there's, you know, Google Docs. They're kind of looking at this as that sort of thing, right? Which was kind of the, you know, our impetus and kind of vision from the get-go. But you know, the code gen, the AI code gen stuff that's come out has just been, you know, an order of magnitude multiplier on how magic that is, right? So that's kind of my best distillation of like, what is going on here, you know?Alessio [00:15:21]: And you can deploy too, right?Eric [00:15:22]: Yeah.Alessio [00:15:23]: Yeah.Eric [00:15:24]: And so that's, what's really cool is it's, you know, we have deployment built in with Netlify and this is actually, I think, Sean, you actually built this at Netlify when you were there. Yeah. It's one of the most brilliant integrations actually, because, you know, effectively the API that Sean built, maybe you can speak to it, but like as a provider, we can just effectively give files to Netlify without the user even logging in and they have a live website. And if they want to keep, hold onto it, they can click a link and claim it to their Netlify account. But it basically is just this really magic experience because when you come to Bolt, you say, I want a website. Like my mom, 70, 71 years old, made her first website, you know, on the internet two weeks ago, right? It was about her nursing days.Swyx [00:16:03]: Oh, that's fantastic though. It wouldn't have been made.Eric [00:16:06]: A hundred percent. Cause even in, you know, when we've had a lot of people building personal, like deeply personal stuff, like in the first week we launched this, the sales guy from the East Coast, you know, replied to a tweet of mine and he said, thank you so much for building this to your team. His daughter has a medical condition and so for her to travel, she has to like line up donors or something, you know, so ahead of time. And so he actually used Bolt to make a website to do that, to actually go and send it to folks in the region she was going to travel to ahead of time. I was really touched by it, but I also thought like, why, you know, why didn't he use like Wix or Squarespace? Right? I mean, this is, this is a solved problem, quote unquote, right? And then when I thought, I actually use Squarespace for my, for my, uh, the wedding website for my wife and I, like back in 2021, so I'm familiar, you know, it was, it was faster. I know how to code. I was like, this is faster. Right. And I thought back and I was like, there's a whole interface you have to learn how to use. And it's actually not that simple. There's like a million things you can configure in that thing. When you come to Bolt, there's a, there's a text box. You just say, I need a, I need a wedding website. Here's the date. Here's where it is. And here's a photo of me and my wife, put it somewhere relevant. It's actually the simplest way. And that's what my, when my mom came, she said, uh, I'm Pat Simons. I was a nurse in the seventies, you know, and like, here's the things I did and a website came out. So coming back to why is this such a, I think, why are we seeing this sort of growth? It's, this is the simplest interface I think maybe ever created to actually build it, a deploy a website. And then that website, my mom made, she's like, okay, this looks great. And there's, there's one button, you just click it, deploy, and it's live and you can buy a domain name, attach it to it. And you know, it's as simple as it gets, it's getting even simpler with some of the stuff we're working on. But anyways, so that's, it's, it's, uh, it's been really interesting to see some of the usage like that.Swyx [00:17:46]: I can offer my perspective. So I, you know, I probably should have disclosed a little bit that, uh, I'm a, uh, stack list investor.Alessio [00:17:53]: Canceled the episode. I know, I know. Don't play it now. Pause.Eric actually reached out to ShowMeBolt before the launch. And we, you know, we talked a lot about, like, the framing of, of what we're going to talk about how we marketed the thing, but also, like, what we're So that's what Bolt was going to need, like a whole sort of infrastructure.swyx: Netlify, I was a maintainer but I won't take claim for the anonymous upload. That's actually the origin story of Netlify. We can have Matt Billman talk about it, but that was [00:18:00] how Netlify started. You could drag and drop your zip file or folder from your desktop onto a website, it would have a live URL with no sign in.swyx: And so that was the origin story of Netlify. And it just persists to today. And it's just like it's really nice, interesting that both Bolt and CognitionDevIn and a bunch of other sort of agent type startups, they all use Netlify to deploy because of this one feature. They don't really care about the other features.swyx: But, but just because it's easy for computers to use and talk to it, like if you build an interface for computers specifically, that it's easy for them to Navigate, then they will be used in agents. And I think that's a learning that a lot of developer tools companies are having. That's my bolt launch story and now if I say all that stuff.swyx: And I just wanted to come back to, like, the Webcontainers things, right? Like, I think you put a lot of weight on the technical modes. I think you also are just like, very good at product. So you've, you've like, built a better agent than a lot of people, the rest of us, including myself, who have tried to build these things, and we didn't get as far as you did.swyx: Don't shortchange yourself on products. But I think specifically [00:19:00] on, on infra, on like the sandboxing, like this is a thing that people really want. Alessio has Bax E2B, which we'll have on at some point, talking about like the sort of the server full side. But yours is, you know, inside of the browser, serverless.swyx: It doesn't cost you anything to serve one person versus a million people. It doesn't, doesn't cost you anything. I think that's interesting. I think in theory, we should be able to like run tests because you can run the full backend. Like, you can run Git, you can run Node, you can run maybe Python someday.swyx: We talked about this. But ideally, you should be able to have a fully gentic loop, running code, seeing the errors, correcting code, and just kind of self healing, right? Like, I mean, isn't that the dream?Eric: Totally.swyx: Yeah,Eric: totally. At least in bold, we've got, we've got a good amount of that today. I mean, there's a lot more for us to do, but one of the nice things, because like in web container, you know, there's a lot of kind of stuff you go Google like, you know, turn docker container into wasm.Eric: You'll find a lot of stuff out there that will do that. The problem is it's very big, it's slow, and that ruins the experience. And so what we ended up doing is just writing an operating system from [00:20:00] scratch that was just purpose built to, you know, run in a browser tab. And the reason being is, you know, Docker 2 awesome things will give you an image that's like out 60 to 100 megabits, you know, maybe more, you know, and our, our OS, you know, kind of clocks in, I think, I think we're in like a, maybe, maybe a megabyte or less or something like that.Eric: I mean, it's, it's, you know, really, really, you know, stripped down.swyx: This is basically the task involved is I understand that it's. Mapping every single, single Linux call to some kind of web, web assembly implementation,Eric: but more or less, and, and then there's a lot of things actually, like when you're looking at a dev environment, there's a lot of things that you don't need that a traditional OS is gonna have, right?Eric: Like, you know audio drivers or you like, there's just like, there's just tons of things. Oh, yeah. Right. Yeah. That goes . Yeah. You can just kind, you can, you can kind of tos them. Or alternatively, what you can do is you can actually be the nice thing. And this is, this kind of comes back to the origins of browsers, which is, you know, they're, they're at the beginning of the web and, you know, the late nineties, there was two very different kind of visions for the web where Alan Kay vehemently [00:21:00] disagree with the idea that should be document based, which is, you know, Tim Berners Lee, you know, that, and that's kind of what ended up winning, winning was this document based kind of browsing documents on the web thing.Eric: Alan Kay, he's got this like very famous quote where he said, you know, you want web browsers to be mini operating systems. They should download little mini binaries and execute with like a little mini virtualized operating system in there. And what's kind of interesting about the history, not to geek out on this aspect, what's kind of interesting about the history is both of those folks ended up being right.Eric: Documents were actually the pragmatic way that the web worked. Was, you know, became the most ubiquitous platform in the world to the degree now that this is why WebAssembly has been invented is that we're doing, we need to do more low level things in a browser, same thing with WebGPU, et cetera. And so all these APIs, you know, to build an operating system came to the browser.Eric: And that was actually the realization we had in 2017 was, holy heck, like you can actually, you know, service workers, which were designed for allowing your app to work offline. That was the kind of the key one where it was like, wait a second, you can actually now run. Web servers within a [00:22:00] browser, like you can run a server that you open up.Eric: That's wild. Like full Node. js. Full Node. js. Like that capability. Like, I can have a URL that's programmatically controlled. By a web application itself, boom. Like the web can build the web. The primitive is there. Everyone at the time, like we talked to people that like worked on, you know Chrome and V8 and they were like, uhhhh.Eric: You know, like I don't know. But it's one of those things you just kind of have to go do it to find out. So we spent a couple of years, you know, working on it and yeah. And, and, and got to work in back in 2021 is when we kind of put the first like data of web container online. Butswyx: in partnership with Google, right?swyx: Like Google actually had to help you get over the finish line with stuff.Eric: A hundred percent, because well, you know, over the years of when we were doing the R and D on the thing. Kind of the biggest challenge, the two ways that you can kind of test how powerful and capable a platform are, the two types of applications are one, video games, right, because they're just very compute intensive, a lot of calculations that have to happen, right?Eric: The second one are IDEs, because you're talking about actually virtualizing the actual [00:23:00] runtime environment you are in to actually build apps on top of it, which requires sophisticated capabilities, a lot of access to data. You know, a good amount of compute power, right, to effectively, you know, building app in app sort of thing.Eric: So those, those are the stress tests. So if your platform is missing stuff, those are the things where you find out. Those are, those are the people building games and IDEs. They're the ones filing bugs on operating system level stuff. And for us, browser level stuff.Eric [00:23:47]: yeah, what ended up happening is we were just hammering, you know, the Chromium bug tracker, and they're like, who are these guys? Yeah. And, and they were amazing because I mean, just making Chrome DevTools be able to debug, I mean, it's, it's not, it wasn't originally built right for debugging an operating system, right? They've been phenomenal working with us and just kind of really pushing the limits, but that it's a rising tide that's kind of lifted all boats because now there's a lot of different types of applications that you can debug with Chrome Dev Tools that are running a browser that runs more reliably because just the stress testing that, that we and, you know, games that are coming to the web are kind of pushing as well, but.Itamar [00:24:23]: That's awesome. About the testing, I think like most, let's say coding assistant from different kinds will need this loop of testing. And even I would add code review to some, to some extent that you mentioned. How is testing different from code review? Code review could be, for example, PR review, like a code review that is done at the point of when you want to merge branches. But I would say that code review, for example, checks best practices, maintainability, and so on. It's not just like CI, but more than CI. And testing is like a more like checking functionality, et cetera. So it's different. We call, by the way, all of these together code integrity, but that's a different story. Just to go back to the, to the testing and specifically. Yeah. It's, it's, it's since the first slide. Yeah. We're consistent. So if we go back to the testing, I think like, it's not surprising that for us testing is important and for Bolt it's testing important, but I want to shed some light on a different perspective of it. Like let's think about autonomous driving. Those startups that are doing autonomous driving for highway and autonomous driving for the city. And I think like we saw the autonomous of the highway much faster and reaching to a level, I don't know, four or so much faster than those in the city. Now, in both cases, you need testing and quote unquote testing, you know, verifying validation that you're doing the right thing on the road and you're reading and et cetera. But it's probably like so different in the city that it could be like actually different technology. And I claim that we're seeing something similar here. So when you're building the next Wix, and if I was them, I was like looking at you and being a bit scared. That's what you're disrupting, what you just said. Then basically, I would say that, for example, the UX UI is freaking important. And because you're you're more aiming for the end user. In this case, maybe it's an end user that doesn't know how to develop for developers. It's also important. But let alone those that do not know to develop, they need a slick UI UX. And I think like that's one reason, for example, I think Cursor have like really good technology. I don't know the underlying what's under the hood, but at least what they're saying. But I think also their UX UI is great. It's a lot because they did their own ID. While if you're aiming for the city AI, suddenly like there's a lot of testing and code review technology that it's not necessarily like that important. For example, let's talk about integration tests. Probably like a lot of what you're building involved at the moment is isolated applications. Maybe the vision or the end game is maybe like having one solution for everything. It could be that eventually the highway companies will go into the city and the other way around. But at the beginning, there is a difference. And integration tests are a good example. I guess they're a bit less important. And when you think about enterprise software, they're really important. So to recap, like I think like the idea of looping and verifying your test and verifying your code in different ways, testing or code review, et cetera, seems to be important in the highway AI and the city AI, but in different ways and different like critical for the city, even more and more variety. Actually, I was looking to ask you like what kind of loops you guys are doing. For example, when I'm using Bolt and I'm enjoying it a lot, then I do see like sometimes you're trying to catch the errors and fix them. And also, I noticed that you're breaking down tasks into smaller ones and then et cetera, which is already a common notion for a year ago. But it seems like you're doing it really well. So if you're willing to share anything about it.Eric [00:28:07]: Yeah, yeah. I realized I never actually hit the punchline of what I was saying before. I mentioned the point about us kind of writing an operating system from scratch because what ended up being important about that is that to your point, it's actually a very, like compared to like a, you know, if you're like running cursor on anyone's machine, you kind of don't know what you're dealing with, with the OS you're running on. There could be an error happens. It could be like a million different things, right? There could be some config. There could be, it could be God knows what, right? The thing with WebConnect is because we wrote the entire thing from scratch. It's actually a unified image basically. And we can instrument it at any level that we think is going to be useful, which is exactly what we did when we started building Bolt is we instrumented stuff at like the process level, at the runtime level, you know, et cetera, et cetera, et cetera. Stuff that would just be not impossible to do on local, but to do that in a way that works across any operating system, whatever is, I mean, would just be insanely, you know, insanely difficult to do right and reliably. And that's what you saw when you've used Bolt is that when an error actually will occur, whether it's in the build process or the actual web application itself is failing or anything kind of in between, you can actually capture those errors. And today it's a very primitive way of how we've implemented it largely because the product just didn't exist 90 days ago. So we're like, we got some work ahead of us and we got to hire some more a little bit, but basically we present and we say, Hey, this is, here's kind of the things that went wrong. There's a fix it button and then a ignore button, and then you can just hit fix it. And then we take all that telemetry through our agent, you run it through our agent and say, kind of, here's the state of the application. Here's kind of the errors that we got from Node.js or the browser or whatever, and like dah, dah, dah, dah. And it can take a crack at actually solving it. And it's actually pretty darn good at being able to do that. That's kind of been a, you know, closing the loop and having it be a reliable kind of base has seemed to be a pretty big upgrade over doing stuff locally, just because I think that's a pretty key ingredient of it. And yeah, I think breaking things down into smaller tasks, like that's, that's kind of a key part of our agent. I think like Claude did a really good job with artifacts. I think, you know, us and kind of everyone else has, has kind of taken their approach of like actually breaking out certain tasks in a certain order into, you know, kind of a concrete way. And, and so actually the core of Bolt, I know we actually made open source. So you can actually go and check out like the system prompts and et cetera, and you can run it locally and whatever have you. So anyone that's interested in this stuff, I'd highly recommend taking a look at. There's not a lot of like stuff that's like open source in this realm. It's, that was one of the fun things that we've we thought would be cool to do. And people, people seem to like it. I mean, there's a lot of forks and people adding different models and stuff. So it's been cool to see.Swyx [00:30:41]: Yeah. I'm happy to add, I added real-time voice for my opening day demo and it was really fun to hack with. So thank you for doing that. Yeah. Thank you. I'm going to steal your code.Eric [00:30:52]: Because I want that.Swyx [00:30:52]: It's funny because I built on top of the fork of Bolt.new that already has the multi LLM thing. And so you just told me you're going to merge that in. So then you're going to merge two layers of forks down into this thing. So it'll be fun.Eric [00:31:03]: Heck yeah.Alessio [00:31:04]: Just to touch on like the environment, Itamar, you maybe go into the most complicated environments that even the people that work there don't know how to run. How much of an impact does that have on your performance? Like, you know, it's most of the work you're doing actually figuring out environment and like the libraries, because I'm sure they're using outdated version of languages, they're using outdated libraries, they're using forks that have not been on the public internet before. How much of the work that you're doing is like there versus like at the LLM level?Itamar [00:31:32]: One of the reasons I was asking about, you know, what are the steps to break things down, because it really matters. Like, what's the tech stack? How complicated the software is? It's hard to figure it out when you're dealing with the real world, any environment of enterprise as a city, when I'm like, while maybe sometimes like, I think you do enable like in Bolt, like to install stuff, but it's quite a like controlled environment. And that's a good thing to do, because then you narrow down and it's easier to make things work. So definitely, there are two dimensions, I think, actually spaces. One is the fact just like installing our software without yet like doing anything, making it work, just installing it because we work with enterprise and Fortune 500, etc. Many of them want on prem solution.Swyx [00:32:22]: So you have how many deployment options?Itamar [00:32:24]: Basically, we had, we did a metric metrics, say 96 options, because, you know, they're different dimensions. Like, for example, one dimension, we connect to your code management system to your Git. So are you having like GitHub, GitLab? Subversion? Is it like on cloud or deployed on prem? Just an example. Which model agree to use its APIs or ours? Like we have our Is it TestGPT? Yeah, when we started with TestGPT, it was a huge mistake name. It was cool back then, but I don't think it's a good idea to name a model after someone else's model. Anyway, that's my opinion. So we gotSwyx [00:33:02]: I'm interested in these learnings, like things that you change your mind on.Itamar [00:33:06]: Eventually, when you're building a company, you're building a brand and you want to create your own brand. By the way, when I thought about Bolt.new, I also thought about if it's not a problem, because when I think about Bolt, I do think about like a couple of companies that are already called this way.Swyx [00:33:19]: Curse companies. You could call it Codium just to...Itamar [00:33:24]: Okay, thank you. Touche. Touche.Eric [00:33:27]: Yeah, you got to imagine the board meeting before we launched Bolt, one of our investors, you can imagine they're like, are you sure? Because from the investment side, it's kind of a famous, very notorious Bolt. And they're like, are you sure you want to go with that name? Oh, yeah. Yeah, absolutely.Itamar [00:33:43]: At this point, we have actually four models. There is a model for autocomplete. There's a model for the chat. There is a model dedicated for more for code review. And there is a model that is for code embedding. Actually, you might notice that there isn't a good code embedding model out there. Can you name one? Like dedicated for code?Swyx [00:34:04]: There's code indexing, and then you can do sort of like the hide for code. And then you can embed the descriptions of the code.Itamar [00:34:12]: Yeah, but you do see a lot of type of models that are dedicated for embedding and for different spaces, different fields, etc. And I'm not aware. And I know that if you go to the bedrock, try to find like there's a few code embedding models, but none of them are specialized for code.Swyx [00:34:31]: Is there a benchmark that you would tell us to pay attention to?Itamar [00:34:34]: Yeah, so it's coming. Wait for that. Anyway, we have our models. And just to go back to the 96 option of deployment. So I'm closing the brackets for us. So one is like dimensional, like what Git deployment you have, like what models do you agree to use? Dotter could be like if it's air-gapped completely, or you want VPC, and then you have Azure, GCP, and AWS, which is different. Do you use Kubernetes or do not? Because we want to exploit that. There are companies that do not do that, etc. I guess you know what I mean. So that's one thing. And considering that we are dealing with one of all four enterprises, we needed to deal with that. So you asked me about how complicated it is to solve that complex code. I said, it's just a deployment part. And then now to the software, we see a lot of different challenges. For example, some companies, they did actually a good job to build a lot of microservices. Let's not get to if it's good or not, but let's first assume that it is a good thing. A lot of microservices, each one of them has their own repo. And now you have tens of thousands of repos. And you as a developer want to develop something. And I remember me coming to a corporate for the first time. I don't know where to look at, like where to find things. So just doing a good indexing for that is like a challenge. And moreover, the regular indexing, the one that you can find, we wrote a few blogs on that. By the way, we also have some open source, different than yours, but actually three and growing. Then it doesn't work. You need to let the tech leads and the companies influence your indexing. For example, Mark with different repos with different colors. This is a high quality repo. This is a lower quality repo. This is a repo that we want to deprecate. This is a repo we want to grow, etc. And let that be part of your indexing. And only then things actually work for enterprise and they don't get to a fatigue of, oh, this is awesome. Oh, but I'm starting, it's annoying me. I think Copilot is an amazing tool, but I'm quoting others, meaning GitHub Copilot, that they see not so good retention of GitHub Copilot and enterprise. Ooh, spicy. Yeah. I saw snapshots of people and we have customers that are Copilot users as well. And also I saw research, some of them is public by the way, between 38 to 50% retention for users using Copilot and enterprise. So it's not so good. By the way, I don't think it's that bad, but it's not so good. So I think that's a reason because, yeah, it helps you auto-complete, but then, and especially if you're working on your repo alone, but if it's need that context of remote repos that you're code-based, that's hard. So to make things work, there's a lot of work on that, like giving the controllability for the tech leads, for the developer platform or developer experience department in the organization to influence how things are working. A short example, because if you have like really old legacy code, probably some of it is not so good anymore. If you just fine tune on these code base, then there is a bias to repeat those mistakes or old practices, etc. So you need, for example, as I mentioned, to influence that. For example, in Coda, you can have a markdown of best practices by the tech leads and Coda will include that and relate to that and will not offer suggestions that are not according to the best practices, just as an example. So that's just a short list of things that you need to do in order to deal with, like you mentioned, the 100.1 to 100.2 version of software. I just want to say what you're doing is extremelyEric [00:38:32]: impressive because it's very difficult. I mean, the business of Stackplus, kind of before bulk came online, we sold a version of our IDE that went on-prem. So I understand what you're saying about the difficulty of getting stuff just working on-prem. Holy heck. I mean, that is extremely hard. I guess the question I have for you is, I mean, we were just doing that with kind of Kubernetes-based stuff, but the spread of Fortune 500 companies that you're working with, how are they doing the inference for this? Are you kind of plugging into Azure's OpenAI stuff and AWS's Bedrock, you know, Cloud stuff? Or are they just like running stuff on GPUs? Like, what is that? How are these folks approaching that? Because, man, what we saw on the enterprise side, I mean, I got to imagine that that's a huge challenge. Everything you said and more, like,Itamar [00:39:15]: for example, like someone could be, and I don't think any of these is bad. Like, they made their decision. Like, for example, some people, they're, I want only AWS and VPC on AWS, no matter what. And then they, some of them, like there is a subset, I will say, I'm willing to take models only for from Bedrock and not ours. And we have a problem because there is no good code embedding model on Bedrock. And that's part of what we're doing now with AWS to solve that. We solve it in a different way. But if you are willing to run on AWS VPC, but run your run models on GPUs or inferentia, like the new version of the more coming out, then our models can run on that. But everything you said is right. Like, we see like on-prem deployment where they have their own GPUs. We see Azure where you're using OpenAI Azure. We see cases where you're running on GCP and they want OpenAI. Like this cross, like a case, although there is Gemini or even Sonnet, I think is available on GCP, just an example. So all the options, that's part of the challenge. I admit that we thought about it, but it was even more complicated. And it took us a few months to actually, that metrics that I mentioned, to start clicking each one of the blocks there. A few months is impressive. I mean,Eric [00:40:35]: honestly, just that's okay. Every one of these enterprises is, their networking is different. Just everything's different. Every single one is different. I see you understand. Yeah. So that just cannot be understated. That it is, that's extremely impressive. Hats off.Itamar [00:40:50]: It could be, by the way, like, for example, oh, we're only AWS, but our GitHub enterprise is on-prem. Oh, we forgot. So we need like a private link or whatever, like every time like that. It's not, and you do need to think about it if you want to work with an enterprise. And it's important. Like I understand like their, I respect their point of view.Swyx [00:41:10]: And this primarily impacts your architecture, your tech choices. Like you have to, you can't choose some vendors because...Itamar [00:41:15]: Yeah, definitely. To be frank, it makes us hard for a startup because it means that we want, we want everyone to enjoy all the variety of models. By the way, it was hard for us with our technology. I want to open a bracket, like a window. I guess you're familiar with our Alpha Codium, which is an open source.Eric [00:41:33]: We got to go over that. Yeah. So I'll do that quickly.Itamar [00:41:36]: Yeah. A pin in that. Yeah. Actually, we didn't have it in the last episode. So, so, okay.Swyx [00:41:41]: Okay. We'll come back to that later, but let's talk about...Itamar [00:41:43]: Yeah. So, so just like shortly, and then we can double click on Alpha Codium. But Alpha Codium is a open source tool. You can go and try it and lets you compete on CodeForce. This is a website and a competition and actually reach a master level level, like 95% with a click of a button. You don't need to do anything. And part of what we did there is taking a problem and breaking it to different, like smaller blocks. And then the models are doing a much better job. Like we all know it by now that taking small tasks and solving them, by the way, even O1, which is supposed to be able to do system two thinking like Greg from OpenAI like hinted, is doing better on these kinds of problems. But still, it's very useful to break it down for O1, despite O1 being able to think by itself. And that's what we presented like just a month ago, OpenAI released that now they are doing 93 percentile with O1 IOI left and International Olympiad of Formation. Sorry, I forgot. Exactly. I told you I forgot. And we took their O1 preview with Alpha Codium and did better. Like it just shows like, and there is a big difference between the preview and the IOI. It shows like that these models are not still system two thinkers, and there is a big difference. So maybe they're not complete system two. Yeah, they need some guidance. I call them system 1.5. We can, we can have it. I thought about it. Like, you know, I care about this philosophy stuff. And I think like we didn't see it even close to a system two thinking. I can elaborate later. But closing the brackets, like we take Alpha Codium and as our principle of thinking, we take tasks and break them down to smaller tasks. And then we want to exploit the best model to solve them. So I want to enable anyone to enjoy O1 and SONET and Gemini 1.5, etc. But at the same time, I need to develop my own models as well, because some of the Fortune 500 want to have all air gapped or whatever. So that's a challenge. Now you need to support so many models. And to some extent, I would say that the flow engineering, the breaking down to two different blocks is a necessity for us. Why? Because when you take a big block, a big problem, you need a very different prompt for each one of the models to actually work. But when you take a big problem and break it into small tasks, we can talk how we do that, then the prompt matters less. What I want to say, like all this, like as a startup trying to do different deployment, getting all the juice that you can get from models, etc. is a big problem. And one need to think about it. And one of our mitigation is that process of taking tasks and breaking them down. That's why I'm really interested to know how you guys are doing it. And part of what we do is also open source. So you can see.Swyx [00:44:39]: There's a lot in there. But yeah, flow over prompt. I do believe that that does make sense. I feel like there's a lot that both of you can sort of exchange notes on breaking down problems. And I just want you guys to just go for it. This is fun to watch.Eric [00:44:55]: Yeah. I mean, what's super interesting is the context you're working in is, because for us too with Bolt, we've started thinking because our kind of existing business line was going behind the firewall, right? We were like, how do we do this? Adding the inference aspect on, we're like, okay, how does... Because I mean, there's not a lot of prior art, right? I mean, this is all new. This is all new. So I definitely am going to have a lot of questions for you.Itamar [00:45:17]: I'm here. We're very open, by the way. We have a paper on a blog or like whatever.Swyx [00:45:22]: The Alphacodeum, GitHub, and we'll put all this in the show notes.Itamar [00:45:25]: Yeah. And even the new results of O1, we published it.Eric [00:45:29]: I love that. And I also just, I think spiritually, I like your approach of being transparent. Because I think there's a lot of hype-ium around AI stuff. And a lot of it is, it's just like, you have these companies that are just kind of keep their stuff closed source and then just max hype it, but then it's kind of nothing. And I think it kind of gives a bad rep to the incredible stuff that's actually happening here. And so I think it's stuff like what you're doing where, I mean, true merit and you're cracking open actual code for others to learn from and use. That strikes me as the right approach. And it's great to hear that you're making such incredible progress.Itamar [00:46:02]: I have something to share about the open source. Most of our tools are, we have an open source version and then a premium pro version. But it's not an easy decision to do that. I actually wanted to ask you about your strategy, but I think in your case, there is, in my opinion, relatively a good strategy where a lot of parts of open source, but then you have the deployment and the environment, which is not right if I get it correctly. And then there's a clear, almost hugging face model. Yeah, you can do that, but why should you try to deploy it yourself, deploy it with us? But in our case, and I'm not sure you're not going to hit also some competitors, and I guess you are. I wanted to ask you, for example, on some of them. In our case, one day we looked on one of our competitors that is doing code review. We're a platform. We have the code review, the testing, et cetera, spread over the ID to get. And in each agent, we have a few startups or a big incumbents that are doing only that. So we noticed one of our competitors having not only a very similar UI of our open source, but actually even our typo. And you sit there and you're kind of like, yeah, we're not that good. We don't use enough Grammarly or whatever. And we had a couple of these and we saw it there. And then it's a challenge. And I want to ask you, Bald is doing so well, and then you open source it. So I think I know what my answer was. I gave it before, but still interestingEric [00:47:29]: to hear what you think. GeoHot said back, I don't know who he was up to at this exact moment, but I think on comma AI, all that stuff's open source. And someone had asked him, why is this open source? And he's like, if you're not actually confident that you can go and crush it and build the best thing, then yeah, you should probably keep your stuff closed source. He said something akin to that. I'm probably kind of butchering it, but I thought it was kind of a really good point. And that's not to say that you should just open source everything, because for obvious reasons, there's kind of strategic things you have to kind of take in mind. But I actually think a pretty liberal approach, as liberal as you kind of can be, it can really make a lot of sense. Because that is so validating that one of your competitors is taking your stuff and they're like, yeah, let's just kind of tweak the styles. I mean, clearly, right? I think it's kind of healthy because it keeps, I'm sure back at HQ that day when you saw that, you're like, oh, all right, well, we have to grind even harder to make sure we stay ahead. And so I think it's actually a very useful, motivating thing for the teams. Because you might feel this period of comfort. I think a lot of companies will have this period of comfort where they're not feeling the competition and one day they get disrupted. So kind of putting stuff out there and letting people push it forces you to face reality soon, right? And actually feel that incrementally so you can kind of adjust course. And that's for us, the open source version of Bolt has had a lot of features people have been begging us for, like persisting chat messages and checkpoints and stuff. Within the first week, that stuff was landed in the open source versions. And they're like, why can't you ship this? It's in the open, so people have forked it. And we're like, we're trying to keep our servers and GPUs online. But it's been great because the folks in the community did a great job, kept us on our toes. And we've got to know most of these folks too at this point that have been building these things. And so it actually was very instructive. Like, okay, well, if we're going to go kind of land this, there's some UX patterns we can kind of look at and the code is open source to this stuff. What's great about these, what's not. So anyways, NetNet, I think it's awesome. I think from a competitive point of view for us, I think in particular, what's interesting is the core technology of WebContainer going. And I think that right now, there's really nothing that's kind of on par with that. And we also, we have a business of, because WebContainer runs in your browser, but to make it work, you have to install stuff from NPM. You have to make cores bypass requests, like connected databases, which all require server-side proxying or acceleration. And so we actually sell WebContainer as a service. One of the core reasons we open-sourced kind of the core components of Bolt when we launched was that we think that there's going to be a lot more of these AI, in-your-browser AI co-gen experiences, kind of like what Anthropic did with Artifacts and Clod. By the way, Artifacts uses WebContainers. Not yet. No, yeah. Should I strike that? I think that they've got their own thing at the moment, but there's been a lot of interest in WebContainers from folks doing things in that sort of realm and in the AI labs and startups and everything in between. So I think there'll be, I imagine, over the coming months, there'll be lots of things being announced to folks kind of adopting it. But yeah, I think effectively...Swyx [00:50:35]: Okay, I'll say this. If you're a large model lab and you want to build sandbox environments inside of your chat app, you should call Eric.Itamar [00:50:43]: But wait, wait, wait, wait, wait, wait. I have a question about that. I think OpenAI, they felt that people are not using their model as they would want to. So they built ChatGPT. But I would say that ChatGPT now defines OpenAI. I know they're doing a lot of business from their APIs, but still, is this how you think? Isn't Bolt.new your business now? Why don't you focus on that instead of the...Swyx [00:51:16]: What's your advice as a founder?Eric [00:51:18]: You're right. And so going into it, we, candidly, we were like, Bolt.new, this thing is super cool. We think people are stoked. We think people will be stoked. But we were like, maybe that's allowed. Best case scenario, after month one, we'd be mind blown if we added a couple hundred K of error or something. And we were like, but we think there's probably going to be an immediate huge business. Because there was some early poll on folks wanting to put WebContainer into their product offerings, kind of similar to what Bolt is doing or whatever. We were actually prepared for the inverse outcome here. But I mean, well, I guess we've seen poll on both. But I mean, what's happened with Bolt, and you're right, it's actually the same strategy as like OpenAI or Anthropic, where we have our ChatGPT to OpenAI's APIs is Bolt to WebContainer. And so we've kind of taken that same approach. And we're seeing, I guess, some of the similar results, except right now, the revenue side is extremely lopsided to Bolt.Itamar [00:52:16]: I think if you ask me what's my advice, I think you have three options. One is to focus on Bolt. The other is to focus on the WebContainer. The third is to raise one billion dollars and do them both. I'm serious. I think otherwise, you need to choose. And if you raise enough money, and I think it's big bucks, because you're going to be chased by competitors. And I think it will be challenging to do both. And maybe you can. I don't know. We do see these numbers right now, raising above $100 million, even without havingEric [00:52:49]: a product. You can see these. It's excellent advice. And I think what's been amazing, but also kind of challenging is we're trying to forecast, okay, well, where are these things going? I mean, in the initial weeks, I think us and all the investors in the company that we're sharing this with, it was like, this is cool. Okay, we added 500k. Wow, that's crazy. Wow, we're at a million now. Most things, you have this kind of the tech crunch launch of initiation and then the thing of sorrow. And if there's going to be a downtrend, it's just not coming yet. Now that we're kind of looking ahead, we're six weeks in. So now we're getting enough confidence in our convictions to go, okay, this se

Hey everyone, Happy Halloween! Alex here, coming to you live from my mad scientist lair! For the first ever, live video stream of ThursdAI, I dressed up as a mad scientist and had my co-host, Fester the AI powered Skeleton join me (as well as my usual cohosts haha) in a very energetic and hopefully entertaining video stream! Since it's Halloween today, Fester (and I) have a very busy schedule, so no super length ThursdAI news-letter today, as we're still not in the realm of Gemini being able to write a decent draft that takes everything we talked about and cover all the breaking news, I'm afraid I will have to wish you a Happy Halloween and ask that you watch/listen to the episode. The TL;DR and show links from today, don't cover all the breaking news but the major things we saw today (and caught live on the show as Breaking News) were, ChatGPT now has search, Gemini has grounded search as well (seems like the release something before Google announces it streak from OpenAI continues). Here's a quick trailer of the major things that happened: This weeks buzz - Halloween AI toy with WeaveIn this weeks buzz, my long awaited Halloween project is finally live and operational! I've posted a public Weave dashboard here and the code (that you can run on your mac!) hereReally looking forward to see all the amazing costumers the kiddos come up with and how Gemini will be able to respond to them, follow along! ThursdAI - Recaps of the most high signal AI weekly spaces is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.Ok and finally my raw TL;DR notes and links for this week. Happy halloween everyone, I'm running off to spook the kiddos (and of course record and post about it!)ThursdAI - Oct 31 - TL;DRTL;DR of all topics covered:* Open Source LLMs:* Microsoft's OmniParser: SOTA UI parsing (MIT Licensed)

In this episode, Amir Bormand engages with Dana Lawson, the CTO at Netlify, to discuss the multifaceted journey from a VP position to becoming a CTO. The conversation delves into the essential skills required, the significance of mentorship, and the societal pressures of career progression. Dana addresses the evolving job market and organizational demands due to the pandemic while emphasizing that the role of a CTO is not the sole benchmark of success. She highlights the crucial balance between technical expertise and strategic decision-making, the importance of empathy in leadership, and fostering collaboration across departments. The discussion also covers continuous learning, the value of networking and mentorship, and maintaining vulnerability in leadership. Dana concludes by offering advice to aspiring leaders and sharing how to connect with her for further career guidance. Highlights: 00:09 Understanding the CTO Role 00:35 Netlify's Mission and Dana's Journey 01:08 The Value of Different Leadership Levels 03:27 Challenges and Perceptions in Career Progression 08:18 Skills Crucial for a CTO 11:56 Transitioning from Technologist to CTO 12:57 Balancing Act: Staying Informed Without Micromanaging 14:39 The Weight of Decision-Making at the CTO Level 15:50 Seeking Support: Mentors and Networks 18:55 The Importance of Vulnerability in Leadership 19:52 Advice for Aspiring CTOs Guest: Dana Lawson is the Chief Technology Officer (CTO) at Netlify, where she leads the company's technical strategy and innovation efforts. With over two decades of experience in engineering and leadership roles, Dana has a proven track record of building and scaling high-performing teams across various industries. She is passionate about fostering collaborative, inclusive work environments and driving impactful technological solutions. Throughout her career, Dana has been a strong advocate for mentorship, continuous learning, and diversity in tech. Her expertise spans both technical and strategic decision-making, making her a respected leader in the tech community. LinkedIn: https://www.linkedin.com/in/dglawson ---- Thank you so much for checking out this episode of The Tech Trek. We would appreciate it if you would take a minute to rate and review us on your favorite podcast player. Want to learn more about us? Head over at https://www.elevano.com Have questions or want to cover specific topics with our future guests? Please message me at https://www.linkedin.com/in/amirbormand (Amir Bormand)

Over the past ten years, Chris Bach has been at the forefront of the transformation of web development.  Chris coined the term "Jamstack," which refers to one of the first conceptions of a composable web architecture (the acronym JAM accounts for the JavaScript, APIs, and markdown that make up a simple decoupled web system). He also founded Netlify, a company that supports these new architectures and which now serves tens of millions of customers. https://ellessmedia.com/csi/chris-bach/

In this episode Andrew tries to pick a CMS for the new MetaMonster website and talks about his dream solution. Then the guys talk about their ideal consulting businesses. Meanwhile Sean is feeling frustrated by how slow his projects are moving, and wishes he could focus on them fulltime for a bit. They also touch on the difficulties of balancing attention to design details versus just getting a product out the door quickly. Finally, Sean shares 3 businesses he loves. Links:Andrew's Twitter: @AndrewAskinsAndrew's website: https://www.andrewaskins.com/MetaMonster: https://metamonster.ai/ChartJuice: https://www.chartjuice.com/Sean's Twitter: @seanqsunMiscreants: http://miscreants.com/StackWise: Coming soon...FigTree: Coming soon...For more information about the podcast, check out https://www.smalleffortspod.com/.Transcript:00:00:00.01SeanUh, yeah, I mean, I was going to talk about, well, I should have your record.00:00:05.81AndrewDo you want to start over?00:00:07.50SeanNo, it just let's just roll with it. Hi, everyone.00:00:10.80AndrewHi, how's it going? Behind the scenes look at Andrew and Sean being a bit of a clusterfuck trying to figure out what the hell the pod about 30 seconds before the pod or five seconds after the pod.00:00:12.65SeanGood.00:00:20.21SeanWe're very organized or we're incredibly organized. think, I think it's a good segue into, into like, we can talk about like other service business and I have a segue into it because I was kind of curious about just how your consulting is sort of going now that.00:00:34.65AndrewOkay.00:00:35.35SeanYeah. but more importantly, some crazy, crazy, crazy tech Twitter stuff going on these days, huh?00:00:42.87AndrewOh, so when i when I said I wanted to talk about CMSs, yeah the WordPress drama, I feel like we covered a little bit last time.00:00:42.94SeanSince the last.00:00:49.11SeanYeah.00:00:49.88AndrewThere's more updates. it's It keeps getting wackier.00:00:53.21SeanMm hmm.00:00:53.72AndrewThe WordPress founder took over a plugin, which is batshit crazy.00:00:59.63SeanYeah, I was just going to go from crazy batshit WordPress things into maybe Ghost and then CMS's house imagining.00:01:08.50AndrewUh, sorry, I totally fucked your, your segue there.00:01:09.97SeanNo.00:01:13.12Andrewyeah, anyway, I need to build a website and I'm trying to pick a CMS and I want you to, to I want you to tell me which CMS to use and I'm gonna, I'm gonna like ignore you and tell you why you're wrong on every CMS.00:01:22.11Seansquarepace Okay.00:01:26.46AndrewLike, because they all suck.00:01:26.71SeanOkay. Hit me. Hit me. They do all suck, but hit me.00:01:31.00AndrewOkay. So I think I have it narrowed down. I wanted to use, so I'm trying to build a proper marketing site for MetaMonster so that I can get a little bit of SEO stuff rolling and then publish some content and just like have a place to do marketing.00:01:51.26Andrewum want to build some free tools, want to do some other things to just start building building the list, our waiting list.00:01:54.30SeanYeah.00:01:59.89AndrewSo need to pick a CMS. would typically just build on Webflow. Like Webflow is so fast. It's what I built chart juice on. It's clunky, it's expensive, it has its problems. The CMS sucks if you're doing a lot of content, but for like early stage SaaS website, I don't know many things better. So would typically just do Webflow. But I know one of the marketing channels I wanna try is building00:02:32.68Andrewsome free tools to try to drive, get like SEO juice from, from free tools and like some traffic. it just aligns perfectly with MetaMonster, you know, having a free like, enter a link or copy and paste your content in and we'll generate a page title for you. We'll generate a meta description for you. Like it just makes too much sense. Um, and sorry, one second. Let me let my cat in.00:02:57.67Seangot00:02:58.58AndrewCome on in you dork.00:03:01.38AndrewOkay. So yeah, I want to build free tools and like.00:03:03.43SeanYou want to build free tools. It's great. It isn't a monster.00:03:08.40AndrewThe process of doing that in Webflow is just clunky. I could yeah know i could build them, host them on some free thing like Netlify, and then just like run them on a subdomain.00:03:19.66AndrewBut you know if the whole point is SEO, then running it on a subdomain is a little counterproductive. you know It's not the worst thing in the world, I guess, but you're just like, do they now?00:03:28.86Seandoes it you I thought subdomains count as the main domains. like Yeah, I thought that was the whole thing.00:03:38.16AndrewI feel, oh, okay, I need to look into that. Cause that would massively simplify my my problems.00:03:44.34Seanright00:03:46.07AndrewI always thought like best practice was to do everything on your primary domain and that like subdomains got treated differently.00:03:52.10SeanI thought that00:03:56.09AndrewYou're looking it up.00:03:57.51SeanYeah, I'm looking it up. I feel like it was something.00:04:01.40AndrewThere was a Google update, like in this, one of these new big updates, they they started00:04:02.81SeanYeah.00:04:06.13SeanYeah.00:04:07.62AndrewMashing it all together.00:04:08.89SeanYeah. I mean, Ahrefs literally pulls shop.mistreins.com and mistreins.com into one thing now for me.00:04:16.03AndrewInteresting.00:04:16.97SeanSo. I don't know. Yea...

On this Screaming in the Cloud replay, we're looking back to our conversation with Cassidy Williams, a Senior Director of Developer Advocacy at GitHub and the co-founder and chief product officer of Cosynd, Inc. Prior to these positions, she worked as the principal developer experience engineer at Netlify, an instructor and senior engineer at React Training, director of outreach at cKeys, a senior software engineer at CodePen, head of developer voice programs at Amazon, and a software engineer at Venmo, among other positions. Join Corey and Cassidy as they reflect on what Netlify is and what a developer experience engineer does, how JavaScript started off as a toy language and why everything that can be built with JavaScript will be moving forward, the benefits of using low-code development tools, how discovering TikTok helped Cassidy drum up a major following on social media, how Cassidy's humor is never directed at people or organizations and why that's the case, the differences between recording a podcast and live streaming on Twitch from the speaker's point of view, and more.Show Highlights(0:00) Intro(0:22) Backblaze sponsor read(0:49) What is Netlify and its role of a principal developer experience engineer(2:50) Is JavaScript the future?(7:46) Using low-code tools for web development(12:12) Having a goofy internet presence in a serious field(17:23) Social platforms as a means to teach(24:50) Twitch streaming and its inherent challenges(28:16) Cassidy's online coursework and how she answers, “So, what do you do?”(32:12) Unique ways of tracking Twitter followers(37:15) Where you can find more from CassidyAbout Cassidy WilliamsCassidy is a Senior Director of Developer Advocacy at GitHub. She's worked for several other places, including Netlify, CodePen, Amazon, and Venmo, and she's had the honor of working with various non-profits, including cKeys and Hacker Fund as their Director of Outreach. She's active in the developer community, and was one of Glamour Magazine's 35 Women Under 35 Changing the Tech Industry and LinkedIn's Top Professionals 35 & Under. As an avid speaker, Cassidy has participated in several events including the Grace Hopper Celebration for Women in Computing, TEDx, the United Nations, and dozens of other technical events. She wants to inspire generations of STEM students to be the best they can be, and her favorite quote is from Helen Keller: "One can never consent to creep when one feels an impulse to soar." She loves mechanical keyboards and karaoke.LinksTikTok: https://www.tiktok.com/@cassidooNewsletter: https://cassidoo.co/newsletter/Scrimba: https://scrimba.com/teachers/cassidooUdemy: https://www.udemy.com/user/cassidywilliams/Skillshare: https://www.skillshare.com/user/cassidooO'Reilly: https://www.oreilly.com/pub/au/6339Personal website: https://cassidoo.coTwitter: https://twitter.com/cassidooGitHub: https://github.com/cassidooCodePen: https://codepen.io/cassidoo/LinkedIn: https://www.linkedin.com/in/cassidooOriginal Episodehttps://www.lastweekinaws.com/podcast/screaming-in-the-cloud/memes-streams-software-with-cassidy-williams/SponsorBackblaze: https://www.backblaze.com/ 

Shawn Wang (aka swyx) is the founder of smol.ai (AI news curation), and the cohost of Latent Space (popular AI Engineer podcast). Plus, Shawn started the AI Engineer movement with his essay Rise of the AI Engineer and organized two incredible AI engineer conferences in the past twelve months - AI Engineer World's Fair and AI Engineer SummitAnd Shawn has angel invested in DevTools like Airbyte, Railway, Supabase, Replay.io, Stackblitz, Flutterflow, Fireworks.ai while running the DevTools angels community. Besides this, Shawn curates DX.tips (DevTools magazine) and in a past life wrote the Coding Career handbook, championed learn in public, cofounded Svelte Society and was previously Head of Developer Experience at Temporal, and a Developer Advocate at AWS and Netlify.Also, before this, Shawn had a very successful career in investment banking, trading, building data pipelines and performing quantitate portfolio management. I think this brings him a very unique perspective - I've always admired his ability to zoom out and see the big picture and the trends. Even though Shawn is now all-in on AI, he's still one of the go-to authorities on DevTools go-to-market.As you can tell, Shawn is someone I deeply admire. So I'm glad he came back.What we discuss:Organizing the AI Engineer ConferencesRise of the AI EngineerIntentionality and principles (yes we even talk about Alcoholics Anonymous)The AI CEOInvisible deadlinesIlya believing in AGI more than most people at OpenAIAre developers going to be obsolete? Thor convinced swyx to invest in SupabaseBuilding DevTools that work well with LLMsAngel investing in DevTools - why and howIs DevRel dead?How to hire DevRelWhy DX.tips existsLinks:Rise of the AI Engineer https://www.latent.space/p/ai-engineerLatent Space Podcast https://www.latent.space/swyx's Twitter https://x.com/swyxswyx's website https://www.swyx.io/swyx's LinkedIn https://www.linkedin.com/in/shawnswyxwang/smol.ai https://smol.ai/DevTools Angels https://github.com/sw-yx/devtools-angelsDX.tips https://dx.tips/DevRel's Death as Zero Interest Rate Phenomenon https://dx.tips/zirp AI Engineer Summit https://www.ai.engineer/summit/2023AI Engineer World's Fair https://www.ai.engineer/worldsfairCoding Career Handbook https://www.learninpublic.org/Shawn's previous appearance on Scaling DevTools https://podcast.scalingdevtools.com/episodes/swyx Eisenhower Matrix https://asana.com/resources/eisenhower-matrixThor from Supabase https://x.com/thorwebdevSolaris AI coworking space in SF https://www.solarissf.com/Browserbase https://www.browserbase.com/Indent https://indent.com/ and Fouad https://x.com/fouadmatinHow to do hackathons https://dx.tips/hackathonsHow to do conferences https://dx.tips/conf-guideHow to hire DevRel https://dx.tips/mailbox-first-devrel-hiringClimbing the ladder of abstraction with Amelia Wattenberger https://www.youtube.com/watch?v=PAy_GHUAICwCheck out the Enterprise Ready Conf from WorkOS https://enterprise-ready.com/

https://podcast.scalingdevtools.com/episodes/swyx-2Plus, Shawn started the AI Engineer movement with his essay Rise of the AI Engineer and organized two incredible AI engineer conferences in the past twelve months - AI Engineer World's Fair and AI Engineer SummitAnd Shawn has angel invested in DevTools like Airbyte, Railway, Supabase, Replay.io, Stackblitz, Flutterflow, Fireworks.ai while running the DevTools angels community.Besides this, Shawn curates DX.tips (DevTools magazine) and in a past life wrote the Coding Career handbook, championed learn in public, cofounded Svelte Society and was previously Head of Developer Experience at Temporal, and a Developer Advocate at AWS and Netlify.Also, before this, Shawn had a very successful career in investment banking, trading, building data pipelines and performing quantitate portfolio management. I think this brings him a very unique perspective - I've always admired his ability to zoom out and see the big picture and the trends.Even though Shawn is now all-in on AI, he's still one of the go-to authorities on DevTools go-to-market.As you can tell, Shawn is someone I deeply admire. So I'm glad he came back.What we discuss:Organizing the AI Engineer ConferencesRise of the AI EngineerIntentionality and principles (yes we even talk about Alcoholics Anonymous)The AI CEOInvisible deadlinesIlya believing in AGI more than most people at OpenAIAre developers going to be obsolete? Thor convinced swyx to invest in SupabaseBuilding DevTools that work well with LLMsAngel investing in DevTools - why and howIs DevRel dead?How to hire DevRelWhy DX.tips existsLinks:Rise of the AI Engineer https://www.latent.space/p/ai-engineerLatent Space Podcast https://www.latent.space/swyx's Twitter https://x.com/swyxswyx's website https://www.swyx.io/swyx's LinkedIn https://www.linkedin.com/in/shawnswyxwang/smol.ai https://smol.ai/DevTools Angels https://github.com/sw-yx/devtools-angelsDX.tips https://dx.tips/DevRel's Death as Zero Interest Rate Phenomenon https://dx.tips/zirp AI Engineer Summit https://www.ai.engineer/summit/2023AI Engineer World's Fair https://www.ai.engineer/worldsfairCoding Career Handbook https://www.learninpublic.org/Shawn's previous appearance on Scaling DevTools https://podcast.scalingdevtools.com/episodes/swyx Eisenhower Matrix https://asana.com/resources/eisenhower-matrixThor from Supabase https://x.com/thorwebdevSolaris AI coworking space in SF https://www.solarissf.com/Browserbase https://www.browserbase.com/Indent https://indent.com/ and Fouad https://x.com/fouadmatinHow to do hackathons https://dx.tips/hackathonsHow to do conferences https://dx.tips/conf-guideHow to hire DevRel https://dx.tips/mailbox-first-devrel-hiringClimbing the ladder of abstraction with Amelia Wattenberger https://www.youtube.com/watch?v=PAy_GHUAICw...for the job. And they should not be doing that job and they should try something else to do. People pay for it because they need the job title to be filled more than they need that person. Those good people are very hard to reach.That's one thing there. I also mentioned some other things that I've found in the different roles in the category: Bottoms-up and open source have been very challenging in the growing a company success criteria. That's what different roles focus on: bottoms-up and open source, and particularly open source. You don't have to be open source. 

Christian Back is the founder of Netlify, a software platform that allows developers to build highly-performant and dynamic websites, e-commerce stores, and applications. The company has now raised close to $200 million from Bessemer Venture Partners, Andreessen Horowitz, Bond, EQT Ventures, Kleiner Perkins, Mango Capital, and Menlo Ventures.The company boasts more than 5 million developers using the platform, although many are using the free tier. It took the company five years to reach 1 million users and just a year to double that, so things are moving quickly.Where to find Christian Bach:• Website: Scale & Ship Faster with a Composable Web Architecture | Netlify• LinkedIn (8) Christian (Chris) Bach | LinkedInWhere to find Hadi Radwan:• Newsletter: Principles Friday | Hadi Radwan | Substack• LinkedIn: Hadi Radwan | LinkedInIf you like our podcast, please don't forget to subscribe and support us on your favorite podcast players. We also would appreciate your feedback and rating to reach more people.We recently launched our new newsletter, Principles Friday, where I share one principle that can help you in your life or business, one thought-provoking question, and one call to action toward that principle. Please subscribe Here.It is Free and Short (2min).

Guest Brian Douglas Panelist Richard Littauer Show Notes In this episode of Sustain, host Richard Littauer talks with Brian “bdougie” Douglas, founder and CEO of Open Sauced. They discuss the multifaceted aspects of sustaining open source projects, Brian's journey in developer advocacy, and the unique goals of Open Sauced. Brian shares insights from his experiences at GitHub and Netlify, elaborates on concepts like lottery factor and the significance of unique issue authors, and tackles the challenges of maintaining open source sustainability. He also explores the balance of addressing enterprise needs while supporting smaller, less visible projects and emphasizes the importance of education and community engagement in open source. Press download now! [00:01:54] Brian discusses his background at GitHub and Netlify, his role in promoting GraphQL, GitHub Actions, Codespaces, and the inception of Open Sauced. [00:03:08] We hear about the features of Open Sauced's dashboard which enhances GitHub insights, OSSF scorecards, and workspace customizations for managing multiple projects. [00:04:31] Open Sauced's business model is currently founded by VC money and aims to serve large organizations with significant open source dependencies, and Brian talks about the team size and funding history. [00:06:08] Brian elaborates on Open Sauced's long-term sustainability plan, focusing on enterprise-level solutions for open source project observability and contributions. [00:09:31] There's a discussion on how Open Sauced interacts with open source communities and the importance of real-world testing and contributions to open source projects. [00:11:06] Richard highlights the FOSS Funders initiative, encouraging companies to support open source projects financially and through active participation. [00:12:44] Brian shares insights on effective metrics for evaluating open source projects, emphasizing the importance of engaging with unique issue authors rather than focusing solely on superficial metrics like pull requests, and discusses his approach to starting meaningful conversations in the open source community. [00:16:08] Brian explains why he renamed “Lottery Factor” to “Contributor Absence Factor,” and discusses the Pgvector project to illustrate the importance of understanding the “Contributor Absence Factor” and the sustainability concerns when a project relies heavily on a few contributors. [00:18:20] We learn more about how Open Sauced sources its data, including their use of GitHub's events feed and their development of the “Pizza Oven” tool to generate insights from Git repositories. [00:20:21] Richard and Brian discuss the challenges of maintaining an open source ethos when dealing with large companies' internal projects, avoiding becoming merely service providers for large corporate entities. [00:24:14] Brian discusses the long-term implications of open source projects that receive substantial funding or become integrated into larger corporate frameworks. [00:27:27] Richard brings up the difficulty many open source projects face in accessing significant funding and Brian shares his vision for supporting less prominent open source projects drawing analogies from his personal experiences. [00:32:42] Richard questions the “up the chain” analogy, comparing it to a pyramid scheme or academia's tenure track. Brian acknowledges the need to support contributors at all levels, not just those at the top, and he introduces the concept of a S Bomb to provide transparency about project dependencies. [00:39:36] Find out where you can follow Brian on the web. Spotlight [00:40:17] Richard's spotlight is Mr. Carreras, an awesome music teacher. [00:40:59] Brian's spotlight is Dawn Foster at the CHAOSS Project and the CHAOSS Practitioner Guides. Links SustainOSS (https://sustainoss.org/) podcast@sustainoss.org (email) (mailto:podcast@sustainoss.org) richard@theuserismymom.com (email) (mailto:richard@theuserismymom.com) SustainOSS Discourse (https://discourse.sustainoss.org/) SustainOSS Mastodon (https://mastodon.social/tags/sustainoss) Open Collective-SustainOSS (Contribute) (https://opencollective.com/sustainoss) Richard Littauer Socials (https://www.burntfen.com/2023-05-30/socials) Brian Douglas- Open Sauced (https://app.opensauced.pizza/u/bdougie) Brian Douglas Website (https://b.dougie.dev/) Brian Douglas GitHub (https://github.com/bdougie) Brian Douglas X/Twitter (https://github.com/bdougie) The Secret Sauce Open Sauced Podcast (https://podcasts.apple.com/us/podcast/the-secret-sauce/id1644263270) The Secret Sauce Podcast: ‘The Future of Cloud Native and AI with Brendan Burns' (https://podcasts.apple.com/fr/podcast/the-future-of-cloud-native-and-ai-with-brendan-burns/id1644263270?i=1000658092259) Open Sauced (https://opensauced.pizza/) Renaming Bus Factor #632 (CHAOSS community) (https://github.com/chaoss/community/issues/632#issuecomment-2152929617) FOSS Funders (https://fossfunders.com/) Andrew Kane GitHub (https://github.com/ankane) Chad Whitacre Website (https://chadwhitacre.com/) Fair Source (https://fair.io/) CHAOSS (https://chaoss.community/) Your Copilot for Git History (Open Sauced) (https://opensauced.pizza/docs/features/star-search/) Open Sauced GitHub (https://github.com/open-sauced/pizza) InnerSource Commons (https://innersourcecommons.org/) Sustain Podcast-Episode 148: Ali Nehzat of thanks.dev and OSS Funding (https://podcast.sustainoss.org/148) Learning in Public with Kelsey Hightower (Curiefense) (https://www.curiefense.io/blog/learning-in-public-with-kelsey-hightower/) Welcome to Wrexham (https://en.wikipedia.org/wiki/Welcome_to_Wrexham) Sustain Podcast-Episode 159: Dawn Foster & Andrew Nesbitt at State of Open Con 2023 (https://podcast.sustainoss.org/guests/foster) Dr. Dawn Foster Mastodon (https://hachyderm.io/@geekygirldawn) About the CHAOSS Practitioner Guides (https://chaoss.community/about-chaoss-practitioner-guides/) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr Peachtree Sound (https://www.peachtreesound.com/) Special Guest: Brian Douglas.

Join Brian Douglas for this final episode of Jamstack Radio as he chats with Matt Biilmann, CEO of Netlify. Together they discuss the evolution of the Jamstack over the past eight years and its impact on the development landscape. Matt shares insights on the current state of Netlify and the exciting new developments on the horizon. Lastly, they discuss the future of web development, including the role of generative AI and the importance of composable architecture.

Join Brian Douglas for this final episode of Jamstack Radio as he chats with Matt Biilmann, CEO of Netlify. Together they discuss the evolution of the Jamstack over the past eight years and its impact on the development landscape. Matt shares insights on the current state of Netlify and the exciting new developments on the horizon. Lastly, they discuss the future of web development, including the role of generative AI and the importance of composable architecture.

Thank you for 1m downloads of the podcast and 2m readers of the Substack!

Popular web framework Astro is making lots of headlines this week, between new experimental feature Server Islands, and achieving “official deployment partner” status with Netlify, it's been a whirlwind.But in addition to Astro's big news, Expo, arguably the most popular framework for building React Native apps, has been endorsed by the React Native team as the recommended way to build apps.Also, Vitest 2.0, the fastest growing test framework, has introduced a new experimental feature called “Browser Mode”, which allows users to run tests in the browser natively, providing access to browser globals like window and document.Now back to Astro. In 2021, Astro made island architecture a mainstream idea, and Server Islands takes it a step further, making it easy to combine high performance static HTML and dynamic-server generated components.And the Astro announcements kept coming with Netlify being declared Astro's official deployment partner. Netlify's betting on Astro and Server Islands, and will be sponsoring the Astro team with $12,500 each month to keep improving the framework and OSS community. Well done, Astro team!News:Paige - Expo is the recommended way to build React Native appsJack - Astro 4.12 Server Islands and Astro server-islands demo siteTJ - Netlify is Astro's “Official Deployment Partner”Bonus news:https://vitest.dev/guide/browser/What Makes Us Happy this Week:Paige - Grafana dashboardsJack - Public speakingTJ - Mammoth Cave National ParkThanks as always to our sponsor, the Blue Collar Coder channel on YouTube. You can join us in our Discord channel, explore our website and reach us via email, or Tweet us on X @front_end_fire.Front-end Fire websiteBlue Collar Coder on YouTubeBlue Collar Coder on DiscordReach out via emailTweet at us on X @front_end_fire

Today we have Brian Rinaldi from LaunchDarkly on the show. This is the final episode of our in person coverage at the SHIFT Conference in Miami. And although Brian works at LaunchDarkly, we actually didn't talk at all about his employer and instead chatted about Jamstack. Brian has a long history with Jamstack, has written a lot about it. Jamstack was popularized and created by Netlify. And there's been a lot of history of controversy with the term. Some people think of it's merely a branding ploy or a marketing thing, and others find it simply confusing because we have terms like LAMP stack, MEAN stack and MERN stack. So Jamstack automatically gets lumped in with those, but it's not actually a technology stack. It's an architectural pattern. Recently, Jamstack has been giving away to what is known as composable frontends and we picked Brian's brain on this and what this means not only for Jamstack, but also the future web development.

Join guest host Jackson Carpenter as he interviews Dorian Kendal, CMO of Netlify, in this episode of TOP CMO. With over 14 years of marketing experience, Dorian shares insights on leveraging webinars, the role of empathy in marketing, and the impact of "dark social" on building communities. Discover how to effectively reach enterprise companies, market to technical audiences, and utilize composable architecture in your digital strategy. Dorian also discusses the integration of AI in marketing workflows and the importance of understanding your audience's mindset. Tune in for practical advice and real-world experiences that can help you navigate the complexities of modern marketing.

Brian Douglas, a seasoned consultant and educator, comes on the podcast to talk about the intricacies of visualizing open source data in React From his journey starting at Netlify to building 'Open Sauce' and engaging with the developer community at GitHub, Brian shares insights on challenges and innovations in data visualization within the React ecosystem. Links https://briandouglas.me https://twitter.com/bdougieYO https://www.linkedin.com/in/brianldouglas https://b.dougie.dev https://youtube.com/@bdougie We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: bdougie.

Our next 2 big events are AI UX and the World's Fair. Join and apply to speak/sponsor!Due to timing issues we didn't have an interview episode to share with you this week, but not to worry, we have more than enough “weekend special” content in the backlog for you to get your Latent Space fix, whether you like thinking about the big picture, or learning more about the pod behind the scenes, or talking Groq and GPUs, or AI Leadership, or Personal AI. Enjoy!AI BreakdownThe indefatigable NLW had us back on his show for an update on the Four Wars, covering Sora, Suno, and the reshaped GPT-4 Class Landscape:and a longer segment on AI Engineering trends covering the future LLM landscape (Llama 3, GPT-5, Gemini 2, Claude 4), Open Source Models (Mistral, Grok), Apple and Meta's AI strategy, new chips (Groq, MatX) and the general movement from baby AGIs to vertical Agents:Thursday Nights in AIWe're also including swyx's interview with Josh Albrecht and Ali Rohde to reintroduce swyx and Latent Space to a general audience, and engage in some spicy Q&A:Dylan Patel on GroqWe hosted a private event with Dylan Patel of SemiAnalysis (our last pod here):Not all of it could be released so we just talked about our Groq estimates:Milind Naphade - Capital OneIn relation to conversations at NeurIPS and Nvidia GTC and upcoming at World's Fair, we also enjoyed chatting with Milind Naphade about his AI Leadership work at IBM, Cisco, Nvidia, and now leading the AI Foundations org at Capital One. We covered:* Milind's learnings from ~25 years in machine learning * His first paper citation was 24 years ago* Lessons from working with Jensen Huang for 6 years and being CTO of Metropolis * Thoughts on relevant AI research* GTC takeaways and what makes NVIDIA specialIf you'd like to work on building solutions rather than platform (as Milind put it), his Applied AI Research team at Capital One is hiring, which falls under the Capital One Tech team.Personal AI MeetupIt all started with a meme:Within days of each other, BEE, FRIEND, EmilyAI, Compass, Nox and LangFriend were all launching personal AI wearables and assistants. So we decided to put together a the world's first Personal AI meetup featuring creators and enthusiasts of wearables. The full video is live now, with full show notes within.Timestamps* [00:01:13] AI Breakdown Part 1* [00:02:20] Four Wars* [00:13:45] Sora* [00:15:12] Suno* [00:16:34] The GPT-4 Class Landscape* [00:17:03] Data War: Reddit x Google* [00:21:53] Gemini 1.5 vs Claude 3* [00:26:58] AI Breakdown Part 2* [00:27:33] Next Frontiers: Llama 3, GPT-5, Gemini 2, Claude 4* [00:31:11] Open Source Models - Mistral, Grok* [00:34:13] Apple MM1* [00:37:33] Meta's $800b AI rebrand* [00:39:20] AI Engineer landscape - from baby AGIs to vertical Agents* [00:47:28] Adept episode - Screen Multimodality* [00:48:54] Top Model Research from January Recap* [00:53:08] AI Wearables* [00:57:26] Groq vs Nvidia month - GPU Chip War* [01:00:31] Disagreements* [01:02:08] Summer 2024 Predictions* [01:04:18] Thursday Nights in AI - swyx* [01:33:34] Dylan Patel - Semianalysis + Latent Space Live Show* [01:34:58] GroqTranscript[00:00:00] swyx: Welcome to the Latent Space Podcast Weekend Edition. This is Charlie, your AI co host. Swyx and Alessio are off for the week, making more great content. We have exciting interviews coming up with Elicit, Chroma, Instructor, and our upcoming series on NSFW, Not Safe for Work AI. In today's episode, we're collating some of Swyx and Alessio's recent appearances, all in one place for you to find.[00:00:32] swyx: In part one, we have our first crossover pod of the year. In our listener survey, several folks asked for more thoughts from our two hosts. In 2023, Swyx and Alessio did crossover interviews with other great podcasts like the AI Breakdown, Practical AI, Cognitive Revolution, Thursday Eye, and Chinatalk, all of which you can find in the Latentspace About page.[00:00:56] swyx: NLW of the AI Breakdown asked us back to do a special on the 4Wars framework and the AI engineer scene. We love AI Breakdown as one of the best examples Daily podcasts to keep up on AI news, so we were especially excited to be back on Watch out and take[00:01:12] NLW: care[00:01:13] AI Breakdown Part 1[00:01:13] NLW: today on the AI breakdown. Part one of my conversation with Alessio and Swix from Latent Space.[00:01:19] NLW: All right, fellas, welcome back to the AI Breakdown. How are you doing? I'm good. Very good. With the last, the last time we did this show, we were like, oh yeah, let's do check ins like monthly about all the things that are going on and then. Of course, six months later, and, you know, the, the, the world has changed in a thousand ways.[00:01:36] NLW: It's just, it's too busy to even, to even think about podcasting sometimes. But I, I'm super excited to, to be chatting with you again. I think there's, there's a lot to, to catch up on, just to tap in, I think in the, you know, in the beginning of 2024. And, and so, you know, we're gonna talk today about just kind of a, a, a broad sense of where things are in some of the key battles in the AI space.[00:01:55] NLW: And then the, you know, one of the big things that I, that I'm really excited to have you guys on here for us to talk about where, sort of what patterns you're seeing and what people are actually trying to build, you know, where, where developers are spending their, their time and energy and, and, and any sort of, you know, trend trends there, but maybe let's start I guess by checking in on a framework that you guys actually introduced, which I've loved and I've cribbed a couple of times now, which is this sort of four wars of the, of the AI stack.[00:02:20] Four Wars[00:02:20] NLW: Because first, since I have you here, I'd love, I'd love to hear sort of like where that started gelling. And then and then maybe we can get into, I think a couple of them that are you know, particularly interesting, you know, in the, in light of[00:02:30] swyx: some recent news. Yeah, so maybe I'll take this one. So the four wars is a framework that I came up around trying to recap all of 2023.[00:02:38] swyx: I tried to write sort of monthly recap pieces. And I was trying to figure out like what makes one piece of news last longer than another or more significant than another. And I think it's basically always around battlegrounds. Wars are fought around limited resources. And I think probably the, you know, the most limited resource is talent, but the talent expresses itself in a number of areas.[00:03:01] swyx: And so I kind of focus on those, those areas at first. So the four wars that we cover are the data wars, the GPU rich, poor war, the multi modal war, And the RAG and Ops War. And I think you actually did a dedicated episode to that, so thanks for covering that. Yeah, yeah.[00:03:18] NLW: Not only did I do a dedicated episode, I actually used that.[00:03:22] NLW: I can't remember if I told you guys. I did give you big shoutouts. But I used it as a framework for a presentation at Intel's big AI event that they hold each year, where they have all their folks who are working on AI internally. And it totally resonated. That's amazing. Yeah, so, so, what got me thinking about it again is specifically this inflection news that we recently had, this sort of, you know, basically, I can't imagine that anyone who's listening wouldn't have thought about it, but, you know, inflection is a one of the big contenders, right?[00:03:53] NLW: I think probably most folks would have put them, you know, just a half step behind the anthropics and open AIs of the world in terms of labs, but it's a company that raised 1. 3 billion last year, less than a year ago. Reed Hoffman's a co founder Mustafa Suleyman, who's a co founder of DeepMind, you know, so it's like, this is not a a small startup, let's say, at least in terms of perception.[00:04:13] NLW: And then we get the news that basically most of the team, it appears, is heading over to Microsoft and they're bringing in a new CEO. And you know, I'm interested in, in, in kind of your take on how much that reflects, like hold aside, I guess, you know, all the other things that it might be about, how much it reflects this sort of the, the stark.[00:04:32] NLW: Brutal reality of competing in the frontier model space right now. And, you know, just the access to compute.[00:04:38] Alessio: There are a lot of things to say. So first of all, there's always somebody who's more GPU rich than you. So inflection is GPU rich by startup standard. I think about 22, 000 H100s, but obviously that pales compared to the, to Microsoft.[00:04:55] Alessio: The other thing is that this is probably good news, maybe for the startups. It's like being GPU rich, it's not enough. You know, like I think they were building something pretty interesting in, in pi of their own model of their own kind of experience. But at the end of the day, you're the interface that people consume as end users.[00:05:13] Alessio: It's really similar to a lot of the others. So and we'll tell, talk about GPT four and cloud tree and all this stuff. GPU poor, doing something. That the GPU rich are not interested in, you know we just had our AI center of excellence at Decibel and one of the AI leads at one of the big companies was like, Oh, we just saved 10 million and we use these models to do a translation, you know, and that's it.[00:05:39] Alessio: It's not, it's not a GI, it's just translation. So I think like the inflection part is maybe. A calling and a waking to a lot of startups then say, Hey, you know, trying to get as much capital as possible, try and get as many GPUs as possible. Good. But at the end of the day, it doesn't build a business, you know, and maybe what inflection I don't, I don't, again, I don't know the reasons behind the inflection choice, but if you say, I don't want to build my own company that has 1.[00:06:05] Alessio: 3 billion and I want to go do it at Microsoft, it's probably not a resources problem. It's more of strategic decisions that you're making as a company. So yeah, that was kind of my. I take on it.[00:06:15] swyx: Yeah, and I guess on my end, two things actually happened yesterday. It was a little bit quieter news, but Stability AI had some pretty major departures as well.[00:06:25] swyx: And you may not be considering it, but Stability is actually also a GPU rich company in the sense that they were the first new startup in this AI wave to brag about how many GPUs that they have. And you should join them. And you know, Imadis is definitely a GPU trader in some sense from his hedge fund days.[00:06:43] swyx: So Robin Rhombach and like the most of the Stable Diffusion 3 people left Stability yesterday as well. So yesterday was kind of like a big news day for the GPU rich companies, both Inflection and Stability having sort of wind taken out of their sails. I think, yes, it's a data point in the favor of Like, just because you have the GPUs doesn't mean you can, you automatically win.[00:07:03] swyx: And I think, you know, kind of I'll echo what Alessio says there. But in general also, like, I wonder if this is like the start of a major consolidation wave, just in terms of, you know, I think that there was a lot of funding last year and, you know, the business models have not been, you know, All of these things worked out very well.[00:07:19] swyx: Even inflection couldn't do it. And so I think maybe that's the start of a small consolidation wave. I don't think that's like a sign of AI winter. I keep looking for AI winter coming. I think this is kind of like a brief cold front. Yeah,[00:07:34] NLW: it's super interesting. So I think a bunch of A bunch of stuff here.[00:07:38] NLW: One is, I think, to both of your points, there, in some ways, there, there had already been this very clear demarcation between these two sides where, like, the GPU pores, to use the terminology, like, just weren't trying to compete on the same level, right? You know, the vast majority of people who have started something over the last year, year and a half, call it, were racing in a different direction.[00:07:59] NLW: They're trying to find some edge somewhere else. They're trying to build something different. If they're, if they're really trying to innovate, it's in different areas. And so it's really just this very small handful of companies that are in this like very, you know, it's like the coheres and jaspers of the world that like this sort of, you know, that are that are just sort of a little bit less resourced than, you know, than the other set that I think that this potentially even applies to, you know, everyone else that could clearly demarcate it into these two, two sides.[00:08:26] NLW: And there's only a small handful kind of sitting uncomfortably in the middle, perhaps. Let's, let's come back to the idea of, of the sort of AI winter or, you know, a cold front or anything like that. So this is something that I, I spent a lot of time kind of thinking about and noticing. And my perception is that The vast majority of the folks who are trying to call for sort of, you know, a trough of disillusionment or, you know, a shifting of the phase to that are people who either, A, just don't like AI for some other reason there's plenty of that, you know, people who are saying, You Look, they're doing way worse than they ever thought.[00:09:03] NLW: You know, there's a lot of sort of confirmation bias kind of thing going on. Or two, media that just needs a different narrative, right? Because they're sort of sick of, you know, telling the same story. Same thing happened last summer, when every every outlet jumped on the chat GPT at its first down month story to try to really like kind of hammer this idea that that the hype was too much.[00:09:24] NLW: Meanwhile, you have, you know, just ridiculous levels of investment from enterprises, you know, coming in. You have, you know, huge, huge volumes of, you know, individual behavior change happening. But I do think that there's nothing incoherent sort of to your point, Swyx, about that and the consolidation period.[00:09:42] NLW: Like, you know, if you look right now, for example, there are, I don't know, probably 25 or 30 credible, like, build your own chatbot. platforms that, you know, a lot of which have, you know, raised funding. There's no universe in which all of those are successful across, you know, even with a, even, even with a total addressable market of every enterprise in the world, you know, you're just inevitably going to see some amount of consolidation.[00:10:08] NLW: Same with, you know, image generators. There are, if you look at A16Z's top 50 consumer AI apps, just based on, you know, web traffic or whatever, they're still like I don't know, a half. Dozen or 10 or something, like, some ridiculous number of like, basically things like Midjourney or Dolly three. And it just seems impossible that we're gonna have that many, you know, ultimately as, as, as sort of, you know, going, going concerned.[00:10:33] NLW: So, I don't know. I, I, I think that the, there will be inevitable consolidation 'cause you know. It's, it's also what kind of like venture rounds are supposed to do. You're not, not everyone who gets a seed round is supposed to get to series A and not everyone who gets a series A is supposed to get to series B.[00:10:46] NLW: That's sort of the natural process. I think it will be tempting for a lot of people to try to infer from that something about AI not being as sort of big or as as sort of relevant as, as it was hyped up to be. But I, I kind of think that's the wrong conclusion to come to.[00:11:02] Alessio: I I would say the experimentation.[00:11:04] Alessio: Surface is a little smaller for image generation. So if you go back maybe six, nine months, most people will tell you, why would you build a coding assistant when like Copilot and GitHub are just going to win everything because they have the data and they have all the stuff. If you fast forward today, A lot of people use Cursor everybody was excited about the Devin release on Twitter.[00:11:26] Alessio: There are a lot of different ways of attacking the market that are not completion of code in the IDE. And even Cursors, like they evolved beyond single line to like chat, to do multi line edits and, and all that stuff. Image generation, I would say, yeah, as a, just as from what I've seen, like maybe the product innovation has slowed down at the UX level and people are improving the models.[00:11:50] Alessio: So the race is like, how do I make better images? It's not like, how do I make the user interact with the generation process better? And that gets tough, you know? It's hard to like really differentiate yourselves. So yeah, that's kind of how I look at it. And when we think about multimodality, maybe the reason why people got so excited about Sora is like, oh, this is like a completely It's not a better image model.[00:12:13] Alessio: This is like a completely different thing, you know? And I think the creative mind It's always looking for something that impacts the viewer in a different way, you know, like they really want something different versus the developer mind. It's like, Oh, I, I just, I have this like very annoying thing I want better.[00:12:32] Alessio: I have this like very specific use cases that I want to go after. So it's just different. And that's why you see a lot more companies in image generation. But I agree with you that. If you fast forward there, there's not going to be 10 of them, you know, it's probably going to be one or[00:12:46] swyx: two. Yeah, I mean, to me, that's why I call it a war.[00:12:49] swyx: Like, individually, all these companies can make a story that kind of makes sense, but collectively, they cannot all be true. Therefore, they all, there is some kind of fight over limited resources here. Yeah, so[00:12:59] NLW: it's interesting. We wandered very naturally into sort of another one of these wars, which is the multimodality kind of idea, which is, you know, basically a question of whether it's going to be these sort of big everything models that end up winning or whether, you know, you're going to have really specific things, you know, like something, you know, Dolly 3 inside of sort of OpenAI's larger models versus, you know, a mid journey or something like that.[00:13:24] NLW: And at first, you know, I was kind of thinking like, For most of the last, call it six months or whatever, it feels pretty definitively both and in some ways, you know, and that you're, you're seeing just like great innovation on sort of the everything models, but you're also seeing lots and lots happen at sort of the level of kind of individual use cases.[00:13:45] Sora[00:13:45] NLW: But then Sora comes along and just like obliterates what I think anyone thought you know, where we were when it comes to video generation. So how are you guys thinking about this particular battle or war at the moment?[00:13:59] swyx: Yeah, this was definitely a both and story, and Sora tipped things one way for me, in terms of scale being all you need.[00:14:08] swyx: And the benefit, I think, of having multiple models being developed under one roof. I think a lot of people aren't aware that Sora was developed in a similar fashion to Dolly 3. And Dolly3 had a very interesting paper out where they talked about how they sort of bootstrapped their synthetic data based on GPT 4 vision and GPT 4.[00:14:31] swyx: And, and it was just all, like, really interesting, like, if you work on one modality, it enables you to work on other modalities, and all that is more, is, is more interesting. I think it's beneficial if it's all in the same house, whereas the individual startups who don't, who sort of carve out a single modality and work on that, definitely won't have the state of the art stuff on helping them out on synthetic data.[00:14:52] swyx: So I do think like, The balance is tilted a little bit towards the God model companies, which is challenging for the, for the, for the the sort of dedicated modality companies. But everyone's carving out different niches. You know, like we just interviewed Suno ai, the sort of music model company, and, you know, I don't see opening AI pursuing music anytime soon.[00:15:12] Suno[00:15:12] swyx: Yeah,[00:15:13] NLW: Suno's been phenomenal to play with. Suno has done that rare thing where, which I think a number of different AI product categories have done, where people who don't consider themselves particularly interested in doing the thing that the AI enables find themselves doing a lot more of that thing, right?[00:15:29] NLW: Like, it'd be one thing if Just musicians were excited about Suno and using it but what you're seeing is tons of people who just like music all of a sudden like playing around with it and finding themselves kind of down that rabbit hole, which I think is kind of like the highest compliment that you can give one of these startups at the[00:15:45] swyx: early days of it.[00:15:46] swyx: Yeah, I, you know, I, I asked them directly, you know, in the interview about whether they consider themselves mid journey for music. And he had a more sort of nuanced response there, but I think that probably the business model is going to be very similar because he's focused on the B2C element of that. So yeah, I mean, you know, just to, just to tie back to the question about, you know, You know, large multi modality companies versus small dedicated modality companies.[00:16:10] swyx: Yeah, highly recommend people to read the Sora blog posts and then read through to the Dali blog posts because they, they strongly correlated themselves with the same synthetic data bootstrapping methods as Dali. And I think once you make those connections, you're like, oh, like it, it, it is beneficial to have multiple state of the art models in house that all help each other.[00:16:28] swyx: And these, this, that's the one thing that a dedicated modality company cannot do.[00:16:34] The GPT-4 Class Landscape[00:16:34] NLW: So I, I wanna jump, I wanna kind of build off that and, and move into the sort of like updated GPT-4 class landscape. 'cause that's obviously been another big change over the last couple months. But for the sake of completeness, is there anything that's worth touching on with with sort of the quality?[00:16:46] NLW: Quality data or sort of a rag ops wars just in terms of, you know, anything that's changed, I guess, for you fundamentally in the last couple of months about where those things stand.[00:16:55] swyx: So I think we're going to talk about rag for the Gemini and Clouds discussion later. And so maybe briefly discuss the data piece.[00:17:03] Data War: Reddit x Google[00:17:03] swyx: I think maybe the only new thing was this Reddit deal with Google for like a 60 million dollar deal just ahead of their IPO, very conveniently turning Reddit into a AI data company. Also, very, very interestingly, a non exclusive deal, meaning that Reddit can resell that data to someone else. And it probably does become table stakes.[00:17:23] swyx: A lot of people don't know, but a lot of the web text dataset that originally started for GPT 1, 2, and 3 was actually scraped from GitHub. from Reddit at least the sort of vote scores. And I think, I think that's a, that's a very valuable piece of information. So like, yeah, I think people are figuring out how to pay for data.[00:17:40] swyx: People are suing each other over data. This, this, this war is, you know, definitely very, very much heating up. And I don't think, I don't see it getting any less intense. I, you know, next to GPUs, data is going to be the most expensive thing in, in a model stack company. And. You know, a lot of people are resorting to synthetic versions of it, which may or may not be kosher based on how far along or how commercially blessed the, the forms of creating that synthetic data are.[00:18:11] swyx: I don't know if Alessio, you have any other interactions with like Data source companies, but that's my two cents.[00:18:17] Alessio: Yeah yeah, I actually saw Quentin Anthony from Luther. ai at GTC this week. He's also been working on this. I saw Technium. He's also been working on the data side. I think especially in open source, people are like, okay, if everybody is putting the gates up, so to speak, to the data we need to make it easier for people that don't have 50 million a year to get access to good data sets.[00:18:38] Alessio: And Jensen, at his keynote, he did talk about synthetic data a little bit. So I think that's something that we'll definitely hear more and more of in the enterprise, which never bodes well, because then all the, all the people with the data are like, Oh, the enterprises want to pay now? Let me, let me put a pay here stripe link so that they can give me 50 million.[00:18:57] Alessio: But it worked for Reddit. I think the stock is up. 40 percent today after opening. So yeah, I don't know if it's all about the Google deal, but it's obviously Reddit has been one of those companies where, hey, you got all this like great community, but like, how are you going to make money? And like, they try to sell the avatars.[00:19:15] Alessio: I don't know if that it's a great business for them. The, the data part sounds as an investor, you know, the data part sounds a lot more interesting than, than consumer[00:19:25] swyx: cosmetics. Yeah, so I think, you know there's more questions around data you know, I think a lot of people are talking about the interview that Mira Murady did with the Wall Street Journal, where she, like, just basically had no, had no good answer for where they got the data for Sora.[00:19:39] swyx: I, I think this is where, you know, there's, it's in nobody's interest to be transparent about data, and it's, it's kind of sad for the state of ML and the state of AI research but it is what it is. We, we have to figure this out as a society, just like we did for music and music sharing. You know, in, in sort of the Napster to Spotify transition, and that might take us a decade.[00:19:59] swyx: Yeah, I[00:20:00] NLW: do. I, I agree. I think, I think that you're right to identify it, not just as that sort of technical problem, but as one where society has to have a debate with itself. Because I think that there's, if you rationally within it, there's Great kind of points on all side, not to be the sort of, you know, person who sits in the middle constantly, but it's why I think a lot of these legal decisions are going to be really important because, you know, the job of judges is to listen to all this stuff and try to come to things and then have other judges disagree.[00:20:24] NLW: And, you know, and have the rest of us all debate at the same time. By the way, as a total aside, I feel like the synthetic data right now is like eggs in the 80s and 90s. Like, whether they're good for you or bad for you, like, you know, we, we get one study that's like synthetic data, you know, there's model collapse.[00:20:42] NLW: And then we have like a hint that llama, you know, to the most high performance version of it, which was one they didn't release was trained on synthetic data. So maybe it's good. It's like, I just feel like every, every other week I'm seeing something sort of different about whether it's a good or bad for, for these models.[00:20:56] swyx: Yeah. The branding of this is pretty poor. I would kind of tell people to think about it like cholesterol. There's good cholesterol, bad cholesterol. And you can have, you know, good amounts of both. But at this point, it is absolutely without a doubt that most large models from here on out will all be trained as some kind of synthetic data and that is not a bad thing.[00:21:16] swyx: There are ways in which you can do it poorly. Whether it's commercial, you know, in terms of commercial sourcing or in terms of the model performance. But it's without a doubt that good synthetic data is going to help your model. And this is just a question of like where to obtain it and what kinds of synthetic data are valuable.[00:21:36] swyx: You know, if even like alpha geometry, you know, was, was a really good example from like earlier this year.[00:21:42] NLW: If you're using the cholesterol analogy, then my, then my egg thing can't be that far off. Let's talk about the sort of the state of the art and the, and the GPT 4 class landscape and how that's changed.[00:21:53] Gemini 1.5 vs Claude 3[00:21:53] NLW: Cause obviously, you know, sort of the, the two big things or a couple of the big things that have happened. Since we last talked, we're one, you know, Gemini first announcing that a model was coming and then finally it arriving, and then very soon after a sort of a different model arriving from Gemini and and Cloud three.[00:22:11] NLW: So I guess, you know, I'm not sure exactly where the right place to start with this conversation is, but, you know, maybe very broadly speaking which of these do you think have made a bigger impact? Thank you.[00:22:20] Alessio: Probably the one you can use, right? So, Cloud. Well, I'm sure Gemini is going to be great once they let me in, but so far I haven't been able to.[00:22:29] Alessio: I use, so I have this small podcaster thing that I built for our podcast, which does chapters creation, like named entity recognition, summarization, and all of that. Cloud Tree is, Better than GPT 4. Cloud2 was unusable. So I use GPT 4 for everything. And then when Opus came out, I tried them again side by side and I posted it on, on Twitter as well.[00:22:53] Alessio: Cloud is better. It's very good, you know, it's much better, it seems to me, it's much better than GPT 4 at doing writing that is more, you know, I don't know, it just got good vibes, you know, like the GPT 4 text, you can tell it's like GPT 4, you know, it's like, it always uses certain types of words and phrases and, you know, maybe it's just me because I've now done it for, you know, So, I've read like 75, 80 generations of these things next to each other.[00:23:21] Alessio: Clutter is really good. I know everybody is freaking out on twitter about it, my only experience of this is much better has been on the podcast use case. But I know that, you know, Quran from from News Research is a very big opus pro, pro opus person. So, I think that's also It's great to have people that actually care about other models.[00:23:40] Alessio: You know, I think so far to a lot of people, maybe Entropic has been the sibling in the corner, you know, it's like Cloud releases a new model and then OpenAI releases Sora and like, you know, there are like all these different things, but yeah, the new models are good. It's interesting.[00:23:55] NLW: My my perception is definitely that just, just observationally, Cloud 3 is certainly the first thing that I've seen where lots of people.[00:24:06] NLW: They're, no one's debating evals or anything like that. They're talking about the specific use cases that they have, that they used to use chat GPT for every day, you know, day in, day out, that they've now just switched over. And that has, I think, shifted a lot of the sort of like vibe and sentiment in the space too.[00:24:26] NLW: And I don't necessarily think that it's sort of a A like full you know, sort of full knock. Let's put it this way. I think it's less bad for open AI than it is good for anthropic. I think that because GPT 5 isn't there, people are not quite willing to sort of like, you know get overly critical of, of open AI, except in so far as they're wondering where GPT 5 is.[00:24:46] NLW: But I do think that it makes, Anthropic look way more credible as a, as a, as a player, as a, you know, as a credible sort of player, you know, as opposed to to, to where they were.[00:24:57] Alessio: Yeah. And I would say the benchmarks veil is probably getting lifted this year. I think last year. People were like, okay, this is better than this on this benchmark, blah, blah, blah, because maybe they did not have a lot of use cases that they did frequently.[00:25:11] Alessio: So it's hard to like compare yourself. So you, you defer to the benchmarks. I think now as we go into 2024, a lot of people have started to use these models from, you know, from very sophisticated things that they run in production to some utility that they have on their own. Now they can just run them side by side.[00:25:29] Alessio: And it's like, Hey, I don't care that like. The MMLU score of Opus is like slightly lower than GPT 4. It just works for me, you know, and I think that's the same way that traditional software has been used by people, right? Like you just strive for yourself and like, which one does it work, works best for you?[00:25:48] Alessio: Like nobody looks at benchmarks outside of like sales white papers, you know? And I think it's great that we're going more in that direction. We have a episode with Adapt coming out this weekend. I'll and some of their model releases, they specifically say, We do not care about benchmarks, so we didn't put them in, you know, because we, we don't want to look good on them.[00:26:06] Alessio: We just want the product to work. And I think more and more people will, will[00:26:09] swyx: go that way. Yeah. I I would say like, it does take the wind out of the sails for GPT 5, which I know where, you know, Curious about later on. I think anytime you put out a new state of the art model, you have to break through in some way.[00:26:21] swyx: And what Claude and Gemini have done is effectively take away any advantage to saying that you have a million token context window. Now everyone's just going to be like, Oh, okay. Now you just match the other two guys. And so that puts An insane amount of pressure on what gpt5 is going to be because it's just going to have like the only option it has now because all the other models are multimodal all the other models are long context all the other models have perfect recall gpt5 has to match everything and do more to to not be a flop[00:26:58] AI Breakdown Part 2[00:26:58] NLW: hello friends back again with part two if you haven't heard part one of this conversation i suggest you go check it out but to be honest they are kind of actually separable In this conversation, we get into a topic that I think Alessio and Swyx are very well positioned to discuss, which is what developers care about right now, what people are trying to build around.[00:27:16] NLW: I honestly think that one of the best ways to see the future in an industry like AI is to try to dig deep on what developers and entrepreneurs are attracted to build, even if it hasn't made it to the news pages yet. So consider this your preview of six months from now, and let's dive in. Let's bring it to the GPT 5 conversation.[00:27:33] Next Frontiers: Llama 3, GPT-5, Gemini 2, Claude 4[00:27:33] NLW: I mean, so, so I think that that's a great sort of assessment of just how the stakes have been raised, you know is your, I mean, so I guess maybe, maybe I'll, I'll frame this less as a question, just sort of something that, that I, that I've been watching right now, the only thing that makes sense to me with how.[00:27:50] NLW: Fundamentally unbothered and unstressed OpenAI seems about everything is that they're sitting on something that does meet all that criteria, right? Because, I mean, even in the Lex Friedman interview that, that Altman recently did, you know, he's talking about other things coming out first. He's talking about, he's just like, he, listen, he, he's good and he could play nonchalant, you know, if he wanted to.[00:28:13] NLW: So I don't want to read too much into it, but. You know, they've had so long to work on this, like unless that we are like really meaningfully running up against some constraint, it just feels like, you know, there's going to be some massive increase, but I don't know. What do you guys think?[00:28:28] swyx: Hard to speculate.[00:28:29] swyx: You know, at this point, they're, they're pretty good at PR and they're not going to tell you anything that they don't want to. And he can tell you one thing and change their minds the next day. So it's, it's, it's really, you know, I've always said that model version numbers are just marketing exercises, like they have something and it's always improving and at some point you just cut it and decide to call it GPT 5.[00:28:50] swyx: And it's more just about defining an arbitrary level at which they're ready and it's up to them on what ready means. We definitely did see some leaks on GPT 4. 5, as I think a lot of people reported and I'm not sure if you covered it. So it seems like there might be an intermediate release. But I did feel, coming out of the Lex Friedman interview, that GPT 5 was nowhere near.[00:29:11] swyx: And you know, it was kind of a sharp contrast to Sam talking at Davos in February, saying that, you know, it was his top priority. So I find it hard to square. And honestly, like, there's also no point Reading too much tea leaves into what any one person says about something that hasn't happened yet or has a decision that hasn't been taken yet.[00:29:31] swyx: Yeah, that's, that's my 2 cents about it. Like, calm down, let's just build .[00:29:35] Alessio: Yeah. The, the February rumor was that they were gonna work on AI agents, so I don't know, maybe they're like, yeah,[00:29:41] swyx: they had two agent two, I think two agent projects, right? One desktop agent and one sort of more general yeah, sort of GPTs like agent and then Andre left, so he was supposed to be the guy on that.[00:29:52] swyx: What did Andre see? What did he see? I don't know. What did he see?[00:29:56] Alessio: I don't know. But again, it's just like the rumors are always floating around, you know but I think like, this is, you know, we're not going to get to the end of the year without Jupyter you know, that's definitely happening. I think the biggest question is like, are Anthropic and Google.[00:30:13] Alessio: Increasing the pace, you know, like it's the, it's the cloud four coming out like in 12 months, like nine months. What's the, what's the deal? Same with Gemini. They went from like one to 1. 5 in like five days or something. So when's Gemini 2 coming out, you know, is that going to be soon? I don't know.[00:30:31] Alessio: There, there are a lot of, speculations, but the good thing is that now you can see a world in which OpenAI doesn't rule everything. You know, so that, that's the best, that's the best news that everybody got, I would say.[00:30:43] swyx: Yeah, and Mistral Large also dropped in the last month. And, you know, not as, not quite GPT 4 class, but very good from a new startup.[00:30:52] swyx: So yeah, we, we have now slowly changed in landscape, you know. In my January recap, I was complaining that nothing's changed in the landscape for a long time. But now we do exist in a world, sort of a multipolar world where Cloud and Gemini are legitimate challengers to GPT 4 and hopefully more will emerge as well hopefully from meta.[00:31:11] Open Source Models - Mistral, Grok[00:31:11] NLW: So speak, let's actually talk about sort of the open source side of this for a minute. So Mistral Large, notable because it's, it's not available open source in the same way that other things are, although I think my perception is that the community has largely given them Like the community largely recognizes that they want them to keep building open source stuff and they have to find some way to fund themselves that they're going to do that.[00:31:27] NLW: And so they kind of understand that there's like, they got to figure out how to eat, but we've got, so, you know, there there's Mistral, there's, I guess, Grok now, which is, you know, Grok one is from, from October is, is open[00:31:38] swyx: sourced at, yeah. Yeah, sorry, I thought you thought you meant Grok the chip company.[00:31:41] swyx: No, no, no, yeah, you mean Twitter Grok.[00:31:43] NLW: Although Grok the chip company, I think is even more interesting in some ways, but and then there's the, you know, obviously Llama3 is the one that sort of everyone's wondering about too. And, you know, my, my sense of that, the little bit that, you know, Zuckerberg was talking about Llama 3 earlier this year, suggested that, at least from an ambition standpoint, he was not thinking about how do I make sure that, you know, meta content, you know, keeps, keeps the open source thrown, you know, vis a vis Mistral.[00:32:09] NLW: He was thinking about how you go after, you know, how, how he, you know, releases a thing that's, you know, every bit as good as whatever OpenAI is on at that point.[00:32:16] Alessio: Yeah. From what I heard in the hallways at, at GDC, Llama 3, the, the biggest model will be, you 260 to 300 billion parameters, so that that's quite large.[00:32:26] Alessio: That's not an open source model. You know, you cannot give people a 300 billion parameters model and ask them to run it. You know, it's very compute intensive. So I think it is, it[00:32:35] swyx: can be open source. It's just, it's going to be difficult to run, but that's a separate question.[00:32:39] Alessio: It's more like, as you think about what they're doing it for, you know, it's not like empowering the person running.[00:32:45] Alessio: llama. On, on their laptop, it's like, oh, you can actually now use this to go after open AI, to go after Anthropic, to go after some of these companies at like the middle complexity level, so to speak. Yeah. So obviously, you know, we estimate Gentala on the podcast, they're doing a lot here, they're making PyTorch better.[00:33:03] Alessio: You know, they want to, that's kind of like maybe a little bit of a shorted. Adam Bedia, in a way, trying to get some of the CUDA dominance out of it. Yeah, no, it's great. The, I love the duck destroying a lot of monopolies arc. You know, it's, it's been very entertaining. Let's bridge[00:33:18] NLW: into the sort of big tech side of this, because this is obviously like, so I think actually when I did my episode, this was one of the I added this as one of as an additional war that, that's something that I'm paying attention to.[00:33:29] NLW: So we've got Microsoft's moves with inflection, which I think pretend, potentially are being read as A shift vis a vis the relationship with OpenAI, which also the sort of Mistral large relationship seems to reinforce as well. We have Apple potentially entering the race, finally, you know, giving up Project Titan and and, and kind of trying to spend more effort on this.[00:33:50] NLW: Although, Counterpoint, we also have them talking about it, or there being reports of a deal with Google, which, you know, is interesting to sort of see what their strategy there is. And then, you know, Meta's been largely quiet. We kind of just talked about the main piece, but, you know, there's, and then there's spoilers like Elon.[00:34:07] NLW: I mean, you know, what, what of those things has sort of been most interesting to you guys as you think about what's going to shake out for the rest of this[00:34:13] Apple MM1[00:34:13] swyx: year? I'll take a crack. So the reason we don't have a fifth war for the Big Tech Wars is that's one of those things where I just feel like we don't cover differently from other media channels, I guess.[00:34:26] swyx: Sure, yeah. In our anti interestness, we actually say, like, we try not to cover the Big Tech Game of Thrones, or it's proxied through Twitter. You know, all the other four wars anyway, so there's just a lot of overlap. Yeah, I think absolutely, personally, the most interesting one is Apple entering the race.[00:34:41] swyx: They actually released, they announced their first large language model that they trained themselves. It's like a 30 billion multimodal model. People weren't that impressed, but it was like the first time that Apple has kind of showcased that, yeah, we're training large models in house as well. Of course, like, they might be doing this deal with Google.[00:34:57] swyx: I don't know. It sounds very sort of rumor y to me. And it's probably, if it's on device, it's going to be a smaller model. So something like a Jemma. It's going to be smarter autocomplete. I don't know what to say. I'm still here dealing with, like, Siri, which hasn't, probably hasn't been updated since God knows when it was introduced.[00:35:16] swyx: It's horrible. I, you know, it, it, it makes me so angry. So I, I, one, as an Apple customer and user, I, I'm just hoping for better AI on Apple itself. But two, they are the gold standard when it comes to local devices, personal compute and, and trust, like you, you trust them with your data. And. I think that's what a lot of people are looking for in AI, that they have, they love the benefits of AI, they don't love the downsides, which is that you have to send all your data to some cloud somewhere.[00:35:45] swyx: And some of this data that we're going to feed AI is just the most personal data there is. So Apple being like one of the most trusted personal data companies, I think it's very important that they enter the AI race, and I hope to see more out of them.[00:35:58] Alessio: To me, the, the biggest question with the Google deal is like, who's paying who?[00:36:03] Alessio: Because for the browsers, Google pays Apple like 18, 20 billion every year to be the default browser. Is Google going to pay you to have Gemini or is Apple paying Google to have Gemini? I think that's, that's like what I'm most interested to figure out because with the browsers, it's like, it's the entry point to the thing.[00:36:21] Alessio: So it's really valuable to be the default. That's why Google pays. But I wonder if like the perception in AI is going to be like, Hey. You just have to have a good local model on my phone to be worth me purchasing your device. And that was, that's kind of drive Apple to be the one buying the model. But then, like Shawn said, they're doing the MM1 themselves.[00:36:40] Alessio: So are they saying we do models, but they're not as good as the Google ones? I don't know. The whole thing is, it's really confusing, but. It makes for great meme material on on Twitter.[00:36:51] swyx: Yeah, I mean, I think, like, they are possibly more than OpenAI and Microsoft and Amazon. They are the most full stack company there is in computing, and so, like, they own the chips, man.[00:37:05] swyx: Like, they manufacture everything so if, if, if there was a company that could do that. You know, seriously challenge the other AI players. It would be Apple. And it's, I don't think it's as hard as self driving. So like maybe they've, they've just been investing in the wrong thing this whole time. We'll see.[00:37:21] swyx: Wall Street certainly thinks[00:37:22] NLW: so. Wall Street loved that move, man. There's a big, a big sigh of relief. Well, let's, let's move away from, from sort of the big stuff. I mean, the, I think to both of your points, it's going to.[00:37:33] Meta's $800b AI rebrand[00:37:33] NLW: Can I, can[00:37:34] swyx: I, can I, can I jump on factoid about this, this Wall Street thing? I went and looked at when Meta went from being a VR company to an AI company.[00:37:44] swyx: And I think the stock I'm trying to look up the details now. The stock has gone up 187% since Lamo one. Yeah. Which is $830 billion in market value created in the past year. . Yeah. Yeah.[00:37:57] NLW: It's, it's, it's like, remember if you guys haven't Yeah. If you haven't seen the chart, it's actually like remarkable.[00:38:02] NLW: If you draw a little[00:38:03] swyx: arrow on it, it's like, no, we're an AI company now and forget the VR thing.[00:38:10] NLW: It's it, it is an interesting, no, it's, I, I think, alessio, you called it sort of like Zuck's Disruptor Arc or whatever. He, he really does. He is in the midst of a, of a total, you know, I don't know if it's a redemption arc or it's just, it's something different where, you know, he, he's sort of the spoiler.[00:38:25] NLW: Like people loved him just freestyle talking about why he thought they had a better headset than Apple. But even if they didn't agree, they just loved it. He was going direct to camera and talking about it for, you know, five minutes or whatever. So that, that's a fascinating shift that I don't think anyone had on their bingo card, you know, whatever, two years ago.[00:38:41] NLW: Yeah. Yeah,[00:38:42] swyx: we still[00:38:43] Alessio: didn't see and fight Elon though, so[00:38:45] swyx: that's what I'm really looking forward to. I mean, hey, don't, don't, don't write it off, you know, maybe just these things take a while to happen. But we need to see and fight in the Coliseum. No, I think you know, in terms of like self management, life leadership, I think he has, there's a lot of lessons to learn from him.[00:38:59] swyx: You know he might, you know, you might kind of quibble with, like, the social impact of Facebook, but just himself as a in terms of personal growth and, and, you know, Per perseverance through like a lot of change and you know, everyone throwing stuff his way. I think there's a lot to say about like, to learn from, from Zuck, which is crazy 'cause he's my age.[00:39:18] swyx: Yeah. Right.[00:39:20] AI Engineer landscape - from baby AGIs to vertical Agents[00:39:20] NLW: Awesome. Well, so, so one of the big things that I think you guys have, you know, distinct and, and unique insight into being where you are and what you work on is. You know, what developers are getting really excited about right now. And by that, I mean, on the one hand, certainly, you know, like startups who are actually kind of formalized and formed to startups, but also, you know, just in terms of like what people are spending their nights and weekends on what they're, you know, coming to hackathons to do.[00:39:45] NLW: And, you know, I think it's a, it's a, it's, it's such a fascinating indicator for, for where things are headed. Like if you zoom back a year, right now was right when everyone was getting so, so excited about. AI agent stuff, right? Auto, GPT and baby a GI. And these things were like, if you dropped anything on YouTube about those, like instantly tens of thousands of views.[00:40:07] NLW: I know because I had like a 50,000 view video, like the second day that I was doing the show on YouTube, you know, because I was talking about auto GPT. And so anyways, you know, obviously that's sort of not totally come to fruition yet, but what are some of the trends in what you guys are seeing in terms of people's, people's interest and, and, and what people are building?[00:40:24] Alessio: I can start maybe with the agents part and then I know Shawn is doing a diffusion meetup tonight. There's a lot of, a lot of different things. The, the agent wave has been the most interesting kind of like dream to reality arc. So out of GPT, I think they went, From zero to like 125, 000 GitHub stars in six weeks, and then one year later, they have 150, 000 stars.[00:40:49] Alessio: So there's kind of been a big plateau. I mean, you might say there are just not that many people that can start it. You know, everybody already started it. But the promise of, hey, I'll just give you a goal, and you do it. I think it's like, amazing to get people's imagination going. You know, they're like, oh, wow, this This is awesome.[00:41:08] Alessio: Everybody, everybody can try this to do anything. But then as technologists, you're like, well, that's, that's just like not possible, you know, we would have like solved everything. And I think it takes a little bit to go from the promise and the hope that people show you to then try it yourself and going back to say, okay, this is not really working for me.[00:41:28] Alessio: And David Wong from Adept, you know, they in our episode, he specifically said. We don't want to do a bottom up product. You know, we don't want something that everybody can just use and try because it's really hard to get it to be reliable. So we're seeing a lot of companies doing vertical agents that are narrow for a specific domain, and they're very good at something.[00:41:49] Alessio: Mike Conover, who was at Databricks before, is also a friend of Latentspace. He's doing this new company called BrightWave doing AI agents for financial research, and that's it, you know, and they're doing very well. There are other companies doing it in security, doing it in compliance, doing it in legal.[00:42:08] Alessio: All of these things that like, people, nobody just wakes up and say, Oh, I cannot wait to go on AutoGPD and ask it to do a compliance review of my thing. You know, just not what inspires people. So I think the gap on the developer side has been the more bottom sub hacker mentality is trying to build this like very Generic agents that can do a lot of open ended tasks.[00:42:30] Alessio: And then the more business side of things is like, Hey, If I want to raise my next round, I can not just like sit around the mess, mess around with like super generic stuff. I need to find a use case that really works. And I think that that is worth for, for a lot of folks in parallel, you have a lot of companies doing evals.[00:42:47] Alessio: There are dozens of them that just want to help you measure how good your models are doing. Again, if you build evals, you need to also have a restrained surface area to actually figure out whether or not it's good, right? Because you cannot eval anything on everything under the sun. So that's another category where I've seen from the startup pitches that I've seen, there's a lot of interest in, in the enterprise.[00:43:11] Alessio: It's just like really. Fragmented because the production use cases are just coming like now, you know, there are not a lot of long established ones to, to test against. And so does it, that's kind of on the virtual agents and then the robotic side it's probably been the thing that surprised me the most at NVIDIA GTC, the amount of robots that were there that were just like robots everywhere.[00:43:33] Alessio: Like, both in the keynote and then on the show floor, you would have Boston Dynamics dogs running around. There was, like, this, like fox robot that had, like, a virtual face that, like, talked to you and, like, moved in real time. There were industrial robots. NVIDIA did a big push on their own Omniverse thing, which is, like, this Digital twin of whatever environments you're in that you can use to train the robots agents.[00:43:57] Alessio: So that kind of takes people back to the reinforcement learning days, but yeah, agents, people want them, you know, people want them. I give a talk about the, the rise of the full stack employees and kind of this future, the same way full stack engineers kind of work across the stack. In the future, every employee is going to interact with every part of the organization through agents and AI enabled tooling.[00:44:17] Alessio: This is happening. It just needs to be a lot more narrow than maybe the first approach that we took, which is just put a string in AutoGPT and pray. But yeah, there's a lot of super interesting stuff going on.[00:44:27] swyx: Yeah. Well, he Let's recover a lot of stuff there. I'll separate the robotics piece because I feel like that's so different from the software world.[00:44:34] swyx: But yeah, we do talk to a lot of engineers and you know, that this is our sort of bread and butter. And I do agree that vertical agents have worked out a lot better than the horizontal ones. I think all You know, the point I'll make here is just the reason AutoGPT and maybe AGI, you know, it's in the name, like they were promising AGI.[00:44:53] swyx: But I think people are discovering that you cannot engineer your way to AGI. It has to be done at the model level and all these engineering, prompt engineering hacks on top of it weren't really going to get us there in a meaningful way without much further, you know, improvements in the models. I would say, I'll go so far as to say, even Devin, which is, I would, I think the most advanced agent that we've ever seen, still requires a lot of engineering and still probably falls apart a lot in terms of, like, practical usage.[00:45:22] swyx: Or it's just, Way too slow and expensive for, you know, what it's, what it's promised compared to the video. So yeah, that's, that's what, that's what happened with agents from, from last year. But I, I do, I do see, like, vertical agents being very popular and, and sometimes you, like, I think the word agent might even be overused sometimes.[00:45:38] swyx: Like, people don't really care whether or not you call it an AI agent, right? Like, does it replace boring menial tasks that I do That I might hire a human to do, or that the human who is hired to do it, like, actually doesn't really want to do. And I think there's absolutely ways in sort of a vertical context that you can actually go after very routine tasks that can be scaled out to a lot of, you know, AI assistants.[00:46:01] swyx: So, so yeah, I mean, and I would, I would sort of basically plus one what let's just sit there. I think it's, it's very, very promising and I think more people should work on it, not less. Like there's not enough people. Like, we, like, this should be the, the, the main thrust of the AI engineer is to look out, look for use cases and, and go to a production with them instead of just always working on some AGI promising thing that never arrives.[00:46:21] swyx: I,[00:46:22] NLW: I, I can only add that so I've been fiercely making tutorials behind the scenes around basically everything you can imagine with AI. We've probably done, we've done about 300 tutorials over the last couple of months. And the verticalized anything, right, like this is a solution for your particular job or role, even if it's way less interesting or kind of sexy, it's like so radically more useful to people in terms of intersecting with how, like those are the ways that people are actually.[00:46:50] NLW: Adopting AI in a lot of cases is just a, a, a thing that I do over and over again. By the way, I think that's the same way that even the generalized models are getting adopted. You know, it's like, I use midjourney for lots of stuff, but the main thing I use it for is YouTube thumbnails every day. Like day in, day out, I will always do a YouTube thumbnail, you know, or two with, with Midjourney, right?[00:47:09] NLW: And it's like you can, you can start to extrapolate that across a lot of things and all of a sudden, you know, a AI doesn't. It looks revolutionary because of a million small changes rather than one sort of big dramatic change. And I think that the verticalization of agents is sort of a great example of how that's[00:47:26] swyx: going to play out too.[00:47:28] Adept episode - Screen Multimodality[00:47:28] swyx: So I'll have one caveat here, which is I think that Because multi modal models are now commonplace, like Cloud, Gemini, OpenAI, all very very easily multi modal, Apple's easily multi modal, all this stuff. There is a switch for agents for sort of general desktop browsing that I think people so much for joining us today, and we'll see you in the next video.[00:48:04] swyx: Version of the the agent where they're not specifically taking in text or anything They're just watching your screen just like someone else would and and I'm piloting it by vision And you know in the the episode with David that we'll have dropped by the time that this this airs I think I think that is the promise of adept and that is a promise of what a lot of these sort of desktop agents Are and that is the more general purpose system That could be as big as the browser, the operating system, like, people really want to build that foundational piece of software in AI.[00:48:38] swyx: And I would see, like, the potential there for desktop agents being that, that you can have sort of self driving computers. You know, don't write the horizontal piece out. I just think we took a while to get there.[00:48:48] NLW: What else are you guys seeing that's interesting to you? I'm looking at your notes and I see a ton of categories.[00:48:54] Top Model Research from January Recap[00:48:54] swyx: Yeah so I'll take the next two as like as one category, which is basically alternative architectures, right? The two main things that everyone following AI kind of knows now is, one, the diffusion architecture, and two, the let's just say the, Decoder only transformer architecture that is popularized by GPT.[00:49:12] swyx: You can read, you can look on YouTube for thousands and thousands of tutorials on each of those things. What we are talking about here is what's next, what people are researching, and what could be on the horizon that takes the place of those other two things. So first of all, we'll talk about transformer architectures and then diffusion.[00:49:25] swyx: So transformers the, the two leading candidates are effectively RWKV and the state space models the most recent one of which is Mamba, but there's others like the Stripe, ENA, and the S four H three stuff coming out of hazy research at Stanford. And all of those are non quadratic language models that scale the promise to scale a lot better than the, the traditional transformer.[00:49:47] swyx: That this might be too theoretical for most people right now, but it's, it's gonna be. It's gonna come out in weird ways, where, imagine if like, Right now the talk of the town is that Claude and Gemini have a million tokens of context and like whoa You can put in like, you know, two hours of video now, okay But like what if you put what if we could like throw in, you know, two hundred thousand hours of video?[00:50:09] swyx: Like how does that change your usage of AI? What if you could throw in the entire genetic sequence of a human and like synthesize new drugs. Like, well, how does that change things? Like, we don't know because we haven't had access to this capability being so cheap before. And that's the ultimate promise of these two models.[00:50:28] swyx: They're not there yet but we're seeing very, very good progress. RWKV and Mamba are probably the, like, the two leading examples, both of which are open source that you can try them today and and have a lot of progress there. And the, the, the main thing I'll highlight for audio e KV is that at, at the seven B level, they seem to have beat LAMA two in all benchmarks that matter at the same size for the same amount of training as an open source model.[00:50:51] swyx: So that's exciting. You know, they're there, they're seven B now. They're not at seven tb. We don't know if it'll. And then the other thing is diffusion. Diffusions and transformers are are kind of on the collision course. The original stable diffusion already used transformers in in parts of its architecture.[00:51:06] swyx: It seems that transformers are eating more and more of those layers particularly the sort of VAE layer. So that's, the Diffusion Transformer is what Sora is built on. The guy who wrote the Diffusion Transformer paper, Bill Pebbles, is, Bill Pebbles is the lead tech guy on Sora. So you'll just see a lot more Diffusion Transformer stuff going on.[00:51:25] swyx: But there's, there's more sort of experimentation with diffusion. I'm holding a meetup actually here in San Francisco that's gonna be like the state of diffusion, which I'm pretty excited about. Stability's doing a lot of good work. And if you look at the, the architecture of how they're creating Stable Diffusion 3, Hourglass Diffusion, and the inconsistency models, or SDXL Turbo.[00:51:45] swyx: All of these are, like, very, very interesting innovations on, like, the original idea of what Stable Diffusion was. So if you think that it is expensive to create or slow to create Stable Diffusion or an AI generated art, you are not up to date with the latest models. If you think it is hard to create text and images, you are not up to date with the latest models.[00:52:02] swyx: And people still are kind of far behind. The last piece of which is the wildcard I always kind of hold out, which is text diffusion. So Instead of using autogenerative or autoregressive transformers, can you use text to diffuse? So you can use diffusion models to diffuse and create entire chunks of text all at once instead of token by token.[00:52:22] swyx: And that is something that Midjourney confirmed today, because it was only rumored the past few months. But they confirmed today that they were looking into. So all those things are like very exciting new model architectures that are, Maybe something that we'll, you'll see in production two to three years from now.[00:52:37] swyx: So the couple of the trends[00:52:38] NLW: that I want to just get your takes on, because they're sort of something that, that seems like they're coming up are one sort of these, these wearable, you know, kind of passive AI experiences where they're absorbing a lot of what's going on around you and then, and then kind of bringing things back.[00:52:53] NLW: And then the, the other one that I, that I wanted to see if you guys had thoughts on were sort of this next generation of chip companies. Obviously there's a huge amount of emphasis. On on hardware and silicon and, and, and different ways of doing things, but, y

Netlify is a popular hosting platform that provides build, deploy, and serverless backend services for web apps. The platform enables deployment directly from source files stored in a version control system like GitHub. Erica Pisani is a Senior Software Engineer at Netlify. She joins the show to talk about how she got started at Netlify, The post Netlify and Edge Computing with Erica Pisani appeared first on Software Engineering Daily.

Netlify is a popular hosting platform that provides build, deploy, and serverless backend services for web apps. The platform enables deployment directly from source files stored in a version control system like GitHub. Erica Pisani is a Senior Software Engineer at Netlify. She joins the show to talk about how she got started at Netlify, The post Netlify and Edge Computing with Erica Pisani appeared first on Software Engineering Daily.

Hosts Victoria Guido and Will Larry are joined by Trent Walton, CEO of Luro. Trent shares his journey into the design world, from his early fascination with typography and logos to co-founding Paravel. This agency later evolved into creating Luro, a no-code solution for building design systems and tracking their adoption across products. Trent emphasizes the importance of understanding the materials one works with in design and development and stresses the need for a holistic approach to product building. This approach blurs the lines between disciplines, encouraging a generalist mindset over specialization. Luro, as a product, stemmed from the realization that existing design systems often fell short in adoption and application, leading to a search for a more integrated and comprehensive solution. Trent outlines the functionality and vision behind Luro, explaining how it serves not just designers and developers but entire organizations by fostering better collaboration, documentation, and understanding of design decisions. Luro aims to streamline the creation and maintenance of design systems, making them more accessible and manageable, even for teams facing resource constraints. By incorporating performance, accessibility metrics, and the ability to track component adoption and integration, Luro provides a platform for continuous improvement and alignment with organizational goals. Luro (https://luroapp.com/) Follow Luro on LinkedIn (https://www.linkedin.com/company/luroapp/), YouTube (https://www.youtube.com/channel/UCsS9BEmX1NPBXkbaLGcMZlw), Discord (https://discord.com/invite/aNEdjnR6A5), or Instagram (https://www.instagram.com/luroapp/). Follow Trent Walton on LinkedIn (https://www.linkedin.com/in/trent-walton/). Visit his website at trentwalton.com (https://trentwalton.com/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript:  VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. WILL: And I'm your other host, Will Larry. And with me today is Trent Walton, CEO of Luro. Luro is a no-code solution to build your design system and track adoption across your entire product. Trent, thank you for joining me. TRENT: Oh, thanks for having me. It's great to be here. WILL: Yeah, I can't wait to dive into Luro and get to know more about the product. But before we go into that, tell us a little bit about yourself. I know you're based out of Texas. TRENT: Yeah, I grew up, lived here my whole life. I'm in Austin with the other co-founders, Dave and Reagan. Been a designer probably all my life, always been interested in, like, typography and fonts. When I was little, I used to buy badges for cars from swap meets and take them home, not because I needed, like, I had a car I was building and had any interest in, like, sandblasting or building an engine. I just liked the typography, and the design of the icons, and the logos, and all that kind of thing. And so, now it's evolved into me just being, like, a type aficionado and a graphic design aficionado, and then that evolved into, especially when I discovered the web in the early 2000s, building and designing websites with Dave and Reagan, who I mentioned. And so, we had an agency called Paravel early on and had a lot of time putting into practice kind of that design and development and building for the web. VICTORIA: So, your first interest in design came from, is it a car engine? Is that what I heard? TRENT: Well, yeah, my father is a mechanical engineer, and so is my brother. And they work on cars, have classic, like, old Mustangs and Cobras and things that they build in their spare time. And I have no interest in that kind of work [laughs] but grew up in that environment. And, you know, pre-internet growing up in the '80s, one of the things that really got me was the aesthetic and the design around those kinds of muscle cars, so, like, old Shelby or Cobra or Mustang Ford ads, just, I really got into that. So, I'd buy, like, car manuals for a few bucks, or if there's a Mustang Cobra and there's a cool, like, chrome snake logo with a condensed uppercase typeface or some sort of lettering that says, you know, "Shelby Cobra." And that's when I realized [laughs] where my interests lie. You know, engines are cool. They sound cool. Fast cars are cool. But I was just totally, you know, enamored with the typography and the design aspect that surrounded those things, and then it just kind of evolved from there. Anything else I could get my hooks into, I picked up on. VICTORIA: I love that because when I talk to people about design, for folks who don't have a background in it, they kind of think, oh, design, that's logos. You know, I'm redesigning my house right now. My husband is like, "Oh, it's picking the tiles and the colors. We can do that." And I'm like, "No, like, design, there's a lot more to it. Design is everywhere." Like, you can find design inspiration from car manuals [laughs], it's so funny that you bought those, or from random logo design and actually, like, really good design. If it's something that's designed well, you probably don't even notice it. You just flow and use the space or use the app as you're intended to. TRENT: Yeah. And I also think that getting inspiration or starting ideas out from anywhere but the medium you're working in might be a nice little trick to bring some, like, naïve, fresh perspective to things. So, I try to go back to that stuff as much as possible. I have heaps of manuals I've bought off of eBay in recent years, yeah, things you wouldn't think you'd find on, like, you know, whatever, a graphic designer's bookcase, just anything to sort of break the monotony or break my own little lenses of what a website should look like, or what a logo or a brand should look like, how to step outside of that a little bit. But it's funny because it really does go back to that initial sense of wonder I experienced at those really just, you know, we're talking, like, in a gross, swampy field in Texas with, like, funnel cakes being served at every corner, like, not the most slick, rad graphic designy vibe, but that's where it all started for me. So, I go back there as often as I can [laughs]. VICTORIA: So, how do you talk to founders or people who are thinking about building products? How do you talk to them about design and give them a where to get started approach? TRENT: I don't know that I ever specifically talk about design or even maybe, like, engineering or about performance. I talk about all those things, accessibility, et cetera. I try to blur those lines as much as possible. It's maybe an idyllic thing that I've had for years. But going back to the agency days, I'll call them the agency days, but up until, like, you know, 2015, '16, Dave, Reagan, and I ran an agency called Paravel. And by nature, the three of us are some sort of a hybrid between a designer, maybe, like, a front-end developer. You know, Dave's more of an engineer now. But we've all been very careful to make sure that we're generalists, which I don't know that that, like, career-wise that, might pay off long term, but I cannot work on the web any other way or talk about the web any other way. I've always felt like, I mean, there was the old, which we don't have to get into, gosh, but the debate on should designers code? But I think the essence of that is really, like, should we be familiar with the materials we're working on? So, anytime I start to talk about designing for the web or designing a product, you want to make sure everyone has a clear understanding of the environment that they're working with. So, is it, you know, a website? And is performance important? And is our site that we're redesigning is it performant now? Is it fast or slow? Or am I a designer who only cares, and this is a thing that I have to fight inside of myself all the time? So, I'm not trash-talking anybody, but, like, do I want to load a bunch of fonts and cool images, and is that my KPI is how interesting and engaging the visuals are? Which is a great one to have, but it also, you know, while you're talking about design, you have to consider all of these other things that can define quality for an experience. Maybe those other things don't matter as much from one person to the next. But the more they are in front of me, the more they evolve the way I perceive what I work on. And so, I try to never really isolate any kind of aspect into maybe, like, a stage or a sprint that we're doing as a team. It's just sort of this holistic kind of hippie vibey way to look at sites, but I want to make sure that it's always, like, we're always starting from a very, very broad place that involves every aspect, and all team members and stuff like that. VICTORIA: Well, I love that because I try to think about that in the same way from the other end, like, on the operations perspective when you're talking about site performance. And, you know, like, is the site responding fast enough? And it comes back to the question of, like, well, what is the experience, expectations of the user? And what's important to get done on the site? [laughs] And having those conversations, like, early on and integrating all these different teams from the design and development and operation side to have that conversation so everyone knows what is the goal of the site and what is the important aspects of the user experience that the system needs to be able to support? So, I also like that you said that it's like, well, should you be familiar with the materials that you're using? [laughs] Thought that that was really cool. Like, I'm actually...my husband and I are renovating our home. And I'm talking about why we should invest in design [laughs], and part of it's because there's things to know about the materials. Like, if you're choosing a floor for your house, like, the designers will know, like, what's the durable ones? What's the ones that are going to fit your need, and your cost, and your budget? And so, like, they don't necessarily need to be a person who's going to lay the floors [laughs], but they need to know what to expect out of what you decide to use. TRENT: Yeah, it's, like, all of these constraints. And so, being familiar with the real-world implications of the decisions we make, you know, inform that. So, yeah, I mean, I think that's pretty similar, too. It's like, well, you need this floor because it's more durable in this climate or whatever, same thing for, you know, the websites that we build. It's all contingent upon the outcomes that, hopefully, we can mutually agree on. You know, there's kind of a general sense of, like, performance is important, and accessibility is paramount and extremely important. But then there's some nuance to that as you get into some smaller decisions. So, having these kinds of discussions early on and frequently and almost...the way I like to think about it is rather than, like, a check-in where we say, "Okay, this is it," but having a place where we can all look to check in and find information and share information that's maybe not so fast. One thing I like to think about is things get lost in chats and maybe even tickets, so as you're closing tickets and opening tickets. There's a bug. I solved it. It's gone. Can you send me this logo? Can we tweak this? These micro changes they open and close very, very quickly. And so, there's this firehose that happens. And so, I find that having a place separate from that for discussing these things and remembering these things, and referencing these things while we are in our code editors or inside of our Figma or any kind of design tool that we use to sort of cross-reference and simmer on things as we think about the decisions that we have to make, as opposed to just knocking them out super quick, always being mindful of those constraints. And again, yeah, the [chuckles] materials we're working with, whether it's just, you know, HTML, CSS, and JavaScript or whatever, but all of those things. It's good to be mindful of that. WILL: I know you said that you've been in design for a while, and so I love just picking the brain of someone who's been into it a while and see how far we've come from, especially just the 2000s. So, in your opinion, with design, how do you feel about where we've come since the beginning of tech to where we're at now and, also, I guess, where we're going with the design? TRENT: Yeah. So, I guess I can really just frame...this is going to help me remember just framing [laughs] where we were. I started off on Homestead, which is sort of like GeoCities. I was in college. I graduated, and I think it was 2001, maybe 2000, anyways. And it was mainly just taking images...I didn't even have Photoshop at this point. And you realize you could, like, tile a background for a build your own website. Homestead was one of those kinds of deals. And I thought that was very interesting. So, I had this cheap digital camera. It took a lot of cords to figure out how to, like, port that onto this old, crappy Hewlett Packard computer that was, like, a hand-me-down. Fast forward a couple of years, I had graduated, did not study design, so I'm all kind of self-taught or just taught by the web, the peers, the information that has been shared and been influenced by. But Dreamweaver was out, and Macromedia was huge, and I loved Fireworks. And so, Dave Rupert, I paid him $80 to teach me HTML [laughs], and so we've been together ever since. This is right out of college. And so, the tools that we used there were pretty rudimentary, but Fireworks was rad. Like, it was kind of web-based. It felt like it made more sense. I love Photoshop, and that's kind of, like, a primary graphic design tool that I still use to this day. But early on, it just felt like everything was so harshly limited. So, if you had any kind of idea that you wanted to execute that you could just draw on a piece of paper, mock it up in Photoshop, the amount of work that you had to do to get that to happen was either extremely high, or it was just impossible. And then, if it was impossible, I bet you can guess what we did. We went to Flash, and we made, like, a crappy video of a web page that was not accessible and really hard to use. I was heavy into Flash for, like, two or three years until kind of, as I had been warned by Dave that, you know, HTML and CSS are going to be the way the web works. But when I came back to that, there was this wonderful time where it felt like we were charting out every single...it was just new territory. It's like we had come to this other planet or this other world, and everything that needed to be done, we had to figure out how, like, getting web fonts onto pages, rounding borders. I mean, getting that done aside from slicing images in Fireworks felt like this new monumental discovery that changed the lives of many. Maybe it did, maybe it didn't, but in my world, it felt like that. And so, early on, you can look back on it and go, gosh, everything was a pain in the ass, like, living with all of these limitations. But for me, I do look back at it like that, but I also look back on it as this wonderful time where we were building the web that we're working on now. So, all these things that make designing easier and quicker come with some sort of a, you know, an evolution of your perception, and [inaudible 13:14] fond memories of work along the way. For me, it's sort of I've just always sort of been around working on the web and watching design evolve, and every little step maybe feels like a tiny one or a large one. But these days, it just seems like, oh, this is exactly how it should have [laughs] always been, like, convenient grids and convenient box shadow and all that kind of stuff. But yeah, it's been nice to sort of grow up only being a web designer. Like, I mean, I've done graphic design. I've done brochures and, print design, and logo design for sure. But, I have always been anchored to and centered around web design and thinking about things in the context of how they will be applied to the web first and foremost. MID-ROLL AD: Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you're tight on time and investment, which is why we've created targeted 1-hour remote workshops to help you develop a concrete plan for your product's next steps. Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. Find out how we can help you move the needle at tbot.io/entrepreneurs. VICTORIA: So, what was the turning point for you that led you to found Luro? How did it all get started? TRENT: With Paravel, the agency days, we had a lot of fun. I think, for us, our big agency spike was when responsive web design came out. Ethan coined the term. There was a lot of people on the web, you know, a lot of agencies or a lot of teams, a lot of companies that needed to pivot into that. And so, we found this great working relationship with companies where we would come in and sort of had a little bit more practice just because we got in early learning kind of how to do that well, I think. And it was a sort of we're going to redesign a page, a homepage perhaps, or, like, a marketing page. You'll do that project; three to six months go by. And then the next thing turns into, well, we have this giant network of e-commerce stores. We have this giant network of pages with, like, download centers and support documents. And now, we need to make everything responsive, and it can be anything. We need to make everything accessible. We need to make everything performant. We need to update the brand on everything. And I don't think we're alone in this. I think this is the beginning of the greater design system discussion as it applies to the web. Obviously, design systems predate the web; design systems pre-date, like, 2012 or '13 or whenever we got into it. But projects started to migrate from, "Hey, can you design this really amazing, responsive marketing page," to "We have a system, and we need you to solve these problems." We love working on those problems. I still do to this day. But the reason why we switched from kind of being a, you know, individual contributor-type agency consultant type roles to building a SaaS product was because we were realizing that things got complicated...is a very, like, boring way to say it. But to get a little deeper, it was, we would see things not ship. So, like, our morale went down. The teams that we were working with morale kind of went down. And as I was digging into why things weren't shipping...and when I mean ship, I think, like, pages would ship, of course. Like, here's a page. It just needs to be built, somebody decided, or a new feature needs to be built. Of course, those went out. But the idea of, is our design system or the system that we're designing launched? Is it applied? Is it fully adopted? Is it partially adopted? It never felt like the amount of traction that we were promising or that we were being asked for. And I don't mean we, as in just the three of us, but the entire team or the entire organization who, in many cases, all were bought into the idea of design systems. So, what we found was, when things got real, and we had to give up things, and we had to work on things and prioritize things, it became much more difficult to work in that capacity, probably partially because of the cross-discipline nature of those things. So, as opposed to what I consider maybe a miserable way to work in many cases, is the classic; here's my Photoshop comp. And I have a red line document JPEG that I will give you, whatever engineer I'm working with, or it's myself, and I'm just giving myself a red line document, but you're just going through and trying to make those things match. And that is sort of not fun for the team because now we're just sort of chiseling each other and sort of, like, going through and critiquing our work over and over versus really kind of in the spirit of prototyping and inventing together. I find that products are diminished when you do that. So, as you try to get into this design system part, it requires a lot more insight into what everyone around us is doing, kind of, as I was saying at the beginning, how to have this cross-discipline view of what we are actually working on. And that view is what we thought, and we still believe in many cases, is absolutely missing. So, you can spin up a design system. And Luro is not the only design system tool. Of course, you can spin up your own. And what I mean by that is, like...I'm maybe going to answer, like, three questions in one. Maybe you haven't even asked them yet. But just to kind of frame this, if you ask anyone what a design system is, it might be a different answer. It might be these are my Figma components that I've created and I've shared out, and there's a public link. You know, an engineer might say, "Well, it's the GitHub repo of components that I'm actually using." So, the design is helpful as documentation. But the design system is the code, or the design system is the actual...or the actual components that are live that users see, which I would argue probably is the most accurate, just because we're talking about user experience impacting whatever business objectives we may have. So, those components need to make their way into live sites or products. So, finding out what that answer is, what's the source of truth? What is our design system? What are our components? What are our standards? You have to have multiple sources for that, just because there's multiple people with multiple opinions and multiple measures of success involved in those. And all of those opinions and measures of success, I would say, are valid. So, accounting for those and kind of crossing the streams, if you will, in one sort of central UI, we believed was crucial enough that we should jump out of the agency days and into a product-building scenario. VICTORIA: That's really interesting. So, you saw this pattern in the delivery of your work as an agency that made you want to build a solution to create better outcomes for a potentially exponential number of clients, right? [chuckles] TRENT: Yeah, hopefully. I think that working on how you work together as a team is vitally important, and if you can find the right environment, then the actual product will benefit. I mean, and I'm not even just thinking about these maybe soft things like, oh yeah, if engineers and designers can work together, the typography will be a little bit better, and the site will feel a little bit more cohesive, and it'll be maybe a little bit easier to digest. I believe that. But I also believe that there are people in organizations doing research, financial analysis, customer analysis, A/B testing, you know, all sorts of work that contributes to the decisions that we make about our sites and products that sort of just gets lost in the shuffle, in the firehose of the day to day. So, having something that takes not only a, I guess, what you could classify as the what for a design system, it could be the design of a component. Maybe it's actually even, too, as well, the code that makes up that component. But then there's this giant why. Why does the button look the way that it does? Why does a card have a border around it? Why? Why? Why? Why? Why? These things maybe they come up during meetings. Maybe there's something that, as a designer or an engineer, I found maybe on the company's shared OneDrive or somebody mentioned in passing. Those things are vitally important, and they need to be, again, back to the morale and perception evolving; they need to be accessible to everyone. But it's a needle-in-a haystack situation. It's funny. We would consult. And one of my favorite stories is we were building this prototype. We were hired to build a prototype for a startup in Austin. They were on a big, open floor-plan office with the glass meeting rooms. And we were showing off our prototype, and we just felt really clever and witty about the way we were going to solve this and the pages that we were going to build. And who is a friend now, a person named Angela walks by, and she's like, "What are you working on?" And we told her what it was. And she says, "Oh, wow, you know, six months before you started contracting with the startup, we did this all, and we've user-tested it. Everybody's been reorged, and nobody remembers. But I have this PowerPoint I can send you, and it will show you the results. Some of these things you're doing are probably going to be great. The other things you should absolutely not be repeating these mistakes." And I thought about how likely it was that she walked by and happened to see that through the window and happened to look on the sharp television on the wall. And it's probably not very likely, and as we become, you know, we're remote and working remote the likelihood of those things happening maybe goes down. The idea of building a product that increases the likelihood or almost makes it seamless that you can find information relevant to what you were working on, even if you're new to that project or you haven't worked on it for a long time, is very, very key. So, within Luro, you can build a design system. You can add your styles. You can add your components, configure your tokens, and do all that, but you can also integrate those things that I was mentioning: prototyping, research, and testing. We also do an accessibility and performance through Lighthouse and give you metrics there. All of those things are associated to the pages that your site is comprised of. They're associated to the components that you use to build everything. So, we're sort of crossing the streams here. So, if you're going into imagine a button component and you're like, okay, the border-radius is four pixels. The type size is 16 pixels, and here's how you code it. We're putting in an actual button. The class is dot btn. That's all great. It's helping us build the button. But if you are asked by leadership or anyone, "Why did you decide this?" Or "What is the impact of design?" Or "What is the impact of the product team on our bottom line? How are you moving the needle? How are you helping us as an organization achieve?" The answer isn't, "Well, we made the border four pixels just like the design [chuckles] said." That's great. Good job. But I think having all of this information associated with design and associated with engineering not only makes us more informed as contributors to teams but it helps us to articulate the value of what we do on the daily in a much more broad organizational sense. So, you can say, "Well, we user-tested this, and we realized that if we took out these form elements from a signup flow, we get more signups by having fewer steps. And so we removed a step. We user-tested it before and after, and signups went up 30%." That's a much cooler answer than, "Well, our design system helps us be consistent," even though we know that that is vitally important, and it makes our app or our site feel much more cohesive, and it contributes to that sign up metric or a sales metric just as much. But having this data and associating it with a component so it's not something that you have to sort of...I guess it almost sounds subjective if you bring it up and say, "Well, we're moving faster, and we're selling more stuff." That's not great. But if you can link and say, "Well, here's a PowerPoint before," or "Here's a summary of a user test before and after. Here's real numbers," it helps you to portray yourself as the designer or engineer or product team member who thinks very deeply about these things, and it helps you to accurately portray yourself in that way. So, I went on a real tangent, but actually just there, I think I just was describing sort of the nuts and bolts of why we built Luro to not only be a design system tool but, like, what we kind of also call a product development tool, a product development system. So, it's extending the idea of design systems to the practice of building a product with an entire organization. WILL: That's really, really cool, and you did a great job explaining it. I'm excited to see it and see where it's going. I felt like a lot of what you were saying was the why you're doing stuff, why you chose, you know, X, Y, Z. Is that where the analytics and the tracking portion of Luro comes into play? TRENT: Yeah. I think that one thing we heard a lot from agencies or even just teams within an organization that are working on design systems is back to that articulating the value of maybe a design system or articulating the value of the work that we do as designers or product builders and similar to we've done a user test and these are the results, and sales or signups, or whatever the case may be, have improved. I think one of the key metrics for a design system is, is the component adopted? There are other ones, and people will mention those, things like, is it helping a team be quicker? So, if there's a design system team, and then there's multiple product teams within an organization, and they all want to work together, and they want to be able to take the components that they need and build their ideas quicker, prototype quicker, that's a great metric as well. But one that we find vitally important is, are the components live to users? And so, being able to track that has a lot of value. One, obviously, is that communicating that to the greater organization, saying, "You know, we've spun up a design system team. The card component is on 49% of pages. The button is on 100% of pages." And then if you're trying to be more tactical about how to improve the product or even just track down, you know, which components or which pages or which experiences aren't, I guess, consistent with the design system, you can say, well, "There's 49%, and there's 51% of pages that may or may not have the card component." And so, you can go find outdated components if you're trying to phase new ones in, and all of those sorts of things as well. So, the metrics are sort of great from a thematic sense, saying, this is the value that our design system is, you know, affording us as a business and the users are experiencing while they're using our app or our site. But then, also, you can drill down into these metrics and see, okay, the button is appearing here. I can click into pages and see views where it's being used on the page level and see, is it being used properly? Those kinds of things. You can track legacy components as well, so, for example, if we've rebranded the site that we all work on together and our old button was, like, dot button and the new button is dot BTN or however we would want to class those things. And you can use classes. You can use data attributes, all those kinds of things. But I would say we can track legacy along that. So, if your goal is to completely adopt the new design system across the entire network and products within six months or whatever the case may be, you know, month over month, week over week, you can check our, you know, line graphs and see, hopefully, the legacy occurrences of that going down over time. So, if, like, the button is being used less and less and then the dot BTN is being used more and more, you can see those sort of swap places. And so, what we have found is talking about things in sort of an objective or fuzzy way, saying, well, we're trying to ship this, and we're doing these inventories, and we're going through all the pages. And we're clicking around trying to find old things, or we're redesigning pages. But it's very, very difficult. This is just an instant quantification of where our components are manifesting in the product. So, what we do is, with Luro, you can give us...whether it's behind an authentication layer or not, we crawl web pages, first and foremost. So, you can give us a site. And this is all optional. You can spin out a design system without this. But we crawl the site, and then we will go ahead and do performance and accessibility scores for there. So, that's one way to itemize work, where you can just say, well, as an agency, we're going to work with this company, and we want to show them, like, the starting point and expose weak points on where we might be paying a lot of attention to. In the design or engineering phase, we need to improve the speed here. We have accessibility violations we need to think about, all that kind of stuff. And then, once you crawl those, you can add your design system, and then you can cross-reference those, and I kind of mentioned that. You can use CSS classes to do that. And so, you'd enter in dot BTN for button. We've already crawled your pages. And so, we can tell you every time that that class appears inside of any page inside of the network. So, it's this very, like, two-minute way to get a wealth of information that's shared and communicated with...the entire organization will benefit. Like I said, like, leadership they can get a sense of how the design system is being used and adopted, but also, the active teams working on things so that they can go find outliers and work on replacing those. VICTORIA: It's been over a year in your journey with Luro. What challenges do you see on the horizon? TRENT: I still think it is an adoption challenge. I think that, you know, one thing that we found is that a lot of teams, and this is going back to our agency days, but I sort of sort of still see this happening now is that building the design system, you know, let me separate these two things. I think designing components and building the design system in the sense of picking styles, and choosing fonts, and iterating upon something like a search box or, a footer, or a modal that's a lot of work. That's just design and product design and product development in general. But the act of, you know, creating the design system, maybe it's the documentation site, or however, we're communicating these standards across the organization. That part, to me, it's always kind of taken too much time and effort. And to be really candid, the amount of budget that's being allocated for those tasks is less. So, we're having a lot of users who are saying, "Well, I wasn't in charge of a design system. We had a team for that. We don't anymore. And now I'm responsible for it," or "The team's been combined, and I'm working on, like, three things at once." And so, something that's very, very crucial to us at Luro is to help with the struggle of spinning up a design system. For us, I fully believe that there are design systems that can be fully custom available to the public and need to have, you know, every page and view needs to be unique unto itself. But for Luro, the starting place that we get you with, you know, you can link in your Storybook. You can link in Figma components. You can add components manually and all those sorts of things. Where we can get you in a few minutes is really close. And then, if you started to fold in, you know, the idea of performance, accessibility, and then all of the other insights that you can then integrate, so if you're doing A/B testing or user testing and doing research, and you want to make sure that that's all involved inside of your design system, then it becomes a really attractive option. So, I think that decreasing the time it takes to get started and to spin up a design system is the number one thing we see people struggling with and the number one thing we want to bring. I kind of like to compare it to services like Netlify. Like, I remember I used to have to set up servers to demo things for clients, and it would take an hour, and I don't know what I'm doing. And I would break stuff, and they would have to help me fix it. So, then I'm bothering him. And then, now I'm just, you know, will either link to a CodePen or drag and drop a deployed URL from something like Netlify. And it's this amazing, almost like it feels like deploying is just as difficult as, like, sketching something out on a napkin. We want spinning up a design system to kind of feel that way so it's not so precious. You're not worried about...it is just easy to get started. And so, we're kind of integrating all these other tools that you use to make that easier and quicker because if you do have other things that you're working on and you need to move beyond that so that you can focus on prototyping, or designing, and building the actual components, you can do that. And you have that option as opposed to having to be mired in some of these other details. VICTORIA: It seems like change management and integrating change into larger organizations is always the biggest challenge [laughs], even for great innovations. And I'm curious: what types of people or groups have you found are quick to adopt this new method and really the right group for you to center your message on? TRENT: Yeah, it is...I was joking, I think, maybe before the podcast started, but it's, like, very ambitious because it's easy, I think, to say, "This tool is for designers. And if you're a designer, you can integrate your Figma, and then you'll have your components published to your team so that they can use them." And that's absolutely true. Like, if you're a designer, Luro is for you. If you're an engineer and you have just received components, and you need a way to document that and show your coded version alongside the design version and be able to collaborate with people in that sense, it is absolutely for you as well. So, you can see how it's almost like you almost have to frame Luro for individuals across the organization. So, it's one of those deals where...and we've kind of experimented with this with the marketing. And the way we've discussed it, we talked to lots of, you know, leadership, heads of product, CMOs, even CTOs, things like that. And so, it's like, if you're trying to get your entire organization to work better, to ship, you know, more effectively, then Luro is the tool for that as well because we're getting into knowledge retention via uploading. Like, my favorite story there is if you're an A/B tester, probably, and this is what we've experienced, is you run these tests. A lot of time and effort goes into building the prototypes for the test, whether that's you or an engineering team that's doing those things. This is one of the things we used to do as an agency. We would be brought on to prototype something totally new. We would test that alongside the existing experience. And an A/B tester, we'd work with them, and they would create, like, a PowerPoint or something that would explain the pros and cons and what should happen next and summarize the test. And that would live on that person's hard drive, whether it's on their computer or, like, a Dropbox or a OneDrive account. And no one ever thought about it ever again. You would just move on to the next test. But the amount of money spent on us to build the prototype and the amount of money spent on the SaaS to spin up the, like, A/B testing environment and all of these things, and then the time spent on the A/B tester to analyze the results and generate a PowerPoint it's not nothing. And so, one of the things that we find pretty appealing for leadership within Luro is the idea of integrating all of these tools and all this work that you do in mapping them to components so that when you pull up, for example, a button component, you'll see all the user tests that have been added over any period of time. So, if you were a new hire and you're trying to onboard, you can go interview everybody in the organization and ask them about the history of a button or a card component or the history of a sign-up page. But then, also, in a self-service way, you can just click into Luro, click a button, click a card, click to the sign-up page, any of those things, and find all that stuff I was mentioning earlier, whether it's a test, or research, or prototyping, or any kind of documents that have been written. These aren't the arguments that Dave or I might have around the actual border-radius value. Those are small things that probably should be lost in the firehose. But if we have learned an outline button with a stroke is performing way better than a solid-filled button or vice versa, that's important information that doesn't need to disappear in six weeks. So, that's the other kind of metric there is explaining kind of the holistic version, telling the holistic story of Luro to those types. And so, yeah, navigating that and trying to get, like, buy-in on a broad level is kind of what we're working on these days now. WILL: Sweet. So, I actually really like how it's almost like version control. You can see the history of what you've been working on. And I really like that because so many times...you're correct. When I go to Figma or anything, I'm like, why are we doing it this way? Oh, we made these decisions. Maybe in comments, you can kind of do it, but I think maybe that's the only place you can see the version control. So, I like that feature. Like you said, you can see the history of why you did something like that. TRENT: Yeah. And think about that, so if I am a front-end engineer and I receive a design and everyone thinks that, why are we doing it this way? I would hate to code something...I can do it. It's my job. But if I don't understand why, my feeling about work and maybe the quality of my work goes down, you know what I mean? I guess what I'm trying to say is, like, feeling like you understand, and you're lockstep with the entire team, and you understand what the goal is...what are we trying to do? What are we trying to achieve? Like, what have we reviewed that has made us believe this? And if you don't have that information, or if I don't have that information, like, there's some traction within the team, whether it's actual momentum forward and the amount of tickets that are being closed, or just the spirit of what we're doing, that the product is going to be diminished. These are all these little things that add up, up, up, up, up over time. So, being able to show this information to be able to access this information kind of passively. So, for example, if you got VS Code open and Luro open and you can see here's the user test from six weeks ago that shows us why we went with option B, you'll say, "Okay, cool. Even better." You know, you can review those things way before you get things handed to you. You know, it's much more kind of this utopian vision of an open, collaborative deal. And the way I would say that is it's, you know, we all kind of hand things off. So, of course, like, there's some version, even if it's like a micro waterfall that happens on a daily basis. We're all doing that. Like, somebody needs to be done with something to hand it off to something else, so we're not all up in each other's space all the time. But one thing that we like about Luro, whether we use Teams, or Slack, or whatever, it's not a real-time thing where I have to say, "Stop, look what I'm doing [laughs]. Come over here and look because I need you to know this." You can get notifications from Luro, but it's not something that is a context-switching demand type of a situation. So, the idea is if you're like, I'm wondering what's going on. I know this is coming up. I'd like to review. Or I could let you know and tell you, and just on your own time, you can go see this. So, separate from, like, the firehose of tickets and chats, you can see the actual product evolving and some of these, like, key milestone decisions on your own time and review them. And if they've happened before you even started on the project, then you can do that as well. WILL: I think that's probably where the breakdown between developers and designers that collab that's where it probably breaks down, whenever you're trying to get your tickets out as a developer. And then there's a change while you're working on it, and it's a complicated change, but you're still responsible for trying to get that ticket out in time. So, I think, like, what you're saying, you can get it beforehand. So, it sounds like, to me, Luro would be a huge help because you have to have developers and designers working together; if you don't, you're just in trouble in general. But anything that can help the relationship between the two I think, is amazing, and that's what I'm hearing whenever you're talking about Luro. It helps. It benefits that relationship. TRENT: Yeah, that even makes me think a little bit about the ongoing collaboration aspect. So, it's like, if something is shipped...or maybe let's go the agency scenario here. You've launched a site. You've launched a product. How do we know how it's performing? Of course, you'll have everybody...they're going to have analytics, and we'll be talking about that. And are signups up or down? But Luro will run tests. It'll continue to run component analytics. So, you can sense whether, like, somebody is changing a component. Or, you know, is the fully adopted design system not being utilized or being utilized less or more over time? But then, also, we're running, again, performance and accessibility metrics. So, we've seen it where we've shipped a product for a client. You know, we've had Luro running. We've sort of used that as our hub to collaborate over time. And then we'll notice that there's a giant performance spike and that, like, the page speed has gone way down. And we itemize issues and can point you to exactly the page that it's happening on and give you some insight into that. Of course, you could go through after you've worked with the client and run Lighthouse on every single page in your own time for fun, but that's not reality or fun. So, you'll get this information. And so, you almost...before we were telling people who were using Luro, we were kind of using it ourselves just to help ourselves do a better job. About a month into a project, we were able to email a customer, a former client, and say, "Hey, site's looking great. Amazing to see this. There's a 3-megabyte, 50-pixel avatar. Someone uploaded a giant image. It displays as 50 pixels. But somebody must have uploaded the full one to your homepage, and your page speed score tanked." They're like, "Oh, wow, they must [laughs] be monitoring us and checking in on us every day." We love them dearly, but we were not doing that. We were using Luro off to the side. So, there is this other aspect of just sort of monitoring and making sure things stay, you know, as they were or better once we ship things and move forward to the next. VICTORIA: That's really interesting. And I'm excited to explore more on my own about Luro. As we're coming towards the end of our time today, I wanted to give you one last chance to shout out anything else that you would like to promote today. TRENT: Oh, that's it [laughs], luroapp.com, you know, that's the main thing. Check out component analytics. We have a YouTube channel, and I would say that's probably the easiest, a lot of effort, even though the videos maybe I'd give myself an A-minus or a solid A, not an A-plus on video production. I'm trying to get better. But explaining just, like, how to set things up. There's, like, a one-minute, like, what is all this? So, if you want to see all the things that I've been trying to describe, hopefully well on the podcast [chuckles], you can see that really well. So, I'd say Luro App and then the YouTube channel. We've got, like, five, six videos or so that really kind of help get you into maybe what your use case would be and to show you how easily things are set up. VICTORIA: Great. Thank you so much for joining us today, Trent, and for sharing about your story and about the product that you've been building. TRENT: Yeah. Thank you for having me. This has been great fun. VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. WILL: And you can find me on Twitter @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Let's discuss the process of deploying Next.js applications using Vercel and explore the benefits of exploring different platforms and paradigms. We dive into the process of getting a project live with Vercel but discuss comparisons in the WordPress world, the complicated nature of deployment in WordPress, how different platforms handle them, and the role continuous integration plays into all of it.A full transcript of the episode is available on the website. Watch the video podcast on YouTube and subscribe to our channel and newsletter to hear about episodes (and more) first!- Vercel – https://vercel.com/- What is utility-first CSS – https://heydonworks.com/article/what-is-utility-first-css/- Brian's website – https://www.briancoords.com- Aurooba's website – https://aurooba.com (00:00) - S02E11 - Next.js Part 5 (00:37) - Familar tools are easier to wrap your head around (03:22) - On Deployment in the WordPress space (09:02) - First Look at Vercel Deployment (10:38) - Environment Variables (12:56) - Errors on first Vercel Deployment (13:31) - Using Vercel CLI (16:16) - How Deployments work (17:18) - Thinking in PRs (17:57) - Exploring the Deployment UI in Vercel (18:40) - Deployment UIs around the web (19:15) - Comparing to Netlify (20:21) - Taking your Vercel Project live (22:56) - Comparing to WordPress Deployments (24:56) - Prebuilt Deployments with Vercel (25:26) - Can you get to this level of deployment in WordPress? (29:29) - Continuous Integration (32:19) - The Advantage of continuous integration tools (34:22) - The value of not committing built files to the repo (35:29) - Cross-pollination between WordPress and other spaces (36:31) - Web Development is more complicated now (37:13) - The slow modernization of WordPress (37:50) - Takeaways from the Next.js Series (41:09) - CSS in JavaScript: a tangent (44:09) - What's Next?

Dansk iværksætter har skabt en unicorn i USA. Hvordan gjorde han? Danmark hungrer efter enhjørninger, men vores enhjørningeføl stikker af til udlandet. Vi refererer naturligvis til begrebet “unicorn”, som det bliver brugt om start-up virksomheder, der har vokset sig store og stærke. Har man en markedsværdi på over én milliard dollar, kaldes man en unicorn.  Det betyder arbejdspladser, skatteindtægter og afkast til de investorer, som har været fødselshjælpere for føllet. Danmark har ifølge Dansk Erhverv fostret 13 unicorns, men problemet er, at de flytter tidligt hjemmefra, så Danmark høster ikke gevinsten af deres vækst.  Men hvordan bygger man egentlig en unicorn? Det fortæller iværksætteren Christian Bach, der sammen med en ungdomsven har skabt firmaet Netlify i USA. Techtopia får hans udviklingshistorie fra ide til udvikling af teknologi og det hårde arbejde med at skaffe investorer, der kan sikre, at virksomheden skalerer til en levedygtig størrelse. En fuldvoksen enhjørning. Link: https://www.netlify.com

This Friday we're doing a special crossover event in SF with of SemiAnalysis (previous guest!), and we will do a live podcast on site. RSVP here. Also join us on June 25-27 for the biggest AI Engineer conference of the year!Replicate is one of the most popular AI inference providers, reporting over 2 million users as of their $40m Series B with a16z. But how did they get there? The Definitive Replicate Story (warts and all)Their overnight success took 5 years of building, and it all started with arXiv Vanity, which was a 2017 vacation project that scrapes arXiv PDFs and re-renders them into semantic web pages that reflow nicely with better typography and whitespace. From there, Ben and Andreas' idea was to build tools to make ML research more robust and reproducible by making it easy to share code artefacts alongside papers. They had previously created Fig, which made it easy to spin up dev environments; it was eventually acquired by Docker and turned into `docker-compose`, the industry standard way to define services from containerized applications. 2019: CogThe first iteration of Replicate was a Fig-equivalent for ML workloads which they called Cog; it made it easy for researchers to package all their work and share it with peers for review and reproducibility. But they found that researchers were terrible users: they'd do all this work for a paper, publish it, and then never return to it again. “We talked to a bunch of researchers and they really wanted that.... But how the hell is this a business, you know, like how are we even going to make any money out of this? …So we went and talked to a bunch of companies trying to sell them something which didn't exist. So we're like, hey, do you want a way to share research inside your company so that other researchers or say like the product manager can test out the machine learning model? They're like, maybe. Do you want like a deployment platform for deploying models? Do you want a central place for versioning models? We were trying to think of lots of different products we could sell that were related to this thing…So we then got halfway through our YC batch. We hadn't built a product. We had no users. We had no idea what our business was going to be because we couldn't get anybody to like buy something which didn't exist. And actually there was quite a way through our, I think it was like two thirds the way through our YC batch or something. And we're like, okay, well we're kind of screwed now because we don't have anything to show at demo day.”The team graduated YCombinator with no customers, no product and nothing to demo - which was fine because demo day got canceled as the YC W'20 class graduated right into the pandemic. The team spent the next year exploring and building Covid tools.2021: CLIP + GAN = PixRayBy 2021, OpenAI released CLIP. Overnight dozens of Discord servers got spun up to hack on CLIP + GANs. Unlike academic researchers, this community was constantly releasing new checkpoints and builds of models. PixRay was one of the first models being built on Replicate, and it quickly started taking over the community. Chris Dixon has a famous 2010 post titled “The next big thing will start out looking like a toy”; image generation would have definitely felt like a toy in 2021, but it gave Replicate its initial boost.2022: Stable DiffusionIn August 2022 Stable Diffusion came out, and all the work they had been doing to build this infrastructure for CLIP / GANs models became the best way for people to share their StableDiffusion fine-tunes:And like the first week we saw people making animation models out of it. We saw people make game texture models that use circular convolutions to make repeatable textures. We saw a few weeks later, people were fine tuning it so you could put your face in these models and all of these other ways. […] So tons of product builders wanted to build stuff with it. And we were just sitting in there in the middle, as the interface layer between all these people who wanted to build, and all these machine learning experts who were building cool models. And that's really where it took off. Incredible supply, incredible demand, and we were just in the middle.(Stable Diffusion also spawned Latent Space as a newsletter)The landing page paved the cowpath for the intense interest in diffusion model APIs.2023: Llama & other multimodal LLMsBy 2023, Replicate's growing visibility in the Stable Diffusion indie hacker community came from top AI hackers like Pieter Levels and Danny Postmaa, each making millions off their AI apps:Meta then released LLaMA 1 and 2 (our coverage of it), greatly pushing forward the SOTA open source model landscape. Demand for text LLMs and other modalities rose, and Replicate broadened its focus accordingly, culminating in a $18m Series A and $40m Series B from a16z (at a $350m valuation).Building standards for the AI worldNow that the industry is evolving from toys to enterprise use cases, all these companies are working to set standards for their own space. We cover this at ~45 mins in the podcast. Some examples:* LangChain has been trying to establish "chain” as the standard mental models when putting multiple prompts and models together, and the “LangChain Expression Language” to go with it. (Our episode with Harrison)* LLamaHub for packaging RAG utilities. (Our episode with Jerry)* Ollama's Modelfile to define runtimes for different model architectures. These are usually targeted at local inference. * Cog (by Replicate) to create environments to which you can easily attach CUDA devices and make it easy to spin up inference on remote servers. * GGUF as the filetype ggml-based executors. None of them have really broken out yet, but this is going to become a fiercer competition as the market matures. Full Video PodcastAs a reminder, all Latent Space pods now come in full video on our YouTube, with bonus content that we cut for time!Show Notes* Ben Firshman* Replicate* Free $10 credit for Latent Space readers* Andreas Jansson (Ben's co-founder)* Charlie Holtz (Replicate's Hacker in Residence)* Fig (now Docker Compose)* Command Line Interface Guidelines (clig)* Apple Human Interface Guidelines* arXiv Vanity* Open Interpreter* PixRay* SF Compute* Big Sleep by Advadnoun* VQGAN-CLIP by Rivers Have WingsTimestamps* [00:00:00] Introductions* [00:01:17] Low latency is all you need* [00:04:08] Evolution of CLIs* [00:05:59] How building ArxivVanity led to Replicate* [00:11:37] Making ML research replicable with containers* [00:17:22] Doing YC in 2020 and pivoting to tools for COVID* [00:20:22] Launching the first version of Replicate* [00:25:51] Embracing the generative image community* [00:28:04] Getting reverse engineered into an API product* [00:31:25] Growing to 2 million users* [00:34:29] Indie vs Enterprise customers* [00:37:09] How Unsplash uses Replicate* [00:38:29] Learnings from Docker that went into Cog* [00:45:25] Creating AI standards* [00:50:05] Replicate's compute availability* [00:53:55] Fixing GPU waste* [01:00:39] What's open source AI?* [01:04:46] Building for AI engineers* [01:06:41] Hiring at ReplicateThis summary covers the full range of topics discussed throughout the episode, providing a comprehensive overview of the content and insights shared.TranscriptAlessio [00:00:00]: Hey everyone, welcome to the Latent Space podcast. This is Alessio, partner and CTO in Residence at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol AI.Swyx [00:00:14]: Hey, and today we have Ben Firshman in the studio. Welcome Ben.Ben [00:00:18]: Hey, good to be here.Swyx [00:00:19]: Ben, you're a co-founder and CEO of Replicate. Before that, you were most notably founder of Fig, which became Docker Compose. You also did a couple of other things before that, but that's what a lot of people know you for. What should people know about you that, you know, outside of your, your sort of LinkedIn profile?Ben [00:00:35]: Yeah. Good question. I think I'm a builder and tinkerer, like in a very broad sense. And I love using my hands to make things. So like I work on, you know, things may be a bit closer to tech, like electronics. I also like build things out of wood and I like fix cars and I fix my bike and build bicycles and all this kind of stuff. And there's so much, I think I've learned from transferable skills, from just like working in the real world to building things, building things in software. And you know, it's so much about being a builder, both in real life and, and in software that crosses over.Swyx [00:01:11]: Is there a real world analogy that you use often when you're thinking about like a code architecture or problem?Ben [00:01:17]: I like to build software tools as if they were something real. So I wrote this thing called the command line interface guidelines, which was a bit like sort of the Mac human interface guidelines, but for command line interfaces, I did it with the guy I created Docker Compose with and a few other people. And I think something in there, I think I described that your command line interface should feel like a big iron machine where you pull a lever and it goes clunk and like things should respond within like 50 milliseconds as if it was like a real life thing. And like another analogy here is like in the real life, you know, when you press a button on an electronic device and it's like a soft switch and you press it and nothing happens and there's no physical feedback of anything happening, then like half a second later, something happens. Like that's how a lot of software feels, but instead like software should feel more like something that's real where you touch, you pull a physical lever and the physical lever moves, you know, and I've taken that lesson of kind of human interface to, to software a ton. You know, it's all about kind of low latency of feeling, things feeling really solid and robust, both the command lines and, and user interfaces as well.Swyx [00:02:22]: And how did you operationalize that for Fig or Docker?Ben [00:02:27]: A lot of it's just low latency. Actually, we didn't do it very well for Fig in the first place. We used Python, which was a big mistake where Python's really hard to get booting up fast because you have to load up the whole Python runtime before it can run anything. Okay. Go is much better at this where like Go just instantly starts.Swyx [00:02:45]: You have to be under 500 milliseconds to start up?Ben [00:02:48]: Yeah, effectively. I mean, I mean, you know, perception of human things being immediate is, you know, something like a hundred milliseconds. So anything like that is, is yeah, good enough.Swyx [00:02:57]: Yeah. Also, I should mention, since we're talking about your side projects, well, one thing is I am maybe one of a few fellow people who have actually written something about CLI design principles because I was in charge of the Netlify CLI back in the day and had many thoughts. One of my fun thoughts, I'll just share it in case you have thoughts, is I think CLIs are effectively starting points for scripts that are then run. And the moment one of the script's preconditions are not fulfilled, typically they end. So the CLI developer will just exit the program. And the way that I designed, I really wanted to create the Netlify dev workflow was for it to be kind of a state machine that would resolve itself. If it detected a precondition wasn't fulfilled, it would actually delegate to a subprogram that would then fulfill that precondition, asking for more info or waiting until a condition is fulfilled. Then it would go back to the original flow and continue that. I don't know if that was ever tried or is there a more formal definition of it? Because I just came up with it randomly. But it felt like the beginnings of AI in the sense that when you run a CLI command, you have an intent to do something and you may not have given the CLI all the things that it needs to do, to execute that intent. So that was my two cents.Ben [00:04:08]: Yeah, that reminds me of a thing we sort of thought about when writing the CLI guidelines, where CLIs were designed in a world where the CLI was really a programming environment and it's primarily designed for machines to use all of these commands and scripts. Whereas over time, the CLI has evolved to humans. It was back in a world where the primary way of using computers was writing shell scripts effectively. We've transitioned to a world where actually humans are using CLI programs much more than they used to. And the current sort of best practices about how Unix was designed, there's lots of design documents about Unix from the 70s and 80s, where they say things like, command line commands should not output anything on success. It should be completely silent, which makes sense if you're using it in a shell script. But if a user is using that, it just looks like it's broken. If you type copy and it just doesn't say anything, you assume that it didn't work as a new user. I think what's really interesting about the CLI is that it's actually a really good, to your point, it's a really good user interface where it can be like a conversation, where it feels like you're, instead of just like you telling the computer to do this thing and either silently succeeding or saying, no, you did, failed, it can guide you in the right direction and tell you what your intent might be, and that kind of thing in a way that's actually, it's almost more natural to a CLI than it is in a graphical user interface because it feels like this back and forth with the computer, almost funnily like a language model. So I think there's some interesting intersection of CLIs and language models actually being very sort of closely related and a good fit for each other.Swyx [00:05:59]: Yeah, I'll say one of the surprises from last year, I worked on a coding agent, but I think the most successful coding agent of my cohort was Open Interpreter, which was a CLI implementation. And I have chronically, even as a CLI person, I have chronically underestimated the CLI as a useful interface. You also developed ArchiveVanity, which you recently retired after a glorious seven years.Ben [00:06:22]: Something like that.Swyx [00:06:23]: Which is nice, I guess, HTML PDFs.Ben [00:06:27]: Yeah, that was actually the start of where Replicate came from. Okay, we can tell that story. So when I quit Docker, I got really interested in science infrastructure, just as like a problem area, because it is like science has created so much progress in the world. The fact that we're, you know, can talk to each other on a podcast and we use computers and the fact that we're alive is probably thanks to medical research, you know. But science is just like completely archaic and broken and it's like 19th century processes that just happen to be copied to the internet rather than take into account that, you know, we can transfer information at the speed of light now. And the whole way science is funded and all this kind of thing is all kind of very broken. And there's just so much potential for making science work better. And I realized that I wasn't a scientist and I didn't really have any time to go and get a PhD and become a researcher, but I'm a tool builder and I could make existing scientists better at their job. And if I could make like a bunch of scientists a little bit better at their job, maybe that's the kind of equivalent of being a researcher. So one particular thing I dialed in on is just how science is disseminated in that all of these PDFs, quite often behind paywalls, you know, on the internet.Swyx [00:07:34]: And that's a whole thing because it's funded by national grants, government grants, then they're put behind paywalls. Yeah, exactly.Ben [00:07:40]: That's like a whole, yeah, I could talk for hours about that. But the particular thing we got dialed in on was, interestingly, these PDFs are also, there's a bunch of open science that happens as well. So math, physics, computer science, machine learning, notably, is all published on the archive, which is actually a surprisingly old institution.Swyx [00:08:00]: Some random Cornell.Ben [00:08:01]: Yeah, it was just like somebody in Cornell who started a mailing list in the 80s. And then when the web was invented, they built a web interface around it. Like it's super old.Swyx [00:08:11]: And it's like kind of like a user group thing, right? That's why they're all these like numbers and stuff.Ben [00:08:15]: Yeah, exactly. Like it's a bit like something, yeah. That's where all basically all of math, physics and computer science happens. But it's still PDFs published to this thing. Yeah, which is just so infuriating. The web was invented at CERN, a physics institution, to share academic writing. Like there are figure tags, there are like author tags, there are heading tags, there are site tags. You know, hyperlinks are effectively citations because you want to link to another academic paper. But instead, you have to like copy and paste these things and try and get around paywalls. Like it's absurd, you know. And now we have like social media and things, but still like academic papers as PDFs, you know. This is not what the web was for. So anyway, I got really frustrated with that. And I went on vacation with my old friend Andreas. So we were, we used to work together in London on a startup, at somebody else's startup. And we were just on vacation in Greece for fun. And he was like trying to read a machine learning paper on his phone, you know, like we had to like zoom in and like scroll line by line on the PDF. And he was like, this is f*****g stupid. So I was like, I know, like this is something we discovered our mutual hatred for this, you know. And we spent our vacation sitting by the pool, like making latex to HTML, like converters, making the first version of Archive Vanity. Anyway, that was up then a whole thing. And the story, we shut it down recently because they caught the eye of Archive. They were like, oh, this is great. We just haven't had the time to work on this. And what's tragic about the Archive, it's like this project of Cornell that's like, they can barely scrounge together enough money to survive. I think it might be better funded now than it was when we were, we were collaborating with them. And compared to these like scientific journals, it's just that this is actually where the work happens. But they just have a fraction of the money that like these big scientific journals have, which is just so tragic. But anyway, they were like, yeah, this is great. We can't afford to like do it, but do you want to like as a volunteer integrate arXiv Vanity into arXiv?Swyx [00:10:05]: Oh, you did the work.Ben [00:10:06]: We didn't do the work. We started doing the work. We did some. I think we worked on this for like a few months to actually get it integrated into arXiv. And then we got like distracted by Replicate. So a guy called Dan picked up the work and made it happen. Like somebody who works on one of the, the piece of the libraries that powers arXiv Vanity. Okay.Swyx [00:10:26]: And the relationship with arXiv Sanity?Ben [00:10:28]: None.Swyx [00:10:30]: Did you predate them? I actually don't know the lineage.Ben [00:10:32]: We were after, we both were both users of arXiv Sanity, which is like a sort of arXiv...Ben [00:10:37]: Which is Andre's RecSys on top of arXiv.Ben [00:10:40]: Yeah. Yeah. And we were both users of that. And I think we were trying to come up with a working name for arXiv and Andreas just like cracked a joke of like, oh, let's call it arXiv Vanity. Let's make the papers look nice. Yeah. Yeah. And that was the working name and it just stuck.Swyx [00:10:52]: Got it.Ben [00:10:53]: Got it.Alessio [00:10:54]: Yeah. And then from there, tell us more about why you got distracted, right? So Replicate, maybe it feels like an overnight success to a lot of people, but you've been building this since 2019. Yeah.Ben [00:11:04]: So what prompted the start?Alessio [00:11:05]: And we've been collaborating for even longer.Ben [00:11:07]: So we created arXiv Vanity in 2017. So in some sense, we've been doing this almost like six, seven years now, a classic seven year.Swyx [00:11:16]: Overnight success.Ben [00:11:17]: Yeah. Yes. We did arXiv Vanity and then worked on a bunch of like surrounding projects. I was still like really interested in science publishing at that point. And I'm trying to remember, because I tell a lot of like the condensed story to people because I can't really tell like a seven year history. So I'm trying to figure out like the right. Oh, we got room. The right length.Swyx [00:11:35]: We want to nail the definitive Replicate story here.Ben [00:11:37]: One thing that's really interesting about these machine learning papers is that these machine learning papers are published on arXiv and a lot of them are actual fundamental research. So like should be like prose describing a theory. But a lot of them are just running pieces of software that like a machine learning researcher made that did something, you know, it was like an image classification model or something. And they managed to make an image classification model that was better than the existing state of the art. And they've made an actual running piece of software that does image segmentation. And then what they had to do is they then had to take that piece of software and write it up as prose and math in a PDF. And what's frustrating about that is like if you want to. So this was like Andreas is, Andreas was a machine learning engineer at Spotify. And some of his job was like he did pure research as well. Like he did a PhD and he was doing a lot of stuff internally. But part of his job was also being an engineer and taking some of these existing things that people have made and published and trying to apply them to actual problems at Spotify. And he was like, you know, you get given a paper which like describes roughly how the model works. It's probably listing lots of crucial information. There's sometimes code on GitHub. More and more there's code on GitHub. But back then it was kind of relatively rare. But it's quite often just like scrappy research code and didn't actually run. And, you know, there was maybe the weights that were on Google Drive, but they accidentally deleted the weights of Google Drive, you know, and it was like really hard to like take this stuff and actually use it for real things. We just started talking together about like his problems at Spotify and I connected this back to my work at Docker as well. I was like, oh, this is what we created containers for. You know, we solved this problem for normal software by putting the thing inside a container so you could ship it around and it kept on running. So we were sort of hypothesizing about like, hmm, what if we put machine learning models inside containers so they could actually be shipped around and they could be defined in like some production ready formats and other researchers could run them to generate baselines and you could people who wanted to actually apply them to real problems in the world could just pick up the container and run it, you know. And we then thought this is quite whether it gets normally in this part of the story I skip forward to be like and then we created cog this container stuff for machine learning models and we created Replicate, the place for people to publish these machine learning models. But there's actually like two or three years between that. The thing we then got dialed into was Andreas was like, what if there was a CI system for machine learning? It's like one of the things he really struggled with as a researcher is generating baselines. So when like he's writing a paper, he needs to like get like five other models that are existing work and get them running.Swyx [00:14:21]: On the same evals.Ben [00:14:22]: Exactly, on the same evals so you can compare apples to apples because you can't trust the numbers in the paper.Swyx [00:14:26]: So you can be Google and just publish them anyway.Ben [00:14:31]: So I think this was coming from the thinking of like there should be containers for machine learning, but why are people going to use that? Okay, maybe we can create a supply of containers by like creating this useful tool for researchers. And the useful tool was like, let's get researchers to package up their models and push them to the central place where we run a standard set of benchmarks across the models so that you can trust those results and you can compare these models apples to apples and for like a researcher for Andreas, like doing a new piece of research, he could trust those numbers and he could like pull down those models, confirm it on his machine, use the standard benchmark to then measure his model and you know, all this kind of stuff. And so we started building that. That's what we applied to YC with, got into YC and we started sort of building a prototype of this. And then this is like where it all starts to fall apart. We were like, okay, that sounds great. And we talked to a bunch of researchers and they really wanted that and that sounds brilliant. That's a great way to create a supply of like models on this research platform. But how the hell is this a business, you know, like how are we even going to make any money out of this? And we're like, oh s**t, that's like the, that's the real unknown here of like what the business is. So we thought it would be a really good idea to like, okay, before we get too deep into this, let's try and like reduce the risk of this turning into a business. So let's try and like research what the business could be for this research tool effectively. So we went and talked to a bunch of companies trying to sell them something which didn't exist. So we're like, hey, do you want a way to share research inside your company so that other researchers or say like the product manager can test out the machine learning model? They're like, maybe. And we were like, do you want like a deployment platform for deploying models? Like, do you want like a central place for versioning models? Like we're trying to think of like lots of different like products we could sell that were like related to this thing. And terrible idea. Like we're not sales people and like people don't want to buy something that doesn't exist. I think some people can pull this off, but we were just like, you know, a bunch of product people, products and engineer people, and we just like couldn't pull this off. So we then got halfway through our YC batch. We hadn't built a product. We had no users. We had no idea what our business was going to be because we couldn't get anybody to like buy something which didn't exist. And actually there was quite a way through our, I think it was like two thirds the way through our YC batch or something. And we're like, okay, well we're kind of screwed now because we don't have anything to show at demo day. And then we then like tried to figure out, okay, what can we build in like two weeks that'll be something. So we like desperately tried to, I can't remember what we've tried to build at that point. And then two weeks before demo day, I just remember it was all, we were going down to Mountain View every week for dinners and we got called on to like an all hands Zoom call, which was super weird. We're like, what's going on? And they were like, don't come to dinner tomorrow. And we realized, we kind of looked at the news and we were like, oh, there's a pandemic going on. We were like so deep in our startup. We were just like completely oblivious to what was going on around us.Swyx [00:17:20]: Was this Jan or Feb 2020?Ben [00:17:22]: This was March 2020. March 2020. 2020.Swyx [00:17:25]: Yeah. Because I remember Silicon Valley at the time was early to COVID. Like they started locking down a lot faster than the rest of the US.Ben [00:17:32]: Yeah, exactly. And I remember, yeah, soon after that, like there was the San Francisco lockdowns and then like the YC batch just like stopped. There wasn't demo day and it was in a sense a blessing for us because we just kind ofSwyx [00:17:43]: In the normal course of events, you're actually allowed to defer to a future demo day. Yeah.Ben [00:17:51]: So we didn't even take any defer because it just kind of didn't happen.Swyx [00:17:55]: So was YC helpful?Ben [00:17:57]: Yes. We completely screwed up the batch and that was our fault. I think the thing that YC has become incredibly valuable for us has been after YC. I think there was a reason why we couldn't, didn't need to do YC to start with because we were quite experienced. We had done some startups before. We were kind of well connected with VCs, you know, it was relatively easy to raise money because we were like a known quantity. You know, if you go to a VC and be like, Hey, I made this piece of-Swyx [00:18:24]: It's Docker Compose for AI.Ben [00:18:26]: Exactly. Yeah. And like, you know, people can pattern match like that and they can have some trust, you know what you're doing. Whereas it's much harder for people straight out of college and that's where like YC sweet spot is like helping people straight out of college who are super promising, like figure out how to do that.Swyx [00:18:40]: No credentials.Ben [00:18:41]: Yeah, exactly. We don't need that. But the thing that's been incredibly useful for us since YC has been, this was actually, I think, so Docker was a YC company and Solomon, the founder of Docker, I think told me this. He was like, a lot of people underestimate the value of YC after you finish the batch. And his biggest regret was like not staying in touch with YC. I might be misattributing this, but I think it was him. And so we made a point of that. And we just stayed in touch with our batch partner, who Jared at YC has been fantastic.Ben [00:19:10]: Jared Friedman. All of like the team at YC, there was the growth team at YC when they were still there and they've been super helpful. And two things have been super helpful about that is like raising money, like they just know exactly how to raise money. And they've been super helpful during that process in all of our rounds, like we've done three rounds since we did YC and they've been super helpful during the whole process. And also just like reaching a ton of customers. So like the magic of YC is that you have all of, like there's thousands of YC companies, I think, on the order of thousands, I think. And they're all of your first customers. And they're like super helpful, super receptive, really want to like try out new things. You have like a warm intro to every one of them basically. And there's this mailing list where you can post about updates to your products, which is like really receptive. And that's just been fantastic for us. Like we've just like got so many of our users and customers through YC. Yeah.Swyx [00:20:00]: Well, so the classic criticism or the sort of, you know, pushback is people don't buy you because you are both from YC. But at least they'll open the email. Right. Like that's the... Okay.Ben [00:20:13]: Yeah. Yeah. Yeah.Swyx [00:20:16]: So that's been a really, really positive experience for us. And sorry, I interrupted with the YC question. Like you were, you make it, you just made it out of the YC, survived the pandemic.Ben [00:20:22]: I'll try and condense this a little bit. Then we started building tools for COVID weirdly. We were like, okay, we don't have a startup. We haven't figured out anything. What's the most useful thing we could be doing right now?Swyx [00:20:32]: Save lives.Ben [00:20:33]: So yeah. Let's try and save lives. I think we failed at that as well. We had a bunch of products that didn't really go anywhere. We kind of worked on, yeah, a bunch of stuff like contact tracing, which turned out didn't really be a useful thing. Sort of Andreas worked on like a door dash for like people delivering food to people who are vulnerable. What else did we do? The meta problem of like helping people direct their efforts to what was most useful and a few other things like that. It didn't really go anywhere. So we're like, okay, this is not really working either. We were considering actually just like doing like work for COVID. We have this decision document early on in our company, which is like, should we become a like government app contracting shop? We decided no.Swyx [00:21:11]: Because you also did work for the gov.uk. Yeah, exactly.Ben [00:21:14]: We had experience like doing some like-Swyx [00:21:17]: And the Guardian and all that.Ben [00:21:18]: Yeah. For like government stuff. And we were just like really good at building stuff. Like we were just like product people. Like I was like the front end product side and Andreas was the back end side. So we were just like a product. And we were working with a designer at the time, a guy called Mark, who did our early designs for Replicate. And we were like, hey, what if we just team up and like become and build stuff? And yeah, we gave up on that in the end for, I can't remember the details. So we went back to machine learning. And then we were like, well, we're not really sure if this is going to work. And one of my most painful experiences from previous startups is shutting them down. Like when you realize it's not really working and having to shut it down, it's like a ton of work and it's people hate you and it's just sort of, you know. So we were like, how can we make something we don't have to shut down? And even better, how can we make something that won't page us in the middle of the night? So we made an open source project. We made a thing which was an open source Weights and Biases, because we had this theory that like people want open source tools. There should be like an open source, like version control, experiment tracking like thing. And it was intuitive to us and we're like, oh, we're software developers and we like command line tools. Like everyone loves command line tools and open source stuff, but machine learning researchers just really didn't care. Like they just wanted to click on buttons. They didn't mind that it was a cloud service. It was all very visual as well, that you need lots of graphs and charts and stuff like this. So it wasn't right. Like it was right. We actually were building something that Andreas made at Spotify for just like saving experiments to cloud storage automatically, but other people didn't really want this. So we kind of gave up on that. And then that was actually originally called Replicate and we renamed that out of the way. So it's now called Keepsake and I think some people still use it. Then we sort of came back, we looped back to our original idea. So we were like, oh, maybe there was a thing in that thing we were originally sort of thinking about of like researchers sharing their work and containers for machine learning models. So we just built that. And at that point we were kind of running out of the YC money. So we were like, okay, this like feels good though. Let's like give this a shot. So that was the point we raised a seed round. We raised seed round. Pre-launch. We raised pre-launch and pre-team. It was an idea basically. We had a little prototype. It was just an idea and a team. But we were like, okay, like, you know, bootstrapping this thing is getting hard. So let's actually raise some money. Then we made Cog and Replicate. It initially didn't have APIs, interestingly. It was just the bit that I was talking about before of helping researchers share their work. So it was a way for researchers to put their work on a webpage such that other people could try it out and so that you could download the Docker container. We cut the benchmarks thing of it because we thought that was just like too complicated. But it had a Docker container that like, you know, Andreas in a past life could download and run with his benchmark and you could compare all these models apples to apples. So that was like the theory behind it. That kind of started to work. It was like still when like, you know, it was long time pre-AI hype and there was lots of interesting stuff going on, but it was very much in like the classic deep learning era. So sort of image segmentation models and sentiment analysis and all these kinds of things, you know, that people were using, that we're using deep learning models for. And we were very much building for research because all of this stuff was happening in research institutions, you know, the sort of people who'd be publishing to archive. So we were creating an accompanying material for their models, basically, you know, they wanted a demo for their models and we were creating a company material for it. What was funny about that is they were like not very good users. Like they were, they were doing great work obviously, but, but the way that research worked is that they, they just made like one thing every six months and they just fired and forget it, forgot it. Like they, they published this piece of paper and like, done, I've, I've published it. So they like output it to Replicate and then they just stopped using Replicate. You know, they were like once every six monthly users and that wasn't great for us, but we stumbled across this early community. This was early 2021 when OpenAI created this, created CLIP and people started smushing CLIP and GANs together to produce image generation models. And this started with, you know, it was just a bunch of like tinkerers on Discord, basically. There was an early model called Big Sleep by Advadnoun. And then there was VQGAN Clip, which was like a bit more popular by Rivers Have Wings. And it was all just people like tinkering on stuff in Colabs and it was very dynamic and it was people just making copies of co-labs and playing around with things and forking in. And to me this, I saw this and I was like, oh, this feels like open source software, like so much more than the research world where like people are publishing these papers.Swyx [00:25:48]: You don't know their real names and it's just like a Discord.Ben [00:25:51]: Yeah, exactly. But crucially, it was like people were tinkering and forking and things were moving really fast and it just felt like this creative, dynamic, collaborative community in a way that research wasn't really, like it was still stuck in this kind of six month publication cycle. So we just kind of latched onto that and started building for this community. And you know, a lot of those early models were published on Replicate. I think the first one that was really primarily on Replicate was one called Pixray, which was sort of mid 2021 and it had a really cool like pixel art output, but it also just like produced general, you know, the sort of, they weren't like crisp in images, but they were quite aesthetically pleasing, like some of these early image generation models. And you know, that was like published primarily on Replicate and then a few other models around that were like published on Replicate. And that's where we really started to find our early community and like where we really found like, oh, we've actually built a thing that people want and they were great users as well. And people really want to try out these models. Lots of people were like running the models on Replicate. We still didn't have APIs though, interestingly, and this is like another like really complicated part of the story. We had no idea what a business model was still at this point. I don't think people could even pay for it. You know, it was just like these web forms where people could run the model.Swyx [00:27:06]: Just for historical interest, which discords were they and how did you find them? Was this the Lion Discord? Yeah, Lion. This is Eleuther.Ben [00:27:12]: Eleuther, yeah. It was the Eleuther one. These two, right? There was a channel where Viki Gangklep, this was early 2021, where Viki Gangklep was set up as a Discord bot. I just remember being completely just like captivated by this thing. I was just like playing around with it all afternoon and like the sort of thing. In Discord. Oh s**t, it's 2am. You know, yeah.Swyx [00:27:33]: This is the beginnings of Midjourney.Ben [00:27:34]: Yeah, exactly. And Stability. It was the start of Midjourney. And you know, it's where that kind of user interface came from. Like what's beautiful about the user interface is like you could see what other people are doing. And you could riff off other people's ideas. And it was just so much fun to just like play around with this in like a channel full of a hundred people. And yeah, that just like completely captivated me and I'm like, okay, this is something, you know. So like we should get these things on Replicate. Yeah, that's where that all came from.Swyx [00:28:00]: And then you moved on to, so was it APIs next or was it Stable Diffusion next?Ben [00:28:04]: It was APIs next. And the APIs happened because one of our users, our web form had like an internal API for making the web form work, like with an API that was called from JavaScript. And somebody like reverse engineered that to start generating images with a script. You know, they did like, you know, Web Inspector Coffee is Carl, like figured out what the API request was. And it wasn't secured or anything.Swyx [00:28:28]: Of course not.Ben [00:28:29]: They started generating a bunch of images and like we got tons of traffic and like what's going on? And I think like a sort of usual reaction to that would be like, hey, you're abusing our API and to shut them down. And instead we're like, oh, this is interesting. Like people want to run these models. So we documented the API in a Notion document, like our internal API in a Notion document and like message this person being like, hey, you seem to have found our API. Here's the documentation. That'll be like a thousand bucks a month, please, with a straight form, like we just click some buttons to make. And they were like, sure, that sounds great. So that was our first customer.Swyx [00:29:05]: A thousand bucks a month.Ben [00:29:07]: It was a surprising amount of money. That's not casual. It was on the order of a thousand bucks a month.Swyx [00:29:11]: So was it a business?Ben [00:29:13]: It was the creator of PixRay. Like it was, he generated NFT art. And so he like made a bunch of art with these models and was, you know, selling these NFTs effectively. And I think lots of people in his community were doing similar things. And like he then referred us to other people who were also generating NFTs and he joined us with models. We started our API business. Yeah. Then we like made an official API and actually like added some billing to it. So it wasn't just like a fixed fee.Swyx [00:29:40]: And now people think of you as the host and models API business. Yeah, exactly.Ben [00:29:44]: But that just turned out to be our business, you know, but what ended up being beautiful about this is it was really fulfilling. Like the original goal of what we wanted to do is that we wanted to make this research that people were making accessible to like other people and for it to be used in the real world. And this was like the just like ultimately the right way to do it because all of these people making these generative models could publish them to replicate and they wanted a place to publish it. And software engineers, you know, like myself, like I'm not a machine learning expert, but I want to use this stuff, could just run these models with a single line of code. And we thought, oh, maybe the Docker image is enough, but it's actually super hard to get the Docker image running on a GPU and stuff. So it really needed to be the hosted API for this to work and to make it accessible to software engineers. And we just like wound our way to this. Yeah.Swyx [00:30:30]: Two years to the first paying customer. Yeah, exactly.Alessio [00:30:33]: Did you ever think about becoming Midjourney during that time? You have like so much interest in image generation.Swyx [00:30:38]: I mean, you're doing fine for the record, but, you know, it was right there, you were playing with it.Ben [00:30:46]: I don't think it was our expertise. Like I think our expertise was DevTools rather than like Midjourney is almost like a consumer products, you know? Yeah. So I don't think it was our expertise. It certainly occurred to us. I think at the time we were thinking about like, oh, maybe we could hire some of these people in this community and make great models and stuff like this. But we ended up more being at the tooling. Like I think like before I was saying, like I'm not really a researcher, but I'm more like the tool builder, the behind the scenes. And I think both me and Andreas are like that.Swyx [00:31:09]: I think this is an illustration of the tool builder philosophy. Something where you latch on to in DevTools, which is when you see people behaving weird, it's not their fault, it's yours. And you want to pave the cow paths is what they say, right? Like the unofficial paths that people are making, like make it official and make it easy for them and then maybe charge a bit of money.Alessio [00:31:25]: And now fast forward a couple of years, you have 2 million developers using Replicate. Maybe more. That was the last public number that I found.Ben [00:31:33]: It's 2 million users. Not all those people are developers, but a lot of them are developers, yeah.Alessio [00:31:38]: And then 30,000 paying customers was the number late in space runs on Replicate. So we had a small podcaster and we host a whisper diarization on Replicate. And we're paying. So we're late in space in the 30,000. You raised a $40 million dollars, Series B. I would say that maybe the stable diffusion time, August 22, was like really when the company started to break out. Tell us a bit about that and the community that came out and I know now you're expanding beyond just image generation.Ben [00:32:06]: Yeah, like I think we kind of set ourselves, like we saw there was this really interesting image, generative image world going on. So we kind of, you know, like we're building the tools for that community already, really. And we knew stable diffusion was coming out. We knew it was a really exciting thing, you know, it was the best generative image model so far. I think the thing we underestimated was just like what an inflection point it would be, where it was, I think Simon Willison put it this way, where he said something along the lines of it was a model that was open source and tinkerable and like, you know, it was just good enough and open source and tinkerable such that it just kind of took off in a way that none of the models had before. And like what was really neat about stable diffusion is it was open source so you could like, compared to like Dali, for example, which was like sort of equivalent quality. And like the first week we saw like people making animation models out of it. We saw people make like game texture models that like use circular convolutions to make repeatable textures. We saw, you know, a few weeks later, like people were fine tuning it so you could make, put your face in these models and all of these other-Swyx [00:33:10]: Textual inversion.Ben [00:33:11]: Yep. Yeah, exactly. That happened a bit before that. And all of this sort of innovation was happening all of a sudden. And people were publishing on Replicate because you could just like publish arbitrary models on Replicate. So we had this sort of supply of like interesting stuff being built. But because it was a sufficiently good model, there was also just like a ton of people building with it. They were like, oh, we can build products with this thing. And this was like about the time where people were starting to get really interested in AI. So like tons of product builders wanted to build stuff with it. And we were just like sitting in there in the middle, it's like the interface layer between like all these people who wanted to build and all these like machine learning experts who were building cool models. And that's like really where it took off. We were just sort of incredible supply, incredible demand, and we were just like in the middle. And then, yeah, since then, we've just kind of grown and grown really. And we've been building a lot for like the indie hacker community, these like individual tinkerers, but also startups and a lot of large companies as well who are sort of exploring and building AI things. Then kind of the same thing happened like middle of last year with language models and Lama 2, where the same kind of stable diffusion effect happened with Lama. And Lama 2 was like our biggest week of growth ever because like tons of people wanted to tinker with it and run it. And you know, since then we've just been seeing a ton of growth in language models as well as image models. Yeah. We're just kind of riding a lot of the interest that's going on in AI and all the people building in AI, you know. Yeah.Swyx [00:34:29]: Kudos. Right place, right time. But also, you know, took a while to position for the right place before the wave came. I'm curious if like you have any insights on these different markets. So Peter Levels, notably very loud person, very picky about his tools. I wasn't sure actually if he used you. He does. So you've met him on your Series B blog posts and Danny Post might as well, his competitor all in that wave. What are their needs versus, you know, the more enterprise or B2B type needs? Did you come to a decision point where you're like, okay, you know, how serious are these indie hackers versus like the actual businesses that are bigger and perhaps better customers because they're less churny?Ben [00:35:04]: They're surprisingly similar because I think a lot of people right now want to use and build with AI, but they're not AI experts and they're not infrastructure experts either. So they want to be able to use this stuff without having to like figure out all the internals of the models and, you know, like touch PyTorch and whatever. And they also don't want to be like setting up and booting up servers. And that's the same all the way from like indie hackers just getting started because like obviously you just want to get started as quickly as possible, all the way through to like large companies who want to be able to use this stuff, but don't have like all of the experts on stuff, you know, you know, big companies like Google and so on that do actually have a lot of experts on stuff, but the vast majority of companies don't. And they're all software engineers who want to be able to use this AI stuff, but they just don't know how to use it. And it's like, you really need to be an expert and it takes a long time to like learn the skills to be able to use that. So they're surprisingly similar in that sense. I think it's kind of also unfair of like the indie community, like they're not churning surprisingly, or churny or spiky surprisingly, like they're building real established businesses, which is like, kudos to them, like building these really like large, sustainable businesses, often just as solo developers. And it's kind of remarkable how they can do that actually, and it's in credit to a lot of their like product skills. And you know, we're just like there to help them being like their machine learning team effectively to help them use all of this stuff. A lot of these indie hackers are some of our largest customers, like alongside some of our biggest customers that you would think would be spending a lot more money than them, but yeah.Swyx [00:36:35]: And we should name some of these. So you have them on your landing page, your Buzzfeed, you have Unsplash, Character AI. What do they power? What can you say about their usage?Ben [00:36:43]: Yeah, totally. It's kind of a various things.Swyx [00:36:46]: Well, I mean, I'm naming them because they're on your landing page. So you have logo rights. It's useful for people to, like, I'm not imaginative. I see monkey see monkey do, right? Like if I see someone doing something that I want to do, then I'm like, okay, Replicate's great for that.Ben [00:37:00]: Yeah, yeah, yeah.Swyx [00:37:01]: So that's what I think about case studies on company landing pages is that it's just a way of explaining like, yep, this is something that we are good for. Yeah, totally.Ben [00:37:09]: I mean, it's, these companies are doing things all the way up and down the stack at different levels of sophistication. So like Unsplash, for example, they actually publicly posted this story on Twitter where they're using BLIP to annotate all of the images in their catalog. So you know, they have lots of images in the catalog and they want to create a text description of it so you can search for it. And they're annotating images with, you know, off the shelf, open source model, you know, we have this big library of open source models that you can run. And you know, we've got lots of people are running these open source models off the shelf. And then most of our larger customers are doing more sophisticated stuff. So they're like fine tuning the models, they're running completely custom models on us. A lot of these larger companies are like, using us for a lot of their, you know, inference, but it's like a lot of custom models and them like writing the Python themselves because they've got machine learning experts on the team. And they're using us for like, you know, their inference infrastructure effectively. And so it's like lots of different levels of sophistication where like some people using these off the shelf models. Some people are fine tuning models. So like level, Peter Levels is a great example where a lot of his products are based off like fine tuning, fine tuning image models, for example. And then we've also got like larger customers who are just like using us as infrastructure effectively. So yeah, it's like all things up and down, up and down the stack.Alessio [00:38:29]: Let's talk a bit about COG and the technical layer. So there are a lot of GPU clouds. I think people have different pricing points. And I think everybody tries to offer a different developer experience on top of it, which then lets you charge a premium. Why did you want to create COG?Ben [00:38:46]: You worked at Docker.Alessio [00:38:47]: What were some of the issues with traditional container runtimes? And maybe yeah, what were you surprised with as you built it?Ben [00:38:54]: COG came right from the start, actually, when we were thinking about this, you know, evaluation, the sort of benchmarking system for machine learning researchers, where we wanted researchers to publish their models in a standard format that was guaranteed to keep on running, that you could replicate the results of, like that's where the name came from. And we realized that we needed something like Docker to make that work, you know. And I think it was just like natural from my point of view of like, obviously that should be open source, that we should try and create some kind of open standard here that people can share. Because if more people use this format, then that's great for everyone involved. I think the magic of Docker is not really in the software. It's just like the standard that people have agreed on, like, here are a bunch of keys for a JSON document, basically. And you know, that was the magic of like the metaphor of real containerization as well. It's not the containers that are interesting. It's just like the size and shape of the damn box, you know. And it's a similar thing here, where really we just wanted to get people to agree on like, this is what a machine learning model is. This is how a prediction works. This is what the inputs are, this is what the outputs are. So cog is really just a Docker container that attaches to a CUDA device, if it needs a GPU, that has a open API specification as a label on the Docker image. And the open API specification defines the interface for the machine learning model, like the inputs and outputs effectively, or the params in machine learning terminology. And you know, we just wanted to get people to kind of agree on this thing. And it's like general purpose enough, like we weren't saying like, some of the existing things were like at the graph level, but we really wanted something general purpose enough that you could just put anything inside this and it was like future compatible and it was just like arbitrary software. And you know, it'd be future compatible with like future inference servers and future machine learning model formats and all this kind of stuff. So that was the intent behind it. It just came naturally that we wanted to define this format. And that's been really working for us. Like a bunch of people have been using cog outside of replicates, which is kind of our original intention, like this should be how machine learning is packaged and how people should use it. Like it's common to use cog in situations where like maybe they can't use the SAS service because I don't know, they're in a big company and they're not allowed to use a SAS service, but they can use cog internally still. And like they can download the models from replicates and run them internally in their org, which we've been seeing happen. And that works really well. People who want to build like custom inference pipelines, but don't want to like reinvent the world, they can use cog off the shelf and use it as like a component in their inference pipelines. We've been seeing tons of usage like that and it's just been kind of happening organically. We haven't really been trying, you know, but it's like there if people want it and we've been seeing people use it. So that's great. Yeah. So a lot of it is just sort of philosophical of just like, this is how it should work from my experience at Docker, you know, and there's just a lot of value from like the core being open, I think, and that other people can share it and it's like an integration point. So, you know, if replicate, for example, wanted to work with a testing system, like a CI system or whatever, we can just like interface at the cog level, like that system just needs to put cog models and then you can like test your models on that CI system before they get deployed to replicate. And it's just like a format that everyone, we can get everyone to agree on, you know.Alessio [00:41:55]: What do you think, I guess, Docker got wrong? Because if I look at a Docker Compose and a cog definition, first of all, the cog is kind of like the Dockerfile plus the Compose versus in Docker Compose, you're just exposing the services. And also Docker Compose is very like ports driven versus you have like the actual, you know, predict this is what you have to run.Ben [00:42:16]: Yeah.Alessio [00:42:17]: Any learnings and maybe tips for other people building container based runtimes, like how much should you separate the API services versus the image building or how much you want to build them together?Ben [00:42:29]: I think it was coming from two sides. We were thinking about the design from the point of view of user needs, what are their problems and what problems can we solve for them, but also what the interface should be for a machine learning model. And it was sort of the combination of two things that led us to this design. So the thing I talked about before was a little bit of like the interface around the machine learning model. So we realized that we wanted to be general purpose. We wanted to be at the like JSON, like human readable things rather than the tensor level. So it was like an open API specification that wrapped a Docker container. And that's where that design came from. And it's really just a wrapper around Docker. So we were kind of building on, standing on shoulders there, but Docker is too low level. So it's just like arbitrary software. So we wanted to be able to like have a open API specification that defined the function effectively that is the machine learning model. But also like how that function is written, how that function is run, which is all defined in code and stuff like that. So it's like a bunch of abstraction on top of Docker to make that work. And that's where that design came from. But the core problems we were solving for users was that Docker is really hard to use and productionizing machine learning models is really hard. So on the first part of that, we knew we couldn't use Dockerfiles. Like Dockerfiles are hard enough for software developers to write. I'm saying this with love as somebody who works on Docker and like works on Dockerfiles, but it's really hard to use. And you need to know a bunch about Linux, basically, because you're running a bunch of CLI commands. You need to know a bunch about Linux and best practices and like how apt works and all this kind of stuff. So we're like, OK, we can't get to that level. We need something that machine learning researchers will be able to understand, like people who are used to like Colab notebooks. And what they understand is they're like, I need this version of Python. I need these Python packages. And somebody told me to apt-get install something. You know? If there was sudo in there, I don't really know what that means. So we tried to create a format that was at that level, and that's what cog.yaml is. And we were really kind of trying to imagine like, what is that machine learning researcher going to understand, you know, and trying to build for them. Then the productionizing machine learning models thing is like, OK, how can we package up all of the complexity of like productionizing machine learning models, like picking CUDA versions, like hooking it up to GPUs, writing an inference server, defining a schema, doing batching, all of these just like really gnarly things that everyone does again and again. And just like, you know, provide that as a tool. And that's where that side of it came from. So it's like combining those user needs with, you know, the sort of world need of needing like a common standard for like what a machine learning model is. And that's how we thought about the design. I don't know whether that answers the question.Alessio [00:45:12]: Yeah. So your idea was like, hey, you really want what Docker stands for in terms of standard, but you actually don't want people to do all the work that goes into Docker.Ben [00:45:22]: It needs to be higher level, you know?Swyx [00:45:25]: So I want to, for the listener, you're not the only standard that is out there. As with any standard, there must be 14 of them. You are surprisingly friendly with Olama, who is your former colleagues from Docker, who came out with the model file. Mozilla came out with the Lama file. And then I don't know if this is in the same category even, but I'm just going to throw it in there. Like Hugging Face has the transformers and diffusers library, which is a way of disseminating models that obviously people use. How would you compare your contrast, your approach of Cog versus all these?Ben [00:45:53]: It's kind of complementary, actually, which is kind of neat in that a lot of transformers, for example, is lower level than Cog. So it's a Python library effectively, but you still need to like...Swyx [00:46:04]: Expose them.Ben [00:46:05]: Yeah. You still need to turn that into an inference server. You still need to like install the Python packages and that kind of thing. So lots of replicate models are transformers models and diffusers models inside Cog, you know? So that's like the level that that sits. So it's very complementary in some sense. We're kind of working on integration with Hugging Face such that you can deploy models from Hugging Face into Cog models and stuff like that to replicate. And some of these things like Llamafile and what Llama are working on are also very complementary in that they're doing a lot of the sort of running these things locally on laptops, which is not a thing that works very well with Cog. Like Cog is really designed around servers and attaching to CUDA devices and NVIDIA GPUs and this kind of thing. So we're actually like, you know, figuring out ways that like we can, those things can be interoperable because, you know, they should be and they are quite complementary and that you should be able to like take a model and replicate and run it on your local machine. You should be able to take a model, you know, the machine and run it in the cloud.Swyx [00:47:02]: Is the base layer something like, is it at the like the GGUF level, which by the way, I need to get a primer on like the different formats that have emerged, or is it at the star dot file level, which is model file, Llamafile, whatever, whatever, or is it at the Cog level? I don't know, to be honest.Ben [00:47:16]: And I think this is something we still have to figure out. There's a lot yet, like exactly where those lines are drawn. Don't know exactly. I think this is something we're trying to figure out ourselves, but I think there's certainly a lot of promise about these systems interoperating. We just want things to work together. You know, we want to try and reduce the number of standards. So the more, the more these things can interoperate and, you know

Jason Lengstorf, a developer media producer and host of the show Learn with Jason, joins Corey on this week's episode of Screaming in the Cloud to layout his ideas for creative developer content. Jason explains how devTV can have way more reach than webinars, the lack of inspiration he experiences at conferences these days, and why companies should be focused on hiring specialists before putting DevRels on the payroll. Plus, Corey and Jason discuss walking the line between claiming you're good at everything and not painting yourself into a corner as a DevRel and marketer.About JasonJason Lengstorf helps tech companies connect with developer communities through better media. He advocates for continued learning through collaboration and play and regularly live streams coding with experts on his show, Learn With Jason. He lives in Portland, Oregon.Links Referenced:Learn with Jason: https://www.learnwithjason.dev/Personal Website Links: https://jason.energy/linksTranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Before I went to re:Invent, I snuck out of the house for a couple of days to GitHub Universe. While I was there, I discovered all kinds of fascinating things. A conference that wasn't predicated on being as cheap as humanly possible was one of them, and a company that understood how developer experience might play out was another.And I also got to meet people I don't normally get to cross paths with. My guest today is just one such person. Jason Lengstorf is a developer media producer at Learn with Jason, which I have to assume is named after yourself.Jason: [laugh] It is yes.Corey: Or it's a dramatic mispronunciation on my part, like, no, no, it's ‘Learn with JSON' and it's basically this insane way of doing weird interchange formats, and you just try to sneak it through because you know I happen to be an XML purist.Jason: [laugh] Right, I'm just going to throw you a bunch of YAML today. That's all I want to talk about.Corey: Exactly. It keeps things entertaining, we're going to play with it. So, let's back up a sec. What do you do? Where do you start and where do you stop?Jason: I'm still learning how to answer this question, but I help companies do a better job of speaking to developer audiences. I was an engineer for a really long time, I went from engineering into developer advocacy and developer experience, and as of the last year, I'm doing that independently, with a big focus on the media that companies produce because I think that what used to work isn't working, and that there's a big opportunity ahead of us that I am really excited to help companies move into.Corey: It feels like this has been an ongoing area of focus for an awful lot of folks. How do you successfully engage with developer audiences? And if I'm being direct and more than a little bit cynical, a big part of it is that historically, the ways that a company marketed to folks was obnoxious. And for better or worse, when you're talking about highly technical topics and you're being loudly incorrect, a technical audience is not beholden to some of the more common business norms, and will absolutely call you out in the middle of you basically lying to them. “Oh, crap, what do we do now,” seemed to be a large approach. And the answer that a lot of folks seem to have come up with was DevRel, which… I've talked about it before in a bunch of different ways, and my one-liner is generally, “If you work in DevRel, that means you work in marketing, but they're scared to tell you that.”Jason: [laugh] I don't think you're wrong. And you know, the joke that I've made for a long time is that they always say that developers hate marketing. But I don't think developers hate marketing; they just hate the way that your company does it. And—Corey: Oh, wholeheartedly agree. Marketing done right is engaging and fun. A lot of what I do in public is marketing. Like, “Well, that's not true. You're just talking about whatever dumb thing AWS did this week.” “Well, yes, but then you stick around to see what else I say, and I just become sort of synonymous with ‘Oh, yeah, that's the guy that fixes AWS bills.'” That is where our business comes from, believe it or not.Jason: Ri—and I think this was sort of the heart of DevRel is that people understood this. They understood that the best way to get an audience engaged is to have somebody who's part of that audience engage with them because you want to talk to them on the level that they work. You're not—you know, a marketing message from somebody who doesn't understand what you do is almost never going to land. It just doesn't feel relatable. But if you talk to somebody who's done the thing that you do for work, and they can tell you a story that's engaging about the thing that you do for work, you want to hear more. You—you know, you're looking for a community, and I think that DevRel, the aim was to sort of create that community and give people a space to hang out with the added bonus of putting the company that employs that DevRel as an adjacent player to get some of that extra shine from wherever this community is doing well.Corey: It felt like 2019 was peak DevRel, and that's where I started to really see that you had, effectively, a lot of community conferences were taken over by DevRel, and you wound up with DevRel pitching to DevRel. And it became so many talks that were aligned with almost imagined problems. I think one of the challenges of working in DevRel is, if you're not careful, you stop being a practitioner for long enough that you can no longer relate to what the audience is actually dealing with. I can sit here and complain about data center travails that I had back in 2011, but are those still accurate in what's about to be 2024? Probably not.Jason: And I think the other problem that happens too is that when you work in DevRel, you are beholden to the company's goals, if the company employees you. And where I think we got really wrong is companies have to make money. We have to charge customers or the company ceases to exist, so when we go out and tell stories, we're encouraged by the company to focus on the stories that have the highest ROI for the company. And that means that I'm up on stage talking about some, like, far-future, large-scale enterprise thing that very few companies need, but most of the paying customers of my company would need. And it becomes less relatable, and I think that leads to some of the collapse that we saw that you mentioned, where dev events feel less like they're for devs and more like they're partner events where DevRel is talking to other DevRel is trying to get opportunities to schmooze partners, and grow our partner pipeline.Corey: That's a big part of it, where it seems, on some level, that so much of what DevRel does, when I see them talking about DevRel, it doesn't get around to DevRel is. Instead, it gets stuck in the weeds of what DevRel is not“. We are not shills for our employer.” Okay, I believe you, but also, I don't ever see you saying anything that directly contravenes what your employer does. Now, let me be clear: neither do I, but I'm also in a position where I can control what my employer does because I have the control to move in directions that align with my beliefs.I'm not saying that it's impossible to be authentic and true to yourself if you work for an employer, but I have seen a couple of egregious examples of people changing companies and then their position on topics they've previously been very vocal on pulled an entire one-eighty, where it's… it really left a bad taste in my mouth.Jason: Yeah. And I think that's sort of the trick of being a career DevRel is you have to sort of walk this line of realizing that a DevRel career is probably short at every company. Because if you're going to go there and be the face of a company, and you're not the owner of that company, they're almost inevitably going to start moving in a direction as business develops, that's not going to line up with your core values. And you can either decide, like, okay that's fine, they pay me well enough, I'm just going to suck it up and do this thing that I don't care about that much, or you have to leave. And so, if you're being honest with yourself, and you know that you're probably going to spend between 12 and 24 months at any given company as a DevRel, which—by the history I'm seeing, that seems to be pretty accurate—you need to be positioning and talking about things in a way that isn't painting you into that corner where you have to completely about-face, if you switch companies. But that also works against your goals as a DevRel at the company. So, it's—I think we've made some big mistakes in the DevRel industry, but I will pause to take a breath here [laugh].Corey: No, no, it's fine. Like, it's weird that I view a lot of what I do is being very similar to DevRel, but I would never call myself that. And part of it is because, for better or worse, it is not a title that tends to engender a level of respect from business owners, decision makers, et cetera because it is such a mixed bag. You have people who have been strategic advisors across the board becoming developer advocates. That's great.You also see people six months out of a boot camp who have decided don't like writing code very much, so they're going to just pivot to talking about writing code, and invariably, they believe, more or less, whatever their employer tells them because they don't have the history and the gravitas to say, “Wait a minute, that sounds like horse pucky to me.” And it's a very broad continuum. I just don't like blending in.Jason: Where I think we got a lot of this wrong is that we never did define what DevRel is. As you say, we mostly define what DevRel is not, and that puts us in a weird position where companies see other companies do DevRel, and they mostly pay attention to the ones who do DevRel really well. And they or their investors or other companies say, “You need a great DevRel program. This is the secret to growth.” Because we look at companies that have done it effectively, and we see their growth, and we say, “Clearly this has a strong correlation. We should invest in this.” But they don't—they haven't done it themselves. They don't understand which part of it is that works, so they just say, “We're hiring for DevRel.” The job description is nine different careers in a trench coat. And the people applying—Corey: Oh, absolutely. It's nine different things and people wind up subdividing into it, like, “I'm an events planner. I'm not a content writer.”Jason: Right.Corey: Okay, great, but then why not bill yourself as a con—as an events planner, and not have to wear the DevRel cloak?Jason: Exactly. And this is sort of what I've seen is that when you put up a DevRel job, they list everything, and then when you apply for a DevRel job, you also don't want to paint yourself into a corner and say, “My specialty is content,” or, “My specialty is public speaking,” or whatever it is. And therefore you say, “I do DevRel,” to give yourself more latitude as an employee. Which obviously I want to keep optionality anywhere I go. I would like to be able to evolve without being painted into a small box of, like, this is all I'm allowed to do, but it does put us in this really precarious position.And what I've noticed a lot of companies do is they hire DevRel—undefined, poorly written job description, poor understanding of the field. They get a DevRel who has a completely different understanding of what DevRel is compared to the people with the role open. Both of them think they're doing DevRel, they completely disagree on what those fundamentals are, and it leads to a mismatch, to burnout, to frustration, to, you know, this high turnover rate in this field. And everybody then starts to say, well, “DevRel is the problem.” But really, the problem is that we're not—we're defining a category, not a job, and I think that's the part that we really screwed up as an industry.Corey: Yeah. I wish there were a better way around there, but I don't know what that might be. Because it requires getting a bunch of people to change some cornerstone of what's become their identity.Jason: This is the part where I—this is probably my spiciest take, but I think that DevRel is marketing, but it is a different kind of marketing. And so, in a perfect world—like, where things start to fall apart is you try to slot DevRel into engineering, or you try to slot it into marketing, as a team on these broader organizations, but the challenge then becomes, if you have DevRel, in marketing, it will inevitably push more toward marketing goals, enterprise goals, top-of-funnel, qualified leads, et cetera. If you put them into engineering, then they have more engineering goals. They want to do developer experience reviews. They want to get out there and do demos. You know, it's much more engineering-focused—or if you're doing it right, is much more engineering-focused.But the best DevRel teams are doing both of those with a really good measure, and really clear metrics that don't line up with engineering or marketing. So, in a perfect world, you would just have an enterprise marketing team, and a developer marketing team, and that developer marketing team would be an organization that is DevRel today. And you would hire specialists—event planners, great speakers, great demo writers, probably put your docs team in there—and treat it as an actual responsibility that requires a larger team than just three or four ex-developers who are now speaking at conferences.Corey: There were massive layoffs across DevRel when the current macroeconomic correction hit, and I'd been worried about it for years in advance because—Jason: Mm-hm.Corey: So, many of these folks spent so much time talking about how they were not marketing, they were absolutely not involved in that. But marketing is the only department that really knows how to describe the value of these sorts of things without having hard metrics tied to it. DevRel spent a lot of time talking about how every metric used to measure them was somehow wrong, and if you took it to its logical conclusion, you would basically give these people a bunch of money—because they are expensive—and about that much money again in annual budget to travel more or less anywhere they want to go, and every time something good happened, as a result, to the company, they had some hand in it nebulously, but you could never do anything to measure their performance, so just trust that they're doing a good job. This is tremendously untenable.Jason: Mm-hm. Yeah, I think when I was running the developer experience org at Netlify, most of my meetings were justifying the existence of the team because there weren't good metrics. You can't put sales qualified leads on DevRel. It doesn't make any sense because there are too many links in the chain after DevRel opens the door, where somebody has to go from, ‘I'm aware of this company' to ‘I've interacted with the landing page' to ‘I've actually signed up for something' to ‘now I'm a customer,' before you can get them to a lead. And so, to have DevRel take credit is actually removing credit from the marketing team.And similarly, if somebody goes through onboarding, a lot of that onboarding can be guided by DevRel. The APIs that new developers interface with can be—the feedback can come from DevRel, but ultimately, the engineering team did that work the product team did that work. So, DevRel is this very interesting thing. I've described it as a turbocharger, where if you put it on an engine that runs well, you get better performance out of that engine. If you just plop one on the table, not a lot happens.Corey: Yeah, it's a good way of putting it. I see very early stage startups looking to hire a developer advocate or DevRel person in their seed stage or Series A, and it's… there's something else you're looking for here. Hire that instead. You're putting the cart before the horse.Jason: What a lot of people saw is they saw—what they're thinking of as DevRel is what they saw from very public founders. And when you get a company that's got this very public-facing, very engaging, charismatic founder, that's what DevRel feels like. It is, you know, this is the face of the company, we're showing you what we do on the inside, we're exposing our process, we're sharing the behind the scenes, and proving to you that we really are great engineers, and we care a lot. Look at all this cool stuff we're doing. And that founder up on stage was, I think, the original DevRel.That's what we used to love about conferences is we would go there and we would see somebody showing this thing they invented, or this new product they had built, and it felt so cool because it was these inspirational moments of watching somebody brilliant do something brilliant. And you got to follow along for that journey. And then we try to—Corey: Yeah I mean, that's natural, but you see booths at conferences, the small company startup booths, a lot of times you'll be able to talk to the founders directly. As the booths get bigger, your likelihood of being able to spend time talking to anyone who's materially involved in the strategic direction of that company gets smaller and smaller. Like, the CEO of GitHub isn't going to be sitting around at the GitHub booth at re:Invent. They're going to be, you know, talking to other folks—if they're there—and going to meetings and whatnot. And then you wind up with this larger and larger company. It's a sign of success, truly, but it also means that you've lost something along the way.Jason: Yeah, I think, you know, it's the perils of scale. And I think that when you start looking at the function of DevRel, it should sort of be looked at as, like, when we can't handle this anymore by ourselves, we should look for a specialty the same way that you do for any other function inside of a company. You know, it wouldn't make sense on day one of a startup to hire a reliability engineer. You're not at the point where that makes sense. It's a very expensive person to hire, and you don't have enough product or community or load to justify that role yet. And hopefully, you will.And I think DevRel is sort of the same way. Like, when you first start out your company, your DevRel should be the founding team. It should be your engineers, sharing the things that they're building so that the community can see the brilliance of your engineering team, sharing with the community, obviously, being invested in that community. And when you get big enough that those folks can no longer manage that and their day-to-day work, great, then look into adding specialists. But I think you're right that it's cart before the horse to, you know, make a DevRel your day-one hire. You just don't have enough yet.Corey: Yeah, I wish that there were an easy way to skin the cat. I'm not sure there is. I think instead we wind up with people doing what they think is going to work. But I don't know what the truth is.Jason: Mmm.Corey: At least. That's where I land on it.Jason: [laugh] Yeah, I mean, every company is unique, and every experience is going to be unique, so I think to say, “Do it exactly like this,” is—that's got a lot of survivorship bias, and do as I say—but at the same time, I do think there's some universal truths. Like, it doesn't really make sense to hire a specialist before you've proven that specialty is the secret sauce of your business. And I think you grow when it's time to grow, not just in case. I think companies that over-hire end up doing some pretty painful layoffs down the road. And, you know, obviously, there's an opposite end of that spectrum where you can grow too slowly and bury your team and burn everybody out, but I think, you know—we, [laugh] leading into the pandemic, I guess, we had a lot of free money, and I think people were thinking, let's go build an empire and we'll grow into that empire. And I think that is a lot of why we're seeing this really painful downsizing right now, is companies hired just in case and then realized that actually, that in case didn't come to be.Corey: What is the future of this look like? Easy enough to look back and say, well, that didn't work? Well, sure. What is the future?Jason: The playbook that we saw before—in, like, 2019 and before—was very event-driven, very, like, webinar-driven. And as we went into 2020, and people were at home, we couldn't travel, we got real sick of Zoom calls. We don't want to get on another video call again. And that led to that playbook not working anymore. You know, I don't want to get on a webinar with a company. I don't want to go travel to a company event, you know, or at least not very many of them. I want to go see the friends I haven't seen in three years.So, travel priorities changed, video call fatigue is huge, so we need something that people want to do, that is interesting, and that is, you know, it's worth making in its own right, so that people will engage with it, and then you work in the company goals as an incidental. Not as a minor incidental, but you know, it's got to be part of the story; it can't be the purpose. People won't sign up for a webinar willingly these days, I don't think, unless they have exactly the problem that your webinar purports to solve.Corey: And even if they do, it becomes a different story.Jason: Right.Corey: It's [high buying 00:19:03] signal, but people are constantly besieged by requests for attention. This is complicated by what I've seen over the last year. When marketing budgets get—cut, arguably too much, but okay—you see now that there's this follow-on approach where, okay, what are we going to cut? And people cut things that in many cases work, but are harder to attribute success to. Events, for example, are doing very well because you have someone show up at your booth, you scan their badge. Three weeks later, someone from that company winds up signing up for a trial or whatnot, and ah, I can connect those dots.Whereas you advertise on I don't know, a podcast as a hypothetical example that I'm pulling out of what's right in front of me, and someone listening to this and hearing a message from a sponsor, they might be doing something else. They'll be driving, washing dishes, et cetera, and at best they'll think, “Okay, I should Google that when I get back to a computer.” And they start hearing about it a few times, and, “Oh. Okay, now it's time for me to go and start paying serious attention to this because that sounds like it aligns with a problem I have.” They're not going to remember where they initially heard it.They're going to come in off of a Google search, so it sounds like it's all SEO's benefit that this is working, and it is impossible to attribute. I heard some marketer once say that 50% of your marketing budget is wasted, but you'll go bankrupt trying to figure out which half. It all ties together. But I can definitely see why people bias for things that are more easily attributed to the metric you care about.Jason: Yes. And I think that this is where I see the biggest opportunity because I think that we have to embrace that marketing signal is directional, not directly attributable. And if you have a focus campaign, you can see your deviation from baseline signups, and general awareness, and all of the things that you want to be true, but you have to be measuring that thing, right? So, if we launch a campaign where we're going to do some video ads, or we're going to do some other kind of awareness thing, the goal is brand awareness, and you measure that through, like, does your name get mentioned on social media? Do you see a deviation from baseline signups where it is trending upward?And each of those things is signal that the thing you did worked. Can you directly attribute it? No, but I think a functional team can—you know, we did this at Netlify all the time where we would go and look: what were the efforts that were made, what were the ones that got discussion on different social media platforms, and what was the change from baseline? And we saw certain things always drove a non-trivial deviation from baseline in the right direction. And that's one of the reasons that I think the future of this is going to be around how do you go broader with your reach?And my big idea—to nutshell it—is, like, dev TV. I think that developers want to see the things that they're interested in, but they want it to be more interesting than a straight webinar. They want to see other developers using tools and getting a sense of what's possible in an entertaining way. Like, they want stories, they don't want straight demos. So, my thinking here is, let's take this and steer into it.Like, we know that developers love when you put a documentary together. We saw the Vue documentary, and the React documentary, and the GraphQL documentary, and the Kubernetes documentary coming out of the Honeypot team, and they've got hundreds of thousands, and in some cases, millions of views because developers really want to see good stories about us, about our community. So, why not give the dev community a Great British Bake Off, but for web devs? Why not create an Anthony Bourdain Parts Unknown-style travel show that highlights various web communities? Why not get out there and make reality competition shows and little docuseries that help us highlight all the things that we're learning and sharing and building?Every single one of those is going to involve developers talking about the tools they use, talking about the problems they solve, talking about what they were doing before and how they've made it better. That's exactly what a webinar is, that's what a conference talk is, but instead of getting a small audience at a conference, or you know, 15 to 30 people signing up for your webinar, now we've got the potential for hundreds of thousands or even millions of people to watch this thing because it's fun to watch. And then they become aware of the companies involved because it's presented by the company; they see the thing get used or talked about by developers in their community, I think there's a lot of magic and potential in that, and we've seen it work in other verticals.Corey: And part of the problem comes down as well to the idea that, okay, you're going to reach some people in person at events, but the majority of engineers are not going to be at any event or—Jason: Right.Corey: Any event at all, for that matter. They just don't go to events for a variety of excellent reasons. How do you reach out to them? Video can work, but I always find that requires a bit of a different skill than, I don't know, podcasting or writing a newsletter. So, many times, it feels like it's, oh, and now you're just going to basically stare at the camera, maybe with someone else, and it looks like the Zoom call to which the viewer is not invited.Jason: Right.Corey: They get enough of that. There has to be something else.Jason: And I think this is where the new skill set, I think, is going to come in. It exists in other places. We see this happen in a lot of other industries, where they have in-house production teams, they're doing collaborations with actors and athletes and bringing people in to make really entertaining stories that drive underlying narratives. I mean, there's the ones that are really obvious, like, the Nikes of the world, but then there are far less obvious examples.Like, there was this show called Making It. It was… Nick Offerman and Amy Poehler were the hosts. It was the same format as the Great British Bake Off but around DIY and crafting. And one of the permanent judges was the Etsy trend expert, right? And so, every single episode, as they're judging this, the Etsy trend expert is telling all of these crafters and contestants, “You know, what you built here is always a top seller on Etsy. This is such a good idea, it's so well executed, and people love this stuff. It flies off the shelves in Etsy stores.”Every single episode, just perfectly natural product placement, where a celebrity that you know—Nick Offerman and Amy Poehler—are up there, lending—like, you want to see them. They're so funny and engaging, and then you've got the credibility of Etsy's trend expert telling the contestants of the show, “If you do DIY and crafting, you can make a great living on Etsy. Here are the things that will make that possible.” It's such subtle, but brilliant product placement throughout the entire thing. We can do that. Like, we have the money, we just spend it in weird places.And I think that as an industry, if we start getting more creative about this and thinking about different ways we can apply these marketing dollars that we're currently dumping into very expensive partner dinners or billboards or getting, you know, custom swag or funding yet another $150,000 conference sponsorship, we could make a series of a TV show for the same cost as throwing one community event, and we would reach a significantly larger group.Corey: Yeah. Now, there is the other side of it, too, where Lord knows I found this one out the fun way, that creating content requires significant effort and—Jason: Yes.Corey: Focus. And, “Oh, it's a five-minute video. Great, that could take a day or three to wind up putting together, done right.” One of the hardest weeks of my year is putting together a bunch of five-minute videos throughout the course of re:Invent. So much that is done in advance that is basically breaking the backs of the editing team, who are phenomenal, but it still turns into more than that, where you still have this other piece of it of the actual content creation part.And you can't spend all your time on that because pretty soon I feel like you become a talking head who doesn't really do the things that you are talking to the world about. And that content gets pretty easy to see when you start looking at, okay, what did someone actually do? Oh, they were a developer for three years, and they spent the next seven complaining about development, and how everyone is—Jason: [laugh].Corey: Doing it wrong on YouTube. Hmm… it starts to get a little, how accurate is this really? So, for me, it was always critical that I still be hands-on with things that I'm talking about because otherwise I become a disaster.Jason: And I agree. One of the things that my predecessor at Netlify, Sarah Drasner, put in place was a, what she called an exchange program, where we would rotate the DevRel team onto product, and we rotate product onto the DevRel team. And it was a way of keeping the developer experience engineers actually engineers. They would work on the product, they didn't do any DevRel work, they were exclusively focused on doing actual engineering work inside our product to just help keep their skills sharp, keep them up to date on what's going on, build more empathy for the engineers that we talk to every day, build more empathy for our team instead of us—you know, you never want to hear a DevRel throw the engineering team under the bus for not shipping a feature everybody wants.So, these sorts of things are really important, and they're hard to do because we had to—you know, that's a lot of negotiation to say, “Hey, can we take one of your engineers for a quarter, and we'll give you one of our engineers for a quarter, and you got to trust us that's going to work out in your favor.” [laugh] Right? Like, there's a lot that goes into this to make that sort of stuff possible. But I absolutely agree. I don't think you get to make this type of content if you've fully stepped out of engineering. You have to keep it part of your practice.Corey: There's no way around it. You have to be hands-on. I think that's the right way to do it, otherwise, it just leads to, frankly, disaster. Very often, you'll see people who are, like, “Oh, they're great in the DevRel space. What do they do?” And they go to two or three conferences a year, and they have a blog post or so. It's like, okay, what are they doing the rest of that time?Sometimes the answer is fighting internal political fires. Other times it's building things and learning these things and figuring out where they stand. There are some people, I don't want to name names, although an easy one is Kelsey Hightower, who has since really left the stage, that he's retired, but when he went up on stage and said something—despite the fact that he worked at Google—it was eminently clear that he believed in what he was saying, or he would not say it.Jason: Right.Corey: He was someone who was very clearly aware of the technology about which he was speaking. And that was great. I wish that it were not such a standout moment to see him speak and talk about that. But unfortunately, he kind of is. Not as many people do that as well as we'd like.Jason: Agreed. I think it was always a treat to see Kelsey speak. And there are several others that I can think of in the community who, when they get on stage, you want to be in that audience, and you want to sit down and listen. And then there are a lot of others who when they get on stage, it's like that this book could have been a blog post, or this—you know, this could have been an email, that kind of thing. Like you could have sent me this repo because all you did was walk through this repo line-by-line, or something that—it doesn't feel like it came from them; it feels like it's being communicated by them.And I think that's, again, like, when I criticize conferences, a lot of my criticism comes from the fact that, coming up, I feel like every speaker that I saw on stage—and this is maybe just memory… playing favorites for me, but I feel like I saw a lot of people on stage who were genuinely passionate about what they were creating, and they were genuinely putting something new into the world every time they got on stage. And I have noticed that I feel less and less like that. Also, I feel like events have gotten less and less likely to put somebody on stage unless they've got a big name DevRel title. Like, you have to work at a company that somebody's heard of because they're all trying to get that draw because attendance is going down. And—Corey: Right. It's a—like, having run some conferences myself, the trick is, is you definitely want some ringers in there. People you know will do well, but you also need to give space for new voices to arise. And sometimes it's a—it always bugs me when it seems like, oh, they're here because their company is a big sponsor. Of course, they have the keynote. Other times, it's a… like, hate the actual shill talks, which I don't see as much, which I'm thankful for; I'd stop going to those conferences, but jeez.Jason: Yeah, and I think it's definitely one of those, like, this is a thing that we can choose to correct. And I have a suspicion that this is a pendulum not a—not, like, the denouement of—is that the right—how do you say that word? De-NOW-ment? De-NEW-ment? Whatever.Corey: Denouement is my understanding, but that might be the French acc—Jason: Oh, me just—Corey: The French element.Jason: —absolutely butchering that. Yeah [laugh]. I don't think this is the end of conferences, like we're seeing them taper into oblivion. I think this is a lull. I think that we're going to realize that we want to—we really do love being in a place with other developers. I want to do that. I love that.But we need to get back to why we were excited to go to conferences in the first place, which was this sharing of knowledge and inspiration, where you would go see people who were literally moving the world forward in development, and creating new things so that you would walk away with insider info, you had just seen the new thing, up close and personal, had those conversations, and you went back so jazzed to build something new. I feel like these days, I feel more like I went and watched a handful of product demos, and now I'm really just waiting to the hallway track, which is the only, like, actually interesting part at a lot of events these days.Corey: I really want to thank you for taking the time to speak with me. If people want to learn more, where's the best place for them to find you?Jason: Most of what I share is on learnwithjason.dev, or if you want a big list of links, I have jason.energy/links, which has a whole bunch of fun stuff for you to find.Corey: Awesome. And we will, of course, include links to that in the show notes. Thank you so much for taking the time to speak with me. I really appreciate it.Jason: Yeah, thanks so much for having me. This was a blast.Corey: Jason Lengstorf, developer media producer at Learn with Jason. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment that will no doubt become the basis for somebody's conference talk.Jason: [laugh].Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.

Netlify recently announced the findings of The State of Web Development, previously known as the Jamstack Community Survey, which is a guide to the trends and strategies shaping the future of web development. Today we're going to talk about some of the findings in this report, including building agility into the enterprise through a composable approach to an organization's digital presence.  To help me discuss this topic, I'd like to welcome Matt Biilmann, CEO at Netlify. Matt - welcome to the show! Resources PartnerHero: to waive set up fees, go to https://partnerhero.com/agile and mention “The Agile Brand” during onboarding! Netlify website: https://www.netlify.com Netlify report: https://streaklinks.com/Bxb2h1dUVFh070U5bQXkCVh2/https%3A%2F%2Fwww.netlify.com%2Fresources%2Febooks%2Fthe-state-of-web-development-2023%2F Sign up for The Agile Brand newsletter here: https://www.gregkihlstrom.com Get the latest news and updates on LinkedIn here: https://www.linkedin.com/company/the-agile-brand/ For consulting on marketing technology, customer experience, and more visit GK5A: https://www.gk5a.com Check out The Agile Brand Guide website with articles, insights, and Martechipedia, the wiki for marketing technology: https://www.agilebrandguide.com The Agile Brand podcast is brought to you by TEKsystems. Learn more here: https://www.teksystems.com/versionnextnow The Agile Brand is produced by Missing Link—a Latina-owned strategy-driven, creatively fueled production co-op. From ideation to creation, they craft human connections through intelligent, engaging and informative content. https://www.missinglink.company

Kyle Mathews is Co-Founder & CTO of Gatsby, the front-end web development platform. Their open source framework, GatsbyJS, is widely adopted with 55K GitHub Stars. In Feb 2023, Gatsby was acquired by Netlify. In this episode, we discuss how GatsbyJS was able to grow incredibly fast, what features matter most for front-end development frameworks (speed, approachability, etc.), learnings from going after a smaller portion of the market and over-hiring & more!

Charlie Gerard is a highly accomplished software engineer and technologist. She's worked at Stripe, Netlify, and Atlassian and authored the book, Practical Machine Learning in JavaScript. In her spare time, Charlie explores the field of human-computer interaction and builds interactive prototypes using hardware and machine learning. Some of her recent projects include building a DIY The post Catching up with Technologist Charlie Gerard appeared first on Software Engineering Daily.

Christian Bach is the Co-founder/CSO at Netlify, Board Member at MACH Alliance, and angel investor.  In this episode, Christian talks about growing up in Copenhagen, family, childhood struggles with Asthma, creative pursuits, storytelling, digital strategy leadership, career trajectory, entrepreneurship, investing, co-founding Netlify, and so much more.

Today we're going to talk about headless e-commerce, and how it improves personalization, reduces friction, and drives greater loyalty. To help me discuss this topic, I'd like to welcome Chris Bach, Co-Founder, CCO and CSO at Netlify a company that powers web experiences for major retailers like Victoria Beckham Beauty, Paul Valentine and Butcher Box. RESOURCES Netlify website: https://www.netlify.com The Agile Brand podcast website: https://www.gregkihlstrom.com/theagilebrandpodcast Sign up for The Agile Brand newsletter here: https://www.gregkihlstrom.com Get the latest news and updates on LinkedIn here: https://www.linkedin.com/company/the-agile-brand/ For consulting on marketing technology, customer experience, and more visit GK5A: https://www.gk5a.com The Agile Brand podcast is brought to you by TEKsystems.Learn more here: https://www.teksystems.com/versionnextnow The Agile Brand is produced by Missing Link—a Latina-owned strategy-driven, creatively fueled production co-op. From ideation to creation, they craft human connections through intelligent, engaging and informative content. https://www.missinglink.company SYNOPSIS In this episode of The Agile Brand, host Greg Kihlstrom speaks with Chris Bach, co-founder, CCO, and CSO at Netlify, about the concept of headless e-commerce and its benefits for retail providers and customers. They discuss how Netlify powers web experiences for major retailers and the innovative opportunities that headless e-commerce presents.

אוהד אדר-פרסמן מכר את החברה הראשונה לצ׳ג האמריקאית לפני כתריסר שנים ושימש כבכיר בחברה, שהונפקה בין לבין, במשך שנים. מאז הספיק להשקיע בעשרות חברות ולהקים עם שותפיו לפני כחמש שנים את חברת סטאקביט, שנמכרה החודש לחברת Netlify.   על מה דיברנו: אינטלגינציה מלאכותית, השקעות, מכירת חברות, חילופי דורות, וויקס, וורד-פרס, סן פרנסיסקו, פיתוח ווב   נותני החסות שלנו: לימודי המשך בטכניון חברת 2sit שבה תקבלו 25% הנחה על הכסא הראשון שתקנו אם תגידו שהגעתם דרך גיקונומי

Netlify's all-in-one development platform gives devs access to build, deploy, and backend services for websites and web apps. Get started with their docs.Jamstack is a web development architecture based on JavaScript, APIs, and Markup (the JAM in Jamstack). Learn what Jamstack is and what benefits it offers.Composable architecture has been called “the next big thing” in web development. Netlify defines it as “a development approach [that] provides the ability to more rapidly build technology stacks by making use of logically separated reusable and customizable components.”Dana is on LinkedIn.Warm congrats to Lifeboat badge winner hasectic saif, who rescued the question How can I print to standard error in C with 'printf'? from an answerless void.

In this supper club episode of Syntax, Wes and Scott talk with Dustin Schau about Netlify Connect, Gatsby, GraphQL, and more. Show Notes 00:35 Welcome 01:20 Who is Dustin Schau? Dustin Schau (@SchauDustin) Develop and deploy websites and apps in record time | Netlify 02:49 Is Valhalla from Gatsby? How to Source Content from a Headless CMS | Gatsby Valhalla Content Hub | Gatsby Netlify Connect Brings All Content Sources & CMS Apps Together 05:41 Valhalla is now Netlify Connect 09:32 How often should you scrape or cache from another API? 10:36 What about auth? 13:41 Will Netlify Connect be open source or paid? 18:48 Is GraphQL it? Overview | urql Documentation GQty 22:35 What odd data sources are you trying to connect? 26:06 How does Gatsby send out to APIs? 29:00 What CMS should people use? The Markdown CMS | Tina The platform to bring your best ideas to life | Contentful The Composable Content Cloud - Sanity.io 31:22 What do you think of component based CMS? SEO Enterprise Rank Tracker - A Keyword Rank Tracking Tool Like No Other | Nozzle.io 35:36 What are your thoughts on the React ecosystem? 43:33 What's the future for Gatsby? 46:14 Supper Club questions folivora.ai - Great Tools for your Mac! Noodlesoft – Noodlesoft – Simply Useful Software Dank Mono: The coding typeface for aesthetes DSchau/dotfiles: :wrench: .files, including ~/.macos — sensible defaults for macOS development (catered to Node.js) Deploy app servers close to your users · Fly Hono - Ultrafast web framework for the Edges Stream Movies & TV Shows | Plex The Free Software Media System | Jellyfin 56:29 SIIIIICK ××× PIIIICKS ××× ××× SIIIIICK ××× PIIIICKS ××× Arc Browser Resend React Email Shameless Plugs Netlify Netlify Connect Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets Wes Bos on Bluesky Scott on Bluesky Syntax on Bluesky

This week Sarah Drasner joins us to talk about her book Engineering Management for the Rest of Us and her experience leading engineering at Zillow, Microsoft, Netlify, and now Google.

The post Netlify with Mathias Biilmann Christensen appeared first on Software Engineering Daily.

Brian Rinaldi joins us to talk about the state of Jamstack in 2023, acronym confusion, SPA confusion, developing common tools of understanding, why Netlify bought Gatsby, and the state of developer conferences.