Generated by Codex with GPT 5.6 Sol XHigh

The Pragmatic Engineer surfaced this piece in its July 15, 2026 podcast episode, Context engineering with Dex Horthy. Gergely Orosz’s conversation with the HumanLayer cofounder is nominally about giving language models better context, but its deeper subject is how software teams can use coding agents without losing control of the systems those agents modify.

The central claim is that a stronger prompt is rarely the whole answer. Reliable agent work depends on managing an information system: what enters the context window, what stays out, how state is compressed between sessions, what feedback the agent can observe, and where a person must still make the consequential decisions. Horthy’s experience is especially useful because it includes both ambitious automation and a failed experiment in shipping code nobody understood.

A Context Window Is Not a Warehouse

The phrase “context engineering” describes the work of assembling enough accurate, relevant information for a model to solve a task while keeping the session focused. Horthy reduces that problem to four variables: context size, information quality, missing information, and trajectory.

Size matters, but the advertised maximum is not a target. Horthy says performance often degrades well before a model’s context window is full; his practical response is to learn where a given model enters what he calls the “dumb zone.” Past that point, the agent becomes less disciplined, overlooks relevant details, or makes increasingly strange changes. A million-token window therefore does not make a model proportionally smarter. It gives the system more capacity whose contents still need to be curated.

Quality matters because every mistaken assumption placed in context can influence all later decisions. Missing facts create the opposite problem: the model fills gaps with guesses that may look locally plausible but steer the work in the wrong direction. Trajectory captures the path dependence of an autoregressive conversation. Once a session has accumulated corrections, defensiveness, and repeated failure, another turn may reinforce that pattern instead of repairing it. Horthy treats stock agreement such as “you’re completely right” after repeated mistakes as a signal to preserve the useful state and start a clean session.

This reframes a common failure mode. Teams often respond to weak output by adding more instructions, logs, files, and chat history. But indiscriminate accumulation can make the signal harder to find. Context engineering is selective: supply the smallest body of high-quality evidence that makes the next decision plausibly solvable.

Compaction Becomes an Engineering Interface

For complex work, Horthy favors frequent, intentional compaction rather than one heroic conversation. One session may explore a codebase and emit a research document. A fresh session turns requirements and that research into a design. Another converts the approved design into an implementation plan. The human reviews the architecture and other high-leverage choices before agents begin producing large volumes of code.

The Markdown artifacts are not merely summaries. They are interfaces between stages, much like an API boundary between services. Each document should carry forward verified facts, decisions, constraints, and unresolved risks while dropping noisy exploration. A clean session then receives a deliberate starting state instead of inheriting every detour from the session that came before it.

This approach also makes failures easier to locate. If implementation drifts, the team can ask whether the research missed a dependency, the design made a bad tradeoff, or the plan failed to preserve a constraint. Without those boundaries, all three kinds of error blur into one long transcript.

The episode connects this practice to Horthy’s open-source 12-Factor Agents work. The durable idea is to own the control flow and treat the model as one component inside a testable system. Prompts matter, but so do state transitions, tool outputs, stop conditions, and the representation handed from one step to the next.

Slow Loops Beat Unsupervised Speed

HumanLayer’s preferred automation is deliberately modest. A nightly agent selects a bounded code-quality task, implements it, and opens a pull request for a person to review in the morning. The team gradually expanded the setup to four agents producing four reviewable pull requests. The loop is useful because it converts unattended hours into a small queue of inspectable work, not because it removes ownership.

That restraint comes from experience. Horthy describes an earlier project in which models wrote code that humans stopped reading. Within months, production failed because a primary key had been threaded incorrectly through the codebase. The agent could not find the architectural cause, and the team had to understand unfamiliar, machine-generated code under pressure. Fixing the immediate defect was only part of the cost; rebuilding human comprehension took weeks.

The failure exposes a gap in common coding-model evaluations. A benchmark can reward a model for producing a patch that makes a test pass. It has far more difficulty measuring whether a sequence of individually successful patches erodes the design of a system over time. Correctness today and maintainability across the next twenty features are different objectives.

Feedback loops therefore need caps, escalation paths, and humans who retain a working model of the software. Tests, telemetry, support tickets, and incident data can help an agent detect and repair faults. They cannot guarantee that anyone will understand the system when the feedback loop encounters a novel failure at three in the morning.

The Human Role Moves Upstream

Horthy sketches three versions of an AI “software factory.” One turns the lights off and accepts unread generated code; his own attempt ended badly. Another reviews every generated line, keeping comprehension but limiting throughput to human review speed. The third concentrates people where judgment has the highest leverage: requirements, design, architecture, risk, and the boundaries of the work. Agents handle more implementation, while humans inspect the decisions and evidence that determine whether the output can be trusted.

His estimates of productivity gains are experience-based rather than universal benchmarks, but the tradeoff is sound. Removing review creates apparent speed by borrowing against future understanding. Reviewing everything preserves the old bottleneck. The more promising middle path changes what gets reviewed: not every keystroke, but the specification, system shape, risky changes, evaluation results, and samples that reveal whether the process is drifting.

The episode’s most useful takeaway is that AI-assisted engineering is becoming less about phrasing requests and more about designing reliable flows of information and responsibility. Good context is curated, compacted, and refreshed. Good loops are bounded, observable, and able to stop. Good automation leaves the team with more leverage without leaving it ignorant of its own software.