Guillermo Rauch: One Stroke Dragon › First of Kind

I really think that human effort is still incredibly underrated. All of the success that I've gotten is by obsessing over simple ideas and just pushing them way harder and further than would seem reasonable or possible, and occasionally having to go against the grain and having to go against common wisdom. So there's an element of being a rebel.

Yeah. Yeah. Yeah.

I think more so than a lot of my engineering peers, I've always looked at building a product or engineering itself as a design problem. I've always worked backwards from what is the interface of this thing to the world, using design tools to model my thinking. So even when I designed the first command line interface CLI for Versell to deploy, I started out with laying out artboards on sketch on the application, saying, okay, when you run VC deploy, this is what you get, and this is what happens when this other thing happens.

But I've also liked the engineering centric approach of you can't just design perfect things in a vacuum. Your little design tool needs to confront reality as soon as possible. Which is kind of like the mission of Versel, if you think about it. Is can I deploy so quickly that some other human agent, some system will give me feedback that'll inform that next step. And so I think it is about the convergence in many ways of design and engineering. I dreamt of a platform that'll bring both closer together. I think another important bit about my past is when I was a kid in Argentina, my dad bought us computers and he brought a vision to my brother and I of software will eat the world. He didn't have the language of Andre yet, but that was his whole thing. He didn't know how to write software, but he knew that people that could would have some kind of advantage. That was kind of his contribution. My mom's contribution was people that know English, speak English fluently, will have an advantage. And you learned those two things simultaneously. Yeah.

This idea that you can see something, go anywhere on the web, click view source, and then be able to reverse engineer what's in front of you. Right.

Yes. And I remember when Google came out with Gmail, this was literally the most important breakthrough in the history of dynamic HTML because they said, well, you could download Microsoft Outlook and check your mail or you can just go to gmail.com. We'll run the whole application there. And most people think of it as like, oh, it was infinite storage that made Gmail magical. But for me, Gmail was my siren call. When that came out, it was this convergence of Ajax. It was this realization that you can create desktop software like experiences inside the browser and therefore anybody with a browser could use your software, and it felt like overnight the CD-ROM was done.

It's like we are no longer shipping software physically. This is how we're going to be shipping.

It's that convergence of two things, because on one hand you have the idea of unlimited storage that comes from the cloud. So if you say my email's interface is the web browser and that goes to a server and that server is in the cloud, all of these elements are connected which lead to such a better user experience, right? You don't have to worry about backups, you don't have to worry about storage. But the idea that the web page would come alive with JavaScript, that's what really got me into this world. And I remember taking jobs as a freelancer because when I was in high school, I had these two competing priorities. I had to, like, get good grades at school, and I was literally just working almost every night with my clients in Europe as my second life. And I remember I would take jobs specifically where I could go deeper into these interests. They never asked for Ajax to make the CRM interface faster. I wanted to create a higher quality product that was more responsive. And then the other thing that it was kind of like a domino reaction, because that also led me to the world of real time. Gmail at one point said, well, why are we stopping at page refreshes? Why are we stopping at pulling emails on a list and clicking them? Can we enable real-time communication between people? And they launched Gchat almost at the same time, perhaps some overlap with Facebook chat. Mhm.

Yeah, there are a lot of elements of Verscell which are about can I disseminate this power as broadly as I can. That's why I got into open source. You know, it was kind of possible to create a real-time communication system, but only Google and Facebook could do it, especially at that scale. So that's why I created socket.io. And then I realized if you're someone that maybe doesn't have a strict title, you're not a designer, you're not a front engineer, you're not a backend engineer, you're not a DevOps engineer, you're a person with an idea and you want to ship, what is the tooling and infrastructure for those people? And you could argue, well, there were things before Versel like Squarespace. They allowed someone to put up a website online, and there were things like Kubernetes and very deep tech infrastructure systems, but there was no system for everybody that could scale up to the largest and most ambitious ideas and scale down to just make it magical, make the experience of deploying an application one command. So there was an overlapping interest there of I want to democratize this to as many people as possible, and I also want to take on the engineering and cognitive challenge of simplifying something that takes weeks or months. Can I bring it down almost mathematically to its physical limit on latency and its simplest design from an interface perspective, which ended up being for us one command deploy?

I think there's something tactical, which is I call it exposure hours. There's something about absorbing a lot of information about the field that you're interested in and creating a huge amount of empathy with the end user. And so to your point, I think there's something about you are the end user of your product and having a dissatisfaction with the status quo. And so I had that ability to actually know how to assemble five different systems to deploy a production grade application, but I also had that, oh my god, like it could be so much better. It could be so much faster. This is not a good experience. And so I had my own exposure hours, but I also had a huge amount of empathy for every developer in the world. And I still do. People praise us for a developer experience. And every time I see a developer that had even one minor edge case, I go and sweat the details. Even today, someone sent me a DM saying, hey, I added this collaborator to this project. He deployed and in this particular PR because of this edge case, the check didn't trigger. And I was like, this is the end of the world. You know, for a lot of other companies, they don't have that pain empathy. They're like, well, just turn your computer off and on again. Yeah. Yeah.

And so I create a set of values internally at Versel to create almost like an immune system against that status quo or that giving up attitude that I think predates a lot of systems.

But there's also this I think higher level concept beyond exposure hours, and I think it's the authenticity of the mission. It's about founder mission fit. I'm not saying that you know every problem in the world that people are going to go out and solve has a deep story back to when they were 10 years old. But I am very grateful that for me it is the case, because when I was 10, had I had a Versel, I would have gotten to where I wanted to go faster. I always tell people a hyperlink will travel the world. Your brightest ideas one hyperlink away from impressing a prospect, getting you connected to your next business associate, whatever. The web sets your ideas free. I would encourage entrepreneurs to try to find that authentic thing about their journey that cannot be easily replicated, especially in the age of AI, right? There's no substitute for that deeply ingrained desire that comes from your personal experience.

As a consequence, people then sort of learn by osmosis. It's like okay, he's always going to focus on this kind of visual detail. I need to write a skill file to catch that next time we actually deploy a change of that nature.

Yes. Yeah. Which is that, you know, actually this is a good example of the overlap between design and engineering. Okay. So layout shift is this concept of when you're loading an application interface, a website, things should have a predictable paint path. They have a predictable layout. Imagine the classic example I give business people is I'm gonna go purchase your product and I'm about to press buy now, and some engineer made a mistake, the page shifts down, instead of buy now I click on an ad or I go out of the website or I go back, and so you lost my sale. And so this is bad because now when you start really paying attention, you realize that a product that janks and jitters around when you load it just doesn't feel good or doesn't look good.

It also has the business element of like, we know from the data that if you are not doing your layout work well, your conversions will decrease or whatever. And also has the engineering side of it because you're making the machine do so many recalculations. The poor web browser, which is a marvel of engineering, it's like, oh okay, I have to do all of this, I did all the math, I'm ready to go, I'm ready to paint, and it's like, no, no, sorry, so we have to do it all over again. I sometimes give people the metaphor of imagine that instead of loading an app once, you wrote code that made the app load five times because you're wasting all of this time and compute. You're wasting energy. I can go on and on to speak of the downsides. And obviously, there's times where you break the rules. It's not that I want people to also be free to make their own choices and not be guided by dogma, right? But like the layout shift, it erodes trust. It feels unreliable. It feels shifty, right? Like a shifty person is not a trustworthy person. So you want to make sure that every single web experience that you deliver is like a highly honed video game. They're like as sprites emerge as things kind of appear on the horizon, they're not sort of jumping around, right? You want to have a stable world.

If you knew this, there's an art in Japan where they paint a dragon in one stroke. Like they load up the brush. Yeah. And they've predicted how you can draw this beautiful dragon in one paintbrush in one stroke. And I've given people that metaphor of like a really awesome application or website will have that intentionality. It's not shifty, of course. Yeah.

I mean, overall, I'm extremely bullish, optimistic, and excited about AI because I've always believed that the best technologies are the ones that broaden access. From the pencil to the printing press to open source to JavaScript, Nex.js, all of these things are just enabling more people to join in on the fun. At its very basic, AI is fun. It's not just bring in a new class of workers in the form of agents. It's bring a new class of builders. People that couldn't design, build, create, ship before can now do it. And this is why Versel leaned in so hard, because I saw in the premise of AI for software engineering an acceleration of our mission. Everyone should be able to ship. Everyone should be able to cook. Now, it's I think crucial that we infuse this point of view of quality into everything we do with AI, because I love that we have now the term slop. I tell people, look, slop is awesome four-letter word that speaks to the negative things that AI can do. Just like spam was for the internet. You have your own email inbox. Well, it can get spam. Oh, you have AI, it can produce slop. And so I first introduced the pillar of AI focus for the company. I said everything we do is in the interest of quality and we won't do any random acts of AI. That's what I call it.

Right. So I wanted to basically create an immune system around it. And you know, we're just talking about how I guide the company, and sometimes it's through memes.

I've now formalized my thinking into the statement of that which I cannot create, I don't understand, which is a famous Feynman saying. It seems very essential to intelligence that you deeply understand how things are built. A good programmer is just an extremely competent computer user. One of the biggest surprises for me has been this idea that a coding agent is going to be the foundation of every agent. Of course, not only from the knowledge point of view, but because of its ability to fix, correct, hack, right? And what do we want out of knowledge work these days? What makes you a good accountant these days? Well, when I studied accounting in my school, in my high school, Argentina, it was about balancing sheets of paper. Now, of course, you would want Excel competence for an accountant that you hired today, or Python or R, etc. So it's very clear to me now that every agent that helps shape the future of a knowledge task will embed within it the capabilities of writing its own programs, of modifying them, of understanding what its own limitations are, and proposing changes to the underlying skill set instructions, prompts, etc. I also thought a narrative here in the value was that in order for an agent to be possible, it needs to be perfect at every step because it's going to be the combination of a set of probabilities and we can't have it mess up at any step. But turns out that's actually not how programmers deal with the world, let alone agentic programmers. We read feedback and we adapt. And in the feedback, whether it's a compiler error or some kind of exit code or whatever, we know how to repair and make progress. And so I think there was a perspective perhaps that agents had to be flawless, but it's the opposite. It's they will keep trying.

Landing means having an actual business outcome that you set out from the onset. And I love this because in my mind it's like if that's a lesson I can teach to every single designer on the planet, like the importance of landing. That's the lesson I would choose.

One of the consequences of AI and agents is that every person is becoming more and more full stack. I think it used to be that perhaps you would say like I need someone to help my team. They're going to be a CSS expert. They're going to be an accessibility. They're going to be a front-end expert. Nowadays I'm thinking of people as the renaissance people of the prophecy, right, like they know and they have every skill.

All-around athletes, because the age they can delegate work to agents. And I think this is going to emphasize and fuel this focus on landing, because you're going to be thinking backwards from the business outcomes, from the experience that you want to create, from the data that you want to produce, from the traction that you want to see in the world, and work backwards your design implementation, etc. We used to mention this other meme internally a lot. We still use it, called iteration velocity. So velocity is a distinct constant from speed. And I've seen in my career, I made the mistake myself of confusing speed for velocity. So speed is you move really, really fast. You type a lot. You spend a lot of tokens. You're token maxing. But for what outcome? Velocity is a speed with a direction, a vector. So for me it's about are we actually getting to the destination?

And this is ultimately why the same agent given to two different people will never produce the same results. I'm actually quite a big fan of this idea of Ralph Wigum.