Z Talk: A 20,000-Word Deep Dive with Cognition CEO Scott Wu — "Our Engineering Team Is 15 People, Each with 5 Devins"

Z Talk is ZhenFund's column for sharing insights.

The company behind the first AI programmer, Devin, has started using Devin to build "Devin" itself.

Last December, Cognition launched the world's first AI coding programmer "Devin," positioned as a virtual engineer that requires no human intervention, can write code independently, and complete entire projects on its own, priced at $500 per month.

Within six months of the product launch, Cognition completed a Series A round of several hundred million dollars, doubling its valuation to nearly $4 billion, making it the undisputed star company in the AI programming track.

Currently, Cognition's engineering team has only 15 people, but each engineer is equipped with a "virtual team" of five Devin agents. Right now, approximately one-quarter of Cognition's internal GitHub Pull Requests are completed by Devin. Founder Scott Wu expects this proportion to rise to 50% within a year.

In a recent appearance on Lenny's Podcast, Scott Wu spoke in more detail about Devin's journey from concept to "junior engineer partner" capable of end-to-end task execution, how it integrates into existing software development workflows, and how he thinks about the evolving role of engineers amid the AI wave.

This article is partially republished from Founder Park, edited and compiled by ZhenFund. Here is the full text:

- Using Devin to build Devin: Think of Devin as a junior partner fighting alongside you. Every engineer building Devin makes extensive use of Devin itself.

- Devin turns engineers from "bricklayers" into "architects": You can give high-level instructions, specifying how you want things implemented. You still need to steer the direction and define the specifications, but the scale of what you can accomplish in a day, the systems you can build — it's on an entirely different level.

- Development will increasingly resemble asynchronous collaborative writing: The key is to clearly define the problem you're solving and the system you're building, then let Devin handle the rest asynchronously. You only step in at points requiring professional judgment.

- Devin excels at clear, specific tasks: You should give Devin tasks, not problems. Guide it when necessary to ensure it stays on the right track.

Devin Multiplies Engineers' Capabilities

Lenny: Let's start by talking about Devin and giving everyone a sense of what it actually is — this is your company's main product. What's the simplest way to understand Devin?

Scott Wu: Devin is a fully autonomous software engineer that can complete tasks end-to-end. There are many great tools on the market now covering various stages of the AI coding workflow. What's special about Devin is that it's a complete asynchronous workflow. You can @Devin in a Slack thread about some issue, or tag Devin in Linear, and Devin will create a Pull Request in your GitHub. So it's entirely designed to collaborate with engineering teams, just like your junior engineer.

Lenny: I remember when you first launched this product, the tagline was something like "your new AI engineer." It was excellent in many ways but had room for improvement in others. It's been about a year since you launched?

Scott Wu: Yes.

Lenny: If you were to measure Devin by engineer seniority levels, where would you place Devin at launch versus Devin today? Is this even a good way to measure Devin's capabilities?

Scott Wu: When we first released Devin a year ago, people didn't even think agents were feasible. It was a very different era. In early 2024, AI model reasoning capabilities were still in a fairly primitive stage.

Since then, it has evolved significantly. In terms of practical skills, we occasionally make these comparisons — at the very beginning, it was like a high school student taking computer science, then it gradually grew to be more like a college intern, and now it's roughly at the level of a junior engineer.

But these benchmarks are rough, because I strongly agree with the idea of "jagged intelligence" — it's far superior to humans in some domains, yet falls short in others.

Over the past year, we've gained a lot of experience, not just about coding agents but about agents in general — including how to build them and how to integrate them into workflows to collaborate with people.

At that time, Devin had no Slack, GitHub, or Linear integrations, no interactive planning phase, and no way to modify the code it generated. So most of the product features we've developed since then have essentially been about finding the best way to make collaborating with Devin and assigning tasks to Devin as smooth as possible.

Lenny: So a lot of the work wasn't just about making Devin the best possible engineer, but about making it better at collaborating with humans.

Scott Wu: I think it's about 50-50. On one hand, Devin's capabilities have improved significantly and measurably. On the other hand, there's the optimization of product interfaces, tools, and so on. People generally know how to use chatbots and collaborate with them now, but for agents, I think users still need to spend some time and effort learning how to use them and maximize their value. So it's really exciting to see many other companies now investing in the agent space as well — this is a direction we're all exploring together.

Lenny: Can you share anything about Devin's current scale? Whatever you're comfortable disclosing. And where do you think Devin's coding capabilities will be in a year?

Scott Wu: We work with companies at all stages and scales. On the smaller end, there are one- or two-person startups using Devin to build their initial prototypes or products. On the larger end, there are major public companies, Fortune 100 companies, or listed banks using Devin across their entire engineering teams.

Overall, we've seen a very broad range of applications. Obviously, the engineering work done at a two-person startup is very different from that at a listed bank.

But the common thread is that Devin is your junior partner that lets you move faster and truly amplifies your capabilities. It amplifies you as an engineer by letting you collaborate with your own Devin team, rather than having to work on individual tasks in fully synchronous fashion.

Then it also amplifies your team and your team's knowledge base, because Devin accumulates substantial knowledge through working with every member of your team, and can bring that knowledge into each new session.

Product Experience Will Shift from "Text Completion" to "Agent" Mode

Lenny: Let's go back to the beginning of the journey. What's the origin story of Devin? How did all this start?

Scott Wu: Most of the founding team have known each other for many, many years. For almost all of us, this is our first time working together, but we've known each other for a long time. Over roughly the past decade, each of us has had our own explorations in AI. In my case, before this I was working on a company called Lunchclub, an AI product for professional networking, which I did for about five years.

One of my co-founders, Steven, was among the first engineers at Scale AI, which has obviously grown tremendously and done exceptionally well.

My other co-founder, Walden, was an early engineer at Cursor, which has also obviously grown a lot and done very well.

Our whole team is pretty much like this — many of us met through programming and math competitions, but in the decades since, we've stayed in very close contact and each gone our own ways.

We have someone who led a team at Nuro, someone who worked at Waymo, and someone who founded their own YC-incubated machine learning tools startup.

We were incredibly excited to build something together. This was around late 2023, about a year and a half ago. At the outset, there were a few things we firmly believed. One was that reinforcement learning actually works and would become the next major paradigm shift in capabilities.

When ChatGPT first launched in 2022, those models were what we in AI call imitation learning. Basically, you have the model read all the text it can find on the internet, then train it to talk like someone on the internet — that was the core of the initial approach. It was remarkable, passed the Turing test, and had encyclopedic knowledge of many things.

The new paradigm we've entered over the past year is truly high-compute reinforcement learning. This is a fundamentally different paradigm: it can go execute tasks, integrate things, then evaluate based on whether the outcome is correct or not, and use that knowledge to decide next actions and learn from them. We were firmly convinced this would happen.

For us, code was a natural choice for several reasons. One is that we're all programming enthusiasts, so code is intimately familiar to us. Also, code itself has a complete automated feedback loop — you can run code, and this automated feedback is exactly what reinforcement learning needs, and it's what makes these models so good at coding.

Another thing we firmly believed was that product experience would shift from "text completion" mode to "agent" mode. Fundamentally, there are already many great experiences in text completion. It's used in marketing, customer support, education, and coding — GitHub Copilot was truly the dominant product of that wave.

But the major shift we really sensed was from this text-to-text model to a truly autonomous system capable of making decisions, interacting with the real world, receiving feedback, iterating, and taking multiple steps to solve problems. We call this an agent, and that's what we were genuinely excited about at the time. So the direction was always coding, always agent. This seems like it should have been obvious from the start, but even so, over the past year and a half, within the broad direction of coding agents, we feel like we've pivoted roughly eight times or so.

Lenny: I've noticed recently that at all the top AI companies — well, not all, but many — the successful products have names different from the company names, which is unusual. Like Cursor and Anysphere, Bolt (bolt.new) and StackBlitz, you guys are Cognition AI, Vercel's v0. That tells me these products emerged later in the company's life; they tried a bunch of things and then went, "Oh, this one worked." It's really interesting how prevalent this is among top companies.

Scott Wu: Yeah, and even OpenAI's ChatGPT, Anthropic's Claude, Google's Gemini. It's interesting, yeah, I agree.

So when we first started, it wasn't even really a company, more like a project, or almost a hackathon. We basically rented an Airbnb for a few weeks around Thanksgiving, got a group of people together, excited to work on some projects, build some cool stuff.

What's interesting is that what we originally built was actually more like solving those competitive programming-style problems, using an agentic loop to get better at them. Obviously if you're running code against test cases, you can evaluate it, and there's a lot of agentic work that can be done to try to do better. We spent some time on that initially.

Then our whole company story, in a sense, is from one hackathon to another. After that, we did another hackathon, and some of the original ideas for Devin came out of that — actually building a software engineering agent, not just a coding agent, and having it interact with many of these tools. But even then, there was so much iteration. Even the idea of talking to Devin — we had to figure that out.

Initially, it was just you give it a task, it works, and finally shows you the finished code. And now obviously, you can jump in at any time, get feedback on the plan, scope out tasks together. A lot of these things we had to develop gradually as we worked with Devin. Of course, we learned a lot about use cases, product form factor, and we made many major improvements and step changes in capabilities — Devin's ability to use tools, debug, and make decisions. So it's been an interesting journey.

For us, the fundamental question, and what we've been thinking about all along, is: what does the future of software engineering look like? How should we collaborate with AI to write code? Because at the end of the day, that's the foundation of all our product decisions.

Lenny: When did you start tinkering with development? When did Devin launch? How long was that period?

Scott Wu: We started in November 2023, still in hackathon mode. We formally incorporated in early 2024. Then our first launch was in March. So that period was absolutely nonstop. Actually, it's been like that for the past 17 months. From launch to working with enterprises, to heavy product development, building it out and making it work for many real use cases, then going fully self-serve in December, and 2.0 just a few weeks ago. It's been a very busy time for us.

Lenny: That's the understatement of the century.

Building Devin with Devin

Lenny: The idea of treating Devin as a "person," creating a personality for Devin — this is different from any other AI application. I don't think any other AI application out there has a name, has you think of it as a person. Why did you decide to go with this design approach? And how did you design it to work well?

Scott Wu: This is a decision we're quite proud of. There are many different product experiences out there. And what really makes Devin unique in what it does is that you can truly hand off tasks to it.

We've increasingly found that the best way to explain the Devin experience to people is to explain: "Yeah, this is your junior teammate." And this applies to many parts of the flow.

For example, during onboarding — initially we did have a lot of users who came into the interface, saw a blank screen, and were completely lost, or they'd say "I'm going to do a massive refactor of the entire codebase."

And what we learned over time was to guide users to shift their thinking, like "Wait, let's get the codebase set up first." Let's first assign Devin a few simple, small tasks to get familiar with the codebase. Let's make sure that if Devin needs to be able to test code, run linters or CI or whatever, we need to make sure Devin has its own VM set up to do these things.

Similarly, user patterns weren't clear at first. Obviously, you can sit and watch Devin execute step by step. But what we found, as a team that needs to build a lot of stuff, is that the optimal workflow is collaborating with multiple Devins, having them execute tasks asynchronously, spinning them up, and only jumping in when you need to provide feedback or guide the plan.

In many ways, the name Devin is our attempt to capture the soul of the product. It really is treated as an autonomous entity that you can hand tasks to, collaborate with, and over long-term use, teach and learn alongside.

Lenny: I want to talk about Devin's impact on software engineering, and how software engineering will change. This breaks into two parts: using Devin this year as an example, for those enterprises, as an engineer, how is their work and how they build changing?

Scott Wu: We're all software engineers; at heart, I'm still a programmer.

From the macro level: computers are getting smarter and capable of doing more and more things. Maybe one day, computers really can do everything we do, and humans no longer need to be responsible for anything.

I don't think that's coming soon. But before then, as long as we humans still need to program, one of the most important tasks is instructing computers on what we want, what we want to build, what we want to do.

So from this perspective, I think as AI gets more powerful, programming only becomes more important. What's truly exciting for us is seeing this iterative shift.

Right now, we can think of Devin as a junior teammate, or a team of junior teammates, that you can work with.

Every engineer on our team uses Devin heavily while building Devin. So Devin merges hundreds of pull requests into production in the Devin codebase every month.

Our entire team is only about 15 engineers, so AI-assisted coding makes up a pretty substantial portion of all the code we write. Each of us has our own team of Devins.

If you're working on various issues, feature requests, bugs, or researching new paradigms you want to build, naturally there are many handoff points. At these junctions, you can @Devin and tell it: "Here's the situation now, can you help with this?"

Sometimes Devin can complete the task 100% autonomously, create the PR directly, and you merge it; sometimes, you might need to jump in yourself, do 10% or 20% of the work — maybe there are some details about how to scope or architect this feature, or you might want to test the frontend yourself at the end to make sure it looks exactly how you want, and give your one or two lines of feedback afterward. But most of the time, it's working with Devin, having it handle more things in parallel, building more stuff.

A Quarter of PRs by Devin

Lenny: Currently, what's the ratio of PRs submitted by Devin versus humans?

Scott Wu: I'd have to check, but Devin is probably about a quarter of all our PRs.

Lenny: What was it six months ago?

Scott Wu: Compared to six months ago, it's grown exponentially internally. Devin's development is about two things: capability and product interface.

First, its intelligence level has improved a lot.

On the other hand, we've also spent a lot of time figuring out how to build its interface: an interface where you can get value from Devin even when it can only complete 80% or 90% of the task.

Devin is obviously not perfect; it makes mistakes. A lot of it is about how you initially scope out tasks with Devin, then get Devin to do what you want it to do? How do you jump in at the end to review and provide feedback? How do you ensure Devin learns over time? How can you check in as needed and course-correct when necessary?

Lenny: Today about a quarter of your PRs are submitted by Devin. What do you think that ratio will be by the end of this year?

Scott Wu: By the end of this year, we expect it to be over half. And one thing we've observed is that you're able to do more and more work asynchronously, and hand off more and more tasks.

I think the soul of programming, the soul of software engineering — whether in the past or present, whether you were using assembly, Pascal, or even in the punch card era — is basically defining the problem you're facing, and really deeply thinking about what solution you actually want. Thinking about architecture, thinking about details, and precisely mapping out in your mind exactly what you want to build, and what you want your computer to do. This is the greatness of software engineering, and its most interesting part.

However, this work might only take up about 10% of a typical software engineer's time. The other 90%, you're hitting Kubernetes errors, you have to debug, you have to figure out what's wrong, or the system crashed, or you left some port open causing issues, or you need to migrate code, upgrade to a new version — more execution-level work like that.

One way we think about building Devin is to truly let engineers evolve from "bricklayers" to "architects." A lot of the time, it comes down to reaching a point where you can provide high-level direction and precisely specify how you want things done.

I think this still very much needs to be human-driven, with humans doing the full specification, while massively amplifying the scale of what you can do and build in a day, an hour, or any timeframe.

In the future, software engineers will still need to learn to code

Lenny: Looking ahead, say someone wants to enter software engineering and become an engineer. First, do you think people should still learn programming? And second, for engineers today, what skills do you think become more important and what becomes less important? As we're discussing this shift from "bricklayer" to "architect."

Scott Wu: I love this question. On whether people still need to learn programming, my answer is absolutely yes.

When you take computer science courses and learn these fundamentals, sure, you learn some things about how specific languages work. But most of what you learn is actually about the ability to logically decompose problems; second, it's about understanding the computer model and all the decisions and abstractions we've built up over time — what is a database? How should you think about a database? What are garbage collection systems and how do they work? And all these different components.

We've been through these phases in programming before. The future phases, I think, will be faster and at a larger scale, but in many ways similar to where we are now. For example, when you use Python today, there's already a lot that's abstracted away. Someone 50 years ago might have said Python is just "you explain what you want in English and the computer does it for you." That's incredibly powerful, it opens the door. We obviously have more programmers than ever right now because of this.

But as you're building your skills as an engineer, it's incredibly helpful to deeply understand these abstractions and dig into what's underneath. For instance, if people really want to optimize a piece of code for performance, they'll use assembly language. To build good systems and understand these things, you definitely want to understand these abstractions — like, how does networking work? What actually is TCP/IP? Or what happens when this Python code gets interpreted? Or all of these details.

We'll reach a state where even people with no experience can build some really cool products and do really great work just by describing what they need. But at the same time, I think for a very long time, people will still need to be able to think precisely about details, peel back the layers of abstraction, and very precisely define what they want to build and how they want to build it.

Lenny: What skills do you think become increasingly valuable for engineers, where should they focus their energy?

Scott Wu: I think it's architectural skills. Engineering already has the term "architect," and I think it's directionally correct. The routine implementation, writing boilerplate code — AI coding is already making us much faster at that.

The key question is understanding complex systems, working within the broader context of the entire company, thinking about the product you're building or the work you're doing, figuring out what problem are we trying to solve? How should we solve it? What solution do we actually want to build? And what are the key decisions and tradeoffs we're going to make?

The people who can do that well are going to increasingly amplify their impact. So if anything, I think a few years from now, there will be many more programmers and engineers than there are today. And obviously the exact form of what it means to be a programmer is going to change quickly. We'll be able to build so much more.

People often bring up "Jevons paradox," and software is really the canonical example of Jevons paradox. Our human society always finds more and more things to build software for, to write more code for — there's genuinely so much more to do.

Lenny: For those who don't know Jevons paradox, can you briefly explain it?

Scott Wu: Of course. Jevons paradox, simply put, is that when the price of something drops, total spending can actually go up. You can think about this in terms of money, time, or resources. But the direct version is: as programming becomes easier, as programming becomes more efficient, we'll have more programmers.

From a zero-sum perspective, you might say, we're going to get 10x faster at software engineering, which means we'll need 10x fewer software engineers. But what I think actually happens in practice is, we'll actually build more than 10x the amount of code. Because all the work we do is obviously constrained by our ability to actually build, execute, and iterate, we'll have so many great ideas, so many great products. People will build more personalized experiences, and so on. There's going to be so much to do.

As technical capabilities continue to improve

Development work will increasingly shift toward asynchronous workflows

Lenny: You said every engineer has a Devin "team." At your company, how many Devins are most engineers typically working with at once?

Scott Wu: It's an asynchronous process — you can spin up and shut down Devins as needed. Most people on the team are typically working with up to 5 Devins at a time. It's a nice workflow — you have 5 things to do, you have Devin #1 do the first thing, Devin #2 do the second thing, and so on. It took us some time to really adapt to and reach this state where it feels very natural to us.

It really is a different experience where you can hand off most things asynchronously. Your goal for each task is to show up at the parts that actually require your expertise, precisely define the problem you're solving and what you're building, or in some of the more complex parts, guide Devin toward the specific type of change you want to make. Like, I want this category set up this way, we should go modify all the downstream references to it. But basically let Devin do most of the work for you asynchronously.

Lenny: Roughly how many engineers do you have?

Scott Wu: Our engineering team is about 15 people right now.

Lenny: 15? Wow. And each person has roughly five Devins. So Devins outnumber engineers five to one. What I love about this is, it's literally a glimpse into the future. You're so far ahead of everyone else in terms of using AI engineers, so observing how you operate is basically understanding how most companies will eventually operate.

Scott Wu: Yeah, and we've seen this transformation ourselves. At the team level, people don't spend as much time just writing boilerplate code or doing pure feature implementation. People can spend more time focusing on thinking about the truly core questions — like, how do we make Devin better? What's the right Devin interface? What combination of workflows or features actually makes the Devin experience as great as possible? That's how we like to work.

Lenny: So when do you hit the inflection point where Devin is improving so much faster than everyone else? Like, once you have enough Devins doing all these things, you're 10 years, 20 years, 30 years, 100 years ahead.

Scott Wu: Engineers around the world will all be thinking about this, developing in this direction, and gradually adapting to these new technologies. As technical capabilities continue to improve, even in today's steady state, things will increasingly shift toward this asynchronous flow.

One reason is that you're always constrained by real-world limitations. You can think of it this way (though these numbers aren't exact), but the basic logic is: being able to write files, complete functions, or lines of code — that kind of task — is already hugely helpful and the experience is excellent. But so much of building software is almost nothing like that.

For example, when you're fixing a bug, you need to start a local server, click through the product on the frontend to try to reproduce the bug. Once an error appears, you go check Datadog to understand what's happening, try to look for other errors in the logs. You look at what went wrong, make some changes, maybe rerun the whole flow to make sure the modified result is correct. This is largely what it means to be a software engineer. These processes all take real time.

As we increasingly move toward this agentic workflow, in some ways, this is like the real path to achieving 200%, 500%, even 1000% growth through software engineering in the coming years.

One great thing about Devin

Is that it's always enthusiastic

Lenny: Let's show everyone what working with Devin actually looks like.

Scott Wu: Sure, the whole process of working with Devin is obviously asynchronous. So, I thought we could actually watch Devin work, then we could look at some other examples of work Devin has done, or things Devin has done for our team. Then we can asynchronously come back and look at that original Devin we started.

The key thing I want to emphasize is: think about us as software engineers, or engineering teams, product managers, etc., thinking about what we want to build, what we want to hand off. So we've already set up Devin with our own Devin codebase. So, I'll spin up a Devin for it. I'll say:

"Hey @Devin, I'm here with my friend Lenny. Can you modify Devin's web app to showcase Lenny's Newsletter as part of the Devin website? Like, on the actual Devin site."

So we kick off this task. As you can see, Devin immediately gets to work and responds. You can handle this asynchronously, or synchronously. This time, we'll dig in a bit and see what actually happens. But as you can see, Devin is browsing files, looking at a bunch of stuff. So we can follow along here as needed and see what makes sense. You can see Devin has already identified several specific parts. Like the sidebar, which we implemented on the frontend. There are some sections there, and we'll have a new component that links to Lenny's site. That all sounds good. Devin is asking if we have any questions. Same situation — you can let Devin make the call and hand it off, or you can throw in more ideas. Like should the button open in a new tab or within the app? I'd say, "Let's have it open in a new tab."

Lenny: Can you answer these questions at any time? Is it waiting for you?

Scott Wu: You can answer these questions at any time to hand off the task, or take it back.

Lenny: It won't be like, "Oh my god, I just wrote it this way, why didn't you tell me sooner?"

Scott Wu: Exactly. One of the great things about Devin is that Devin is always enthusiastic, always ready to put in the time.

We'll give Devin a moment to work. It'll browse through these files, then create a PR for us, and we'll see how it turns out. But I think it'd be fun to show some examples of Devin in other scenarios too.

One example is something I did with Devin just this morning. I had Devin help me review some background for this podcast. Obviously, I'm a huge fan of this podcast and newsletter. I asked Devin: "Hey Devin, I'm going on a podcast. Can you research everything about Lenny and make a nice website quiz for me so I can make sure I have my facts straight?"

So Devin did this this morning, and I'll roughly show what Devin came up with. Looks like it first went to Wikipedia. Unfortunately, there's no Lenny page on Wikipedia. Lenny, we've got to work on that — Devin is so disrespectful to you. We need a page. Then, it found you on Spotify.

Lenny: So you were watching it research in real time?

Scott Wu: Yes. This was obviously from this morning.

Lenny: This is a replay of what Devin did. This is part of Devin's functionality — you can look back at what it did.

Scott Wu: Yes. Especially when you're building engineering projects or something like that, you can see every step Devin takes. Or if Devin tested code locally, you'd obviously want to be able to go look at what Devin clicked on, what it tested, things like that. It found the newsletter, it's looking at this, about to read through all of this.

Then it says: "Alright, let's start putting the code together. I've researched all this, I'm writing all this, putting the app together." It actually played its own quiz. Let's see, let's see how much I know.

Lenny: What's the name of the podcast?

Scott Wu: Lenny's Podcast.

Lenny: How many subscribers does the podcast have?

Scott Wu: A million.

Lenny: What are the three main topics Lenny focuses on?

Scott Wu: Product, growth, and careers.

Lenny: Very good! That's a good quiz. Besides the podcast, what else does Lenny do?

Scott Wu: I'd say writing, angel investing, and advising.

Lenny: How often does Lenny publish?

Scott Wu: Once a week. We can get through all of these. I obviously took this quiz too, to make sure I was well prepared. But this is just one of the more fun examples.

Lenny: Scott, how many subscribers does my newsletter have?

Scott Wu: Over a million. I'll show one last example, and then maybe we can go back to that original task we started.

Many of Devin's features are designed to integrate seamlessly with existing code workflows. For example, we were exploring the DeepSeek codebase on GitHub, imported it into Devin, and forked it.

I want to show a couple things here. One is that Devin builds its own wiki, presenting a comprehensive deep understanding of the codebase. When Devin indexes a codebase, it builds a representation of it, continuously learns and optimizes — this is one of its core capabilities.

What's interesting is, we found that humans also want to understand the codebase representation, so we launched Devin Wiki. You can browse through sections and see each different thing. Here's FP8 operations, here's SGLang integration, there are diagrams about how different layers are built and composed, deployment operations, and lots of architectural details. You can ask questions based on this.

For example, you could ask: "How does DeepSeek handle multi-token prediction designed for speculative decoding?" Devin will search the entire codebase and give you a well-reasoned answer. We use this all the time, especially when planning tasks and providing initial prompts — it's useful even without a specific task.

Devin Excels at Defined Tasks, Not Open-Ended Questions

Lenny: As I talk to more and more AI companies and applications, I'm learning there's huge variation in how large a codebase they can integrate. This is a big issue for existing companies, startups, and companies with large existing codebases. How should people think about what codebases Devin can plug into?

Scott Wu: Yes. So we want to handle the largest possible codebases. The way we typically think about large codebases as engineers is, when changing or thinking about a specific task, you don't memorize every line of code at once. Instead, you form high-level abstractions, review them, gradually zoom in, and then get clearer details.

Devin works very similarly: it first maps out the high-level architecture of the codebase, understanding its purpose and basic functionality, and then for each component, it can also dig deep and provide more detailed analysis. Like how exactly the FP8 to vFloat16 conversion mechanism is set up, what role each part of the codebase plays, and so on. Similarly, we've designed Devin to be scalable from the ground up.

Lenny: This basically goes back to your point about engineers as architects, and Devin helping you understand the architecture.

Scott Wu: Exactly. We found an interesting use case where users often use Devin to onboard new engineers joining the team. When you first join, you're full of questions about the codebase and setup, and sometimes it's a bit awkward asking your mentor or manager, especially worrying that your questions might sound naive. In that case, just asking Devin, browsing the wiki it generates, and understanding its internal representation is really helpful.

Lenny: That's interesting, going back to your point that Devin isn't just a junior engineer but has "variable intelligence," understanding the codebase like a senior engineer. Normally you'd have to ask engineers who've been there a long time — what does this thing do, where is it, how does it work — and Devin is surprisingly good at this.

Scott Wu: Yes, retrieving and processing large amounts of code and tokens is exactly what language models are good at, and it can help you when you need it.

Devin Wiki is a feature we just launched last week, fully integrated with Linear. If you have a task in the DeepSeek codebase, you just add the Devin tag, and Devin will give you its take on the task. You can look at each specific file or important code snippets it flagged. If you agree with what it's built and concluded, you can spin up a Devin session to actually complete the task.

Lenny: Sounds like a simple idea, but essentially you're saying there are bugs and feature tasks in Linear, and now Devin can just handle them directly for you.

Scott Wu: It's a manual process. When Devin is planning a task or offering ideas, you obviously want to be involved. Devin will also tell you its confidence level, like its likelihood of understanding a certain part, which helps speed things along.

As you said, a lot of product managers like using Devin with Linear to better understand things, codebases, and so on. For example, Claire Vo at Launch Darkly is a heavy Devin user — she likes planning tasks, asking data-related questions, or whether a feature has been merged to production, how many people are using a certain feature, and so on. It's a clean way to get intelligence.

Lenny: I love the Linear integration — it stays simple. You can add a small ticket like linking something to the homepage, and Devin understands precisely and shows you.

Scott Wu: Yes. Looks like Devin finished the work. Seems like there was some CI issue, and it's debugging it now. But it's already submitted the initial first version of the PR, so we can take a look. This is Devin's site, obviously on this custom deployment. And here's Lenny's Newsletter.

Lenny: Ship this to production! That's amazing.

Scott Wu: Devin obviously has access to our own Devin codebase, and it's done a lot of work there, so it's very familiar with all the parts here.

Lenny: Beautiful. Yeah, I love how it looks. It'll bring some nice growth. You link to my site, we juice the PageRank.

Scott Wu: Yeah.

Lenny: What a beautiful website for my newsletter. Is this a good example of the kind of thing Devin is really good at? Like, "here's a very specific modification request for a website."

How should people think about what Devin is good at versus where things might go wrong?

Scott Wu: I think Devin excels at well-defined tasks. You should assign Devin tasks, not problems. Things like quick frontend feature requests, bug fixes, adding tests and documentation.

One factor that makes the loop work really well is the ability to iterate and test quickly. For example, pulling up a preview directly to check if a link works — Devin can do that easily too.

Devin will often log into Devin, start a Devin session, and make sure it works on our own codebase, which is kind of funny. But generally you want something that's easy to verify and easy to test, that's the main thing. You can also tackle bigger projects or bigger requests. But in that case, you should expect to need to guide Devin more to make sure it's heading in the right direction.

Lenny: That's interesting because it's very similar to how people talk about synthetic data and reinforcement learning — creating data where there's a very clear, definitive answer, yes or no.

What was the most debated thing in designing and building Devin?

Scott Wu: A few examples come to mind. One I'd call the "how opinionated should we be" question.

We have our common Devin workflows that integrate with Slack and GitHub, create pull requests for us in our repos, respond to issue reports, and so on. Of course, we also encounter many other situations — lots of people using Devin, creating different use cases. Some people even use Devin to order DoorDash. And many others build cool websites from scratch or do things like that.

This is an interesting tradeoff for us. I'd describe it this way: most features we build in our product are definitely geared toward creating pull requests and use cases for engineering teams. But I think if people want to use Devin for other purposes, we also want to make sure they fully understand the limitations and where they might run into difficulties.

Generative AI is interesting. One of the most common pieces of startup advice I see is: focus on a very narrow segment, do things that don't scale, build one really excellent use case, and expand from there. I think that's good advice in every respect.

But for generative AI, you naturally see a lot of product experiences end up becoming more general-purpose. This is something we're still thinking through. We also want to do things to support other types of use cases, to handle things people might want to do with Devin.

Another question is: to what extent should Devin be a complete, integrated project experience versus more of a composable toolset? We have Devin Search, Devin Wiki, and the Linear ticket scoping feature — these tools interact with each other. But over time, we've increasingly viewed it as a toolset. And I think building the agent with all these capabilities, Devin itself, is the core piece. That will always be the truly special part of what we do.

However, real-world software involves a complex set of tools. There are many different workflows and many different use cases that make sense. For example, you could ask Devin Search and Devin the same question. Devin might just start working, but sometimes users prefer to have more control.

You might be designing a coding task but not want Devin to start on it yet. You just want to ask Devin Search which parts of the codebase might be relevant, or request to see relevant code snippets, or understand existing representations through the wiki. So we've found that these features become natural and meaningful over time, both in terms of functionality and user experience.

---

The Agent Coding Experience Will Iterate Another 20 Times

Lenny: In AI coding, there are multiple different approaches. You've gone all-in on the AI engineer, but there are also IDE companies and companies building great engineering models. Now even OpenAI, Anthropic, Cursor and others are building agents. How do you position yourselves, and what do you see as the key to winning in this space?

Scott Wu: I think all these teams are strong. They're made up of very smart, forward-thinking people building many excellent products. And I think there's still a lot to do in the coming years as AGI gradually materializes.

One of my favorite lines is: in 2017, if you asked whether we had AGI, the answer was no. By 2025, if you ask whether we have AGI, the answer is, you have to define AGI, and it depends on what you're researching.

A core issue this touches on is that there's so much genuinely amazing stuff happening right now, and it's easy to underestimate the magnitude of this transformation.

Over the past 10 to 30 years, there have been many great products that made various niche segments of the product building lifecycle a bit easier.

For example, great instant messaging products, logging products, billing products, all kinds of different tools. All these areas will evolve several times faster — this will be an order-of-magnitude shift.

From our perspective, we've always focused on one area: autonomous coding agents.

There are many problems to solve here. On core capabilities alone, there's still a lot of work. We constantly encounter situations like: "Why did Devin make that decision? No human engineer would do that."

In many ways, like the product interface, there's obviously a lot to think about. This isn't just a single goal we're working toward — it's something that changes with every capability iteration. I estimate the agent coding experience will iterate another 20 times in the future.

We'll reach a stage in a few years where you might not need to look at code at all. You'll just review and specify tasks, saying: "Let's add a new tab here, should save this info. Spin up a database table and index it on columns X, Y, and Z." You'll be able to interact with your product in real-time and have your agent build these features for you.

Between now and then, there will be many generational shifts. But I think the product experience itself changes each time, along with all the practical issues of rolling it out worldwide. So people need to learn how to use new technologies.

At the same time, there's a lot of work to do on deployment and handling all the complexities of real-world software. There's still a lot of "legacy" code in COBOL, Fortran, and so on. People have done all kinds of abstractions and detailed work.

So we've been focused on coding agents from day one. It's the one thing we truly believe in and design for — extending even to our revenue model and usage-based setup, woven into all the product experience.

For example, where do you want to talk to Devin? You want to be able to talk to Devin in Slack. You want to launch it from your issue tracker. And of course, capabilities.

So I don't think there's a simple answer — it's a combination of factors. But this is indeed the area where we've invested all our time for the past year and a half, and will continue to for the next five to ten years.

---

User Stickiness Is the Key "Moat"

Lenny: Along these lines, a general puzzle in AI is moats and defensibility. When building products becomes easy and so much is built on models that are themselves advancing so rapidly, how do you think about building a moat in this space?

Scott Wu: I think this is usually more about user stickiness than moats. Typically when people say moat, they mean something that prevents competitors from entering the market. At the macro level, across many different companies at different layers of the AI stack — foundation model labs, application layer, and so on — I don't think there are any hard barriers that prevent others from entering.

What I think truly exists is stickiness. I'd define it as: once you start using a product experience you genuinely love, are you excited to keep using it?

Or is there an effect where, from now on, it's just as easy to switch to a new product and learn it? From this perspective, I think coding agents have several especially strong aspects.

First, there's a lot of inherent stickiness and accumulated learning over time. Compared to a human engineer: an engineer on day one at a company versus one who's been there five years, wrote half the code themselves, touched every file, built every part, and knows everyone else on the team — their output is incomparable.

Devin also genuinely learns and builds its understanding of a customer's codebase, tech stack, and processes, and can do more over time.

On the other hand, I think what's very exciting is what I call the "multiplayer" aspect of code — there's genuinely a lot to do here. This is how so much gets done in the real world.

Using Devin as an engineer by yourself is one use case. We also commonly see engineers working with Devin and training Devin. People use Devin to help onboard new engineers and teach them things. Or I'll start a session with Devin in Slack and say: "We're building such-and-such product"; then another engineer will chime in: "The reason we originally did it this way was X and Y. Devin, when you make this change, please make sure it still supports that workflow." Devin will say: "Got it." Or Devin will create a PR, and someone else will review that PR or leave some comments, and Devin will handle them accordingly.

Across all kinds of software engineering scenarios, Devin lays the groundwork for an experience where the value it provides to a customer's entire workflow grows over time. We think more about: how do we make Devin increasingly useful the more you use it?

Lenny: Cursor CEO Michael shared a similar view — he sees moats, or user stickiness, the way Google does it: low switching costs, but what matters is being the best. Do you think going further, if you can create even stronger stickiness where users can't leave because the product is so good, because they've accumulated knowledge, and because it's deeply integrated into their workflow — is that the next level?

Scott Wu: I think one nice thing about software engineering is that, for better or worse, there's a very clear value metric. At least for the foreseeable future, there's always a clear next goal.

There may come a point where you can tell Devin, "Build me a complete YouTube," and it actually does it. And the YouTube of today represents hundreds of millions of hours of human engineering time — the algorithms, the infrastructure, every tiny detail.

And maybe one day Devin can do that out of the box, though that's far in the future.

One cool thing about developers is that they're genuinely willing to learn new experiences and put in the effort, if it means they get increasingly high-quality output.

We've passed the inflection point for AI coding

Lenny: Without giving away trade secrets, what has enabled you to make Devin so good? Was there a breakthrough with a specific model? Some people have shared that Claude Sonnet 3.5 and 3.7 were huge breakthroughs for a lot of their products. What are the keys in your architecture or in how you built Devin that make it work so well?

Scott Wu: We started betting on agents very early. I think agents became viable and practical much earlier than most people realized. As the whole community has really rallied around it, you can see its impact in pre-training, you can see it in a lot of the work around these models.

From our perspective, I don't think there was ever a single, step-function foundation model shift or anything else that made a night-and-day difference in Devin's performance.

But new models come out every week now, and that also has a major impact on what we can do. On top of that, we work with research teams at foundation model labs and build on top of their work.

So I want to offer a bold take here: I think in terms of base intelligence, we've basically reached what we need. We're not pre-training models ourselves, not trying to increase the model's base IQ — instead, we're more focused on teaching it all the traits and details of real-world engineering. Like how to use Datadog, how to find bugs in programs, how to handle every situation, how to create GitHub PRs.

There's so much detail and specificity in the work we do every day. It's more about teaching the model to reflect the complexity of the real world, rather than getting it to some higher, fundamental level of problem-solving.

Lenny: You've shared a perspective before about how past disruptive technologies grew — they were very hardware-dependent and had limiting factors in their growth, whereas AI is different.

Scott Wu: For many reasons, I think AI will be the biggest technology transformation of our lifetimes.

But one thing I'd say is that most of the major tech revolutions of the past 50 years — personal computers, the internet, mobile phones — all had a significant hardware component that played an important role in their proliferation.

The internet started as just communication between some universities, but over time the whole world got connected. That took many, many years.

Mobile phones were the same. PCs were the same. What's particularly interesting about this is that we've seen the impact: in all this hardware, so much depends on real-time adoption.

So the people building products for these industries watched their markets grow steadily year after year as mobile subscribers and internet access numbers increased. Many companies grew up from the very beginning of the industry.

Apple and Microsoft were founded almost at the same time. Many great internet companies and others too. It was something that reached the whole world, or a large part of it, over time, and had enormous impact — but it took years to get there.

One major difference I think AI has already shown is its potential for explosive growth.

I think we've firmly passed the inflection point for AI coding — meaning, as an engineer, if you're not using AI at all, you're being left behind. This is a technology that everyone should have and use, and there are no hardware distribution barriers. That means this space is growing exponentially.

Lenny: Michael Pollan has an interesting point — clichés are clichés because they're so true. That's why you think, "I've heard this a million times." I think people hear this and think... but what's actually happening is insane. That's why you're here helping us through this transition.

Scott Wu: It's an interesting time. It's going to take real investment and real work. But from our perspective, as engineers, it means keeping up with everything that's happening is incredibly important. Not just your ability to learn and use these technologies, but also teaching the AI about your codebase so it can actually build effectively with you and do more of what you want it to do.

Treat Devin as your "new coworker"

Lenny: For employees at companies listening to this podcast, they might be thinking, "We should be using Devin at our company." What have you found helps engineers at companies get adoption and be able to use Devin, whether culturally or operationally?

Scott Wu: One pattern we often see is that there are a few people on the team who are really excited to try new things, willing to put in the time and effort, and super excited to get it going. They'll do all the setup, give Devin access to the codebase, teach Devin how to run lint and CI and all these details. They'll start by assigning initial tasks, basically helping Devin establish a foothold.

Over time, eventually people see that Devin is writing all these PRs, doing these things.

Lenny: "That new hire Devin is just cranking out PRs like crazy."

Scott Wu: They see this and naturally want to join and get an account. And the cool thing is, when they join, Devin already has quite a bit of knowledge about the codebase they're working with and is already collaborating with it.

So one really cool thing we often see is that those early adopters can genuinely pave the way for everyone else on the team.

The main point I want to make is that this is a very different product experience. It's worth noting that we still have a lot we can do to make it as intuitive and clear as possible for people to understand how to use Devin, what the right steps are, and how to truly maximize value from Devin.

You need to put in the effort to understand what it takes to make Devin successful. We've found ourselves using Devin more and more over time, with every update.

Lenny: If you could sit next to every new user using Devin for the first time and whisper a few suggestions in their ear to help them use it better, what would you say?

Scott Wu: I think the most important thing is to really treat Devin as your new junior engineer. I think that's the most important thing.

I think people come in, see the blank page, and think of all kinds of things they want to try.

What we typically see work is that you can try demos, you can do things. But a lot of the time it's: we figure out what tasks we want to get done today or this week, and get Devin started on those tasks.

We start with the easier ones, then work with Devin to understand what setup it needs to test its own code and do well, then scale up over time. As you work with your engineer (Devin), you get better at understanding how to communicate with them, or which tasks or projects are good to bring them into — that's really our core philosophy.

Lenny: Let's say every engineer has 5-10 Devins, they become managers of junior engineers. That's not necessarily the best job in the world because it means tons of review work. At least you don't have to do performance reviews and one-on-ones. But it's like sitting around checking tons of PRs all day.

You become the architect, which is kind of what every engineer eventually wants to be. They all think, "I just want to do architecture, I don't want to fix bugs." How do you make life pleasant, fun, enjoyable — basically as an engineering manager who might be managing 500 Devins in the future?

Scott Wu: I think the "bricklayer" versus "architect" framing is closer to the experience than being a manager.

A lot of the difficulty of management, or why people shy away from it, is a lot of context, ownership, accountability — and then all the emotional stuff.

Working with Devin is more like having an interface to hand off and build tasks, finding the right level of abstraction, finding workflows that actually work.

The analogy I'd make is, when we invented Python, in many ways the description and planning of tasks was obviously a different paradigm. But I definitely think this is far from the kind of "management bureaucracy" people usually think of.

With Devin, a lot of the time it's more like: find the right level of abstraction you can collaborate with, find the workflow that works well. You can have Devin try something first, and if it works well, you merge it right away. If it needs some changes, you give feedback. It's more about making Devin part of your process rather than losing control, which I think is what people fear most about management.

Lenny: Have you considered launching a manager Devin to manage other Devins?

Scott Wu: We've thought about it. Devin can spin up other Devins through the API, and we've already seen this use case.

If you have some large tasks you want to tackle, Devin will break them into chunks, and you need to give them the appropriate permissions to do that. This isn't enabled by default right now, but over time, you'll see more and more of this.

For humans, to use a technical term, there's a coupling between context and thread. What I mean is, each person can only operate single-threaded on the work they're doing, and they have their own set of context. Other people can be doing other things simultaneously, but they have their own context.

But for agents, you can have one agent pursuing multiple lines of exploration simultaneously, and they can share all the context. This is still in a very early stage, but we'll see this in the future. Once we reach that stage, there will be many new paradigms waiting for us to build.

Lenny: That decision you just mentioned is interesting — whether to have one Devin, and only one Devin, doing everything and delegating tasks; or whether you have five Devins, each doing independent things. That's a very interesting decision.

Scott Wu: Yes, absolutely.

Startups: There Are Always Three to Five Things

You Have to Take Further Than You'd Think

Lenny: So far, in the process of building Devin, what's the most counterintuitive thing you've learned? Something that goes against conventional startup wisdom.

Scott Wu: I've been thinking about this a lot recently as we've built Devin. This isn't actually my first company. For many of us, this isn't our first company. Our team has about 26 or 27 people total, and roughly 18 of them had founded their own companies before this.

One thing that comes to mind is that there are certain very common clichés you hear in startups — that you have to move fast, or that you have to hire great people. There's always that same set of three to five things that get repeated over and over. They're the conventional wisdom of startups.

When I first started out, as a founder, I definitely had that mindset. But when you really get deep into it, after many years, you learn thousands of other things you need to learn. On all these different fronts, you encounter many small details — team building, product, strategy, engineering decisions, fundraising, sales, and all the other components.

Over time, I've increasingly felt that to build a great company, sometimes it's simply about taking those three to five things even further than you imagined.

Everyone says we moved fast, but the reality is, we held a hackathon in November 2023, another one in December, formally incorporated in January 2024, had a prototype in users' hands by February, launched the product in March, and had our first customers in April.

We truly accelerated at every single point, and that really made a huge difference for us.

Yes, everyone always says you should hire great people, and I think the truth behind that is you should do whatever it takes to get the people you actually want to bring in.

One of my favorite stories to share: we had a candidate come in for an interview. He was a junior at MIT, very young. We put him through the interview process, and he performed dramatically better than almost every full-time candidate we'd ever interviewed.

So we said: "What do you think about taking some time off from school and coming to work with us to build Devin? We think you could make a massive impact from day one."

He thought about it for a while and came back and said: "I'd love to, I'd want to do this, but my parents want me to graduate from school. I'm not sure how this could work." So we talked more and understood the situation.

Then we flew to North Carolina, went straight from the airport to his parents' house, had dinner with them and his parents, talked a lot, tried to understand what they needed. They said: "This sounds like a great opportunity, but we want our son to graduate." We discussed this carefully and came up with a plan: he could work for us full-time while still taking the courses he needed to take and doing what he needed to do to get his diploma. We discussed this, reached an agreement that worked for everyone. We went straight back to the airport — that was my first and only time in North Carolina.

It's one thing to hire great people, but truly never giving up and doing whatever you can to create the conditions for people who are genuinely right for the team — that's what matters.

He's been on our team for over a year now, an absolutely incredible engineer, and we wouldn't be where we are without him.

Similarly, we had another person, also an extremely talented candidate, very young, with great offers from many other companies, who wanted to start his own company someday. We talked to him about a lot of obvious things — like having him meet our investors, or exposing him to customers, or seeing many other aspects so that when the time came, he'd have all the experience he needed to start his own company.

But another important thing was, he was already in conversations with a lot of great companies, and he didn't want to burn any bridges. So we basically sat down with him and hand-wrote his rejection letter responses to all the other companies, worked through the wording with him — like, "How should you express that you genuinely appreciate the time they spent, while also making clear that you obviously want to stay closely connected." Our job was to make sure he was happy enough that he wouldn't want to leave anytime soon.

The way you build a truly great team is by genuinely fighting for what's right for them.

Lenny: These stories are incredible. They make "hire the best people" so real. This is what hiring the best people sounds like. This is what it takes.

Scott Wu: We work very hard to reimagine things from first principles, thinking about where technology is headed in 5 to 10 years? And what role do we want to play in that future?

Lenny: I'm wondering if one day people will be fighting over Devin.

Going back to your three to five things — that's fantastic advice. You always hear hire the best people, move fast, build what people want.

Scott Wu: Yes, build what people want, be as close to your customers as possible.

I think another thing is, always think about where things are headed, not where they are today — especially in AI, where things are moving so fast, with so many talented people. So it's not just thinking about what things will look like in 10 years, but thinking about what will happen next week. Things are moving so fast, it's hard to predict. You really have to be very rigorous with yourself in thinking about those things, and evaluating every decision you make through that lens.

Lenny: The emphasis here is on staying focused. It feels like there are 1,000 things you should be doing, but it's always these five things.

In AI, Everyone Can Multiply Their Own Capabilities

Lenny: Is there anything else you want to share? Anything you want to leave with listeners?

Scott Wu: There are many different views on AI. I think basically every possible emotion is covered. There's a lot of fear, and a lot of skepticism. We're also very skeptical people ourselves — always wanting to try things ourselves before we can truly see and believe it.

For me, the main thing is that I'm incredibly optimistic about products built with AI — not just code and Devin, but the entire field and everything that's being accomplished. Everyone can multiply their own capabilities.

That's how we've always thought about it, how we think about what we're building. And, I think there's still so much to do in the world. I'm not too worried about us running out of things to do. From that perspective, what we've always been most excited about is how all of us can do more.

Lenny: With that optimism, we come to the very exciting lightning round.

First question: What are two or three books you find yourself recommending most often?

Scott Wu: On the non-fiction side, for entrepreneurs, one thing I love is learning and understanding the history of Silicon Valley. All these things we think about — someone invented them. Like someone invented the concept of a seed round, someone invented the concept of venture capital, someone invented the concept of PMF. All these different principles we talk about.

For that, there's a book called The Power Law by Sebastian Mallaby, which I love. It's basically a tour of many of the great businesses and great products built over the past six or seven decades in Silicon Valley.

On the fiction side, I've personally always loved F. Scott Fitzgerald's The Great Gatsby — one of my personal favorite novels.

Lenny: Have you had any favorite movies or TV shows recently?

Scott Wu: I have to admit, I can't think of any movie or TV show I've watched recently. I'm looking forward to watching many great works after AGI.

Lenny: That has to go in the trailer. That's amazing. I love that. That also shows how hard you're working, how much is going on, how fast everything is moving.

Have you discovered any product you really love recently? Could be an app, could be a physical thing, could be a toothbrush.

Scott Wu: One I'd mention — I recently bought an Aura frame. It's basically a photo frame that displays photos, and you can show a new photo every day, every hour, or every 15 minutes, whatever you like. I've actually really enjoyed it. I think it's a really nice way to — basically a frame that shows memories through photos.

And then another thing as a general item — it's not particularly new, but I want to say that I think AirPods are actually really well made, really well designed. I've now realized that I basically use them in every situation. I take calls on AirPods while walking, I obviously wear AirPods while working at my computer. They work quite well in many different situations. They're very comfortable, very stable.

Lenny: Yes, I want to double down on the Aura frame. I got one for my mom and my mother-in-law too, and they're just really great for sharing photos of your kid with family. People may have heard of digital photo frames, but Aura just does it really well, it's super easy to add photos, and they look really nice.

Scott Wu: You can imagine, not too far from now, we'll have the Aura frame, except it turns all your photos into Studio Ghibli style. Or just imagine some cool thing you've done.

Lenny: Cool. I believe it's spelled A-U-R-A, if folks want to check it out. We'll link it, not sponsored. Okay, two more questions.

Do you have a favorite life motto that you come back to often and find useful in work or life?

Scott Wu: Yeah, one thing I think about a lot is that a lot of sayings actually contradict each other? Like, "birds of a feather flock together," and then you also have "opposites attract." You feel like they're both right, and they're usually both right. A lot of the time it's about understanding why.

One that I feel like, especially in the startup world, I almost think about constantly is that I think focus and drive are really important, really maximizing your potential. At the same time, it's really important not to tie your personal emotions to success or failure.

Especially for startups, because there's always ups and downs, and honestly, even the most successful companies too. It's a bumpy road, lots of things happen, lots of experiences. One thing I think about a lot is that you really want to try your best, give it your all, and do everything you can. Basically, you want to leave it all out on the field. But at the same time, you want to be able to accept both victory and defeat. You want to be able to move on and get to the next thing each time.

For your own emotional state and mental state, being able to do that is really important. We've made lots of mistakes, my first company was obviously cool but there were lots of hairy things there. And then in the Cognition journey, it feels like eight years have been compressed into one, and still moving at that speed. But somehow it actually makes you more successful too.

If you don't tie it to your personal worth, you're actually more able to give your all and do the things that lead to success.

Lenny: That's so interesting. I actually just recorded a podcast with an executive coach, Jerry Colonna, and that was one of his big pieces of advice. It's this very Zen approach of non-attachment to outcomes.

Scott Wu: Yeah.

Lenny: Okay, last question. Is there a story behind the name Devin? Or were there other names that were candidates for this agent?

Scott Wu: Devin was actually decided pretty early on. We were interested in coding agents from the very beginning. For example, my co-founders are Steven and Walden, and we had this idea.

When we first started the company, we tried to expand the scope as much as possible, let everyone think outside the box, let everyone do their own thing for a while first, and then we'd integrate and take everything we'd learned.

Walden made a version of his virtual developer, called Dev Walden, and then Steven did his version, called Dev Steven. We integrated all of these together, and it was Devin.

Devin was decided pretty early. I would say, we did have one major decision, which was what should Devin's image be. As people know, there's that hexagon logo. There's actually also an otter, a little otter with a laptop on its lap, that was also Devin. We debated what to use and what not to use. It's been a while now, but somehow we still have both the hexagon and the otter.

Lenny: You skipped over the origin of Devin.

Scott Wu: Devin, it's a dev, kind of like when we integrated all the names, it was clear this would be the universal dev that we'd all want to work with.

Lenny: Scott, this has been so fun, I've learned so much. Last two questions, where can people find you or Devin? And anything else you want to tell them? How can listeners help you?

Scott Wu: Our website is app.devin.ai. You can also find us on Twitter or lots of other social media. We'd love to hear any feedback you have on the Devin product. There's a lot to figure out.

Like I said, we're all still 20 steps away from the future of software engineering. So hearing what people think as they try the product means a lot to us. So if there's anything we can do better, please let us know anytime.

Lenny: Scott, thank you so much for being here.

Scott Wu: Thank you so much for having me, I had a great time.