{
  "video_id": "2Fp3jIrFTMo",
  "channel_slug": "nvidiadeveloper",
  "channel_handle": "nvidiadeveloper",
  "title": "Building Towards Self-Driving Codebases with Long-Running, Asynchronous Agents",
  "duration_seconds": 2269.0,
  "url": "https://www.youtube.com/watch?v=2Fp3jIrFTMo",
  "upload_date": "",
  "transcript": "Hey guys, I'm Aman. I'm one of the founders of\nCursor. And today I'm going to be talking about\nwhat we think the future of AI coding will look\nlike. In particular, talking about async agents\nand this future that we believe will\nlook like, self-driving code bases.\nI'm going to start by walking through how coding\nhas changed over the last several months and years\nand then go through each of these future\neras. What will async agents look like\nand what will self-driving code bases look like?\nFinally, I'm going to end by talking through\nwhat the role of the engineer looks like in a\nworld where code bases are fully self-driving.\nSo way back in 2021 2022, the primary way\nthat people were coding was just using IDs\nwith effectively no AI. No autocomplete even\nthe the only autocomplete completion was\nIntelliSense level things. But around that time\nlanguage models started getting much much better\nat coding both generating code and\nunderstanding code. And so the first\nAI coding application that started to\nwork was autocompletion or tab complete.\nThis is around the time that cursor burst onto\nthe scene. And so roughly the way that this works\nis by looking at the last however many minutes\nof work you've been doing inside of your editor\nand then understanding that models can predict\nwhat the next few minutes of edits, places you're\ngoing to jump to will look like. And so it looks\nlike this autocompletion predicting the next edits\nand so on and so forth. But models continue\nto get much better at code and they got better\nat being able to generate more complex changes\npotentially whole features. And they got strong\nenough that you could ask with natural language\ninstructions for agents to be able to implement\nfull changes. And so that brings us to the next\nera, the era we're currently in, where synchronous\ncode coding agents have quickly become the\ndominant way of programming and coding with AI.\nAnd you see this in the data. 2025 was really the\nyear of coding agents completely taking off where\nat the start of the year the models become good\nenough and the harnesses around them become good\nenough that you can actually start to use coding\nagents for the first time for a lot of your work\nand then by the end of the year we're\nat a point where the vast vast majority\nof code written in cursor is coming from agents\nrather than people using tab and this graph is\nactually astounding because it's not just\ntracking users are using agents versus tab,\nbut it is agent requests versus tab accepts.\nAnd with tab, effectively, every keystroke\ncan potentially trigger a tab request and get a\nrequest. So, so you end up seeing so many more\npeople actually submitting whole prompts and\npressing entering keystrokes in the editor.\nNow, synchronous agents work quite well,\nbut there are a lot of limitations.\nYou're mostly running these things on your local\nmachines, so they eat up a lot of resources.\nAnd if we want to be able to write more and\nmore code and kind of increase the throughput,\nwe're not going to be able to run tens of agents\non our local machine. And so that brings us here.\nWe are in the second era of AI coding and slowly\nmoving towards this third era of async agents.\nWe believe async agents will need their own\ncomputers and cloud environments to run.\nIf you want these agents to run for\na very long time, they're going to\nneed to be able to test their work. And\nthis means doing things like computer use\nor running lots of tests. That may be extremely\nresource intensive. You can maybe scale this\nlocally to a few agents, but scaling to tens\nat a time is just not going to be possible.\nAnd agents should have the full\nsuite of tools that a developer has.\nAnd in these cloud environments, they should\nbe able to do whatever you could do locally.\nAnd so here you can see the cursor cloud agents\nproduct where we've given our agent access to\nthis VM and a full desktop and it can use\nthe desktop in the ways described before.\nAnd one of the more interesting\nways that it does use it is via\nbeing able to use the computer and actually test\nout features. And I'll talk more about that later.\nAnd internally, we've seen\nrapid adoption of cloud agents.\nThis is a chart that tracks until the end\nof February, and it's quickly becoming the\ndominant way of coding within our company. Right\nnow 30% of merge PRs are coming from cloud agents.\nAnd there's one pretty actually I'll talk about\na few examples of these PRs because it isn't\njust these trivial bug fixes. One change\nmade was there was a pretty big refactor\nfor video rendering that made things 25x\nfaster and migrated things from React to Rust.\nAnd it took 8 hours. And here the computer was\nextremely useful for the agent to have because\nit could iterate because it could iterate on\nmaking a change actually running it measuring\nthe latency of that and then continuing to\ndo it over and over again. Another example\nwas implementing this 10,000 line PR of adding\nnetwork policy controls for sandbox processes.\nSo what started to cause this inflection\npoint because you can see that around when\nit says here artifacts are released internally you\nyou see this uptick in growth when we are using\nearly versions of cloud agents. It started become\nreally really tricky to review all the changes\nthat agents were producing. We're now operating\nin a regime where agents are producing two,\nthree, fourx more code than they could have if\njust running locally in a synchronous manner.\nAnd reviewing all those code changes and\nthen iterating with the agent when reviewing\ncode manually just doesn't become tractable\nat larger and larger levels of throughput.\nAnd so in the same way that a manager might do\na mix of code review but then also review the\nwork of their engineers output, we think it's\nreally important that when using cloud agents,\nengineers can review the outputs of the\nmodel and we call these outputs artifacts.\nOne example of this is video artifacts. So you\ncan see here that after implementing a feature,\nwe have cursor go in and actually take a\nvideo of the fully functioning feature.\nIf there's a bug in how it implemented it, you\ncan just look at this video and then follow up\nwith the agent. Or if it implemented it in a way\nthat didn't follow exactly how you specified.\nSimilarly, you can reprompt it without having\nto look at the code to understand what's going\non. Then when you get to a working demo of\nwhat you think your feature should look like,\nyou can take a pass at the code and review\nthat and merge it in if things look good.\nSimilarly, for ML research, we found it pretty\nuseful for very small scale experiments,\nhaving models go out and build a research report.\nSo this is the output of what maybe a researcher\nmight do. And so you're not just reviewing\nthe code changes made by this this agent,\nbut you're reviewing a report which is\nfar easier to grow quickly and understand.\nAnd again, it lets you iterate far more quickly\nand then go to the code changes only when\nyou have extreme confidence that\nit's done the right set of things.\nWe're still figuring out what this looks like\nfor places outside of research and pure product.\nA few additional ways that we think\nit could be helpful for backend and\ninfra might be iterating more so on things like\narchitecture diagrams iterating more on plans.\nIt's possible that you want the models to oversee\nyour code and tests wouldn't be things that are\nactually checked into the codebase but they exist\nas artifacts that let you understand if the agent\ndid the right thing or not and can be effectively\nthrown away. But we haven't quite figured out what\nit looks like for those other domains outside of\nproduct and research yet. But we're working on it.\nSo how do we build cloud agents and make them\nextremely good at long running tasks? Because\nthis is the only way in which cloud agents and\nasync agents become useful if you can actually\ntrust that they can run for a pretty long time and\ndo a better job than if they're running quickly\nlocally. So I want to introduce this concept of\ntrain time versus test time. The way that these\nagents are trained one of the main ways in\nwhich these agents are trained is using RL\nreinforcement learning and it will see a task in\ntraining try to solve it many different times and\nthen the times that it succeeded those attempts\nwill get positively reinforced by the model. So\nthe model will learn to act more like that and\nlearn to act less like the failure attempts.\nAnd generally if when you deploy your agent in\nthe real world, those problems that it sees,\nthose tasks it sees are very similar\nto the task that it's been trained on,\nyour agent's going to perform a lot better.\nSo you want this train time, test time match.\nAnd if there's a mismatch, you're going\nto see some degradation of performance.\nSo, if you were to naively just have an\nagent work for a very, very long time,\nit's going to have to run trajectories that\nspan not just hundreds of thousands of tokens,\nbut millions, potentially\ntens of millions of tokens.\nAnd then this starts to get outside of the bounds\nof how these models and agents are trained where\nit is just intractable to train and RL agents\nfor things outside of hundreds of thousands maybe\nmillions of tokens. So as you go to high millions\nor tens of millions, they'll just fall apart.\nAnd you guys may have observed this from using\ncoding agents that run for extremely long times.\nBut they'll lose track of things kind of not be\nable to go in enough detail in certain parts.\nAnd this is where we find the concept\nof multi-agent to be extremely useful.\nMulti-agent is a broad term that effectively\ncovers any system that uses multiple agents\nin any way. The simplest version of this\nis just the main agent and sub agents.\nAnd this is one of the key reasons why we believe\nsub agents work works extremely well for longer\nrunning tasks where each of these subtasks is\nnow a much simpler task that is well within\nthe distribution of how these models are\ntrained. And then the actual outer model\nthat is calling all these sub agents\nis not running for as long a time,\ninstead of running for tens of millions of tokens,\nit's running for maybe a few hundred thousand\nand then calling sub agents, kind of fanning out\nthe work that way. And so you get this nicer match\nwhere the models aren't kind of overextended in\nhow long they run versus how they're trained.\nAnother benefit of the multi-agent system\nis that you're starting to see some kind of\nspecialization or divergence in capabilities and\nmodels for different things. And what do I mean by\nthis? We found that OpenAI models tend to be the\nstrongest when it comes to higher level planning\nand orchestration. But when it comes to things\nlike computer use or multimodal understanding,\nGemini and Anthropic models are stronger. When\nit comes to creating better UIs, Anthropic models\ntend to be stronger. And so the way that our cloud\nagents work is we generally use OpenAI models\nas the planner and then we'll use other better\nmultimodal models and computer use computer using\nmodels to actually record the videos or use the\nfeatures and prove to you that things are working.\nI think another interesting way that sub agents\ncan be useful are at a certain point sub agent\ntasks are not complicated enough that you need\nthe absolute largest slowest models for it\nand you can use much faster models and get the\nexact same performance for simpler sub agent tasks\nand so we also end up doing this in the\nproduct and get the same performance\nwhile delivering results much much faster.\nSo what are the weaknesses of this system? In the\nsame way that the single agent running for a long\ntime would fall over at long task durations. This\nthis system also works but then as the task as the\ntask length also gets longer eventually it'll hit\nits limit where the planning steps and the outer\nagent will start to go for millions maybe tens\nof millions of tokens and then it will fall apart\nagain. And models still aren't trained super\nwell to be excellent orchestrators of agents.\nAnd I think there's that the way that RL works\nreally benefits for kind of the worker level task,\nbut there's a lot of work to do to make models\nmuch better at this kind of orchestration layer.\nIt's something that we're very focused on when\ntraining the next generation of our own models\nas well, especially in be able being able\nto call out to multiple different models.\nAnd I think another piece that is underrated is\nthe value of what we call model UX. And this is\nkind of the reviewability of the model's outputs.\nIf we're starting to trust the artifacts produced\nby the model more than the code itself and the\ncode changes, then the model needs to do a really\ngood job of creating those artifacts for you. In\nparticular, if it recorded a video of a useless\npart of the feature that it was building or the\npart part of the product that it was building, it\nwouldn't be helpful at all and you'd have to go in\nand read the code anyways. So models need to learn\nhow to produce really useful and understandable\nartifacts. Already we see this at a kind of\nlower level with certain models will if different\nmodels produce the same kind of markdown answer.\nIt's much easier to understand when it's\nnicely formatted. And if it's this densely\npacked set of paragraphs, it's going to take\na lot longer to grok. So understanding the\nactual thing that the model did making the model\nreally good at at doing that will matter a lot\nespecially as models get arbitrarily good at given\na well-defined spec producing a correct answer.\nSo now I want to talk about what we call\nself-driving code bases. And we view this as\nsomewhat of a kind of terminal state of\nwhat async agents look like looks like\nand self-driving code bases. I think it involves\na few details. One is we want self-healing and\nfixing. And this means that there are changes\nbeing made that no human is ever reviewing.\nOnce more, as we go from local to async, you\nknow, you're increasing the number of agents\nper person from a few to tens. But at a\ncertain point, if you want to increase\nyour productivity to have more and more done,\nit's going to be too many agents running for\npeople to review some agents outputs.\nAnd so you want some changes that just\nautomatically get into main. And you can imagine\nthis looks like an issue tracker where issues are\nreported and some issues are easy enough to fix\nand models and agents have high enough confidence\nthat they can go make the fix, it can get\ninto main and no one's ever looked at it.\nThen the the other piece is being able to\nsignificantly increase the scope of what\nyour agents can do. in particular building full\nprojects or products or extremely large features\nwith little to no human intervention. Think of\nlike excellent products like notion or PowerPoint\nand whatnot. Can you have models do something\nlike build PowerPoint with little to no human\nintervention? It will take time to get there, but\nI think something like this might be possible.\nAnd in this world, we believe there's\ngoing to be no human written code.\nSo, first let's talk about self-healing and\nfixing. One of our early attempts here at creating\na product that can do this is what we call\nautomations. And so you can trigger these things\nin certain events like the issue tracker case\nthat I mentioned before where you can have agents\non every issue proposing a potential fix. But\nyou can also have agents running at other really\nvaluable events like every time you get paged in\nthe middle of the night, we have an agent going\ninvestigating the issue and then proposing a\npotential solution. So, if you're waking up groggy\nat 2:00 a.m., you might just need to do fix you\nmight just need a single click to fix the problem.\nEventually, we'd like to get to a spot where\nagents can always be the primary on call.\nAnd there are issues that will pop up in the\nmiddle of the night that an agent will fix\nand no human will ever get paged. Humans\nwill just be escalated to as a secondary.\nAlready we're using this in research for\nour training runs. We have agents running\nevery few steps looking at the logs in the\nclusters, looking at weights and biases\nto understand what's going on with all the\nmetrics and then flagging potential issues.\nThis lets us catch potential failures in training\nearlier so it doesn't silently degrade the model.\nAnd then it lets us catch issues\nthat could lead to runs crashing,\npreventing anyone from getting paged\nor losing valuable training time.\nWe also do this for code review and for\nsecurity where we're able to find a huge\nnumber of PRs with vulnerabilities that would\nhave otherwise gotten shipped. So having these\nagents just always running in all these events\nhas already started to show serious signs of life.\nNow I want to talk about what that second part\nof self-driving code bases looks like. Meaning\nbuilding full projects having really really\nlong running agents with little to no human\nintervention. The browser was one of our attempts\nat this. A browser is an extremely complicated\npiece of software on the level of or harder than\nan OS. It requires a rendering engine that can\ntake arbitrary HTML and CSS and turn it into\npixels handling animations as well. It requires\nbeing able to run arbitrary JavaScript in the\nsandbox environment and lots of other complicated\nthings. And so it's a really daunting challenging\ntask where the ceiling can be quite high.\nAnd we wanted to see if we could get agents to\nactually build some kind of working browser. This\nwas a one-week run that took billions of tokens on\nthe order of tens of thousands of dollars worth of\ncompute. And it produced something that works but\nis still quite far from real production browsers.\nYou can see an example of the browser here where\nit's able to render lots of arbitrary pages pages.\nThere's still several hiccups that don't\nmake it a fully functioning browser, but it's\nextremely impressive that agents are\nable to do something like this today.\nSo how did we actually build a harness\nto make something like this work? It\nextended the harness that we were using for async\nagents and use the same concept of multi-agent.\nSo we don't want to let a given agent run\nfor far too long because it's just going to\ngo off the rails. And so what we do is we have\na high-level planner that can then call out to\nsubplanners and it's this recursive like\nthing where the subplanner itself can call\nother subplanners and at the lowest level or the\nleaf nodes you have workers. And we found this\narchitecture. We tried a bunch of different\nones and this one ended up working the best.\nAnd it's a good bit simpler than kind of any of\nthe other ones we tried and really does leverage\nthat same concept of compressing the amount\nof tokens a given agent needs to run for.\nThe thing that we're pretty excited about\nis trying to make this multimodal as well\nwhere you can leverage those same strengths\nof different models that we mentioned earlier.\nWhere for the computer using pieces you'd use a\ndifferent set of models as you would for planning\nand as you would for UI. We're really excited\nabout also training our models to be quite good\nat these tasks. I don't think any model has been\ntrained with the idea of being able to use it in\nthis extremely long long-running harness. And\nwe're pretty excited about training a model to\nact as this planner or subplanner and be really\ngood at calling out to itself or other models.\nSo now we have this harness that works\npretty well. It's still early days and\nit'll take a lot of time to get to something\ntruly shippable. But what does the right user\ninterface look like in the world where we\nhave these self-driving codebase systems?\nRight now we have to do something that\nlooks like what prompt engineering was\na year and a half or a few years ago for\ngetting these agents to work. You have to\nwrite a really really detailed spec and\nthat goes into detail how it should think\nabout breaking down problems. Really sets\na clear rubric of what defines correctness.\nAnd it just takes a lot of attempts\nand kind of nudging the harness\nto get it to work really well. So the UX isn't\nthere yet. We expect that as agents get better,\nyou'll be able to the burden of how good the spec\nneeds to be will decrease and you'll be able to\nwork with models as well on building out really\ngood specs for building these entire projects.\nAnd then when you have agents building entire\nproducts, what is the right level of review?\nIt would suck to do this many tens of thousands\nof dollar run for a week and then come back and\nthe output is garbage. You want to be able\nto intervene at sub points in the middle.\nI think it looks fairly similar to the same\ninterfaces that work for normal cloud agents where\nyou'll want the model to be able to\nproduce these artifacts in the middle\nlike videos of various features. The model's\ngoing to need to be it's going to need to get much\nbetter at that piece of model UX because there's\nsuch a large surface area of what one could test,\nwhat one could record, what one could try to\nshow to the user and it needs to work on the\nareas of maximum ambiguity where the user\ndidn't specify enough or it's most unclear\nwhat the right choice is to have the user go\nin to have the engineer go in and result that.\nBut this is still an open question and\nwe're working on figuring that out.\nSo what does cursor look like in this world\nwhere you're running these agents for extremely\nlong time horizons? They're tackling\nfull projects full projects and kind of\nautomatically healing your codebase. Well, in the\nsame way that the old generation of clouds kind of\nacts as what we call a cost of goods sold cloud\nin delivering your service, your product to users.\nThe old clouds deliver the infrastructure such\nthat you can do this. Cursor aims to be a new kind\nof cloud that is we're building an R D cloud that\nhelps enterprises build more ambitious software\nand what does engineering become an interesting\nquestion and we've thought about this a good bit.\nI'll preface it by saying like we don't have a\nfantastic answer and it's really hard to predict\nexactly what it'll look like. But the things that\nwill be missing from agents and models for a while\nironically is kind of real agency\nof deciding what should get built.\nThere'll be details and product taste that are\nreally hard to learn. But ultimately deciding\nwhat are the right things to build that matter\nin the world are the most important pieces.\nAnd this is why we're investing really\nheavily in growing headcount ourselves.\nWe're scaling engineering 3x this year. And we\ndon't think that just because our engineers are\ngetting more productive with AI, we want to keep\nthat same level of productivity but cut headcount\nby a certain amount. Instead, we want to tackle\nmore ambitious things. We want to increase our\nproductivity and compound really excellent\nengineers with excellent tools like cursor.\nThanks. Now I'll kick it over to the audience for\na quick Q A. Excellent. Any questions for Aman?\nYeah. Oh, great.\nHi, Aman. Uh, my name is Michael Wield.\nI'm a student at Tane University. I have\none semester left. Just two weeks ago I\nwas actually taking a midterm in my class\nfor an artificial intelligence class and well\nover 90% of the class I want to say was cheating\nusing artificial intelligence tools large language\nmodels to effectively answer questions about\nwell how does AI work and how can we build agents\nfor certain problems. So I think it's illustrating\nthat like as you said the role of writing programs\nis definitely changing. How do you think cursor\nyou know perhaps aligns with the vision of say\nwhat someone's learning in education and I don't\nknow where do you think say for instance someone\nthat's studying computer science or studying to do\nsomething like software engineer how that's\nchanging and how cursor is changing that.\nYeah, I think education adapts extremely slowly to\nthese rapid technological changes. So I think lots\nof different organizations will be at different\nplaces and how far along they are and trying to\nuse these. I think you kind of need to allow\npeople to use AI for their applications just\nbecause that's not what things will look like in\nthe real world. And today you definitely still\nneed to really understand the details of the\ncode when operating in big company code bases,\nbut I think that will probably be\nless and less the case in the future.\nSo I do think that organizations should try\nto and educational organizations should try\nto adapt the way that they teach to account for\nthis future. Great question. Any way in the back\nThat's all right. Hi there. Thanks for the talk.\nReally appreciate it. There's a lot of discourse\naround taste these days. You were mentioning\nit as well. It's interesting because people\nare also learning a lot from these models and\nusing them as well. How do you guys think about\nboth protecting taste as people learn or develop\nor cultivating taste as well in what you build\nI think it's really important to not\nlose to slop and you need to make sure\nthat people still design and spend a\nlot of thought on what the shape of the\nUX will look like and what the shape of\nthe product will look like and making\nsure you don't just let velocity take over that\nbecause I think taste matters in a few places.\nThere is the product side of making sure you're\nbuilding the right features, the right UX and then\nI think taste also matters in the architectural\nand infra side and will matter for a while\nof making sure that you don't just merge swap code\nchanges and kind of really really bad architecture\nor kind of code design. So just making sure\nthat you really value that as a company\nand state this clearly is important and\njust like don't lose the battle to slop.\nQuestion here ammon great talk thank you regarding\ngenerating code is great but what about code\nreviews like do you have any thoughts on that?\nYeah, I mean I think in the same way that models\nwill get much better at producing that new code,\nthey're going to get a lot better at reviewing\ncode. And reviewing code for humans is most of\nthe time a lot less fun than writing code. And\nso now you have this this interesting thing where\nit's it's an activity that humans prefer not\nto do and models can be really really great at.\nI think we still need to get better at figuring\nout how to do that for code review. Already\nthey're decent, but I think there's just more\nwork ahead of us. On the RL side in particular,\nhey V from EAI. You said you're scaling your\nengineering 3x. As as you're assessing the\nfolks you're looking to bring on board for\nthat agency skill and agent building skills,\nlike how are you assessing them or what's\nwhat's your mechanism for figuring that out?\nThe final stage of the interview process\nis a two-day one or two day on-site project\nwhere they get to use cursor. So they get\nto use agents as much as they want. And the\ndifficulty there is we've had to consistently\nincrease the scope of what that project demands\nas the products have gotten as agents have\ngotten much much better. But we find that to\nbe an excellent way of testing whether people can\nuse agents effectively and we test for the things\nthat matter which are that agency piece and\nmaking like the correct decisions with respect\nto the architecture the code or product taste\nor so on and so forth for other disciplines.\nGreat question. Hi Aman thank you for the session\nI'm Suresh from United Health Group. So definitely\nlike the concept the way you explain the planner\nsubplanner and then worker agents. So have you\nthought about if you look at the enterprise right\nwe still have large code bases sitting on legacy\nlike AS400's main frames right so it's very\ndifficult to understand it's really what we really\nneed agencies to understand the concept and\ndecompose and write even provide some kind of\na design even before start coding. Yeah. So for\ncode understanding and I think there's two pieces\nthere. There's code understanding and then there's\nhow do you actively make your codebase better.\nOne other part of a self-healing codebase and\nself-driving codebase that I didn't mention\nis while you're sleeping while you're not\nactively using these agents they should be\nactively improving the codebase. If there's tech\ndebt or pieces of code that are really gnarly,\ncomplicated, hard to understand, they should be\ngoing in and just cleaning those up with the spare\ncompute and off-peak hours. And then yeah, I think\nagents have been excellent for understanding code.\nA lot of the time the way that people work\nfor or do engineering at cursors they spend\na lot of time working with the agent to understand\nsome part of the codebase before actually writing\na plan and then having the agent implement\nthat. So it's something we care a lot about.\nAnd similarly for understanding\nharder parts of the codebase\nwe think you know spending more computers scaling\nthis thing up in the multi-agent way could help.\nGreat question. I think we have time\nfor two more questions. So here you are.\nHey thanks for the presentation. Just a\nquick question on the enterprise software\nrealm as coding gets easier agents are doing\nmore coding. Do you think there will be a\nproliferation of enterprise software\nlike there'll be more software companies\nyou know more agents of record and things\nlike that? Yeah, I think you're going to see\nit easier and easier to create net new software\nto maintain complex software. And so I expect that\nyou'll be more bottlenecked by the quality\nof your ideas and deciding what to build\nthan anything else. And this allows a lot more\ncompanies to pop up, starters to pop up, people to\nand existing companies also to build more more\nproducts and enterprise additional enterprise\nofferings. So I see this kind of affecting\nall players in the space and what they can do.\nHi. I'm Joe Felder, software engineer at NASDAQ.\nAnd I had a question about the shift of the\nengineers role. And what you think of this that\nin the past, the best engineers can pay attention\nto details, can hold a lot of things in their\nhead, develop algorithms, all that sort of thing.\nAnd that was a really important skill for a good\nengineer, as well as top down versus bottom up\nlooking at things and all that. What do you\nthink will be the next big skill for this new\nway of doing things that an engineer would need\nto have since they don't have to focus on the\ndetails that way anymore? I think like there are\nthe skills that I had mentioned earlier of taste\nand architecture and product. But I think the same\ninitial two things that you mentioned still apply.\nSo holding a lot in your head is extremely\nvaluable. Now just the bar has kind of increased\nor like the types of things that you hold in\nyour head maybe change. So maybe you instead of\nan engineer holding a lot of a particular part\nof the codebase in their head. An engineer may\nneed to hold the entire codebase in their head but\nnot need enough detail of the lowest levels that\nthey're holding in your head. So actually I think\nholding a lot in your head will still be quite\nvaluable to be effective in working with these\nagents. And then attention to detail. I just think\nlike the what the details are will change but I\ndo think that same attention to detail matters\nright on the product side models will still make\nmistakes in various ways and misunderstanding what\nthe user wants and will do and have being\nable to pay attention to detail there\nor maybe they just don't have sufficient context\nin making the right architectural decisions.\nand being able to pay attention there\nin what the model is proposing to you\nand its outputs and the artifacts will still\nbe quite valuable. Fantastic. I think those\nwere some of the best questions we've had\nin sessions all day. So, I want to take a\nmoment and thank Aman so much for a fantastic\npresentation. Everyone put your hands together.",
  "transcript_chars": 31879,
  "ingested_at": "2026-05-15T10:50:25.746401+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 19510,
    "like_count": 431,
    "channel_id": "UCBHcMCGaiJhv-ESTcWGJPcw",
    "categories": [
      "Science & Technology"
    ],
    "tags": []
  }
}