28 years old, 6 months, creating the world's first AI programmer, and an AI unicorn valued at 2 billion

In the field of AI coding, Cognition can definitely be considered a "legend." In March 2024, it announced the launch of its first AI programmer, Devin, which garnered over 30 million views in total, attracting widespread attention online; in December, Devin went live with a subscription price of $500 per month, possibly the most expensive subscription price for an AI product currently. Cognition was established only 6 months ago, and top Silicon Valley investment firms Founders Fund and Khosla Ventures invested $176 million in Cognition AI, pushing its valuation to over $2 billion, making it another AI unicorn. The founder and CEO, Scott Wu, is of Chinese descent and won the IOI (International Olympiad in Informatics) gold medal for three consecutive years from 2012 to 2014. Cognition has many major clients, including Ramp, an expense management company with an annual revenue of $300 million, which uses Devin to write test code and clean up dead code; another client is MongoDB, a data platform with an annual revenue of $1.7 billion, whose Chief Product Officer, Sahir Azam, stated that the company used Devin to update outdated code architecture, saving clients millions of dollars. The biggest difference between Devin and mainstream AI code completion tools is that it can theoretically write code on its own without human involvement and complete entire projects typically assigned to human developers. Moreover, users can run multiple Devin Agents in parallel to complete different coding projects. Recently, 28-year-old Scott Wu participated in a lengthy interview with the renowned tech podcast Colossus. He discussed with host Patrick the process of building Devin, how Devin can increase software engineers' productivity tenfold, and the future trend of AI programming in the entire software engineering industry. Some interesting points . We have always adopted an agentic approach, and I believe the biggest leap is in the distinction between asynchronous and synchronous. Many code assistants use language models for code auto-completion, which saves engineers some time and overall improves engineering efficiency by 10% to 20%. But Devin can take on the entire coding task, and its improvement is tenfold, not 10%. Users can delegate tasks to Devin and continue with their own work; they can run other Devins simultaneously to complete different tasks. . We care about building capabilities and product experiences centered around software. I have no doubt that the intelligence of AI foundational models will continue to improve. However, the details of all the tools we use, how decisions are made within these tools, and even how to communicate with users, where the user interface is, how to interact with Devin, provide feedback, check Devin's progress, and ensure there are no issues—there are many details in these processes that truly reflect what is called intelligence . My point is that problems should not be solved in a vacuum; we need to consider how to translate the intelligence of AI into meaningful assistance for software engineers and their daily work. Therefore, a lot of work is needed to adapt to the capabilities of specific tools and specific technology stacks, and significant work is also required on the product side. . I believe that the main use case for GPUs and AI foundational models will be agents, as the number of AI foundational model calls required for each agent query far exceeds that of a single Q&A query. What will happen next is that these AI foundational model companies will think about how to build their models to optimize agent usage. . We have a unit called ACU—Agent Computing Unit. It basically encompasses all the decisions Devin makes, the frameworks used, the code run, etc. It roughly corresponds to users paying about $8 to $12 for every hour Devin works. Devin can accomplish a lot in an hour, and our pricing model is designed to make it ten times cheaper than if users were to complete these tasks themselves. When we start having AI that executes tasks rather than just answering questions, this will become the new paradigm. . No matter how solid your entrepreneurial foundation is, there is always another level to elevate. For example, moving forward as quickly as possible; in our case, we established the company in January, began building the initial version of the product; launched the product to the first batch of initial users in February; released it in March; completed a large-scale financing round in April, and reached a significant partnership with Microsoft in May. . The difference between autonomous driving and AI coding is that autonomous driving indeed needs to achieve 99.9999% reliability. In terms of software engineering, Devin is not a 99.9999% solution; it is more like Waymo in 2014. But the key is to let Devin handle the first processing or let Devin send code for you to review. If Devin does 90% of the work and you do 10%, that is still very useful. The efficiency improvement of Devin is 10 times, not 10% Colossus: Scott, could you first describe the company's business? Scott Wu: We were established about a year ago (in 2023), focusing on building AI that automates software engineering. The product we are developing is called Devin, which is the first fully autonomous AI software engineer. Devin is essentially capable of completing all parts of the software process, so the way users collaborate with Devin is the same as how they would work with human colleagues. Devin can be used in Slack and GitHub, utilizing all of the user's tools and working in their local development environment. Devin not only writes code but also handles all related parts, including running the local environment, reproducing bugs, checking logs, identifying issues, testing bugs, adding some unit tests, and then submitting pull requests to the user for review Colossus: If Devin is viewed as a human engineer, can its capabilities be measured by salary or years of experience? Scott Wu: At the beginning, it was equivalent to a high school computer science student or an intern. Now, it’s more like a junior engineer. If a user says, "I need you to restructure the entire codebase, rewrite everything to improve efficiency tenfold, and I will check it in a week," that may not be the correct way to use Devin. It largely transforms every engineer into an engineering manager, allowing users to delegate tasks to Devin, such as, "Devin, take a look at this and do a preliminary processing first." The output from Devin may require the user to fix some issues that arise, or Devin may pose questions that need user responses. But the overall idea is that users can asynchronously collaborate with their Devin team while handling their own tasks or working independently. Colossus: One cool aspect of general models is how hard it is to predict how the world will use them to build other things. Now that Devin is fully open, what surprises you most about how people are using it? Scott Wu: Many emerging use cases are ones we couldn't predict ourselves. The companies we collaborate with initially use Devin for migration, system refactoring, and version upgrades. For example, we work with banks and healthcare companies, where much of the clients' code is actually decades old. They want to use the latest tech stack to make it faster, more efficient, and more secure, while also making it easier for developers to work on. But if your codebase has 30,000 files, modernizing that code can be very cumbersome and labor-intensive. This is one of the main reasons we see clients using Devin; many clients have conducted internal studies and found that Devin has increased engineering team efficiency by 8-12 times. This means users only need to ask questions and review code without having to write it themselves. In these usage patterns, Devin can complete many routine tasks in one go. Colossus: What are the key differences between Cursor and tools like Devin? Scott Wu: Since our inception, we have been adopting an agentic approach, and I think the biggest leap is the distinction between asynchronous and synchronous. Many AI code assistant tools use language models for code auto-completion or to write certain files or functions. If they write correctly, users just need to press the Tab key to confirm or accept the suggestion, saving them input time. These technologies overall improve engineering efficiency by 10% to 20%. But what Devin can take on is at the task level; its improvement is tenfold, not just 10%. Because users can hand over entire tasks to Devin and then continue to handle their own matters Devin can test its own code, run it in real-time, consult documentation, and even access websites independently. It can also communicate within the technologies used by the user's team, such as GitHub, Slack, or Linear. Users can run multiple Devins simultaneously to complete different tasks and only need to conduct code reviews afterward. This creates many meaningful differences in product experience. Frankly, our clients believe that Devin complements code auto-completion tools, and many clients use both simultaneously. Colossus: Since you are building an "AI Agent" system, please tell us what "agent" means and why it is such an important construct in the upcoming technological era. Scott Wu: GPT emerged two years ago, which was a huge surprise for everyone. For a while, all products based on it were essentially text completion products. This makes sense because the native form of language models is to input text and output text. The first large-scale code product, GitHub Copilot, is a text auto-completion tool where users input their files and context, and it predicts the next line. If correct, the user just needs to press the Tab key, saving the time of typing that line. However, it does not save the user's time in thinking about that line of code, as it is still the user who decides what is correct and what is not. An agent is a new paradigm where models can act and make decisions in the real world. In many ways, it mimics human behavior, where humans interact with the real world, browse websites, try different approaches, and see what works and what doesn't. Agents run code, check outputs, or view logs, etc. In software coding, having text auto-completion for code indeed gives users higher efficiency, but an agent is like having a full engineer collaborating with the user, which is its purpose. Do not solve problems in a vacuum; consider how AI can truly help engineers. Colossus: Investors will ask every founder, after the emergence of OpenAI o1, how you avoid being replaced. So please tell us how Devin is built and how you consider working in synergy with these evolving AI foundational models during the building process. Scott Wu: We are 100% focused on solving all problems in the software engineering process. In fact, software engineering itself is very chaotic. My point is that problems should not be solved in a vacuum; we need to consider how to translate AI's intelligence into meaningful help for software engineers and their daily work. Therefore, a lot of work is needed to adapt to the capabilities of specific tools and specific tech stacks, and a lot of work is also required on the product side. A simple example is that Devin must integrate into all of the user's tools; Devin must work within the user's GitHub, must work in the codebase, must use Confluence documentation or other places where information is stored, and must read bug reports on Jira In addition, Devin needs to learn the codebase over time. Even very smart software engineers may not be as efficient on their first day at the company as those who have been there for five years and know the entire codebase inside out. Devin needs to understand in the same way, such as "What is the purpose of this file, what are these functions for, and if I want to perform a pattern migration, what should I do in steps 1, 2, and 3," etc. There is also the entire practical step-by-step decision-making process, which is clearly different from text/code completion. When fixing a bug, a very natural process is: first, I would try to reproduce the bug myself; I need to run all the code locally and try to trigger the bug. If the bug does occur, I would check the logs to see what the error is and what the variables are. Then, I would read the relevant documentation, run some tests, and test again to see if it works. If everything is fine, I would add a unit test to ensure it doesn't fail again. I think another question you are asking is what an AI entrepreneur thinks about these continuously improving AI models. This is a very interesting question because many technological advancements are more leapfrogging. When smartphones were first introduced, the first question was, what would you do when everyone has a smartphone in their pocket? To some extent, this is the core of companies like Uber, Airbnb, DoorDash, etc. You can think of it as a shift in technology that makes us consider what will happen in the coming years with this shift. AI is more of an incremental thing. From GPT-3, 3.5 to 4, every little technology improves over time. This means we really need to consider what the model itself will not do over time. What we care about is the capabilities and product experiences built around software. I have no doubt that the intelligence of AI foundational models will continue to improve, but the details of all the tools we use, how decisions are made within these tools, even how we communicate with users, where the user interface is, how to converse with Devin, provide feedback, check Devin's progress, and ensure there are no issues—there are many details in these processes that truly embody what is called intelligence. We have always thought in this way: how to ensure that everything we do complements the improvement of the model and also complements all other parts, as part of a technology stack specifically designed for software services, and how to do it as well as possible. Colossus: When did you find that Devin is truly useful for software engineers? Scott Wu: I think the way Devin works is that it has many iterative processes that are very natural. For example, if it's not just about writing a demo, but rather "I need you to work in my codebase, build a new feature, and integrate it with all existing content and test to ensure it works." Then obviously all these iterative steps are things that Devin does for you Helping people discover problems and debug software like an AI version of Stack Overflow was actually Devin's first Aha moment. Stack Overflow is a Q&A community for programmers and developers, aimed at helping users solve programming and technology-related issues. It is one of the most popular programming Q&A platforms in the world, with a large user base and rich content resources. When we set up the MongoDB database for our work, since everyone has slightly different approaches, there are always some small details that can trip you up. We spent some time trying to set up MongoDB, but it just wasn't working well. So we handed it over to Devin and said, "Can you help me get it running locally?" Anyone who has done this knows that the process basically gives you a set of commands to try, but they don't work. Then you read the errors, copy and paste, try to figure out what happened, Google it, find a solution, run it, and then encounter another error. You repeat this 10 times until things work properly. Then Devin did it. It doesn't just give you an answer like Stack Overflow. After seeing the error, Devin would say, "Let me see what happened, let's check which ports are open, let me look at the database schema, let me see if the socket connection is set up." It runs all those commands to check that information and then decides, "Okay, what should I try next?" Then it tries that, and if it encounters a new error, it can debug. The integrated autonomous process, I think that's the biggest difference. Colossus: How do you use Devin in the process of building Devin? Scott Wu: We use Devin extensively while building Devin; it provides a very asynchronous new workflow. For example, all our communication happens in Slack, and we have several Slack channels: the crashes channel, which reports whenever there is a production environment crash; the front end channel, where we discuss any front-end feature requests; and the bugs channel, where users submit bug reports. In all channels, whenever there is a new report, we let Devin handle it. Devin is not perfect; it's just a junior engineer and usually needs guidance. About 50% of the time, Devin outputs usable code that can be merged directly; the other 50% of the time, you need to decide whether to continue guiding Devin or make some modifications yourself, or even start from scratch. We also have two other scenarios for using Devin. First, since you need to report bugs anyway, you might as well bring Devin in at the end of the workflow, so you can quickly get a test result Another example, as an engineer, you might see a lot of small issues while reviewing code, such as, "This code is too messy. This thing is technically correct, but it's not the most stable practice." These small issues can distract you and affect your focus. You can launch Devin from the IDE and say for each issue, "Can you quickly refactor this?"; or "Can you make this type-safe?" Then Devin will help you fix it, processing asynchronously while you continue with the project. Colossus: If part of Devin's secret lies in the iterative and autonomous nature of the entire process, what is the most challenging part of building this capability? Scott Wu: The model's capability itself is obviously the most apparent. If you consider now, "I am going through a step-by-step process to make decisions to maximize my chances of solving the problem after 100 steps," then clearly this is a completely different problem-solving goal. But I think it's not just that; the infrastructure and overall experience are also very complex. For example, Devin has its own running machines, and you want to support many features, such as rolling back machine states, quickly processing loads, being able to immediately start a new Devin instance, navigating all previous decisions, switching back and forth between these different contents, or being able to process different Devins in parallel, etc. I think this boils down to the chaotic part of software engineering, which is indeed very different from solving problems in a vacuum. Devin needs to utilize all integrations, be able to maintain the user's machine state, or work within the user's Git checkout. Colossus: In what areas do you hope foundational model companies will improve to make Devin more effective in the future than it is now? Scott Wu: Foundational model companies are very excited about agents, and that makes sense. For example, when you ask GPT a question and get an answer, that's a single model query, and of course, consumer pricing is the same. But if calculated by API pricing, that cost is one-millionth of a dollar. However, if you ask Devin, "I have a new feature that I need you to build, can you build and test it to ensure it works properly?" Devin might make hundreds or even thousands of decisions in the next half hour, which means it requires more GPU inference time. Therefore, in the coming period, even in the next year, I believe agents will become more prevalent. I think the main use case for GPUs and AI foundational models afterward will be agents, as the amount of AI foundational model calls required for each agent query far exceeds that of a single Q&A query. What will happen next is that these AI foundational model companies will think about how to build their models to optimize agent usage. I believe that technologies that handle multi-turn tracking and can manage long context outputs will be very helpful. Context is a big issue that people spend a lot of time thinking about. For agents, for example, if it has a half-hour decision-making process, clearly understanding what happened in the past half hour would be very beneficial The core of entrepreneurship is the team coming together to do something meaningful. Colossus: What was the most difficult or stressful moment during the past year of founding Cognition? Scott Wu: My favorite part is the product launch. You know how it is with startups; things are always very close to the deadline. Recently, we had a launch event, and we also had an initial product launch in March. The days leading up to these two launches were the most stressful, but they were also the most memorable experiences. The March launch was very important. Obviously, the product itself needed to be tested with early users to ensure everything worked as expected. Then there were all the other things like shooting videos, thinking about blog posts, curating content, releasing information, and collaborating with customers to get testimonials. During the March launch, we were also in the process of fundraising. We had to deal with meaningful candidates within our sight and do various tasks. For that launch, there was an article about our company written by Ashlee Vance for Bloomberg. It was originally scheduled to be published at 6 AM on Tuesday, but we requested them to delay it a bit to 9 AM on Tuesday—we needed those extra hours. That night at 1 or 2 AM, we still hadn't finished shooting the launch video, and we had to be prepared to handle 10 times or more user load. These were all things we had to do to prepare for the launch. It was a crazy weekend, with everyone coming together to really get everything done. This is also one of the reasons why it was great that we all lived in the same house and worked together. Because the shared experience has a special significance. I feel like if we were in the office, it wouldn't have the same feeling. Colossus: I'm particularly interested in product launches. I think they contain many business elements. Can you reflect on what the best and worst parts of these two launches were? Scott Wu: To be honest, the team's experience was the best part. Being able to build and accomplish these things together is truly the soul of a startup. As for the worst part, the night before the launch, we did user load testing, but Devin crashed at that time, and all the information collapsed; we couldn't handle the load at all. We originally expected to handle a very high number of concurrent Devin sessions per minute, but it just didn't work. Fortunately, it was resolved later; sometimes you just have to push it out and do your best. Colossus: I’m curious about how you transitioned from an IOI gold medalist to a successful entrepreneur. What was the process like when you were building Lunch Club (Scott Wu's previous startup), and what insights did this business journey provide you? Scott Wu: Lunch Club was my first company, and I dropped out of school to start it. First of all, it was an AI platform built for professional networking. We facilitated millions of meetings, and it was really fun for both team and product building I think the entrepreneurial wisdom that everyone often talks about has almost become obvious truths, to the point where people easily overlook their importance. For example, moving forward as quickly as possible, never compromising on hiring, staying close to customers, and focusing on building products that users love and need. But the fact is, no matter how solid your entrepreneurial foundation is, there is always room for improvement. For instance, moving forward as quickly as possible, in our case, we established the company in January and began building the initial version of the product; in February, we launched the product to the first batch of initial users; in March, we had a release; in April, we completed a round of large-scale financing, and in May, we reached a significant partnership with Microsoft. At the same time, we gained many enterprise clients, and the team continued to grow. No matter how fast you move, it is still worthwhile to try to push for a faster pace. No matter how close your contact with customers is or how deeply you understand their issues, you may never regret spending more time with them to gain deeper insights. Additionally, no matter how high your standards are in hiring, you may never regret pursuing higher-caliber talent. I think this is the most important lesson I learned during my entrepreneurial journey. Colossus: What lessons has Lunch Club brought you in entrepreneurship? What is the biggest takeaway, and how can these experiences be applied to Cognition? Scott Wu: One of the biggest lessons is that sometimes solving a bigger problem is easier than solving a smaller one. People often say that if you pursue something truly large and exciting, you will be able to gather a group of team members who are very excited, passionate, and committed to pushing the frontier, which can sometimes make things easier. For example, our team now has about 20 people, 14 of whom were once founders. We have all started companies before, and it is a very, very talented team. Many of them could easily secure a blank check if they wanted to raise funds and do their own thing. But many times, we just want to come together and build something truly great. Colossus: When communicating with investors, what are the questions people don’t ask you about the product, company, or vision that they should? Scott Wu: That’s a good question. I think one obvious difference is that people sometimes only talk about or inquire about experiences related to the team. For example, launching the product, seeing feedback from people, and engaging with users. I think how we as a team build Cognition is truly special. We have some of the smartest, most ambitious, and capable people, but they are all so low-key. I think for me, the real core is that 20 people live in one house, trying to do something meaningful. I think talking about it is completely different from actually seeing it with your own eyes. So one thing we often do is invite people to come to the house to see what it’s like. It might be 1 or 2 AM, and people are still working and creating, with lots of discussions and things moving quickly. This is probably what I am most grateful for in the process of building the company Pricing models will shift from usage-based to performance-based Colossus: How do you think about and formulate pricing strategies? Scott Wu: For AI Agents, good or bad, it ultimately comes down to usage. There are reasons behind the input and output. For inputs, the running costs are indeed higher. You need to handle more queries and tasks, and the GPU computation required for each task or job is also greater. But I think in terms of output, it’s equally obvious that when you start taking on tasks, there will be real end-to-end tasks. Measuring the specific impact of this is much cleaner and clearer. We basically price based on value; we want to reduce costs for users by 10 times when they are building projects, fixing bugs, or optimizing features, so we want Devin's running costs to also decrease by 10 times. We have a unit called ACU—Agent Computing Unit. It basically encompasses all the decisions Devin makes, the frameworks used, the code run, etc. Roughly equivalent to Devin working for one hour, users pay about $8 to $12. Devin can accomplish a lot in one hour, and we set this pricing model to ensure it is 10 times cheaper than users doing these tasks themselves. When we start having AI that executes tasks rather than just answering questions, this will become the new paradigm. Colossus: I'm curious about your thoughts on whether we have achieved Artificial General Intelligence (AGI). Scott Wu: I think, in a sense, we already have AGI. In October 2017, if you asked us if we had AGI, the answer would have been no. And in 2024, if you ask whether we have AGI, the answer depends on how you define AGI. I think the definition of AGI is cyclical; some might say AGI can accomplish 80% of human labor. But if AI can really do 80% of the work, humans might focus on that remaining 20%, making the 80% claim invalid again. But from a practical perspective, I think there will be a process where we continuously push the development of capabilities, and for a while, there will be many "small things" that need to be solved, where humans still perform better in certain aspects. Then AI solves those problems, and people will say humans are still better in another area. Clearly, as humans, we take a lot of pride in wanting to find what makes us unique. From a practical standpoint, what’s more important is whether AI is good enough, whether it is integrated into products, and whether it is distributed widely enough to truly impact the world, the economy, and people's daily lives. The more important question is whether humans have actually improved their efficiency by 25 times because of AI technology. Currently, AI is shockingly excellent at solving mathematical problems and can be among the top ranks of humans. The distinction lies more in whether this level of intelligence is being used by everyone globally and in a way that truly brings them significant value Is it actually driving us to achieve a massive transformation in GDP growth, efficiency improvement, and quality of life enhancement? Colossus: Investors are mostly obsessed with Scaling Laws because they have a huge impact on AI companies. If you are paying attention to the dynamics in the foundational model space, what are you spending time thinking about and focusing on? Scott Wu: I think Scaling Laws are somewhat of a myth. We are indeed making continuous progress on these models, driving improvements in capabilities; and we have also discovered many new technologies, with post-training efficiency being higher, along with techniques like reinforcement learning. Of course, Scaling Laws do exist, but I believe that much of the progress we see is fundamentally due to the introduction of new technologies that make these technologies more efficient or allow them to scale beyond previous levels. Therefore, people sometimes describe Scaling Laws as if, with enough hardware, models will just keep getting better and stronger. I believe that reaching the current level of models is, on one hand, due to Scaling Laws, but also driven by innovation. From the perspective of AI foundational models, we always want to closely monitor the latest developments and what’s coming next. We work closely with all foundational model companies to evaluate early models and conduct customized model training. We see this as an incremental process, and as decision-makers, it’s crucial to understand which capabilities will be enhanced and which capabilities, products, or human experiences need to complement these capabilities to provide valuable offerings to your customers. In the future, AI will take on 90% of the work, while humans focus on the 10% creative part. Colossus: Regarding the competitive environment, do you see it as a hopeful greenfield, or more like a battlefield where every available opportunity is fiercely contested, filled with intense competition and sharp rivalry? Scott Wu: I believe it is still a very promising greenfield; the technology itself is still in a very early stage. Its actual value may take a year or two to truly manifest. One point I often think about is that the software space is just so vast, with many aspects and details, and AI can accomplish many completely different things. One way I think about it is that for every use case we discuss, there are huge, very meaningful businesses that can be built around that use case. For example, in AI for data observability, there’s Datadog, which has annual revenues in the billions and is growing rapidly. There are also many excellent companies in the incident response space, like PagerDuty. But AI will expand these areas by several orders of magnitude again. Testing, code modernization, and customer migration are similar. Even today, large companies like Microsoft, Amazon, and Google face enormous efforts to migrate customers to their platforms, costing billions or even tens of billions of dollars each year. These areas are so vast, and many questions about product form factors still exist With the continuous advancement of technology, the types of use cases we can support will only become larger. Colossus: What do you think are the overestimated and underestimated aspects of your field in the world today? Especially in terms of automation in software engineering. Scott Wu: The speed of development may be an overestimated aspect. If we look at the overall development of artificial intelligence, AI agents will truly play a role in various fields. Code is one of them, but I can almost say that the first AI agent was actually self-driving cars. This is a true form of artificial intelligence that makes decisions in the real world, receives feedback, and iterates. When I lived in Mountain View in 2014, I often saw Waymo cars driving on the streets, and I believed I would be able to use them. We will eventually reach that stage (Level 5 autonomous driving). Of course, there is still a lot of room for growth, and it will indeed take a lot of time. The difference between self-driving and AI coding is that self-driving really needs to achieve 99.9999% reliability. In software engineering, Devin is not a 99.9999% solution; it is more like Waymo in 2014. But the key is to get Devin to complete the first processing or to have Devin send code for you to review. If Devin does 90% of the work and you do 10%, that is still very useful. Colossus: You won an IOI gold medal around the age of 17, so you could say you are one of the best programmers in the world. What qualities do those who perform well in competitions possess that set them apart from others? What is at the forefront of competition? In this field, in what areas do you try to surpass your competitors? Scott Wu: These competitions are more like algorithm problem competitions. But in all of this, I think the core of programming is the ability to deeply understand abstractions and work at an abstract level. I believe this is still true in today's software; the core part of software engineering is to truly understand the customer's problems or your own product issues and find solutions. Think carefully about how you will represent it, how to architect it, and consider all situations and details. Interestingly, this is clearly the part of software that every engineer loves, and I think this is also the key that distinguishes a person from an ordinary engineer to a 10x or even 100x engineer. At the same time, this may only account for about 10% of an ordinary engineer's workload, as the remaining 90% of their time is spent debugging, implementing, setting up, testing, handling their DevOps, figuring out why the database crashed, or dealing with all these things that seem more like implementation rather than creative. But even so, I would say creativity and problem-solving truly define programming. Colossus: Can you paint a picture for us of your predictions for computer programming in the next five to ten years? Scott Wu: First of all, you asked about competitive programming. The best programmer in history is a person named Gennady Korotkevich. I can imagine that in the next year or two, we will have AI capable of defeating Gennady in the next programming competition. I think this will be a moment like AlphaGo, where people will exclaim, "Wow, such a thing really exists." What will happen to software engineering as a whole? I return to the point we discussed earlier: all programming is essentially about telling the computer what you want it to do. Much of the work related to AI and AI agents is actually just the next generation of human-computer interfaces. If you consider a programming language like Python, which is probably the most popular language right now, but if you really look closely, it is a huge compromise. From the human perspective, obviously, you have to learn to code. 99% of the people in the world do not code, and it takes years to learn all the details. And you learn these things just to communicate with the computer. From the computer's perspective, Python itself is actually notoriously slow and inefficient. If you really understand how to run code on bare metal assembly, you can make all systems run ten times or even a hundred times faster. I think one major problem that AI will truly solve is essentially a translation problem, which is that anyone, without needing coding training, can accurately describe what they want to build. The computer will construct an efficient and fully functional version. It will take some time to achieve this. Obviously, I think this is the direction we are heading in the future. Colossus: In five years, let me, someone with no computer science experience, be able to obtain what I want with high fidelity without relying on human programmers. Do you think this is feasible? Scott Wu: I think it is feasible. I believe five to ten years is a reasonable timeframe. I want to add that we are assuming applications must be able to generalize. Perhaps it can be said that today the cost of software engineering is so high that the only software worth building is applications that can serve millions of people, like YouTube or DoorDash. But there are many things that would be better served with code. Communities of thousands of people, small groups or niches, or even personalized products tailored for one person. So whatever your daily tasks are, they are actually better suited to be handled with code. This code can accomplish everything you might need to do and make all executions clearer. The reason we haven't achieved this is that no one in the world feels it makes sense to write custom software for their personal use case every time they want to do something new. But I believe we will reach a stage where this is possible. Colossus: You mentioned earlier that engineers spend only 10% of their time on the creative part, while 90% of their time may be spent ensuring things run smoothly, more like mechanics rather than creative, productive engineers. Does this mean that in the short term, Devin and other similar systems will help us complete that 90% of the work, allowing programmers to focus on that 10%? Scott Wu: I believe this is completely correct. AI takes on all the miscellaneous tasks: implementation, debugging, and iteration, saving 90% of the time. Then, engineers can focus on the remaining 10% tenfold. Clearly, there are many fears about the impact and replacement of human jobs as AI capabilities improve. But I think one of the wonderful aspects of software is that if we have ten times the capability over the past several years, there is actually ten times or more software that can be developed. If you talk to any engineering team, no team will say, "Yes, we have built everything we want to build." Every team has 20 projects they want to do, but due to the shortage of software engineers and the lengthy software development process, they can only choose three to pursue. I sincerely believe we will see many instances of the Jevons Paradox: as software development becomes easier, we will continuously build more software. The Jevons Paradox refers to the situation where technological advancements improve the efficiency of resource use (reducing the amount required for any one use), but the cost reduction leads to increased demand, causing the rate of resource consumption to rise rather than fall. Developing software is now about ten times easier than it was in the 1980s, and similar transformations will clearly happen even faster. In the long run, I think the core of software engineering is still about each person deciding which problems they want to solve and what kind of solutions they want to build. Artificial intelligence is not magic; it clearly won't solve all your problems for you, but it will empower you to precisely define the solutions you want and be able to realize and build them. Colossus: If we have previously been constrained by the supply of development capabilities, and this situation is about to change, does this mean that those who do better in demand and distribution will win in the future? Scott Wu: I believe in the software field, we have always been constrained by supply rather than demand. Clearly, there is a lot of demand that is relatively fixed. I think there will be many interesting second-order effects regarding what will happen to the economy, and many intriguing questions. The simplest way to put it is, where is all the funding in the tech sector flowing? Where is venture capital flowing? Primarily to software engineers. Therefore, when you bring ten times the benefit for each software engineer, it really changes the landscape—the things people can build with products and what they can do are vastly different. Then, I think in the long run, companies will see many interesting impacts. To put it bluntly, I see several different categories of companies. I think the most difficult category is those that heavily rely on switching costs and lock-in. Many software companies earn substantial revenue because switching to other products or technologies is very painful. If Devin can handle all the implementation and migration, and these costs drop to zero, clearly more competition will shift towards having better products. This will be a real shift that companies need to deal with. At the same time, this is not a nihilistic view. You know, there are many things that will remain strong, or even stronger. Network effects, I believe, will always be golden. Data and personalization will become even more powerful. Therefore, companies that have the infrastructure or possess all personal relationships and data will be able to provide truly optimized personalized products for everyone, rather than those clunky ones Products that are suitable for everyone but not perfect for anyone, I believe these companies will perform exceptionally well. Colossus: Technology will lead to a decrease in cost curves. One of the most obvious things that has already happened in artificial intelligence is that the marginal cost of content creation across all different forms of media is starting to approach zero. It seems that the cost of the software itself in what you are building is also experiencing the same curve. In such a reality, how do you build a software company? If I fast forward 10 years, or long enough, why would Devin still need costs? Why wouldn't there be an open-source Devin doing everything for me? If we enter an era where the marginal cost of software creation approaches zero, why would I still need to pay for software? Scott Wu: I believe Devin is currently the only one in the market doing this. But as you said, I believe many competitors will emerge soon. Those who want to do similar things in coding are good for consumers. We just discussed things like 10x engineers. In fact, as a software engineer, at every level of decision-making, quality, and skill, there is this exponential return curve. One obvious thing is that we can truly personalize Devin highly for each customer. For example, for many clients of Devin, Devin understands every detail of the entire codebase, having written half of the files in the codebase. These details, not just lines of code, but also decision processes, thought processes, etc., have all been internalized by Devin and collaborated with the entire engineering team. This is indeed a trade-off: a potentially smart and sharp engineer who is just starting to engage with your codebase today versus an engineer who has been working in your codebase for years, understands every file, has built all these features, and fully comprehends what your engineers mean when they ask certain questions. This can boil down to pure technical switching costs, such as migrating all files to a new platform or transferring to a different platform. Yes, I believe this will become cheaper over time. Meanwhile, if you have a level of personalization, if you have network effects or other factors, it’s not just about switching costs, but about your ability to provide a better product.