01 · An application, opened like a product

PREHOG

Context before employment.

This is my application for the Context Engineer role on PostHog's Wizard & Docs team — and it's also the first thing I've shipped with PostHog installed. One small system, doing both jobs at once.

02 · Why PostHog

A working style, not a logo

Every place I've done my best work shares a shape: ship in the open, keep context legible instead of hoarding it, and let real usage settle arguments instead of opinion. PostHog's engineering culture is that shape, in public.

  • Autonomy, not process theater
  • Context that's written down, not tribal
  • Small teams where writing and code are the same job
  • Shipped and observed, not polished in private

03 · Why Context Engineering

Five disciplines, one center

Context Engineering isn't a pivot for me — it's the name for the point where the disciplines I already practice converge. Software engineering, reliability, interaction design, technical communication, and AI workflow engineering all answer the same question: what does the next reader — human or agent — actually need to know?

Five things I already do. One name for the center they share.

See the evidence on /about

04 · How I work

A loop, not a waterfall

This deck was built by running the loop on itself: understand the role, structure the narrative, build the shell, instrument it, test the flows, watch what the data said, refine, document the decisions — including the ones I chose not to make.

05 · Evidence

Three artifacts, not a gallery

Selected because each one answers the same question: why is this relevant to Context Engineering?

localcrew

Local-first orchestration harness

Pools Ollama and OpenAI endpoints across a LAN into one addressable inference network — systems thinking about context and compute, not just prompt text.

View source

stay-ahead

Techniques for agent-supported development

A public, working notebook on turning documentation into something an agent can actually use — the thesis this role is built on, practiced before I knew the role existed.

View source

prehog

This page, reviewing itself

Instrumented, tested with Playwright, and documented for both readers — a README for you, an AGENTS.md for the next coding agent that opens this repo.

View source

06 · Learning PostHog through implementation

Analytics begins with questions

This page is my first production PostHog install. Before any event was named, I wrote down what I actually wanted to know. The event model below is deliberately small — and you can watch it happen live.

Question Signal
Do people meaningfully progress through the deck?prehog_slide_viewed
Where do sessions stop?prehog_slide_viewed vs. prehog_completed
Is the navigation discoverable on mobile?prehog_navigation_used + masked replay
Do reviewers inspect the repository?prehog_outbound_clicked
Does anyone let it auto-play, or take control?prehog_autoplay_toggled

07 · Context for humans and agents

One source, two readers

This repository models what it claims: the same underlying context — architecture notes, decisions, analytics rules — is written once and shaped twice. A README.md narrates it for you. An AGENTS.md structures it for the next coding agent that opens this repo.

Read AGENTS.md

08 · Why me, why now

Not a pivot — a convergence

I want a role where engineering, explanation, reliability, and AI-assisted delivery are the same job, not four separate ones. Ten-plus years of full-stack work, QA automation, internal documentation systems, and AI workflow engineering have pointed at the same center the whole time — this page and /about are the evidence, not the adjectives.

09 · Inspect the work

Source, not just slides

GitHub github.com/benmcnulty/prehog Resume benlive.tv/about Portfolio benlive.tv/portfolio Home benlive.tv

Thanks for reading this deeply. A short, real, dismissible survey may show up here — it's the only feedback interaction on this page.