Aidan Cunniffe on AI, Automation & Code Quality | Atlassian Team 25 EU Barcelona
The introduction of software collections includes a suite of DevOps tools, particularly the DX tool for engineering management. This tool gathers feedback from engineers to identify bottlenecks and enhance developer experience. AI plays a crucial role in automating tasks, improving productivity, and facilitating data sharing. The discussion also covers challenges in automation, the impact of AI on code quality, and the need for critical thinking in development.
Transcript
Hey folks, we're back at Atlassian Europe and we're here with Aiden to talk about software collections, which is, as I understand it, a suite of DevOps tools that you guys have pulled together, including a DX tool, which is, I think an engineering software, engineering management platform. Is it one way to describe that? But um, this is all coming together in one offering.
So Aiden, walk us through what's going on here. Yeah, So obviously everything's been changing in the software development world with AI and the introduction of all of these new abilities. Um, and we think the time is now to really think about what the future of software development looks like and get all the Atlassian tools, uh, sort of pointing in that direction.
So that's been sort of the motivation behind putting the collection together. Um, and we're really happy to have DX joining us to do that, um, because they are the market leader both measuring and improving developer efficiencies. So if we're building all these AI tools to help teams get better, we wanna make sure we're actually tracking the ROI of that and helping teams actually, um, move faster too.
So for the uninitiated, what exactly does DX do and where does it fit in their portfolio? Yeah, So it's gonna be in the software collection, um, and it's got two main components to it. They can help you survey your engineers and get qualitative feedback from them about what's working, what, what's good for them, what's not been good for them, uh, and a lot of quantitative data that helps back up those stories and, um, help you identify the biggest bottlenecks that you need to work on as a team.
So it's, uh, like performance and um, and uh, development productivity tools, uh, in a really nice suite that's been working well for teams like Dropbox, um, and, and others. Right? So there's a lot of focus these days on managing developer experience and improving all that, but it sounds like to me the way we go about doing that today is a little less than scientific.
So is this a more scientific way of figuring out what your developers are actually doing versus what they might be while complaining about? Yeah, definitely. I mean, we've heard people talk about this being sort of the best they had before.
Um, so putting real data behind this I think is, is more important now than ever. Where does AI fit in this whole conversation? 'cause of course a lot of people watching this are wondering if AI is gonna replace them someday, but it doesn't seem that way.
What's your take? Uh, we definitely don't think it will. Um, and me and my colleagues we're working to build a world where human engineers are able to, uh, be a lot more productive than they were before, have a lot better time coding, delegate, you know, tedious but honest task, um, to the agents while really thinking about the high quality important work that they're doing.
So we're seeing at least internally, um, phrase these new stats, like 40% more prs, uh, huge jumps in developer satisfaction. It's making our teams happier and more productive. And we're hoping that software collection helps us sort of share the positive benefits of AI with all of our customers.
Right now, in theory, DevOps is supposed to be about the relentless automation of software engineering practices. In reality, to your point, there's a lot of manual stuff and a lot of tedious stuff that just burns people out over time. So can we just reduce the burnout rate?
And a lot of these teams have high levels of turnover that nobody really talks all that much about. Mm-hmm. Yeah, I mean that's a big thing that we hope to help with.
Um, I think part of that is automating the work, um, and AI and better tooling can help you do that. What excites me about the dx uh, acquisition is that it's telling the other side of that story because once you get to be 5,000, 10,000, 20,000 engineers, the bottleneck shift from like tooling and technology problems to process, um, and management problems. And I think we're now able to sort of tell both of those stories, uh, with one collection that we weren't really able to tell before.
Mm-hmm. It also seems to me like we've given the developers all these great new AI coding tools and they're generating more code than ever, but I don't think we thought through like how does all that code come through our existing pipelines? 'cause they're very brittle as they currently stand.
So do we need to re-engineer the back end to accommodate all this new stuff on the front end? Yeah, so I've just seen an amazing demo that my colleagues at Bitbucket put together of, um, AI in a CI pipeline. So actually when your CI fails, having it open, you know, more code changes to fix whatever had broken.
Um, we also are doing really cool things with AI code review, uh, that, uh, was launched today with VO dev. So all of these areas along the SCLC that have always been sort of those brittle bottlenecks, um, I think we're gonna be able to, to make some big improvements on. So, um, we're, we're definitely trying to think about it.
It's, it's early days, but, um, I'm really excited for all the stuff we keep putting out and how quickly the teams have been moving, Who's doing the actual fixing of the code. 'cause sometimes developers are like, you know, you can't touch my code. But in reality, software engineers have been kind of tweaking code for a long time to make it fit in a production environment and maybe not telling developers of exactly how they went about doing that, but how do I kind of navigate those issues?
And for that matter, how does the AI know what's in the production environment? Yeah, so this is, um, obviously an emerging, emerging area that a lot of teams are trying to figure out. I think Atlassian is really well positioned to have telemetry from both production with JSM and tying it all the way back to the development process with Rob Dev, uh, Bitbucket and all the tools and software collection.
So that's always been our, our story, why we think we will do a great job in the AI world. Um, we've got more context and sort of more more in teamwork graph than any of the other competitors. Um, and we think Atlassian customers are really gonna benefit, um, as we tighten those screws and make everything a lot more seamless and closer together.
As I look at the current DevOps pipeline that's out there, there's a lot of tools. Will AI kinda rationalize these tools into something that feels more like a single platform? And is some software collections kind of a step in that direction?
Yeah, I think every team is still gonna choose a couple tools. They all have their own flavor. I don't think that's necessarily going to go away, but I think the, the core pieces of the, of things like the pipeline, the SEM, the agent platform you use to do all your AI agents and delegating code tasks, I see those as kind of being the big pillars that you want to have well integrated.
And then those tools can use some of the other tools that are sort of doing more specific cases in the market. So it's still gonna be messy, but I, I think we can get it a little more under control. Alright.
Speaking of messy, I'm trying to figure this one out. Is each engineer gonna have their own AI agent or will they each have their own small army of AI agents and then everybody on the team will have their small army of AI agents and somehow or other this will all get orchestrated? Or is it more likely that the team will have an AI agent that's been trained to perform a specific task on behalf of the entire team?
Mm-hmm. So I think there's gonna be, uh, sort of two different answers here. Um, but I'll tell you when, when each one will apply, I think you're gonna have the, uh, virtual teammate for, uh, like very vertical tasks.
Like, we need to go fix these production bugs or integrate with this API or fix this solution for our customer. Um, and then I think when you have engineers who are gonna be building like the future, like brand new features, uh, like Rajiva is showing today with live editing inside of, um, inside of Confluence, that's still gonna require a lot of forethought. And what we can do for developers building those really complicated features is let them basically have their team of junior developers that report to them and use the AI as sort of virtual teammates.
So I think it's different depending on kind of the kind of work, but that's what I've seen be really successful internally and I think other companies are seeing that too. I think you just said all of the above, but Okay. Yeah.
Um, as we kinda also look at the platforms, there's this thing out there now called the model context protocol server, and I think you guys have one and everybody else does too, I'm pretty sure. But will it become easier to share data across these tools now with these AI agents because we're gonna have some sort of de facto standard for doing that and maybe I don't need to write as many scripts? Mm-hmm.
I think definitely, um, the, I've had personal great success like having, uh, the MCP servers for different databases and CI tools like set things up for me. Um, I think there's obviously questions about how you, how you wire all that together, but I see a world where it's a lot more open and easy to connect things and hopefully that, um, actually helps like the best tools win because a lot of the time you set something up, you've integrated and now you can't really get off of it. Um, and I'm hoping now that this allows sort of great paradigms to come, come in and people to adopt them faster.
How smart will the agent get? And I'm asking this question because, um, if I look at a lot of DevOps organizations, you'll see a lot of pipelines and they're not always efficiently used and maybe they have more pipelines than they need, or maybe they don't have as many as they should, but will the agent kind of be able to look at the workflow and say, you know, here's how it should be properly structured. Mm-hmm.
I think they're gonna be able to help with a lot of those tasks. Um, you can't pull a, you know, a bunny out of a hat, like if it, if no one really knows what the pipeline's doing or why it exists and doesn't, you know, fit into any other work, maybe it can go away and you just delete it. Um, but I think for migrating things, bringing them forward, making things better, like the agents are very good at maintaining the same behavior that was there before and helping you port to the latest standards.
So I could definitely see that too. But, um, yeah, they're not gonna, they're not gonna, they can't do alchemy yet, no one can. Okay.
Um, what's your best advice to folks then about how to get started with all this stuff? 'cause I think a lot of people out there are like, you know, they're downloading a tool here and downloading another tool over there and there's a lot of experimentation going on. Is that the right way to go after this?
Or is there a more strategic way of thinking about this? Yeah, I think the, the teams that get the furthest with this, uh, AI development transformation, um, are gonna be approaching it, um, with little experiments, but they're going to take what works and then start implementing it top down. Um, and that I think can help people move a lot faster.
Um, so it's, it's about, um, it's about basically taking a more active role and saying, okay, we're trying to solve this problem. Maybe we found that problem because of dx. We're gonna send a team of four or five people to start trying it the new way, learn a lot, and then we're gonna try to roll it out to the rest of the organization.
I think that's, that's gonna be how people can really run experiments and uh, and know that what they're doing Makes sense. Yeah. Do you think, I mean, you hear people say this, but I don't know if it's true, but they'll say, you know, we're gonna build more software in the next two years than we built in the last decade.
Do you think that that's actually gonna happen? I think there's a chance that there's, uh, gonna be an explosion of internal software, um, and there's gonna be a lot more feature velocity on sort of SaaS and, and privately uh, built software. But I also think that a bucket that less people are talking about is old legacy software that's still running on mainframes, um, and everything in between.
And I think there's gonna be a lot of work to modernize a lot outta that stuff before you can really, um, put it into overdrive. So those are kinda the three buckets I see. And I think that third bucket of, um, sort of rebuilding and modernizing is gonna take up a lot of time the next couple years.
Also, what is the definition of a developer gonna look like in the age of vibe coding, right? If it seems like everybody and his brother could become a developer, but there may not always have the best software development practices in mind. So is there gonna be a lot more code of, uh, uncertain quality in the pipeline and, you know, is that something I need to think through?
Yeah, So what we've seen, and there's been some, uh, some reports that come out about this that, that backed it up is, um, these are, these are tools they amplify. So if you have, um, a a great developer who really thinks about the architecture and how to build this is gonna make them able to, to put out a lot of good code faster. But if you take someone who doesn't have, have solid understanding of their principles and you give them the tool, they're just gonna produce a lot of stuff that doesn't follow those principles.
Um, so we think software development is still really important. We still think people should be studying that, learning about it, um, and trying to really understand what these tools are building. 'cause you know, the, the dirty little secret about software is building it is, is actually never been the hardest part.
It's always been selling it and marketing and maintaining it. So, um, this initial boost of like, I got it out in a week or a day, um, that's actually not the hard part of software development and, uh, it's, it is everything else that I think is most important. Mm-hmm.
How attached will we get to our AI agents? Are people gonna put names on these things and start calling them, you know, my little buddy or what? Um, I don't know.
That's, uh, that was above my pay grade. I think. I think, uh, there, the, the world is big.
There will be people who do that. Um, I don't know if it's gonna be everyone I, I think, but a lot of the work is gonna be figuring out the right relationship to have with these tools, um, how you collaborate with them. I know people who, who put in way too much and try to get the AI to think for them and do everything and their projects don't turn out well.
I know people who, who really have figured out, okay, here's what it's good at, here's what it's not good at, here's where it can help me, here's where it might struggle. And really building that empathy for this thing. Um, and I think those developers get a lot further with a tool.
If you have a set of AI agents and I have a set of AI agents and they're, we are assigning them to do a task, they'll have to negotiate with each other at some point, won't they? Or will they just kinda look at each other and kind of say and do their thing and ignore each other? But how will a team of AI agents kind of come together to function as a team?
Yeah, I think there's probably the best parallels will be how engineers come together to function as a team. So, uh, pull request, uh, to make sure that, you know, no one's changing things without people seeing it and looking at it. Um, having pipelines to make sure that no one's creating regressions, having test suites.
Because I mean, the real reason why test exists is because I might know about behaviors that you don't know about and that no one's written down. And if, uh, you change them, I want to know and I want you to know before I know. Um, so that's why we've built all these practices and I think it's just gonna be an extension.
Alright. So you've been at this a while, clearly, I mean, you know, a while being months and years compared to everybody else, but, um, what do you know now that you kinda wish you knew a year ago? I wish you knew a year ago.
I think, um, I was, I was in that first camp that I was just talking about a minute ago, people who just, you know, gave it the mission and said, go do all this for me. Think about it, figure out the best way, do all this. Um, and I think that what I've realized is I was outsourcing too much of my thinking.
And I think that is going to be a problem in the AI era, not just in development, but everywhere. I think you want to keep your thinking and use these tools to help you execute, um, and, uh, not use them to sort of replace your own, your own ability to be creative and think I was, I was just using them too much. They're very addictive in that way.
Um, but I've, I've tried to find a better balance of how I, how I use the tool. All right, folks. You heard in here ai, don't replace yourself with AI because otherwise things will get messy and complicated.
And thanks for being on the show. It's been a pleasure. Thank you.
All right. And we'll be back in a minute, guys.