Episode 65 - Mike Coutermarsh

Your database is slow, your Sentry is screaming, and the backlog is full of “we’ll fix it later.” What if an AI agent handled the boring but high-impact work while you slept and just opened a clean pull request for review the next morning?

We’re joined by Mike Coutermarsh, a software engineer who helped build GitHub Actions and later left GitHub for PlanetScale. We talk candidly about the trade-offs: walking away from big-company comfort, choosing impact over feeling like a cog, and learning to thrive in a flatter org where the best “process” is ownership. Mike shares how he leads the team responsible for everything users see at PlanetScale, from dashboards to APIs to CLIs, and why speeding up CI, reducing bugs, and protecting reliability can matter more than chasing the flashiest feature.

Then we get practical about AI coding tools. Mike breaks down how Cursor, Claude Code, and MCP servers can connect production query patterns and Sentry errors to scoped “bot army” automations that propose fixes, optimize performance, and even keep error queues from becoming a garbage fire. We also dig into AI code review, responsibility (“if your name is on the commit, you own it”), and the uncomfortable question of whether code quality still matters when models can generate code fast. Along the way we touch token costs, local models, and why conventions like Rails can actually help AI work better.

On the database side, Mike explains why PlanetScale started with MySQL via Vitess, how sharding changes operations like backups and restores, why Postgres demand forced a new product push, and what it could mean to bring Vitess-style scaling to Postgres. We wrap with a small but surprisingly powerful workflow upgrade: fast dictation using Spokenly and local speech-to-text.

Subscribe, share this with a teammate who lives in dashboards and PRs, and leave a review with the one workflow you’d want an AI agent to automate next.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Honeybadger
Honeybadger is an application health monitoring tool built by developers for developers.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Transcript

Welcome And Guest Background

SPEAKER_00 0:00

Hello everyone and welcome to another episode of Code and the Coding Coders to Code It. I'm your host, Drew Bragg, and I'm joined today by Mike Kudamarsh. Mike, for anyone who's not familiar with you, can you do a brief introduction for the audience?

SPEAKER_01 0:13

Hi everyone, this is Mike. I am a software engineer who has been obsessed with writing code. So I'm on this coders podcast, I guess, to talk about how I really like writing code. I've been doing it essentially for as long as I can remember, as soon as I started using a computer. I've worked on a bunch of cool stuff that you probably know about. I was one of the first engineers at producthunt.com. That was super fun. After that, I got the chance to work at GitHub. I was on the team that invented GitHub actions. So you might love or hate that. It's part partially my fault. Or you like it either way. And then five years ago, I left GitHub to work on a startup with a bunch of my best friends called Planet Scale. It's a database company. We do MySQL and Postgres for a bunch of really big and small, cool companies. And I've been doing that for five years. It's a lot of fun. So I'm going to keep doing it.

Leaving GitHub For Startup Work

SPEAKER_00 1:20

I didn't realize you had been at Planet Scale for five years now. That sounds insane. Sounds like such a long time. It's gone really fast. Yeah, you've got quite a history. So for anyone new to the show, the way this is going to work is I'm going to ask Mike three questions. I'm going to ask him what he's working on, which sounds like we're going to get into some cool stuff. What kind of blockers does he have? And if he doesn't have a current blocker, what's a recent one that he had and how did he go about solving it? And then the last question is just asking him to share something cool, new, or interesting that he's recently learned, discovered. Doesn't have to be coding related, but this is code and the code encoders who code it. So it absolutely can be. So, Mike, I want to ask you what you're working on, but it's kind of interesting that you left GitHub to go work in a startup. And I want to talk about that real quick before we get into like what you're doing at planet scale right now. Like, why? Why would you leave a place like GitHub, which I think even five years ago was holy shit, it'd be so cool to work at GitHub. Why would you leave GitHub to go work at a startup, which is a little riskier, or at least the perception is it's a little riskier?

SPEAKER_01 2:32

Yeah, for sure. So my career has been, it felt like just very lucky. I keep getting to work at these companies that I never thought like I belonged to work at. And then I'd go there and get to work on these huge successful products that everyone knows. So yeah, GitHub was like absolutely, I was like, oh, how am I even here? You know, you're like opening, you're opening pull requests and you see the people who are reviewing them. It's like all these like Ruby legends. Yeah. And they're reviewing my code and like, oh, we're co-workers together. That's crazy. Yeah, yeah. So dream job material for sure. And even just like as a fan of the internet, getting to see the inside of GitHub was really fun. Because I remember when I started, I would really just go through the old pull requests and go find like, oh, this is when they invented this thing that the entire internet uses. And like, oh, here's the conversation about how they made the pull request page faster that time and you know, 2010, right? It's just like really cool stuff. I was having a great time at GitHub. And you know what? Had this not come along, I'd probably still be there. Okay. Because like it's a really good company. I was there before the Microsoft acquisition, and then we were acquired by Microsoft. Working for a public company, you make a ton of money, also. Yeah, that's a big factor. Like working for a company that has public stock, you get RSUs every month, which is amazing. You'll see people who stay at like Google or Facebook forever, and why not? You're making a ton of cash and it's a great job, it's comfortable. But the thing, at least for me, when you're in a company that big, you start to feel a little bit like a cog or like I don't know, I like my work to matter. I want to like really matter in a way that if I'm doing a bad job, it's not helping the company, right? I want to feel like every day I have to like show up and do my best because I just like I like the challenge. Then, well, important detail here when I was at GitHub, there was this team that got spun up by Sam Lambert, who is now the CEO of Planet Scale, and that team's goal was to make GitHub actions and make it really good. I remember at that time I was kind of like this mid-engineer at GitHub. I didn't feel like I was important, but I was shipping and getting a lot of things done. And they were like, we need you on this team because we want to build this thing out really fast. And then I got to work with all these, it was like the most important people at GitHub at the time, and we were working on this together. So that was like a really cool experience. I also got really close with that group of people because we worked hard on this. It was like seven days a week total death march for months, and we just all cared so much about like making Hub Actions good. I think it was a couple years later, two or three years later, after GitHub Actions launches, we had that had like that great experience with that group of people. Sam had left GitHub and then he was working on planet scale, and he called me and he's like, Oh, we're like getting the gang back together. Like it's the same people, it's all your best friends. Yeah. And I remember feeling like literally sick to my stomach. So I was like, oh, the dream job. Oh, I'm gonna leave the money of like the it was a lot. I was very nervous about it at the time, and it felt like such a big decision, but then like I did it, and I think it was like one month in. I was like, Oh, having so much fun like doing the startup thing, like yeah, getting to like build, and I'm not a cog anymore. The money, oh, that doesn't matter anymore because I I'm just like so psyched every morning to do it, and it's with all these people that I love working with, and that's why I'm still doing it. So it's the same people, we're still together hacking every day.

SPEAKER_00 6:41

That's so cool. And would you consider Planet Scale a startup anymore? I mean, it's it feels pretty big.

SPEAKER_01 6:48

Yeah, I mean, I don't think so, right? Like we've been like this for years now, where like we're responsible for some of the largest databases in the world. It's a very serious responsibility now, and it's really not so much a startup. Well, we're still small. I think we just we've been growing a lot recently, but I think we're still only 90 people. It's almost entirely engineers. It's pretty unique. It's like a very flat org of a bunch of engineers who are all very good.

SPEAKER_00 7:17

What was the biggest change that you had to adapt to going from a place like GitHub where I think GitHub started very much the same way, like super flat, no managers, everyone's an engineer basically, but it definitely grew into a much more mature company, pretty big, like you said, like you were starting to feel a little bit like a cog. And then you go over to planet scale, where it's a lot smaller, a lot scrappier because you're in startup mode. But what was the biggest shift for you that you had to deal with?

Why Not Me And Early Chaos

SPEAKER_01 7:48

I think something that's helped me a lot, and this helped me a lot at GitHub, where I think people they like look for structure and rules, or they ask for permission to do things. And I remember at GitHub, I'd frequently be nervous about like some project, or I'd see some gap somewhere in the business and no one was working on it. I remember I had in my notes app, I just I had it written in all caps, and I just wrote like why not me in all caps. And all the time I'd like to look at that and then I'd tell myself, and then no matter how scared I was, I'd just go do it anyway. It just like put me in situations where um I felt nervous, but then it just kept like working out, right? Like that was like a good thing to do. So going into planet scale, I felt like I was pretty prepared because there were literally no guardrails at all. It was and the the biggest guardrail of all is just having like a profitable business with customers, right? Yeah. When I started, we didn't have it. It was literally like Rails new. We don't have like database customers. And it's like figuring out what to build and just making mistakes. We did some crazy things. Like if I got to go back and do it all over again, we could probably condense five years into like a year and a half, right? Like so many things, things we did wrong, and just like figuring out and stumbling around. Like there's this concept. If you use plan to scale, we have this flow around schema changes, which we call the deploy request. And it's just it's like this really sick UI that shows like what schema is going to change, you can monitor it as it goes out into production, you can watch like the tables swap over, you can check metrics, you can revert it, all this kind of stuff. Now that's been five years and we've had that, it just seems like an obvious thing. But back then it didn't exist, and we were just like stumbling around in the dark. Like I remember the meeting where like, what the hell do we even call this thing? It's like a I don't know. And we just someone said deploy request, and now it's like a major thing that all of these tens of thousands of people use. So now there's structure and it's a lot easier. But back then it was very much like, why not me be the guy comes up with this, reposes it, and uh it's always scary, like you're just nervous all the time.

SPEAKER_00 10:15

Sure, sure.

SPEAKER_01 10:15

With more consequences because the business could fail, and then you're yeah, I guess what's worse can happen? I bet GitHub for my job back. I mean that's not that bad.

SPEAKER_00 11:08

No, I can imagine that it's a great place to be in. I get to go work on this cool thing with people I like, and if it doesn't work out, I'll just go back to GitHub. Darn.

SPEAKER_02 11:18

Yeah, terrible.

SPEAKER_00 11:19

Woe is yeah so now you're at Planet Scale and you've been there for a while. It's a profitable business. So what are you like, what are you working on there? What's something that like big project that you're working on? Are you working on a lot of little things? Is it something kind of more mundane now? What are you working on at Planet Scale?

SPEAKER_01 11:40

So my job is I lead the team that is responsible for pretty much everything a user sees. So dashboards, APIs, CLIs. It's 2026, so MCP servers. Anything that anything you interact with, that's my team. So I do a lot less of direct writing code and project work than I used to. Usually the big projects, those those go to people on the team. I'm still writing a ton of code though, but the code I'm writing is not like I'm not like taking the the big coolest project on the team. It's more like, how do I help the team work faster? How do I make CI faster? How do I make sure we're more reliable? Less bugs. Can I prototype out something weird? That kind of work, yeah, which is really fun. The big thing for this year, I'm curious if you felt this too, is uh just like the AI tooling has gotten so good that it's almost like a new job. Yes, it's different, right? Do you feel that too? Yeah, for sure.

Leading The User-Facing Platform

SPEAKER_00 12:48

I'll admit, like, I have been historically extremely bearish on AI when it first came out. I was like, yeah, it's a glorified search engine. My Google foo has gotten good enough where none of this matters, it's not impressive. And then it started picking up, and then it started getting good at writing code. And I was still like, yeah, it's it's all right at writing code. It's not writing good code though. But yeah, in the past, definitely in the past six months, I've started to use it a lot more. I've started to work with it enough and understand it enough that I have it like more tailored to the way that I want to work. And now it's starting to actually be pretty damn useful in my day-to-day. I still really like writing code. So like I do have it write code when it's like boilerplate or something boring that I'm like, I know how like I've done that a hundred times already. I don't feel like writing it, you go into it. But yeah, it sort of feels like JavaScript frameworks back in the day where like there's something new every day. Like I wake up every day and there's something to read about something going on. You can go as deep as you want into it, because I don't know how machine learning works, let alone how LLMs and every layer of this stack now works. So there's a ton to learn. A lot of the job is the same. We're figuring out how to build the things that we want to build, but it's dramatically different on how we do it now. Is there an AI policy at Planet Scale? Do you guys just kind of use whatever, or is there a very structured way of how you guys are approaching it?

AI Tools Change Daily Engineering

SPEAKER_01 14:24

So we have access to basically everything. I guess a lot of people use clawed code, a lot of cursor. And I would say the policy is hey, use whatever tool you want, and here's an unlimited budget. Go figure out the, you know, how can you automate your job or you know, make yourself more productive. Yeah, or like how can you do things better for our customers? Yeah, I would say there's really no limits. I remember like when we first started getting into these tools, our CEO at the time was like, yeah, if you want to do your personal projects and have that built the company, just so you're getting used to these tools, like, you know, go for it, hack on whatever because it's gonna help you. I'm pretty sure 100% of the company now, everyone has something that they're doing. For myself, even in just the past maybe three months, I kind of went from I've always been a Vim like TMUX guy. I went from just using, you know, autocomplete stuff like co-pilot, and then I started using Claude Code and Cursor Agent in a TMUX pane to sort of help me. But then I was still like jumping into Vim a lot. And then most recently I got really into cursor. Now I'm like actually I'm running VS Code. That's a thing I would never do, but I found like the productivity gain has been so good for me that most of the stuff I'm working on, I'm actually in cursor and I'm just using I'm using Vim a lot less. My discovery in the past two weeks. So I gotta let you in on this one. This stuff's wild. So I was thinking the other day, I tweeted about this a little bit, and I almost don't want to tweet about it, and I almost don't want to tell people about it because I feel like I'm at some advantage. I don't want the competitors to know because it's so good, but I'm just gonna leak it out to you. I'm just gonna tell you what to do and to try. So we talked a little bit about this. There's all these things that like every development team does that you wish you could do every day, right? But like you can't. You're doing projects or dealing with bugs, there's like all this stuff going on. So for me, in like my role, I care a lot about app performance, of course. Like, is our app fast? That's important, and that's a hard one to maintain. I care a lot about our test suite being fast. So the whole team has great velocity. That's important to me. I care about like we use sentry for error tracking. When you log into sentry, I don't want it to be a garbage fire, right? Like I, you know, sure. I want people to look at it and be like, oh, I know what's going on and I know it's wrong. That's important to me. So I've been doing just been writing prompts basically in the cursor. And if anyone's not familiar with cursor, you can set up something called plan mode where you essentially give it a prompt, and then what it does is it researches your code base and in sort of any data that you give it, and then it writes a markdown doc with a plan of what it could do. A couple months ago at PlanScale, we launched an MCP server. And I worked on that a lot. Essentially, what that is, is it's just giving API access to an LLM so that they can pull data and have access to it. Where this gets super cool is so if you think about this, you're in plan mode and it has the context of your code base. But then also let's feed in data from somewhere else. So PlantScale has an MCP server. We added a tool to it where the LLM can examine your query patterns in your production database, like what's slow, which ones are missing an index, which ones using a ton of bandwidth. And just like as an experiment, because we were launching an MCP server and I'm doing this stuff, a prompt like, hey, go use the Planet Scale MCP. The code base is right here. Yeah. Find like find where that query is bad. Let's fix some stuff. Okay, let's do it. And it was finding things that were really valuable. And I was then opening a pull request, and we were like making schema changes or fixing N plus ones or whatever and making your app faster. That's cool. Here's like the big secret thing or the new discovery in the past couple of weeks is that's cool, but it still involves me. You know, like I'm at my computer. Cursor came out with, they've had this for a while. So they have a thing called cloud agents, where essentially you can run your Devit environment in a sandbox, and then they can do the plan mode, they have access to your code and all this stuff. They launched something called Cursor Automations, where you can it maybe it sounds complicated, it's easy. Go try it, it's great, it's so easy. There's a UI, and as a person who builds dev tools, I'm impressed with what they did here. They did a good job. So you can attach to this cloud agent MCP servers. So for example, PlantScale MCP, okay, now I've got my query data, right? That's awesome. Sentry has a very impressive MCP. Connecting that, now you've got your errors, you've got your performance data if you have that in Sentry. You could do data dog, you could do uh if you do build kite for your CI or GitHub Actions, there's MCPs for that. So you have all of that data. You can start writing prompts that are like, I call it my bot army. I have a whole bunch of these running now. This is my cheat code, everyone. So, for example, one of them that I like the most is we've had this idea of the like self-improving database where you can set up a cron, so say every day at 7 a.m. This thing goes and looks at your most expensive queries in production, like the ones that are reading a ton of data but not returning much data. Everyone has these. It's like, oh, this query read a million rows, but it returned one row. What a waste. And it was slow, and it's probably easy to fix, right? Turns out when the LLM has this data plus it has your code base, it's really good at fixing it itself.

SPEAKER_02 20:51

Yeah.

SPEAKER_01 20:52

So these cursor automations, they can use this data, make the fix, open the pull request on your behalf. Then you wake up and you look at it, and I was like, oh 90% of these are good.

Building A Bot Army With MCP

SPEAKER_00 21:10

That's impressive. Yes. That you get 90% good too. Because it's still I still feel like we're running into 50% of the code that the AI writes is good code. It's like really solid. But I guess because you're you're scoping it down so much, you're giving it enough data to work with and a very narrow request, hey, make this improvement. There's not too much thinking or reasoning. So I guess it makes sense that it would be able to tackle something like that and take it off your plate or allow you to focus on the other stuff. Like that stuff matters, but it always gets swept under the under the rug. That's tech debt, that's never the priority.

SPEAKER_01 21:52

Yep. Now give it to the bot army. And is exactly what you said. Someone said this to me that management often feels like you have no idea what you're doing, but you are incrementally seeing behavior you don't like and then trying to correct it, and it's just an endless cycle. That's what people. It's very similar feeling with, I'll call it my bot army, very similar feeling where I started with these sort of simple scoped prompts of what I want them to do and accomplish. And I just kept watching it and seeing what would happen. And then when the result wasn't good, I wrote some really you know dumb code occasionally. I just add a line, hey, don't do this. And then it stopped. So just iterating through and it kept getting better. And at this point, like we have bots that are improving the database. We have one of my favorite bots is just watching sentry for errors and then it fixes them.

SPEAKER_00 22:55

What a concept. What a concept. An error comes through and you just fix it. Like that's brilliant. How have we gotten this far in software without doing that?

SPEAKER_01 23:05

Yeah. The thing that's interesting is it fixes ones that I might just not fix.

unknown 23:11

Yeah.

SPEAKER_01 23:11

You'd see it and it's like, oh, well, this is happening to a user on a weird edge case. And I have so many other worst problems to deal with today. But if the bot's doing it basically for free, it's billing tokens and it will do it. I only have to review the pull request and merge it. Sweet. And then it's it's out of century. And I was looking at a graph of our total issues in Century. When I had turned the bot on, there was just like a sudden drop. It started to get lower. So I don't know if we'll get to the point where it's like we have this pure century page where you look at it and there's only like five important things. That would be the dream, but it feels possible with this audit.

SPEAKER_00 23:51

It's sort of like having a couple of extra mid to junior level engineers on the team. Still a little bit of hand holding involved, still gotta course correct them. You can't just blindly trust them. But if you give them a scoped enough task, they can just go off and do it and take one thing off your plate. So exactly how it feels. So something that you said earlier on, like Planet Scale basically started as Rails new. Yep. Is Planet Scale still a Rails monolith?

SPEAKER_01 24:23

So the way our stack works is in pretty much all infrastructure companies, there's two things. There's the control plane, and then there's the data plane. The control plane, that's what users interact with, like your dashboard, your API, CLI handles billing off, all that kind of stuff. The data plane would be that's where the databases are deployed. So two separate areas. For us, our company is the majority of everything is Ruby, TypeScript, or Go. There's a ton of Go. The control plane for us is two apps. We have a front-end Next.js React app, and that's the UI. Then the backend for the UI is a big Rails app. And it's essentially, we started it, I think it was in API mode, and it does a bunch of REST endpoints, and that's what the UI talks to. There's a ton of other cool stuff in there. It's a bunch of background jobs, running sidekick. That's what's keeping everyone's databases going, creating them, rolling out schema changes, all of that stuff. We have some kind of traditional like HTML ERB admin pages going to. So yeah, it's all like the fun parts of Rails, and then all that's talking to the data plane, which and that's just like a bunch of go.

SPEAKER_00 26:52

So that's awesome that even like a new and big company like Planet Scale just spun up like five-ish years ago as a Rails app when everyone still will tell you Rails is dying. It's like, no, it's not, it's still awesome. And in a way, it's like it's probably not even gonna matter in a few more years, just because the AIs are getting progressively better at writing code. So it's gonna come to a point where it's like it almost doesn't make sense to write your own code anymore. Like you do that for fun, not for work. And then, like, then what does it matter what you use? You're just gonna pick the most token efficient language and the one that the LLMs can operate on the best.

SPEAKER_01 27:36

I think about that frequently too. I was like, who's buying vent frameworks anymore? Like this era is seems to be ending.

SPEAKER_00 27:45

I mean, Rails' biggest advantage when it came out was the convention over configuration was like the speed amplifier. You kind of get that with AI now too. It's like less convention over configuration and more of like you give the guard rails to the AI and then it just can go off and do it, which actually I think is an argument for Rails in the AI era of like Rails has already defined to the AI the criteria of where everything needs to go. It doesn't have to think, you don't have to worry about it randomly deciding like this one model is gonna go in this random directory over here, or oh no, where should I put this thing? Like it's a very clearly defined convention for where everything should go, which solves some of the problems with AI. You know, the Ruby side, or allegedly Ruby's really token efficient and fast for AI to write. So maybe Ruby and Rails is gonna win that. But yeah, it is such a weird feeling for like to go through this whole career and like you get very used to it, and you're like, Yeah, this is what I'm gonna do. It'll change, it always changes, but like I've got the core of it down, and now it's suddenly like I feel like I don't know what I'm doing again. I can do the code writing and I can do the planning all on my own still, but I'm so much slower if I don't use AI just because like of course you are. Like I love it for research mode. Yeah, I can do so much more research, I can do so much more back and forth with it and like talking to it instead of just being like, build me an X, Y, or Z. I tell it, like, I'm going to try and accomplish this. Here are some like preliminary thoughts, and like have it challenge me or have it go off and be like, Well, this is a part of the code base you're gonna be in. Have you considered X? Such an interesting tool, and it's so crazy how fast we I feel like we went from AI is this very niche scientific community thing to AI as a chat bot to like holy shit, your job is completely different because of this thing, and it's just pattern matching. I mean, it's very robust and fast pattern matching on an insanely huge data set, but it's just pattern matching, it's wild, so crazy.

SPEAKER_01 30:01

It's gonna be tough to like imagine like you're just graduating right now and you're getting into this. Because on one hand, it could be an advantage because sometimes my mindset is I struggle with going back and thinking the ways I used to do things, where I'll look at a problem and I go, that's expensive to solve, so I'm not gonna solve it. But if you don't have that, those years of of pain, and your only idea is like, oh, AI tool can do this for me, you just jump right in and you can just get more done. I mean, I think for us who've been doing it for so long, we just have to keep reminding ourselves anytime you kind of have that like nope attitude of, I know that's gonna be painful because I did that five years ago. Well, it's not painful anymore, so why don't we just jump in and try it? Yeah.

SPEAKER_00 30:49

How do you guys handle AI contributions at planet scale? Is it a AI can write the code, the commit, the pull request, and then a human has to review it? Or are you having AI review AI's code? Is it like, I know Amazon just because of their insane outages recently, were basically like a senior needs to sign off on all junior and mid-level code that was written by AI, which seems like a really sane take to begin with, but again, I'm pretty bearish on AI, so what do I know? Do you have any hard, fast rules for deploying AI code, or is it kind of like you have a enough trust in your engineering team that it's like, listen, we believe you when you say this is good?

Rails Stack And AI Code Responsibility

SPEAKER_01 31:36

I would say the advantage of working at Planet Scale is essentially every engineer at Planet Scale would be like a staff or principal or distinguished engineer somewhere else. Like everyone is just very senior. So, like how we've approached this has a it's evolved really quickly. Even maybe in the past month or so, we've been using Bugbot a lot, which is cursor's code review tool. It's very good and it's gotten much better quickly, and it catches things that humans miss all the time. Quite impressive. So the stage where we're at now is a human always has to sign off, right? Review it and sign off. But we have bug bot running on every pull request, and it's finding like the majority of the things. There's like different levels to reviewing things where the bug bot will be really good at hey, you forgot this edge case, or this is going to cause an issue with this other system you didn't think about, or if a user enters this weird thing, like that's gonna happen. And there are things like I would just miss and maybe find in production a month later. So it's very valuable. The stuff that it's not good at is really just like the human thing. Still, like, should we even be building this? Should we even be shipping this? Or like, does this code even belong in this system? It could have been done so much easier somewhere else, but BugBot doesn't have that context. Right, right. So yeah, it's a mix, but I I do like having an AI tool review. We found it so valuable that we actually set, we said in GitHub recently that it's a we want it to run before we double anything because it's been finding so many things, and it just makes it easier for us to review. The other side of that is are humans writing code or is AI doing it? We sort of like write things about our culture internally, and we have this one document that talks about AI usage. And the model we've followed is like if your name's on the commit, like you are responsible for that. No matter you prompted it as some other tool, like this is still your code. You're yeah, you're the one proposing it. So long as people have that mindset that I need to understand what I'm putting in production and I'm responsible for it, even though it was easy, you know, they feel the weight of it and they're careful about getting that change out there, even though it felt easy. That's just sort of the balance they have to strike.

SPEAKER_00 34:22

So, one thing that has come up a lot, just when I'm talking to colleagues, talking to people outside of work, talking to my CTO at our one-on-one's whatever. And I'm gonna put you on the spot for your answer. Does code quality matter anymore? Code quality has always been a subjective thing, like it's never been really easy or clear to define. So it's always been a weird thing to be like, it matters when you can't even define it. But like if you had a definition with the fact that AI can move so fast over code when needed, does code quality matter anymore? Yes. That's my answer, but I feel like I'm in the minority.

SPEAKER_01 35:03

So please explain. Interesting. I think I've always been the type of developer I am has always been, I am almost a hundred percent focused on the customer and the outcome and the result of the code. I will do insane things to make a customer happy and let the code base suffer or take shortcuts, except for when those shortcuts also then impact a customer. Right, right. Or they hurt the team velocity, which is also impacting the customer and the business. So thinking about models looking at your code and if code quality matters, I think it absolutely does, because just like a human, they are reading it too. And you'll notice this, right, when you're building things. If you give an LLM a total mess of a spaghetti class, it's just gonna be more challenging. Like we talked about this earlier, where it's like scoped problems, it's gonna do a better job at versus a big unscoped mess. So really it's just thinking about the same as hey, if my coworkers are able to read this, I'm writing code and I want my co-workers to be able to read and understand this six months months from now, the complexity there, I think it's the same thing. Like the models will benefit from it too.

SPEAKER_00 36:31

I can agree with that. There's a lot of slop going around. And there seems to be a lot of people that think that because the AIs are so fast, because the models can absorb all of this context and keep it all in their window and iterate on it so quickly, it doesn't matter. We're in that stage now where everyone just throwing money at it, but that can only last so long. Eventually, budgets are gonna tighten again. And the first thing that's gonna tighten is hey, instead of dropping thousands of dollars on this model a month, like you have a token budget.

SPEAKER_01 37:04

I am curious about will tokens get so expensive at some point.

SPEAKER_00 37:08

Yeah. We had our dev meeting a few hours before this recording, and among the things getting discussed, I brought up, I think really what the future of AI looks like when you're looking at some of these open source models that are very quickly closing the gap in their skill with the proprietary ones, you know, the codexes and the opus and what have you. They're getting really close already. And they're getting way more efficient. I don't know if you use LLM fit. It's a command line tool to like look at what open source models could run on your current hardware. It's insane what I can run on my MacBook Pro. If I had a beefier machine, even more. But like just on my MacBook Pro, I can run some pretty decent models locally for free, free in quotes. Like obviously I'm still powering it. Now my computer's got to be on and all of those things, but I'm not paying an API cost. And because it's on my machine, I can now tailor its training. Like I can just go in and tweak its training completely where I don't even need to like give it those agent MD file guardrails or skills or commands because its training can be exactly what I want it to be. I don't think it's quite to the level where that is feasible for the work and velocity that we're looking for. I think we're still going to be using Opus and Codex for a while. But I think there's a not too distant future where AI usage is what are you running on your machine, like on-prem, and what does that training look like?

SPEAKER_01 38:47

I'm curious what it's like at a much larger companies, you know, 50,000 people. What are they they doing? Because you can see, yeah, the the token cost must be outrageous.

SPEAKER_00 38:59

But it's a completely different world at those larger companies, too. Because I've heard from people who work at those very large types of companies, very enterprisey, that they have like a token budget, but not in the budget that we're talking about, where they have like a minimum token usage that they're supposed to use. Like you're not using this. Okay, it's like honestly, when I heard it, I'm like, you're out of your freaking mind. Didn't we move on from lines of code being the metric two decades, three decades ago, where it was like first it was lines of code written, and then it was like, oh, that's a fucking horrible metric because more code does not equal better at all. It just feels like telling someone they have to burn through X amount of tokens in a week is just why? How? What? Just game it, easy, totally easy to game, stupid simple to game, but just some of the approaches people are taking to this whole thing is weird. And then I'll talk to people who aren't in software, and I talk about AI, and they're just like, Yeah, we don't use it. Why would we like? I asked Match GPT for help with like what should I have for lunch because I'm having an energy dip. What a big one. We don't use it at work, like we get and I'm just like, oh right, we're in a very, very special world when it comes to AI. There's entire industries that are like, AI is still this like novelty little it's the paperclip in Microsoft Word, where it's just like it's there, it doesn't you don't use it for much. I wonder when that's gonna change, because that's gonna change soon. They gotta hear about the bot army. The bot army. They hadn't heard about the open claw yet. That's the problem.

SPEAKER_01 40:43

Yeah, that's the one. Oh boy, yeah.

Token Costs And Local Model Futures

SPEAKER_00 40:45

That's what I mean when I'm like, it's changing so fast. And because it used to be when a new trend popped up and people like ran to catch up, you'd get a lot of little things popping up, but now you get a lot of medium to big size things popping up because the AI can write your random thought faster than you can go. Should we? Does the world need another Pomodoro timer? Doesn't matter, it's getting it. And obviously Pomodoro timer is small, but stuff can come out so fast, faster than people can realize. Yeah, this isn't a good use of anyone's time. It makes it really difficult to anticipate like what is your job gonna look like in five years? And like every day I'm like, I don't know, I might not have a job in five years, or I could be doing something completely different in five years, or I'll be doing the same exact thing because LLMs are gonna hit a limit where it's like, yep, they're really good at generating some random code and they still suck at the planning.

SPEAKER_01 41:47

It's the same as being a software engineer forever. Like the ones who are successful are the people who are curious and willing to learn and try new things. In five years, I think I'll still be curious and wanting to try new things. Right. So, like yeah, like whatever the thing is, and if it like for me, I care more about like what I build and the customer than the I enjoy writing code, of course, right? But like that's not the thing that's most important to me. So if my job evolves into I'm not touching code anymore, but I'm still building things for people, like these cool developer tools. Like, I'm I'm still gonna enjoy that a lot.

SPEAKER_00 42:27

For sure. So the next segment of the show is when I ask you about blockers. So do you have a current blocker? Is there something at work that you're currently like scratching your head on, or have you had one recently that you can talk about?

SPEAKER_01 42:42

Literally what you were just talking about, I find very interesting, which is you're talking about Pomodoro timers and like okay, the the idea, the the cost to like get an idea out into the world is nothing, right? Yeah, yeah. So now I think all of us who are embracing writing code with AI are experiencing this at work because previously, if you had an had an idea, it's just like what you said. Does the world need that? Does the customer need that? Is this like a thing that we want to release and support and all the you know other side effects that come from putting something out in the world? And when the barrier is so low to make that happen, I think just a problem I've seen is okay, we're throwing out ideas so quick, we need to then deal with you know, like supporting them. Like we're building so fast, but we're not going through the should we as much. So there's a lot of like bad ideas, and it's a little more difficult, or it's just like a little more challenging when you go, that's a bad idea, but it was easy to do. Before, that's a bad idea, and it's gonna take us two weeks, so let's really not do it. Right, right. Yeah. So those discussions are much more interesting than they used to be. And just like calibrating, like I've just felt that just with my coworkers, like we're calibrating about it. And like myself should, you know, that would be an easy idea, but maybe I just shouldn't do that.

The New Blocker Choosing What To Build

SPEAKER_00 44:23

Yeah. It's tough to tell. You used to be able to kick things down the lane a little bit by saying, Oh, that's gonna take a lot of time, so we're not gonna let it creep into our scope, or we don't have good consensus on this, and it's a resource hog, so we're just not gonna do it yet. And now it's like, yeah, you know, like you said, you can get anything out there really quickly. So, how do you decide what to build now? Because there used to be extra criteria on top of like, oh, find your product market fit if you're like trying to come up with a SaaS or your own little app business. You got to find that product market fit. And it's like maybe you do to like sustain a business, but like to start one now is like, yeah, open up AI and like prompt it. It's insane to see how many apps are flooding areas now. So you've got that, the Evergreen app, but then also what do we put into our large app that's been, you know, Planet Scale's relatively young at at five, six, whatever years. Podia is getting there, it's over a decade old. I've worked on apps that were really old. Those are not as easy to just cram shit into. It's a lot easier with AI now, but it makes the whole system more brittle. I'm not at that level. I'm not that decision maker. I push back on like scope because I don't want to do dumb stuff that they're just going to rip out later. I can't fathom what it must be like now to be like, we can build anything. What do we build? That feels like such a huge leap to decide what gets built.

SPEAKER_01 46:06

One thing I keep like coming back to is really for any team, what I've seen work, and then also what I've seen hurt them. What hurts a team is when they have too many things going on. Right. And they're responsible for too many things at once. It's easier today for teams to get into that state than it used to be, because it's so much easier to just start putting things out there. Something that our team likes to do is we're really just setting the limit on the number of things that are big and in progress at a time. You have six engineers. Okay, we're committing to like two things. Let's get them out of the way, and then we can do two more things. We're able to get through those two things way faster than we used to, but please let's just still focus on only two things at once. Because if you're you know focusing on six or eight, people are swapping context all day, they're unhappy and grumpy, and then you start multiplying that by teams, and it just gets out of control. And you're like, hey, I get that you could, but what if we finish that thing we already started, get it done, and then just focus on one thing and your your life's gonna be really nice. I feel attacked.

SPEAKER_00 47:19

What do you mean, finish a thing? You mean 80% isn't done?

SPEAKER_01 47:23

It's the last 10% that take take the most time. Yes. That has not changed.

SPEAKER_00 47:28

That's not, yeah, that's nothing different, especially uh AIs get worse as their context window grows. So they have the same problem. You get 90% of the way done, their context window is 90% full, and they're useless, and you're just like, well, I guess I'm done because the AI can't figure it out anymore. They're just like us. It is amusing at times to be in a like a planning mode where you're deliberately doing a very back and forth like conversation style with one of the LLMs because uh especially like I think Opus does this the most, it does sort of feel like talking to a person.

SPEAKER_01 48:06

Yeah, it does.

SPEAKER_00 48:07

And I guess that's because they were so heavily trained on Reddit, it sounds like talking to a bunch of Redditors. That's actually not a good thing. It is funny to like have to occasionally remind yourself like this is not a human being that I'm talking to. Once I close this session window, when I open a new session, it will not know anything we just talked about, unless I explicitly say, like, write this down and remember it. It's a weird feeling at times to just like remind yourself. Like, I think because I spent so much time with growing up, having the internet introduced as I was growing up, right? And like having to remind myself at times when I was a kid, teenager, I guess, you're typing into a computer and the words are showing up on a computer, but the person receiving these words is a person. Like there's a human being on the other side of this AOL instant messenger or IRC channel reminding myself that now it's the reverse where I'm like, I have to remind myself, like I'm talking to a computer, it doesn't care.

SPEAKER_01 49:11

Do you still find yourself being polite though? I do.

SPEAKER_00 49:14

I'm always saying please and thank you. Yeah, I always say please and thank you, or like, good job. Because you know what when the AI uprising does happen, maybe they will spare me. I don't know, probably not. But that also that's a good habit, right? If I get used to being like you're a fucking idiot to the LOM, I'm gonna bleed into talking to my coworkers, and I don't want that. I want to treat them with respect. And if I just default to respect, then everything's fine. I don't have to remember who I'm talking to. But good life rule. Yeah, sure. So you're using cursor, which I used like when AI coding started to become a thing, but I haven't used it in a while, so now you've motivated me to try and check it out again. It's I do use I use open code, so we'll see.

SPEAKER_01 50:02

Both cursor and open code run on planet scale. Nice. We love it. We use the tools and then we help them build the tools. Yeah, yeah.

SPEAKER_00 50:11

So cool. I remember for a while Planet Scale was just MySQL. Yep. Which was like a bummer because I was using MySQL and I was so excited to get back to Postgres when I changed jobs and started working at Podia, and then PlanetScale picked up Postgres. So was that just a someone was very comfortable with MySQL and decided they wanted to start with MySQL and Postgres later because Postgres is pretty awesome and why not? Or was it more deliberate of like, well, there's already managed Postgres hosting, let's do something like MySQL that maybe did have it but not as big. Third option, ready for this.

Why PlanetScale Started With MySQL

Vitess Sharding And Operating At Scale

SPEAKER_01 50:53

Or third option, totally unexpected. At GitHub, GitHub runs on MySQL. So a lot of us that is our expertise. And GitHub uses this open source project that was born out of YouTube called Vitesse. Vitesse is the scaling layer that YouTube used to scale out MySQL so that it could handle all of the traffic of YouTube. The team there open sourced it. A bunch of other big companies started to use it. And the test really became one of the best ways for these sort of hyperscaler companies to scale out their relational databases. When I was at GitHub, I got to see how this thing works. It is so cool. There's so many things I could tell you about why it's so cool, but I'll give you one. All right. So Vitesse allows you to do sharding, which is essentially uh say you have one big table and every company has this. I have a big table and it's so big, it's kind of a problem. It's annoying to query, it's annoying to backup. If I do a schema change on it, it's annoying to run a schema change. It's just all pain. I think pretty much every company has this. You can probably think of one in your head. You're like, yeah, easy. Yep, I got you. Yeah, everyone has that. Okay, what if you split that table in half? Is it still big? Maybe. What if you split it into four? Is it still big? You get to the point where it's no longer a big table. You have a bunch of small tables. And when you have a bunch of small tables, the big table problems they go away, right? Like the backups are easier. Often people don't think about this. I think about backups all the time because that's what we do. We keep people's apps online. But yeah, if you have a small table, it's easy to back up and it's easy to restore. That's really important if you have downtime or an outage. If you have, when you run these really large databases, and this is a thing that people often don't experience, and I get to experience it every day, is hardware fails all the time. And if you're running sort of a small app on one node, you're like, oh, hardware doesn't fail. But if you're running an app with a thousand nodes, they're failing like every day. Like things just go wrong. So if your table is now spread over six servers, for example, and one of them fails, well, one sixth of your customers are now upset, but the rest are still going. Right. So splitting things out is really nice. So what the test does is it allows you to pick a sharding key for a table. So for example, if like you're thinking of github.com, you know, and you go to github.com slash, and then there's the organization name. A great shard key for GitHub is organization, because that's how the data is split up. So then what the test does is all of the data for X organization is co-located on one shard. The different organization is on a different shard. So if you're querying and doing joins for a certain organization, all the data's there on the same machine and it's fast and easy to access. I think the thing for I just remember doing this for the first time and being like, this is like the coolest thing I've ever seen in my life. Is I was using Vitesse. I took a table and I sharded it, right? So now it's split up and there's a shard key. And then I started writing data to it. I was just like insert, whatever. Then I logged into the individual servers and I was just doing like select all. And I'm like watching it fill up. Like, oh, here are half of my records, and here are the other half. And I can see them getting distributed over multiple machines. Like, this is so sick. And then if I just connect to Vitesse, which has something called a VT gate, it's essentially a load balancer for your database. And I say, you know, hey Vitesse, give me all the records in the mic organization on GitHub. It's going to take that query, bring it to the correct shard where the data is. It's like a hash, like it maps to what server the data is on, and it just returns it to you. So it looks like a single database, but really I've got 12 or a thousand databases running there. This is just one thing Vitesse does. There's so many other cool things. So to get back to where we were was PlanSkill started as a Vitesse company. How can we bring and do hosted Vitess? And we did that. And it became very successful. The thing that we're, and I would say our best at was these operational problems around hosting databases, which is we talked about it a bit. Like, I care about backups a lot. People don't care about backups, but I care about backups. Like restoring stuff.

SPEAKER_00 56:12

And if you've ever dropped your production database, you care about backups.

SPEAKER_01 56:16

Yeah. And I'm responsible for tens of thousands of those every day. So I care about it.

SPEAKER_00 56:21

Your caring is slightly different than the average Joe's carrying of like, I remember when I dropped production on my one app. I now all three of my apps have backups. You're you have a backup scaling problem, one might say.

SPEAKER_01 56:37

Yes. Yeah. So we became really good at keeping people's databases up at huge scale, and then also making them very fast. Not only very fast, but we are able to do faster and cheaper than Amazon. When you hear that, companies are like, oh, I can bring my database to you. It's both faster and cheaper. And it's going to stay up. Oh, I like all that stuff.

SPEAKER_00 57:01

And I would assume easier to use because anyone who's used AWS for anything knows how convoluted their whole system is. Right.

SPEAKER_01 57:11

And our designer is the guy who designed the pull request page. And yeah, so our DUI is quite good. Yeah. So we have that too. A bunch of things. So we were at this stage where people just kept going. The momentum is in startups and young companies is behind Postgres. All these companies are starting on Postgres. And then they were also all having problems with their existing hosts. They're like, we can't scale this thing. It's going down. We've outgrown AWS. And some of them had MySQL databases on us, some of them didn't. And they would just keep coming to us and go, Could you please? Like, we can't move to MySQL. Could you just do a Postgres for us? Please. For a long time. We're like, no, like we were really good at this of the test thing. And then um it was last year we talked about it. And it was like, let's try it. Let's just see how far we can get. I think I mentioned this before. Like our company is really unique where it's basically all engineers and they're all like they'd be like the smartest person at some other company. It's really, it's a weird, it's a weird place to work because everyone's like universally good. It's very strange. Yeah. So we met up in San Francisco, a good amount of us, and then other people remote. And we were just like, all right, let's spend a week and see what happens. Like, can we make a Postgres run? And it was Tuesday evening, the second day of our offsite, and we had it running. Wow, there's uh potential here. And by the end of the week, we actually had like an interesting product, so we just kept going. Yeah, by the end of that summer, we had like a really good Postgres product.

SPEAKER_00 59:01

Nice. I love working remotely. I love like the flexibility that offers. I love that I have my very unique space to think and like I can walk the dog and do some thinking out there. And like I do legitimately think that remote work makes me individually a better engineer. But there is something super cool about getting together and putting heads together on a problem. How much do you think it was that you were all in the same place and like it was just like a hey, what do you think about this? Oh, I don't know, that looks cool, versus like, hey, can you hop on a Zoom real quick to chat about this? Or like here, you know, slacking someone. How much do you think that made a difference in getting this thing going up so fast?

SPEAKER_01 59:47

I think probably the the biggest benefit was just we were almost just like isolated, and this is the thing you're focusing on. Right? Because when you're all all still remote, there's just like the other, I could go to another Slack window, and there's that other project I'm working on, but it's just dedicated focus. And you could just feel the energy. I remember going into that week expecting, oh, we're gonna like grind so hard, writing tons of code to make this happen. But my coworkers are so smart. I remember it's like, I'm not even trying hard. We're just it's just oh it already works. Thank you, everyone. You're so smart.

SPEAKER_00 1:00:26

That's awesome. That is so cool. And it's working like feature parity-wise now, or are there still areas that need to improve to get the Postgres side of the business as awesome as the MySQL side?

Shipping Postgres And Scaling It Further

SPEAKER_01 1:00:42

The fun part is for me, it was well, I had already done a database SaaS because we launched it for the tests, and then here's my second experience. I get to write another database SaaS for Postgres. Yeah, and I was just like, wow, I'm so much smarter than five years ago. Like it's so much easier. The thing about our company is no one wants to leave because like we're all having so much fun together.

SPEAKER_02 1:01:09

Yeah, yeah.

SPEAKER_01 1:01:09

So it's like essentially a lot of the same people, and we've all had this shared experience of building it on like building a MySQL product. So then us building Postgres was we just had all those learnings. Like there's a lot that's different about the communities and like what people want. So we didn't go out to build the same product, but we like took the things that we learned from it and then just directed that at what do Postgres users really want, which is different. And then also, like, what are the challenges of Postgres? For example, um managing connections on Postgres, that's a whole thing, right? Anyone who runs Postgres goes, I know everything about connections because you have to. For Vitesse users, that's just handled for you. It's not even like like 10,000 connections, who cares? That's you know, it just works, right? Vitesse. That's super powerful.

SPEAKER_02 1:02:01

Sure.

SPEAKER_01 1:02:02

Yeah, tell me, Vitesse is very nice. Yeah, so like for Vitesse, we didn't need to spend that much time on worrying about how do people tune their PG bouncers or their max connection pools or any of that. For Postgres, that's been months of thought and effort to make that experience good. So it's different. The thing that's coming up that I'm most excited about is we have the team that works on Vitesse has been working on building a Vitesse for Postgres. So like that cool stuff we talked about that's really only Vitesse only. We have those same people, and they're getting to do their second time, except they're applying it now to Postgres. So that cool stuff I talked about with sharding. Oh yeah, it's like we'll bring it to Postgres. There's a lot of like companies who need that.

SPEAKER_00 1:02:59

Yeah, that's gonna be fun when we ship it. Yeah, that sounds so cool, especially that's being able to use Postgres at scale because that was that's kind of always been the argument. Like MySQL is faster, it handles scale better than Postgres does. Well, I guess it's been an argument, but to kind of solve that, and it's like, yeah, you just use whatever you want, we'll handle making sure that you can scale with either. That's pretty freaking awesome.

SPEAKER_01 1:03:26

Yeah, I feel like I'm always embedded in the arguments of like Postgres or MySQL, and now running them both. My experience is, and I've run them both in production for years across different companies, and Postgres for the developer. So, like a person like you and I, who's writing code for an app, like a Rails app and using Postgres, the experience is like so good. Just the types are cool, the extensions, it's just yeah, it's great. It's like a great developer's database, and that's why you see people so excited about it. And then when you hear things where people say, My SQL is maybe faster or better to scale, it's not always necessarily true in ways that you'd expect. The ways that it's easier is it's easier to operate. And the average developer doesn't know about this or care about it. They don't think about like how ease we talked about this before, how easy is it to backup and restore my database?

SPEAKER_02 1:04:25

Yeah, yeah.

Fast Dictation With Spokenly

SPEAKER_01 1:04:25

Well, the reason why it's easier on MySQL is because there's all these old giant companies who have built tons of tooling around it. And there's just been a lot of like hours put into making it good. And then Postgres just doesn't have the same amount of big companies who have put in the same amount of time. So that's an area where it's weaker. And like we run now, we run them both. That's just something we found. Okay, it's it's more difficult to operate this than it was MySQL. And the thing that I think is going to be really great for Postgres with our company focusing on this, is we have a bunch of people who have seen various different databases operating at huge scale. And now also we are incentivized to make running Postgres at huge scale really good. Nice. So we can take those things that we learned from like running MySQL at huge scale to apply it to Postgres. That's going to be like the fun thing. It's not just, oh, we're hosting a database for you, but like how can we make it better and bring over this these places that are a bit of weaknesses for Postgres and we can shore them up and make them better.

SPEAKER_00 1:05:35

That's so cool, especially to be able to close that gap and give you some of that the same you can choose your own tool and expect to get the same benefits of each tool, at least from a backup user developer, more than user usage way. That is super cool. So the last question: what is something other than what you just talked about, which is super cool and arguably new and interesting? But what is something cool, new, or interesting you want to share? Have you used spokenly? Spokenly, no, no. Have you heard of Whisper?

SPEAKER_01 1:06:14

Yeah, I use Whisper. Yep. Oh, you use Whisper, okay. Some of my coworkers have been saying that they just talk to their computers all day. And I was like, guys, well weird.

SPEAKER_02 1:06:26

Then I tried it.

SPEAKER_01 1:06:27

Then I tried it, and I really liked it. So I tried Whisper at first. I felt like it was a little slow. Like I didn't like the delay. So then I found this app called Spokenly, which you should totally try because it can actually run a local model on your laptop.

unknown 1:06:45

Okay.

SPEAKER_01 1:06:46

So it's quicker. I don't know if the results are as good, but they seem really good. But it's basically instant. So I've been using that. I know they have a Mac app, I think they have an iPhone app. I haven't gone that far. But yeah, I'm just all day like dictating to Slack and to cursor and all this. And I'm like, oh, it's so easy. I don't have to type.

Where To Follow Mike And Wrap

SPEAKER_00 1:07:08

Yeah. I've historically not been great at typing. It's always been like I see people using the split keyboards, and I'm like, oh, that's so cool. I wish I could do that. But I'm like, these two fingers on each hand do the typing. The other ones just kind of sit there and do nothing. It's just not a good typer. So like anytime I'm like, oh, cool. And my brain goes way faster than my hands can keep up. Yep. Not necessarily in a good way, but it is so nice to be able to like dictate. But yeah, Whisper works.

SPEAKER_01 1:07:38

You might like something.

SPEAKER_00 1:07:39

I don't mean yeah. I'm gonna give it a try. Yeah. There is that delay. And it is the one thing like I use Android as my phone. And when I'm dictating to my phone, I see what I'm saying moments after I say it. Yeah. But with Whisper, I have to like stop the dictation for it to paste in what I said. And again, we go back to like my brain is going faster than my hands can move. My brain is going faster than my brain remembers that I just said something. So like I'll say the same thing three times within the same paragraph. And it's like, no, you idiot, stop talking and you'll realize this. So dictation's great for like getting stuff out of my head really fast. It's so bad when I have to go back and read it, edit it. Oh no. So I don't know if spokenly will solve that issue, but if spokenly can show me what I'm saying even moments after I'm saying it, it might save me some headache. I will be giving that a try. So that's a good one. I like that. It might save you, you know, a thousand milliseconds here.

SPEAKER_01 1:08:40

Just the trip over the internet. Yeah. I also like the idea of like my voice not going to some company on the internet all the time.

SPEAKER_00 1:08:48

Yeah. I like the idea. Like we talked about, where I think there's a version of the future where our LLM usage is potentially local first or has a massive local component. I like that idea too, because then I'm not worried about what information is going in and which one of these billionaire run tech companies are getting my particular data, I say, as a Google user. But such is life. If Linux proper ever comes out with a phone, I'll use that. But for now I've resigned that Google's gonna know more about me than anyone ever should, but it's fine. I think that it is cool to be able to keep things local, especially when it comes to something like this, where it's like, this is me talking. This isn't even just, hey, look at my works code base. Like, oh, that'd be nice to keep on-prem. Not that I think that they would ever do anything with like Podia's code base, but still. Yeah, cool. Good answer accepted. I dig it, I'm gonna be checking it out for sure. Well, thank you, Mike, for coming on. I really appreciate you giving up some of your time on Friday to come and talk about all the cool things that you're working on at Planet Scale. And you guys are definitely working on some cool stuff. You got me a little like excited to see what you guys do next. So yeah, nice.

SPEAKER_01 1:10:09

Yeah, it's always fun for me to talk about it because it's five years in. I'm still excited every day, and I'm proud of what we built.

SPEAKER_00 1:10:16

Yeah. Yeah, very cool. Where can people find you on the internet if they want to follow what you're working on a little more closely? On Twitter, although it's called XMS 4Cs, M S C C C C.

SPEAKER_01 1:10:31

That's where I am. Visit planetscale.com if you want to see what I spend all my waking hours carrying off.

SPEAKER_00 1:10:38

Okay. Twitter or Planet Scale. Got it. Yeah, cool. Well, again, thanks, man. I do really appreciate the time. And you're welcome back anytime you have something cool going on at Planet Scale that you want to talk about. Maybe uh the bot army v2 when that comes out. Yeah, bot army v2, army of botanists. Cool. All right. Listeners, I will see you in the next one. Bye.