Know What's Happening (i.e. observability)

What you'll see developers say online

You can’t know what’s happening inside a vibe-coded app. That’s for real developers. There’s no logging, no error catching, no events. When something breaks in production, you won’t find out until a customer complains. Hand your app to any developer for review and they’ll look for the basics, not find them, and discount the whole thing: go away and bring in someone who knows what they’re doing. Observability is enterprise complexity: a non-coder can’t set it up.

The solution: observability in plain language

Developers call it observability. For you it’s one question: how do I know my app is doing what I think it’s doing? You can borrow what the dev world knows without asking a developer to run this for you. It means knowing you’re delivering value on a consistent basis: what you say it does, it does, and when you change code, it still does. Most people assume it’s all about logs; it isn’t. It can be as simple as knowing when something breaks on your site, front end or back end, and actually finding out. Every app can get this. It’s not a huge investment. Start with what it means for your app and where you are today, then think about how that grows as the app grows.

If you do this yourself

You stay in the AI saddle longer and keep costs down. Your confidence stays up. It’s fast, easy, and surfaces issues you didn’t know you had. You stop looking like someone who can’t answer basic questions about their own app.

Developer perspective

If you build an app and don’t read the code, you won’t know what it’s doing. That’s a valid concern. When a developer says you can’t see what the app does, they’re often right. You solve it by adding observability, not by becoming the person who reads every line.

My Go To Prompts

I review codebases all the time. I’m a battle-tested CTO. I’ve built startups. Here are three prompts I use every day. These aren’t theoretical. They’re the actual prompts I run, tune, and build skills around.

1. Framing prompt

Your starting point. This tells the AI who to be before it looks at your app so the rest of the conversation stays grounded in observability that fits your situation, not generic enterprise boilerplate.

Assume the role of a code observability expert: an early principal engineer at Sentry.io with 25-30 years of experience across platforms and languages. You understand the core principles of observability, how teams overbuild in one area and neglect others, and how to right-size observability for a specific app and problem. Hold that stance as we assess what’s happening in my app.

Follow-up questions you can ask

Paste these after the framing prompt to tease out what observability means. Still no code changes.

Priority

Why is this considered the highest priority for my app right now?
If you skip

What happens if we skip this? What breaks, what do we not see, and when would we regret it?
Sentry building blocks

Sentry thinks about observability as logs, errors, events, and dashboards. For my app, where would each provide the most value, and where would it be overkill? Where would logs help first? Explain in plain language.
Dashboard

Can you outline a custom dashboard that gives me observability across the health of my app and the areas that matter most without going into implementation details yet?

2. Current state prompt

Use this after the framing prompt. You are not asking the AI to fix anything yet. You are building a picture of what observability you already have and what you are missing. That stops random changes and helps you learn what observability actually means for your app. Expect a table you can read and push back on with follow-up questions.

Using your observability expert role, review what we have built so far, our code, mission, vision, goals, and stack. Give me an overview of our current observability: what is in place, what is missing, and what matters for this app. Do not make changes yet. Return a markdown table with one row per core observability area. For each row include: the area, a score from 1-5 for where we are today, highest value / lowest effort / highest impact (rank or note), how Sentry or its components could help if there is a gap, a plain-language sentence on why it matters, and one question I should ask next to go deeper. Sort the table so the best next conversations are at the top.

Follow-up questions you can ask

Paste these after you have the table. Same chat, still no code changes. They help you judge effort, complexity, and value like a Sentry review would.

Why this order

Looking at your table, why are the top three rows ranked highest? What value do we get in the first week if we only tackle those?
If we skip it

For the lowest-scored rows, what happens if we skip them for the next 30 days: what do we not see, and when would we regret it?
Effort and complexity

For each row, estimate effort in hours (not sprints) for a vibe coder working with AI. Flag what is genuinely complex vs. what is just unfamiliar Sentry vocabulary.
Right-size it

Which rows would you call overkill for our stage, and which are non-negotiable before real users? Where do Sentry logs, errors, events, and dashboards earn their keep first?

3. Capture the Wins and Patterns

Run this when you are ready to save what you learned. It creates a markdown file in your project root so the next observability conversation picks up where you left off. You are not re-explaining your app from scratch every time.

As a senior observability expert, create a markdown file at the root of this project named observability-status.md. Document what we found in this conversation: your observations about the app, our current observability status (what we have, what is missing, scores if we used them), patterns and priorities we set, and how observability supports our mission. Write it in plain language so that in future chats about observability you read this file first and treat it as the starting context. Do not make code changes in this step, only create or update the file.

Follow-up questions you can ask

Use this if you decided on new patterns or priorities after the file was created. Same chat.

Update priorities

Take any patterns or priorities I outlined in our conversation and add or update them in observability-status.md. Keep the file aligned with what I have decided matters for this app.

What you get

If you use this, you will have an understanding of observability that matches your product, not a generic enterprise checklist. You will know where things are. That turns off the easy write-off, because you can point to what you built and how you watch it.