AM

André Meyer

Things André Says on Podcasts

“Developers are still pretty happy, even though AI essentially takes away the writing of the code. It wasn't really about the act of typing code. It was about being able to build something that benefits somebody else. As long as they remain in the driver's seat and can choose what to build and design a solution, they are oftentimes still pretty happy about the creation part of their work.” — André Meyer, Engineering Enablement “Most of those metrics are focusing around development related activities and almost none of the metrics around collaboration. And the challenge is that developers spend maybe 30, 40, 50% of their time in collaboration and communication. But with those dashboards, we don't really understand how this part is impacting their work lives.” — André Meyer, Engineering Enablement “You as an author, you own the change. So you actually still need to read and understand your AI-generated change before asking anyone else to spend time on reviewing your potential AI slop. For a low-risk change with high confidence, we can maybe just trust our tests and rely on an AI review. But for the high-risk ones or the low-confidence changes, we need to ask someone else to review, not just for finding bugs, but also to spread knowledge.” — André Meyer, Engineering Enablement “They were designed for a world where producing code was really costly and now it's almost free. It's super cheap. And so those metrics inflate a lot and they're also very easy to game. And shipping more doesn't really mean that you're creating anything of value.” — André Meyer, Engineering Enablement

Where to Find Them

André Meyer has been a guest on Engineering Enablement .

Recently: “Inside the DevEx Metrics Compass with André Meyer” on Engineering Enablement (November 2026).

What They Said

“Developers are still pretty happy, even though AI essentially takes away the writing of the code. It wasn't really about the act of typing code. It was about being able to build something that benefits somebody else. As long as they remain in the driver's seat and can choose what to build and design a solution, they are oftentimes still pretty happy about the creation part of their work.” — André Meyer, Engineering Enablement

Brian Houck asked what would change about a "good day" for developers if the Good Day study were rerun now that AI does much of the coding. André Meyer says the core findings, making progress on something meaningful with few blockers, still hold.

Engineering Enablement · 2026-11-12 Permalink → Listen →
Engineering Enablement
André Meyer

Yes.

Brian Houck

…this idea that we're all going to be managers of agents. And so we're constantly switching between tasks. I'm curious, if you were to rerun this study today, what do you think would change around how, like, what makes a developer feel like this was a good day versus this was not a good day?

André Meyer

So one of the core findings of the study was that developers said that on a good work, They were able to create something of value, which means they were able to make progress and work on something that is meaningful. And I think this hasn't changed. The other thing that we've also seen is that on good days, they are able to spend time efficiently. So, this means they have very few blockers and no infrastructure issues and few interruptions and things like that. Sadly, this also has not changed yet. And I would argue that AI, in some cases, even creates more interruptions. And then finally, they also said that on good days, they spend more time coding and they have more time to actually write code, which is pretty cool. On good days, this was around 30% of their time. Yet, it wasn't really about the act of typing code or like really writing it down. It was again really about being able to build something that benefits somebody else at some point. And this is also why many of the developers we are talking to today with AI are still pretty happy, even though AI essentially takes away that part of their job, which is the writing of the code. But as long as they remain in…

Brian Houck

Now, I do think that for many developers, having a sort of deep understanding of how the system works was also like a sense of joy, and they liked to get deep into the technical details. And you say that as we move to sort of higher levels of abstraction, you're still dictating what it is we're…

André Meyer

I would say yes or no. So, yes, there is this switch of from writing code to orchestrating agents more or supervising agents more and then reviewing code as well. But I think it really depends on whether the developer can decide what they delegate and what they still want to keep close to their…

Brian Houck

So, we've talked quite a bit about collaboration so far. And, you know, in your Good Day paper, you sort of like look at that tension a little bit between collaboration can be incredibly helpful, particularly around things like planning and spec generation, but it's also a source of interruptions.…

Speaker names come from our own diarization. The position is estimated from where the line sits in the episode.
“Most of those metrics are focusing around development related activities and almost none of the metrics around collaboration. And the challenge is that developers spend maybe 30, 40, 50% of their time in collaboration and communication. But with those dashboards, we don't really understand how this part is impacting their work lives.” — André Meyer, Engineering Enablement

Brian Houck asked what surprised André Meyer most about what companies choose to measure, after he mapped more than 120 metrics from about 40 companies into the DevEx Metrics Compass. This is the biggest gap he found.

Engineering Enablement · 2026-11-12 Permalink → Listen →
Engineering Enablement
André Meyer

…the compass really helps you to navigate this fragmented landscape by exploring metrics, by comparing or benchmarking against other companies that are maybe similar to you, and also by allowing you to receive an actionable report at the end to sort of know where to get started and what to do next.

Brian Houck

…many different metrics are sort of mapped together to different frameworks. And it's like, it's a lot of fun to go and dive into. And so as you were creating it, as you were diving into all of these metrics in use across the industry, what surprised you most about what companies choose to measure?

André Meyer

Before I answer one quick addition to my previous response, I wanted to give a shout out to also my collaborators on the compass briefly, Thomas Fritz, Gail Murphy and Patrick Meyer, who helped me with all of that and setting it up and giving feedback and so on. And to come back to your question about what surprised me the most is that most of those metrics are focusing around development related activities and almost none of the metrics around collaboration. And the challenge around that is that developers spend maybe 30, 40, 50% of their time in collaboration and communication. But with those dashboards, we don't really understand how this part is impacting their work lives and their developer experience.

Brian Houck

I think collaboration is part of the very definition of developer productivity. It is one of the dimensions of space and has been often the hardest to understand because collaboration is incredibly important to delivering innovation, but it can also be an incredibly large source of toil. And I'm…

André Meyer

Not that I've seen, to be honest. And there are only very few collaboration metrics that we actually have. That's the opportunity, I guess. Exactly. That's an opportunity for researchers, for DX and many others to contribute. I think that some good measures would evolve around finding a balance…

Brian Houck

Which is like a huge shout out to the idea of measuring sort of meeting like clustering. And do you have sufficiently large gaps between meetings to do deep focused work? Found that that can be substantially more predictive of how much work devs get done than just like the total number of meetings.…

Speaker names come from our own diarization. The position is estimated from where the line sits in the episode.
“You as an author, you own the change. So you actually still need to read and understand your AI-generated change before asking anyone else to spend time on reviewing your potential AI slop. For a low-risk change with high confidence, we can maybe just trust our tests and rely on an AI review. But for the high-risk ones or the low-confidence changes, we need to ask someone else to review, not just for finding bugs, but also to spread knowledge.” — André Meyer, Engineering Enablement

Brian Houck asked for one change a team could try to make developers' days better. André Meyer's answer is a team agreement on pull request etiquette for AI-assisted work, because review load is growing and developers either rubber-stamp reviews or get stressed doing them properly.

Engineering Enablement · 2026-11-12 Permalink → Listen →
Engineering Enablement
André Meyer

Yeah, then just if I then have a question, but I know that my team will be around later for collaboration time, I might be willing to wait for half an hour or an hour to ask that question instead of just dropping by my colleague and interrupting them all the time.

Brian Houck

…Andre. If a team wanted to make more of their work days quote-unquote good over the next month, what's one change that you would recommend for them to try? And how would you tell whether it helped both the developers themselves, but also ultimately did it result in good outcomes for the customer?

André Meyer

So, my number one suggestion would be to optimize for focused versus collaboration work. But another thing I have been thinking of more recently is that PR review load is increasing a lot. And for developers, it's a huge challenge to deal with this growing review load. André Meyer they just rubber stamp reviews or they do it properly, which stresses them, increases cognitive load, and so on. So, what I would do is I would gather with the team and agree on something like a PR etiquette for AI-assisted work, basically saying, Okay, you as an author, you own the change. So, this means you actually still need to read and understand your AI-generated change before asking anyone else to spend time on reviewing your potential AI slop. And then the author might also need to rate something like the risk level or like a confidence score or something, because if it's a low-risk change or like high confidence in that change, we can maybe just trust our tests. So, we may not even need to ask someone else to, or like another human, to review it, and we can just rely on an AI review. But for the high-risk ones or the low-confidence changes, we need to ask someone else to review, even not just for finding bugs, but also to spread knowledge…

Brian Houck

So, if I understand, it's like a mix of both having the time to do deep focused work and then having clearly agreed to sort of accountabilities and boundaries on where everyone's responsibilities lie on that. And you think like doing those two things will lead to better days?

André Meyer

Absolutely. Yeah, I think if we can reduce the number one thing that we still keep hearing in the age of AI, which are meetings and too many interruptions, that's an actionable and simple thing to. To work on and explore. And the other thing really is the growing cognitive load that developers keep…

Brian Houck

Awesome. I think that's a great place to leave it. I'd like to remind the audience: too many DevEx Metrics Compass little guidance is the paper out now. ACMQ could not encourage people to read it anymore. It is phenomenal. Andre, thank you so much for joining us.

Speaker names come from our own diarization. The position is estimated from where the line sits in the episode.
“They were designed for a world where producing code was really costly and now it's almost free. It's super cheap. And so those metrics inflate a lot and they're also very easy to game. And shipping more doesn't really mean that you're creating anything of value.” — André Meyer, Engineering Enablement

Brian Houck asked why it is so hard to answer "we've invested in AI, but has it helped?" André Meyer said most dashboards track AI use and output, like adoption, acceptance rates and pull request counts. This is his explanation of why classic output metrics stop meaning much once AI writes the code.

Engineering Enablement · 2026-11-12 Permalink → Listen →
Engineering Enablement
André Meyer

Hi, Brian. Thanks so much for having me. It's always super exciting to talk to you about good developer experience.

Brian Houck

…leader being asked, you know, we've invested in AI, but has it helped? And leaders today frequently have dashboards, but they rarely have clear answers from those dashboards. Like, why is it such a difficult question to answer? Like, you know, has AI helped? Like, has our investment in AI helped?

André Meyer

Yeah, from talking to developers and building the data set around the COMPASS, which by the way, includes metrics from around 40 companies, we've noticed that most dashboards are only covering AI use and AI output. So instead of actual outcomes and value delivered. So they would look at metrics around AI adoption, daily active users, acceptance rates, in some cases, even lines of code or token spend. And those are really easy to collect, which is why they are so commonly used. But it only shows if AI is being used and it doesn't really show how it helps to create more value or even true return on investments. And also we've noticed that they use a lot of sort of classic output-related measures like throughput and number of pull requests and deployment frequency and things like that. And they were already a challenge before AI to like compare between teams and divisions and so on, but this got even more ambiguous with AI. The problem is that they were designed for a world where producing code was really costly and now it's almost free. It's super…

Brian Houck

So that's really interesting, sort of the idea that whether or not AI is helping is a difficult question. to answer because the easiest metrics to measure are the ones that tell us sort of the least about outcomes. And to try to help us reason about measures better, in your paper, you mapped out…

André Meyer

So as you've mentioned, we've looked into all the measures that we could find in the engineering space, so what companies are actually applying, but also from the research space. And we've seen that there are a lot of metrics and we started to collect them in a systematic way and we've gathered the…

Brian Houck

For those who have not seen the DevEx Metrics Compass, I like cannot encourage you enough. It is beautiful and just like awe-inspiring how many different metrics are sort of mapped together to different frameworks. And it's like, it's a lot of fun to go and dive into. And so as you were creating…

Speaker names come from our own diarization. The position is estimated from where the line sits in the episode.

Collections They Appear In

Software Engineering & Infra