Earley AI Podcast Episode 67: How AI Is Transforming Software Engineering With Yang Li of Cosine

In this episode of the Earley AI Podcast, host Seth Earley sits down with Yang Li, a leading figure in AI and software innovation. Yang is the Chief Operating Officer of Cosine, an advanced AI development firm, with deep experience driving startups, scaling organizations, and pioneering advancements in engineering and software development. Yang’s work focuses on leveraging AI to empower the next generation of developers, especially in navigating the increasingly complex landscape of modern and legacy codebases.

Yang and Seth dive into how AI is reshaping the role of software engineers, the evolving challenges of handling massive backlogs and legacy systems, and what creativity and efficiency really look like in an age of AI-powered software development.

Key Takeaways:

• AI’s Impact on Software Engineering: AI is shifting the developer’s role from hands-on coding to more creative, iterative, and strategic work.
• Tackling Legacy Code: Cosine is pioneering new ways for AI to handle outdated and complex codebases (like COBOL and Fortran) that most engineers—and AI models—struggle with.
• Augmenting, Not Replacing, Engineers: AI tools like Cosine’s Genie reduce ramp-up time for engineers, help address daunting backlogs, and act as creative partners rather than outright replacements.
• The Challenge of Benchmarks: Yang explains why public coding benchmarks can be misleading when bringing products to real-world enterprise environments, especially with diverse codebases.
• The Emergence of ‘Vibe Coding’: Idea-to-prototype time is shrinking, allowing non-technical team members to quickly bring their ideas to life using AI assistants.
• Risks & Limits: Over-reliance on AI, standardization versus differentiation, and the need for new evaluation criteria in engineering organizations.
• Future Skills: The importance of risk-taking, adaptability, and prompt engineering as software development evolves, plus insights into how organizations are rethinking career ladders and promotions in an AI-powered world.

Insightful Quote from Yang Li:

"Previously you had to use words and language to describe your idea, you can now show people your idea... The time between you having thought of an idea to actually be able to show people that idea has now reduced almost to zero because of vibe coding."

Tune in to discover what’s next for software engineering in the age of AI, and how to stay ahead in this rapidly changing landscape.

Thanks to our sponsors:

• VKTR
• Earley Information Science
• AI Powered Enterprise Book

Transcript

Copy Transcript Copied

SPEAKER_00 0:01

This is the Early AI Podcast hosted by Zephyr. Join us as we delve deep into the passions, expertise, and experiences of thought leaders and practitioners to talk about what's possible with artificial intelligence. The Early AI Podcast is sponsored by Early Information Science, your digital transformation journey with design and deployment of innovative technology solutions, as well as Vector. Now enjoy the show.

SPEAKER_01 0:28

Well, welcome to today's Early AI Podcast. I'm Seth Early, your host, and today we're diving into how AI is changing the landscape of software development. With AI models advancing rapidly, the role of developers is shifting in big ways. And we'll break down what that means for the industry and what's really next. Our guest today is Yang Lee. He's a leader in AI and software innovation. Yang has a strong track record in scaling startups and navigating complexities of AI technology. Currently, he's chief operating officer at cutting-edge AI development firm Cosine. He's played a key role in everything from pioneering a micromobility IPO to driving major advancements in engineering software. His work focuses on leveraging AI to empower the next generation of developers. Yang, welcome to the show. Thanks for having me, Seth. Let's start off with the big picture question. When you start thinking about AI and development, how is AI reshaping the role of software engineers today? We know that there's lots of different approaches for doing code generation. We know there's GitHub copilots and other types of uh tools. With AI shifting from hands-on coding to more strategic and architecture-driven approach, what do you see as the key elements of that transformation?

SPEAKER_02 1:43

Yeah, I think that, you know, my view is that it's become quite a binary environment, right? So on the one hand, which I think which is very publicly noticeable, developers are pushed towards becoming much more creative, to build experiment much more, iterations much faster, build whether it's new, brand new apps or software or even brand new features, this vibe coding phenomenon has pushed developers to become much more creative. They become the ideas person. So they have every skill set and no excuse now to not become the pioneers of new ideas. On the other side, I think what is less talked about is also the vast quantities of backlog tasks, right? You know, any organization that has software more than a couple of years old with more than a million or two lines has a huge backlog of whether it's bugs that are non-critical, features that you know are important to some customers, but probably not enough to divert the entire engineering team towards, or even just nice to have, like these ideas that are more rounded but just require more engineering effort to do, but are sitting on a backlog. I think that is now the next frontier where people are focusing on to say it's fun and it's useful to have greenfield projects and vibe to put your way through that. But what do we do now in terms of the backlog that we've had maybe years, if not decades, of? Yeah.

SPEAKER_01 3:05

So so that's that's really super important. And I know there's some organizations, there was an insurance company we worked with years ago that had, you know, of course, they still have COBOL, right? And they had so many systems and processes and just such complexities that trying to innovate was really a nightmare for them. And that that legacy code base that that they had was just insurmountable in terms of trying to modernize that. So I imagine that that's certainly going to be true for some organizations. How do you how do you really see that being addressed in in this uh AI-driven software engineering environment and and um landscape?

SPEAKER_02 3:43

Yeah, I think it's it's a question or a problem that we were posed quite early on. When we started Cosign, you know, we of course were dough-eyed and idealistic and thought, you know, in a few weeks we could create a solution that every investment bank and insurance company under the sun would use. And you know, quite frankly, we were put it in our place very early on. Another from our side is that we spoke to a you know, a bold bracket investment bank that flew us out, present we presented to the managing directors, and they just asked us point blank how are you going to help us make PRs uh, you know, and ship new code in COBOL, in Haskell, in Assembly, you know, to a certain extent that a lot of these languages are no longer taught. Like no, no college student is learning uh you know COBOL or Fortran anymore. And so what do we do?

SPEAKER_01 4:34

And there's not a not a lot of training examples out there, I would imagine.

SPEAKER_02 4:37

Exactly, right? And and even if there are training examples, then they're not open source. They're behind their private repos inside these enterprises that they wouldn't never let you have access to. And so that's that's fundamentally a lot of these important and you know out-of-distribution sort of examples are not also not trained inside LLMs, no matter what model you use, whether you train your own, whether you use an open source or a closed source, open AI, anthropic, a meta model. It's just out of distribution. So what can you do about it, right? So we took the perspective of you only have two options in in our view, right? You have some players in the space who are doing agentics software engineers like we are. You you kind of brute force it. You rely on inference-time compute, you throw as many solutions as possibly for humanly or even a GPU possibly that you can generate. So you're somewhat throwing spaghetti at the wall, hoping that one of these solutions will work. And in an infinite time frame with enough compute, I think it is possible, but it's probably not very probable that you'll land on something that adheres to you know four-trand code that was written in 1971. I think that's the problem, and that's what we always wanted to focus on as an organization. We knew that there were lots of players and competitive space in a Greenfield project, in a modern code base, whether it's TypeScript or JavaScript. But what we wanted to do was, well, how do you train AI to be good at legacy code bases, you know, uh coding languages that have fewer examples? Well, we fundamentally said, well, how does a human do so, right? So we thought, well, if you are a human, if you were dumped inside a code base you were unfamiliar with, and if you're looking at a language that you haven't learned fully, you would rely on two things. One is that you would kind of browse, right? You would gather information, you would open some files, you would read documentation, you would, you know, to some extent, you would look at comments that have been left by other developers in the past. And on the other side, you would rely upon your other knowledge to generalize across, right? So you would look at other languages that you would be familiar with to do so. And so that's what we did. We uniquely have uh you know, generated a synthetic data set. And this is from day one we've always said that mimics how a human would reason and navigate a code base and do you know coding tasks, right? So what we did is that we essentially uh are able to generate uh that data set that teaches or shows the AI how exactly for types of tasks, what files you would open, what what are the steps you would take next, so that there is some sort of semblance. And I'm not claiming that we've instilled reasoning inside AI model, but it's it's some sort of mimicry of reasoning. And so what that allows us to do is that our product and our AI model that powers it is able to take an unfamiliar code base, an unfamiliar task, and kind of work through it and generate much more signal, right? So that it can become much better at doing these tasks.

SPEAKER_01 7:29

So so that's interesting. And and how well has that worked in practice? Have you been able to tackle some um revamping and and uh uh redeployment of uh of that type of legacy um software?

SPEAKER_02 7:44

Yeah, so I I think that there is two data points uh to point out here. One is, of course, everyone in this industry cares about benchmarks, and our latest benchmark is we ran Swede Lancer, which is an open AI release coding agent benchmark, which is they took a million dollars worth of real developer tasks on upwork. So these are real bounties that uh someone was willing to pay for and then completed by a freelancer, and then they pit essentially AI coding agents up across those million dollars of tasks. We scored, you know, we essentially scored 49% uh across the benchmark, and and that is significantly higher. And don't quote me on this, please don't check this. My believe is like uh so if you look at OpenAI's GPT-4, they were at 8%, and uh 01 was at 16%, right? So it is a significant jump in terms of its ability to solve problems of real developer tasks, which we hope, right? And and no benchmark is perfect, it's always room from benchmarks, but it is a cross-section of a real developer task across the spectrum. I was saying, like, you know, and I think even you know, the the second data point is that you know we we now do have uh since we last like connected, we we we do have a publicly available product now everyone can access. And one of one of the larger enterprises that we deployed at is a is a large um you know, you know, bulge bracket investment bank that that is specifically asking us to tackle the the problems that their engineers cannot do, right? And um, you know, I was I can't I can't tell promise you what the long-term aspect is because we've just launched a week ago, but early on it's it's very promising in terms of like, you know, just even if you are super skeptical and say, you know, I don't believe in a gentic software engineers yet. We have seen that time to get a human engineer up to speed on a language or uh or a repo that they are not familiar with has decreased dramatically. Where we're talking orders of magnitude faster.

SPEAKER_01 9:36

Interesting. So so it's essentially helping the engineer be able to tackle these problems. Now you said they were not able to tackle the problems. What was the what was the big um obstacle when you said their engineers couldn't do some of these things? Was it just lack of experience and fluency in the in the uh languages because they're so archaic? Was it the level of complexity of the of the different systems and tools? What was the um a big obstacle?

SPEAKER_02 10:01

Yeah, I think that I can't say for certain, but at least from the data that I I have seen, the my my gut feel is that the vast majority is from bad prompts, right? So there's two, there's essentially a couple of ways that you can use our product genie. You can just type it into a chat box, give it a prompt, you can copy and paste a ticket from linear, you can do a direct integration, so you can assign the linear task or Jira task, or you can send it from Slack. When the prompt or the ticket is detailed enough, then our agent is is much more capable. It's usually the lack of information that is problematic, right? So for a human, you can be much more um flexible in terms of being vague, and you know, if you said something ambiguous. No, yeah, ambiguously say, you know, uh fix the fix the bugs on the front end. That that that maybe because you've spoken to a colleague at a water cooler, you wouldn't understand that. But for an agent, because you don't have that context, it just doesn't work. So if you can overcome that problem, the next problem we have is, and I don't think this is unique to us, I think this is a lot of coding agents are the same, is that if the task is too large or too too big, right, it events essentially it kind of loses its way. I'd say it's you know, not to humanize it too much, it almost gets distracted. And so what we are about to release next week is a new feature called Auto PM. So, you know, we as a it's an auto project manager. We see it as our version of uh deep research as like an open AND where it can ask further questions, it essentially puts itself into a loop and it can go for hours, right? We've given it tasks where it has come back three hours later and successfully deployed, you know, a huge change, right? Where there is like tens of thousands of lines of differences. And I think for us that that's the next step, what we're trying to fix. There's always a limit of what we we think that, as you know, as you ship, as you think you fix somewhere, there's always a new leak that appears somewhere else. But I think we are moving towards both user education becoming better, but also a product becoming better much more truly agentic, right? I saw something in X the other day. It's like you can't really claim your uh AI tool as agentic unless it basically when you have to prompt it multiple times for the same task. And I think we we probably agree, right? When we hopefully our next update will decrease that, but we're not truly agentic fully until we get to the point where it's completely autonomous by itself.

SPEAKER_01 12:18

Well, I I guess I would not completely agree with that. I would think that you still have to give course corrections, you still have to give ongoing instructions and prompts and so on. But I understand the point. Yeah. Um, I'm not sure I would agree with it completely. I think you could still be agentic and not and still have some interventions. Anyway, I don't want to argue that point. But but my question, uh let me rephrase my question a little bit, because when you first mentioned this, you said this uh large uh investment bank was asking you to solve problems that their engineers could not solve. And so can you talk more about what was holding the engineers back? So where how did you fill that gap? What was the specific capability that he did not have, or what was the reason? Was it simply a matter of bandwidth? Was it simply skill set? Was it complexity? What were the things that that were stopping the agent, the engineers from being able to solve those problems?

SPEAKER_02 13:09

Yeah, I think there's a couple of different categories, but you're absolutely right with the first one. One is number one is just bandwidth. A lot of these times the engineers do not have the capacity to get to it. Like when we talked about the backlog, these backlogs sometimes decade long, if not more. What they simply do is that they assign every task to our agent. And speaking very candidly, some tasks we only return a result that is 20, 25% useful. Other times we return something that is 99% useful. But it is still better than zero. And then what they do is that again, the feedback we've gotten is even if it doesn't completely get it right, it's much easier for an engineer to critique the work than it is for them to start on a blank sheet of paper and have no context. And so they they are able to work asynchronously, and even to the extent where they still do not assign any engineers fully to this backlog. What they do is to say, well, the engine, the human engineers, you're assigned for this print, you still have your own tickets that you have to prioritize. But in your downtime or asynchronously, take a preview or take a peek at what a genie has returned. And if it takes you know one or two prompts, or it takes, and we we essentially allow the developers to have the same um you know code editor that Genie has access to. So you could just literally dive in and change a few lines of code. If that is all it takes to ship the PR, and what Genie does is it runs your your CI fully, right? So it you have some level of confidence already that the PR its shipping will work if it passes your CI. It allows them to basically juggle and multitask much more effectively. So that's the first category. The second category is I also see a lot of problems, particularly with legacy code bases, which is simply size of code base. No engineer can memorize a million lines of code and you know how it works and interoperates and all that stuff. And it's simply, you know, whether it's a new engineer or an experienced engineer, it's it's allowing them to essentially say, okay, I now have some idea where to go. And even if the agent is completely wrong, it started my thinking in towards that direction. And it it it's it's this essentially to solve the cold start problem, right? I think non-engineers or people who haven't done software engineering before view it as you know, the engineer sits down, immediately starts writing code as if it's in a Hollywood movie, and then at the end of the day, they ship something and it works magically. They're probably, I think most engineers would agree, the vast majority of the time is thinking and researching and navigating. And and that for what we what we do is that we eliminate that cold start problem. Um, and sometimes 100% of the time, and sometimes 20% of the time, right? And then it that doesn't matter. And the very last category, I think, for us that is um surprising, right? And and maybe this is not fully surprising, not surprising inside an IDE. I think that it's become the norm for people to use uh AI-enabled ID like cursor or windsurf, and it's it's but that's on device, right? So someone you can't really do asynchronously, and you know, if you wanted to a lot of times if you wanted to access your terminal and do commands, you have to be present to allow it. Asynchronously on an agent, we have found that it's uh it's almost a creativity problem that we're solving. So when an engineer is given a vague uh task to say improve uh conversion or improve loading speed, right? We have seen people do the same task concurrently in multi in multiple instances. So the same ticket is prompted slightly differently 20 different times, and then they the engineer then comes back, you know, let's say 30 minutes later, and then they see which one has promise. So it's it's A-B testing on a massive scale where they they couldn't think of every single idea, they then tested every single idea, and then they essentially eliminate the ones that are not working very aggressively. And that is something that we've seen a lot of the larger organizations that we do, because obviously the larger organizations have lots of voices and lots of great ideas, but how do you filter down to the right idea? Well, data or performance speaks for itself, right? So why not try it? And to enable people to do it asynchronously, multiple instances at the same time, concurrently, is something that is only achievable if you have an agent and not inside your IDE, right? And and also for us, you know, the way that our pricing works, right? And you know, people can go on our website and look for pricing on cells, so we'll promote ourselves here, but it's flat, right? So I I think for us it's like people are now increasingly worried about using AI-enabled IDEs and the price that yes, there is a fixed monthly subscription, but then the number of tokens and or you know computing units that you have is is suddenly going to skyrocket if you really rely on it. And efficiency increases, but so does your cost. I think that it's not as linear as people think, which is efficiency increases and then cost decreases. A lot of organizations have not seen their cost decrease. They've actually seen their cost increase despite the productivity increase that they're having.

SPEAKER_01 17:55

Right. I mean, it's almost I almost think that that generative AI slows me down, right? Because I will start with my materials. I never ask it questions without context. It has all of my content, it has articles, it has my tone and voice and all of that. But then when I start processing my ideas, I have too many options, right? I have to and I have to go through different iterations. And so I agree, you know, the more possibilities there are, the more bandwidth it requires to evaluate those. So hopefully that'll that'll improve. Now, one of the things that we talked about in the earlier uh prep uh call was were benchmarks and how you mentioned at the time that you you're you did really well on a benchmark. And maybe you could talk about that benchmark. But then you said, but the product was still lacking from your perspective. And you want to talk a little bit about benchmarks versus you know real-world product capabilities, and then what you found, you know, was what was that disparity?

SPEAKER_02 18:49

Yeah, no, I I think you know, this was last summer when we we ran Sui Verified, right? Which is an another coding agent benchmark that was industry standard. At that time, we were the highest score in the world. We haven't since run it. And I think that it's quite indicative why we haven't rerun it because we didn't think it was particularly useful anymore to help us build a product. But uh we still represent as the largest jump in score in its history, you know.

SPEAKER_01 19:16

That's impressive.

SPEAKER_02 19:17

Yeah, I'm arguing with that. You can't argue with that data, right? Yeah, we can't, and and I think and again, don't quote me on this. I think we are also one of the few people, if not the only people in the world store that has run every single task on Sweetbench and Sweetbench verified. It's just actually it's an incredible hard benchmark to get up and running. Um and and and the problem is with with Sweetbench, is that at the time we blindly accepted because everyone else loved it, then if we beat it, then obviously our product will be great. In hindsight, it was only Python, right? And and then it was only about bug fixes. Engineers across the world don't just use Python to fix bugs, they do such a wide variety of things. And we we actually soft-launched that product to a small cohort of, you know, we had tens of thousands of people on our wait list, and we let a few a few like sort of select users and some smaller ones, some larger ones, on it to try it, but it just kept on not working, right? And and then it was because it was it was such a disparity, was to say we had such a great benchmark result, but in the real world it wasn't working, and there was a couple of things that wasn't working. Number one is that we the product itself just wasn't conducive in supporting how to work with an agentic uh AI coding agent, right? At that time, our product was even if Genie got it 99.99% right, there was no way for you to make small changes with a code editor, and and you would have to reprompt it and hope for the best and hopefully it came out again. And that was non-deterministic. And and we were just too naive thinking that of course we it would it would work and you could just re-roll the dice, but that just wasn't the case. And I think the second point that we we found was that you know, we uh actually found that it it's not just one benchmark. You we actually had to create from the difference between last year and this year is that we now have a a plethora of internal benchmarks that are not public, right? We we use the full candor here. We do we do use the public benchmarks as some sort of PR and some to promote ourselves, and it's generally accepted, and people get very excited about it. And it's it's it's part of the portfolio that we use today. But a lot of the times now we we do is we have to create benchmarks in areas where there is no coverage on public benchmarks, right? So, for example, of what about a code base, or what about a project that uses multiple languages at the same time, right? Or what about you know using libraries that are severely outdated instead of just the most up to date libraries? And that that to us is actually the biggest learning is that we've now have a dedicated team just to build in internal evals doing that. And for us, then this is a I guess a little bit of I don't know. My team behind me is going to kill me for saying this out loud, but we are, you know, we are we are very advanced in supervised fine-tuning, and this is what a current product uses. But of course, like everyone else, and you know, there's an MIT review, tech review article about us in Poolside, both tackling the next frontier, which is you know, reinforcement learning with code execution, creating our own evals and reward functions is how you win the next frontier doing reinforcement learning sort of techniques. And for us, we're already seeing for Genie3, our next model, huge leaps in sort of performance just simply by having really great internal evals that other people don't have. And I do think that that's what's going to make or break our startup in the future about creating these coding agent models.

SPEAKER_01 22:43

Interesting. That's interesting. So, so um one of the things that we had uh talked about is the danger of you know over reliance on some of these tools, just like we see you know, marketing organizations uh, you know, offload too much of their stuff to a gen AI application, and then their campaigns kind of sound like everybody else, and you know, they don't they don't have as much differentiation. I like to say uh, you know, uh uh standardization when you're doing stuff that other people are doing will give you some efficiency, but differentiation gives you competitive advantage, right? And now in the coding world, of course, you are there are always differentiating because you have very unique problems to solve, but is there still uh a potential or is there overly reliance? Are people getting potentially getting lazy in terms of depending upon these tools or or offloading too much of these tools? And and and if so, what's what's the implication of that?

SPEAKER_02 23:38

Yeah, I I think there are from talking to our customers, I think there are probably two points that I would mention. One is I don't think that there is an over-reliance just yet, right? There may come a time where we do everything and nothing is done by humans anymore. But so far, at least specifically for our unique quality of being able to tackle complex legacy code bases and large backlogs, the backlogs are huge, right? But this is so people there is a lot of backlog tickets to churn through before people start running out of things to do. And these were unnatural. The second point I would say is you know, we we found a unique perspective from actually um an HR executive. So we were talking to a large enterprise about deploying our solution on premises, which we actually managed to engineer a solution for. Uh and you know, we are cloud native, and while main public product is a is a cloud product, but for this customer, we built an on-prem solution. The the HR director uh or the SPP of HR essentially asked, how do we promote people if they are everyone's skill set is at parity? When a junior engineer is doing the same work and the output as a senior engineer, what does a career ladder look like? So I wouldn't necessarily call it lazy, right? So we we didn't call people lazy uh you know, from using better IDEs or you know, better computers. It's just a shift in technology and becoming more efficient. Is my I'm maybe I'm a tech optimist here. But I do think there are some consequences in terms of how do you assess, right? Laziness is one factor, competency is another. How do you assess the promotion factor? And and prompt engineering may be it, right? So you get the effectiveness of writing prompts is where you assess someone, or maybe you just look at sheer output, right? Does it work? And and what is a binary outcome? Does it work and how many PRs did they they merge? How many PRs they shipped what were merged in the end into the code base?

SPEAKER_01 25:33

Interesting. So I I was uh listening to an article on uh uh one of uh a podcast uh someplace, and they were talking about how uh organizations are uh uh trying to test people uh you know for employment. And obviously one of the ways of of doing that is with task-based assessments. And then the question is do you let people use AI tools or do you not let them use AI tools when they in fact will be using them in their work, right? So it was kind of an interesting uh dilemma, and there was some uh discussion about how people are addressing that and and getting around that. But I think your your point around evaluation is very important. What and what what are the results? What are the outcomes? So, you know, when you think about the ability to handle autonomous development of very complex software, uh, you know, there's there's some really great thinking here that you've shared. But what what are the what are the biggest misconceptions that you're seeing in the marketplace? What are people not understanding about AI assisted or AI generated software engineering? What are the misconceptions? What are people missing?

SPEAKER_02 26:40

I think the first one is in general, and maybe this is I shouldn't be doing it because I am in the industry. I think in general, coding agents are overhyped. I think that there is an expectation and you know, of being able to do tasks end-to-end fully, any task, anywhere, any code base. We're not quite there yet, right? I I think that there is no player, whether you are you know well funded or you know, lots of great talent, whether you are cognition in Devon, whether you are, you know, pool side, whatever you may be. I don't believe anyone is there. And I and I think that what the problem is, is that even though everyone claims to be a generalist coding agent, you do actually drill down to it. There is a niche that people are kind of dominating. So I I you know I may be misrepresenting my competitors and you know, fellow startup people, but you know, Cursor and Windsor, you know, Replit, right? We count Amjan Massad as an investor, um, you know, are great at brand new projects. But we we do think we are much more competitive. We are lighter, we are faster, we are more capable at legacy backlog tasks that no engineer ever wants to be assigned to. Maybe with time it will converge and we will become generally better as the models, underlying models become better as well. But I think for now, the the the misconception is it's not fully capable. We we you have to drill down and be honest and say you are you're better at specific things. We we can, right? If you if you go on to uh you know uh our our a website now and sign up, you you get a free trial, right? So everyone can sign up and in and to try it out and you don't mind. If you people don't like it, you can cancel. But you can ask it to do uh do you need to do a brand new project, right? So make a Tetris clone, you know, make me uh you know a data visualization website. You can do it. I just don't think that we are the best tool for that. And I think there are plenty of other tools that are better.

SPEAKER_01 28:33

So um interesting you talked about vibe coding uh earlier. And what is your definition of vibe coding and and what do you think that means in in the marketplace? And I imagine there's everything from you know, it it reminds me of the days of Lotus Notes of all things, back in the when people were sending their administrative assistants to application development classes, which I was teaching, saying, anybody can do this, right? Anyone can to build the notes application. And then you saw what it meant when administrative assistants built, you know, notes formed and so on. But tell me what your thoughts are about about vibe coding, and then you know, what does it really mean in in your world, and then what do you think it means in the bigger picture?

SPEAKER_02 29:19

Yeah, I where did that name come from? I think I think for me, you know, and maybe my pause here gives you everything you need in terms of I think it's a fuzzy definition, and and I definitely bend the definition depending on the conversation I'm having here. But I think in general I think it it is it is it is a seamless way for someone to get to turn their idea into something that is presentable to share with someone else. It doesn't always have to work, and it doesn't, it definitely isn't seamless. And you know, you've seen lots of horror stories now on X, where you know there's security vulnerabilities, there is the fact that you know after a certain point it's not scalable anymore and they have to rebuild it with a human engineer. I think those problems will solve itself for time, right? Everyone's improving, their product and models are improving. But I think what it is for me, what vibe coding is, is where previously you had to use words and language to describe your idea, you can now show people your idea, right? And that that time between you having a thought of an idea to actually be able to show people an idea has now reduced almost to z to zero because of vibe coding. And and I think to some extent I agree, it has democratized. You know, in our team, you know, we have people who are non-technical people who haven't learned to you know code. And part of the Friday demo sessions that we have, you know, we have uh, you know, if we have some pizzas and we have some beers for everyone, we asked the non-technical people to build us uh a demo, right? Whatever feature, whatever new idea they want, they have to prompt it their way. We we helped them obviously set them up with with something like Vercel so that we can deploy and actually see it. But we want we want to see that side. And actually, I would say a lot of the time, maybe more than half of the time, the best idea that came out from that session is a non-technical person because they have a different perspective. Whereas previously they could not possibly code that up.

SPEAKER_01 31:03

Right. And what what kinds of ideas are people coming up with? And just just out of curiosity, like what would a vibe coding output be for a non-technical person in your organization?

SPEAKER_02 31:14

Yeah, so you know, we uh we had I can come up with two ideas, right? So we essentially had an idea which was sort of like an abandoned checkout uh idea. So when you see a new customer go through the funnel and at some point they fall out. So instead of emailing them and doing traditional mode, you can see certain behavior within the product already that you instantly insert a, let's say, a coupon, or give them an offer, or prompt them with a certain uh pop-up, or maybe something to nudge them in the right direction, where it was based on data so that you've gathered so far through the funnel, or people who are similar cohorts, right? And that was an idea from a marketer where where you couldn't, you know, we probably an engineer may not have thought about that because they're not focused on it. And and the way that they did it was to say, well, we wanted to build essentially um, you know, uh essentially a small app that was running internally that captured these data points and read it from somewhere like post hoc, where it caught that behavior and put them into a cohort, you would instantly give them an offer that you started pricing for them. And another idea that what that came up was essentially, you know, based on again, if we found you know, certain behaviors or demographics to say, well, they may be more inclined to use to work on a project that is on a certain code base or coding language, or you know, they're from a certain maybe they're from a certain region where we say, okay, they're probably learning the language for the first time. So JavaScript, TypeScript, maybe a more modern language, we kind of shift that again towards the the copy might change as as they are going through the just really great ideas that we would we we could action and generally will make an impact to our business. Right.

SPEAKER_01 32:50

No, that's great. And I and I I totally see your point of giving those tools and capabilities to people who normally would not have them, but they still have great ideas and they can explore those ideas uh in a meaningful way. So before we wrap up, when you look back at your career and your work across different sectors, what advice would you give to developers and technology uh professionals who are trying to make an impact in 2025 and beyond? What kind of advice would you give people? Sometimes I say, if you went back to yourself, if you could go back to yourself after you graduated college, what would you say? That's one way to think about it. But generally speaking, you know, where what guidance? Because things are changing so rapidly. And it's also kind of asked the question of where where the future careers will be and and so on. But what kind of advice would you give people?

SPEAKER_02 33:38

Yeah, I I I think again, speaking very kindly, I I always hesitate to give advice because I I still don't feel like I know what I'm doing either.

SPEAKER_01 33:47

You're figuring it out as we all are.

SPEAKER_02 33:49

I'm figuring it out as I go, and I feel like if I repeated my life again, you know, if it was a true controlled experiment, I'm not sure I would get the same result again. So I I always I always hesitate because I always think there is a little bit of romanticizing for people who achieved any success to retrospectively, you know, uh apply logic to say, well, I was successful because I did this. But I think I would encourage, and this is not unique, my younger self to be not afraid to take risks. And and and I suppose I would frame that as in you kind of only need the dice to land on six once. You know, you just need to go and do it, right? Whatever thing that you have an inkling for, whatever that you you feel like this could work out or could not work out, particularly if you are young and you just graduated, you know, you don't have kids, you don't have a mortgage, you don't have that, just go do it. Because like, yes, you may fail and you might be embarrassed, but actually if you just strike it lucky, you know, I've been very fortunate to have uh encountered and worked with and exited with lots of successful entrepreneurs. And I think if you got them to speak candidly, they would say they worked hard, they are smart, but actually they got lucky, and that luck came from the fact that they actually did something, right? This this idea of the bias towards action of just go and do it.

SPEAKER_01 35:08

Right. That's a great, that's a great point. And you know, if you don't roll the dice, you're not gonna get six sixes, right? So you have to take those risks and you have to take those chances. And and you're right, you know, early in your career you can do that. Well, thank you so much, Yang, for joining us today and sharing your thoughts and your insights. I really appreciate it. Um, and thanks to our listeners for tuning in. And uh, of course, stay with us for more conversations about AI and and how things are evolving. Also, want to thank uh Carolyn uh Southwick for uh her help in putting the show together. But uh again, Yang, thank you so much for your time today. Thank you for having me as well, Seth.

SPEAKER_00 35:44

Thank you for joining us on another deep dive into AI innovation. Tune in next time when we introduce another industry expert and discuss how to maximize AI in your world. The Early AI Podcast is sponsored by Early Information Science and Vector. To learn more, visit early.com. That's earlier.com. Thank you for tuning in.