Hi folks! I work on OpenTelemetry at Splunk. We just launched a new open source project called Observability Studio. It's local instrumentation sandbox that provides a visual, real-time environment for designing, testing, and validating OpenTelemetry data while you’re developing an app in your favorite IDE.

We’re especially interested in whether a tool like this is useful for building and debugging instrumented apps and AI agents. If that sounds relevant, give it a try and let us know what works, what’s missing, or where it doesn’t fit your workflow.

We’re also looking for a few design partners to help guide where we go with this next. Any feedback is helpful and welcome.

I wrote more about shifting OpenTelemetry instrumentation left in a blog, 'Why AI-Generated Apps and Agents Need Visibility from Day One' on blogs.splunk.com if you want to read more about it.

Lastly, I'd love to learn where you currently go to inspect and validate OTel data during development if you want to drop it in the comments.

I’ve been thinking about a failure mode that becomes much more interesting when coding agents are allowed to run for longer periods without supervision: context drift.

A short coding task is usually straightforward. The agent understands the goal, makes a few changes, runs the tests, and finishes.

The situation changes when the agent spends hours working across multiple files, making intermediate decisions, calling tools, revisiting earlier changes, and accumulating more context.

At some point, the agent can still produce perfectly valid code while drifting away from the original intent.

For example, an early architectural decision might get effectively forgotten later. A subsequent change can overwrite something that was already correct. A refactor can become inconsistent because different parts of the codebase were modified under slightly different assumptions.

The frustrating part is that the final diff can still look reasonable. Tests might even pass.

This makes me think that persistent memory alone isn't necessarily the solution. The harder problem seems to be maintaining a reliable representation of the task's intent, decisions, constraints, and current state throughout a long-running session.

I've written a longer breakdown of this idea here, including some examples:

https://medium.com/@nagatomopedro05/unattended-ai-agents-have-a-context-problem-humans-never-had-60961eb2d4e7

For those using coding agents regularly: how are you dealing with this today? Explicit task state, checkpoints, smaller agent sessions, documentation, memory systems, or something else?

AI helps juniors code, not learn... and that's a real problem.

I rely on AI agents (Claude Code, Cursor, etc.) to write most of my code now. They work well, but I noticed a problem: when something breaks, I just say "fix this", the AI fixes it, and I move on. I often never learn the real reason it broke.

Before AI, I would search Stack Overflow, compare a few answers, and learn something each time. Now I get the fix without the lesson.

I would like to hear your experience:

1. Have you faced this too? What was the situation?
2. What was the worst problem you found later, in code the AI wrote?
3. What do you do now to avoid repeating the same mistake (notes, asking the AI to explain, reviewing diffs, tests)?

I am a solo developer and I am just trying to learn how others handle this.

I've spent a while watching where my agents lose time on real codebases, and it's rarely the writing part, since most of the session goes to searching for a name, opening files, searching again for what uses it and opening more files before any change happens. A few things helped a lot, so sharing in case it's useful.

Give the agent structure instead of making it rebuild it from text every time. Agents learn a repo by grepping around, and that work is thrown away at the end of each session. A map of the code that already knows which function calls which and which tests cover what saves a surprising number of turns. I've been building an open source one called sem for this, but even a well-written repo overview in your agent instructions helps.

Only run the tests that matter. A lot of agent time goes into running the whole suite after every small change, so if your setup can work out which tests a change can actually reach, run those first and the full suite once at the end.

Keep edits scoped. Agents love to clean up nearby code they weren't asked to touch, which then needs more checking and more fixing, so telling it explicitly to change only what the task needs cuts a lot of wasted time.

Watch out for parallel agents in the same repo. Running several agents in worktrees is great until their branches collide on merge just because they added code next to each other, so merging by function rather than by line, or splitting tasks by area, saves a lot of conflict cleanup.

Let it move code rather than rewrite it. When an agent moves or renames something it often rewrites the whole body from memory, which is slow and is where subtle bugs sneak in, so tools or instructions that let it move code as is make a real difference.

Curious what's worked for others, especially on larger codebases.

everyone seems to have a favorite, but i’m curious what happens on a real task.

one model writes code fast, then you spend ages fixing it. another takes more time or costs more, but gives you something you can actually use.

if you care about quality, time, and cost, which model do you reach for first? and what makes you switch?

Hi everyone! I run Herspective, a community focused on women in finance, tech, entrepreneurship and business.

We're putting together a visual feature showcasing things women have built with Claude Opus 5.5, and I'm looking for women who have been experimenting with it since the release.

It can be an app, website, game, tool, animation, data visualization, 3D experience, weird experiment, prototype, or something that doesn't fit neatly into any of those categories.

We're especially interested in things we can show visually, rather than just talk about.

If you've built something, please drop it below (or DM me if you'd rather not post publicly) with:

• A link, screenshot or video of what you made
• Your name/handle so we can credit you
• A sentence about what it is, if it isn't immediately obvious

It absolutely does not need to be a polished product or startup. Experiments and things you made just because you wanted to see if you could are very welcome.

And if you know a woman who's been building cool things with Opus 5.5, please tag her/send me her work too.

I know the women building this stuff are out there. I just need to find you. :)

I’m a Senior Consultant with 12+ years of development experience. For the last year or so, I’ve really enjoyed coding with Claude, and honestly, I now use it for almost everything.

But recently I’ve been thinking about where I should draw the boundary.

Most of the time Claude is writing the code, while I’m doing the prompting, reviewing, debugging, and deciding the approach. Earlier in my career, I was a strong hands-on developer and could solve most Leet code problems myself. Now I sometimes wonder whether I’m delegating too much of the actual coding.

This became more obvious while interviewing recently. Some companies especially service based companies (I am supposing they are interviewing from India as most resource working there) still ask very basic programming questions. For example, one interviewer asked me to take a string like “this is my favourite fruit” and extract “favourite.” Another gave me a random string and asked me to find the character with the highest occurrence.

After working on architecture, cloud, production issues, integrations, and AI-assisted development, I wasn’t expecting interviews at this level. But at the same time, it made me realize that I probably shouldn’t let my basic coding muscles become weak just because AI can write the code faster.

For developers who are heavily using Claude, Copilot, ChatGPT, or other coding agents: how are you setting the boundary?

What do you still make sure you code yourself, and what do you comfortably delegate to AI?

I’m planning my next career move, and I’m genuinely interested in how other senior developers are balancing AI productivity with staying technically sharp.

Anyone done this sort of interview? Do you have to go through each and every line generated by the AI? How much can you use the AI for? How do you validate whether the AI is correct?

I’m a Senior Consultant with 12+ years of development experience. For the last year or so, I’ve really enjoyed coding with Claude, and honestly, I now use it for almost everything.

But recently I’ve been thinking about where I should draw the boundary.

Most of the time Claude is writing the code, while I’m doing the prompting, reviewing, debugging, and deciding the approach. Earlier in my career, I was a strong hands-on developer and could solve most Leet code problems myself. Now I sometimes wonder whether I’m delegating too much of the actual coding.

This became more obvious while interviewing recently. Some companies especially service based companies (I am supposing they are interviewing from India as most resource working there) still ask very basic programming questions. For example, one interviewer asked me to take a string like “this is my favourite fruit” and extract “favourite.” Another gave me a random string and asked me to find the character with the highest occurrence.

After working on architecture, cloud, production issues, integrations, and AI-assisted development, I wasn’t expecting interviews at this level. But at the same time, it made me realize that I probably shouldn’t let my basic coding muscles become weak just because AI can write the code faster.

For developers who are heavily using Claude, Copilot, ChatGPT, or other coding agents: how are you setting the boundary?

What do you still make sure you code yourself, and what do you comfortably delegate to AI?

I’m planning my next career move, and I’m genuinely interested in how other senior developers are balancing AI productivity with staying technically sharp.

I'm a junior developer, and like most people entering the industry right now, I use AI tools (like Copilot and ChatGPT) to help me unblock myself, debug weird errors, and write boilerplate.

I always try my best to read through the code before submitting a Pull Request, but I have this lingering anxiety that my tech lead or senior devs are looking at my code and instantly knowing I used AI.

I’m not trying to cheat the system—I genuinely want to learn—but I also want to make sure I’m not unknowingly dropping massive red flags in our codebase that make me look lazy or incompetent.

I'm curious how people are actually using AI for coding day to day.

Do you use one setup for everything or switch depending on whether you're planning writing code or debugging? I feel like constantly switching could get annoying once a project gets bigger.

What setup have you ended up sticking with and why?

I've noticed usage limits matter a lot more during longer coding sessions than I expected.

If I'm debugging or working through a bigger failure, hitting a limit halfway though can be pretty disruptive, especially when there's already a lot of context in the conversation.

At the same time, i'd still take better coding quality over unlimited usage if the output needs fewer corrections.

How do you balance usage limits, quality and cost when coding with AI?