Comprehend First, Code Later: The AI Skill I Rely On Daily

What changes when a software engineer starts managing agents instead of writing the code herself? Priscila Andre de Oliveira introduces her daily work at Sentry through that change of role. Living in Vienna, a parent, a Verdaccio npm registry maintainer and a ViennaJS co-organizer, she has given herself a promotion from senior software engineer to “agent manager”—without a salary increase. Her colleague Dominic Dorfmeister captured the arrangement in a photograph: Priscila at her desk, managing agents across three monitors.

She reports that since December 2025, she has worked by prompting rather than coding directly. Even the presentation was created by a skill. Her contributions with Claude include bug fixes, features, refactors and changes across repositories. Generating code has become part of the workflow; responsibility for what enters the codebase remains hers.

Sentry’s scope makes that responsibility concrete. Known for error and performance monitoring, it has expanded into observability, including metrics, profiling and tools for monitoring agent applications. Priscila describes a company founded in 2010, with more than 15 years of code, around 400 employees worldwide and 100,000 organizations depending on it. This is also the codebase that pays her salary: keeping it working is a direct, personal reason to care about what agents produce.

That concern has not stopped experimentation. A Sentry hackathon gave employees several days to get familiar with AI and try new projects. The resulting tools address different parts of everyday engineering:

• Abacos: tracks internal AI usage.
• Warden: reviews code in pull requests.
• Junior: can be triggered in Slack when a thread raises a bug or questions a UI change. Priscila describes it analyzing the thread and creating a corrective PR.

The useful starting point for Junior is the conversation people are already having: a complaint, an unexpected change or a bug report supplies context for an investigation.

The AI SDK integration testing repository predates that hackathon. It contains tests for Sentry’s AI integrations, and it gave Priscila a more demanding introduction to agent-assisted work: her team asked her to contribute only through prompts, continuing until she obtained a satisfactory result. These tools became part of daily internal use, rather than remaining hackathon experiments.

AI adoption sits alongside deliberate maintenance. Priscila reports that Sentry devoted a three-month quality quarter in the preceding year to improving its codebases. The work included removing TypeScript any types, addressing accumulated TODO comments, simplifying code and removing unused feature flags. These are concrete ways to reduce technical debt and keep the code understandable as it evolves.

Priscila reports about 100 merged PRs per day, with contributions across four offices and from outside contributors to Sentry’s fair-source codebase. Components are deprecated, replacements appear and lint rules change. Even after more than six years at Sentry, she can return from vacation to a PR full of conflicts. Resolving those conflicts requires more than reconciling lines: she needs to catch up with the conventions and decisions that changed while she was away.

Understanding is therefore a daily engineering task. Priscila cites an unspecified study estimate of 70% of developer time spent reading and navigating code; that figure depends on the study and its definition of comprehension. Her practical point is that engineers already spend substantial effort understanding existing systems. AI offers a way to recover that understanding faster.

Telling an agent to explore a repository and then make a change leaves an important gap: the agent may have misunderstood what it found. The engineer needs enough understanding to steer the investigation. Otherwise, a plausible explanation can carry a mistaken assumption straight into implementation.

Priscila’s examples concern recovering context that previously required manual investigation or waiting for another person:

For incident investigation, she says a short prompt can now return context in seconds. For product questions, a colleague in another time zone might previously have replied the next day. These are examples from her own workflow: the productivity gain she emphasizes is reaching an informed understanding sooner.

As the same questions recurred, Priscila asked Claude to analyze her local cache of 116 sessions. It classified her activity into comprehension, modification, process, review, generation and other. In that personal analysis, she reports 67% comprehension and 2% code generation. The percentages describe her classified usage; she does not specify the denominator or classification procedure, so they should not be read as shares of working time.

Those repeated prompts became Catch Me Up, a skill stored locally on her computer that she could share if she wished. The slide groups its exploration areas into Architecture, Convention, Feature trace, Syntax / API, Testing and History. The command /catch-me-up gives her a reusable entry point for questions about structure, behavior, tests and past decisions.

The packaging is simple: a Markdown file containing a detailed natural-language prompt with clear goals. Because much of Priscila’s work is on the front end, she favors visual explanations. The skill asks for structures she can inspect—an organizational diagram, a flow or a table—instead of relying only on paragraphs. A compact instruction file following that approach could look like this:

# Catch Me Up

Help me understand the repository before proposing changes.

Explore the area relevant to my question:
- Architecture
- Convention
- Feature trace
- Syntax / API
- Testing
- History

Explain the relevant structure with a flow or table.
Answer my specific question directly.

The reusable part is the combination of an exploration goal and an explanation format that helps the person understand the result.

The demonstration returns to the unfamiliar AI SDK testing repository where Priscila had been asked to contribute only through prompts. She shows a prepared run, avoiding the risk of a live run failing during the presentation. Using Claude Opus, she asks for orientation as a new contributor and adds a concrete question: does the repository simulate a Sentry envelope and intercept it during tests?

The output provides a summary and a flow explaining how the repository works. It also corrects the premise of her question: the prepared answer says the tests intercept real envelopes rather than simulate them. The answer begins describing a spawned collector, but Priscila does not walk through its remaining details. The important distinction is where the test data comes from: a simulated envelope would be constructed for the test, while this answer describes capturing a real one. That is the prepared demo’s explanation of the repository, not a claim that its current revision has been independently checked.

This is useful because the output changes what she understands before she contributes. Without that assistance, she would need to establish the same facts herself. She distinguishes experimenting on a vibe-coded project from shipping code at work that she does not understand. The skill also helps with PR review: knowing the surrounding project is not always enough to approve a particular change, so she uses it to recover the missing context before making that decision.

In Vibe Coding Our Way to Disaster, Jake Nations draws on Rich Hickey’s Simple Made Easy philosophy. Priscila describes the proposed workflow as research, planning and implementation—a familiar division for anyone using Claude Code’s planning mode. She agrees with those phases but adds an explicit human checkpoint: understand the research before authorizing the plan.

The resulting procedure is straightforward:

1. Research: have the agent explore the relevant code and context.
2. Comprehend: read the findings and establish your own understanding. Redirect a mistaken interpretation or request more investigation where context is missing.
3. Plan: once the understanding is sound, ask the agent to propose the change.
4. Implement: proceed with the agreed direction.

The comprehension step can send the work back into research. Its purpose is to make sure the person directing the agent can recognize when the investigation has gone the wrong way, before that direction becomes code.

Armin Ronacher, Flask’s creator and a former Sentry colleague, raises the same concern in The Final Bottleneck: people are reporting that they no longer know what code is in their own codebases. Priscila’s response is to make comprehension the central benefit of AI assistance in a large codebase. Faster generation does not remove the need for someone to understand the result.

Her usage analysis surprised her, and she invites others to inspect their own patterns. Recurring questions may reveal where a reusable skill would help most. AI can be a tireless teammate for those questions, including the ones an engineer might hesitate to ask another person. Use that availability to align your mental model before prompting for changes—and protect the codebase that pays your salary.

She closes with “ship kino code,” her counterpoint to shipping slop, and discloses that the talk is sponsored by Sentry. The audience invitation was to visit Sentry’s downstairs booth and scan a QR code for a three-month trial of its business plan.