Alex Lebedev

Alex Lebedev is an AI product engineer at PostHog who built and launched Replay Session Summaries, a system for analyzing how people experience software. His work addresses a concrete problem with automated product analysis: an exception can look serious to a language model even when the user completes the task. He has also orchestrated sandboxed coding agents to investigate and fix problems in customers’ products, extending automated analysis toward proposed changes.

From extracting data to interpreting behavior

Alex’s career spans digital marketing, data extraction, and product engineering. In his 2022 Extract Summit slides, he described more than seven years in digital marketing as an analyst and manager, alongside more than seven years of full-time programming experience, including three at Zyte. By then, he was a software engineer at Hotjar.

That presentation explored an unusual application of data extraction: understanding how air alerts interrupted daily life in Ukraine. Alex built an open-source collection project that checked public Telegram channels every five minutes and stored new alerts. Historical records made it possible to investigate the time available for work, sleep, and other activities between interruptions.

At Hotjar, Alex helped introduce AI into the Voice of Customer team’s products, experimenting with language models when the team had little prior AI expertise. He later joined PostHog, where his work includes automated analysis of session recordings. His GitHub profile describes building with language models since GPT-3 and reports that Replay Session Summaries has analyzed more than one million recordings for over 5,000 organizations.

Checking a diagnosis against the user’s experience

Alex’s Session Summaries engineering account explains why event logs alone could produce misleading diagnoses. Models interpreted alarming exceptions as evidence of failure even when users had completed their tasks. Filtering noisy events did not resolve the problem, so the system added short video clips around suspected failures to check what users actually experienced.

The engineering choices address different parts of that problem:

• Combine events with visual evidence. A recording can show a stalled screen, while event data can reveal an underlying timeout. Together, they help connect a technical event to its effect on the person using the product.
• Keep the user journey intact. Splitting a session into independent parallel analyses can remove the context needed to interpret an action. Alex favors preserving the journey where possible, accepting limits on parallelization to retain that context.
• Recover useful work after failures. Temporal activities, retries, and cached intermediate results allow analysis to survive individual model-call failures. A partial report can remain useful when an all-or-nothing pipeline would return nothing.

These decisions explain the work beyond the choice of model: the system needs evidence that a problem affected the user, enough surrounding context to interpret it, and a way to retain completed analysis when another step fails.

From analysis to proposed fixes

PostHog Self-driving connects product signals—including errors, session recordings, and support conversations—with codebase context. It groups problems into reports and sends actionable work to coding agents in cloud sandboxes, which prepare changes for review. Branch protections, continuous integration, and human merge decisions remain part of the process.

Alex’s contribution includes orchestrating sandboxed runs using Claude, Codex, and GLM on Modal. On his GitHub profile, he reports more than 446,000 such runs to research and fix issues in customers’ products. That orchestration work sits alongside the session-analysis system he says he built and launched solo: one interprets product behavior, while the other gives agents an environment in which to investigate and act on problems.

His smaller project BeatWombat applies a neural network to music, analyzing tracks to assemble playlists that match a person’s running, walking, or jumping rhythm. It reflects another application of his work with data: turning analysis into a specific product behavior.