真實世界中的生成式 AI:Charity Majors 談 AI 可觀測性
Generative AI in the Real World: Observability for AI with Charity Majors
Honeycomb 共同創辦人兼 CTO Charity Majors 與 Ben 討論生成式 AI 如何改變可靠軟件的建構,以及可觀測性的作用。她指出,非確定性系統需要「更多嚴謹,而非更少」,並建議以 OpenTelemetry 自動插樁,透過追蹤記錄 Agent 的決策和任務步驟。
AI makes it possible to generate code faster than teams can understand and support it. In this episode, Honeycomb cofounder and CTO Charity Majors joined Ben to discuss how that shift changes the work of building reliable software. Charity explained how observability helps teams connect changes with outcomes, why nondeterministic systems need “more rigor, not less,” and how traces can show the decisions agents make along the way. Over their wide-ranging conversation, she and Ben also covered automatic instrumentation with OpenTelemetry, why we should think of ourselves as “owners on the loop,” the limits of AI in debugging and SRE, and broader industry concerns like the pressure AI hype places on engineering teams and why maintenance, not speed, builds “enduring value.”
About the Generative AI in the Real World podcast: In 2023, ChatGPT put AI on everyone’s agenda. In 2026, the challenge will be turning those agendas into reality. In Generative AI in the Real World, Ben Lorica interviews leaders who are building with AI. Learn from their experience to help put AI to work in your enterprise.
Check out other episodes of this podcast on the O’Reilly learning platform or follow us on YouTube, Spotify, Apple, or wherever you get your podcasts.
Takeaways
00.59. “Observability is for unknown unknowns.” Monitoring is a way to set thresholds and alert on expected conditions. Observability supports open-ended investigation to answer questions you didn’t know to ask and “find things you didn’t expect.” When AI code generation became capable enough to change software work, observability best practices had to evolve, which is one reason why the second edition of Observability Engineering, which Charity coauthored with Liz Fong-Jones and George Miranda, more than doubled in size.
05.24. Cheap code shifts the work to understanding and support. AI can quickly produce implementation, tests, and documentation, but teams still need to understand what they built and agreed to support, and how their users are experiencing the product. As generating lines of code becomes “effectively free and instant,” validation, review, and operational support can constrain a team’s pace. Of course, Charity wryly noted, so can “every other part of the software development lifecycle.”
06.24. The people who take the credit for AI-assisted work should be able to explain it. AI-generated results (and the papers describing them) complicate authorship, expertise, and the academic training process, something that’s become a particular point of consternation for mathematicians of late. If someone is claiming a result they accomplished with the help of AI, they should be able to present it to peers, Charity and Ben agreed. When AI handles entry-level problems, professions may need new ways for junior practitioners to develop mastery, but Charity is skeptical we’ll run out of problems to solve:
In the same way that I’ve made peace with the idea that cars are faster than I can walk or run, I have made peace with the fact that computers can compute better than I can. . . .That doesn’t mean that there’s no value in the practice, or the discipline, or the learning, or the rigor. It just means that this is one of the things that humans are no longer the best at. But there are a lot of things that we are the best at, and being the best at something isn’t all of what makes it worth doing.
15.56 Nondeterministic systems require “more rigor, not less.” As Charity noted, “The future of software is both determinism and nondeterminism. It really is about using these superpowers that we’ve been given to build those feedback loops. And observability is really the feedback loop of feedback loops.” It’s what connects actions with outcomes and helps teams learn what happened after they make a change. Her analogy:
It’s like we’ve all been riding lawnmowers and just kind of putt-putt, putt-putt, putt-putt along down the road. And now, all of a sudden, our lawnmower has a Ferrari motor in it, and we’re like, “Vroom!” Now we can vroom into the ditch. We can run into a wall. And we have to build structure. We have to build rigor into our system if we want to run down the middle of the street.
18.53 People need to own the loop, and understand the decisions the agents are making. If you need to add observability to your agents, Charity recommends starting with autoinstrumentation with OpenTelemetry and traces that capture agents’ decisions and steps through a task. As for your role, it goes beyond staying “in” the loop. Charity prefers the term “owner on the loop” because it emphasizes the active understanding and control required to manage these systems. AI can amplify experienced debugging and SRE teams, especially when people direct work during rare, high-stakes incidents. Agents have little training data for those situations and can make an incident harder to diagnose. These tools are “not magic,” Charity pointed out. AI “is not a replacement for expertise, but it can be a really powerful adjutant. . .at your side.”
26.00 Different telemetry needs different strategies. Charity distinguished the abundant output from third-party infrastructure from the business-critical telemetry produced by a company’s own code.
There’s observability for infrastructure, which is mostly third-party code. . . .It’s code you didn’t write, but you have to operate it. You can’t change it, but it’s just outputting a lot of logs and metrics into your database logs and your ETLs, or CloudWatch, and all this third-party code is just emitting a lot of stuff. . . .That stuff you should just put someplace that is cheap commodity storage. . . .It shouldn’t be super expensive, just that it’s there when you need it.
Then there are your crown jewels: your code, the code that makes you the company. . . .You should instrument in such a way that preserves as many of the relationships between the data points as possible: arbitrarily wide structured-data blobs, structured logs, and/or traces with lots of spans. Because the most valuable part of your data is the relationships. . . .You don’t want to spread it out into hundreds or thousands of individual metrics or log lines. You want to keep it together so that you can correlate: when this happened, that happened; or when this happened, that was true; or when this happened, it was part of this long event. . . .This is the most important data you have. And for that, it should go someplace. . .that preserves those relationships and opens it up for explorability by you or your agents.
來源:O'Reilly Radar · oreilly.com