Build core skills to thrive as an AI-era developer

[MUSIC PLAYING] ANDREW MACVEAN: Hi, everyone. How are we doing? Here we go. How are we feeling? Excited? There we go. Maybe a little overwhelmed? Curious? Hopefully, curious. OK, well, we're Andrew and Nicole. We're both leads on the Developer Intelligence Team here at Google. And together, we spend our careers studying software engineers-- the people, the processes, the tools, the systems, the culture. And we want to start by recognizing, this is a big moment for software engineering. You see quotes like this that really emphasize not just the magnitude of the moment but the speed at which change is happening. Our goal today is to share some of our research, some of our knowledge about what we're seeing inside of Google, and ultimately answer this question. How can we, as software engineers, continue to thrive in the AI-native era? We're going to do that by walking through this T-shaped software engineering role that we're seeing really grow in importance. We'll go into detail on some of the patterns we're seeing in terms of how software engineering is being done, the skills and the capabilities we're seeing are top engineers embody, and introduce some practical tips for how you can think about your role. But first, we want to set the scene. We want to make sure we're all on the same page here. Like we said, this is a big moment. But what's actually happening? First of all, we're seeing fairly pervasive adoption of AI tools for software engineering-- probably not a surprise to anyone here. The majority of tech professionals are using AI and relying on it, in many cases, a lot. We're also seeing profound impact. So inside of Google, 3/4 of all code is written by AI. At the same time, people are very reasonably asking, is it actually improving productivity? And if it is, is it 10%, 10x, 100x? The truth is in some places, there's even a productivity paradox occurring. There's some research that our DORA team did by studying multiple companies that increasing AI adoption can lead to individual productivity benefits, while, at the same time, decreasing team-level benefits. Over the last year inside of Google, we've seen some really interesting patterns emerge. First of all, we are seeing a lot of benefits. Not only are we seeing AI generate an increasing amount of code with more and more autonomy. We're seeing that with the right system, the right environments in place, that code actually lasts. This presentation is about the skills and the capabilities that really allow that to happen. Second of all, there's some really interesting emergent behaviors beyond those top-line numbers. For example, we're seeing that the engineers that use AI the most, they're actually spending more time coding, more time ideating, and more time collaborating with their peers. This is maybe counterintuitive. The truth is, they're doing more of these activities. The shape of them just looks a little different. Our top-performing engineers, they're more active, not less, even though they're delegating more and more work to AI. Now, it's important to note those AI benefits, they're not necessarily homogeneous. We know all about the old adage, garbage in, garbage out. And we've seen a lot of research around the need to not only really master working with AI but also the context and the domain in which you're applying that AI to. Furthermore-- and this is likely preaching to the choir here-- but software engineering is so much more than coding. And coding was never actually the bottleneck. We're talking about a hugely complex here. To get the true benefits, we need to really recognize two more things. First, we need to think about AI for the entire software development lifecycle and, indeed, the entire product development lifecycle. We need to think about AI way beyond code generation. Second, this isn't just about applying AI to the old ways of working. The magic actually happens when those traditional processes, they're evolved and even transformed. We're going through multiple paradigm shifts. We're seeing totally new processes emerge with totally new people taking on new roles in the software development lifecycle. So I go back to the question that we introduced at the start. This is a lot of change to deal with. Well, hopefully, today, I've got two pieces of good news for you. The first is however you are feeling, trust me, you are not alone. There's a lot of research on this, both inside and outside of Google, and there's a lot of really complex emotions emerging. None of this is surprising given the size and the speed of change. The excitement is real. The opportunities are real. But it is a lot. The second piece of good news is that this talk is really about how you can rise above all of this and continue to thrive in this AI-native era. There are no magic wands, but there are ways to thrive. We're seeing strong evidence that despite the new shape of the software engineering role, when the change is approached intentionally, this really can and should be the most exciting time to work in this field. NICOLE FORSGREN: Thanks, Andrew. OK, so let's talk a little bit about the patterns that we're seeing in our highest-performing engineers that are really adopting an AI-native approach. Here we'll introduce some interesting behaviors that we're seeing emerge. And then we'll pull it all together to talk about this really expanded role of software engineering. As Andrew mentioned, our job is to really study and measure the engineering system and all of the pieces that fall within that. So we're measuring end-to-end time, how long it takes to go from an initial seed of an idea of the way to getting that idea out into a real user's hands. So here we're thinking about not just software engineering and coding but actually the entire product development process. In that system, our most productive AI-native engineers, they're doing a few things differently. We'll go through five patterns that we're seeing emerge. First is that these engineers are operating at higher altitudes. They are combining their engineering knowledge, but they're also applying their understanding of business context and user needs. They're thinking deeply about why they're building it, not just what they're building or how. Now, if we think about this, this has always been what's expected of senior engineers. But now that we have AI accelerating execution, doing it well has never been more important. Second, they're shifting left on intent. I know some of us have heard this at the conference today. Now, traditionally, shifting left meant moving testing or security earlier into the software development lifecycle. But today, we have more and more work being handled autonomously by agents. So now we need to shift left on intent. We need to spend more time upfront and energy to really plan, explain these clear instructions, talk about trade-offs, provide the right context. What this means is that a fundamental source of truth is moving away from the code itself. And it's really shifting toward the structured intent that happens upfront. Our engineers are writing specification files, which, if we think about it, is really product thinking made explicit. This helps better guide our AI, but it also documents the decisions much more explicitly than some of us have done in the past. And this is critical because as agents are taking on more and more execution, they need to know these trade-offs and these decisions as they're building. I know that building without capturing intent is really tempting-- it's fun to do on a weekend, maybe. But we risk having prototypes that no one understands the rationale for. So when we actively organize this continuously evolving knowledge, that's one strong strategy to prevent severe cognitive overload. Building on the point before that I just made, our top engineers are not vibe coding. They're not just prompting for code. What they're doing is they're designing environments. They're setting guardrails. They're creating systems so that agents and humans can work together toward a goal and a broader purpose. Think of this like creating a system of reasoning so that we can operate at scale beyond what one person can do. So this also includes now setting up agents, teams of agents, giving them the right context, giving them the right skills to be able to act. Our top engineers-- I know someone else mentioned this in another session. They don't just want fast code. They want verified, high-quality code. So when we delegate to these teams of agents and we're delegating this execution, how do we keep the bar high? How do agents know when to act and even where to debate each other to find better solutions? So this all comes from the second pattern and the specifications and intent files that we just discussed. And even though we're shifting left on intent and capturing this and specifying it early, feedback loops are really important to this process. Next up, AI isn't just changing the way that people build but who can build it. It's really decoupling a person's job role from the types of things that they can do in the tasks they perform. We're also seeing the rise of a micro-team, small cross-functional agile pods. These have less communication overhead and much tighter collaboration loops. These teams can execute at really large scale and good velocity thanks to the agents that they're using and deploying. But again, this is only possible if we shift left on intent because that helps us master the delegation to agents. We have to clearly articulate the context, the constraints, the goals, the trade-offs, the success criteria so that the agents can handle how and not repeat mistakes or keep iterating and creating things they've already learned about. So we also need to design the system so our agents can access the right tools, navigate data, and then iterate with you moving forward. The fifth and final pattern is really about having a scientific mindset and how we all need to continually explore. If we're going to work at the cutting edge, we need to be open to failure. Things are moving so fast it's rarely right about-- the idea's rarely about getting it right the first time. It's to learn what we can as we move and then iterate and contribute up into a learning organization. Now, every week, our engineers are experimenting with new approaches and investing in codifying that learning back into the system. Again, intent and feedback loops here are key. It isn't a scientific mindset if we just randomly explore and we never capture and apply those learnings. So pulling this all together, we're talking about shifting left, shifting up, and system design. Now, system design includes the environment, the actors in that environment, humans, agents, and tools, and of course, the culture that ties it all together. This lets us focus our efforts on the most important problems to really learn and adapt as quickly as possible and then execute effectively while feeding insights back into the system. OK, so we just talked through five patterns that we're seeing during this shift. And if we go back to the goal for today, we want to put that together into a way of thinking about the core skills that we need to really thrive in this AI-native era. We will repeat ourselves a few times. But we really want to help connect the dots and emphasize some of the things that we're seeing in this evolution. As we mentioned, our top performers are increasingly T-shaped, and the idea of a T-shaped developer isn't new. We've heard of this before. Yeah, we're quite familiar with it. We are seeing a few things emerge, though. Now, for those who haven't heard of a T-shaped engineer, the basic premise is that this top bar, the horizontal bar of the T, represents a broad foundation of knowledge in the wider, software engineering ecosystem. It doesn't mean we have expertise in all areas, but we have a good understanding of how key parts of the system work. And then, the vertical stem of the T represents the deep, specialized knowledge and hands-on expertise that a software engineer has. It can be within a specific field, like fintech. It can be on a particular technology stack or framework. But that's our deep expertise. What we're seeing, though, is an interesting evolution of this T-shape. First, there's a new layer of horizontal expertise that we need. And that is really about effectively working with and engaging with AI. It's non-negotiable that AI-native engineers can really understand the constraints of AI in a task-specific context. We need to be able to assess the outputs and the quality and ultimately steer AI effectively. We're also seeing some additions on the wings of the T here. We're seeing some more breadth required. Because AI has this lower barrier to entry, and it's really increased the throughput of coding, it's more important than ever to understand this context. So on one arm, we have adjacent engineering. Because AI is creating more and more functional code, the key considerations and trade-offs that we're making need to be at the forefront of what we're thinking about here. The second area here is adjacent non-engineering. And specifically, this is about business and user context. Because now AI can handle how of coding, we need to make sure that we are thinking about and understanding the business and contextual needs that we're solving for. I think one thing that's interesting is that this is already what's expected of our senior developers. We've talked about this a little bit. But now that our engineers are working at higher and higher altitudes, we can do more with agents. So the difference here is really that, A, there's a fundamental assumption about using AI effectively. And B, for a lot of the reasons that we discussed, AI makes the depth and breadth needs a little more acute. We notice them a little bit more. We need that adjacent knowledge. We need the depth of technical knowledge. Otherwise, AI can just make us do wrong things faster. ANDREW MACVEAN: Awesome. Thank you, Nicole. With us so far? So far, so good? OK, we're going to unpack the model a little more. We're going to move through each of the T-shaped skill domains. And for each, we'll give you a few stories, a few anecdotes from inside of Google. We want to really emphasize a few things. First of all, how things are actually playing out today, what we're learning, and really make clear the importance of the entire T shape. We'll then pull it together by sharing some of those practical tips we mentioned that really help you acquire or embody the behaviors and the recommended practices. OK, let's start with core software engineering skills. And to understand how these skills are evolving, I want to share a story from our search organization. Right now, we have product managers who are shipping features all the way through to live experiments. Now, they aren't writing traditional code. They're using some of our internal platforms that help translate their intent-- that's the user or the business need-- into working features on our real production tech stack. Now, from the outside, you could think, hey, if PMs are coding their way to production, what role do those traditional core software engineering skills actually play? The reality is, none of this is possible without an incredibly advanced platform. The deep expertise in system architectures, the different strands of different language frameworks, they're all baked into the platform, as are the scalability requirements, the reliability requirements, et cetera. Now, this to me, this is a really nice example of how the engineer is working higher and higher up the abstraction stack. The engineer isn't handcrafting those individual features. They're precision engineering the ecosystem that allows those features to exist safely. Now, that requires more engineering depth, not less. So given this general trajectory, let's talk about three concrete shifts we're seeing around these skills. First, because code generation is happening faster and faster, effective verification, it can become the bottleneck. AI can act as a massive force multiplier, but you must possess the deep expertise required to evaluate, integrate, and maintain its output. However, given the scale at which AI can operate, this is not necessarily about manually verifying each line by line. This isn't possible cognitively. It's about setting those effective feedback loops, ensuring that you catch issues reliably and in low-stakes environments, and using that data to ensure that you, as an engineer, your attention gets put on the highest value, most necessary things. And so our internal platforms, they're really designed to allow us to quickly test out features, gather that performance data in a safe way, and use these feedback loops to really target engineers where their expertise is most required. That's where they're then brought into the loop. Now, this leads us to our second point. And Nicole mentioned this already. Our engineers, they don't vibe code. They control. They're really precision engineering. If you lack deep engineering understanding, if you don't understand the systems you're building against, AI can run the risk of generating technical and cognitive debt at an incredibly fast rate. This is why our teams, they've been working on these internal platforms. They make development go from intent to functioning, high-quality, reliable, and secure code. Our engineers, they're thinking about setting the boundaries and the guardrails of the system. So, for example, they're specifying the nuanced style guide conventions that the agents must adhere to with the right checks and balances to detect when the agents start to drift. Now we know some of these models, they have a tendency to sound incredibly confident. We know that, when they're operating at scale, it can be all too easy to just accept changes wholesale. There's a saying I like-- delegate tasks, not judgment. It's essential that it's your core engineering skills that are what push the model in the right direction. Again, this is about creating the environment-- the system where issues can be caught and remediated with minimal risk. What we don't want is intellectual passivity. That's why the feedback loops are so important here. It's about getting end-user feedback, performance feedback, and using that to measure adherence to the intent. Observability is critical so that we can establish where guardrails may be missing, or agents are making incorrect assumptions because they don't have the right context. OK, so it's easy to stand up here and say, maintain your deep expertise. But how do you actually do that in this fast-moving, ever-changing environment? Here's three practical tips that our top teams are really embracing. First, we really recommend re-implementation as a learning tool. Because AI can generate solutions so quickly, don't just accept the first draft. Instruct the AI to tear it down and re-implement it. Ask it to document its logic for why it approached it differently and what it learned in the process. This is incredibly useful for checking those initial assumptions, seeing where context may be missing, and thinking through the implications of different approaches. Second, we encourage our teams to do walkthroughs of alien code, system architectures, and agent decision traces. We have engineers explain the code or the systems that they did not write themselves in order to help build the shared mental model and the theory of the system we know to be so important. Now, analog approaches, they work incredibly well here. And so we've actually seen teams adopt more and more whiteboarding to help articulate that logic in the system. For us, code is increasingly not the first-class outcome. It's adherence to that intent, your ability to hit those business and end-user goals, and a shared understanding of the system which should be a deliberate deliverable. Third, I'm sure you've all seen the increasing practice of using skill files, rule files, et cetera to really explicitly codify team practices, expectations, and institutional knowledge into your agents in a consistent and scalable way. And this is something we've seen become increasingly important. We're talking about ways to context engineer at scale with greater reliability. Our best teams, they don't just use agents out of the box. They're creating, they're curating, and they're maintaining structured agent role profiles, giving them very specific behavioral attributes and providing them with the recipes to effectively work inside our system. Again, being forced to consistently reflect on what good looks like-- what is a good behavior from an agent? That's a really good way to remain sharp in your core engineering skills. It ensures you have an up-to-date understanding of the system you're trying to build, and that you're creating those feedback loops to know what is working, what's not, and how to make your agents more effective. Now, importantly, these skills, the rules, the system specs, they should be treated like you would other code, with appropriate version control and observability practices in place. NICOLE FORSGREN: Thank you. OK, next, we'll talk about GenAI use. We want to share a little bit more about how our engineers are working with AI and how they're building the right systems so that their AI can be effective. Here, we're really moving beyond an era of AI enhancement to AI-native engineering. This is a big mental model shift from being a conductor of a single agent to really an orchestrator of an entire system. So here, we're seeing three principles emerging. Our orchestrators are managing teams of asynchronous AI agents. Each has its own context window. Each has its own specific area of responsibility. And then, the human software engineer above is the one who sets the environment and directs the flow. Our engineers are directly and indirectly teaching agents how to act by giving them the skills that Andrew mentioned, which is essentially giving them the exact recipes and tools and domain knowledge that they need to execute their tasks. This shift to orchestration is a new skill. We need to know when to delegate and when not to delegate. Our top teams really help avoid this automation trap by establishing clear human baselines for their work and measuring the verification overheads. To help climb to a win, we run experiments, and we find the tasks where the probability of success is the highest. This allows us to keep human attention on the tasks that we know agents can't yet perform or where taste and judgment is really essential. Because evaluation cost is a new critical bottleneck, our engineers are having to deeply engage with their system thinking skills. Where we don't see enough success, we start analyzing agent traces and we build a shared understanding of where our system can improve, whether it's something like the usability of tools that the agents aren't using or the skills that agents themselves have been equipped with. One example is adversarial review agents. Here we're seeing engineers deploy these to push at decisions and push at their edge cases. Traces are documented, and the intent and agent rules are then updated because we learn from what we've done. None of this is possible without a deep understanding of the underlying software systems, while also having the AI skills that understand the strengths and weaknesses of the model and of the agents that we're working with. Inside of Google, we're seeing substantial growth in the amount of code that needs reviewed. And so we're building code review agents. Their goal is to evaluate functionality, reliability, performance, usability, security, and even maintainability. Our goal is not to replace human code reviewers with AI but, rather, create tighter and tighter feedback loops. We want to catch as many issues as we can as early as possible. We want to feed those issues back into the system, for example, documenting where incorrect assumptions were made, all while preserving human cognition for these high-value tasks. So that's why we started creating shepherding agents. These agents guide changes through our CI/CD pipelines. They trigger review agents multiple times. And then, they also leverage risk assessor agents that scan in-flight changes and flag high-risk changes for human review. Of course, I come back to the need for software engineers to delegate tasks, not judgment. I think we share that as a favorite quote. Our software engineers are playing a critical role here. First, they help define expectations around topics like usability and maintainability. What do we even mean by these things? How does it differ team by team? How is it contextually specific? Second, there tend to be trade-offs between these constructs. In which situation do we prioritize performance, or do we prioritize usability? Applying this requires human judgment and taste. AI can help inform us. It can help surface the risks in the trade that we're considering. But ultimately, the judgment comes from the human. So how can we upskill ourselves to work more effectively with agents? And maybe more importantly, how can you help your organizations and your systems be ready to embrace these new ways of working? First, we strongly recommend upskilling on evals. Because verification is such a big bottleneck, you need to be confident in how you evaluate AI output. The whole of the T-shaped engineer is essential here because it really requires a mix of AI, software engineering, user and business skills to make sure that we're developing realistic, grounded, and relevant evals. Our evals are also a critical artifact to ensure shared team knowledge, and they're a big part of how intent is captured. They help us define what good looks like. Second, our top engineers are not just doing personal self-reflection, but they're forcing their agents to constantly reflect and document. We think about this a little bit like agent journaling. It is fascinating, at the end of the day, to see how my agent perceived its day-- where it got stuck in the system, where it got confused about instructions, where it felt productive. These reflection journals give me insights and give all of us insights into how we can improve, not just how we work with AI, for example, giving it clear instructions on what language or framework to use. But also, we can improve the entire ecosystem around the agents. For example, if your agent is consistently having difficulty accessing an internal tool, you might have a tool usability problem that's worth solving. Third-- and I know we've said this a couple times already-- we want to build teams of agents. Now is the time to really lean into the opportunity to scale beyond a single agent to a balanced team with strict rules and protocols. We're doing this right now inside of Google, for example, with some migrations we've been doing around TensorFlow. This is highly complex, delicate work. Instead of using a single chatbot, our team deployed a strict three-agent architecture-- one, a planner agent that generates verifiable migration steps; two, an orchestrator agent that groups those steps; and then, finally a coder agent that executes them. Our top-performing teams scale beyond single agents by codifying their best practices, for example, around stylistic rules and coding preferences. In the TensorFlow migration example, different playbooks are fed into the agents to ensure a migration in one product area, like YouTube uses YouTube-specific practices. Another thing to consider here is agent sprawl. For example, some argue you should stick to three to five agents so you can meaningfully track the work. I think we're generally aligned with this as a sweet spot. But we are seeing more and more tools emerging to support multi-agent system management with an increasing number of agents. And we think some of the techniques we've discussed here can help you with that additional scale. This leads to our final point. We can't rely on vague prompts and expect high-quality outcomes. We need precision engineering. Here is where we're seeing spec-driven development, where product thinking and architectural decision-making are showing up, and they're being documented upfront, and they're increasingly important. Goals, constraints, rationale-- these are critical contexts, not just for the agents executing the tasks, but really for the broader team. The specs, when we combine them with agent roles and skills, are a source of truth for what and the why of the system that you're building. Here they're documented to guide agents at scale that support system understanding and maintainability. ANDREW MACVEAN: All right. So we've really implicitly talked about the agent-adjacent skills a few times already because, really, all of these capabilities, they're interacting with each other all the time. Take the review agent as a clear example of combining all four. But let's now move to the adjacent engineering wing. And this is where domains like cybersecurity, privacy, and industry-specific regulations, as well as deployment infrastructure, become so important. If your organization has high-quality internal platforms, strong APIs, clear, well-documented workflows, AI really acts as a powerful collaborator. But if you suffer from fragmented tooling, siloed data, and maybe fragile infrastructure, AI is maybe not going to save you. It'll simply help you generate technical debt faster. There's some wonderful research that our DORA team did that really speaks to this point. AI is an amplifier, and it is a mirror. It magnifies those existing strands while it holds up a mirror to those weaknesses. The adjacent engineering wing, this is where AI is most likely to introduce quiet, catastrophic debt if it's left unchecked. And so let's talk about three principles to help mitigate this. First of all, our story of the search PMs, it's highly relevant here too. Embedding those best practices directly into a high-quality internal platform, that's what allowed us to get those features out without handcrafting each line of code. That requires many, many adjacent engineering skills, for example, understanding the deployment environments, the security needs, reliability needs, as well as those deep core engineering skills that we've already discussed. One of the statistics we're most proud of is that while we are seeing increases in the amount of code being written by AI, we have not seen any measurable increase in outages or decrease in system reliability. What we want is 10x the velocity without 10x the risk. One way that we've achieved this is by creating tiered risk environments. We recognize that different applications, they have different environmental needs. For example, an internal Google application doesn't need to scale to a billion users. So our goal is to get from a prototype all the way to production in a more incremental and iterative fashion. We're moving through these different risk profiles and, in the process, really containing the blast radius while still achieving faster and faster feedback loops. This also speaks to other adjacent engineering skills, like effective experimentation. When features are moving through your system faster and faster, how do you actually get them out to users in a way that isolates the features appropriately and allows you to measurably understand how they're performing? Thinking through these environments, the critical architectural and deployment considerations, this is becoming increasingly important for our engineers to engage with. So how do you actually build these muscles? Here's four tips we're seeing our top teams embrace. First, we highly encourage a culture of blame-free postmortems. To build truly resilient systems, you need to make a habit of documenting, reading, and, importantly, discussing outages and incidents. This really builds your intuition for those edge cases, scale limitations, and the reliability threats. It's also invaluable context as you think about how to steer and guide your agents. So for example, triangulating these postmortem documents with an agent's self-reflections that Nicole discussed and observability traces, that allows you to see where the edge cases may be getting exposed or your system instructions may be unclear. Second, don't just use AI to build. Use it to stress-test. So going back to our points about balanced agent rules, explicitly setting up red team agents allows you to see your system through the eyes of malicious actors. Having your agents explain how they would exploit the system, that forces you to engage with those exploit mechanisms. Rather than just passively accepting solutions, you begin training yourself and your agents to spot the vulnerabilities that your generation agents may be missing. Now we covered this already is the really interesting rise of analog approaches to map systems and of course, data maps too. Whiteboards really are at a premium, with the real focus on thinking through those initial architectures. By manually tracing a pipeline, you can build mental models of things like enterprise compliance before a single line of code is actually written. Codifying that intent on a whiteboard is a great way to challenge those initial assumptions and ensure that your agents have the right context going into execution. Finally, observability really is a critical piece of the puzzle. If features are hopefully moving through your system at 10 times the speed, you need to be able to monitor those to understand how things are actually behaving in the wild. We found, for example, that some of our earlier-career engineers, they were getting blocked by opaque performance metrics, really subtle system health regressions. They didn't know how to diagnose the complex distributed systems that they were deploying to. And so what we did is we invested more in observability tools and unified data agents. And the data agents, they had access to code, error logs, performance data stack traces. And what we found is that we were able to empower those engineers to better interpret and understand the complicated systems. This, to me, is another nice example of not just using AI to build but using AI to understand. OK, this brings us to the last capability in our T, and that's adjacent non-engineering skills. This is all about deeper alignment with user and business needs. Now the agents are able to handle a lot more of the routine task execution, our engineers, they have the mandate to focus more heavily on what and the why. But we acknowledge for many of us, this is an uncomfortable shift. Our DORA research highlighted that many developers were facing a real identity threat. Because we've historically derived so much value from the sheer craft of coding, we need to really deliberately shift how we think about and measure our worth. We have to lean into the broader value of our work. That comes from solving real human and real business problems. Our engineers, they're increasingly acting as value translators. They're taking those user needs, the business needs, and they're turning them into precise requirements. Consider a feature request to improve performance. And AI might be able to find and refactor an inefficient loop. But a value translator, they first ask, improved performance for whom and under what conditions? They might look at metrics and user feedback and find this specific user segment that requires the change. They then guide the AI to optimize the critical code paths that actually affect that specific scenario. Here's another example of where human taste and judgment are really essential to point the AI resources in the right direction. I really like this quote from Peter Senge. "The most effective people are those who can hold their vision while remaining committed to seeing current reality clearly." This perfectly captures what we're talking about with the T-shaped engineer. They have the ability to form that broad vision, thanks to these adjacent skills, but also intimately understand the technical reality, thanks to that engineering depth. They use the systems and the practices that we've talked about today to capture intent, maintain understanding, and ensure we never lose that context of the current reality as we build. Now, of course, we're here today to talk about the T-shaped engineer. But software engineering isn't the only discipline becoming more T-shaped. We're seeing the exact same evolution in our product managers, our data scientists, and our UXers. We shared the story earlier about our search PMs. Now, while it's the software engineers that built the safe, reliable platform, of course, the PMs, they too are extending their adjacent skills. They're not waiting on a designer to hand over a static [? mock.?] They're going from an idea of the way to a working system. This allows us to create more nimble and more fluid teams. Now each discipline, they still have their specific strengths and role to play, but the boundaries are starting to blur. For example, in one of the internal tools I work on, PM, UX, and engineer, they're all shipping code. Now the big problems, they're still working on together, but something like a UI papercut that maybe sticks out more to a designer. That designer is just going ahead and fixing and shipping the code themselves. And that, to me, is the true power of this T-shaped era. OK, we could spend a whole hour on this topic, but here's two quick tips we're seeing teams embrace. First, avoid the temptation to have AI synthesize all of your user feedback. It's incredibly tempting to just dump hundreds of user feedback logs into an LLM and ask for a summary. I think, if done properly, there can be space for this. But much like we're seeing an increase in analog whiteboard sessions, we're also seeing an increase in traditional high-touch user feedback sessions, and our engineers are really enjoying being deeply involved. Hearing the actual joy or the actual frustration in a user's voice, it builds profound empathy, and it really makes the why behind things more real. Second-- and we've mentioned this a few times-- is spec-driven development. Really treat your spec as the ultimate product deliverable. Our best teams, they are fiercely protective of these specifications. A lot of their cognitive energy goes into debating the goals, the business logic, and the edge-case constraints. Forcing this clear articulation early and in the open has really ensured teams get aligned on the why and helped agents have access to the more nuanced institutional knowledge. Remember when everyone can prototype at lightspeed, taking a few moments to capture intent really prevents exploration from just turning into chaos. And because we treat these specs like code, tools like the review agent that we mentioned, they can really be used to stress test requirements or look for logical collisions before the execution has begun. NICOLE FORSGREN: OK, now we're going to pull it all together. When we combine the deep expertise that we need to catch AI's mistakes, the skills that we need to orchestrate the fleet, we have our adjacent engineering so that we can understand the system, and our non-engineering to really give us that broader context. That's what we're seeing it takes to thrive in an AI-native era. Here, we're talking about possessing the skills to capture and translate knowledge in a way that preserves signal-to-noise for both humans and agents so that we can have that virtuous improvement system. Hopefully, the framework and capabilities and patterns that we've shared give you a useful way to think about your role or give some inspiration for things that you can try. We also want to talk a few minutes to speak to the engineering managers and leaders in the room. Engineers do not work outside of an org, and we don't work alone. So that's what we focused on so far. But the hard truth is, you can't mandate a T-shaped developer inside of a broken system. As our DORA research shows, and as Andrew mentioned, AI can be a harsh mirror reflecting all of our weaknesses as well as our strengths. If we have well-aligned teams with strong practices, AI can accelerate value delivery. But if you have fragmented tooling, siloed data, or especially a culture of blame, AI won't save you. It is simply going to expose all of those bottlenecks. I love this quote from Deming. "A bad system will beat a good person every time." Right now, we're asking engineers to really focus their attention on some of the hardest architectural decisions. We're asking them to verify machine output and then context switch all the time between multiple agents. This can really be cognitively exhausting. 10x output cannot come with 10x cognitive load, or that will burn people out. So as a leader, how can we create an environment where our engineers can safely evolve, so that our engineers can embrace the expanding T-shaped role? We recommend three immediate shifts. First, redefine how you measure productivity. We have to stop measuring our teams by pull requests, throughput, or lines of code accepted. We should reward outcomes and business needs that are met. We need to focus on the right outcomes with a balanced understanding of value. For example, if we measure only speed and never quality, our developers won't take time to rigorously verify AI's output. And then system instability skyrockets. We recommend a balanced portfolio of metrics. And there are a lot of good resources out there to get you started. Second, actively protect this productive struggle. We have to carve out dedicated time during work hours so that our devs can learn these tools and understand the systems that they're building. Encourage them to manually do architectural walkthroughs or experiment with a new tool or approach so that they can learn how tools handle different problems differently. If you don't give them the space to build these important mental models, your team will just drown in cognitive debt. Third, foster radical psychological safety. We're in an era of experimentation. Your teams are going to build agentic workflows that fail. If your culture punishes those failures, developers are going to rely on the skills that they have and their old, safe ways of working. We need to celebrate intelligent failure, create blameless postmortems, so that the whole team learns from the mistakes that are happening in the system. Now, all of this has always been true, but we've said all along, AI is really a mirror and an amplifier. We want to conclude by explicitly acknowledging and re-emphasizing just a few things. Managing an agent workforce while architecting complex systems could sound exhausting because it forces us to stay exclusively in this high-altitude decision space. The silver lining is that while the nature of our effort is changing, we still have that joy of building. By investing in the expanded T-shaped developer skill set, you get to see your ideas come to life at unprecedented speeds, and they bring you closer to the actual software that you want to create. You aren't leaving behind the craft of software engineering. You're simply stepping up to its highest and most impactful level. And most importantly-- I know we've said this, but it's worth reiterating. The software engineering role is not vanishing. It's simply evolving. And if anything, it's becoming more important. So we need to shift left. We need to shift up. And we need to think about designing systems, not just bits of code. So thank you. [MUSIC PLAYING]