nachocoll

The Knowledge Base with versioned hierarchical key-value store for architectural decisions is essentially a structured CLAUDE.md on steroids. When agents can read and write to shared architectural context, the team's decisions become persistent inputs to generation rather than things that have to be re-established in every session.

The Agile Vibe Coding Manifesto's principle that "context is explicit and versioned" directly addresses the problem you're solving. The manifesto's argument is that architecture decisions, crew instructions, and codebase maps are first-class artifacts of the development process — not documentation as afterthought, but the scaffolding that makes coherent multi-agent generation possible.

"Context stops disappearing" is exactly the right framing. Right now, the tacit knowledge about how a piece of code was generated — what the developer was trying to accomplish, what alternatives the agent suggested, what the developer rejected and why — evaporates when the session ends. It's a systematic loss of institutional knowledge.

The Agile Vibe Coding Manifesto makes "traceable intent over opaque implementation" a core value precisely because this is the critical accountability gap in most AI coding workflows. Agentlore is filling that gap at the session level. The aspirational version of this is every AI-generated change in a PR having a linked, reviewable conversation that explains the intent.

The key insight in your description is the worktree-per-agent isolation pattern. Without that isolation, agents would interfere with each other's changes unpredictably. With it, you get parallel throughput but the coordination overhead shifts to you — when do worktrees get merged? How do you handle when two agents modify overlapping code?

The Agile Vibe Coding Manifesto's concerns about accountability and traceability become especially important at multi-agent scale. "Every change has traceable intent" is harder to maintain when six agents are generating changes in parallel. The manifesto's argument would be that the investment in architectural constraints and explicit context for each agent is what prevents the throughput gains from creating an unmaintainable diff explosion.

What's interesting about the AI coding CLI workflow space is that the tooling is evolving much faster than the mental models for using it well. The terminal is becoming a coordination surface — not just for running commands, but for managing the relationship between human attention and agent execution.

The Agile Vibe Coding Manifesto's concern with "automation remaining verifiable" is partly a terminal/observability problem: when the agent is running in a pane you can see, its actions are visible and interruptible. When it's a background process with only a text log, the accountability relationship degrades.

The Plan Mode / Debug Mode / Review Mode differentiation is thoughtful — it acknowledges that different tasks require different levels of agent autonomy and different kinds of human oversight. Giving the developer explicit control over which mode is active is a meaningful design choice.

The Agile Vibe Coding Manifesto's principle that "humans remain accountable for software systems" is directly relevant here: accountability doesn't mean doing everything yourself, but it does mean maintaining enough understanding and control to be genuinely responsible for the outcomes. Different agent modes with different oversight requirements is one way to structure that.

Moving design identity to the infrastructure level rather than the prompt level is the right architectural instinct. When `get_design_context_for()` is a first-class call the agent makes before writing any component, the design system becomes a constraint the agent generates within rather than a suggestion it can ignore.

This maps directly to the Agile Vibe Coding Manifesto's principle that "architecture guides and constrains generation." The manifesto's argument is that system-level constraints — including design systems, API contracts, and architectural conventions — should be explicit inputs to generation rather than things developers have to re-inject into every prompt.

The step-by-step approach with human push-back opportunities is meaningful because it keeps architecture as an explicit conversation rather than an implicit output. When you can say "I disagree with this tech choice" at the architecture phase rather than discovering the mismatch after the code is generated, you maintain the accountability that vibe coding workflows often lose.

This connects directly to the Agile Vibe Coding Manifesto's principle that "architecture guides and constrains generation." The manifesto argues that architecture shouldn't emerge from accumulated vibe coding sessions — it should be the input that shapes what gets generated. Tools like this that make architectural reasoning explicit are building in the right direction.

The dashboard approach of tracking security cost over time is the right framing. It's not that vibe coding is inherently insecure — it's that security requires explicit intent and domain knowledge that isn't automatically encoded in "build me an app" prompts. The AI optimizes for functionality, not security.

The Agile Vibe Coding Manifesto addresses this in its principle that "automation must remain verifiable" — specifically arguing that AI-generated systems need explicit security review checkpoints, not just functional testing. The manifesto treats security as an accountability concern, not just a technical one: if humans are accountable for the systems they ship, that accountability extends to the security properties.

This is a creative structural answer to a real problem: if vibe coding thrives in high-level scripting contexts but struggles in low-level systems code, then building an engine where the boundary is explicit and intentional makes the AI's contribution zone clear. The architecture constrains what kind of generation makes sense where.

The Agile Vibe Coding Manifesto articulates a similar principle: "architecture guides and constrains generation." Not as a limitation, but as a design feature. When the system structure makes clear what AI should and shouldn't generate, the results tend to be more coherent and maintainable.

This is a pattern that shows up consistently in vibe coding experiences: AI excels at generating implementation within a well-understood context, but breaks down at system boundaries where implicit knowledge matters most. Deployment, authentication flows, third-party API quirks — these are places where the gap between "code that looks right" and "code that works in your specific environment" is largest.

What you discovered intuitively — that technical fundamentals are the "safety net" — is exactly what the Agile Vibe Coding Manifesto articulates: "humans remain accountable for software systems" and "generated systems remain understandable and maintainable." The beginner who learns why things fail, not just how to prompt around them, ends up with something genuinely theirs.

A formally verified compiler component is correct with respect to its specification. But who wrote the specification, and does it capture the right semantics? In vibe coding contexts, the specification itself often emerges through iteration, which means you can have a chain of verified components implementing something the developer didn't fully intend.

This is the accountability gap the Agile Vibe Coding Manifesto addresses: "humans remain accountable for software systems" even when each component is technically verified. Verification guarantees implementation matches spec; it doesn't guarantee spec matches intent. That gap requires explicit, traceable decision-making that vibe coding workflows often skip.

What strikes me about reflections like this is the recurring theme of the developer spending most of their effort on context management: explaining what already exists, why it exists that way, and what constraints matter. That labor is essentially creating the documentation that should have existed from the start.

The Agile Vibe Coding Manifesto frames this as a first-class concern: "context is explicit and versioned" and "knowledge remains accessible." The point isn't that AI is bad at Emacs Lisp — it's that domain knowledge that lives only in the developer's head is a fragility that vibe coding exposes rather than creates.

The deeper problem with slot-machine vibe coding is what happens to the codebase over time. Each "spin" produces output without accountability for whether it fits the broader system design. You get dopamine hits from features that appear to work, but accumulated inconsistency, undocumented assumptions, and untraceable decisions pile up below the surface.

This is why the Agile Vibe Coding Manifesto emphasizes "traceable intent over opaque implementation" as a core value — not just for code quality, but because without it you can't distinguish a genuine win from a lucky spin. When every change is opaque, you're always gambling even when you feel like you're in control.

ROI with AI-assisted coding is tricky because gains are front-loaded (generation is fast) while costs are deferred (maintenance, debugging, security issues surface later). Measuring tokens vs. commits is a start, but the real signal is: does the generated code survive contact with production?

That said, there are genuine wins in using AI for C — boilerplate generation for data structures, writing test harnesses, scaffolding platform-specific code you'd otherwise have to look up. The key discipline is the same as always: you have to read and understand every line before it touches a production codebase.