The Next Chapter of Developer Experience: TAG De... Julien S, Graziano C, Mona B, Kevin D & Daniel O

This talk discusses the work and initiatives of the TAG Developer Experience, highlighting their definition of developer experience within the cloud-native ecosystem. The speaker explains how developer experience encompasses not only developer tooling but also application architecture and runtime factors that influence daily work. They elaborate on three primary initiatives: improving secure coding practices in CNCF projects, exploring the state of AI-assisted development tools, and creating a common specification for application dependencies. Through surveys and community engagement, they aim to gather insights on the existing challenges and successes within developer workflows, particularly regarding security and AI integration. The talk emphasizes the importance of collaboration and continuous improvement in developer experience.

Hey everyone. Uh thanks for joining us today. Uh we're going to be talking about Oh, 1 minute? He said He said yes. So, we're going. So, thanks for joining us today. Uh we are uh TAG Developer Experience, part of the members of TAG Developer Experience. We want to talk about the next chapter of developer experience, what we've been up to ever since the TAG reboot about 1

year ago, what we've been working on, our current initiatives, and then we'll also open it up for uh questions from the audience to have uh conversations with you folks. This is TAG Developer Experience. Uh so, there are three chairs, a few tech leads, and that's uh who we are. And uh I'll pass it off to Mona first so that uh she can talk about some of our

focus areas and what we're doing as this TAG. You want to go first here? >> Yeah. Okay, I can go. It's on? Okay. I still need to start? Uh I'm sure I'm sorry. So, we started our TAG by defining uh what actually developer experience means because, you know, like different people have different uh definition of what developer experience actually means. And we try We try to make

uh sense of the of the terminology in the uh cloud-native ecosystem. Uh so, from our perspective, developer experience is the interface the developer get to interact with uh day in and day out in the software development life cycle. And from our observation, we found that these can be split into three different areas. Uh like the developer tooling, which includes uh which includes the inner loop on the

local machine of the uh of the developer developing as a source code and developing features. All the tooling included in the cloud-native ecosystem can be under the inner loop, also the outer loop. Once that the code gets out of the developer machine and gets to be ready to be reviewed and shipped to production and beyond. Um we found though that the developer experience is not only about

the developer workflow. It goes beyond because cloud-native affects as well the application architecture. And we found that there is another category that most of the time is ignored, which is the application runtime. The application runtime includes like the service-to-service communication, also like communication hubs like the messaging queues and streaming. And what's more, like the application deployment topologies, is it on edge or is it somewhere else? Um

the multi-tenancy, for example, all these affects the developer experience in one way or another because like this is this is like affects the the work of the of the developer every day because it affects the application architecture, which they are mainly developing. With the rise of the platform engineering as well, there is a third pillar, which is the platform enablement. And this is this is big because

of course like the platform engineers define the interface the interface or the golden passes that developers get to interact with every day. And like that can be golden passes, policies, and everything that it's not only a GUI or is it it's not only a developer portal, but this is integrated in the total software development, of course. What we do based on that is that we take care

of all the solutions that are underneath of these of these pillars. We try to uh define a standards, define guidance, and cloud-native developer developer experience frictionless. And that's it, and I'll be back Yeah, okay. Thanks, Mona. Oops, sorry about this. All right. All right. Um we want to talk about our current initiatives. Before, let's just define what is an initiative for TAG developer experience for those who

don't know. So, an initiative is basically a target set of work that we want to accomplish in a relatively limited amount of time. So, initiatives go from 3 to 6 months. They have a very clear deliverables and a pretty well-defined scope that is quite limited. So, compared to CNCF subprojects that are meant to last much longer in time and don't have as clear deliverables as an initiative

is very bound to be short in time, so 3 to 6 months. So, we have a few initiatives right now that are in flight, so we'll go very quickly around them. The first one is about showcasing frictionless secure coding success stories and pain points in CNCF CNCF projects. So, what I wanted to do with this title is see if there's a contest about the longest title for

CNCF initiatives, I wanted to win it with that one. So, what is the goal of our initiative here with this? So, TAG security and compliance provides a lot of guidelines around how to keep our CNCF projects secure. It is not always completely in line with the developer friction and experience. So, what we want to do is we want to poll CNCF project maintainers and contributors and the

community on how they've been adopting these security practices and what this adoption has basically meant for the developer experience throughout adopting them. So, that means we want to hear the good stories that you've adopted some um some tools and some practices that have basically improved the security posture and as well improve the developer experience and reduce friction or the opposite where there are some guidelines that the

tax security has provided that are maybe a little bit harder to put in place, has been introduced friction and we want to try to surface these. So, here you have a QR code to a survey and it would be a really amazing if some of the CNCF contributors that are uh here in this room would be able to fill this survey and then the goal is to

say, we'll take the results of this survey and then discuss them with tax security as well. We want to create workshops with targeted set of people. So, some folks from developer experience, from tax security and some of the contributors and maintainers and try to have conversations around what have been the success and failures about adopting these practices through the developer lens to try to reduce friction and

improve the security posture of CNCF projects and improve the developer experience as well of these same CNCF Yeah, and just uh if you have any questions about any of the So, we'll we'll go through the different initiatives just to kind of give you an idea of what we're working on. Uh if you have any questions, uh you know, think about them and uh right after we present

the initiatives, um we're happy to take these questions, right? That's why we're here in the panel, but just keep that in mind. >> Exactly. So, we'll go through them sure quickly, then we'll take questions and we're also at project pavilion at 4:00 p.m. if you want to talk more about these initiatives. We'll we'll at least I'll be there and some of us will be there as well

to answer your questions afterwards. Thank you, Julian. Next one, state of AI assisted development in CNCF projects. Uh there is of course a lot of uh interest into the usage of AI for building software. And the idea here is to ask and listen to uh CNCF projects maintainer contributors or anyone who has something to say about how they integrated AI into the SDLC to understand which are

the pain points, where is the most of the value into integrating AI into the SDLC, what is working, what is not working, the challenges you are facing now, what you solved, and there is a survey. This is a QR code for our survey. Uh it's a very short survey. It takes something like 3 to 5 minutes to to to fill the form, and uh we are always

looking for uh new contributors to help us to analyze the data and build the final uh outcome, which is a white paper to help the other contributors to start the journey into uh the adoption of AI assisted development tools into open source project or into enterprise project. So, who here is using AI uh as part of their development cycle with assistance or any other pieces? Okay, so

you should all scan this QR code and give us your feedback on how you're using it cuz I think it would be really helpful for uh everybody to know how everybody else is using it, and then kind of uh maybe we can learn from each other, right? Of course, you see us as a representative of the tag, but if you want to join us to work together

with us on the initiative, this is the um the survey, but in the heading of the survey there is the link to the the the issue of the initiative, and you can just drop a uh comment there, and we are welcome everyone to to work with us. Yeah. Okay. I think I'm next. All right. So, uh the third initiative that or initiative, yes, I I always say

issue, but I mean initiative uh that we're working on in the tag is about uh creating a common spec for uh application dependency. So, what we've seen is that um a lot of times when you're working on an application and um you want to either use it on your local machine and you don't exactly know what kind of dependencies this application has um or kind of the

opposite where maybe we've been developing this application on our local machine, we created some dependencies on it. Now, we need to deploy that and um you know, the platform team needs to know what exactly dependencies this uh this application has. So, the idea is to create a common spec in in the CNCF space, just an open-source specification uh that defines the the dependencies of your application. Um

and so, that's definitely a pain point that we've seen in in the you know, in any kind of organization. So, um this initiative has been pretty well received. So, there's a first deliverable already uh created, which was kind of the research on the current state of affairs and you can see the link right there in the in GitHub. And then um so, what we're doing now is

we're kind of uh trying to figure out how we can best um get those dependencies. So, and the first idea was to do something like uh eBPF to try to just observe the behavior of applications and then try to figure out what kind of dependencies it has and then create that into uh some sort of mapping and and then into the specification that some something like score

could use to then uh use for different projects like Crossplane, Radios, and whatever more. Um and then with some feedback we also, uh, you know, realized that maybe there's a a better way for, especially when Apple application developers know what their, uh, what dependencies they need, um, to actually build that into their application. So, if you're a Java developer, maybe you can use Java Docker annotation in

your code and based on that we can create, uh, the the spec for the platform team to use and vice versa. So, this is something that we're working on right now as well. Also, and looking for contributions for experience from, uh, the community as well to see, you know, like what is, uh, what is needed. Um, what are your pain points? Does this resonate and do you

see any other solutions? So, you know, again, happy for anyone to contribute to this initiative as well. Yeah, to speak of the contributions, we have Simon here. He actually proactively engaged at this initiative a lot. So, I'm going to give you a quick moment and then he going to share what kind of, like, Apple contribution he actually done there. Um, yeah, uh, so I'm I'm Simon Forster.

Um, I'm a platform engineer by background. Um, and, um, I was really interested in this and just speaking about how I got involved. Uh, for me it was very informal and it was meeting with the the original author of the issue within at, um, KubeCon within Atlanta, participating in the original meeting, um, and then, um, understanding what was involved. Um, my involvement, um, through this issue has

been on, uh, reviewing this. Um, I was, um, probably a a participant in the code level declarations feedback there. That was something that I was was really interested in. Um, and for me my my involvement within the tag has been, um, attending meetings, keeping abreast of the issue. Um, it hasn't been something that's been my number one focus because I work across other activities within the CNCF.

So, um, I've been it's been really rewarding to be able to participate where I can, but it hasn't taken up a huge amount of uh, time for me. So, just to reiterate on that. Yeah, thanks for sharing. Yeah, that's really good feedback. So, you don't need to actually spend a lot of time to contribute back to CNCF part of the tag, not only this tag or other

tags. So, you maybe spend just a little bit time, have some fun, and then with the some networking with the some CNCF people. So, this is a last at the least. So, our initiative. So, so we actually looking for the actual like a volunteer this one. So, we actually submitted this initiative a couple months ago, but we couldn't find some volunteer. Not only like a member, but

also like lead this initiative. So, this is a mainly for developer inner for process, but more like AI app dev stuff. So, in order to develop AI application, you have to do do the some build bro a lot of stuff from the how do you running on your model local machine as a container or just like a binary? And also how to build, how to compact, and

how to deploy, how to communicate. There are many kind of like a real local stack you're going to do that. So, this is a how do you going to create the like end-to-end like a experience and with the multi uh CNCF projects. So, if you are interested like a AI some experience for application development, doesn't matter Java, .NET, Python, or any kind of programming language, maybe this

should be interesting. So, as uh the Julia mentioned earlier, so each initiative, so we have a some kind of a little bit timeline, so we're going to deliver some kind of deliverable in next 3 months, something like that. But, once you participating and act proactively during this initiative, you can actually a little adjusted compensation with the other leaders. You know, they are more flexible and then just

if you have any interesting this last initiative, please contact one of us and then we are more than happy you and then working together with that. And I'm going to hand you over back to Yeah. Thank you. And just in general also so these are initiatives that are we are actively working on. If you have any ideas of anything else in the CNCF space that helps with

developer experience, some idea of how to contribute or anything, we're also looking for, you know, contributions in terms of new initiatives. So, please, you know, join that as well. Amazing. So, with that we'll take questions from the audience. It can be conversational as well and we also have some pre-canned questions, but we'd be very happy if folks from the audience have some questions for the panel about

either the current initiatives or initiatives that we should be considering as well or if there's ways that TAG developer experience can make your life easier. There's a mic there, so if there's any volunteers. Don't be shy. Go ahead. I want to ask. So, I don't have a problem not being shy, but it might be a silly question. experience, is that mostly like intended to be across CNCF

projects or within contribution or is the scope even broader? How should we go because I can't imagine that you can well, make the scope so big you can involve all of software developments and software in the entire world into it. I'm pretty sure it's probably listed somewhere in in the charter somewhere which I then didn't read. But but how does that work? I guess I can go

very quickly and think the panel can expand on this. So, the our scope within developer experience is to work on uh developer projects around the CNCF projects themselves, right? Our scope isn't broader than that, but we feel that some of the initiatives that we have can have a broader impact. So, good developer practices uh for CNCF projects and white papers around AI, for example, like Cristiano is

working, right? They can expand much broader than just CNCF projects. So, I don't know if there's anything folks here can add. No, I think you nailed it. Do you want to add Sure. Yeah, speaking about the AI initiative, we need to give a boundaries to the initiative just to be effective when working on the on the specific initiative, but the idea is always to help the community.

So, we are not working only with the project of the CNCF, but we need we aim to do something that is useful for the broader community. That's the point. Yeah, because I imagine that um that's at least how work for me and for well, work at my company. Um we're an end user, so when we look at the CNCF, we don't just look at the projects, but

also how the projects are governed or how the uh say uh a proposal system works. Um that was also of course the um the ADR concept like architecture decision records, which is essentially just a specialized versions of caps or apps because of course Python have their own peps. Um but uh yeah, those those practices, while initially targeted at CNCF projects, they turn out to be your default

good practices to use everywhere when possible. I mean, if you are a five-man company, maybe it's a little bit overkill. Um but yeah, so essentially, if there's something coming out, uh uh uh something is being used that improves the experience uh within the project, it is very likely that it will also be adopted outside of that. Is there Is there is sort of feedback loop for that

where people might say, "Hey, I'm using it in a new and unusual way. Uh uh It might not be directly related to your current scope, but it might be something that affects future work that will then like be reverse adopted into CNCF project." That would be something that's Yeah, absolutely. I think I mean, especially cuz like you're saying in software development, you the ideas are universal. We

focus specifically on the CNCF projects, but the ideas can come from anywhere and they will most likely also apply to the CNCF space. So, yes, I mean, absolutely, if you have any ideas, absolutely looking for those as well. Cool. Thank you. Thank you. And then, yeah, I mean, you can put the microphone more in the middle for the next person. I should have said that at the

start, but cuz you're like Yeah, seems I'm in the center. No. Yeah. A little bit more even. >> OCD happy. I'm serious. I'm working in Nebulous and I have one questions for every person who involved in developer experience because it's now a pain point for me. Uh now developers began to be very productive. We know why, but what but how to manage where result in terms of

code review? Because previously we believe what code review can fix issues, can help to deliver better code, better source base, but now it but now the size of pull request can be several thousands of lines of lines written by LLM. I don't don't speak about AS love. I mean what we scored well tested uh and this code was include a huge amount of work, uh testing on

staging environments, testing with different patterns of load, etc. etc. etc. but the amount of code it's a problem itself. Maybe you have in your projects the same experience, uh not just to reject all merge requests, pull requests with AI. Maybe something which can help me. Yes. Amazing question. I'm sure there's a lot of opinions here in the room. Okay. Uh this is actually an open question we

have into the AI assisted development initiative a specific question about how you as a project uh deal with AI generated pull request. Um the point is that now many uh open source projects are uh starting adding um AI policies to govern how contributors can or can't use AI to generate the code. And the point is this is something I want to stress. We are five here. We

work with other people in the in the talk, but we always have a bias. So, if we work together within small groups, we are generating something that is biased by our experience. That's why we need the input from you. So, if anyone here is working on a uh specific project and want to share their experience, feel free to take the microphone and don't ask a question, but

try to answer one of the questions. I can just uh have a comment No, it's on here. Uh so, I think um like I think when it comes to like I think like teams need to think and define uh what do they generate by with with AI because I think it might like there might be there are I see two forces in the AI space. Some people

go above and beyond in in the two extremes. Like they some people need to just merge or commit their code without with no reviews with with no human review. I mean here not the AI review. >> not work I think. Yeah, not not AI reviewed and the other the other extreme is that they want to ditch AI all together or they don't believe in it or they

don't trust it. They don't trust the input from AI. So I think between the two extremes what we need to do in this space is that we need to define practices and standards. We need to define a new workflow like that the software development used to be an iterative process and it needs to stay this way. I'll and it's we still need to have human input no

matter how much the output is. I think we need to have control if the output is beyond your capacity then you need to define how much can I take right now in order to be productive and not to risk my systems to have like a problem in production later on because the consequent the consequences of fixing all these issues later on will be costly I have to

say. So this is something like you have to have control like I have like have a tap like if the AI is is a water tap right now and it's just like getting you water then you need to adjust your your tap and see how much you can take and then take it from there. Develop practices. This is my comment. I didn't know about the others, but

yeah. From my perspective, I have uh the same thoughts I just talked already with many people, and they believe what PR is also some kind of team ritual like daily daily stand-up or retro or something else, and we need to formalize it and understand which things we can we can we can achieve through reviews and think what it's still limited by capacity of uh of individual contributor

to review this code. Um and also I can share interesting thing because I integrate machine learning models many years ago. Uh it was the main area of product moderation on on marketplace, and we have human moderators, and business customers always believe what a human has 100% recall, 100% accuracy, and they don't want to use AI because it provides only 80% of accuracy and 65% of recall. Uh

but nobody tried to measure the performance of real moderators at that moment before me. So, basically, maybe we need to understand also our baseline. Yeah, I think AI has been amazing or is getting amazing at generating a lot of the code, right? But our processes to integrate code into the system is much more than just writing the code, right? It's it's been a limit before, but now

it's not the limit. But getting these PR reviews done in a different matter, maybe, is perhaps part of the solution to try to solve these, Yeah, I started what of writing of code it's only only 1 to hours of developers day. And previously, you can generate you can write during this time only some bunch of lines, and now it was amplified. So, you can write in 2

hours something which can be can be previously can be completed only in 1 week. So, it's amplifying the real contributors, the stage of reviewing of code reviewing of contribution become becomes becomes very frictional bottleneck. Great. thank you for your answers. I will continue to think about how to live in 2026. Thank you. I think next question because we don't have much Yeah, yeah, we have a couple

of very short ones that will fit in the 2-minute warning. So, for AI we essentially apply the same rules as for human PRs, which means that a human PR is also constrained to something that's realistic to be reviewed that is self-contained. And if you produce more work, well, that means that this ends up in the PR queue, and that's okay. Which means that if you have an

LLM, just because you you can produce more text doesn't mean that that more text means that you suddenly don't have to obey the rules anymore. Of course, obeying the rules sounds very strong. We ended up doing something slightly simplistic. We we get up, so we take the diff. We see how many bytes it is, and if it's over a certain amount of bytes, then we kick off

an other LLM that will parse it, and it will print out a nicely formatted message like, "Hey, I've seen you're you're trying to do X, Y, and Z, but it's not broken down into multiple pieces, so do that first." Which means you actually >> to do the same. Yeah. >> I mean limit the merge request size, but it's uncomfortable to team to understand what's happening in the

input. be around so we're kind of out of time. We'll be around a little bit here, but yes, exactly. The kiosk we're at the project Pavilion. We'll have a kiosk between 4:00 and 5:00. So right after this session then tomorrow morning as well you can drop by and we can have amazing conversations with you folks. So lastly I just want to mention that here we have the

two QR codes for the surveys that we have in flight. Would really appreciate if some folks here would connect with us and give the give us your feedback. Then here this is the feedback a lot of surveys to do. So another survey to do about this session and what is your feedback about it. And as well some links here to get in touch with tag developer experience.

We have a bi-weekly meeting on Wednesdays. We also have a slack channel that you can use to reach us. These are the links that you can use to to find out more about us as well. So thank you very much.