Building an AI tool with Thomas Lopes === Thomas: [00:00:00] I feel like there's going to be continuous iteration of creating new tools and new ideas, I created code converter in a day, and a lot of other people are creating these tools in really small timeframes because it's pretty simple to use and so I feel like this will continue to happen and experiments will continue to show up and people are just going to experiment. More and more ambitious ideas Noel: hello and welcome to Pod Rocket, a web development podcast by Log Rocket. , log Rocket helps software teams improve user experience with session replay, error tracking and product analytics. You can , try it for free@logrocket.com. I'm Noel, and today I'm talking to Thomas G. Lopez. Thomas is a front end engineer at AppRight, , and confesses that he has way too many side projects. , recently, , Guillermo Rauch of Versace called one of those projects a glimpse of how AI will revolutionize code migration. So I'm excited, , to chat about that today as well. Welcome to the podcast, Thomas. Thomas: Thank you, Noel. I'm really glad to be here. Noel: , before we get [00:01:00] into any of these side projects, , can you tell us a little bit about yourself and how you got into web development, , and what you're working on? Thomas: So, , I'm a front end developer. I'm currently based in Portugal, but my roots are in Switzerland and Brazil. , I've always been , , interested in tech like since an early age, but I only started programming when I was 16 years old. Before that, I only had like, played with some double free schools examples and stuff like that. But when I was 16 years old, I figured I wanted to do something tech related for college and I started reading some Python books and started, , learning how to cope in. And I really liked it. That led me to doing some, , light freelance, , jobs, , and stuff like that until I eventually went to college to study computer science. In college when, , we started doing some group assignments, I noticed this, most of my colleagues and friends weren't too much on the front end side of things. And so our [00:02:00] assignments generally look pretty bad, especially , when we were doing like web apps or stuff like. So I thought, huh, I'm maybe, let me try, , try it out. I always thought I wasn't going to like front end, but I really got into it. , shortly after I started getting into front end, I also got into an, , interview process for an internship, , quickly learned, , a JS framework. It was view, I think at the time, did some, demo app for the info. I got a role. And since then . , I've been through , some jobs. , as a front end developer, I really, really got into it, , mostly with react, a little bit of view. And I'm currently working, , with, without both on, , work and on personal project, which is a dream come true. Noel: , yeah, so recently, , you got a lot of buzz around one of your tools called code converter. Because , code aver is kind of, you know, , it does what its namesake sounds like it does. But could you give us in your words, what motivated you to create it , and how it works? Thomas: . So as you said, yeah, code VER is a [00:03:00] tool for converting code. Uh, , between different tech stacks, languages, frameworks, whatever. , it actually mostly started out just because I was seeing, , a lot of people doing like AI side projects with open AI's api. And I wanted to see how it worked out, if it was really hard to do, if, , I just wanted to know how it works, how to create a web app with ai. And so I thought of, I was trying to think about interesting ideas and that's when I thought about code conversion. , at first I thought mostly between front end. That's mostly what, , I do. But, let me just do cone conversion in general. Just I wanted to see if I was able to build something with it, and really surprisingly, it was much easier than I thought it was. Like , this isn't meant as a flex, it's just working with, , open AI's API and building a web app with it was pretty much hassle free. Noel: Nice. . So I guess , if we can peel back \ , [00:04:00] the curtain a little bit. Is it, , primarily functioning by tweaking a prompt based on what the destination language is and saying, open ai, convert this code. Thomas: Yeah, that is mostly it. Like Code River has a set of predefined options of predefined languages, , but you can also input the custom language. So for custom languages it is basically just saying, Hey. Convert this and then adding some syntax highlighting on top and stuff like that. But the actual conversion is just convert this for me with an edit prompt saying, Hey, don't explain what this code does, just output the code itself because I just want to show the output code. But for the predefined ones, , , I do have some fine tuning cuz sometimes the result wasn't desirable. I was getting some weird outputs here and there, and so I had to give it a little extra nudge just to make sure everything works fine. I also recently added the option to add custom, , parameters, , arguments. For example, with spelt I say, Hey, , I want it to [00:05:00] be type script, or I do not want it to be type scripts, stuff like that. Noel: Nice. Is there any like post-processing you do to the code at all? Are you essentially just taking , , what the model gives you , and spitting that out? Thomas: , there's almost no post processing. The only one I do have is for some reason after some tweaks. , the model was returning it kind of like a markdown format, meaning it had some back before and after the code. So I do remove those. But barring that, the only thing I actually do is add some syntax highlighting, but the actual text is without filter. Noel: . Gotcha. You mentioned, , like code highlighting and stuff there, so , I'm sure that there are some interesting front end considerations here as well. Can you tell us what, the stack is , for the front end and what led you to that stack? Thomas: Yeah. Yeah. So the whole stack is pelt kit. , I think I used Tailwind for this project. Yeah, I did use Tailwind for this project. , that's mostly it in terms of, , front end stuff, nothing too complicated , I built out my own components. I didn't use a component [00:06:00] library for the syntax highlighter. I use something called Shiki. I think that's, Which is pretty fancy because it gets its lists of available languages from VS code and teams as well. So initially I did have the idea to kind of allow you to choose your own vs code team or something like that, but I just went up with one that I found was nice. And what this allowed me to do was, it was pretty easy to add syntax highlighting I just get the output, get the. And just pass that in parameters. But sometimes it does fail, especially because of custom inputs. What full language that I wrote , there's no support for it or, , when entering a custom language, , I'm not going to write like s spells and then dash ts or something like that. I'm just going to write anything there that may not get recognized by shaky. So syntax highlighting is not g. But if there's an arrow, just show the text without so highlighting. [00:07:00] Another consideration was format code formatting. I was worried that I would have to use prettier or something like that, but to my benefit check, , the Open AI API generally , , returns the outputted code in a pretty good format so I don't have to worry. Noel: Yeah, , I've kind of been doing , this process to just manually, like via prompts and via the API when I'm calling stuff. And I've found that as well. Like, , I've been using it, I've. I've got , old projects in JavaScript that I'm converting to Typescripts. I'm like, generate types for this, big JSON blob and it like works very well. And usually gives me pretty decent formatting out of the box or at least close enough where I can paste it into my editor and it like, , can be autocorrected into the formats that I'm using. , cool. How about , , like hosting and the auxiliary, things that , one has to consider. For side projects, do you have a typical, hosting stack that you end up reaching for, or does it depend on the project? Thomas: No, no, actually mostly I use Versace for my projects, so it's really exciting that uch, , talked about one of my project. But [00:08:00] yeah, I mostly do use Versace. I think it started on a previous job. I already used it at work. I think it works pretty great out of the box. , normally all my projects, , outside of work are small side projects and it has always worked pretty great. It's pretty easy to get going. It works great with, , full stack frameworks, which is what I'm using, which since we use spell kit, it just works out out the box. Mostly value. I've also used Hiroku in the past. , I've used a little bit of net. I do want to try out sst, but the one I always go back to is for sure. Noel: Yeah. , , I guess , for , the server side component of this, I assume that there is at least a layer where like, You're taking your private API key and using that to make the request , to the open AI APIs. , is that all pretty simple? Are you able to use like Versace tools off the shelf for that? Thomas: Exactly. So, , at first actually called converter. I was using my own key, and then instead of just sending the request directly to OpenAI, I did have a layer of extraction, [00:09:00] which is, , I have an API route, basically a server. , route on salt kit. And so the client would send a request to my server route, which would then, , , add some custom logic, put the API key in there, and then send it to open ai. That still happens. The only difference is I'm no longer using my key because of billing issues. A lot of people use this and , I have to change it. So now you have to input , your own key. Noel: Mm. I think that is, Probably for, for a lot of these projects, of this cloth, I feel like we're seeing a lot of these where it's like some prompt engineering on top of open and, and we're just like kind of converting a user's request into it. But I feel like this is the problem is no one's totally cracked the like, but like these requests aren't free and we've gotta figure out an elegant way to do billing. So it's like, eh, you either input your own API key or you have to monetize it in some way. I mean, they're pretty cheap, especially with some of the model updates that have been coming out. But you know, especially. If the project hits any level of success, it's still a lot more expensive than like a [00:10:00] typical web request would be. Right? Thomas: For sure, for sure. , one thing that I actually thought about \ , there's a Versace employee, I forgot his name, but they did room G P T, and they also ran into the same issue. Like it got a lot of traffic, much more than cold. And It wasn't feasible to just continue free usage. So at first they, I think created like you had to authenticate with like Google Off or something like that. And then it would limit to free usage , , a day, which would already help a lot. And now I think it's paid. , but I didn't want, , for my particular project to go through that household. It was never. , the idea to make it a commercial product, it was just meant as an experiments and so that's why I opted to just let the user set their own key. Noel: Hey, uh, interjecting quick here to remind you guys that Log Rocket offers session, replay, issue tracking, and product analytics to help you quickly surface and solve impactful issues affecting your user experience. With Log Rocket, you can find and solve issues faster, improve [00:11:00] conversion and adoption, and spend more time building a better product , , I think that's a reasonable decision, especially like, if your target market is like developers and tech savvy people that like are familiar with logging into a system and getting an API key to do things, , it's probably , a pretty easy choice. , I think , my next line of questions are, are slightly more abstract, but I'm curious, , , , given the traction that this project got, have you been thinking about , this kind of tool for maybe larger projects for like more than one file at a time? Conversions. What do you think would need to happen for us to get there? , and I guess, do you think that is thing that'll happen in the foreseeable future? Thomas: I do think that's something that would happen. It's kind of something that, , I really dream about. It would be amazing. , I think. We're, , at early stages of these tools, not of chat BT and stuff like that, but the actual tools that come out it. We see it a little bit with co-pilot, which already changed developers', workflows quite a lot, , in some ways more than others, but still, , having like [00:12:00] a lot of improvements, especially now that Kit help announced co-pilot. I feel like there's going to be continuous iteration of creating new tools and new ideas, like things like I created code converter in a day, and a lot of other people are creating these tools in really small timeframes because it's pretty simple to use when you have that API layer of abstraction. And so I feel like this will continue to happen and experiments will continue to show up and people are just going to experiment. More and more ambitious ideas such as project level conversions and helpers and stuff like that. Like I can envision not only code conversions, but stuff like I want to get functions and stuff from one file and make it a little bit more generic, separated into helper files and stuff like that. I feel like that would be invaluable. I feel there's probably a technical limit, , current. For example, if we're talking open in the eyes, since that's what I used, there's , the limit of [00:13:00] tokens and the context and stuff like that. So that's something we would have to overcome. Also, it's pretty expensive to run these models and stuff like that, but I feel like we're going to get there. These are problems that are going to continue to be solved. At least that's what I. Noel: Yeah, I guess , maybe one question. I think this will. , one more interesting question , is in your testing, , how, , frequent were, like code errors, like logical errors in the output, , of conversion , via the tool? Thomas: I mean, it was frequent, but it depends on what, one thing that particularly happened was called migration. Sometimes between libraries, not languages. So like converting between Python to JavaScript. It's pretty simple. It's mostly syntax, but it's spell to react and stuff like that. It can be more complicated. Sometimes we would just try and use React hooks inside. Which obviously doesn't work. Or let's say you're using a Python library such as Bandas, and then you want to convert that to [00:14:00] TypeScript. How would you do that? Like the tool , would, uh,, first try and find Bandas on, , on TypeScript, which I think doesn't exist. And if it doesn't, it will need to know about. So there weren't so many syntax hours. There was one \ , or another one, but it was pretty easily solved. But there were, , more hours about, Hmm, , this just doesn't fit here. Like this function can be called here. , this is not a function that can be imported here. This library doesn't exist here. Stuff like that, that is more common. Noel: Yeah. Like those kind of larger like contextual problems, like understanding , what's in the libraries that are available and yeah, like how things can be imported and study. I, I could see that being challenging. So , the question that I was teeing up for there was that and maybe this isn't feasible, but if we ever , get to a point where like we can do this kind of conversion pretty consistently, bug free, especially on large projects, do you think that also drastically changes? Just like what languages [00:15:00] developers are using data to data, right. Code. Because it feels like we've kind of shifted towards these like very developer friendly higher level languages because they let us. , \ write more high level abstract code though. Let's just do more powerful things more quickly cuz we're not messing with the fiddly bits. , do you think that AI kind of, of this form will continue that pattern to a point where we're not really writing as much code day to day and instead we're like, , writing. Something, maybe it's prompts, maybe it's, it is still some kind of code like syntax that then, we can use an AI to come up with the actual constructions to send to the machine. Or do you think that that is pretty, , I don't know. Would, would be too error prone. Thomas: That's a good question. To be honest, I haven't thought of like a high level like that. , but it's interesting. I first thought of like something a little bit more like. At first, what I think will happen is maybe with code conversions being a little bit simpler, we will be less fearful of adopting like a new technology or something like that. Cuz worst case scenario, you can just convert it [00:16:00] more or less, you know? So this can help adoption for like smaller frameworks or less known once, but actually, , using like more prompts than code maybe. I, I feel like we first need to see how a project level. AI tool would work like, hey, create this product, add this library, , do a set of files that do X and y. , we first need to see how that would work and how that would integrate and later on see that. I think it's could work for maybe smaller projects or sometimes, I mean, we already see like no code tubes do some stuff pretty well, but when you need a little bit more customization, you end up, you normally. To just go over the code again, so I don't feel like it's going to be super abstract. I feel like there are going to be tools that help you get started more easily. Maybe you have less barer plates to get started. I feel like that's what's going to happen, at least at first. Noel: Yeah, I think it's hard for me to grasp , , too [00:17:00] much increased abstraction. And I just feel like , there's so much context , baked into like, okay, I want to import this library to do, , syntax highlighting, like, to use an example , you just used for your, for the project itself. Some of those things seem hard to. Articulate to a model for it to figure out , how you actually wanna do it. But again, maybe I'm being overly shortsighted here. Thomas: Yeah. But there's also another question too is like, programming languages or a way for us to communicate with computers. At what point is natural language easier to describe stuff like at a higher level? Yes, sure. , if I say create a webpage that has a counter and it outputs for me, that's great. But when I get into the finer details, there comes a point where, ambiguity of natural language and stuff like that, , that natural language has in programming language does not, , starts to get messy, right? Just writing stuff in code is going to be more precise, and I feel like you're going to start actually losing time if you're just using natural language to describe. Noel: [00:18:00] Yeah, , I think particularly like in the design space, right? Like it's hard for me to imagine really tweaking and customizing like front end without , some kind of declarative language of some kind that's like, , CSS or H T M L, , , so yeah, I think I'm with you there. With that in mind, , , , do you view code converter, this project as kind of like a stepping stone and it's like, okay, well that, that's probably done. It'll always be focused on one file conversion or is it something that you've been playing with more and seeing what you could kind of add to it feature-wise to make it, more robust. Thomas: , at first I didn't even imagine that colder look at the trashing that it got, it was just experiment. Since it did get some attraction and I did like working with it, I added some features to make it more usable. Like at first they didn't have syntax highlighting, they didn't have custom languages, they didn't have custom options, stuff like that. But now that that's mostly done, like most of the features to make it actually, I'd say usable, , are done. At this moment, I'm not like wanting to make it into this big product. I feel like that will take a lot of time. It's [00:19:00] pretty big endeavor. It's not something that, , I particularly want to solve at this moment. , it's, Just as I said, it started in the, as an experiment, I'm really happy with it, but I want to keep it as an experiment. But at the same time, I'm really interested in seeing what other companies , are doing, what other , products are going to solve. I'm really excited to see what's in star, , for us and I will still keep playing around with it, but it's not something that I'm going to invest my time a hundred. Especially since I feel like maybe it could be a wasted time on my part, not because it's not going to be useful, but I feel like, huh, GitHub is just going to come over and do something that's 10 times more, , not polished, but has a lot of features that I alone just couldn't feasibly do or stuff like that. Noel: Yeah. Yeah, we had a couple, a couple of questions come up as well, like from people we just scoured Twitter and look for some stuff. , I think some of the interesting ones were about performance and even just like kind of code review more abstractly. And I've seen other projects [00:20:00] crop up on Hacker News and stuff that are kinda like automating that first step of code review. Did you consider. \ adding any of that here? Or , do you feel that the output is already gonna be pretty, , efficient, effective, healthy, clean code? Thomas: I mean, I, , I confessed that. I didn't think about that. That could be like, , a good process, but at the same time, you can see design-wise it was meant to be like pretty simple, just conversion two, , it's not supposed to have like a chat PT, like dialogue with back and forth and stuff like that. Especially cuz I feel like that would be a bit like, huh, why don't I just choose chat PT without any ability mutation that, , or constraints I built around culture. So I didn't think about that, but what I do feel like, As projects go on and on that, yeah, sure. There's going to be a po moment where they review pool requests. , I actually already saw it to about review pool requests, but let's say , , a code converter like to opens up a pool request for code migration, and then, , another two reviews their code, [00:21:00] stuff like that. I feel like these codes, , these tools will all work together. inTANDEM in that. Noel: Yeah, I think so too. I think , we'll see a lot of people leveraging multiple projects that are in this space to optimize , their workflows. , Another question, which I thought was interesting was somebody was asking about like older languages. , , they mentioned cobalt, but I'm curious, did you mess with like cobalt or Fortran or , even like assembly, anything like that? Like can you make this higher level? Thomas: I did not, but I do think it would be super interesting. , I need to try it out , after this. But at Isker, I mean like some older languages have some really different syntax, like instead of far loops we have jumps and stuff like that would be interesting to see how they interact. But one thing that probably would be simpler, I guess the older languages don't have as many libraries and overload of things that we do nowadays. So while we were talking before that on converting libraries and stuff like that is kind of hard. If you're just converting the language, maybe that's simpler. It's also \ not constantly [00:22:00] updated, so there's no like new syntax to review. It's not like an out of date training model. That stuff already exists. There's a lot of samples regarding it. Maybe it actually works, I would guess It works pretty well, I would say. Noel: Yeah, I wouldn't know why it wouldn't like assuming a sufficient amount of that data was pulled into the model. I would think it would, , perform just as one, like you said, if not a better, because there are fewer externalities probably in a lot of that code. But who's to say that there's like also nuance and. It's weird abstractions. I guess the reason that those languages are hard to write in, I think sometimes is they're like, I don't wanna say like archaic because , it feels overly negative, but we have to think more about what the, , machine is actually doing versus what the . Nice abstract coat is declaring. , but it'd be fun to play with for sure. I agree. Well, , , is there anything else that's been. On your radar anything , you're working on or excited about, , kinda coming up or in the near future that you wanted to mention? Thomas: Yeah, sure. , besides like ai, one thing that I really liked about this [00:23:00] is just actually communicating with other developers. Like actually, , just. I'm getting to talk with other developers and actually today , I'm going to start work on a project that's basically parting over and pretty well known open source library from Reacts Felt. And I've got some other developers , and people that, , all got really excited and I also want to help out. And I feel like before this project and the reach it got, I wouldn't feel as comfortable like just reaching out to. To help out or stuff like that. So that's something that's pretty exciting. , there's also another project that, uh, , before I did COPE weather, which I also made public, which is felt radio menu, which is a little component, a radio menu component based on Rhino Freiberg's work. I hope I pronounce \ , , his name correctly. And I want to create an NPM package out of that too. Besides that. On the ai, uh, , side of things, , I've just been seeing more and more products pop, , up. [00:24:00] I'm now currently working out, , stuff with blank chain, , and docs, meaning basically, let's say you want to integrate, , custom chat, but tailored to your own documentation. Noel: Hmm. Thomas: Sometimes it's a less known, a lesser known project or just like new documentation. I think chat p t's training data only goes to like 2021. So if you want to add new stuff, you need to give that information. So I'm playing around with that a little bit. I was even thinking maybe doing like a two for spout hackathon, which basically grabbed your SP kit project or something like that. And. Add docs to it? No, not added docs, but added like a search to it. It's like docs. that would be pretty cool. I didn't even start doing that, but , it was an idea that was on my mind. I feel like something like that would be pretty interesting. Maybe not even tailored to a specific framework. Likewell just, Hey, you have a website. You just input a website in it automatically. It gives [00:25:00] you chat PT docs. Noel: Yeah. Nice. Nice. If you wanna get in touch, , is, , Twitter, what you monitor the most closely? GitHub, what do you prefer? Thomas: Yeah. Yeah. , mostly I've been, , using a lot of Twitter recently. , but GitHub is also somewhere I'm pretty active, always pushing, , site projects, , there. Noel: Cool. Wait, we'll get links to those in the show notes. , well thank you so much for coming on , and chatting with me, Thomas, it's been a pleasure. Thomas: Thanks so much. No, explain a blast.