'Grafana's Big Tent' podcast: Anthropic on agentic coding, observability, and the future of software engineering

In this episode of "Grafana's Big Tent" podcast, hosts Mat Ryer, Senior Director of AI at Grafana Labs, and Tom Wilkie, CTO at Grafana Labs, sit down with Eric Burns, Field Executive Architect at Anthropic, to talk about why Anthropic bet early on running across every major cloud, what it's like watching a technology go from "interesting" to "obviously inevitable" in real time, and how agentic coding tools have changed the day-to-day of building software at Grafana Labs.

You can watch the full episode in the YouTube video below, or listen on Spotify or Apple Podcasts.

Note: The following are highlights from episode 9, season 3 of "Grafana's Big Tent" podcast. The transcript below has been edited for length and clarity.

Why Anthropic bet on being everywhere, not just one cloud

Tom Wilkie: We're a pretty big fan of Anthropic models. We do use models from other vendors. I've heard they exist. But I think one of the things that attracted us to the Anthropic models was the availability. We run across all the major cloud providers, across Microsoft and Amazon and Google and so on, and the fact that you can get your models in-region across all of them was a big win for us. How did that come about, or why is that Anthropic's strategy versus, I know Anthropic and OpenAI and Google have very different strategies for model availability.

Eric Burns: Yeah. I've only been here coming up on two years, which makes me near old guard at Anthropic, but not there for the early days in the origin story. It strikes me as kind of a classic second-mover situation where there was an early breakaway leader and they had kind of a slightly more vertically integrated, or at least single-partner, strategy. When you're trying to get your feet under you as a startup, you try to figure out where your opportunities are and you maximize what you can do within the opportunity space.

So I did a startup before this. One of my favorite quotes from that time was something like, "Great architecture is all in the constraints." If you're a second-mover lab, one of your constraints is that you need to line up a hosting partner and you need to tell a good story for that. I think it's a very significant maturity transition for a company to be able to work with many different partners and many different platforms. It's kind of ripping the Band-Aid at a technical level that you can put in all of this work before the first dollar of partner revenue arrives.

That's a substantial opportunity cost, and it might fail, and you might be left without a good result. But I think one of the things that makes Anthropic is the decision to pay that cost early and to generalize and be able to work across clouds. You can see that now in being the first model provider to reach all three major hyperscaler platforms. I think one of our core competencies is making our models run on a diverse set of hardware.

Natural language as the new UI for dashboards

Eric: One of the most fun things about working at Anthropic is that there's just this continuous progression of goosebumps moments where you're like, "Oh my gosh, I can't believe computers can do this." And also, "I can't believe I'm getting to see this up close in the lab as it's materializing."

One of those moments that I'll never forget was the first time that I saw that we had a model that was able to basically start with natural language and create streaming UX, just build charts at the speed of thought, build very capable React single-page apps in a single prompt. I thought, "Oh my gosh, this is going to completely transform how we deliver user experiences." 

This has progressed into this idea that there's a UI paradigm that you can actually build and it's a legitimate choice now. Which is, you start with natural language and end with streaming charting and BI and structured data presentation. I feel ridiculous saying this out loud on a Grafana podcast, but it just does seem like the wind is at the back of that particular model, that UX design model right now.

Tom: One of the longest open issues on the Grafana repo was, how do I batch-edit things? Because from a UX perspective, actually doing good batch-editing UX is really hard, it turns out. I now just believe natural language is the best UX for doing certain tasks, like batch-editing dashboards.

Eric: Yes, absolutely.

Tom: In one of the early demos that Mat gave me for the Assistant, which I thought was very impressive because I understand how hard it was to achieve, was to make all the themes for the panels purple and change all the panels. Obviously, you show that to a salesperson and they're like, "Why do I want that?" But for an engineer, it's like, "Oh wow, that's really difficult to pull off."

And suddenly, there's a lot of pre-AI dashboard slop around, but now the AI is actually better at producing dashboards, we've found, than humans. It labels the axes. It puts reasonable names on them and titles.

AI adoption across Grafana Labs' engineering org

Tom: We obviously have all witnessed the revolution in software engineering. I don't think, at Grafana Labs, any of our engineers are writing code anymore. Our penetration for things like Cursor, Claude Code, Codex, and so on is basically now at 100% in our engineering teams. But I guess this is an observability podcast and we should probably talk about observability at some point. As you go and talk to customers and execs and the community, what are you seeing in terms of the agentic use cases in observability?

Eric: It's a very complex set of actors that are gradually reaching consensus. If I go back to what's happening with coding agents, I've seen this real shift at the executive discussion level over the last six months especially. Six months ago it was: Are the models going to get good enough? Are the coding agents actually going to get there? Is this something that we should inflict on our team, or can we kind of hang out in shadow IT land and some people come in and use it?

Now it has definitively shifted... If you equip all of your frontline engineers with a fire hose of output, all of your other systems are going to crumble under the amount of stress that they're putting on them. Now it's moving to a second-order problem of building heavy automated test coverage, which of course coding agents are great for, obviously having evals around anything that is non-deterministic, and basically stacking the way up to being able to deploy coding agents with some confidence.

Then the second realization, as orgs sort of get the baseline of internalizing officially blessed coding agents, whatever flavor they pick, is this realization that integration just got really, really cheap. Being able to take one internal system and string it to another one became a prompt and a one-shot and some smoke testing, as opposed to, if you're outsourcing it, massive spec document, throw it over the wall, several iterations, months later, you get this dashboard that has been scoped down to the shadow of what you were hoping it would be, and you're like, "I guess I'll do another turn."

The ability to wire all this stuff up just based on immediate need, and then just sort of chat with your data or build a dashboard based on some wild idea, I think this is putting even more pressure on strong, opinionated UI systems for delivering this stuff, and critically, ways to persist it. One of the uncomfortable flip sides of all this prolific output from product managers and people—who didn't think of themselves as coders, but they can write the requirements and they can vibe-code their way to stuff—is distribution and hosting is actually really hard.

If you've got these deeply rooted systems of record where all of your tribal knowledge and all of your state info and your telemetry lives, and you've got kind of a consistent way, for example Grafana, to deliver this to users, the integration is where the magic is happening. It is not just ripping the whole thing off and saying, "Well, anybody can have a database, and we can vibe-code all of the integration layers in between, so why would we need a rendering system?" People still need a way to onboard onto using a platform. It's like back to that old "Who Moved My Cheese?" [story]. If the UI is continuously shifting, you can't enable people on it. You can't train people, and you can't really document it.

Zigbee meshes and Home Assistant

Tom: I don't get to code that much. I've got a very large engineering team. I'm mostly a manager now, and I have a backlog of coding projects that I've wanted to do. I'm slowly ticking off that backlog.

This is the intersection of AI and observability, because I do a lot of home automation. Everything in my house is fully automated, and I really want to store a lot more telemetry about my Zigbee mesh, for instance. Sometimes you press a button and it doesn't quite work, or doesn't work as quickly as you would hope, and I want to know why. What do I need to optimize and fix?

I just opened this PR yesterday, actually, and it was mostly Claude Code. It's been on my backlog to go and instrument Zigbee2MQTT for a very long time. It's not hard. It's 500 lines of Node. I am not a JavaScript or TypeScript engineer. It would have taken me days, if not weeks, to have done that, because I would have had to learn a ton. But I can read it and it seems reasonable. It does the right thing. It's got 100% test coverage. The satisfaction of being able to tick off a bunch of personal projects has just been absolutely huge.

Eric: There are two really interesting principles—not principles, attributes of coding agents for certain personalities. One of them is, I've also gone down the rabbit hole of Home Assistant and linking everything to everything and automating it all. I use Grafana and my Home Assistant to look at my InfluxDB, which is all my sensor outputs and so on.

Tom: Terrific. A hot tip: if you use the Prometheus exporter in Home Assistant, I recently refactored all of that, again using Claude Code, two months ago, so it's now got loads more entities in Prometheus.

Eric: Excellent. I know, I'm turning into a serious Home Assistant nerd, so perhaps there's a separate conversation.

The 'recovering engineer' getting the dopamine hit back

Eric: This zone of things that I can trust Claude to solve is now a fairly complex software project, but the only upside: there's no business value generated. I can click something on my phone that I used to click on a wall panel, right? Things like that. Or I can see high-fidelity data that I couldn't see before. The cost-benefit is getting completely transformed in terms of the effort that I imagine something is going to take. It has been in steep log decay to the point where basically nothing feels out of reach in this sprawling home integration project.

There were certain things where I was like, "OK, well, I'm just going to grit my teeth and reach in there and write the code, or I'm just not going to do it at all." So the first property is, many things that were total wastes of time got so cheap that just dashing off a Claude prompt and then checking in an hour later and saying, "Oh my goodness, I got this thing." I wasn't expecting that pure upside.

The second one I think is really profound for managers, and I experienced this. The last time I wrote production code was five years ago. There's a half-life of the quality of your dev situation where I can step away for a month and come back, and it would be eight hours before I was back in the flow. You pull down the latest, you've got some break, somebody forgot to check in this other thing, there was a framework migration, now you have to go read the docs for this framework, just on and on. The ability to ramp back up into the flow is almost always instantaneous now, because Claude will just bash through whatever nonsense is keeping you from being in your dev loop.

Tom: We refer to managers in Grafana Labs as recovering engineers.

Eric: Yeah, right. It's the encapsulation of exactly that idea. Suddenly that recovering engineer can get the dopamine hit of solving a problem that they didn't used to be able to.

Do we still need to read the code?

Mat Ryer: Do you think we will end up in a situation where we've stopped looking at the code, like Assembly? We don't really look at Assembly unless we need to. Most people can't, though they probably can now thanks to Claude, etc. Do you think we'll get to the point where the code is like, you look at it if you need to debug something, otherwise you're good. 

Eric: You know, if you talk to Boris [Cherny], the creator of Claude Code, his view is, "We're already there." About a year ago, I stopped dirtying my hands with reading the actual code. Now I operate at the pattern level.

Increasingly, lately, I've had this weird experience with Opus 4.6 where I'll think I see something smart and I'll interrupt it in a loop. Then it dawns on me that it's actually a step ahead of me, and I'm like, "Oh, I'm so sorry. I thought I understood that, but actually, I don't. You're already on the right track."

So there's a certain threshold where, you know, I fancy on a good day I'm a decent engineer and I kind of know what's going on. I had this very uncomfortable feeling of being in Claude's way as it was trying to solve the problem and benevolently deliver the thing that I was asking it for.

One tier of question is, should we go review the code? Another one entirely is, is a human, even a competent one that knows the code base, for some value of competence, adding value or reducing throughput? I think these are the questions that, back to the idea of software engineering collectively engaging with it, there's no one right answer. Again, it's a question of risk tolerance.

But I've definitely had this ratcheting sense of my value being pushed out of implementation in the same way that anybody that's ever written Assembly would feel that most likely a high-level language expressing programmer intent very well, and a strong performance and compilation stack, is going to outperform whatever any of us could do at the assembly level.

Mat: Yeah, I see that future. I really do. It's closer than we think. Very exciting.

"Grafana's Big Tent" podcast wants to hear from you. If you have a great story to share, want to join the conversation, or have any feedback, please contact the Big Tent team at bigtent@grafana.com.

Grafana Cloud is the easiest way to get started with metrics, logs, traces, dashboards, and more. We have a generous forever-free tier and plans for every use case. Sign up for free now!