A way of working with AI, still evolving

When a prompt is no longer enough

For a small, isolated task, a good request may be enough. Then the work stretches over time: more files, more decisions, more attempts, perhaps more agents. At that point, getting a useful answer is no longer the main problem.

The problem is remembering why I made a decision, understanding what is about to change, checking that the result matches what I actually wanted, and preventing speed from taking me off course without noticing.

The sequence I am using

In the LAB, the work currently tends to follow this sequence:

Above all, one principle: Human in Command. This is the sequence that currently helps me see where something begins to diverge. Tomorrow it may be different.

It does not mean doing everything by hand

When I started using AI for development, I was mainly worried about wrong code. Over time I realised that the more interesting problem was something else.

AI does many things well, and that is exactly why it becomes easy to let it make decisions I never consciously chose to delegate. It can propose a solution, identify files to change, write code, prepare tests, fix an error and document what it did. All of that can be extremely useful.

But there is a difference between executing a decision and deciding that it is the right decision.

For me, Human in Command means this. The human still decides where the work is heading, which parts of the project may be touched, which trade-offs are acceptable and when a result is genuinely valid.

It does not mean checking every line produced by AI: if that were always necessary, much of the advantage would disappear. It means having enough visibility to intervene at the points that matter.

An example. Un coding agent scopre che, per chiudere un task, deve modificare due file che avevo lasciato fuori dal perimetro. Può essere giusto farlo. Ma voglio essere io a decidere che quella modifica è autorizzata. Lo stesso vale se introduce una nuova dipendenza o propone di cambiare una scelta architetturale: quella decisione deve tornare visibile prima di diventare semplicemente parte del codice.

Understand first, then change

One of the habits that changed my work with coding agents the most is simple: before making a change, ask the agent what it thinks it has understood.

• What did you understand from the request?
• Which files do you think are involved?
• What do you expect to change?
• Do you see dependencies, risks or side effects?

They may sound almost trivial. They help expose a divergence while correcting it is still cheap.

If the agent misunderstood the scope, I want to know before it has changed ten files.

It is not always necessary. But as the project grows, it becomes increasingly useful to have a moment when the agent’s interpretation becomes visible before execution.

Smaller, more visible, easier to verify

The speed of coding agents makes it easy to ask for very large changes. That is why I started doing the opposite.

Smaller tasks. More explicit scope. Changes that are easier to observe.

I do not want to artificially reduce what AI can do. I want to understand better what it has done.

Defining a scope means deciding which parts of the project may be touched and which stay out for that activity. It matters even more when several activities are moving forward in parallel.

Dependency and interference are not the same thing

My rule today: never have two agents writing to the same part of the project at the same time. If it stops being useful one day, I will change it.

Finished does not mean accepted

An agent can declare that it has completed an activity. That does not mean the work is finished.

Verification is the moment when I compare what was done with what I actually asked for. I check:

• the diff, the line-by-line comparison between before and after;
• tests;
• out-of-scope changes;
• new dependencies;
• technical warnings;
• acceptance criteria;
• possible side effects.

What I want to avoid is circular verification: “are you done?” — “yes”.

Verification has to produce something observable. It does not have to be complex, but it must be enough to distinguish a plausible result from a verified one.

Remember less, but better

Working with AI produces an enormous amount of memory: chats, prompts, code, assessments, decisions, documents and failed attempts.

Saving everything does not mean remembering better. Often the opposite happens.

With VIBE APP I am exploring a question: what is actually worth keeping? For now, four elements seem most useful:

The goal is the minimum useful context needed to resume the work without rebuilding everything from scratch every time.

Not just AI errors

It is easy to blame AI. But many of the most useful mistakes I have encountered were not model errors. They came from a request that was too broad, an implicit scope, insufficient context, a task that was too large, a rule that made sense a month ago but no longer does, or a decision that remained only in my head.

That is why I treat error as material for the experiment: something to fix, but also something that should leave a trace in the next attempt.

A rule has value as long as it solves a real problem. When it stops doing so, it must be allowed to change.

The same problem, observed from different angles

Some tools born in the LAB are starting to connect. They are not a suite yet: they are experiments looking at the same problem from different angles.

Local AI

Un modello Local AI è un’idea affascinante: lo installo sul mio computer e gli affido alcune attività, invece di interrogare sempre un servizio cloud. Ma conoscere il linguaggio non vuol dire conoscere il mio progetto. Il modello non sa com’è fatta l’architettura, quali decisioni abbiamo già preso, quali regole sono nate dopo un errore, quali parti considero stabili.

So the question is not whether it can run on my PC, but how much work is needed to make it useful inside that project. Sometimes giving it the right context each time may be enough. In other cases it may need deeper specialisation, up to fine-tuning, which is not free: it requires data, preparation and a concrete reason to do it.

Per questo, nel mockup di VIBE APP, l’Local AI è una domanda aperta e non una funzione pronta.

For now, I do not have an answer. It is exactly the kind of question the LAB exists for.

The method è ancora una domanda

The most interesting part of this page is not what it tries to fix in place, but what it continues to question.

This page will change if the experiments show that some of the ideas collected here do not work. That is exactly what I expect from a method that is still alive.