Featured image of post Building a Startup with AI with Jowanza Joseph

Building a Startup with AI with Jowanza Joseph

Jowanza Joseph shares how his startup leverages AI tools like Cursor to accelerate software development and compete with established players.

Listen

Subscribe

Transcript

[00:11] Tim: Welcome to episode 10 of the Into the Hopper podcast. I’m Tim Hopper, and on this podcast, I occasionally interview my friends about their life and work. Today, I have my friend Jowanza Joseph back on the podcast. He was last on in February of 2022, when we talked about his book, Mastering Apache Pulsar, which you can find at podcast.tdhopper.com. When we last talked, Jowanza was a vice president of software engineering at Finicity, a Mastercard company. Since then, he has started his own company called Parakeet, which is a compliance automation and risk management platform built specifically for industrial sector businesses, which maybe he can tell us what that means if it’s relevant to our conversation. But Jowanza’s startup has been built in this new era of LLM-assisted programming, and Jowanza and his team have leveraged these AI tools to move fast and serve their customers more effectively. I asked Jowanza to come on and talk with me about what this looks like. Welcome, Jowanza.

[01:06] Jowanza: Hey, thanks for having me on, Tim. Good to be here. And yeah, happy to talk about what we’ve been up to at Parakeet. I guess, to your question about the industrial sector, I’ve been playing with this concept because our target market is large companies—enterprises—that produce things: consumer products, chemicals, wood, oil, energy. Apparently the Bureau of Labor Statistics has a word for this: the goods-producing sector. So I’ve started using that. It’s a mouthful and has a hyphen in it. I don’t really like it, but I guess that’s technically the industry we’re in. “Industrial” would include things we don’t necessarily serve, like logistics or companies that maybe don’t produce things. We focus on companies that produce things, starting with manufacturing, and we’ve recently gotten a couple customers in oil and gas and energy that are in the last stages of their contracts. So we’re trying to expand pretty quickly.

[02:16] Tim: So this isn’t really the focus of our talk, but so customers are buying your product. Are they moving from an SAP solution or like, what are they using?

[02:24] Jowanza: Yeah, that’s my favorite topic. It’s a pretty vast landscape. There is software called GRC—governance, risk, and compliance software. These are information systems that help you collect information about your regulators and about how you comply with those regulations or standards. Something like Salesforce is an information system for sales; GRC is an information system for risk and compliance. So we compete against those. There are some in the market that aren’t necessarily targeted toward our audience, but we do have to rip and replace those when it makes sense. We also do see what you said: SAP.

People will use their ERPs as a governance, risk, and compliance platform. You can get a customized build of whatever you want on some of these ERPs, and some customers have done that. It doesn’t fully suit their needs, so they’re looking for solutions that are more tailored to the specific problems in compliance and risk management. That’s common. Our current customers aren’t in that bucket. They have paper systems or a glued-together hodgepodge of Google Sheets and Trello, and they want something more streamlined that will help reduce the overall cost of compliance, because that’s really what we’re tackling: the fact that it’s expensive.

[04:04] Tim: Yeah, sounds like you have the sales advantage of selling to people using something they otherwise hate.

[04:09] Jowanza: That doesn’t make it any easier. You know, the status quo bias is pretty strong. Like, there are probably many things in your life that are annoying, but you just deal with it because the idea of you’re replacing your grill with a new grill that doesn’t, you know, creak every time you close it, or you’re replacing your front door that doesn’t— you have to really push it hard to get it closed.

[04:30] Tim: Yeah.

[04:30] Jowanza: It’s just too expensive or too much inertia required to do it. So that’s what we’re fighting against most of the time. You know, we have demos, they really wow people, but then organizationally, they have to get behind the idea of a new login, a new thing to support, you know, a new way of doing things. And it’s hard, and it’s my job to, make that easier.

[04:50] Tim: Yeah, that makes sense. I don’t know how much of your career history we need to jump into. I guess we probably talked about that a little bit on the last podcast, but I don’t know. Do you want to give the 20-second overview of your career and maybe how it led to where you are?

[05:05] Jowanza: Yeah, certainly. So I graduated from BYU in 2012, and my plan at that point was to get a PhD in economics, but I didn’t get into the schools I wanted to. So I decided to take a year to retake the GRE and kind of work on some research and get myself in a better position to get into the top 10 school. But in the meantime, I got a job at an analytics consultancy. So I did a bunch of like JavaScript tagging and learning kind of JavaScript there. So I went from that, worked at Adobe as a data scientist, and then like switched from data science to software engineering, worked at Pluralsight, and then at Finicity, which was acquired by Mastercard. And then right before starting Parakeet, I was a founding member of another startup. And then that kind of got me excited about, you know, trying to do my own company. And I did that last year. So it’s been a year since founding Parakeet. So it was last November. And it’s been a great year. It’s been a real whirlwind of, you know, customer traction, raising money, building a team, and now, you know, going into a year where we’re really trying to push the gas next year.

[06:16] Tim: Cool. And I think as well as you talking about, you know, you trying to make a product that is able to do something much more inexpensive than what some of your competitors might offer are related to the involvement your startups had or the involvement AI’s had, I guess, in your startup. I did an episode about a month ago or so with our friend Ravi Mody about his use of AI for programming. And I was excited to talk about you as well. Because I think both of you are using tools, but, you know, Ravi is like literally copying and pasting code snippets into a chat, you know, ChatGPT or Claude or something.

[06:56] Jowanza: That’s crazy.

[06:57] Tim: Yeah. Which I think has been very different from what it’s looked like for you. And yet both of you seeing a lot of benefits, but I know from talking to you that these tools have really enabled you to do more and to do more with a smaller team. And what I was hoping to talk about today is just what has that looked like and how has that impacted your, you know, your own personal software development practice? And then, you know, even if there are other things beyond that, because I know you wear a lot of hats at the moment. And then, you know, what has AI and LLMs meant for trying to start a startup in 2024?

[07:33] Jowanza: So let’s start on the development side. A big, big user of Cursor. So that, that’s kind of, I think, encompasses most of my LLM to software development as far as actually writing code goes side. So what it looks like for me, and I’ll be very transparent about this, is Cursor writes the majority of the code that I, I write. So I think as far as like me typing anything into the keyboard, it’s really correcting mistakes that Cursor makes or maybe giving Cursor a pattern to follow, because some of my feedback to Cursor and, and LLMs in general, they have a lot of really bad habits and, and also a lot of, I would say, like path of least resistance, you know, kind of, kind of behavior. And there’s also a disconnect, right, from the context of your, your code and like how it runs, and then the small change you want to make.

And if that change would necessarily break the whole codebase. So, a lot of what we’re doing is API endpoints, and there’s patterns, right? We use frameworks, and, you know, both in TypeScript and then also Python. And it’s not uncommon, right, for Cursor to do things right 10 out of 10 times, and then on the 11th time, do something very bizarre. And so it’s not quite to the level where it can, like, completely, you know, go on its own. But what programming looks like for me now is, okay, say I want to add a new API endpoint that connects to a news API and then feeds that into, like, Parakeet’s app so we can share news with our customers. So I would take the API spec from the website. and download that as Markdown and say, hey, Cursor, here’s this API. I want to make a new endpoint that’s called this, and I want it to do this.

I want it to go get— take parameters from the GET request and go out and then call this API. Here’s the key. Here’s the headers. Write this for me. It will do it pretty okay the first time, right? There’s gonna be probably some missing things, and then I’ll read it through. So I kind of become more of like a reviewer, and then I’ll say, okay, here are all the spots where it’s wrong. Can you, can you correct it? And so it’s, it’s much more of a kind of a conversation feedback loop than it is like me, me typing code. And then I will typically get to a point where I can run that code, either run a test or just run like an offline you know, local mode kind of integration test. But if I can’t, then I’ll switch to writing the code, right?

Sometimes it’s just incapable of doing what I’m asking, either I’m not asking it well or it’s that bridge too far, too new of a pattern, it can’t copy what it’s already been trained on. And then I’ll just hop in and I’ll write it. And so even then, sometimes, you know, I’ve gotten to the point now where I could be so lazy to say, write a for loop for me. Like, I simply want to write like, you know, for you know, open parentheses, like, I just don’t want to do it. So it— I definitely burn through all my, you know, tokens every day that I, that I’ve got from my account. So, so from there, writing tests, I think, is another big thing that I, I do. So I always hated writing them.

I always liked thinking about them, like what the, the test should be and like all the different permutations of them, but I never liked sitting there and writing all the expectations and you know, really grinding through it, because it is, it is a grind. And I’m sure you’ve had this experience too, where you go to stand up and someone says, oh, I finished the code, but I’m writing the test, right? It’s like, okay, yeah, sometimes it takes longer to write the test than it does to write the implementation. So, Cursor do that. It’s pretty bad at, on its own, thinking through all the permutations of what should be tested. But if you tell it, then it will write the test for you. So, you still have to, give some thought to it. But that, that, that’s really my flow. And that’s for frontend and backend.

That’s also for— let me, let me, one thing I will caveat. So we’re using a few like AI frameworks for like agents. So Crew, and then we also use Vercel. And for, for whatever reason, like the training and like inference for that isn’t that great. So anytime it comes to, to that code base, I have to kind of write it myself because It doesn’t understand like the SDK that well, even though I’ve given it the docs, it’s still kind of choppy. So there are places where it’s not perfect, but what this has enabled is that the speed of development is really astronomically fast. So we were able to— we’re at feature parity with any of our competitors within a couple months. So we got from, you know, zero, nothing, to something that was comparable to, you know, some of our competitors that are, you know, $200 million in ARR in a few months, right?

And that’s not just AI, that’s also us working a lot, but it should be impossible to do that. But when you don’t have to sit there and tinker on a keyboard and an AI can actually, you know, produce the text output a lot faster than you can type, then it just compounds. And I will also kind of— last thing I’ll say about this is just on the quality side, it’s not better quality than like a good developer. So, excuse me. So if I were to compare like my codebase probably to code that you’ve written by hand, you’ve got some pretty fun repositories out there. It’s way worse, but it’s understood, like it’s well tested and the limitations of it are understood. But as far as like the readability, the ability to give it to another human and say, hey, here’s great code, not all of it is, right?

Some of it is, we refactored some of it, but anything that’s kind of built in a rush, I’d say it’s pretty low quality compared to a good human, but like maybe good compared to like a median or, you know, 75th percentile programmer.

[13:51] Tim: That leaves me with a lot of follow-up questions, but To that latter point, do you also, are you at a point where you’re also then using the LLM to maybe explain some code maybe someone on your team has written or code that you wrote 9 months ago and you, you know, you wrote with Claude 9 months ago and you’re saying it’s not great code. Are you using, you know, in Copilot, I know you can do like /explain. I’m sure there’s something comparable in Claude. In Cursor?

[14:20] Jowanza: Yeah, actually I do that more commonly with SDKs. So if I pull in a new library and I want to understand what a function does, instead of reading the documentation, which sounds so lazy, I would rather just ask it, like, hey, what does this do? And it does a good job of explaining it. Also writing notes or like writing, I guess, like not quite notes. I don’t like that word, but, you know, just explaining what a function does or maybe changing the names of the parameters on a function so it’s a lot clearer for someone to understand. I’ll have it do that. But what I find is like the creativity and the thoughtfulness of the LLMs isn’t there, right? So if you ask it to explain something better or any kind of descriptive marker, like it’s going to kind of just explain it differently, not necessarily better.

Like it doesn’t really understand what you mean. So you have to really get good at prompting and saying, explain it this way, right? Like, I want you to name the parameters on the function like this, and then it will do a good job. So it can feel a little bit frustrating because I think a lot of the experience of programming is just, you know, you taking what you know and like your best practices and kind of just going at a problem and It feels a lot of times with these LLMs like you’re starting from scratch, like they’re not really saving or like recognizing anything you’re telling it. So every time you’re prompting, it’s just lots and lots of text. And so it’s still faster than you writing the code, but, you know, me explaining in a bulleted list how I want you to change the naming, naming of my function, it’s frustrating.

And then even sometimes little things like You know, I will go back and forth from like a JavaScript codebase to Python. And, you know, you got the camelCase versus the snakeCase, like forgets, right? It’s like, okay, all of a sudden it’s like writing a bunch of camelCase in Python. It’s like, okay, let’s back up and stop, right? Like, let’s go back to how it’s supposed to be. So, stuff like that can be quite irritating, I would say. And I know a lot of people who, not us, but, you know, a lot of people I’ve talked to find it just irritating enough that it’s not quite good enough for them. But for me, speed is really the paramount thing that we have to do, especially getting to market and differentiating ourselves.

And so we have to kind of take the hit on the code reliability, you know, all the things that I really do value as someone who’s worked in software for so long. But, you know, at this early stage, it’s just kind of a race. And, you know, we have to get out there and make that happen. But at a certain point, right, we’ll have enough customers, enough employees where, these decisions will have an impact on our ability to continue to move faster, and we’ll have to kind of reevaluate it at that point. Like, how do we have a coding standard maybe that our LLM coding assistants follow? Or how do we have a process that prevents some of the kind of edge cases and bugs that we see from happening? And we haven’t had to answer those questions quite yet. We’re still pretty early, but I feel them coming for sure.

[17:33] Tim: Yeah, those are challenges of using AI. But at the same time, what if you were doing this 10 years ago? You’d be trying to scale up a team, right? You’re hiring more people. You’re still needing to ship fast, right? You’re still having to prioritize features over, you know, having a beautiful code base, right? Uh, it’s— I don’t know if it’s necessarily categorically different.

[17:59] Jowanza: Um, yeah, I think, I think you have a good point. It’s really not. As soon as you started pointing out, I’m like, ah, you know, it’s not really that different because, yeah, I remember I’ve worked at many Early stage startups, and yeah, you made the same choice. You made the choice that getting a customer today was worth the outage you would have tomorrow, and you know that just a choice that you’d make every time. And I think even you know for someone like like yourself, you know who’s working at a much bigger company, probably still would make that choice, right?

Like not not necessarily outage, but I think you take into effect like your impact on on the future, and you’d say well it’s you know it’s going to impact the future, but right now. the difference between having this and not having it, it’s worth whatever the future tax will be and we’ll just pay it. And we’re definitely in a mode of doing that. I think we also are cognizant of it. And when there are bugs or when there are support tickets, the area that, that kind of quality degradation or like, or a hit that we took on the quality before comes up, comes to show. It’s like, okay, we didn’t really, test this that well. So now when, when someone, you know, does a dropdown and, you know, picks a choice that wasn’t inside of our enum, oh, it was— it’s like we’re the only ones to blame for that, right?

We’ve got it out quickly, but yeah, we introduced something that, that broke, you know, the experience for the user, which happened the other day, right? It’s like there was— Here’s a situation where there’s a field that’s like a multi-select, but it’s all enums. And somehow like one of the enums on the website got hardcoded that wasn’t supported on the backend. Right. So then it just turned into this cascading failure when they tried to submit it. And it’s, yeah, it’s our own fault. Right. It’s like LLM-written code. And, you know, somehow that translation didn’t happen clearly. And then the test didn’t catch that. And, but, but to your point, I’ve had that same problem happen when humans were doing it. So it’s like, it’s just the tax of fast writing.

[20:03] Tim: And for the RDR. people studying this, but it’s going to be interesting to see what, what, what are the impacts of auto-generated testing? Are, you know, if we can come up with test cases or even into your point or your example, having the developer be able to think through possible cases, but just having the test itself, you know, be as, as auto-generated as possible.

[20:32] Jowanza: Yeah.

[20:33] Tim: Are, are people going to write more tests? Are there going to be— what, like, what are the long-term ramifications of that going to be? Because I mean, you know, I think that’s another easy thing, especially in a startup, to think, oh, we’re not going to spend time on testing right now. Whereas y’all might say, you know, we can, we can add tests very quickly. And even if your code quality is worse, Does more test coverage, is that gonna have, you know, positive payoff in the long run? Uh, it’s an interesting question.

[21:06] Jowanza: Actually, I would like to know your opinion on this too. So with quality, this word always kind of eluded me, right? Because when we say quality, do we mean understandability, right? Do we mean that we know if that this will behave these particular ways, like deterministically? Like if you give it this input, this output will happen at this speed. Or, you know, if you scale it up to this many requests, this predictable behavior will happen on the other end. Like, is that quality? Or are we talking about something more like less quantitative and more just about aesthetics, right? This looks, looks good, looks well documented, you know, has— follows a convention. It always kind of— it always struck me as a word that could mean both. And I don’t know that that’s necessarily what’s the most valued.

I think inside of a company, probably the first way, everyone probably cares a lot about that more as far as the business goes. As far as the developers go, it’s probably split 50/50. I think most people want to have, you know, what they would consider elegant-looking code. But if you had the trade-off between elegant-looking code and code that just worked predictably, you’d probably just choose the one that worked predictably. And I think explaining it or getting you to understand it would be, you know, it’s not impossible, but, you know, having code that’s really well-written, but that doesn’t perform well, it doesn’t perform predictably, would be very frustrating, I think, to experience.

[22:38] Tim: Yeah. I don’t have really any familiarity with kind of the theoretical side of this. I mean, I know this is an area of academic study, which is—

[22:47] Jowanza: Yeah, for sure.

[22:48] Tim: You know, who knows how valuable that is? Yeah. I mean, I think that’s an interesting distinction. And I think about quality often as maintainability.

[22:58] Jowanza: Maintainability.

[22:59] Tim: Which maybe has some aspect of both of those things, but you know, Fred Brooks talked about in No Silver Bullet, which was 30 years ago, maybe more now, probably almost 40 years ago. He talks about how all code is just developing over time, right? Like, as soon as we have code, And it has uses, people start to find new uses. And so then like the code needs to develop. And so, you know, we have very few things that are just really frozen in time. The exception probably being like some kind of, you know, mathematical routines and things where like, you know, this, you implement a fast Fourier transform in Fortran and then people build libraries on it for the next 40 years.

[23:41] Jowanza: Right.

[23:42] Tim: But even something like Vim, right? Like Vim is still being released and, and people are building NeoVim. And so can we actually make the changes that we need to do and do that with confidence and efficiently? You know, I think in poor quality code, you, you have to make changes with a lot of fear like that you’re going to break something, which is an area which I think testing, when testing is done well, you can remove that. Fear of breaking something. But at the same time, it’s not just that you can test it. You also, it also has to like some level of understandability because you need to be able to go in and find where you make a change. So yeah, I know that’s, that’s kind of the, uh, what I think is just a very pragmatic perspective on quality.

From what you’re describing, it seems to me that the risks become You know, if you’re committing yourself to testing, it’s great, but the risks become, does your code just become unnecessarily complex or inconsistent in such a way that it’s like, you can’t even identify, you know, you need to go make a change. You need to go fix this dropdown. Can you actually quickly identify where that’s happening and then go make that change? And that can be hard in any codebase, but I guess if you’re doing, I don’t know, I’m thinking on my feet here, but that would be my fear of kind of somewhat losing control by handing more over to the LLMs. But at the same time, like we said, if you hire 10 22-year-old junior engineers, is it going to be any better?

[25:24] Jowanza: Right. And yeah, I wonder, I wonder that all the time because Yeah, I get a lot of pressure, you know, from peers, you know, sometimes investors, you know, to increase the number of developers, right, that we have, because there’s just this idea that, you know, we would get just more, more velocity and, and also just not be as quite as hard, quite as overworked, which, which I think, I think we definitely are. But at the same time, it does introduce kind of another layer of someone, their prompting, you know, their ability to submit code. And, and we do have, you know, code reviews and things of that, that nature. But yeah, it’s, it’s, I think the, the tax is very accumulative, right? Like, you, you don’t, you accept, you know, maybe one recursive function that you don’t fully understand that Claude wrote for you.

And then, you know, it seems tested, the tests all pass, but You know, it’s the collective understanding of it maybe didn’t go under the rigor or the scrutiny that maybe it would at a bigger company that had, you know, more sophisticated process. And but yeah, if you think about the cost of it, it’s not zero for us. Our customers are big companies and they’re going to be upset if they encounter problems. But it’s not the same thing as if we had $100 million or $300 million users that relied on us for their music, right? Because then, you know, if something goes wrong and no one can, you know, play a song on their app, then it’s just a huge problem versus, you know, oh, I couldn’t, you know, get the latest news about regulatory compliance for today.

You know, it’s not great, but it’s something that we can probably fix quickly and everyone can go on their merry way. So we have to kind of do those trade-offs as well.

[27:15] Tim: Yeah, that makes sense. Are you Do these conversations come up with your customers at all? Is there awareness among your customer base of what this looks like, or is that a concern?

[27:28] Jowanza: So, not necessarily like how we’re writing code. I think that the security of our code, the security of our environments, that concerns them. Like, they want us to be as secure as possible. They have their own security posture and compliance requirements around information security. And so, we try to meet those. And, and yeah, we’re continuing to get certified, like, you know, SOC 2 Type 2, ISO. We’re going to do all of them because that’s what our customers are asking, and it’s a good, good thing overall. But inside the product, we do also have a lot of interactions with LLMs. We have an AI agent that’s called Rosella inside of our product. And, and so they, they have questions about that, like, you know, where’s the data going?

Like, is this being used to kind of continually improve the performance of, of Rosella, and, you know, they will try to add it in their contracts, right, that we can’t use it for training data or that their, you know, instance or interaction is kind of separate from everyone else’s because they understand that their competitors might be our customers in the future or maybe are now. So that’s something that they bring up quite often in the sales process. It’s just kind of a check your boxes and make sure you’re not leaking data that your competitors could use.

[28:45] Tim: Yeah, I’d imagine that’s you and everybody else trying to sell SaaS products right now since everybody’s doing the same thing.

[28:51] Jowanza: Certainly. And yeah, there’s not a lot of guarantees that actually come from the providers. And so yeah, we have to be, you know, as good as we can. But yeah, once you send data over to whomever, I won’t name anyone, but like, you know, it’s kind of goes into a domain that is uncertain. And so you have to decide that it’s worth, you know, the effort and the automation to allow that transaction? And I think overwhelmingly we’ve said yes, but, you know, there are some use cases where the answer is still no.

[29:25] Tim: And thinking about maybe the early days of your product or early days of new initiatives, are you using Claude— I’m sorry, Cursor or LLMs to help bootstrap new codebases in terms of just thinking through how you set up and structure and organize a codebase? Or is that something that was a more manual effort? And it sounds like there are more and more tools out there of folks trying to enable that bootstrapping. Has any of that been useful?

[30:00] Jowanza: Yeah, that’s a good question. So we just had this happen. So we released Android and iOS apps. We put those in a new repository and initially we tried to have them suggest like, hey, we’re going to have an Android app. We want to have a shared view with the iOS one. Like, can you, can you do, you know, a folder structure, code structure that works? And we just weren’t really satisfied with the kind of outcome. So we ended up doing it manually and hopefully that works out well. It’s so far so good. It’s pretty early. It’s been like a week since we’ve had these apps out in the, in the— in beta. So it’s in like TestFlight and then whatever the Android version is called. So we’ll see. But yeah, I haven’t had a lot of success like saying, okay, like here’s a new React project, structure it for me.

We’re still using like the React starter or, you know, the Node.js or Python starters because yeah, I feel like it’s not really an area that is the long tail or like the hardest part of the code. It’s really just getting bootstrapped could, could be interesting place to, to use it. But we, we find it’s more of like, okay, now I want to add a new view to my iOS app. And that’s where we find like Cursor would give a lot of value because it’ll take what we have already and then, you know, implement kind of what we, we want to going forward.

[31:21] Tim: Yeah, that’s helpful. It’s interesting to me, and this is my personal problems, but I have a couple side projects that I’d like to do. That a couple months ago, I was just trying to use Cursor to bootstrap and my knowledge of like the whole JavaScript frontend and even just things recommending using JavaScript backend tools. My knowledge is just very slim. And I, the bootstrapping stuff I made some headway with, but then I eventually just like hit walls that I was like, I don’t know if I’ve just set something up wrong. And at some point just getting into kind of these loops with the LLMs where they’re suggesting, you know, you’re like modifications that are just going back and forth to the same 2 or 3 solutions not working. But yeah, I would be interested to see as those— I know there’s the Vercel v0 site now for bootstrapping sites, which I haven’t tried yet, but it’s a pretty cool idea.

[32:16] Jowanza: Yeah. I use something called Magic Patterns. So I started out with v0 and then Magic— I switched to Magic Patterns to And that’s basically our designer. So, so what I do anytime we have a new feature is I describe it in natural language and, you know, I’ve got like a custom framework as far as design. So it knows my, my design system. And so I’ll tell it, hey, I’m making a new feature. It’s, let’s say something that’s new that we’re doing. So we’re working on like catalogs. So this is like, if you’re a business and you want to share your catalog with another business. then like what will enable you to do that, we’re connected to your ERP or your order management system and we can, we can create a digital catalog and then you can pass that along.

So for, so for this, I, I just describe like, hey, I want, you know, an experience of 3 steps and, you know, it uses our design system and, and then I can keep prompting it and it, it’ll get to a design and then actually we’ll hand that off to my engineering team and then they will implement it and it’ll be pretty much pixel perfect because it, it is, using our design system that we have. So it’s really awesome for that, and it’s saved me from having to get a designer because it functions like a designer would, except of making a new component. So that’s where we’ll have trouble, right? If we wanna make a table that looks different than the tables that we have now, or if we wanna make a new component that is just slightly different from what we have, then it takes kind of getting back into Figma and drawing it.

But Otherwise, like just taking our existing component library and then, you know, composing a new UI out of it, it’s great for that. And then even for the backend, I’ll use Claude to take a first crack at it. So I’ll say, hey, I’m building this feature, you know, I need— it needs to do this, this, and that and the other. Can you give me, you know, a Postgres, you know, SQL schema for this? And then it’ll give me one, I’ll read through it, you know, it may have some problems and I’ll just keep prompting my way to, to it being good. And then I’ll say, hey, put this in a table, you know, make it 4 columns, you know, make one column the name, make one column if it’s required or not, one column the type, and then one with notes. I make an enum, you know, for the ones that should be enums. It’s that one lazy thing that LLMs do.

They always try to turn enums into strings, so you have to tell ’em, don’t do that, right? It’s enum, like actually enumerate it, please. And then that will gimme a pretty nice, you know, draft. I’ll copy that into Linear. And then I’ll make some edits because usually there’s a couple things that are a little bit over-engineered, which I think is kind of good that Claude will over-engineer rather than under-engineer. But I’ll kind of reset it and like, hey, we don’t need to do this. Like, what it likes to do is make things extremely normalized. So, you know, a lot of times if you would just throw like your category, you know, for a, a schema, like inside that schema, it always wants to put it in a different table, right? And then each of the enums, they want that in a different table too.

So it’s ultimate flexibility, but it’s overkill for most use cases, right? You don’t need to do that unless you really envision, you know, 100 categories, then it’s just kind of too much. So I’ll have to kind of back it up. Yeah, so, so it— so we’re— I’m using it all over the place. I mean, I use it in my go-to-market as well, um, LLMs. I use them to do research on people. Which I guess that’s more like a combination of tool use and LLMs, but you know, that, that I use that writing, I find it pretty mediocre at. It’s just something that it’s, it’s a skill that still humans can just write much better, like a good human than, you know, LLM. But yeah, there’s a lot of great places that I use it.

[35:54] Tim: Do you have any thoughts on what all this is gonna mean for someone graduating college in 2024? 25.

[36:02] Jowanza: Yeah, I think that the— we talked about this earlier. I wonder if we both lived through this like booming, you know, tech economy where, you know, from like 2017 probably through 2022, you could always find another job, right? It’s like you could always work your way into at least a $10K, you know, kind of promotion. You could get a title that you didn’t didn’t really earn. It’s like you could, you could be a senior engineer after a year of experience because there’d be someplace that would hire you and give you that title. It— I have a limited sample size of this. It feels like that’s over. It doesn’t feel like we’re gonna go back to that time. It still feels like there’s plenty— like, plenty is a hard word to use, but it feels like there’s plenty of jobs.

But the skill set that’s required and the amount of people that companies need to do software development does feel like it’s less, right? It just doesn’t have the same requirement there. And so I think what that means is hopefully more companies are doing software development, right? So then it gives opportunities maybe that aren’t— maybe instead of going to work for Meta, you go work for a pharmacy or like a compounding pharmacy, right? Because they’re trying to do software stuff. But then also I think what it means for you and then what I’ve really valued is when a person, you have to have kind of more skills, right?

So if you want to really make a dent in and get into the industry, if you can design, if you can be full stack, or if you can make iOS apps, like if you could just as one person bring more value to the company, then I think that’s going to make it easier for you to hire. But as we both know though, being an expert in a whole bunch of things is impossible, right? But being good enough to be dangerous in a whole bunch of things is totally possible. So I think that a lot of software development will end up looking more like that. And I think for someone in college, it’s probably good to tinker, to say, okay, being amazing at Java alone, like maybe that’s required by your CS program, isn’t going to get it done, right?

Like maybe being amazing at Java and then taking that skill and turning your web app into an Android app, you’d stick out, right? Show you that you could, you can use, whether they’re using LLMs or not, you could kind of display this full stack of talent. And I think even from the hiring I see, and even the hiring I’m doing, that’s kind of what I’m expecting, right? So someone that come in, I can move them around the chessboard based on what I need. And then I think that’s what it looks like a lot more. I think the specialty of just, I’m a backend engineer, I’m a frontend engineer. It feels mostly gone. I think the places where I still see that specialty is like machine learning, AI, you know, infrastructure. That’s stuff that still requires a high degree of specialization.

But I think in our traditional, you know, web apps and mobile apps, it does feel like it’s just converging. And I think I would recommend that to anyone who’s studying this stuff, that that’s the expectation, that it kind of will all converge. And I think, I think I heard this from you the other day that like you, like getting to a new job and like not understanding the code base that well and not understanding the language that well, the expectation now is that LLMs would help you get there, right? That you could, you could use them to just say, okay, I don’t, I’ve never written Ruby, but like explain how this works. And that within a couple weeks of doing that, you should have some proficiency in, in how, how it works. And like even some of the, weird intricacies of the language, and that just wasn’t possible before.

Like, I remember being intimidated by, you know, taking jobs in languages that I didn’t know, but I don’t feel that way anymore. I feel pretty confident that I probably won’t even have to ever type out any Ruby or type out the weird pipes they use, right? Because Cursor will probably write most of it for me, and I’ll spend a lot more time thinking about what I wanna build.

[40:00] Tim: So, I joined Spotify a month ago, and what I— the conversation I had shared was with my colleague. We do data pipelines and Scala. And I said, like, how— I’ve very limited exposure to Scala. And I said, how deep of an understanding of Scala do I need to get? And he said, basically, because of LLMs, not nearly as much as you would have needed to a few years ago, which was not the answer I expected to hear. And it’s been— I mean, I’m so, you know, I’m currently trying to do my first project, which is in Scala. And It’s also, I’m learning IntelliJ, which I’ve never really used before, but using Copilot and IntelliJ. And so part of it’s just like learning the mechanics of a new tool, but then also trying to understand how both to use Copilot to help me generate code and then also use it to help me understand code, just because there’s, you know, I kind of understand the functional concepts conceptually, but just understanding the syntax and stuff, there’s a lot of nuances that are just not as familiar as someone who’s predominantly worked in Python for 10 years.

[41:05] Jowanza: Yeah.

[41:06] Tim: It’s been an interesting experience. It’s new territory for me coming in and learning something like this with an LLM, you know, options to help. And, you know, in the past, I would have spent a lot more time on Stack Overflow. The stats have been shared recently of How Stack Overflow traffic has decreased. And I’ve looked, I think, at 2 things on Stack Overflow, whereas 5 years ago I would have been at Stack Overflow 100 times this week for the stuff that I’m doing. Uh, it’s just interesting to see. I think it’s interesting hearing you talk about, you know, early career folks, the opportunities here, you know, you could— Well, in a lot of, a lot of ways, the conversations that people are having are not totally different from You and I started off more kind of in the data science space.

[41:58] Jowanza: Yep.

[41:59] Tim: And people were having these same conversations 10 years ago, like, oh, what do you recommend for an early career person getting into data science? Which has always been a very hard question. And it seemed to be a hard route to take, but I think there’s, in the same way there was then, these tools are giving opportunities for folks who want to get ahead to distinguish themselves.

And You know, it’s always been the case, just, you know, going and getting a computer science degree and doing decently at a computer science degree has really not been enough for a lot of tech jobs in that you— people are hiring and they want someone who is showing their curiosity and their ability to go learn things outside of the curriculum and be able to come into a job where your computer science degree only has so you know, depending on where it’s from, limited amount of relevance in that, you know, the technologies that we’re using are not things that people are learning in school, probably rightly so. But people have always been wanting to hire people who are kind of learning and doing things outside of just following a curriculum.

And I think of all the— if I could go back to being in college or even earlier, I, you know, I was a kid in West Virginia in the early 2000s and wanting to learn about computer programming and having zero opportunity to do that. You know, nobody around me knew anything about computer programming.

[43:29] Jowanza: Right.

[43:30] Tim: And, you know, I was just, you know, going to W3Schools and the limited web resources out at the time. You know, we didn’t have MOOC courses. You know, I bought a book on BASIC and a book on PHP at Barnes& Noble and was like trying to learn, teach myself programming. And just thinking if I could go back and have the power of something like Cursor, the fear that people have is, oh, then you’re just going to, you’re just going to do all these things and not have understanding. But the opportunity to be a student and move at the pace that you’re talking about, think just in the ideal world, thinking about how much more you could actually learn. by not just having to be there, you know, typing every key, but instead having this thing that’s going to help you accelerate. I think there’s a real opportunity there. And, you know, I don’t want to be naive about the challenges of people getting into the job market here.

[44:26] Jowanza: Yeah.

[44:27] Tim: But yeah, I don’t, I think if I was talking to someone, I would encourage them to jump on that and not to use an LLM to just like answer your homework questions as fast as possible. Right. And not gain any understanding, but instead to be doing things and like teaching yourself things and having it as like, you know, this little assistant sitting on your shoulder helping you. I don’t know. Is that, is that too starry-eyed?

[44:52] Jowanza: No, I think that’s the way I look at it too. Yeah. I had a similar, similar upbringing and, well, not similar at all. West Virginia versus Queens, but the computer thing. So I remember I was, yeah, 1999. I got a Compaq, convinced my mom, it was $1,000, right? And then it came with a free monitor, I remember, from that computer store, which we don’t have those anymore. And yeah, I mean, I was very curious about like, okay, how do I do something on this, right? Rather than just searching the internet. And it was just hard to even know how to search. Like, if you searched like computer programming, it ended up on some forum, right? Where people were just talking about BASIC or, you know, PHP or Perl.

[45:32] Tim: Same place.

[45:33] Jowanza: Yeah, I’m like, how do I even start with this? And yeah, having some way to say, even like what my daughter has access to now, where, you know, you can even have an environment that’s interactive, right? Like, that just runs code inside of it. And it’s just pretty incredible. But yeah, it’s hard though. I think it’s— there’s a lot of overselling and hype around, you know, AI is being kind of like completely autonomous and like going out and writing, you know, full, full company, company’s codes. But I think the reality is like it’s clearly valuable. It clearly can help be a real speed improver and really drive, you know, that kind of improvement. But I think it’s, it’s still one of these tools that’s best in the hands of an expert, right?

If you know what you’re doing, you know what you’re trying to write, then you can prompt in a way that will get the best outcomes. And if you don’t, then, you know, you’re going to get pretty mixed outcomes and frustration, or you’re not even knowing what you’re really looking for. So like being able to say, you know, make me an app that, you know, that, I don’t know, shows maps versus, hey, make me an app that integrates with Google Maps API. Here’s my API key, here’s the documentation, here’s what it should be like. You’re going to have an advantage in that second case, but For how long? I don’t know. Maybe these things will become sentient and they’ll just know what you’re thinking and build exactly what you want.

[46:58] Tim: Yeah. I don’t know. I did a math research program in college and my Polish advisor, when talking about the problem we were trying to solve that summer over 8 weeks or something, would always say, if we solve it faster than we think, we’ll just go sit in the hot tub for the rest of the summer. He used to go to the gym at the university and work out. He said he only worked out so he could sit in the hot tub afterwards. I don’t know. I guess I’m not much of an AI doomer, but it’d be great to have things that can do things for us even faster and faster. I’m skeptical that it’s really gonna give us all 2-hour working weeks and then we spend the rest of the time in the hot tub. But I think the opportunities that are gonna be opened are gonna be very neat.

[47:44] Jowanza: Do you make any forecasts or predictions as to what the next 5 years No, I just don’t think, like, I don’t think we’re capable of really understanding it. And then I think that there’s a lot of information asymmetry, right? So you see things that are like, you know, Sam Altman says that, you know, AGI will be ready in 2025. And then you see other things that are like, you know, we’ve reached kind of the peak of, you know, scaling of training and like we kind of run out of training examples and, you know, getting from here to something else is going to be harder. It’s going to take more, you know, computational and algorithmic, you know, changes than we thought. We were hoping to just train our way there.

And so I don’t know, like, and then, and then you do have experiences with LLMs today, and, and you constantly get this thing that’s like, oh, they’re amazing, but also like they’re dumb compared to what’s coming, right? And, and it’s like, but then, and that keeps being said even though they’re improving. And they still do dumb things. And, you know, it can be quite frustrating as someone that uses them all the time, right? Where they misquote things or like, you definitely can’t trust like the citations that come out of them.

[48:56] Tim: Yeah.

[48:57] Jowanza: It’s happened 100 times to me where I’ve been embarrassed myself, right? Sharing something that was just, you know, not— it’s just misinterpreted, right? It’s like, it’s not what that research says. And then you ask the LLM again and they’re like, oh yeah, it isn’t what it says. Like, how did we end up here, right? How did you end up where, you know, it’s not right. But then you— anyway, it’s all probabilities and, you know, inferencing. But, but yeah, I don’t know, like, it, it could be. I think the thing I would say I do know and I feel pretty confident about is I don’t know how— if this were possible, right, where you had artificial general intelligence and, and they could— you could use it to do work for you autonomously, and how that would turn into those gains coming back to you, right?

It seems like what would be more likely would be that those gains would just go to corporations, right? And that they would not pass those along to you. So it seems more likely that if you own the corporations that were using the AGIs to gain more efficiency, earn more market share, improve their margins, that would go to the investors and the owners of those corporations and not down to the people who work there. So it seems like there’s something that needs to be thought through here.

[50:20] Tim: Yeah.

[50:20] Jowanza: I don’t know if it were premature, but it strikes me as like, even what I was saying earlier, right? Where I’m taking AI to do design and I’m not passing that along to a designer, right? Keeping those, say, profits for myself. And I would imagine the same thing would be true, right? If you could find a way to automate accounting, then, you know, the statement is, oh, there’ll be a new job for you to do. But I think that the real endgame is that, you know, these intelligences are— they can do anything, right? So we’re not needed to do work, right? So then, you know, if all of our economic value is in the work we can do, then what, right? And I don’t think that those philosophical questions are being addressed or answered, but hopefully, it will be at some point if we’re really going to a world where we don’t need to work at all because our whole economic value is tied to the fact that we can produce things. And if we’re not asked to anymore, then I don’t know. What does that mean for me?

[51:24] Tim: It sounds like a good topic for your economics PhD when you get into MIT.

[51:29] Jowanza: When I go back. Yeah. Yeah.

[51:32] Tim: I think those are legitimate questions.

[51:34] Jowanza: Yeah. I don’t know. There’s no answers to it, man. No one’s really trying to address that.

[51:38] Tim: Yeah.

[51:39] Jowanza: Because I think it’s, we’re, we’re way, we’re bridges far from that, right? We’re, we’re, we’re, we’re at a point now where people are saying, you know, you know, AI is taking people’s jobs, but, but it’s not happening at, at a scale and at a consistent and like repeatable pace that anyone’s really that, that worried about it. But yeah, if we, if we did get to that point where, you know, there’s no, no more need for anyone to make tool and die or no one to, You know, construct a building and no one to, you know, write code at Spotify, then what does society look like? And yeah, I don’t know.

[52:12] Tim: I think at least in the near term, the free market optimist in me says, you know, it’s not a zero-sum game, right? So you’re not hiring the designer, but maybe now the designer also has the opportunity to go start this very streamlined startup. And, and be able to do things that he or she couldn’t have done previously in the, in the same way that, you know, it’s exactly what you’re doing, right? Maybe you’d still be at Finicity if you hadn’t, if you hadn’t, you know, had the opportunities to do what you’re doing here. So yeah, I mean, I think, you know, I, I don’t know what that means in the long run, but I think, I don’t know. I think at least right now it’s opening opportunities and Now’s the reality we need to live in. So I think, yeah, I just think there are huge potential for people right now.

And I think, you know, I was talking to a friend about someone who’s not technical, but kind of knows LLMs fairly well about their impact recently. And he was saying, you know, are there really like real uses or are these just kind of like toys? And I said, I think even if progress stopped right now and we just had the models we had right now, we’d impact software development for the next 100 years. And I don’t know actually what I meant by saying the next 100 years, but the reality is people all around the world are doing things like you’re doing right now. And it’s very cool. And it’s—

[53:39] Jowanza: Sure.

[53:39] Tim: The benefits are undoubtedly there in my mind. And I would say in your mind, from what you’ve shared.

[53:46] Jowanza: I agree. I think, and to your point of the non-zero-sum game, you think about this as like, okay, so because I don’t need to hire a designer, then I don’t need to raise as much money. And then my investors could fund 2 companies instead of 1 company now, right? Which could be just a better outcome overall because, you know, that there are more companies, more people tackling more problems. And, you know, maybe 2 of our companies would actually employ more people than my 1 company ever would in the longer run. So yeah, there’s, I think this, that’s a really positive way to look at it. I think it’s easy to, yeah, come to a more doom view of it, especially if you see some of the places where AI is really tackling. So things like taxis, right?

It’s like there’s, you know, just millions of people that rely on Uber and Lyft for some kind of income. And, you know, the thought of that income drying up for them is a devastating thought. But Would that turn into a different kind of opportunity for them? I hope to be optimistic enough to believe that it would, because that’s a future that I like a lot better than the future where it’s like, no, there isn’t anything else. And this, whatever, $30K a year that you’re making from this job, good luck finding a replacement for it.

[55:04] Tim: Yeah. Well, we won’t aim to solve any age-old economic problems today.

[55:10] Jowanza: We probably won’t.

[55:13] Tim: I would love to talk to you more and we’ll maybe try to do another episode sometime about kind of more of the nitty-gritty about like effective use of Cursor. Um, I think that’s an interesting topic, but I’ve enjoyed a lot of the higher-level discussion and I don’t want to go down that rabbit hole now, an hour in. Um, any concluding thoughts you have?

[55:34] Jowanza: Just optimistic about the future and, uh, Yeah, I just love the opportunity to build things in this era. And yeah, hopefully, you’ll see some Parakeet ads coming soon. We’re going to try to turn on the advertising spigot. You’re not my target audience, so if you see ads, let me know because I’m probably wasting money if that happens.

[55:56] Tim: I use ad blockers as aggressively as possible or pay for subscriptions to avoid them. So maybe if you start buying some of those cheap Twitter ads they have these days.

[56:05] Jowanza: Well, thanks. Thanks for having me on, Tim.

[56:06] Tim: That’s great. Yeah. People can follow you. I think your website is, is it jowanza.com?

[56:10] Jowanza: Yep. jowanza.com. And yeah, I’m Jowanza on all social media.

[56:14] Tim: Yeah. And very interesting follow and very interesting life. You know, a lot of varied interests and things. I’ve learned a lot from you and people can check that out and you can, they can check out the earlier discussion with Jowanza on my podcast at podcast.tdhopper.com. As well as the discussion with our mutual friend, Ravi Mody, about this same kind of topic is there as well. And some interesting back catalog. Now, 10 episodes over 4 years. That’s quite the catalog. But quality over quantity.

[56:47] Jowanza: All right.

[56:48] Tim: Thanks for your time, Jowanza. It’s awesome.

[56:49] Jowanza: All right. Thanks, Tim.

Feedback