Jennings's Blog

No Vibes Allowed

Published on
Last updated on
Technical
AI

Recently a new video No Vibes Allowed has challenged the previous spec-driven development; some of the points are really good. I formerly started AI code from spec; now it is time to refresh the idea.

Through several months of practice, I already found the limitations of spec. So I created a workflow to streamline development, but the starting point is the spec, not a limit on the spec. AI development is not just spec; sometimes it is very difficult to describe the details when you don’t have that knowledge.

I standardized the whole software process into 13 phases, emphasizing the research, spec/plan, and implementation. The research should include the codebase assessment and online best-practice/key paradigm research, plus curated materials to support the development process. The plan should be carried out to make sure it utilizes the report created by the research. I also created many sub-agents to manage different tasks and subagents will dramatically reduce the context window, since each agent controls its own context window, thus the main context window will not fill up quickly.

Also, multiple rounds of iterations will help improve all kinds of documents, reach a point where we have a complete understanding of the feature, and then we choose one implementation.

I used a central coordinator to orchestrate the process and monitor each sub-agent’s progress, and update the documents once each task is done. Hence, we have no worry of key information loss; we can easily create a new session to implement the feature when all the documents are complete. So with these technique the context window may be also full, we can create new session, continue implementing the same feature without resuming previous session(when I was starting AI coding, i just want to keep only one session, assume that in same session the LLM will know more details, but it proves me wrong, LLM is stateless, we should proactively manage the context window)

By employing git worktrees, we can simply create worktrees, ask different agents to implement the same feature and do end-to-end tests in different worktrees, and pick the best one to merge into the main branch. This will increase the quality of the code a little bit.

By manually compacting, we can have more control over the context window. We can decide what to keep and what to discard, and save the kept content in a Markdown file; when continuing, we can ask the agent to read this file to understand where we sit. But actually, since I use my coordinator workflow, the context window stays at 40%–60%, and I think this is the optimal range.

Notes:

  • The Core Problem with AI Agents

    • The “Slop” Cycle: Without proper context management, developers often ship code that requires immediate reworking, creating a cycle of “slop”

    • LLM Mechanics:

      • Statelessness: LLMs are stateless; they rely entirely on the current context window to function
      • Token Quality: Better tokens in = better tokens out. The only leverage points are correctness, completeness, and size of the context
      • Trajectory Issues: If an agent makes a mistake and you “yell” at it, the history shows a pattern of failure. The model may predict that the next logical step is another failure to continue the pattern

    • The “Dumb Zone”

      • Definition: The “Dumb Zone” describes the degradation in model performance as the context window fills up
      • The 40% Rule: Performance (diminishing returns) often starts to drop when the context window is filled beyond roughly 40% (varies by model)
      • Implication: If you load your context with too many logs, JSON dumps, or entire files, you force the agent to operate permanently in the “Dumb Zone”

  • “Solution 1 - Intentional Compaction**

    • Concept: Instead of letting the context window bloat, actively compress information

    • Method:

      • Start a task.
      • If the context gets too full or the agent gets lost, ask it to summarize everything meaningful into a single Markdown file.
      • Restart a fresh context window using only that summary

    • What to Compact: Focus on exact file names, line numbers, and specific findings relevant to the problem, rather than raw logs or generic summaries

  • Solution 2 - Sub-Agents for Context Control

    • Misconception: Do not use sub-agents to role-play (e.g., “You are the QA Agent,” “You are the Frontend Agent”)
    • Proper Use: Use sub-agents to fork the context window
    • Workflow:
      • Parent agent needs information.
      • Sub-agent spins up a fresh context window to read files, search the codebase, and learn.
      • Sub-agent returns only a succinct answer to the parent.
      • Result: The parent agent stays in the “Smart Zone” (low context usage) while gaining all the necessary knowledge

  • The RPI Framework (Research, Plan, Implement)

    • Overview: A three-phase workflow designed to keep context usage low and leverage high

    • Phase 1: Research

      • Goal: Understand the system without making changes.
      • Action: Find relevant files and understand code flow.
      • Output: A research markdown document.

    • Phase 2: Plan

      • Goal: Create an explicit set of instructions.
      • Content: Outline exact steps, file names, and line snippets.
      • Importance: This is the highest leverage point in the process.

    • Phase 3: Implement

      • Goal: Execute the plan.
      • Action: The “dumbest” part of the process; just following instructions.

  • Why “On-Boarding” Agents Matters

    • The Memento Analogy: Like the movie Memento, an agent wakes up with no memory. If you don’t “onboard” it (give it context), it will hallucinate or make things up
    • Static vs. Dynamic Context:
      • Static Docs: Adding a CONTRIBUTING.md or architecture doc to every repo is brittle. These docs go stale and become “lies”
      • On-Demand Context: It is better to generate compressed context on demand. Use tools/sub-agents to take “vertical slices” of the codebase relevant to the current task

  • Conclusion & Action Items

    • Don’t Outsource Thinking: AI only amplifies the quality of your thinking. A bad plan = 100 bad lines of code
    • Get “Reps”: There is no perfect prompt or tool. You must practice (“get reps”) to learn when to use heavy context engineering vs. simple prompts
    • Pick One Tool: Don’t try to min-max across every new tool. Pick one, master the workflow, and focus on leverage
Back to Blog