Building AI-Native Engineering Teams: Thomas Dohmke and Rajeev Rajan on Agents, Roles, and What Changes Next
The Pragmatic Engineer
At The Pragmatic Summit, host Gergely Orosz asked two leaders what it means to build an engineering team "in the age of AI." Rajeev Rajan is CTO of Atlassian, a large company with legacy systems and thousands of engineers. Thomas Dohmke is the former CEO of GitHub and had announced his new startup, Entire, the day before. Both agreed that agents are changing how software gets built. They differed in emphasis. Rajan described a measured, company-wide rollout backed by metrics. Dohmke was more skeptical about current hype and more focused on what the change means for founders, managers, and the everyday experience of coding.
What "AI-native" means right now
Rajan said an AI-native team starts with mindset: the team has to believe in working through agents. Atlassian has both kinds of teams. Some still write software the traditional way, partly because of legacy systems. Others are AI-native, and on those teams, he said, engineers write "zero lines of code." The work is orchestrating agents.
He described several effects. The lines between product management, design, and engineering are blurring, with PMs and designers now writing code. The teams are not necessarily getting smaller, but they are producing more, "sometimes 2x, 5x more," in his words. He also sees more creativity. People can feed screenshots into agents and design more modern UX, and the shorter distance between PM, design, and engineering makes conversations more vigorous. He argued that talk of using AI for efficiency and smaller teams "is missing the point." The real questions are what you can now build that you couldn't before, and how much more joy the work can bring.
Dohmke compared the term to "cloud native." When GitHub started in 2008, nobody used that phrase. It was coined later, once people could see how companies had reinvented deployment and development. He expects "AI native" to follow the same path, so what we call AI-native today will look very different in a few years. His own example of AI-native people is his two sons, aged 13 and 11. A year or two ago they came home with puppy images on their phone home screens, generated with Adobe Firefly. When he asked how they had found the tool, they said everyone at school was using it. For that generation, he said, using an agent instead of a Google search will feel natural.
He then pushed back on what he called a lot of exaggeration about living entirely through agents. As a startup founder, he said, much of his time goes to HR systems, month-end close, and filling out a directors-and-officers insurance form, and no agent helps with any of that. Since announcing Entire, he had received hundreds of emails from would-be angel investors and from experienced developers applying for jobs. He is still looking for an agent that can answer them kindly while making clear he wants to focus on building the company.
He sees a similar gap in software teams. Developers will use Claude Code or another agent to write code. But he doesn't think 3,000 engineers collaborating on markdown files is workable; he called it "a nightmare." It gets worse on international teams. Programming languages, he noted, shrink the vocabulary to a few dozen words that everyone shares. Describing a feature in a language you don't think in, such as English for many engineers in Germany, Spain, India, or China, is "really, really hard." He said the industry hasn't figured that out.
Not reading the code
Asked how workflows have changed, Dohmke said the biggest shift is among developers who start greenfield projects with tools like Claude Code: they force themselves not to look at the code. He said he sees this across the people he is interviewing, whether they come from Microsoft, GitHub, Atlassian, ThoughtWorks, or Block. (Rajan joked about poaching. Dohmke mentioned that about a third of Entire's team is Australian, because one cofounder went to high school with him in East Berlin and later emigrated to Australia. Australian press coverage of the announcement had taken a swipe at Atlassian.)
According to Dohmke, AI-native developers try to look at the code as little as possible. They work through prompts, reasoning, and stating intent. He applies the same idea to code review. Ideally he never reads code line by line, because that will become a growing bottleneck. Instead, a tool such as Cursor's Bugbot points out the mistakes. He said he is waiting for the moment when the review agent works directly with the coding agent, and he asked why a human needs to sit between them. The developers who have learned to work this way are, in his view, the most AI-native today. That ability is a skill in itself. It is also his answer to whether agents will replace humans: no, humans are being "up-leveled" to become masters of the agents.
Left of code, right of code
Rajan described the tooling shift in two parts. As implementation becomes close to free, he said, the bottleneck moves to what he calls "left of code" and "right of code."
Left of code means planning and writing specs. At Atlassian, Confluence plays a big role here because it holds intent and specifications. He acknowledged Dohmke's point that this is mostly English. Product-oriented engineers leave many comments in Confluence, and Atlassian's agents read those comments and work through the issues in a loop, which he called "really amazing." Right of code covers CI/CD, deployment, incidents, and severity events, and Atlassian uses agents there too. The company calls this whole approach the "AI-native SDLC," covering ideation through coding to production, and Rajan said it is changing its tool set substantially.
Rovo Dev and the role of context
Gergely asked about Rovo Dev. Rajan explained that it is Atlassian's own coding agent and also its brand for agent work across the software development lifecycle: code review, CI/CD, and incident resolution.
He said Rovo Dev runs on Anthropic's model yet beat Claude Code on the SWE benchmark. His explanation was "one magic word, which is context." Agents are only as smart as the context they get. Atlassian has built what it calls the teamwork graph, which records who works with whom on which PR and which Jira issue. He said this context helps Rovo Dev produce much better PRs.
Distributed teams and agents as sparring partners
Gergely noted that Entire is spread across time zones, which is unusual for an early-stage startup. Dohmke first said there is no single right model. People should find what makes them happy, much as in personal relationships. A beautiful San Francisco office is fine, and so is hybrid work. He likes remote work because he loves traveling and values 24/7 coverage from people in Australia, Germany, Spain, Lisbon, the UK, and the US.
The cost of remote work, in his view, is loneliness. That includes the pandemic sense of being alone at home, but also not knowing who you can ask a question. In an office you can see who is free and who is busy in a meeting. Agents, he said, now fill that role as sparring partners and experts for brainstorming, writing an ADR, or solving a problem. Over the weekend, while preparing Entire's launch, he realized he needed a cookie policy in addition to terms of service and a privacy policy. He asked Cursor Composer to add it to the React app, and it was "done in 3 seconds." With coding, review, brainstorming, and research agents always available, he said, remote work has reached a level that wasn't possible before.
He also pointed to launch days. A team in one office eventually has to go home. With people in Australia, it is around noon in Melbourne when it's 6 p.m. in San Francisco, so someone is still keeping up engagement on Discord and in open source. Office teams still have the advantage of whiteboard brainstorming. But agents have, he said, "evened out" some of the disadvantage remote teams faced, especially as most AI-native companies in San Francisco have returned to the office.
Rajan said Atlassian leaned into distributed work well before COVID, so the pandemic felt natural, and its products are built for distributed collaboration. The company still has offices, in San Francisco, Sydney, and elsewhere, and believes in "intentional togetherness." It is not remote-only, but it doesn't mandate office attendance; it calls the policy "team anywhere." He agreed that agents have helped. He remembered being stuck on code in the office at 2 a.m. with nothing to do but reread it until it made sense. Now an agent can explain the code or write it. He said that makes distributed work even easier.
Ownership moves from code to intent and verification
On how engineering roles are changing, Rajan framed it in terms of ownership. Ownership is shifting from code to artifacts like Confluence pages, Jira issues, and Loom videos. Loom is a product Atlassian acquired, and he said video can express much more intent. Those artifacts feed the agents and lead to better outputs.
Accountability is also shifting toward verification. Humans still need to understand code, with agents helping. But the emphasis is on guardrails and on checking inputs and outputs so you know the AI's code is good.
Atlassian is not yet making radical changes to team structure or to the mix of managers, PMs, designers, and engineers. The focus is on how an existing feature team can do more and be more creative. The company is not primarily trying to use fewer people, though Rajan said some cases show "10x even 100x" productivity gains and the team is reshaped around that.
Asked what reshaping means, he described experiments where teams deliberately wrote no code by hand. That forces different thinking: organizing the repo differently and setting agent rules differently. He noted that agents lack context at the start of a project, while a repo already full of code gives them a better starting point. Those experiments made a lot of progress. Legacy codebases are harder and take much more effort. Rovo Dev is not yet at the point where it can take on a complex project in a legacy codebase. He called that a hard problem many people are working on and expects it to be solved "very soon," but for now teams can't be as aggressive there.
The Homer Simpson car and the collapse of roles
Dohmke offered two angles. First, there are always more ideas than time. He joked that when you're single, your Saturday-morning plans for the weekend work out; when you're married with kids, your family decides what actually happens. Software is similar. Ideas go into to-do lists, then into Linear backlogs that keep growing until someone throws them out and starts over, and the same ideas come back. Agents move this one step to the right. Feed all those ideas to agents, and the backlog becomes a pile of pull requests, which is now the bottleneck because nobody can review them all. Then review agents will auto-merge and auto-deploy, and you get "the Homer Simpson car": a product with every feature and no coherent design. That is why, he argued, product managers, designers, and engineers are still needed to architect great products. He added that people can spot a bad product much more easily than a good one.
Second, he expects a "massive role collapse." In his view the product manager becomes a product engineer, the designer becomes a design engineer, and the software engineer remains a software engineer, with the roles overlapping far more. He said he is already hearing that companies expect PMs to use a coding agent to build a prototype instead of writing a document and handing it off. The same applies to marketers, communications staff, and assistants, who are using Lovable, Replit, and similar tools to automate parts of their work.
That raises the question of whether IT becomes the "bad cop," as in The Phoenix Project, blocking everyone from deploying, or whether organizations find ways to let everyone build. He tied this to what he sees as the purpose of any organization, going back to the Dutch trading company: a team together is more powerful than individuals. He said the industry hasn't yet figured out how to ship great products securely and in a trustworthy way while moving faster and letting everyone in the company build.
Engineering leaders and the span of control
Rajan said one exciting change for leaders, himself included, is that they can write code again. Over the holidays he bought a personal laptop at an Apple Store, partly because IT restrictions sometimes block installs, and used Claude Code to build an app and some Python scripts. His bar for his own code is high, so building a feature the traditional way would take a lot of time. With Rovo Dev and other agents it goes much faster, and joining a hackathon is satisfying. Leaders tend to drift away from code and engineers as they move up; he thinks that gap is shrinking.
He also expects the span of control to widen. He has long favored an extreme case: for 400 engineers, take the square root and give 20 managers 20 reports each, leaving just two layers of management. Most organizations instead have managers with three or five reports; the worst case is a binary tree with two reports all the way down. He cited reports of leaders with 33 direct reports, including someone named Tibo, and Jensen Huang with 40 or 50. He expects more direct reports, fewer managers, and managers closer to the code, all of which he considers good.
On traditional career paths, Rajan said his first advice to engineers is "Don't be a manager." Someone told him the same early on, and he avoided management for years until decisions were being made that he didn't understand, which pushed him to "the dark side." For engineers, he thinks this is a great time: write code, use agents, explore the cutting edge. "We don't know where the future's going," he said, but engineers who write code will be fine. For managers and leaders it is harder, and there may be fewer of them. Hands-on leaders will do well. Those who cling to old career paths may need to find something else.
CTOs coding again and top-down adoption
Dohmke had three points. First, he joked that founders asked by investors how they'll beat incumbents should say that Atlassian's CTO had to buy a laptop with his own money to start coding. He said it shows that even agile companies that build agile tools can't do what a startup can do in five minutes. Rajan promised to fix it.
Second, he said that over the past two years, coding agents like Copilot, Cursor, and Devin have let many CTOs and CIOs, including at the largest banks, return to coding because setup and package problems no longer take hours. Friends of his in that world gave Devin a task every night, checked the results in the morning, and carried on with their executive jobs. After two weeks of this, he said, they realized everything in their organizations would have to change. Unlike the bottom-up approach in the Twilio founder's book Ask Your Developer, these executives told their organizations they would roll out agents with no excuses. Many banks still run archaic systems and have developers working through Citrix, and CTOs often couldn't override CISO concerns. Dohmke believes that has changed dramatically because leaders are getting hands-on again. He claimed no software development technology has been adopted as fast as agents, and contrasted this with many German, Japanese, and other international companies that still aren't in the cloud because of legal and security concerns.
AI and honesty in management
Third, Dohmke talked about management itself. As CEO of a 10-person startup he wasn't really a manager; he became one when Microsoft acquired his startup and he had to write job descriptions, interview, and write performance reviews. When ChatGPT arrived, managers used it to write reviews, and employees used it for their side too. At Microsoft, he said, employees fill in around seven fields and managers respond to each one, and a lazy manager might just write "I agree with you." His own trick was to ask employees for the bullet points they'd fed into ChatGPT, so he could see how they were prompting.
He connected this to GitHub's "developers first" principle. When GitHub's messaging sounded too corporate, Hacker News let it know. Developers want the truth and directness, not marketing. He argued the same holds for managing an engineering team. Your team knows whether you're being straight or sugarcoating a message that really means improve or leave. AI makes sugarcoating harder: if he spends an hour writing a polished review, the engineer can feed it back into ChatGPT and ask what he really meant and whether AI wrote it. He sees that as good. He compared it to AI-written sales emails, which he wants an AI to delete. Management, he said, is more enjoyable when built on honesty and trust, and managers can no longer fake being the nicest manager while their team struggles. Gergely summed it up as: managers may become a bit more enjoyable.
Atlassian's numbers and the two-year view
Asked about the biggest change so far, Rajan said Rovo Dev is used by all of Atlassian's engineers, and the share of diffs going through agent code review rises every day. He reported that PRs per engineer are up 89%, issue cycle time is down 42%, and 51% of security vulnerabilities are now caught by agents. He said DORA metrics are improving. Beyond the metrics, he highlighted the loop between PM, design, and engineering, which matters for a company building Jira and Confluence. PMs using tools like Replit are producing better specs that sit closer to the intended product and are easier for engineers to implement.
For the coming year, he expects to move from today's mix of manual and agent coding toward building products with zero manual code. He thinks teams will trust agent code reviews with little human review and will shift from inspecting code to verifying that systems meet security, reliability, and performance standards. Looking two years out, he speculated there might be no programming languages or IDEs at all, just some kind of "AI JVM." His reasoning was that programming languages exist because we don't want to write assembly. If AI can tell the computer what to do and debug itself, the work shifts to higher-level intent. He called this "super extreme" and said he doesn't know if it will happen, but thinks it is conceivable.
Token costs and the joy of coding
Dohmke named two big changes from a CEO's view. The first is cost, which he said is "through the roof." Managers are used to a fixed operating budget, mostly salaries, benefits, and travel. Token costs are variable, and the more productive developers become, the more they spend. That can create an inversion where you have to slow down developers who burn too many tokens, which means building fewer features. Startup founders face this only when runway gets short, but managers at large companies will have to work it out with finance, because traditional budgeting won't fit. He said companies actually want teams to burn more tokens. He noted that even OpenAI, whose engineers seem to use tokens without limit, pays for GPUs from Azure and Oracle. And nobody wants to lay people off to pay for tokens, because the human cost is far higher than the benefit.
The second change is positive: "coding is fun again." He learned to code on a Commodore 64 in the early 1990s, when he had only books and a computer club that met on Wednesdays. You got stuck and went to bed frustrated. The internet and forums helped. Now an agent can figure things out in seconds. He thinks people underestimate agents by focusing on code generation. Often the best use is pasting a build or npm error into Codex and telling it to fix it, or having it write or fix unit tests. When he asked who loves writing unit tests, one person raised a hand, and he joked about looking for Kent Beck.
About a month earlier, at an OpenAI event for builders previewing the Codex Mac app (under NDA then, now public), he built three native Mac apps in SwiftUI without looking at the code, including a menu bar app. He said anyone who has tried to set up an Xcode project just to hide the dock icon knows the idea usually dies before the first build runs.
He concluded that productivity gains matter to CFOs, CEOs, and stock markets. What matters to engineers, whether on hobby projects or at Atlassian, Entire, or GitHub, is that the job is fun again. Rajan agreed "100%," and the session ended there. The open questions they raised along the way remain: how to collaborate on natural-language specs across languages, how to apply agents to legacy codebases, how to let everyone build securely, and how to budget for tokens.
You know, when we organized this event, we just wanted to look at the most important questions that we're facing at that time. And this was 5 months ago. And we thought some of it might be AI, but it turned out AI is everywhere. So, I'm not going to beat around the bush.
The two of you are very similar in many ways. You have... Not like that.
[laughter]
You've run or are running large organizations. You're building brands that developers love and use and are engaged with. And Thomas, you're now starting something completely new, so you're also doing something completely different. What does an AI-first or AI-native team mean to you? And I'll start with you, Rajeev. Sure.
First of all, Gergely, 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, you know, 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, you know, it starts with the mindset, right? You have to really believe in doing AI-native work and working with agents and things like that. We have teams at Atlassian, engineering teams, some of which are still doing the more traditional way of coding and building software because 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 2x, 5x more. And the creativity is going up. What you build is much more creative. You can put in screenshots of things and design, you know, more modern UX. And between PMs, designers, 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?
You know, 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, in 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.
I have two boys, 13 and 11. And most of the time they're playing Minecraft. Sometimes I can also convince them to code. But certainly they are AI native. You know, one day they came home, I think it was a year or two ago, and they showed me their cell phones and they had puppy images on the home screen. And they used 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, a Google search or trying to do it the traditional way.
And I think if we're all honest with ourselves, you know, there's a lot of, sorry, bull out there of how all my day-to-day is AI 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 month-end close and getting, you know, directors and officers insurance. And that's a form that I have to fill out, and no agent helps me with any of that. And if you hear that in podcasts, I'm like, "Sure, sure, sure." You know, in theory, that is my life, but in reality, you know, yesterday we announced my company. Since then, I got hundreds of emails from investors that absolutely still want to angel invest into the seed round. People that have 12 years of experience, the best developers, you know, on the planet, yet they're sending me an 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 I can be a nice human and give them a response, but also let them know that I'm not interested in, you know, that conversation right now because I want to build a company.
So, I think that's the core crux of AI native teams today in software development. Yes, we're going to use Claude 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 then have folks in Germany, you know, that speak English with an accent, or in Spain or in India and China and whatnot, that aren't actually as fluent in English, it's actually an even worse nightmare, because programming language is great. It reduces vocabulary to 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.
And how are your teams today using tools? How have their workflows changed?
I mean, I think the biggest change in the workflow is that most developers that start greenfield from scratch today and have used Claude Code force themselves to not look at the code. And basically it starts with that. That's happening at your teams, right? 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 so. Easy with the poaching there. Well, I'm... They're all coming to me, you know.
[laughter]
But all these... Yeah. Yeah, yeah.
[clears throat and laughter]
Well, you know, about a third of the team of my startup Entire is Australian, because one of the co-founders 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 dig a little bit at Atlassian yesterday when the announcement came, because your stock price is down and whatnot. It has nothing to do with us, but of course, you know, that's not how the press works. It's all the sad stuff, you know. Yeah. Anyway, where was I?
Developers, you know, that want to be AI native, what they're doing is try to look at as little code as possible and force themselves to figure it out with a prompt and a reasoning process and voicing intent, right? And in the same way with code review, ideally, you know, I never have to read the code line by line, because that's going to become an increasing bottleneck. I have Cursor Bugbot 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 do we need the human in the middle of that?
And I think that's where the most AI native developers are right now: they're 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're up-leveling the humans to become the masters of these agents.
Yeah, on tools, I think there's two parts to it, right? 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 increasingly one of the tools we are using in Atlassian a lot is Confluence, because Confluence is where the intent and the spec go. And yes, it's mostly English language, and Thomas makes a good point about language, but that's where you're putting in really what you want to build. 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 route loop and, you know, solve things, which is really amazing.
But yeah, left of code, and then right of code, it's the standard stuff: CI/CD, deployment, incidents, SEVs. How do you find that out? So, using agents to do that is what we're doing. So, I'd say we are looking at it holistically across the entire software development life cycle. 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.
Okay. What about Rovo Dev? Tell me what Rovo Dev is.
Yeah, yeah, yeah. So, Rovo Dev is a coding agent, but it's also our brand for doing things across the entire SDLC. So, we're using it for code reviews, we're using it for CI/CD, we're using it for incident resolution. So, you built your own coding agent. Yes.
Now, here's an interesting thing: we are using Anthropic's model, but in the SWE-bench benchmark, we actually beat Claude 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 them, and in Atlassian, we have built what is called the teamwork graph, which is, you know, who does Thomas work with, on which PR, on which issue in Jira. And that context really helps Rovo Dev do a much better job with the PRs that it produces.
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 an early stage startup. Usually, the conventional wisdom is be in the same office, you're going to be riffing off each other. Why did you decide to go distributed, and does AI have anything to do with this?
First of all, I want to say, you know, I'm a strong believer that everybody needs to find their own happiness, right? And just similar to the relationship that you have in your personal life, it's the same with the relationship that you have 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. If you're going to work in a hybrid scenario, also great. And I love working in remote teams because I love traveling. I love the 24/7 coverage if you have people in Australia, in Germany, in Spain, in Lisbon, and the UK, whatever, in the United States, in the 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, if you have a remote team, is that you're lonely, right? And lonely might be in the kind of COVID alone-at-home sense, but also in the who-is-available-for-me-to-ask-the-question sense. And it's much easier to do that in an office environment, because you can kind of figure out that Gergely is only, you know, surfing on X and posting and whatnot. And so I can ask him a question. Never, never.
[laughter]
And at 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 sparring 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." You know, over the weekend I was preparing a 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 3 seconds, right?
And I think remote work, with the help of agents, has gotten to a new level that wasn't possible before, because I always have somebody available. My code review agent, my coding agent, you know, my brainstorming agent, my research agents, all these kinds of things. And I think that's for us the huge benefit, especially if you have these launch days, right? If everybody's 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 6:00 p.m. here, it's like noon or something in Melbourne. And so they're still working and maintaining, you know, the engagement on Discord and any open source project.
So I think in some ways, you know, agents have gotten us an advantage again, you know, for being remote first. And other teams that work in the office together, you know, have on their side that they can brainstorm in front of whiteboards. So, it evened out a little bit of the competitive disadvantage that has certainly evolved here in San Francisco, as most of the AI native companies have gotten back into the office.
And Rajeev, how are you seeing this, because you have distributed teams. Is it changing?
Yeah. Well, Atlassian has actually been leaning into distributed teams way before, even before COVID. So, when COVID actually happened, it was super natural for us to be in that kind of situation. Our software is naturally for collaboration across distributed teams, but we're not remote. We have offices. We have offices in San Francisco, in Sydney, in different parts of the world. So, we do believe in that intentional togetherness you get when human beings come together and work together. So, we're not a remote-only, remote-first kind of company, but we don't mandate you coming into the office. 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. I remember the days when I was in the office at 2:00 a.m. 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 distributed in this fashion.
And you know, a big thing that we're all seeing, and you're seeing it as well, is the role of the 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 had in place before?
Yeah, we think about it in terms of what changes with respect to ownership, things like that, right? And what we are finding is it's less about code ownership. 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 of the Atlassian product. And you can express a lot more intent and thoughts in video. And so we're 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 a lot of code reviews and trying to understand code, which you still have to do, but 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're not going down the path of saying, "Oh, let's do it, you know, with fewer people necessarily." That's not the biggest angle. In some cases we do find 10x even 100x 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?
Can you tell me a tiny bit more when you say like you see more productivity, I mean you reshape the team for that. What could that mean or what does that mean?
Well, we've 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 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, you know, it takes a lot more effort and things like that. And so, we've made a lot of progress with Rovo Dev, but it's not yet at the point where you can give it like a complex project on 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 aggressive.
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're writing things down into to-do lists and then we're moving them into Linear backlogs, and your backlog gets longer and longer, and somebody just throws it all away and starts fresh and brings 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 of the code, and now you have your backlog in 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 and auto deploy it, and what you get is the Homer Simpson car. Right? Because all the ideas you had, you know, 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 know if everybody has that picture in your head. The flip side of that is, you know, that and then obviously 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, right? You're not the pragmatic product manager and the product manager designer, but I 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's 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, as an expectation of their job, to use a coding agent to build a prototype instead of just writing a document and then handing it off.
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 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're much more powerful than as individuals, right? That's the Dutch Trading Company philosophy if you go back to 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 and trustworthy way we can ship amazing products, you know, by moving much faster through the life cycle while at the same time empowering everybody in the company to do so.
And we've talked about the engineer role and of course how designers and product managers are getting closer. What about the engineering leader? You know, you've got a lot of outstanding engineering leaders inside Atlassian. How do you see their roles changing, and you Thomas, as you're going to be hiring, who would you hire for? Before, you would have obviously hired for every 10 engineers an engineering manager or something like that. How will that change for you? So I'll start with you, Rajeev.
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, I bought a laptop, because sometimes you can't install things because of IT, but like I bought my own personal laptop at the Apple Store and installed Claude Code and built an app, a bunch of Python scripts and things like that. And for someone who has grown up writing code, my bar for my own code is super high, as it is for all my engineers. And so for me to take a 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 Rovo 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 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, you know, the degenerate case 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 organizations have people who have like five or three reports. The most degenerate case is the binary tree, right? Two reports, two reports, two reports all the way down. But I think the span of control will increase. I think, you know, Tibo talked about having 33 direct reports. You know, Jensen talks about having — 33, yeah. Yeah, yeah, having like 40 or 50. Yeah, I think people will have more direct reports and fewer managers. And managers will be more connected with the code. I think all of this is really a good thing.
As a follow-up, what about the traditional career path? Oh my gosh, I'm talking like pre-2020, 2022, because we were used to there being a career path: be a software engineer, senior engineer, then either staff engineer or engineering manager, senior engineering manager, director, senior director, etc. What do you think might happen, just taking an educated guess?
Well, first of all, anytime somebody asks me about career path as an engineer, the first thing I tell people is, "Don't be a manager." 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 possible, until I found decisions being made that I didn't understand, and so then I bobbed 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 — Well, it worked out pretty good in the end.
Yeah, yeah, yeah. But I'd say for engineers, I mean, it's a great time to be alive, right? I would just write code, use agents, figure this out, do all the advanced, cutting-edge stuff. For a while, I mean, we don't know where the future's going, but 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, then it's amazing. I think there's less of like leadership, management, blah, blah, blah. It's more of doing and figuring things out in this new world. And those who do, I think, will do well. Those who want to stick to the old career paths might have to find something else.
I have three things. Number one, for all the startup founders, every time an investor asks you, "How are you preventing the incumbent doing the same thing that you're doing?" Just tell them that the CTO of Atlassian had to buy a laptop with his own money to start coding. That's the best answer I can give, because it shows you how even relatively agile companies that actually develop agile tools can't really do what you can do in 5 minutes.
All right, I'll fix it. I'll fix it once I acquire a company, Thomas.
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 2 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 actually have friends in that space that told me stories of how every night they would give Devin a task and say, "Devin, build me this." And then in the morning they'd check in with the developer, the agent, and 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 2 weeks and you realize everything is going to change and has to change in my organization. And in contrast to the Twilio founder's Ask Your Developer, where the developer decides bottoms-up what the tools are, those folks went into the organization and said, "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 going through 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're basically getting our hands dirty again and realizing how powerful this technology is, and that shift is happening and you see that everywhere. No other software development technology has been adopted as fast as agents, right? Like most German companies, Japanese companies, other international ones are still not in the cloud because of all the kinds of concerns that they heard from the legal teams, security teams and so on and so forth.
And then there's the third piece. You asked about leadership and managers. The first time I really became a manager was when my startup got acquired by Microsoft, because as CEO of a 10-person startup you're not actually a manager, you're just one of 10, and you're the speaker and the one who 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. And when ChatGPT came out, all of a sudden we would just 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'd write "I agree with you," and the employee is not happy about that. Hang on. 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.
So you became the CEO of GitHub with this mentality?
You know that God loves GitHub.
You know the key, 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 on Hacker News very straight, right? Like when a GitHub blog post or GitHub tweet or a message is too corporate, quote unquote, developers won't like that. They want the "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, right? And I think the same is true for being a people manager, an engineering manager of a team. Your team knows exactly whether you're talking straight to them and giving them the truth, or whether you're sugarcoating that they actually are doing so well and you're kind of trying to give them the message that you either improve or you get out, right?
And I think this is where the AI is changing this, because I'm spending an hour writing a prettified 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, 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. I want an AI that deletes all that and tells them to never contact me again. And I think the same is true for people management: it's so much more enjoyable when you have a relationship with your team members 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.
I mean, you heard it from the last CEO of GitHub: your manager 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?
Yeah, I mean, clearly the biggest change is agentic coding and using agents to do stuff, like in Atlassian, Rovo Dev is used by all our engineers. Not
All the engineers?
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 gone down 42%. 51% of security vulnerabilities are now caught through agents. So, we're seeing massive change in our productivity output metrics, the DORA metrics, all of that is going up, you know, is going well, up meaning well, because of agentic coding and that sort of thing.
And more than the metrics, I'd say 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're finding that because PMs are using Replit and things like that, they're 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 manual coding, I would say. Because today it's a mix of 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 Tibor didn't want to look out 2 years, but if I were to look out 2 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. Because if you think about it, programming languages are there because, you know, we don't want to write assembly and we need something to tell the computer what to do. But if AI is able to do that and, you know, you're able to debug cells 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 world looks like.
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, you know, mostly your salaries, your benefits and then some travel and expenses, right? 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 then they're like, well, then build less features, right? And that's something that a startup founder only deals with when the money runs out, the run rate gets shorter, but a big manager in a corporation will actually have to figure out with their finance team, right? The traditional approach to this will no longer work. And you actually want to encourage teams to burn more tokens. And you talked in the very early session this morning about OpenAI's billions of tokens and 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, and all of a sudden, 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, you know, I learned coding on a Commodore 64 in the early 1990s and then I had a Pentium 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, right? And you went to bed frustrated, and in the morning hopefully you had some, you know, 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 3 seconds, you know, ask the agents to figure it out, and I think, you know, we're 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 like that on the terminal and just feed that into Codex and say go and solve this. I don't want to deal with any of that. But I think it's way more fun than it ever was. Same for unit testing. Raise your hand if you love writing unit tests, right? Oh, there's the one. I'm looking for Kent Beck. No, the exception to the rule, right? But that's so powerful, to just say write me unit tests, or fix the tests, and what have you. Coding is fun again and it brings us back to when we learned coding. I think what agents have done is 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 were all under NDA, but now the app is out so I can talk about it. And it was a bit of, you know, food and presentation, and then we all had some coding time, and I built three native Mac apps in SwiftUI without ever looking at the code, right? And I had a menu bar app, and somebody was yesterday on X saying, "I love building menu bar apps on Mac," right? And it's so easy, and if you ever tried that yourself, going on, you know, 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, you know, 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, which ultimately got us in this profession, hopefully, or whether it's, you know, doing work at Atlassian or Entire or GitHub, I think that's what is so amazing about this.
And that is the actual drastic change. The productivity is great, you know, for the CFO and the CEO and the public stock market, but what really matters to us is our job is fun again.
100%. And I love that. So, thank you so much Rajeev and Thomas, and especially for that nice ending. This was great. Thank you. Let's give a round of applause to them.
Article published