← All speakers

Bio, Work & Ideas

Dex Horthy

Conference affiliation: Co-Founder · HumanLayer · 2026

Dex Horthy is the co-founder and chief executive of HumanLayer, which builds collaborative AI-powered development tools for engineers working in complex codebases. He created 12-Factor Agents and helped establish context engineering as a practical discipline for making coding agents reliable without sacrificing architectural judgment or maintainability.

From enterprise infrastructure to coding agents

Horthy started programming in high school at NASA’s Jet Propulsion Laboratory. He subsequently spent seven years at Replicated, progressing through engineering, solutions engineering, product, and executive responsibilities. His work included container orchestration and helping companies including HashiCorp, DataStax, and H2O.ai deliver self-hosted Kubernetes products.

HumanLayer joined Y Combinator’s Fall 2024 batch. Its initial product let agents request human approval or clarification through Slack, email, and SMS—a response to Horthy’s experience building automation capable of taking consequential actions, such as deleting unused database tables. Initially a solo founder, he later brought on Kyle Mistele as co-founder and chief technology officer. The company expanded from approval infrastructure into a collaborative engineering environment for teams adopting coding agents.

  • 12-Factor Agents makes reliability an engineering problem. Horthy’s open-source framework treats agents as conventional software augmented by carefully selected model decisions. Engineers should control prompts, context, execution state, and orchestration; interpret tool calls as structured outputs executed by deterministic code; and build workflows that can pause for human approval. Small, focused agent loops belong inside dependable systems, not above them.
  • Context engineering depends on evidence, not volume. Horthy argues that incorrect information, missing details, stale documentation, and noisy tool output degrade agent performance. His practice of intentional context compaction distills repository research into concise, reviewable artifacts containing the relevant files, behavior, and implementation constraints. Subagents help by investigating independently and returning compact findings; assigning them fictional organizational roles adds little.
  • Research, Plan, Implement preserves shared understanding. His workflow for established codebases separates investigating the actual system, preparing explicit implementation and verification steps, and executing the reviewed plan. Beyond improving model output, the approach maintains human mental alignment: engineers can understand how their codebase is changing before reviewing extensive generated diffs. Horthy demonstrated the method on the BAML Rust codebase while acknowledging its limits when an attempt to remove Hadoop dependencies from Parquet-Java required renewed architectural analysis.

Horthy continues experimenting directly with developer tooling, including shannon, which manages interactive coding-agent sessions through tmux. His central conviction is that faster software delivery remains valuable only when engineering teams retain responsibility for the systems they ship.

Talks by Dex Horthy

4 talks

Key ideas

Scroll to read ↓

Dex Horthy explains how intentional context compaction, targeted research, explicit implementation plans, and human review can help coding agents work more effectively in existing codebases without sacrificing team understanding.

  • Optimize an agent’s context for correctness, completeness, manageable size, and constructive trajectory; incorrect information is more damaging than missing information or excess noise. 4:52 ↗
  • Use intentional compaction to preserve relevant findings, files, and implementation details while starting fresh context windows without repeating exploratory work. 2:52 ↗ 3:59 ↗
  • Treat subagents as isolated research contexts that return concise findings, not as fictional frontend, backend, or QA teammates. 6:34 ↗
  • Ground research in the current code, then create explicit plans with concrete changes and tests; review those plans to maintain mental alignment and catch mistakes before they multiply. 13:57 ↗ 15:03 ↗ 15:46 ↗ 16:42 ↗
  • Scale the workflow to the task: simple changes may need no formal research, while complex or cross-repository work can benefit from deeper investigation and repeated compaction. 17:40 ↗
  • Keep humans responsible for architectural reasoning and organizational change: coding agents can amplify sound judgment, but they cannot substitute for it. 10:00 ↗ 16:42 ↗ 19:24 ↗

Key ideas

Scroll to read ↓

Dex Horthy reduces an agent to structured model output, deterministic execution, explicit state, and a controlled loop—then shows where small doses of model judgment outperform a free-running agent.

  • Use an agent only where model-driven judgment adds value. If the correct procedure is already an exact sequence, deterministic code may be faster to build and easier to trust.
    0:45 ↗
  • Treat tool use as structured model output followed by application-controlled execution. Own the dispatcher, loop, branching, and termination rules.
    3:44 ↗
  • Persist execution and business state outside the model so long-running workflows can pause, receive callbacks, and resume through ordinary APIs.
    7:14 ↗
  • Context engineering means selecting and representing prompts, history, memory, retrieval, results, and errors—not filling the largest available context window.
    9:14 ↗
  • Embed focused three-to-ten-step agent loops inside deterministic workflows, with explicit human clarification, correction, and approval paths.
    11:13 ↗
  • Prefer tooling that generates inspectable, owned scaffolding and removes peripheral work without hiding prompts, context, state, or control flow.
    14:44 ↗

Key ideas

Scroll to read ↓

Coding agents can shorten implementation while leaving maintainability unmeasured. Safer acceleration starts with understanding the training signal, then moving human judgment earlier in the development process.

  • When faster coding meets production
    0:47 ↗
  • The factory already had loops
    3:37 ↗
  • Automation moves the bottleneck
    6:01 ↗
  • The cost of returning to unread code
    7:25 ↗
  • Why training in the harness matters
    10:13 ↗
  • What passing tests teaches
    11:21 ↗
  • Architecture sends its bill later
    13:11 ↗
  • Turn review back on, then move decisions earlier
    14:48 ↗
  • Design the program before slicing the implementation
    15:59 ↗
  • Review overload is also a rework problem
    17:01 ↗
  • Build within the constraints
    17:54 ↗

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