← All speakers

Bio, Work & Ideas

Greg Pstrucha

Conference affiliation: Sentry · 2026

Greg Pstrucha is a staff software engineer at Sentry and co-founder of Subroutine who builds safeguards for AI coding agents. His work on Seer, Sentry’s debugging agent, and dotagents, its open-source agent-configuration tool, addresses a practical question: how to make autonomous software development reliable, secure, and economically defensible.

Earlier in his career, Pstrucha worked on mobile infrastructure and Horizon Worlds at Meta and managed Robinhood’s API platform team. At Facebook, he contributed to engineering work on iOS out-of-memory crashes in 2015 and automatic memory-leak detection in 2016.

He subsequently co-founded Subroutine, serving as chief technology officer and developing infrastructure for secure AI applications. His work on containerized development environments led to an open-source workspace tool that isolates parallel coding agents in separate Docker environments. Git worktrees can separate files, he argues, but leave agents competing over services, ports, credentials, and privileged tools.

  • Deterministic coding-agent guardrails. Pstrucha favors type checking, linting, targeted tests, architectural constraints, and verification earlier in development. For Seer, a plausible diagnosis is insufficient if its proposed fix targets the wrong repository, fails checks, or produces poor code.
  • Agent skills as software dependencies. With dotagents, he and collaborators brought versioning, lockfiles, trusted-source policies, and shared configuration to agent skills. His security experiments identify attack paths through image metadata, helper scripts, package hooks, symbolic links, and persistent agent memory.
  • Economically defensible agent autonomy. At the Great Loops Debate, Pstrucha supported automation for well-specified tasks, security scanning, and disposable prototypes while challenging the assumption that additional agent loops automatically improve production code. Repeated nondeterministic verification can multiply errors and token costs; architectural judgment still requires deciding what should never be built.

Read the topics behind these talks

1 conference talk

Key ideas

Scroll to read ↓

A useful agent loop needs more than persistence: it needs verifiable goals, controlled permissions, meaningful feedback and an engineer who still owns the result.

  • Can a loop tell whether it built the right thing?
    0:42 ↗
  • Control, verification and cost
    7:26 ↗
  • Persistence needs an external permission boundary
    15:42 ↗
  • Existing codebases need executable constraints
    19:21 ↗
  • Verification quality and fresh context
    24:38 ↗
  • Allocate context deliberately
    30:26 ↗
  • Loom and the limits of convergence
    33:21 ↗
  • Where loop spending pays
    36:12 ↗
  • Shared memory does not settle shared authority
    39:01 ↗
  • The teaching loop needs a controller
    43:19 ↗
  • Build the factory as a product
    46:34 ↗
  • Trace intent through to production
    49:36 ↗
  • Practice, competition and the remaining model limit
    52:46 ↗
  • Stronger types and an editable supply chain
    57:00 ↗

References