Skip to content
Innovation & Growth Talking point

Turn the corrections you keep repeating to a coding agent into automatic checks

Sentry's Greg Pstrucha says agents forget, so rules belong in the code, and agents can now write those rules.

W
WebPulse Newsroom
AI-assisted · 2 min read
Share on X LinkedIn
Turn the corrections you keep repeating to a coding agent into automatic checks
In brief
  • Pstrucha argues that coding agents forget corrections, so teams should turn the ones they repeat into automatic checks such as lint rules.
  • He said agents can write those rules, and he has an agent mine past transcripts and reviews for candidates. He also said code review stays for now.

Turn the corrections you keep repeating into automatic checks, where a rule can catch them. Greg Pstrucha, a staff software engineer at Sentry, made this case on the AI Engineer show. He is on the team building the platform under Seer, Sentry's debugging agent. His argument: agents forget, so the rules must live in the code.

What was said

Pstrucha described a loop. He points out a mistake, and the agent agrees and fixes it. Then compaction happens, meaning the agent's earlier conversation is trimmed to fit its limit, and the mistake returns. He listed the usual culprits: overly defensive code, tests that test nothing, and endpoints nobody needs.

His thesis is to stop re-prompting and write the agent's rules down as checks in the codebase. He named three tools: tests, strict typing and linters, a linter being a program that flags broken rules. He focused on linters, because "the things that are writing code do not have any memory and are going to make the same repeated mistakes over and over again."

Before agents, he said, a custom linter carried a maintenance cost, and people remember a reminder. Pstrucha argues the cost of writing such a rule has now fallen, because an agent can draft it. He also has an agent review his past transcripts and review feedback, and propose which corrections make good rules.

At Sentry, an older Django codebase without strict typing everywhere, the API had drifted from its OpenAPI schema, the written description of what each endpoint does. His team added three rules. Endpoints must declare a response type, carry a schema decorator, and match the schema.

Why it matters

Our reading: every correction a reviewer repeats is a candidate rule, and corrections left in chat threads vanish when the agent's context resets. If Pstrucha is right that rules are now cheaper to write, the key input is noticing a repeated mistake and stating it precisely enough to check. Managers could ask whether review comments become rules or are simply typed again.

The other side

Pstrucha did not claim checks are enough. He said tests, types and linters are not total solutions. Strict typing alone still leaves a team in a bad place if it permits states nobody wants. He also said the goal is not to remove code review quite yet.

For qualitative quality, which a rule cannot score, he said engineers must draw on their experience, or what Twitter calls taste. He warned that an agent given a number will optimize hard for it, so a metric can be gamed. His cost claim is his own view; the excerpts offer no measurement or long-term upkeep data.

Written by the WebPulse Newsroom with AI assistance, and checked by our editorial review: every quotation was verified against the recording's transcript. How we use AI.

The conversation this talking point comes from

Share this insight