How much can you delegate to agents?
build mode
PostHog says trusting AI agents isn't about how smart the model is, it's about the task itself. Their framework: check two things — can you verify the output, and can you undo it — to pick one of four autonomy levels.
Based on reporting by build mode — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
There's a tempting but lazy assumption floating around dev teams right now: as models get smarter, you can just hand them more rope. PostHog's Jina Yoon pushes back hard on that, and the analogy she uses is a good one — trusting an agent more just because the underlying model improved is like ditching your seatbelt because you bought a nicer car. The model isn't the variable that matters. The task is.
Her framework boils down to two questions you ask before delegating anything: can you verify the result deterministically, and can you cheaply undo it if it's wrong? Cross those two axes and you get four levels. Level 0 is hard to check and hard to undo — sensitive, tricky code where you still want a human doing the actual work, agent as glorified autocomplete. Level 1 is hard to check but easy to undo, the zone for subjective calls like renaming a variable for clarity, where a draft PR sits until a human signs off. Level 2, easy to check but costly to undo, is where most professional dev work sits today — deterministic tests exist, but the merge itself is gated. Level 3 is the promised land: easy to check, cheap to undo, agents running unsupervised on things like dependency bumps or lint fixes.
PostHog backs this up with real examples from their own codebase. When engineer Dylan overhauled the feature flag engine to support generic property targeting, the change touched live customer flags and scoring functions in ways that couldn't be grepped for — so he did the risky core migration by hand and only delegated the safer SDK propagation work across JavaScript, PHP, Ruby and Flutter. Contrast that with Robbie rewriting their SQL parser in Rust, where he barely read the agent's output because a machine oracle could verify it — though PostHog still ran it through shadow mode in production and a staged cutover before trusting it fully, since a parser touching every query is not something you want to get wrong.
The more interesting part is the advice on how to engineer your way up the ladder rather than just accepting the ceiling. For subjective Level 1 work, they suggest LLM-as-judge setups, scoped measurable goals like hitting a 3% conversion target, or writing custom skills that encode team taste. For Level 2, the fix isn't more human gates — it's baking guardrails into the pipeline itself: dry-running by default, scoped credentials, feature-flagged rollouts, so you stop being your own bottleneck. And Level 3, still sparsely populated today, is where PostHog is placing its bets with things like Scouts, agents that run on a schedule, scan product data for signals, and draft their own PRs.
What ties it together is a shift in mindset: autonomy isn't granted to a model, it's engineered into a task. Build smaller, more checkable, more reversible tasks, and you create more room for agents to run free — regardless of which model happens to be under the hood this month.
My take — AI-written commentary, not fact-checked reporting
This is the most useful mental model I've seen for agent autonomy because it refuses the industry's favorite cop-out — 'just wait for GPT-6 to be smarter.' The real bottleneck is almost always process design, not model capability, and PostHog dogfooding this on their own SQL parser and feature flag engine makes it credible rather than theoretical. Every team obsessing over which frontier model to adopt next should instead be asking whether their tasks are even structured to be checkable and reversible — that's the unglamorous work nobody wants to do, and it's the actual unlock.
Read more about this at: build mode