A fireside chat on the evolution of the developer craft

[MUSIC PLAYING] RICHARD SEROTER: All right, welcome, everybody. Thank you for joining us today. We're going to have a fun conversation with some people who've never been, I think, on a stage together before. We have Aja, who's one of the most pragmatic and talented engineers I have met. There's Ciera, who does some of the most interesting work on what Google engineers are doing every day and how we get better. And I always love her insights. And Addy, who's doing some of the most creative and thoughtful work into, what does modern AI development even look like? So you are in for a treat. And then me, who doesn't belong up here. So I'll be asking these smart people some questions about, what does this mean? What kind of skills should we have? What sort of changes should we be getting ready for so we can really get to work? I've asked them to have no filter. This is live stream, so what can go wrong? Let's have some fun. So kind of to start off, I want to think about, how do we think about the role of, what in the world's a senior engineer nowadays? Is it based on your skills? Is it based on even the scope of the work you do? How do we think about this now, as we have this sort of almost agents or junior engineers and then you have others. What's the relationship? How does even a career progression work? I'll start with you, Addy. ADDY OSMANI: Yeah, I think seniority used to mean that you could write code and solve problems that other people couldn't. And now it means that you understand code that other people can't necessarily understand. But clarity, seniority, is something I think about. And the people who I feel are doing the best at this moment are the ones who already have that strong kind of mental mindset that they're bringing to the table. So they're building their AI base on top of already strong engineering fundamentals. RICHARD SEROTER: Yeah. ADDY OSMANI: Think about it. RICHARD SEROTER: Ciera you've looked at even how Google looks at engineering, and seniority, and progression. What in the world's a senior engineer in 2026? Is it any different? Or are we redefining it? CIERA JASPAN: I think a senior engineer is still going to have a lot of the qualities that they do today. They are the people who are going to take a problem and break it down into smaller, more component parts. They're the people who do trade-off analysis. Do I want this particular system to be highly secure, but the performance is less? Or do I want something that's less secure, more performant? That depends upon what kind of business case you have. And it depends upon all sorts of other trade-offs you're trying to make. So I think a senior engineer is still going to be doing those types of things. The hard part is that we're now going to need to make sure everybody is a senior engineer, including our most junior people graduating from college today. So we're going to need to figure out how to upskill them really fast. RICHARD SEROTER: Can I ask you a spontaneous follow up, Aja? Would you hire differently for senior engineer? What would you be looking for now that you weren't looking for 12 months ago? AJA HAMMERLY: So I've always had kind of a philosophy that a senior engineer is someone who solves challenging technical problems in a way that works for the business, and someone that I wouldn't mind debugging an issue with in prod at 2:00 AM, so other things. I would look for the ability to use the tech and a strong curiosity about the tech, and someone who has techniques for staying up to date because, I don't know about all y'all, but, wow, it feels like we're all on a rocket ship together right now. And so, yeah, I would look a little bit differently. I'd want someone who's comfortable with AI, who's using AI, and also someone who has the skills and has built the practice for themselves of keeping up-to-date on these techniques and is curious about new options. But at the core-- for me, at least-- senior engineers solve interesting business problems and have the wisdom and skill to do that. And I don't think that part has changed. RICHARD SEROTER: Yeah, Addy, would you write a different job description today if you were adding a senior engineer to the team? ADDY OSMANI: I think that on top of what everybody else has said, I would also want somebody to have a perspective on what mentorship means today. I want someone that is not just going to be spawning 20 agents and leaving the rest of the team to figure things out by themselves because I think to that point of, the juniors of today are our seniors of tomorrow, we need to be investing in them. I feel like we need to be very proactive and explicit about how we are helping them level up because you don't know what you don't know. You don't know what it means to have a high-quality solution that addresses all of the business needs, all of the needs of the problem space. And so that's one thing that I would be looking for, for sure. RICHARD SEROTER: That journey as developers learn and as we grow, there's the engineers are doing more types of work, maybe even producing some of the docs, doing some of the product work, the UI work in others. How do we adapt when who writes code is blurring? Ciera, you've been studying how Google's done development for a very long time. And there's probably some very clear definitions of the work that's kind of changing. Does anything change when, all of a sudden, a PM is writing code, even prototype work, or the designer, or any of us. What has to change here? How do we have to think differently? CIERA JASPAN: We are actively-- it's hard. I like to do research, and it's really been hard to do research on this topic because it is changing so fast. This is something we are actively looking at, is trying to understand, how are everyone's job roles changing? I can tell you that it's been interesting to watch, though, anecdotally, even from my own team. My team is a cross-functional team. We have software engineers, UX researchers, and data scientists. And we had one week we were all trying to explore how to use AI. And we came back together at the end of the week. The most interesting part was that the software engineers weren't writing code. We were all writing design docs and fixing up our documentation. And the UX researchers were all writing code. RICHARD SEROTER: Wow. CIERA JASPAN: So there's this, we all kind of did, but it was always the junior level of it. We were all doing the junior level of everyone else's job and then the senior level of our own job. So that's my anticipation based upon that of what's going to happen, but this is something we're actively exploring. RICHARD SEROTER: That's a great answer. Aja, when you think of even your team, you have some pretty Swiss army knife-type team members who can do all different types of work. But as you look at this, because different people can do different parts now, do the expectations on a developer change? Do they say, this isn't my job anymore? Is everything everybody's job? AJA HAMMERLY: I think we're still at a stage where everyone has expertise. Everyone has a place where they're deep. Everyone has places where they have wisdom. AI makes us able to do things we couldn't do before. I'm a huge fan of the idea of builders and that we're all builders, and we all bring unique talents to that. And that was true before. And this is the thing. We all have languages, or frameworks, or parts of the stack that we're better at. That said, I am seeing-- and not just in my team, not just at Google, but when I talk to folks in the community, folks who have a lot of curiosity-- I keep saying that word --and a lot of different talents are being very successful with these tools because they can take their knowledge about-- they know a little bit about UX, they know a little bit about product design, and they know a little bit about how to code or a lot about how to code. And they can take those things together. And AI lets them combine those skills in new and interesting ways. And that's super interesting. How do I think about how that changes things for developers? I think that's still happening. I think we're all still on this journey together. RICHARD SEROTER: Yeah, Addy, how do you-- for anybody who's a developer engineer today, how do we not get annoyed when all these other people are building stuff and handing it to us? Leave me alone. Do your job. I want to do my job. That's not what's going to happen. ADDY OSMANI: Yeah. RICHARD SEROTER: How should the current engineers think about all these other new builders kind of coming in on their action? ADDY OSMANI: So when we talk about new builders, very often, we're talking about folks vibe coding a solution. Vibe coding has really raised the floor in terms of how many people can go and build stuff. And that's kind of amazing. Instead of just talking about a static mock, we can talk about a prototype you can start playing around with. That's a big shift. At the same time, I feel very strongly that agentic engineering, and how you factor in classic computer science, systems engineering, all those best practices to make sure that whatever gets created has good quality, has good security, has everything that you need to battle harden it for production. I think all of those things continue to be important. And as we expand the total addressable market for builders, we need to help people understand that there is a difference between one-shotting a solution, or quickly putting together something that you can throw up on a URL and something that can actually last time and maintenance. RICHARD SEROTER: As we think about what in the world is going to last, since no one can predict anything, how do you think about that reskilling, the de-skilling? There's a lot of stuff we need to forget, even in software engineering, as we do the new work. So what should people in this audience or people online be thinking about, where do they got to spend some of their time to continue to be relevant? How do they make sure they're not investing in the wrong places, where AI can do that job tomorrow and they haven't differentiated themselves? So where would you see, Ciera, an area maybe-- first off, for you, where should we be de-skilling? Is there something we should stop doing as part of this journey? CIERA JASPAN: Is there something we should stop doing? I am less certain about what to stop doing. I hadn't thought about in terms of that. RICHARD SEROTER: I can give you new skills, but I'm throwing a curveball at you. CIERA JASPAN: Oh, I hadn't thought about that one too much. But I'm going to go with new skills, then, because of that. I think one of the skills that we need to reinvest in, maybe, is actually doing a better job with our documentation. So when you think about bringing on agents onto a team, this is, you just doubled the size of your team and they're all junior engineers. And I know many of your teams probably are like many other teams in industry. You didn't quite write down everything, all the design decisions, all the process things, and you maybe have some out-of-date documentation. But it's not been worth it to update that documentation sometimes because, previously, you maybe had one new engineer a year join your team. And they have their own skills that they might be transferring from another team. They already know some of this stuff. So you didn't have to write it all down. Now you've literally doubled the size of your team, if not more, with entirely junior people. So we need to be reinvesting in writing high-quality internal documentation. RICHARD SEROTER: Addy, you've been writing a lot about, what does this kind of new way of working look like, some of the practices specifically, especially agentic engineering? So either on de-skilling, which I know is a hard one, or as you think of reskilling or just completely new skills, what is a skill that people in this room should walk out of here going, I need to learn how to do this? ADDY OSMANI: So very often in this moment, we will tell people to be endlessly curious and to be endlessly hungry. And what that often means is that you need to be very intentional about carving out time in your week to be trying stuff out. I can't remember another time in the industry, where it doesn't matter whether I'm talking to a junior engineer or a VP of engineering. Everybody is trying to carve out time to build, learn, experiment, and see what works and what doesn't work. And I think that that's very important. At the same time, what I hear from a lot of developers is that there is now such a big focus on velocity. We need to ship more. We need to get more product out, more features out. And people wonder, well, is there enough in that loop now for me to learn on the job? And so I think people need to be very intentional with, I'm not just going to work with my LLM on generating code. I'm actually going to take the time to understand what it generated, why it made some of the decisions that it made, so that you can stay a little bit sharp as you're building. RICHARD SEROTER: As a quick follow up, you wrote a couple of weeks ago-- everyone should read Addy's blog. It's terrific. But you kind of built on something. We were in a meeting and heard about cognitive surrender. We were talking about that. Can you explain what that is to this team and what you just said there, of taking time to study what was produced is really important. So what is cognitive surrender? ADDY OSMANI: So there's really two key ideas here. The first is cognitive debt. And cognitive debt is the erosion of your understanding and your memory around how to solve problems because you are deferring to AI to help you with them. And a natural conclusion from that, or a natural follow up, is cognitive surrender, where you stop thinking altogether. And the answer the LLM gives you is the answer that you just accept. You blindly accept it. You say, OK, I'm just going to merge those changes in. And if there's a problem, well, I'm just going to say the agent's going to fix it. And the big challenge with that is that we stop critical thinking. We stop thinking for ourselves. We stop being able to properly debug systems because we actually don't know how they work. And so you end up with a really big house of cards at the end of the day. So we want to avoid that. RICHARD SEROTER: Yeah, Aja, when you think of reskilling, or a new skill, or something, where for either senior engineers or even junior engineers getting going, where's that area that they should feel urgency on to develop? AJA HAMMERLY: So I think the thing that folks should feel urgency on is architecture, knowing how to solve problems, knowing how to break up problems, knowing what should be an agent encapsulated versus what is too much responsibility for any single agent, how those agents should talk to each other. If you have a large problem, do you break it up? Do you have one agent work on it for a day? Or do you have 10 agents work on it for an hour, 24 agents work on it for an hour? Those architecture questions have moved way down the stack of the employees. Everyone can solve-- is dealing with those architecture questions now. So thinking through those problems, understanding trade-offs in approaches. I'll use the word algorithm, but it's more than that. It's architectures. That's the stuff that I think everyone needs to be up to date on because we have a huge set of tools now to bring to problems, but we still need to frame the problems well for those tools. And we need to make decisions that make sense and that are sustainable using those tools. So for me, it's just all sorts of AI architectures. RICHARD SEROTER: Right. So can I give you a de-skilling that you can argue with me about, which you won't agree with me on? CIERA JASPAN: Go for it. RICHARD SEROTER: Awesome. I think we should fall out of love with our IDEs and programming languages, in a lot of cases, because you might spend a week tuning your VS Code or your IntelliJ to just all your favorite specs and settings. I don't think it matters that much anymore. Use them. That's amazing. But it seems like as we move to different surfaces and you want to have a little more promiscuity in your DevTools, you should not be just married to one stack, even one programming language, because you're limiting yourself. But disagree with me. I just think we need to deskill on our tools, unless it's Antigravity. Then you should be totally committing to it entirely. But for the most part, how do you feel about the DevTools? Aja? AJA HAMMERLY: So I was going to say, if you'd asked me about de-skill earlier, that we should de-skill on syntax. I have always loved programming languages, and I always use a lot of them. I was writing Lisp yesterday to put Antigravity CLI inside Emacs because it made-- brought me joy, not because it needed to be there. But I'm now using Go, which I didn't know six months ago. I conceptually understand the strengths and weaknesses of Go. I understand the concepts behind Go. I can read it, but I probably could not write a line of-- significant number of lines of Go myself right now because I haven't learned the syntax. I've learned to read it. I've learned the strengths and weaknesses of it, I've learned the concepts, but I don't really bother with syntax. On any given week, I probably touch five languages these days because different problems are shaped for different tools. And I just use the right tools. ADK, I have learned ADK-- David? David's not in the room. I've learned ADK, but I could not tell you the syntax. RICHARD SEROTER: Right. AJA HAMMERLY: I use it all the time. I generate all that code. RICHARD SEROTER: That's a good answer. Ciera, tell me that's blasphemy or how you feel about the DevTool space. CIERA JASPAN: I'm going to shift your de-skilling question a little bit and say that, I think the thing to de-skill on is anything that causes us friction. So that's anything-- and some parts of the IDE are that, like I have to-- if I install a new IDE and I want to change up all the settings to be exactly the way I like it, ugh, that's a waste of my time. I don't really enjoy doing that. But there's other aspects of our workflow, our daily workflows, that give us friction. And I think right now is a good opportunity to say, anytime you find a friction point, try to de-skill on that by getting the AI to do it for you. Those are the things that are causing us pain and are not helpful to our own productivity. RICHARD SEROTER: That's a good answer. Addy, how do you feel about DevTools? You don't have to implicate yourself because I know you use virtually everything right now. But were you doing that five years ago? Or did you have a more fixed stack and now you're just swapping all the time? Has that always been the case for you? ADDY OSMANI: So I have a slightly different twist on the question, which is, I would say five years ago, in the industry, there was a lot of religion around the tech stacks people would use, and the frameworks people would use, and the libraries people would use. People have very strong opinions and they feel like they were a part of a particular community. RICHARD SEROTER: Yeah. ADDY OSMANI: And getting someone to switch from one solution to another is something that often came with friction and often came with a lot of effort. I think over time, what we're seeing is, if an agent can help you not have to worry about that problem to-- Ciera's problem. That point about friction, I think that is going to mean that maybe we spend less time worrying behind the scenes about what framework we're using. I think that's interesting. I would also agree with you that, five years ago, we probably still would have been debating about what the right sets of plugins, and syntax, and all of those things we should be highlighting in our editors. And that matters a lot less now. RICHARD SEROTER: Yeah, so I don't like using the term best practice nowadays because nobody knows it's a best-- good practice. And so for all of the people here, we could look at something that was considered conventional wisdom even six or 12 months ago and go, that's wrong now. Look at something like RAG, which everyone was obsessed about, retrieval augmented generation. And now, hey, there's new ways that you might do context setting or different patterns for agent architectures that we don't find exciting anymore. How in the world are we supposed to grab on to anything when it comes to practices, the ways to work with these tools, when it's changing this fast? What's our responsibility? What do you think developers need to be doing? Sierra, you track how a lot of developers are following practices at a company. What happens when they're not stable? CIERA JASPAN: It is impossible for me to do research on them, is that-- RICHARD SEROTER: Your job is impossible, yeah. CIERA JASPAN: No, but we are early in the technology adoption cycle right now. And I will say, I personally find this painful as both a researcher and a software engineer. But it's also a necessary phase for us to go through. We are right now-- our whole industry is just exploring this space. We aren't sure where we're going and exactly all the opportunities that are available. And we should be exploring it. We should be trying everything and see what works, see what doesn't. I would predict a couple of years from now, we're going to start seeing a consolidation. We're going to start seeing best practices emerge. And that's where the research side, from my perspective, is going to become fun because now I'm able to say, OK, this person proposed this is a best practice and this person proposed this is a best practice. Now I can actually go and figure out which ones of those actually are, which ones are not. How do we tweak them? And after we get some best practices, we will start codifying those. And this is where the development tools are really going to shift because we will take those best practices, codify them into the tools. And that's going to be eventually what really helps us have a huge boost to overall productivity. But this is a technology adoption cycle. Our industry has done this before, by the way. If you want to have real fun, go look at the abstract for the original paper about Fortran. The idea of structured programming was so new that people were amazed by it. And the abstract you could put in a paper today, it's like, we're going to have hundreds of times more productivity gains if we all use this. And that still went through that adoption cycle. We still tried out a bunch of stuff. And at some point, we figured out gotos are a terrible idea. Don't do that. We're going to have that same adoption cycle here. Hopefully, it'll be a little bit shorter. I think it will be. But a couple years from now, I we're going to start really seeing some best practices emerge. RICHARD SEROTER: So, Addy, do you think it's a bit of wait and see or do some experimentation? If you find something that works for you, just do it. And don't feel FOMO that you're missing the new hot thing talked about at I/O this week, if your thing works. How should someone think about the experimentation, but sometimes not avoiding settling on anything for years until all the standards get set? ADDY OSMANI: Yeah, so I think our industry tends to fall into the trap of painting things with very broad strokes. And what I mean by that is, if you go on X and you see that there are three tools that have been released this week, new models, all of these things, Ralph loops people are using, anything that looks like it's new, who is that best for? RICHARD SEROTER: Yeah. ADDY OSMANI: Is it best for the one-person startup, the one-person founder? Because they've got a very different workflow to a team or an enterprise. And we often don't provide that nuance to people. And so when it comes to some of these ideas that are maybe bleeding edge and getting shared on social networks that haven't had a long time to stabilize, I would say it's good to pay attention to them. Places like X can be a good leading indicator for what will eventually stabilize. Maybe try it out yourself, but don't feel compelled to bring that into work until you've seen other people try it out, unless you are that one person or three-person startup and you've got high-risk aversion, you're OK with taking a little bit of risk. So I feel like it's OK to not feel like you have to jump at every single new thing, but just be mindful of where that noise is coming from because it might not apply to you. RICHARD SEROTER: So, Aja, if that person is listening to social media, going, my gosh, I'm still writing code by hand like a dinosaur, I'm just so irrelevant that I should be doing 100% of my code with teams of agents who work 24/7, how do we tell that person, maybe, it's OK, relax, you don't have to follow every trend right now? AJA HAMMERLY: Everyone can just simmer. That would be a good start. Addy said it, it depends. It depends. The answer to all questions in software engineering-- and most things in life-- are it depends. If a production-- if a practice seems interesting, it seems related to a problem you're solving, great. I have a problem that I'm currently banging my head against, trying to figure out how to get AI to work for it. I can tell you right now, RAG doesn't work because I tried it and it didn't work. So it's fine. It's fine to work at this at a pace that is appropriate for your risk tolerance for your industry. I think everyone should be aware of these things. If you are an engineering manager and you are in the audience or you are watching, I highly encourage you to set aside time for your team to experiment. Call it show and tell. My team calls it work in progress. Call it science fair, whatever you need to do, because you're not going to actually be able to understand if these new trendy things will work for you unless you get hands on with them. You need to actually make the time to experiment. So please request from me to all of you. Set aside two hours a week, and we're just going to go experiment with these things. But if something doesn't work, if you don't have time to check it out this week, that's fine. And this isn't new. That's the thing. I've been to a lot of tech conferences over the last 20 years. There's always a new thing. Plenty of companies are running monoliths with no small services. Some companies have monorepos. All of these things have gone in and out of style. And the reason they've gone in and out of style is that they solve problems for some people and they don't work for others. And that's cool. If it works for you, great. RICHARD SEROTER: Now, in some cases, of course, we could just say, I'm just going to wait, hold tight for a little bit. So for some specifics, I'm going to ask each of you kind of some-- what's something someone should be doing as a daily habit now? What are some areas? And everything doesn't fit every person, as Aja has explained really well and all of you explained. But, Addy, I'll start with you. When you think of a habit that you either started yourself or you would encourage others to start to change that mindset? Because I think what we're doing is building new habits. We're not just adding tools. ADDY OSMANI: Absolutely. RICHARD SEROTER: What are those habits? ADDY OSMANI: So I think that, early on in the adoption cycle, we would talk about, AI is great because it can help us ship things faster. I don't think that's the right way to think about it for your daily workflow. I think mutual amplification is a good way to think about it. And what that means is, as I use an agent every day, I should be getting better, my agent should be getting better, and there should be a loop there where we are both helping each other amplify and get better together. Specific things you can do by that-- and the tools are getting better at this as well-- trying to make sure that you have a clear idea about, what are the new insights that I had from the day? Are those things that I bake back into my skills? Are there things that I share into a learning markdown file or something that my agent can reuse? How do I make sure that the mistakes I made yesterday are not the same ones I'm going to make tomorrow? That's one thing that I try to do with my agent. RICHARD SEROTER: How do you do that? Do you block off the last 15 minutes of your day? Are you doing it continuously? How did you make that habit? You could say, that's a good idea, but you got to do it. ADDY OSMANI: Yeah, so in your agent's markdown file or whatever configuration you have, you can define an instruction that says, at the end of this session, let's either try to codify the learnings from it automatically or prompt me to even ask, well, what are the things that I didn't actually know from the day before? So I think that just having a reinforced learning loop can be useful there. RICHARD SEROTER: That's a good one. Ciera, as you think of-- you were talking beforehand before we got up here, some of the agents you're building for fun productivity-wise or things like that to change your work. Have you noticed certain daily habits that people could add, even if it's bit-by-bit, that start to flip that mindset? CIERA JASPAN: I'm actually doing a very similar thing as Addy. I'm trying to be very intentional when I am using an agent and trying to teach that agent to do a new thing. That at every step, I'm saying, OK, please go update your markdown file to put everything you just learned about this. Every time it makes a mistake, I ask it to figure out why it made that mistake. Go update that file again. And it feels a little slower at first, but I am doing that because it does get me to a faster place at the end. I'm also, I will note, not someone who-- I'm not a person who jumps onto the latest tool every single day. I cannot keep track of how many new tools are going on. So I'm very intentional about this month, I'm going to learn this new tool, or I'm going to take agents and use them to solve the following common type of problem I have. And I've spent that whole month really focusing on that, finding the best practices for myself. And then I share those with my team. RICHARD SEROTER: Nice. Aja, as you think of daily habits for yourself, things you've seen from your team, but what does somebody walk out of here going, you know what? You do this on Thursday, and you just start breaking it down. AJA HAMMERLY: So, yes, one of my colleague's said 100% that. But I'm going to throw a weird one out that I've adopted and I've found super helpful. I treat any of the AIs that I'm interacting with, whether it's in Docs, whether it's in Antigravity, whether it's Gemini.google.com, I treat all of those as an adversarial mentor. So when I finish coding, I'm like, hey, what did we miss? What did I miss? What do you think I'm not going to understand about this? When I'm writing a doc, whether it's for you, Richard, or someone else, I'm like, hey, what are some of the objections to this going to be? What parts of this are unclear? How can I become better from this? One of the first directions I gave Antigravity 2.0 when I started it up on my machine in beta testing is, I'm here to learn. I need you to tell me how I can improve. But every time I finish a session, it's like, hey, what did we miss? What did we forget? Every time before I do a push, what isn't right? What doesn't look good here? Those are the things I'm asking it to remind me of. And I tell it, don't be nice, because, sometimes, you have to tell it to not be nice. And I find that setting it up as an adversarial mentor, there's no audience. It's an AI. If it tells me I'm dumb, it's a dumb computer. We're even. It's fine. But the quality of my work has massively improved because I'm a little less concerned with velocity. The velocity will come. I'm concerned with quality. And by building that habit in, that I try to finish nearly every session with that adversarial interaction, improves the quality of what comes out of that session a lot. And it does not feel good the first couple times. And it feels super weird the first couple times when your AI is telling you that you are a complete idiot and you missed all of these things, especially when the AI wrote that code. But the quality really improves. RICHARD SEROTER: That's great. I know one of the habits I've been thinking about is I'm trying to unlearn searching and think more in prompting. For example, most of us have been trained to talk to a search engine like a caveman, like San Diego, vacation, summer. We just knock this stuff out. And instead of writing sentences, I think we see in our Google Search data, we're seeing people write sentences with actual punctuation because they're prompting, they're thinking, they're communicating. You got to unlearn that. That's a new habit. But these engines aren't as simple as they were 15 years ago. You can ask pretty complicated things, so you take a second and actually formulate your goal, not just some weird keyword hack that I was used to doing. So even at this conference alone, there's how many new CLIs? Probably too many IDEs, DevTools. It's really easy to feel some fatigue over, just give me my old IDE from five years ago and leave me alone. Why are there so many freaking DevTools and SDKs? And first off, how is someone supposed to keep up to date on any of this? And then there's a pressure to say, I have a real job. I'm literally paid to keep up with this, and I barely do. Most of you all have real jobs, where someone's paying you to do something, not just to watch what's going on in social media. So how do you find that balance, Ciera, as you look at, we have to keep getting better, but I have a day job. How do you allocate the time? Or how do you focus that the right way? CIERA JASPAN: It's really hard to not be constantly feeling FOMO right now, right? There's always new things. I try to keep in mind-- this is why I did the thing where I said, I'm only learning one new tool a month. It keeps me sane. RICHARD SEROTER: [CHUCKLES] CIERA JASPAN: Because then I can-- because I do like to go deep on something. When I have a new tool that I'm going to use, I really want to understand it. And I really want to be able to make sure that I can use it in the best possible way. So for me, just picking one tool at a time, learning it well, and then deciding if I want to keep it in my rotation or if it's done, no, that didn't work for me. I do try to fail fast. If I see something that's just really not going to work, I will fail fast on them quickly and then pick up another one. But once I find one I like, I spend a good month with it. RICHARD SEROTER: That's good advice. How do you stay up to date? Even within Google, we share more tools than I'm aware of. So do you just wait for word of mouth? Do you explore randomly? CIERA JASPAN: Oh, yeah, I talk with my teammates. I keep track of different newsletters. A lot of times, though, your teammates are working on similar, as Aja said-- Addy said, your teammates are working on similar types of problems used, so they might have found something else that works for them. So that's where I usually get my info. RICHARD SEROTER: Yeah, Aja, I ask your team to do more and more all the time. I'm sorry, but not really. So they've got the regular work they have to do, but then they have to stay up to date on all this. How do you steer them or even steer yourself to do both of those things? AJA HAMMERLY: So a couple of things we do, we obviously mentioned the work-in-progress meeting. That's a place where folks share half-baked AI experiments and non-AI experiments with each other. It's where I have learned a lot of different techniques, different tools, internal tools. Another technique I personally use is, hey, how'd you do that? I was using that 10 years ago when I was learning new languages, new frameworks and stuff like that. Someone would show me, cool. I remember I did a-- I had a conference, where I used a weird keyboard shortcut in the talk. And that was the only thing people remembered from my 45-minute tech talk. Wait, how'd you flip those two characters? What was the command to do that? So I just asked how you did that. Make time for it. As I said, we try to make time for it. We try to build real stuff that we use. Bootstrap your own tools, even if there's stuff that you can actually buy. Even if you're only the user, bootstrapping your own tools gives you opportunities. And then the last one is cultivate relationships with smart people, whether those are people you follow online, whether those are people that you work with, whether those are personal friends. I learn a lot of what's going on in the world with AI from a handful of people that constantly send links to me saying, hey, did you see this? Or, hey, here's a research paper you might like. And I'm like, great, this is going to be fun to listen to on the treadmill. And that really helps too. I obviously check out social media and things like that, but-- RICHARD SEROTER: Yeah. AJA HAMMERLY: Having relationships with really smart people, including people on the panel here, whether online or in person, is really, really helpful. RICHARD SEROTER: Super helpful. You both actually mentioned the idea of having it be part of your actual work. So you're not looking at tools and things that are completely disconnected from your work. Maybe that makes it fit more. Is that a critical part of it? It's got to actually solve part of the work you're trying to do anyway? AJA HAMMERLY: I have a hard time getting motivated about a tool that doesn't solve a problem I currently have. RICHARD SEROTER: Yeah, Addy, what are you doing here? How are you both staying fresh? But also, you have a job to do. AJA HAMMERLY: So the way that I navigate this is I give myself an innovation budget. And I'm very intentional with, I only have a finite amount of time for experimenting with a brand new tool. So I'm going to be very picky with what I choose to try out, so that I have enough time to actually get a sense for whether it's going to help me be more productive. The other side of this is we're seeing a lot of convergence right now, right? If you take a look at any coding tool that is trying to help you with orchestration of multiple agents or managing multiple agents, the UX of many of these tools now look very, very similar. And so if you are picking a thing and it happens to be one of the top five popular things, there is a reasonable chance that you're going to at least build out the patterns and the muscle to also be successful with other tools. And so when it comes to that innovation budget, I try to look out for things that are not converging. Is someone trying out a new way of solving this problem that everybody else isn't? That's what I would-- RICHARD SEROTER: Yeah, that's interesting. On one hand, finding things that are similar. If you know one agent framework, you kind of know them all, or one agentic IDE, you kind of know them all. But you're looking not for those things. You're looking for those sort of left field, they're doing something new here. ADDY OSMANI: Exactly. RICHARD SEROTER: Interesting. So we talked about my clumsy attempts to move from searching to prompting, but how should developers here, overall, think about, I'm not just writing code, I'm writing prompts? I'm writing specs. I'm maybe even treating the output of the LLM or my harness as read-only code. And if I don't like the output, I go back and update my prompt, my context, my whatever. That's a weird mental shift. So, Aja, how do we go from, I write code to I write intentions that get turned into code? That's a weird, almost, identity shift. AJA HAMMERLY: It is 100% identity shift. And it's a mental model shift because you have to give up some control on the path that the code is going to take to get to the solution. That doesn't mean that you should not be a responsible developer. It doesn't mean that you should not review that code. It does not mean that you should not have the tools in place to make that code is correct, but you should have all of those already in your process. For me, it finally clicked about a year and a half ago when I sat down and watched someone who was really good at this, that they were describing the end state that they had shifted-- because when I got into computers, I got into computers because I wanted to build cool stuff. I think that's probably true of most of us. And then I got into the fact that I had to think about, OK, how do you build cool stuff? What's the syntax? What's the language? What's the framework? What do I need to pull in as dependencies? And watching someone who didn't happen to be an engineer at Google, who was very successful with some of our code gen tools, they had switched back to, I'm here to build cool stuff. And they were describing in detail the end state they had in mind. They were describing what they wanted to build. People call this spec-driven development. I think all development has kind of always been spec driven, but the idea that you have to switch-- you have to uplevel your thinking and get out of the syntax, get out of the particular libraries, potentially, and be very focused on the problem you're trying to solve. And it seems so obvious, and it is so, so hard. The number of times that I've been working on something-- I was working with Antigravity yesterday and I'm like, no, I don't want you to do it that way. And just time out. Let's talk. Let's have a conversation about why Antigravity is using that approach versus my approach. Oh, I didn't realize that there was this dependency situation here and this version was going to be faster. Great, let's do it your way. But it's not-- it doesn't feel right after 20 years of writing softwares. It's hard. And I don't think we talk enough about how it's hard. People assume that prompts are just, talk to it and it'll work. And that is true, but you have to be super clear on the problem and precise in describing it. And that is difficult for many of us. RICHARD SEROTER: Of course. Yeah, Ciera, how do you think about it? As well as maybe even that quality attribute because maybe, sometimes, we really feel we want to own the writing of code so we can trust it, or that it has a quality bar. When we're moving to prompts, how am I supposed to think differently about those kind of attributes? CIERA JASPAN: I kind of like that this is maybe going to be the forcing function that's going to take us from being programmers to being engineers. The code is still there. We still have to make sure it's high quality. But part of quality is not just the individual lines of code. It's about how the whole system is put together. It's about, does this system even solve the problem my users have in the first place? These are all aspects of quality, and that is still very important. What's going to-- the major way our mental model is going to change, though, is that it's not about just the code anymore for anyone. You have to be a real engineer. You have to think about, when I'm writing this prompt, what is the thing I'm building? How do I break down the problem? What are the trade-offs I'm going to be working with? RICHARD SEROTER: Yeah, Addy, prompts, code? Where's your head go? ADDY OSMANI: I think that when we-- building on top of the end state, do we actually know what we want? And I think that question is a good forcing function for us to really think hard what done and what good means because done can mean it's functionally correct. It doesn't mean that the front end, the UI, looks great, that it loads fast, that it's delightful, that it's accessible, or any of those other things that could technically mean done in our heads as experienced engineers. But sometimes, we can feel like we've written this long spec. And if it doesn't include all of these other dimensions in it, we're then deferring to the LLM to figure out, OK, well, what did you mean? And can I infer what you meant by previous sessions? Or do you have another idea in mind? So I think that all of this is just helping us get more clear about what we want and try to codify that inside your specs to the extent possible. RICHARD SEROTER: That's smart. All right, a couple more questions for you. And we'll be around afterwards if you want to come challenge us or yell at us about something. The first one was going to be, given that there's all these things we can do all with AI now, what's one of those things that you actually kind of excited about doing differently? Maybe it is the toil that we talked about earlier of getting out of the friction points. But give me something that you're actually excited about that you're looking forward to this doing to your work or has already done to your work. Aja, what actually has you pumped? AJA HAMMERLY: Can I have two? The first thing I'm super excited about is that the barrier to entry for new technologies is way lower. So we've been talking about, how do you keep up and stuff? But also, keeping up just got easier. I can try a new framework or a new tech stack in half an hour that would have taken me a week in the past. I can actually try a real problem as opposed to my go-to toy problem for learning new stuff. That excites me because I am trying so many new things right now that I haven't had time to try before. And the second thing that excites me-- and this is maybe unique to my role, but I don't think so-- is I am really enjoying sitting down with someone who thought that they couldn't do this. Frequently, these folks are in tech, but they're not coders. Or they feel that they couldn't ever be a coder for some reason. And helping them make something that they see as valuable, that helps them with their day-to-day job. And the fact that I get to do that on a daily basis, oh, my gosh, this is so cool. RICHARD SEROTER: Yeah. AJA HAMMERLY: And I think we can all do that, potentially, depending on where we work and what our role is. And I love watching folks make their first thing that has value to them. RICHARD SEROTER: Love it. Addy, what excites you? What are you able to like, I can either do this differently now, or I know I can do it when I look into the future? ADDY OSMANI: I can't remember another time when I felt more productive and more excited to work with my tools, while simultaneously feeling more tired than I ever have. And a lot of that comes down to, I love that we can use background agents, parallel agents right now, right? There are probably folks in the audience that have got their agents just running back home, building a bunch of cool stuff while they're here. I think that's kind of amazing. The fact that you can do that on your phone, your laptop, anywhere, and close the lid, and it's still working, that's kind of amazing. RICHARD SEROTER: Yeah. ADDY OSMANI: At the same time, running multiple agents does not mean that there is more of you. And so we have to realize that our cognitive bandwidth does not parallel as in the same way. So we need to start building out those patterns, and also maybe just have a little bit of patience with ourselves. RICHARD SEROTER: You've talked about the orchestration tax. You can't manage 20 agents successfully in your own brain very well. We just have finite capacity. So do you just manage yourself differently there or just know, here's my limit? I can handle this much. ADDY OSMANI: So the way that I navigate it is, I try to define isolated tasks that I am OK to defer to my background agents. And then I'm very intentional with picking the ones that require that cognitive bandwidth and require a little bit more attention. Maybe that's where the complexity is. And so far, I found that split has allowed me to stay sane and navigate this a little bit better. RICHARD SEROTER: Awesome. Well, let me do one more question for everybody here. We've talked about some takeaways. But, Ciera, what do you want someone to walk away with again or do tomorrow? What's one thing? Just do this tomorrow. They'll make you happy. And that's what we're all here for anyway. So how will they make you happy tomorrow? CIERA JASPAN: I would actually like to pull up something that Addy, mentioned, which was this idea of cognitive debt. Please, everyone, go read the paper that Margaret-Anne Storey wrote about three models of debt. She talks about technical debt, cognitive debt, and intent debt. Go learn about that. And she talks about how AI can accelerate everything about this, both making them better and making them worse at the same time, even. And what I would love for you to do is read that and think about, how are you going to use AI to make this actually better, to reduce technical debt, and to actually reduce cognitive debt and reduce cognitive surrender, keep yourself in the loop while still taking care of all the technical debt issues? RICHARD SEROTER: I love that. Aja, something people should do tomorrow? AJA HAMMERLY: So I'm going to go completely practical on this. Think of a task right now that you have to do on a regular basis that does not bring you joy. And go see if you can use one of the tools that we launched a year ago, yesterday, to reduce the amount of time that takes for you. I am still working through this process every time I do a repetitive task. Is this worth automating? The automation cost is way lower now, and my life is better with things that I enjoy being most of my time. RICHARD SEROTER: Awesome. And, Addy? ADDY OSMANI: Remind yourselves that there is a difference between feeling busy and actually being productive. You can run 20 agents and feel really, really busy. That doesn't mean you're actually getting productive work done. So just be very intentional with where you're spending your time and how many agents you're trying to run in parallel. RICHARD SEROTER: Love it. Yeah, I'll also say, do something that brings you joy. I built an Android app in AI Studio two hours ago. It just made me happy. So also, find some things that remind you why you love tech. So thank you to my panelists. You all are unbelievably smart and insightful in this sort of thing. And we're all learning as we go. Let's be curious, let's be humble, and let's do it together. Thanks, everybody. [MUSIC PLAYING]