Raw capture — raw/ytx-building-world-class-engineering-teams-age-of-ai.md

url: https://gist.github.com/5a3168d465667b77688dd74ba9b03271 date_fetched: 2026-07-05 backfilled: true

You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert

AI-native teams start with mindset, not just tools. Rajeev stresses that teams must “really believe in doing AI native work” and working with agents. Some Atlassian teams still code traditionally, but AI-native ones write “zero lines of code” manually—everything is orchestration of agents.

The bottleneck is shifting left and right of code. With coding becoming “free,” the hard parts become planning/specking (left of code) and deployment/incident resolution (right of code). Atlassian is re‑tooling the entire SDLC around this.

Roles are collapsing into overlapping Venn diagrams. PMs are becoming product engineers, designers are becoming design engineers, and the distance between PM, design, and engineering is shrinking. Thomas: “The product manager is becoming a product engineer and the designer is becoming a design engineer.”

Productivity gains are real, but the point is creativity, not headcount reduction. Rajeev reports PRs per engineer up 89%, issue cycle time down 42%, 51% of security vulnerabilities caught by agents. Yet the goal is “what can you create now with AI that you could not create before” and “how can you have that much more joy?”

Context is the magic ingredient for agent performance. Atlassian’s RoboDev beats Devin on SWE‑bench by leveraging the “teamwork graph”—who works with whom on which PRs and Jira issues—to give agents rich context.

Distributed teams get a new advantage from agents. Thomas argues agents act as always‑available “pairing partners” for brainstorming, code review, and research, evening out the competitive disadvantage of remote work versus in‑office whiteboarding.

Engineering leaders can code again, and span of control will increase. Rajeev sees leaders reconnecting with code via agents. He predicts flatter orgs with managers having 20–50 direct reports, fewer management layers, and less pure “leadership management.”

Token costs invert traditional budgeting. Thomas warns that as developers get more productive, flexible token costs skyrocket, creating pressure to slow down some developers—a problem large‑company managers must solve with finance.

Coding is fun again. Both speakers emphasize that agents remove drudgery (build errors, unit tests, boilerplate) and bring back the joy of building, especially for hobby projects and rapid prototyping.

Pithy and provocative quotes

Thomas on the gap between AI hype and daily reality: “If you hear that in podcasts, I’m like, sure, sure, sure. … in theory that is my life, but in reality … I got like hundreds of emails from investors … I’m looking for the agent that solves all that for me instead of just trying to figure out how can I be both nice human to give them a response, but also let them know that I’m not interested in that conversation right now because I want to build a company.”

Rajeev on the real promise of AI: “The discussion about using AI to produce more efficiency and maybe smaller teams and fewer engineers is missing the point. It’s more about what can you create now with AI that you could not create before and how can you be that much more productive and how can you have that much more joy?”

Thomas on the absurdity of AI‑native markdown collaboration: “We’re going to use cloud code or some agent to build code, but no, we’re not going to feed Markdown files into that like 3,000 software engineers all collaborating on markdown. That is a nightmare. … programming language is great. It reduces vocabulary on like 20 words that everybody can speak.”

Rajeev on context as the secret sauce: “Agents are as smart as the context you give. And in Atlassian we have built what is called the teamwork graph … that context really helps Robo dev do a much better job.”

Thomas on the Homer Simpson car of agent‑generated features: “What you get is the Homer Simpson car. Because all the ideas you had without any process and any creativity and product management and whatnot leads to products that have lots of features that look like Homer Simpson.”

Rajeev on career advice for engineers: “Anytime somebody asks me about career path as an engineer, the first thing I tell people is don’t be a manager.”

Thomas on the CTO of Atlassian buying his own laptop: “Every time an investor asks you how they’re preventing the incumbent doing the same thing that you’re doing, just tell them that the CTO of Atlassian had to buy a laptop on his own money to start coding.”

Thomas on the joy agents bring back: “Coding is fun again. … I think what agents have done is it bring us back to the joy of coding.”

Tools, practices, and methodologies

RoboDev (Atlassian’s internal coding agent): A coding agent used across the entire SDLC—code generation, code review, CI/CD, incident resolution. Built on Anthropic’s model but beats Devin on SWE‑bench by leveraging Atlassian’s “teamwork graph” for context. Used by all Atlassian engineers.

Teamwork graph: Atlassian’s internal knowledge graph that maps who works with whom on which PRs and Jira issues. Provides rich context to agents, dramatically improving their output quality.

Confluence for left‑of‑code speccing: Engineers and PMs put intent, specs, and comments into Confluence; agents read those comments and run RALPH loops to generate code. Shifts the artifact of record from code to the spec.

Loom (video messaging): Used to express intent and thoughts via video, which is then fed into AI agents to produce better artifacts. Part of Atlassian’s push to move beyond text‑only specs.

Cursor Composer: Mentioned by Thomas as a tool he used to generate a cookie policy implementation in a React app in seconds. Example of an agent that handles non‑coding tasks quickly.

Devin (Cognition AI’s agent): Referenced as a coding agent that some CTOs use overnight to build features, then check in the morning. Symbol of how leaders are re‑engaging with code.

Replit / Lovable: Low‑code/no‑code platforms that PMs, marketers, and assistants are using to build prototypes and automate parts of their work, blurring the line between builders and non‑builders.

Codex Mac app (OpenAI): Thomas used it to build three native Mac menu‑bar apps in SwiftUI without looking at the code. Demonstrates the speed and accessibility of agent‑assisted development.

AI‑native SDLC: Atlassian’s holistic approach: ideation → coding → deployment → production, all augmented by agents. Not just a coding assistant but a rethinking of the entire lifecycle.

Verification over inspection: Instead of line‑by‑line code review, teams are shifting to verifying inputs/outputs, guardrails, and system behavior. Code review bots may eventually negotiate directly with coding agents, removing the human bottleneck.

Forcing yourself not to look at the code: A practice Thomas observes among AI‑native developers: they start greenfield projects by voicing intent through prompts and reasoning, deliberately avoiding reading the generated code to build the skill of managing agents.

Unanswered questions and omissions

How do you manage token costs at scale without stifling productivity? Thomas flags the inversion where more productive developers burn more tokens, forcing managers to potentially slow them down. No solutions are offered—just the problem statement.

What happens to junior engineers when senior engineers become “masters of agents”? The talk focuses on up‑leveling existing engineers, but doesn’t address how juniors learn fundamentals, develop taste, or gain the context needed to effectively prompt and verify agents.

How do you ensure quality and security when humans stop reading code? Rajeev mentions shifting to verification of inputs/outputs, but the specifics of guardrails, testing strategies, and what “verification” actually entails in an agent‑driven pipeline are left vague.

What about the legacy codebase problem? Rajeev admits agents struggle with complex projects on old codebases and that “we’ll get there very soon,” but no concrete approaches for bridging that gap are discussed.

How do you prevent the “Homer Simpson car” when agents auto‑merge and auto‑deploy? Thomas raises the risk of feature bloat without human curation, but the talk doesn’t explore process changes (e.g., how product management adapts) to prevent this.

What are the implications for team morale and culture when roles collapse? The blurring of PM/design/engineering is presented as positive, but potential friction, ownership confusion, or resistance from specialists isn’t addressed.

How do you handle the language and communication barrier when prompting in English? Thomas notes that non‑native speakers struggle to describe features in English, making markdown‑based prompting a “nightmare.” No mitigation strategies are offered.

What does the career ladder look like in a world with fewer managers and flatter orgs? Rajeev says “managers and leaders, it’s a little tougher” and there might be fewer of them, but doesn’t sketch what advancement looks like for those who don’t want to stay pure ICs.

How do you maintain institutional knowledge when code is generated and not deeply understood? The shift away from reading code line‑by‑line raises questions about long‑term maintainability and debugging when the original human intent is buried in prompts, not in the code itself.

What about the ethical and legal dimensions of AI‑generated code? No mention of IP ownership, licensing, compliance, or bias in generated code—elephant‑in‑the‑room topics for any organization adopting agents at scale.

Speaker A: You know, when we organized this, this event, we just wanted to be the answer. Look, look at the most important questions that we are facing at that time. And this was five months ago. And we thought some of it might be AI, but it turned out to be AI is, is everywhere. So I'm, I'm not going to beat around the bush. The two of you are very similar in many ways. You have not like that. You've run or are running large organizations. You're building brands that developers love and use and are engaged with. Thomas, you're now starting something completely new, so you're also doing something completely different. What is an AI first or AI native team mean to you? And I'll start with you, Rajeev.

Speaker B: Sure.

Speaker C: First of all, Gerge, thank you for inviting me and thanks everyone for coming. The energy here is just palpable. So it's really great to be here and I'm really excited to be talking about AI native stuff. Everyone wants to talk about AI these days, so it's fun. But what does an AI native team look like? Well, first of all, it starts with the mindset. You have to really believe in doing AI native work and, and working with agents and things like that. We have teams at Atlassian Engineering Team, some of which are still doing the more traditional way of coding and building software. Cause we do have legacy systems that take that. But we have a number of AI native teams where engineers are basically writing zero lines of code. It's all agents. It's orchestration of agents. What we are finding is the lines are blurring between PM design and engineering, where PMs are writing code, designers are writing code. This is basically leading to more productivity, generally speaking. And the thing I find is that the teams are not necessarily getting smaller, but they are producing a lot more, sometimes 2x5x more. And the creativity is going up. What you build is much more creative. You can put in screenshots of things and design more modern UX. And then you can also between PM's designs and engineers, the distance is shrinking as well. So that's making for more vigorous conversation and more creativity. I find that the discussion about using AI to produce more efficiency and maybe smaller teams and fewer engineers is missing the point. It's more about what can you create now with AI that you could not create before and how can you be that much more productive and how can you have that much more joy?

Speaker B: I think there's multiple answers to this. Rajeev gave one of them. If I think about the word AI native in the same context as cloud native. When GitHub started in 2008, nobody spoke about cloud native. It is a term that was introduced after the fact, after identifying how all these companies reinvented, how they're deploying and developing systems. And I think the same is going to be true for AI Native. What we're calling AI Native now is going to be very different than what is going to be AI native in a few years. And I have two boys, 13, 11, and most of the time they're playing Minecraft. Sometimes I can also convince them to code, but certainly they are AI native. One day they came home, I think it was a year or two ago, and, and they showed me their cell phones and they had like puppy images on the, on the front, on the home screen. And they use Adobe Firefly to generate these images. And I'm like, how the hell did you find Adobe Firefly? Oh, everybody in school is using it. And I think that's the AI native generation, those that are growing up now with these agents. For them, it will be just so natural to use an agent instead of going to, you know, Google search or trying to find it, to do it the traditional way. And I think if we are all honest to ourselves, you know, there's a lot of sorry bull out there of how all day to day is a native and I'm using agents for everything. You know, I'm a startup founder. Most of the time I'm still dealing with HR systems and my, my month and close and getting, you know, directors of board insurance. And that's a form that I have to fill out. No agent helps me with any of that. And if you hear that in podcasts, I'm like, sure, sure, sure. You know, like in theory that is my life, but in reality, you know, yesterday we announced my company. Since then I got like hundreds of emails from investors that want to absolutely still angel invest into the seed round. People that have 12 years of experience are the best developers on the planet, yet they're sending mean email to apply for a job and I'm looking for the agent that solves all that for me instead of just trying to figure out how can I be both nice human to give them a response, but also let them know that I'm not interested in that conversation right now because I want to build a company. So I think that's the, the crux of AI native teams today in software development. Yes, we're going to use cloud code or some agent to build code, but no, we're not going to feed Markdown files into that like 3,000 software engineers all collaborating on markdown. That is a nightmare. Right. If you have then folks in Germany that speak English with an accent or in Spain or in India and China and whatnot that don't actually are as fluent in English, it's actually an even worse nightmare because programming language is great. It reduces vocabulary on like 20 words that everybody can speak. As soon as you have to describe a feature in a language that you don't actually think in, it's really, really hard. And I think we haven't figured any of that out.

Speaker A: And how are your teams today using tools? How have their workflows changed?

Speaker B: I think the biggest change in the workflow is that basically most developers that start greenfield from scratch today and have used cloud code is that they force themselves to not look at the code and that basically it starts with.

Speaker A: That's happening at your teams, right?

Speaker B: That's happening. I think that's happening everywhere in the industry, like in all the people I'm interviewing, whether they work at Microsoft, GitHub or Atlassian or ThoughtWorks or Block or.

Speaker A: So easy with the poaching there.

Speaker B: Well, they're all coming to me, you know, but all these don't worry.

Speaker C: Thomas Villaguaria.

Speaker B: Yeah, yeah. Well, you know, about a third of our team of my startup entire is Australian because one of the co founders is actually went to high school with me in East Berlin and then immigrated to Australia. And so the Australian press didn't let that opportunity go to shit a little bit on Atlassian yesterday when the announcement came because your stock price is down and whatnot has nothing to do with us. But of course, you know, that's not how the press works.

Speaker C: It's all the sad stuff, you know.

Speaker B: Yeah. Anyway, where was I? Developers, you know, that want to be AI native. What they're doing is try to look at little at the code as possible and force yourselves to figure it out with a prompt and a reasoning process and voicing intent. And then same way with code review ideally I never read the code line by line because that's going to become increasing bottleneck. I have cursor, bugboard or one of these tools point out the mistakes to me and I'm waiting for the moment. And I think a previous session alluded to this that let's just have the code review bot or agent work with the coding agent. Why would you need the human in the middle of that? And I think that's where that the most AI native developers are right now is the ones that have figured out how to do that. And that is a skill in itself. And that's I think answering the question, are we going to replace humans with agents? No, we are up leveling the humans to become the masters of these agents.

Speaker C: Yeah. On tools, I think there's two parts to it. One is that coding and implementation is becoming free to the point where the bottleneck is shifting to what I call the left of code and the right of code. On the left of code. It's about planning and specking and they're increasingly one of the tools we are using. In Atlassian a lot is confluence, because confluence is where the intent and the spec and yes, it's mostly English language and Thomas makes a good point about language, but that's where you are putting in really what you want to build, especially for product oriented engineers. They're going in and putting in a lot of comments and our agents are able to read the comments and go off in a RALPH loop and solve things, which is really amazing. But yeah, left of code and then right of code, it's the standard stuff. CICD deployment, incident SEVs. How do you find that out? So using agents to do that is what we are doing. So I'd say we are looking at it holistically across the entire software development lifecycle. We call it the AI native SDLC all the way from ideation to coding to deployment and production. We are changing the tool set quite a bit.

Speaker A: Okay, what about robo dev? Tell me what robo dev is.

Speaker C: Yeah, yeah, yeah. So robodev is a coding agent, but it's also our brand for doing things across the entire sdlc. So we are using it for code reviews, we're using it for cicd, we are using it for incident resolution.

Speaker A: So you built your own coding agent?

Speaker B: Yes.

Speaker C: Now here interesting thing is we are using Anthropic's model, but in the SWE benchmark we actually beat plot code, which sounds amazing. How do you do that using their model? Well, it comes down to one magic word which is context. Agents are as smart as the context you give. And in Atlassian we have built what is called the teamwork graph, which is who does Thomas work with on which PR on which issue in jira and that context really helps Robo dev do a much better job with the PRs it produces.

Speaker A: What is happening with distributed teams. Thomas, you mentioned that your team is spread across a bunch of different time zones, which is super unusual for early stage startup. Usually the conventional wisdom is like be in the same office, you're going to be Riffing at the each other. Why did you decide to go distributed? And does AI have to do anything with this?

Speaker B: First of all, I want to say, you know, I'm a strong believer of everybody needs to find their own happiness, right? And that's similar to the relationship that you have in your personal life. It's same with the relationship with your company. There is not one perfect approach. And if you want to work in a company that has a beautiful office in San Francisco, great. You want to work in a hybrid scenario, also great. And I love working in remote teams because I love traveling. I love the 247 coverage. If you have people in Australia and Germany and Spain and Lisbon and UK whatever in the United States in different time zones. And that makes my life happy and doesn't mean that anybody else is wrong in how they're running their company. What it does though, is if you have a remote team is that you're lonely. And lonely might be in the kind of like Covid alone at home sense, but also in the who is available for me to ask the question. And it's much easier to do that in an office environment because you can kind of figure out while Google is only, you know, surfing on X and posting and whatnot, and so I can ask him a question and never, never. And in the same time, if you're busy in a conversation with Rajeev, then obviously I won't run into the conference room and ask you, hey, can you do this code review for me? And I think agents basically gave us these bearings partners, these experts that I can just ask and say, hey, I want to brainstorm on this topic. I need to write an ADR or solve a problem. I was over the weekend preparing our launch, so I figured out I need not only terms of service and a privacy policy. I also need a cookie policy. So I was trying to figure out how do I do that in the React app, and I just asked Cursor Composer to do that for me. And it was done in three seconds. And I think that's the remote work. With the help of Agent has gotten a new level that wasn't possible before because I've always somebody available. My code review agent, my coding agent, my brainstorming agent, research agents, all these kind of things. And I think that's for us the huge benefit, especially if you have these launch days right? Everybody in the same time zone in the same office. At some point, you need to go home. That's just the reality. If you have folks in Australia, by the time it's 6pm here, it's like noon or something in Melbourne. And so they're still working and maintaining the engagement on Discord and the open source project. I think in some ways agents have gotten us an advantage again, you know, for being remote first and that, you know, other teams that work in the office together, you know, have on, on their side when, when they can brainstorm in front of whiteboard. So it evened out a little bit of the competitive disadvantage that certainly has evolved here in San Francisco as most of the AI native companies have gotten back into office.

Speaker A: And Rajeev, how are you seeing this? Because you've been, you have distributed teams. Is it changing?

Speaker C: Yeah, well, we have, we are actually Atlassian has been leaning into distributed teams way before, like even before COVID So when actually Covid happened, it was supernatural for us to be in that kind of situation. Our software naturally is for collaboration across distributed teams. That we are not remote. We have offices, we have offices in San Francisco, in Sydney, in different parts of the world. So we do believe in like that intentional togetherness you get when human beings come together and work together. So we're not like a remote, only remote first kind of company. But we don't mandate you coming into the office. We are like, you can work from anywhere, we call it team anywhere. You can work from anywhere. You can work with people. And to Thomas's point, I think agents have changed things a lot. Like, I remember the days when I was in the office at 2am writing code and you get stuck and all you can do is read the code and read the code more until you understand it and figure it out. Well, now you can ask an agent and the agent can explain it for you or even better, do the code for you. So I think with agents it's gotten even better and easier for us to be able to be distributed in this fashion.

Speaker A: And a big thing that we're all seeing, you're seeing it as well, the role of software engineer changing and the role of the engineering leader, the engineering manager changing. From your vantage point, what are you seeing happening so far? What do you expect? And especially looking at Atlassian, are you doing any change in terms of defining the role or thinking about or relaxing some of the things that you've kind of had in place before?

Speaker C: Yeah, we think about it in terms of what changes with respect to ownership, accountability, things like that. Right. And what we are finding is it's less about code ownership, it's more about like, now the artifacts are shifting to things like confluence and JIRA and Even Loom, we have a lot of interaction through a product we acquired called Loom, that's now part an Atlassian product. And you can express a lot more intent and thoughts and video. And so feeding that into our AI agents and using that to produce better artifacts, the ownership is shifting towards that. And then the accountability part is increasing as well. Instead of like a lot of code reviews and trying to understand whether the code is good, which you still have to do when the agents help you, it's about verification, right? What are the guardrails, what are the inputs and outputs that you want to verify so that you know that the AI code is good and that the agents have done a good job? That's where the ownership and accountability is shifting. And so that's how we are thinking about it. But in terms of team structures and managers and PMs and designers and engineers, we aren't thinking. We're not doing like radical changes yet. What we are focusing on is that team structure, that team that's producing the feature, how can they do more? How can they be more creative? We are not going down the path of saying, oh, let's do it with fewer people, necessarily. That's not the biggest thing. In some cases, we do find 10x, even hundredx more productivity, and we then reshape the team for that. But our angle is more. How do you unleash more creativity and how do you do more?

Speaker A: Can you tell me a tiny bit more? When you say you see more productivity of the team and you reshape the team for that, what could that mean? Or what does that mean?

Speaker C: Well, we have tried some projects where we are like, hey, what if we didn't write any code manually? Like, what does that look like? Right? And that forces you to think differently, that forces you to organize the repo differently, that forces you to set up the rules for the agents differently. The agents don't have enough context. When you have a repo with full of code, it can start off in a better place. And so that forces you to sort of really be AI, native AI first. And we're finding that in those cases, we make a lot of progress. You can get real good productivity. But if you have a legacy code base that has been around for a long time, it's not as easy, right? We find that it takes a lot more effort and things like that. And so we have done a lot of progress with Robo Dev, but it's not yet at the point where you can give it a complex project and a legacy code base and I think that's a hard problem that a lot of people are working on. I think we'll get there very soon. But that's an area where you can't go and be as a aggressive.

Speaker B: I have two angles on this. I think one is, you know, we're constantly in this problem that we have way too many ideas in life and way too many things to do. You know, one of my jokes is that when you're single, your Saturday morning is great. You have all the plans for the weekend. When you're married with kids, all the plans that you had on Saturday morning didn't happen by Sunday night because your family determined what you're actually doing over the weekend. And the same is true in software projects. And the way we're solving this is we are writing things down in to do lists and we have moving them into linear backlogs and your backlog gets longer and longer and somebody just throw it all the way and start fresh and bring up the same ideas again. And what we're now doing with agents, we're shifting this one step to the right where we just feed all of that into agents and agents write all the code. And now you have your backlog and your pull requests. And that's the bottleneck now because you can't review all of that. And then there are going to be agents that review all that code and auto merge it and auto deploy it. And what you get is the Homer Simpson car. Because all the ideas you had without any process and any creativity and product management and whatnot leads to products that have lots of features that look like Homer Simpson. I don't everybody has that picture in your head. The flip side of that is, you know that and obviously we need to so that we still need product managers and designers and engineers to actually architect products that are really great. And every time you're using a product that's not great, you know exactly that that's the case. Right. Like it's easier for us to find something bad than finding something good. At the same time, I think we're going to see a massive role collapse between the traditional engineering roles.

Speaker C: Right.

Speaker B: You're not the pragmatic product manager and the product manager designer, but actually think the product manager is becoming a product engineer and the designer is becoming a design engineer and the software engineer stays a software engineer. And so the Venn diagram of these roles is overlapping much more. And I think it was this morning session, or maybe it was the off the record session yesterday, but we're seeing a lot of that where product managers in companies are now forced to, as an expectation of their job, to use a coding agent to build a prototype instead of just writing a document and handing it. Now, that's the obvious part of this, but it's also true for your marketer, for your comms people, for your assistant. All those folks are already using lovable or Replit or any of these tools to actually automate part of their life. And then the question becomes, is it the bad cop like in the. I think it was in the Phoenix project that blocks everybody from deploying, or do we find ways in the organizations to actually let everybody be a builder and contribute back to what ultimately is the goal of every organization, which is as a team, together we are much more powerful than individuals. Right. That's the Dutch trading company philosophy. If you go back where companies come from and we have to find these processes. And I think that's the thing that we haven't really figured out of how in a secure way and trustworthy way, we can ship amazing products by moving much faster through the lifecycle, while at the same time empowering everybody in the company to do so.

Speaker A: And we've talked about this is the engineer role and of course, how the designers and product managers are getting closer to. What about the engineering leader? You've got a lot of outstanding engineering leaders inside Atlassian. How do you see their roles changing? And Thomas, as you're going to be hiring, who would you hire for before, you would have obviously hired for every 10 engineers, like an engineering manager or something like that. How will that change for you? So I'll start with you, Rajeev.

Speaker C: Yeah, I think one of the most exciting things for engineering leaders, including myself, is we can write more code now. I love writing code over the holidays, bought a laptop and. Because sometimes you can't install things because of it, but I bought my own personal laptop at the Apple Store, installed cloud code and built an app, bunch of Python scripts and things like that. For someone who has grown up writing code, my bar for my own code is super high as it is for all my engineers. For me to take time out to go and build a whole new feature, it's a lot of time in the old traditional way, but now I can do it much faster with robo dev, with agents and things like that. And it's always satisfying to go join a hackathon, build something and write code. And so for all the leaders, I think it's like you can get a lot more connected because sometimes as a leader, you go up the chain and then you get more disconnected from code and engineers. And now I think that gap is shrinking. The other thing that's interesting that's happening is the span of control is changing. I've always advocated for the degenerate case of where you have a team of 400 engineers. You take the square root of 400 and you have essentially 20 direct reports each having 20 direct reports. And then it's just two layers of management. But usually most, most organizations have people who have like five or three reports that most degenerate cases. The binary tree, right? Two reports, two reports. Two reports all the way down. But I think the span of controls will increase. I think, you know, Thibaut I think talked about having 33 direct reports. You know, Jensen talks about having 33. Yeah, yeah, yeah. Having like 40 or 50. Yeah. I think like people will have more direct reports and fewer managers and managers will be more connected with the codes. I think all of this is really good thing.

Speaker A: As a follow up, what about the traditional career path? Traditional? Oh my gosh, I'm talking like, you know, like pre, like 20, 20, 22, because we were used to, there was a career path like be a, you know, software engineer, senior engineer, then either staff engineer or engineering manager, senior engineering manager, director, senior director, et cetera. What do you think might happen just in taking educated guests?

Speaker C: Well, first of all, you know, anytime somebody asks me about career path as an engineer, the first thing I tell people is don't be a manager. You know, in fact, I did that myself when I started out. Somebody gave me that advice. And so for the first many years of my career, I avoided being a manager as far as I could until I found decisions being made that I didn't understand. And so then I popped my head up to see, okay, what the hell is happening and that sort of thing, and then joined the dark side. But like, you know, worked out pretty

Speaker A: good in the end.

Speaker B: Yeah, yeah.

Speaker C: But I'd say like, you know, for engineers, like, I mean, it's a great time to be alive. Like I would just write code, use agents, figure this out, do all the advanced, you know, cutting edge stuff for a while. I mean, we don't know where the future is going. But like, you'll be fine if you're an engineer. Writing code. Managers and leaders, it's a little tougher. I think there might be fewer of them. I think it's exciting if you want to be hands on that, it's amazing. I think there's less of like leadership management, blah, blah, blah. It's more of like doing and like figuring things out in this new world. And those who do, I think will do well, those who want to like stick to the old career paths might have to find something else.

Speaker B: I have three things. One, number one for all the startup founders, every time an investor asks you how they're preventing the incumbent doing the same thing that you're doing, just tell them that the CTO of Atlassian had to buy a laptop on his own money to start coding. That's the best answer I can give because it shows you how even, you know, relatively agile companies that actually develop agile tools, you know, can't really do what you can do in five minutes.

Speaker C: I'll fix it once I acquire your company, Thomas.

Speaker B: Or you can get their assets. You can get their assets and use them for coding. Number two is I think what happened in the last two years through coding agents like Copilot, Cursor and Devin is that many CTOs and CIOs even in the largest banks in this country and many other countries have realized they can go back to coding because it no longer takes hours to install all the packages and figure out all the problems. And so I've actually, I have friends in that, in that space that told me stories of like on every night they would give Devin a task and say, Devin built me this. And then on the morning would check it, check in with the developer agent and then keep going that way. And then they have their normal day to day as a CTO of a big bank and you do that for two weeks and you realize everything is going to change and has to change in my organization and in contrast to the, you know, Twilio founders, ask your developer where the developer decides, bottoms up, what the tools are. Those folks went into the, into the organization says, I don't want to hear any excuses, we're going to roll out agents. And you know, many banks still are on very archaic systems and they have developers like Citrix and what have you. And often the CTO was not empowered to override this because of CISO concerns and what have you. And I think that has dramatically changed because we basically can get our hands dirty again and realize how powerful this technology is. And that shift is happening. You see this everywhere. Like no other software development technology has been adopted as fast as agents. Right. Like most German companies, you know, Japanese companies, other international are still not in the cloud because of all the kinds of concerns that they heard from the legal team, secure teams and whatnot. And then there's the third piece. You Know when you ask about leadership and manager, you know, when I became a manager, the first time I became really a manager was when my startup got acquired by Microsoft. Because CEO of a 10 person startup, you're not actually a manager, you're just one of 10 and you're the speaker. And it has to do payroll and pitch to customers. And I became a manager and I realized, oh God, now I have to hire people, which means I have to write a job description and do interviews and I have to write performance reviews. When ChatGPT came out, all of a sudden we just would ask ChatGPT to write the performance review for us. And of course the employees did the same on their side. And if you have worked at Microsoft, the employee has to fill out, I think seven input fields on their side and then the manager has to react to those seven input fields. And if you're a lazy developer manager, you're right, I agree with you. And the employee's not happy about that. And so you kind of hacked that system by just asking ChatGPT, which then in reverse is then give me just the bullets that you put into ChatGPT. So at least I know how you're prompting.

Speaker A: So you became the CEO of GitHub with this mentality.

Speaker B: God does GitHub, you know, the key pragma if you will, or dogma. By the way, we were joking in the green room. I think the next one is the Dogmatic Summit. And so we have all the dogmas on stage. It's much more entertaining. I think it's developers first, right? Developers first is what we always said at GitHub for everything we design, for every process, for the marketing. And when we fail, you can see that a hacker news varies straight right? Like when a GitHub blog post or GitHub tweet or a message is too corporate. Developers won't like that and they don't want to have that. Give me the truth, give me the direct conversation, don't give me all the marketing bull that works for other products, but it doesn't work for developer tools. I think the same is true for being a people manager, an engineering manager of a team. Like your team knows exactly whether you're talking straight to them and giving them the truth or whether you're sugar coating that they're actually not doing so well and you're kind of like trying to give them the message that you either improve or you get the out. And I think this is where the AI is changing this because I'm spending an hour of writing A pretty fight summary of a performance. Of course the engineer just feeds that into ChatGPT backwards and says what did Thomas actually mean and did he use AI to write this and all of that. And I think this is a good thing. Like, you know, when we think about AI driven sales processes, hell, I don't want an AI email from a sales agent to sell me some outsourcing company or something like that. Just I want an AI that deletes all that and tells them to never contact me again. And I think the same is true like for people management. It's so much more, it's so much more enjoyable when you have a relationship with your people, with your team members, your ICs, that's on an honest, trustworthy basis like you hopefully have with your spouse at home and your kids and whatnot. And I think that is going to shift because you can no longer cheat your way as a people manager into being the nicest manager of everybody. While in reality you're struggling with all the problems in your team.

Speaker A: I mean, you heard it from the last CEO of GitHub, management might actually become a bit more enjoyable. Thanks for that. Looking at your current teams now, what is the biggest change that's already happened in how you're working and what do you expect to happen this coming year?

Speaker C: Yeah, I mean like clearly the biggest change is agent decoding and using agents to do stuff. Like in Atlassian, robodev is used by all our engineers.

Speaker A: All the engineers.

Speaker C: Yes, yes. Nice. Yes. Code reviews. I mean every day I see the percentage of, you know, diffs that are through code reviews are increasing quite a bit. PRs per engineer have gone up 89% issue cycle time has got, has gone down 42%. 51% of security vulnerabilities are now cut through agents. So we are seeing like massive change in our productivity output metrics, the DOTA metrics. All of that is going up, you know, is going well up meaning well because of agent decoding and that sort of thing. And more than the metrics, I'd say like we are really excited about how we are working across PM and design and engineering because we build a lot of products like Jira, Confluence and so that loop is very important for us. And we are finding that because PMs are using like replit and things like that, they are producing actually better specs that are much more amenable to being close to the product that we want, easier for engineers to go implement and so definitely seeing a lot of change. What will happen in the future I think is this notion of building products with actually zero lines of code. Manual coding, I would say, because today it's a mix of like some manual coding, some agents. I think we will get to the point where we just trust the code reviews done by the agents and not have to have too much human review over that. I think we move towards more verification of inputs and outputs to see the system performing according to the right security, reliability, performance bars, less about inspection of code. And then if I were to look out, I know that Thibaut didn't want to look out two years, but if I look out two years plus, maybe we don't have programming languages and IDEs anymore and we have some kind of AI JVM or something that just sort of does things. And because if you think about it, programming languages are there because like, you know, we don't want to write assembly and we need something to tell the computer what to do. But like if AI is able to do that and you're able to debug sev using AI as well, then it shifts to a higher level intent and you don't need maybe programming. Now that's super extreme. I don't know if it'll go there, but it is conceivable. And so that's really exciting to think about what that word will look like

Speaker B: from the CEO perspective. I think there's two drastic changes. One is costs are through the roof. And as everybody who manages a larger team has some fixed OPEX budget that is mostly your salaries, your benefits and then some traveling expenses, all of a sudden we have flexible token costs. And the more productive you had all these impressive statistics, the more productive your developers are, the more your costs are going through the roof. And you actually create an inversion where you have to slow down some developers because they're burning so many tokens and they're like, well then I will build less features. And that's something that a startup founder only deals with. When the money runs out, the run rate gets shorter. But I am a big manager in a corporation will actually have to figure out with their finance team the traditional approach to this will no longer work. And you actually want to encourage teams to burn more tokens. And you talked in a very early session this morning about OpenAI's billions tokens and that they don't have to pay for them. Obviously that's not true. They're paying for the GPUs to Azure and Oracle and whatnot. But that's I think, a drastic change to how we're managing Teams that all of a sudden you had. And look, what nobody wants to do is fire people to offset the cost of the tokens. Right? Because the human cost of that is way higher than the benefits. I think the very positive version of that is coding is fun again. And I learned coding on a Commodore 64 in the early 1990s. And then I had a 386 DX40 with a turbo switch and a Pensium and whatnot. And I remember the days when I couldn't solve any of my problems because all I had was books and computer club was only Wednesdays and you were just stuck and you went to bed frustrated and in the morning, hopefully you had some intuition of how to solve that problem. Came the Internet, came forums. All of a sudden you could talk to people. Now you can just in three seconds ask the agents to figure it out. And I think we are underestimating the power of these agents because we all think about code generation. I think the best scenario is actually I have some stupid build error or NPM error or something on the terminal and just feed that into codecs and say, hey, go and solve this. I don't want to deal with any of that. I think that's it's way more fun than it ever was. Same for unit testing. Raise your hand if you love writing unit tests, right? Like, oh, that's the one

Speaker A: I'm looking for.

Speaker B: Kent back the exception to the rule, right? But like that's so powerful to just say write me unit tests or fix the tests and what have you. Coding is fun again and brings us back to when we learned coding. I think what agents have done is it bring us back to the joy of coding. And I was at OpenAI a month ago or so and they showed a couple of builders the new Codex Mac app and made sure we're all in the NDA. But now the app is out so I can talk about it and was a bit food and presentation. And then we all had some coding time. And I built three native Mac apps like in SwiftUI without ever looking at the code, right? And that's just the menu by app. And somebody was yesterday on X saying I love building menu bar apps on Mac and it's so easy. And if you ever tried that yourself in going on GitHub, Google, Stack, Overflow, whatever, even setting up just the Xcode project to hide the dock icon and have it only in the menu bar, you have given up and the idea has flown away by the time you actually had the first build running. And I think that's just so incredible. And whether that is applied to all our hobby projects, but ultimately got us into this profession, hopefully, or it's doing work at lesson or entire or GitHub, I think that's what is so amazing about this, and that is the actual drastic. The productivity is great for the CFO and the CEO and the public stock markets, but what really matters to us is our job is fun again, 100%.

Speaker A: And I love that. So thank you so much, Rajiv and Tomas, and especially for that nice ending. This was great. Thank you. Let's give a round of applause to them.