← Home Coding basics

Le basi che evitano disastri con gli agenti AI

Concetti pratici per programmatori e vibe coder: naming, segreti, env, gitignore, commit e dipendenze spiegati con prompt di controllo.

best practice 01

Naming convention

Rischio: Nomi vaghi come data, stuff, thing o final2 rendono il progetto difficile da leggere e da far modificare a un agente.

Regola: Usa nomi che dicano cosa rappresenta una cosa e perché esiste: userProfileForm, submitPayment, buildSearchQuery.

prompt check
Review naming in this code.

Look for:
- vague names
- misleading names
- inconsistent component/file names
- names that hide side effects

Do not rename yet. First propose a small rename plan with risks.
best practice 02

API key mai nel frontend

Rischio: Il frontend viene scaricato dal browser. Se metti una chiave lì dentro, chiunque può leggerla e usarla.

Regola: Le chiavi stanno nel backend o nelle variabili ambiente del servizio che esegue il backend. Il browser chiama solo il tuo endpoint.

prompt check
Check whether this project exposes secrets.

Look for:
- API keys
- tokens
- connection strings
- private endpoints
- credentials in frontend code
- credentials in logs or config files

Do not modify code yet. Report where each risk is and how to move it safely.
best practice 03

.env e local settings fuori da git

Rischio: File locali come .env, local.settings.json o config private possono contenere segreti, URL interni e credenziali.

Regola: Versiona solo esempi senza segreti, tipo .env.example. I valori reali restano locali o nel provider cloud.

prompt check
Inspect git-tracked config files.

Find files that should probably stay local:
- .env
- local.settings.json
- secrets files
- service account files
- private certificates

Suggest a safe .gitignore update and an example file without secrets.
best practice 04

Perché .gitignore conta

Rischio: Senza .gitignore rischi di committare node_modules, build, cache, file temporanei, database locali e segreti.

Regola: Un buon .gitignore tiene il repo pulito e riduce incidenti. Va controllato quando aggiungi framework o tool nuovi.

prompt check
Review the .gitignore for this project.

Check whether it excludes:
- dependencies
- build output
- local env files
- cache folders
- local databases
- OS/editor files

Propose only entries relevant to this repo.
best practice 05

Commit piccoli

Rischio: Un commit enorme rende difficile capire cosa ha rotto cosa, soprattutto quando lavora un agente.

Regola: Ogni commit dovrebbe raccontare una modifica coerente: una feature, un fix, una pulizia limitata.

prompt check
Review local changes and suggest a commit split.

Group changes by purpose:
- feature
- bugfix
- styling
- docs/content
- cleanup

Do not stage or commit. Only propose groups and commit messages.
best practice 06

Dipendenze con criterio

Rischio: Installare pacchetti per ogni problema aumenta bundle, manutenzione e superficie di rischio.

Regola: Prima cerca se il progetto o il framework risolvono già il problema. Aggiungi librerie solo quando il valore è chiaro.

prompt check
Before adding a dependency, evaluate whether it is necessary.

Compare:
- existing project utilities
- framework built-ins
- small local implementation
- new dependency

Return the tradeoff and recommend the simplest maintainable option.