VIBE APP: keeping the thread while AI accelerates
An open experiment about context, scope, memory and verification in day-to-day work with coding agents.
VIBE APP is not meant to be another coding agent. It is an experimental tool placed between human intent and agent execution, designed to make decisions, limits, results and learnings visible. Features and hypotheses may change; mistakes are part of the experiment.
Nine steps to find your way
Can speed become a boomerang?
Coding agents make it possible to produce changes very quickly. The risk is not that every change is wrong; it is that the project changes faster than we can understand, verify and remember it.
Make a few important things explicit
The hypothesis è modesta: un'attività gestita con AI può essere più controllabile se, prima dell'esecuzione, rende espliciti obiettivo, contesto, perimetro, vincoli e criteri per giudicare il risultato.
It does not mean making every request heavy. It means finding the minimum amount of structure that prevents having to reconstruct everything afterwards.
A space between intent and execution
Intent
What we want to achieve and why it is worth doing now.
Scope
Which parts the agent may touch, and which it must leave alone.
Trace
What was actually requested, decided and implemented.
Verification
How to distinguish a completed result from one that is merely plausible.
VIBE APP tries to collect these elements without replacing the tools that write code. The agent remains the executor; direction and judgement remain human.
It does not measure “how much the AI worked”: it tries to make the points that require a decision visible.
Mockup, not roadmap. Some features may become part of VIBE APP, others may remain separate experiments, and others may be abandoned.
One step at a time
The cycle non è prescritto come metodo universale: è la sequenza che sto verificando nel lavoro reale. L'idea è osservare dove nasce una deviazione prima che diventi difficile ricostruirla.
“I want to migrate VAT calculation to the new engine.”
Before the code, I try to make the intended result explicit. It is still an incomplete request, but at least it states the direction.
Four files involved, one dependency, high risk.
The agent states what it thinks it needs to touch before doing it. This is the moment when I can notice that it interpreted the request differently from what I intended.
The work stays inside billing/.
The scope is not there to stop the agent from reasoning. It is there to make it visible when execution asks to go beyond what I had approved.
Diffs, tests and deviations before acceptance.
The result is not “finished” just because the code compiles or the agent says it is done. I try to see what actually changed and relative to which original intent.
Independent does not mean harmless
Two activities can be functionally independent and still interfere if they change the same files, modules or architectural decisions. That is why VIBE APP distinguishes dependencies from interference.
The cautious rule today is to avoid multiple writers working on the same scope at the same time. It is not a final solution: it is temporary protection until more reliable signals exist for governing parallel work.
core/logging/format.py e billing/invoice.py were not in the authorised scope.
python-dateutil 2.9.0 was introduced without prior request: a decision is needed before accepting it.
billing/tax/engine.py supera la soglia che avevo scelto come segnale di attention.
The point is not to prevent the agent from deviating. It is to make the deviation visible before it becomes an implicit decision.
Do not keep everything: keep what changes decisions
Chats, prompts, code, notes and documents produce more memory than can realistically be used. Useful memory should separate the current state, decisions that change the project, recurring rules and the history needed to avoid repeating an error.
Where we are
What exists today, with which limits and dependencies.
Why
Choices that would be costly or risky to lose.
How we work
Constraints that recur across activities and sessions.
What changed
Errors and checks that changed the way of working.
Observations, not verdicts
More tightly bounded tasks make it easier to verify a change and reconstruct why a decision was made.
Asking for an assessment and a plan before the patch reduces surprises about scope.
How much structure improves the result before it becomes an excessive cost.
What the minimum useful memory is for resuming a project with a new agent.
These observations do not yet demonstrate a methodology. Their main value is helping formulate the next experiment.
The same problem seen from different angles
VIBE APP does not exist in isolation. Some questions I am exploring here already emerged in other LAB experiments, while others are opening new branches. I do not yet know whether they will converge into a single system; for now I want to understand what each piece genuinely adds.
Prompt Builder
Prova a rendere espliciti obiettivo, contesto, perimetro, vincoli e criteri di verifica prima che una richiesta venga consegnata all'AI. The question resta aperta: quanta struttura aiuta, e quando diventa burocrazia?
Open Prompt Builder →Local AI
I am exploring whether some bounded tasks can be entrusted to a local model. It is not a switch: model selection, context, datasets, possible fine-tuning and validation can make this path much less immediate than it first appears.
VIBE APP
It tries to keep intent, scope, decisions, verification and memory visible while different tools perform the work.
The question non è soltanto “posso far girare un modello in locale?”, ma “quanto lavoro serve perché quel modello diventi sufficientemente competente sul mio progetto?”
In some cases, providing the right context at the right time may be enough; in others, deeper specialisation may be needed, up to fine-tuning. Understanding when fine-tuning adds value, and when it only adds cost and complexity, is itself part of the experiment.
What I still do not know
- How much should an agent know before changing a project?
- How structured should a prompt be?
- When does context help, and when does it become noise?
- How small should a task be to remain verifiable without losing the bigger picture?
- When does a rule genuinely reduce errors, and when does it only slow the work down?
- What happens when there is no longer one agent, but many?
Did this experiment help you understand how it works?
Do you have a different experience to share, a mistake, an objection, or an idea to add?
Send a contribution →