← 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

References