Skyvern, Two Years Later: Browser Automation for Everyone

Speaker 1: Hello, friends. This is APIs You Won't Hate. My name is Mike Bifulco. I am super happy to be sitting down and catching up with what feels like an old friend at this point, someone who I haven't talked in. We just checked the calendar, and somehow two and a half years ago, April 2024 was last time Suchintan Singh from Skyvern joined me for a call.

We were talking about the future of APIs in 2024, which feels like, I don't know, a 100,000 chapters ago in the in the story time of developers. Hey, thanks for joining me again today. I'm really excited to have you back. How are you doing?

Speaker 2: Yeah, I'm excited to be back. You're right. I felt I feel like I just talked yesterday. But also, I feel like there's like 80,000 new products, AI products have been released since then.

Speaker 1: So it's a different world. Yeah. It's it's been wild. Like, since then, I don't know. We've...

I've done a bunch of things. I'm sure you've done and learned a bunch of things. And I'm sure Skyvern has been in all sorts of directions. So why don't we start there? First of all, give me like the thirty seconds.

What is Skyvern?

Speaker 2: Yeah. So Skyvern is an open source AI browser automation tool. We help a lot of big companies automate work they would have otherwise done manually. And instead of writing code, they prompt it instead. Really empowering nontechnical people to kind of create their own and automate their own work.

Speaker 1: Yeah. And it's one of those things that, like, when you hear about it, I think you can think of a thousand different use cases for it. Well, just as a reminder, what does, like, hello world look like with Skyvern?

Speaker 2: If you're trying our product, we help companies automate things from, like, applying to a job automatically all the way to, like, processing invoices and reconciling accounts receivable for businesses. So, really, it depends on what the biggest problem that you have, which is both powerful and confounding in its own way.

Speaker 1: Yeah. In many ways, everything under the sun. And because of that, I'd imagine, like, the problem space you operate in is very broad and very large. So let's let's maybe, like, zoom out a little bit. A lot has happened since 2024.

I would guess the last time you and I talked, I would imagine we maybe mentioned AI as, like, something we use and are toying around with and are looking at use cases for. It is it is shot certainly from there to ubiquitous in the lives of developers. And I think it's starting to have this cascade effect where vibe coders are a thing now. I don't know if that term was around last time we talked, but there's also people who are strictly nontechnical who are starting to use tools like what you're building, and products like what you're building. They may not even think of it as a tool, for example.

What have you done in the last two years? What does it feel like now to be operating Skyvern?

Speaker 2: I I think as a founder of an AI company, we've had to reinvent our product every six months. And Yeah. Doing so is almost a requirement because everybody's learning new ways to, like, give AI to people, And we have to pick the best of those and bring them into our product and also dump the ideas that are no longer relevant that were common back then. A really good example is last time we talked, RAG, you know, retrieval augmented generation was, like, the the golden standard for interacting with agents and LMs. And our products are built around like a thought process.

And we recently had to do a full rewrite where we dumped all that from the Yeah. Product that actually made it way better by by doing so. And this is a really specific example of the invention that has happened. Yeah.

Speaker 1: Yeah. Pretty pretty incredible that what was the bleeding edge is now essentially gone from a lot of use cases. Not that Rag is not used ever anymore, but what does that mean for you? What what is it... Was it superseded by?

Speaker 2: So the first... But last time we talked, the first version of Skyvern used to do this thing where it would like... When it when it accessed the website, would basically scan the HTML and scan the screenshot and correlate what's going on between the two to decide what actions to take. And it was based on reg. It would do reg over the HTML.

And it was necessary back then because the models weren't good enough to actually understand how to search it correctly. And as the models got better, that approach ended up just being expensive and slow to operate on. And so a few months ago, we rewrote the entire engine from scratch. And instead of giving the models context, being like here's the website, like what should we do? We said we're like here's what the user wants to do.

And you can search over the website, you can search the screenshots if you so choose. And we were able to kind of make Skyvern 2.3 times faster with this approach because it wasn't actually taking in all those context anymore to decide what it needs to do. And it also got about 50% cheaper for us to run.

Speaker 1: Yeah. Wow.

Speaker 2: And and Wow. But it... But this is something that wouldn't have been possible last year because the models would have listened to much. Right. And so that purchase was invalid last year, but the model is getting better made a certainly better approach.

Speaker 1: So from your perspective, as you're building things for your customers, is is the messaging still transparently the same? Like, it... Your use case doesn't change, we just do it better and faster now?

Speaker 2: Exactly. The problem we're solving is exactly the same as it was back then. And it's... Our customers are actually trusting us to do the innovation for them in this in this sector. Does that make sense?

Speaker 1: Yeah. Yeah. Absolutely makes sense. I'm I'm wondering a little bit the next thing I say what I'm gonna think of this in two years when... Whether or not this will be a, like, a flash in the pan or not.

But how have classifiers changed what you're doing? So is we're probably two or three weeks out from JEV making a big splash as this really incredibly fast tool for classifying information similar to how LLMs work. What does that mean in your world?

Speaker 2: Yeah. So we we... The the day JEV came out, we did a POC of JEV as the core underpinning of our product. And it is incredible. It's so fast and so cheap.

It like you you really don't have much to think about as you're using it. But the accuracy profile of it was basically the same as GPT four was back in the good old days. And and so what we we we tried putting in production obviously and ran it on our benchmarks and the accuracy made it a nonstarter. People have gone... Begun to expect high precision browser automation tooling when they're prompting.

And it just Right. It wasn't at that level at that yet. But if it's anything like g p d four, six months later, the models got so much better that that it just kind of show... Should... Gave us a peek into the future of the right paradigm

Speaker 1: Yeah. So it's almost like, keep an eye on it for a bit and see what what happens in, you know, springtime or whatever as things get better. Yeah. Just in case maybe I jump to the conclusion too quickly here, what is the 100 level explanation of what JEV is?

Speaker 2: Yeah. So the the way the the way I think about JEV is it's basically a classifier on any task. Before, I used to work a lot with traditional ML and classifiers have to be trained for specific use cases. JEV doesn't. And that means that you can give it text and ask it to tell you something that you already know to be true within the text.

And so for browser automation you can ask it to ask it across these elements like what do wanna interact with. And it'll be able to tell you that with pretty high precision. And because it's not generating text, it's just classifying, it's super cheap to run super fast because it doesn't have to do like the second pass pass propagation that an LLM would have to do. But it means it also can't. It can't be be unstructured as a consequence.

So when Yeah. First came out, one of the biggest problems it had was it can process images, which then Right. Five five companies solved the next week the next week after after that. So That seems to be the way it goes. Yeah.

Speaker 1: And the speed is another thing entirely too. I think we've all gotten accustomed to you punch something into your LLM of choosing and wait, I don't know, three seconds, six seconds, thirty seconds in some cases, and it comes back and has what is usually a satisfying result, although maybe longer or slightly hallucinated. By comparison, these classifiers are insanely fast. And so I'd imagine like the benefit of that when it when it gets accurate enough for you will be yet another, you know, 2.3 x faster feeling in some some cases.

Speaker 2: Yeah, definitely. Actually, when JEV came out, the first thing I tried to get it to do, it was a bit of a sidebar, was I tried to get it to play RuneScape. I don't know if you've heard of this. But somebody put out this private server that you can control with, like, machines, and I tried to get it to, like, control the character and, like, actually progress in the game, which which ended up being a really fun, like, way to see whether it can, like, move as fast as the game engine does, which LMs definitely can't.

Speaker 1: Right. Yeah. Man, Mike in college would have made a full on business out of playing Diablo two and just, like, collecting up the best things on screen for sure. Tell me a little bit then about, like, lots has changed in our world. This stuff is changing so rapidly.

And like you said, it's all changing every six months. I think that probably means that the types of people who are using Skyvern are changing just as well. And so what are what are your like shapes of audience look like if you break it into buckets of maybe technical expertise?

Speaker 2: Yeah. So it has changed a lot in the last two years. And I'm gonna fast forward to the answer and then we can work backwards to like what what worked. Today, we sell to non technical teams. Most of our customers are people within companies who are usually doing the work manually, who know it really well, and they wanna automate it.

And before they had to ask a programmer for help or automation engineer. But now they don't. They can write their own prompts. They can actually like see see the agent working and edit the prompts as needed and get get it under production. And that is our primary focus.

That's our primary user today. But that's not where we started. Last time we had this call, our primary customer was developers who wanted better tooling, like a better playwright basically to go automate websites. And over time has changed from you know developers who just needed help writing code. We launched in Hacker News, the top column of those kind of things help me write code.

To increasingly higher levels of abstraction to the point now where we are helping mostly nontechnical people who've never written a line of code in their life, can't read code, actually do things that they never thought they could.

Speaker 1: Yeah. What does that mean for the nontechnical people? How how are they using it? Is this a sort of product where I can go in and just type what I want and I get outputs? Am I...

Is it being driven by an agent? Something like that?

Speaker 2: Yeah. So the way Skyvern works is you go into it and you can write a prompt or a series of prompts that let it accomplish a task. And so let's say that you wanted to use Skyvern to go fetch your utility bills. You could give it four prompts in a sequence to run. The first one is log in.

You give it your credentials. Maybe maybe some two FA information. The second one would be like go find the page with the invoices. The third one might be like, apply a filter for the state range. And the fourth one would click download and grab the invoice and save it.

And so that is something that, you know, before you'd have to write a pretty long playwright script for, but now you just write the four prompts and then the agent kind of understands that... Does does the action of the website, writes its own code, and maintains it for the user so they don't really have to think about it ever again.

Speaker 1: That's pretty amazing. That is, to a large extent, the dream of now everyone speaks code to the extent that they need to. I would imagine there's a bit of a learning curve even still. What have you learned from working with people who've never written code before who are suddenly end users of what is inherently a very technical thing?

Speaker 2: The the the thing that makes programmers successful and the thing that made me successful as programmers is they tend to be systems thinkers. You see a problem, you break it down into the components of it, and then you implement each component to carry out a specific task. We find that in our users, they still have to be system thinkers to be really successful. Like they have to be able to take like an abstract thing they wanna accomplish, break it down to the components that come together to make that happen. And and instead of writing code to it, they just write the prompts instead that compose that system and execute.

So I think I think the profile person is still relatively the same, but the the the the language they write is English instead of your bare

Speaker 1: Sure.

Speaker 2: Language like

Speaker 1: Perl. Yeah. Something something that I would imagine a lot of nontechnical people have never even, like, bothered to try envisioning. I think that's a really interesting idea that that you suddenly have these very highly sophisticated tools at your fingertips to get things done with. As you've worked on this, have you come across any use cases that are particularly outstanding to you as creative or off the wall weird or anything like that?

Speaker 2: I I think the coolest person I talked to actually found us from the last recording of this

Speaker 1: Hey, no way. Shout out.

Speaker 2: Yeah. It was really cool. It was like a... I live in Canada and it was a mom from the next city over.

Speaker 1: No way.

Speaker 2: And she didn't know how program. This is 2024. So, very long time ago. Kind of remarkable. She didn't know to program and she was building like a music processing app for her son.

Wow. And she was like going back and forth to deep seek on how to like what code to write to like get get this music that would be published to publish into her app. And she was like stuck with this like one website that just didn't have an API. And so she was looking for our product and how to do it. And she just kept going back and forth with an LM.

So we're like, do I do this? How do do this? And it's like, don't understand anything is spitting up. I'm just gonna try it. See what happens.

And she just kept going through a loop until she actually got it working first on. And she didn't know any... About any anything... Any code at all. And just hustled through these, like, archaic interfaces that we now we take for granted.

You know? Sure. Wow. Made it happen.

Speaker 1: The tenacity of that to just stick with it and, like, be hopeful to an extent that it's gonna work is surprising and very, very cool. Does that mean you're working with people... So this is, again, far far less technical people than in the past. It probably sounds like to an extent you're working with people who are mid... Midway technical.

Do vibe coders come into the... In your world at all?

Speaker 2: Yeah. So Vibe coders... I think Vibe coders are our primary audience, I would say. Yeah. Okay.

Yeah. Okay. And I think the definition of Vibe coders is just expanding and expanding to include people who've never seen a line of code before.

Speaker 1: Yeah.

Speaker 2: I don't know if you're I

Speaker 1: would say that's on me.

Speaker 2: But I don't know if you're experiencing this, but these days, I don't even read the code that AI outputs anymore. And it's a bit bit extreme development, I would say, but it

Speaker 1: It's a it's a lot more management now than it was, you know, prior. Like, write a really, really solid description of what you want. Write really good rules for making sure it's solid and and working and testable and observable. And then, like, the mystery meat in the middle is becoming less important, certainly, especially week over week as models on the foundation layer get even better. Yeah.

It's it's a fascinating thing to experience, especially as, like, someone who spent, gosh, twenty plus years, like, sitting and executing code and watching my debug dot print to see what's going on and and trying again. You know? It's it's matured so quickly. Yeah. That's really interesting.

Speaker 2: So so the way I think about it is Uh-huh. Five coders were a small class of people before that would trust the output of an LLM and publish it. And I think that cohort is just expanding to consume programmers and non programmers. Now everybody's a live coder basically, if that makes sense.

Speaker 1: Yeah. No, absolutely makes sense. It's it's a very, very different world we get to live in now. And I think to an extent, technical people like you and me should be embracing it because it's just the direction things are headed. But I also think, like, your experience as a builder for as long as you've been doing this will help you to build better things for people who don't know that they should be worried about, you know, man in the middle attacks or or their prompt getting corrupted or whatever it may be for you to use

Speaker 2: your environment to the front end. Yeah. Like, sources.

Speaker 1: Yeah. And imagine trying to explain that to someone who's just been vibe coding for the last week, and they... Like, these are unfathomable unfathomable problems at that level. Certainly. Yeah.

It's really interesting. So from the perspective of APIs You Won't Hate, a lot of our audience are your... Gosh. What would I even call it, like, traditional developers in that sense, technical programmers programmers. And I think they are very interested still in, okay.

Well, I wanna have the version of this that I can use that is source controllable, that is type checkable, and all those things. What does Skyvern look like for someone who's on that side of things, like building with Python or TypeScript or whatever it may be?

Speaker 2: Yeah. So one of the cool things about Skyvern is that as the agent runs, what it's actually doing is generating code under the hood and saving it and maintaining it for you. And so we do have a cohort of users that are very excited about traditional development and what they'll actually do is export the code that we generate and save it inside the repository. The second part that's maybe interesting is, and this this maybe is a little bit spicy, is you could argue that browser automation is like the ultimate API. It's like arbitrary instruction that should in theory work on any website in its in its final form.

Yeah. Maybe maybe there's this like really cool stat I came across like two years ago, which is that there's about 1,100,000,000 websites in the world and only 900,000 APIs that exist.

Speaker 1: Yeah. Wow.

Speaker 2: So there's a really wide gap between APIs You Won't Hate, as you would say, to the total pool of websites in the world. And and maybe the... There's there's a possibility that the the ultimate API is just like a text box. What do you wanna do with this product? And then it just does it for you.

Yeah.

Speaker 1: Yeah. I did some diving into your docs before, and I think you're you're enabling that in more and more ways. One of the interesting cases that I came across was you have, of course, makes sense, a connector for MCP services. And so that probably means some some amount of your users may not even be doing this thing as a fully automated way, but, like, punching in the tool call to their, you know, chat GBT once a once a month, maybe to fill out their invoices or to submit their payments or whatever. That's a really interesting change in use case.

These are people who are like, it's a utility to them. Maybe it's more so a tool to them than a developer in a sense. How how has building in that direction shaped what you're doing? Like, are you able to listen more to the use cases of those folks? Are you getting, like, sign signals that your telemetry is shifting one way or the other from API use to tool calls to, you know, just in in browser calls?

Speaker 2: I would say most of our customers either interact with us where you either interact with us through MCP where they are using a different AI product to create these automations, or they're using us like something like Cloud Code. Yeah. Where they are using us to actually build the build the automations and so on. And and what was really interesting is I would say the top thing that we integrate into is not like a direct API call, but it's like retool. It's like somebody's internal website inside the company that is now calling Skyvern to go do something.

Every tool needs to be... Needs to do internally. Does that make sense?

Speaker 1: Yeah. Yeah. I'm sure I can think of half a dozen use cases that would be very interesting internal things for me as we're we're building out a craft work here too. I think you mentioned this earlier, but also a very interesting angle for for Skyvern is that you're open source too. So what does the open source story look like?

Speaker 2: Yeah. So I think when we started the open source story, it was super simple. It was... You look at all the popular browser automation libraries, Playwright, Selenium, Puppeteer, they're all open source. And so you could imagine, like, bottoms up adoption is driven that way that way and, you know, get developers excited.

But but now we see ourselves going more in the direction of n eight n, which is like, you know, n eight n, you could say it's like... Was like a tool for like semi technical people to create their own automations, like if this is in that style. And it was open source, so they could actually deploy it into their instances and run them.

Speaker 1: Right. You

Speaker 2: see our product being pushed more and more in that direction where, you know, as people move away from, like, hardcore programming, writing their own code to, like, actually just deploying apps easily, that core user is just increasing and increasing.

Speaker 1: A very interesting angle on the competitive part of it that you really are, like, start start in a world where not even not even long ago, but we were writing these complex scripts to be able to do XSS parsing of what's on a page after a fetch. Yeah. Playwright comes along and then makes that a little bit better and a little nicer and more deterministic until the... You know, whenever your your local credit union changes the shape of their web page and then everything breaks. Breaks.

And this is maybe like a sweet spot for these nondeterministic calls where you give it a goal, and it can go and do things that are useful for you and still give you presumably a typed output or an output that's predictable in one way or the other. Yeah.

Speaker 2: And what's what's becoming increasingly important is understanding when to loop in a human again. Like, many of our customers will do regulated work. Like, they'll help companies incorporate where they need to, like, file a form with the IRS or they're, you know, buying stuff for areas of the world where you can't actually buy products on Amazon, for example. So you need to, like, process that transaction. Do you trust the agent to put in a credit card?

You know? Right. Like, do you trust an agent to actually, like, fill in a Social Security number correctly? Maybe. I do.

But not everybody does. Yeah. Not

Speaker 1: everybody Do you have guidance

Speaker 2: on that? What we find is, like, trust is built off experience. And so everybody should and does come in with this, like, mistrust of agents. Like, can you actually trust them to do the right thing? And so how can you like create that trust?

Well, you let the agent run and prove in like a safe way that it's actually gonna do the right thing every single time. And so in our product, we actually have very thoughtfully put in cases where it'll push to a person to approve or take over the screen and actually behave as the agent. And we find that they'll start with that. And then they'll get frustrated because that'll be annoying for them. Right?

Because they just basically done the right thing. And then they'll eventually take that away. Yeah. But if you take it away from the start, you don't you don't give people the ability to build trust, which is actually very Sure. With these Yeah.

Systems. Right? Like, I didn't... I I read all the code I used to write last year. Yeah.

And over time, I learned to trust that, okay, it'll probably do the right thing as long as I propped it this way. And then I stopped reading the code. Sure. And that's true with any kind of system no matter... And any kind of agent human interaction, I would say is like you...

The trust is built over time and experience. Yeah.

Speaker 1: Yeah. For my longtime engineering friends who've recoiled in horror at the idea of not looking at your code, I think it's very similar to people used to look at their assembler, you know, assembly level code to make sure that it was compiling correctly and shifting around memory in all the ways. And there's probably very similar discomfort when you move from there to c or c plus plus or from c plus plus to Java. Right? Like, I I wanna control how my memory is being allocated and not similar growing pains along those ways.

It's the nature of of this change to a very large extent, and I think that is the discomfort to build into. Maybe maybe that's the whole thing is we're building through discomfort right now as engineers in both directions. Maybe as engineers and and as people who haven't touched this thing before. Automating your world, that progressive adoption of functionality is a super, super cool idea. And to be honest, I'm not sure it's something I've heard put into words quite quite as well as you just described it there too.

I think it's a really interesting idea.

Speaker 2: The most interesting part of... I I love the analogy of compiled languages because Yeah. C or rust are still useful languages. It's still useful to have control over memory. It's still...

It currently useful for certain set of applications to go low level and hyper optimize for speed. Yeah. Right? Or memory profile or whatever, but not everywhere. Right.

And I think this is a distinction that matters when maybe why Python did go the way it did was that sometimes ease of use, the value of that exceeds the kind of low level control. But both are valuable and they will remain valuable forever. And I see that a lot with our product. It's like there are cases where you can trust the agent and it's not really consequential. It'll do the right thing or wrong.

Who cares? As long as they tried, it's okay. And there are cases where you wanna make sure it did the right thing for sure. Yeah. Right?

And and both are incredibly important.

Speaker 1: Definitely. I unlikely that NASA will be anytime soon giving their astronauts a prompt as their sole control of the spaceship. You know? And, like, we're we're doing the same thing here. It's a it's a different thing.

We're doing in a lot of ways, like, the comparative equivalent of ordering a Big Mac as opposed to, you know, send me off to Mars or whatever it may be. Yeah. That's... Man, there's there's so much so much interesting space to explore and all that. And a lot of, like, people caught up in this who the adoption curve is a really interesting thing to get through with them.

One of the things I also really like about your product that I think is helpful for people apart from open source, right, if you're comfortable with the Go compiler yourself and do all that goodness, run off off to the races until I'm sure at some point, it's like nicer to have a hosted service, and that's that's where you start to win. But also, you have a a pretty generous free tier as well. Talk to me a little about the pricing of the product and how you get people to adopt that way.

Speaker 2: Oh, man. I I have no idea if our pricing is good or not. I'm gonna start the entire answer with that. Have no

Speaker 1: idea if

Speaker 2: our pricing is good or not. The reason I wanna say start with that is you often will never know if your pricing is correct or not. There is a couple of things you wanna accomplish with pricing. One is with AI tooling, people are skeptical of it until they've tried it. And so you need to make sure they're able to try it so they can kind of move past that skepticism pretty quickly.

And the free tier is really important for that. Can you give them enough of a taste of where they hopefully find some value from the tool right away, but not so much that it's expensive like gonna break the bank for you as a company to support that. And that's the line we've been trying to prod here. And then after that, as you look at different pricing tiers, right, it's like, how can you help individual people? Often a pro tier is good for that.

How can you help teams? You know, a team tier is good for that. How can you help enterprises who have, like, very strong reg... Like, regulated regulatory requirements like HIPAA or security requirements like SOC? How can you help them?

And of course pricing is differently because the risk associated with each tier increases dramatically. And that's something that we've spent some time thinking about. And we find thinking about it like an orders of magnitude is the right way. Free is great for trying. Tens of dollars is probably great for, you as a person.

Right? Hundreds of dollars probably good for you as a team. And thousands of dollars is probably reasonable for a company who wants like legal stipulations for the place to make sure that their data will be safe. Yeah.

Speaker 1: That's a very, very well reasoned approach, I think, and it has a story for the sizes... Many sizes of people that would jump in and onboard with it. Thinking again about the people who maybe are on the on the edge of, like, you you might be a good candidate for... You might be a candidate user of Skyvern. What are the types of things that people should be, like, seeing as a signal of, oh, you should go and try this.

If you're if you're hearing this kind of problem coming up in your day or in your your uncle's day or whoever it is, your neighbor who's asking you how would I do this, or can you make me an app for that? What are the signals you listen for and how would you guide people to steer in that direction?

Speaker 2: I'm gonna half answer this question. Yeah. I'm gonna half answer. I promise. We talk when we when we talk to developers, we find that they are really really excited about building an automation system.

And that is definitely the place where if you are excited about that then we're not the right tool to do it. But usually what happens after you build an automation system, especially inside of a company, somebody has to actually build the automations. And I find most developers hate doing that part of it. It's like, once the system is built, who's actually gonna go in like write the code to like, know, generate an insurance quote or like who's gonna write the code to like submit this PO or purchase order to this system? And that's what our developers hate doing.

I find that's the kind of spot where a product like ours is exceptionally useful. This comes up over and over again as we try and sell our product. It's like once the system is built, who's actually gonna build the automations?

Speaker 1: Right.

Speaker 2: It's kind of like building website. Like building a website builder is super exciting. Actually building a website for a person is like kind of, you know, nobody like touching CSI.

Speaker 1: You lose steam right away. Yeah.

Speaker 2: Yeah. And so for automate... For automations, like, you know, whenever somebody wants something automated, the the question should always be like, who... Are you just gonna build one or two or three automations? Maybe it's fine for you to do it.

Or you're or you need to build a 100. Yeah. And if you need to build a 100, do you wanna be the one building a 100? If not, then then you wanna look for a tool that empowers people who who are excited to build a 100 to build them. Yeah.

Speaker 1: Totally. Totally.

Speaker 2: I don't know if I answered your question, but

Speaker 1: You did. Definitely. So we've also talked that the world has changed a lot, certainly since last time you and I talked. But, I mean, in a lot of ways since last month, the... Our world keeps changing.

I'm curious as you're looking forward, what are you excited about next? What do you think are the changes coming down the pipe?

Speaker 2: We talked about system one models earlier, the classifiers, the Java style models. Yeah. I'm really, really excited for those. I think that they... Just to recap, they're they are models that can identify and map some inputs to some, like, specific buckets or classifications.

And they're super cheap and super fast. I'm really excited about those. I think particularly as they get smarter and they can run on your computer instead of a data center, your phone maybe. They'll be exceptionally powerful and particularly using those navigate interfaces is something that is I think inevitable. That part is really exciting.

I think the second part is I don't live in The Bay, but I go there quite a lot. And I think the Silicon Valley is like way ahead in the AI adoption curve than the rest of the world is. And I think that I'm really really excited for more of the world to learn about what they what they can actually do with AI. You know, have go basketball with this guy who who who told me that, you know, his company needs to do like some crazy impact assessment before they're allowed to bring AI into the company. And, you know, I think once the people working at the company get to get a taste of what it can do, I think the the people who imagine and are...

Who are imaginative will just, go crazy with ideas and maybe not sleep for a week as they're prompting away and building crazy stuff.

Speaker 1: Yeah. Right. I think there's lot of reasons, you know, maybe Skyvern's next class of products should be like a nice pillow or something like that. Let your let your end users relax after a month of binging on the thing. Minh, that's...

It it is really encouraging to see the way that technology is becoming accessible to a lot of people and that access to information is, in a lot of ways, becoming more more reachable for for all sorts of people. I think products like Skyvern are are a gateway to a lot more ideas for people. You and me growing up as builders, systems thinkers also produce a certain type of output that is maybe typical of systems thinkers. But I think there's probably... You know, as more creatives get into this world, as more people coming from other backgrounds come in, I think we'll have a a large variety of, like, new software that comes into our world, thanks to tools like what you're building.

And that's that's a reason to be excited, I think. There's, like, all kinds of reasons to be scared, and we can get into that on, maybe a Friday, the thirteenth episode of the podcast sometime. But, yeah, it's it's cool to see. I'm also looking forward to the future and definitely looking forward to, like, the changes that, will come with Skyvern. I...

God. I cannot imagine what it's gonna be like two years and four months or whatever from now, but you are more than welcome to come back and and have a chat about any changes that are coming anytime soon. Before I let you go, there are a couple of things I'd like to ask. For starters, is your team hiring at the moment?

Speaker 2: Yep. We're hiring we're hiring for two roles. One is we're looking for product engineers who, like, love helping nontechnical people program. And it requires quite a different kind of thinking because a a lot of the tooling that you find yourself valuable through the command line are also useful for non technical people, the command line is not the right interface for them. And so we are hiring for our product engineers to help us with that.

And then second is one kind of underbelly of a tool like ours is kind of dealing... The web is like very adversarial. There's a lot of websites that wanna make sure you can access them. And we we work... We we...

We're looking for people who are excited to kind of understand how that system works and kind of ethically access these websites that maybe are just, like, inventing everybody.

Speaker 1: Yeah. Yeah. There's a lot of that right now, and I think interesting to explore and to find the ways to do that correctly, ethically, whatever

Speaker 2: the Yeah. And that's that's the nuance point. It's like, definitely don't wanna encourage bad behavior. Of course. Like, obviously, this this can be used for abuse and tons of negative negative stuff.

And that's not the role I wanna play in the world. But there's a lot of also value creation that you can create doing it ethically. And that's something that we we care a lot about.

Speaker 1: I'm glad you called it out in that way too. Where's the best place to find Skyvern online?

Speaker 2: Two places. One is our open source repository. I think last time we talked, just launched it. So it had like zero GitHub stores. And now we have 22,000.

So it's grown a bit since then. Yeah. It was pretty cool. And the second place is on on our landing page, skyvern.com. You can check out the kind of things companies do with us.

And if it's interesting, give us give us a try.

Speaker 1: Yeah. And where's the best place to find you online?

Speaker 2: The play... You can find me on LinkedIn or by email. You can email me, Suchintan@Skyvern.com. You might find me on Twitter, but I will never respond there

Speaker 1: because For many reasons, I'm sure. Yeah.

Speaker 2: For many reasons. No doubt.

Speaker 1: Yeah. Well, I'll make sure you drop links in the show notes for all of the things we just mentioned, jobs, Skyvern, open source, where to find you, LinkedIn, all that. And if people wanna send read only messages to your Twitter, they can do that from there too. Suchintan, thank you so much for joining me today. It's been really great catching up with you.

Looking forward to seeing what happens next for for y'all and come back anytime.

Speaker 2: Yep. Thank you. Of

Speaker 1: course. Take care.