No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer

Dex Horthy frames the central problem as a mismatch between apparent output and durable engineering progress. He describes AI-assisted software development that produces more shipped code while also creating rework, code churn, and technical debt. Straightforward greenfield projects may suit coding agents, but large, established systems present a different challenge: understanding existing architecture, navigating accumulated constraints, and making changes that do not simply create another cleanup project. 0:24

His proposed response is context engineering: improving what current models can accomplish by deliberately managing the information available in their context windows. Horthy says his three-person team spent eight difficult weeks changing how it collaborated and built software, ultimately reporting approximately two to three times more throughput. He presents that experience as a team-specific result and motivation for the workflow, not as a guaranteed outcome for every organization. 1:09

The objective extends beyond generating correct-looking code. Horthy identifies several requirements at once: agents must handle brownfield codebases and complex problems, avoid low-quality output, preserve mental alignment across the team, and meaningfully offload work to AI. Those goals can conflict when increased code generation outpaces human understanding, making collaboration and review part of the technical problem rather than an afterthought. 2:02

A common failure pattern begins when someone asks an agent to complete a task, repeatedly corrects its mistakes, and continues until the conversation becomes unwieldy. Restarting with a fresh context and clearer steering can help, but Horthy recommends a more deliberate technique: intentional compaction. The agent compresses useful information from an existing conversation into a reviewable Markdown document, allowing a new agent or context window to begin from the important findings without repeating the entire investigation. 2:52

The value of compaction depends on selecting information that materially affects the next decision. Searching for files, understanding control flow, editing code, and collecting test or build output all consume context, as do verbose tool responses. A useful compacted artifact should preserve the task, relevant files, and precise locations while removing unnecessary noise. Horthy characterizes coding models as stateless across the information not present in the current conversation, so the quality of their next action depends on the quality of the tokens available to them. 3:59

He evaluates context along four dimensions: correctness, completeness, size, and conversational trajectory. Incorrect information is the most damaging, followed by missing information and excessive noise; repeated failed attempts can also establish an unhelpful interaction pattern. His informal dumb zone describes degraded results as a context window fills: using Claude Code as an example, he suggests that diminishing returns may begin around 40 percent utilization, while emphasizing that the threshold varies with the model and task complexity. 4:52

Horthy argues that subagents are most useful as a mechanism for controlling context, not as simulated organizational roles. Instead of assigning agents anthropomorphic titles, a parent agent can delegate a bounded investigation to a separate context window. That worker performs the expensive searching and reading, then returns a concise finding—such as the relevant file—so the parent can proceed without absorbing every exploratory step. 6:34

He builds on that pattern with frequent intentional compaction, organized into three practical phases: research, plan, and implement. Research establishes how the existing system actually works and identifies relevant files. Planning converts that understanding and the requested change into explicit steps, including filenames, code snippets, and a testing approach after each change. Implementation then executes the reviewed plan while keeping the active context focused. 7:28

The workflow is not an argument that these three labels are universally necessary or permanent. Horthy explicitly says that research-plan-implement may not remain the defining sequence; the enduring principles are compaction, context engineering, and avoiding overloaded context windows. He also rejects the idea that better results come from accumulating Markdown artifacts for their own sake: documents matter only when they accurately compress relevant truth or intent and improve execution. 17:40

Persistent repository onboarding documents can give agents useful background, but they introduce a scaling problem. As a codebase grows, comprehensive instructions either become too long or omit important details, potentially consuming much of the effective context budget before the agent begins useful work. Progressive disclosure can improve this arrangement by distributing guidance across repository levels so an agent loads root-level information and only the additional context relevant to its current area. 11:54

Even carefully organized documentation can drift away from the implementation. Horthy therefore favors on-demand compressed context: steer the agent toward the relevant area, use targeted investigations to examine vertical slices of the system, and assemble a research document based on the current code itself. He describes this as compressing truth rather than relying on documentation that teams may fail to keep synchronized with shipped changes. 13:26

Planning then becomes compression of intent. A useful plan combines the research with a product requirement, bug report, or other requested change and specifies what will happen concretely enough for a human to assess the approach. Horthy says his team increasingly includes actual proposed code snippets because vague plans do not provide sufficient confidence about the resulting changes. The tradeoff is that longer plans can improve execution reliability while becoming harder to read, so each team must find a workable balance. 13:57

This review stage protects mental alignment: a shared understanding of how the system is changing and why. Horthy says code still gets reviewed, but reviewing plans can help technical leaders track evolving architecture and catch problems earlier without relying exclusively on large diffs. He also highlights the value of showing reviewers the implementation steps, prompts, and successful build evidence so they can understand the path behind a change rather than seeing only its final code. 15:03

Horthy illustrates the approach with work on a 300,000-line Rust codebase for a programming language associated with Boundary ML. He describes comparing plans produced with and without research, discarding weak research outputs, and receiving a positive response to a proposed fix. In a separate extended session on BAML, he reports shipping 35,000 lines of code over seven hours, while explicitly noting that some of that volume came from generated code and updated golden files; one pull request was merged approximately a week later. These examples are presented as specific experiences, not controlled measurements or evidence that raw line counts equal productivity. 8:15

The limitations are equally important. An attempt to remove Hadoop dependencies from Parquet Java did not initially succeed, and Horthy says the collaborators ultimately returned to a whiteboard after identifying the system’s pitfalls. His conclusion is that AI cannot replace the underlying engineering judgment: it amplifies the thinking already invested in the task, and a misunderstanding in research can misdirect an entire implementation while a flawed plan can produce many flawed lines of code. 9:02

The appropriate amount of process depends on the change. Altering a button color may need only a direct instruction; a small feature may require a simple plan; work spanning multiple repositories may justify dedicated research followed by planning; especially difficult problems can demand still more context engineering. Horthy argues that learning this calibration takes repeated practice, recommends becoming proficient with one tool instead of continually optimizing across several, and identifies organizational adaptation as the longer-term challenge: teams need leadership, review practices, and shared workflows that prevent faster generation from becoming someone else’s cleanup burden. 17:40