Vibe coding is incredibly productive.

You describe what you want, an AI agent generates code, you iterate, fix a few issues and move forward faster than a traditional development process would usually allow.

But after working this way for some time, a deeper problem appears.

The AI may write code quickly, but it does not automatically understand:

  • why the architecture looks the way it does,
  • which conventions the project follows,
  • which previous approaches failed,
  • which decisions must not be reopened,
  • which files should remain untouched,
  • or how success should actually be verified.

This is where vibe coding starts to break down.

The problem is not always the intelligence of the model.

The problem is that the development process has no durable memory.

The amnesia problem in AI-assisted development

A normal AI coding session often starts from almost zero.

You explain the repository, architecture, constraints, naming conventions and current task. The AI performs reasonably well.

Then, a few days later, you start a new session and explain many of the same things again.

The model may be different. The conversation history may be missing. Previous corrections may no longer be visible. Important decisions may have disappeared into chat history.

The result is familiar:

  • duplicated utilities,
  • unnecessary abstractions,
  • inconsistent naming,
  • changes outside the requested scope,
  • untested claims that “everything works”,
  • and architectural decisions that are repeatedly reopened.

This is not necessarily a model failure.

It is a workflow failure.

What Hermes Agent gets right

I recently reviewed the architecture described in Hermes Agent for Dummies and compared it with my own work using AI coding agents.

The most interesting idea is not Telegram integration, desktop chat or another chatbot interface.

It is the separation between the model and the agent.

The model is only the reasoning engine.

The agent is the broader system around it:

  • identity,
  • memory,
  • reusable skills,
  • tools,
  • execution environment,
  • scheduling,
  • safety controls,
  • and feedback loops.

Hermes treats memory and procedures as durable assets. The model can change while accumulated knowledge remains.

That concept has significant implications for vibe coding.

A better architecture for vibe coding

Instead of treating AI coding as one long conversation, we can structure it as a controlled engineering process.

For example:

Requirement
→ Project context
→ Implementation plan
→ Human approval
→ Code generation
→ Automated verification
→ Independent review
→ Knowledge update

This changes the role of AI.

The AI is no longer only a code generator.

It becomes part of a repeatable engineering system.

1. One profile per project

A single general-purpose agent eventually mixes contexts.

Backend conventions get mixed with frontend preferences. One project uses PostgreSQL, another SQLite. One repository prefers Rust modules, another a .NET modular monolith. One project wants strict release discipline, another is still an experiment.

Hermes profiles solve this by giving each agent its own configuration, identity, memory, skills and history.

For software work, that could mean separate contexts for:

  • each major product,
  • architecture,
  • implementation,
  • security review,
  • documentation,
  • or experimentation.

The goal is not to create more bots.

The goal is to prevent context contamination.

2. Project memory instead of repeated explanations

Every project should have a small, explicit memory layer containing stable facts:

Technology stack
Architecture principles
Naming conventions
Security constraints
Known limitations
Decisions already made
Things the agent must not change

In Hermes, critical information is kept in compact memory files that are always loaded, while longer conversation history remains searchable.

The same principle works for coding.

Not every detail belongs in the prompt.

But important constraints should always be present.

If the agent must repeatedly be told the same rule, the rule probably belongs in project memory or in a skill.

3. Skills as engineering playbooks

This is probably the most useful idea.

A skill is not a fact.

It is a procedure.

Examples for development work could include:

  • safe feature implementation,
  • repository onboarding,
  • bug investigation,
  • database migration,
  • Rust module refactoring,
  • security diff review,
  • release verification,
  • dependency upgrade.

A skill can define:

When to activate
What steps to follow
Which pitfalls to avoid
How to verify the result

Hermes stores skills as reusable Markdown playbooks and loads their full content only when relevant.

This means every correction does not need to disappear into chat history.

A useful correction can become a permanent development rule.

4. Learn from corrections

One of the strongest ideas in the Hermes approach is that an agent can turn difficult tasks and user corrections into reusable skills.

For example:

AI proposes the wrong repository pattern
→ developer corrects it
→ the correct pattern is added to a skill
→ the same mistake should not happen again

The point is not that the model magically trains itself.

The point is that the workflow captures experience.

Over time, the system learns the project-specific way of working.

This is especially important in long-running repositories, where the most valuable knowledge is often not in the code itself, but in the reasons behind the code.

5. Separate planning, implementation and review

Vibe coding often fails because the same agent:

  • interprets the requirement,
  • designs the solution,
  • writes the code,
  • tests it,
  • and evaluates its own work.

That is too much trust in one reasoning process.

A better pattern is:

Architect Agent
→ creates the plan

Implementation Agent
→ performs the approved change

Review Agent
→ independently inspects the diff

The human remains responsible for approval.

This creates a lightweight separation of duties without removing the speed advantage of .

It also changes the question from:

Did the AI say it is done?

to:

What evidence shows that the change is correct?

6. Deterministic verification must stay deterministic

AI should not verbally claim that a build or test passed.

It should run the actual checks.

For example:

cargo fmt --check
cargo clippy
cargo test
npm run build
git diff --check

The output should be captured as evidence.

This is important.

Reasoning belongs to the AI.

Verification belongs to tools.

A model can explain why a test should pass, but the test runner decides whether it actually passes.

7. Independent review of every significant change

After implementation, another agent can inspect:

  • the diff,
  • affected modules,
  • missing tests,
  • security impact,
  • unrelated changes,
  • dependency additions,
  • rollback risk.

The developer then reviews both the code and the AI reviewer’s findings.

This does not need to be heavy process.

Even a short independent review can catch the common failure modes of AI-generated changes:

  • doing more than requested,
  • silently changing behavior,
  • adding dependencies without reason,
  • missing edge cases,
  • or producing code that looks correct but was never exercised.

8. Build a project knowledge base

Long-term projects accumulate more than code.

They accumulate:

  • architecture decisions,
  • rejected alternatives,
  • security assumptions,
  • deployment lessons,
  • incidents,
  • test results,
  • product ideas,
  • research.

A Markdown-based project wiki, maintained by AI but stored in Git, can become the institutional memory of the project.

For development teams, this may be more valuable than generating another thousand lines of code.

The next productivity gain may not come from making models write more code.

It may come from making sure the system remembers what has already been learned.

Vibe coding should become evidence-based

The next evolution of vibe coding is not simply a stronger model.

It is a stronger process around the model.

A mature AI-assisted engineering workflow should be able to answer:

  • Why was this change made?
  • Which rules did the agent follow?
  • What files were modified?
  • Which tests were executed?
  • What evidence proves the result?
  • What was learned for the next iteration?

Without those answers, vibe coding remains fast improvisation.

With them, it becomes a real engineering discipline.

Final thought

The biggest opportunity is not to make AI write more code.

It is to make sure that every correction, decision, test and successful workflow becomes part of the system.

That is how vibe coding moves from:

Prompt → code → hope

to:

Context → plan → implementation → verification → review → learning

And that is the point where AI-assisted development becomes much more than autocomplete.