Ciao! Sono

Federico Calò

Sviluppatore Software | Divulgatore Tecnico

Creo applicazioni web moderne e strumenti digitali personalizzati per aiutare le attività a crescere attraverso l'innovazione tecnologica. La mia passione è unire informatica ed economia per generare valore reale.

Contattami

Chi Sono

La mia passione per l'informatica è nata tra i banchi dell'Istituto Tecnico Commerciale di Maglie, dove ho scoperto il potere della programmazione e il fascino di creare soluzioni digitali. Fin da subito, ho capito che l'informatica non era solo codice, ma uno strumento straordinario per trasformare idee in realtà.

Durante gli studi superiori in Sistemi Informativi Aziendali, ho iniziato a intrecciare informatica ed economia, comprendendo come la tecnologia possa essere il motore della crescita per qualsiasi attività. Questa visione mi ha accompagnato all'Università degli Studi di Bari, dove ho conseguito la Laurea in Informatica, approfondendo le mie competenze tecniche e la mia passione per lo sviluppo software.

Oggi metto questa esperienza al servizio di imprese, professionisti e startup, creando soluzioni digitali su misura che automatizzano processi, ottimizzano risorse e aprono nuove opportunità di business. Perché la vera innovazione inizia quando la tecnologia incontra le esigenze reali delle persone.

Le Mie Competenze

Analisi Dati & Modelli Previsionali

Trasformo i dati in insights strategici con analisi approfondite e modelli predittivi per decisioni informate

Automazione Processi

Creo strumenti personalizzati che automatizzano operazioni ripetitive e liberano tempo per attività a valore aggiunto

Sistemi Custom

Sviluppo sistemi software su misura, dalle integrazioni tra piattaforme alle dashboard personalizzate

const federico = {
  nome: "Federico Calò",
  ruolo: "Sviluppatore Software",
  città: "Bari, Italia",
  missione: "Aiutare attraverso l'informatica",
  passioni: [
    "Codice Pulito",
    "Innovazione",
    "Crescita Continua"
  ]
};

La Mia Missione

Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.

Democratizzare la Tecnologia

La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.

Unire Informatica ed Economia

Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.

Creare Soluzioni su Misura

Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.

Trasforma la Tua Attività con la Tecnologia

Che tu gestisca un negozio, uno studio professionale o un'azienda, posso aiutarti a sfruttare le potenzialità dell'informatica per lavorare meglio, più velocemente e in modo più intelligente.

Parliamone Insieme →

Unisciti alla Community

Entra nella community di sviluppatori dove discutiamo di software, AI, architettura e DevOps. Condividi idee, fai domande e cresci insieme a noi.

Canale

FC Dev Blog

Ricevi notifiche su nuovi articoli, serie complete, tips settimanali e tool in evidenza. Contenuti bilingui IT/EN direttamente nel tuo Telegram.

Nuovi articoli appena pubblicati
Tips e code snippets settimanali
Sondaggi sugli argomenti futuri

Iscriviti al Canale

Gruppo

FC Dev Community

Una community bilingue IT/EN per sviluppatori. Discussioni, Q&A, aiuto reciproco e networking con altri professionisti del settore.

Discussioni su articoli e tecnologie
Help coding e code review
Opportunità di lavoro e collaborazione

Unisciti al Gruppo

Topic di Discussione

Visualizza

Master SQL

RoadMap.sh

Novembre 2024

Visualizza

Oracle Certified Foundations Associate

Oracle

Ottobre 2024

Visualizza

People Leadership Credential

Connect

Settembre 2024

Linguaggi & Tecnologie

Java

Python

JavaScript

Angular

React

TypeScript

SQL

PHP

CSS/SCSS

Node.js

Docker

Git

💼

12/2024 - Presente

Custom Software Engineering Analyst

Accenture

Bari, Puglia, Italia · Ibrida Analisi e sviluppo di sistemi informatici attraverso l'utilizzo di Java e Quarkus in Health and Public Sector. Formazione continua su tecnologie moderne per la creazione di soluzioni software personalizzate ed efficienti e sugli agenti.

💼

06/2022 - 12/2024

Analista software e Back End Developer Associate Consultant

Links Management and Technology SpA

Esperienza nell'analisi di sistemi software as-is e flussi ETL utilizzando PowerCenter. Formazione completata su Spring Boot per lo sviluppo di applicazioni backend moderne e scalabili. Sviluppatore Backend specializzato in Spring Boot, con esperienza in progettazione di database, analisi, sviluppo e testing dei task assegnati.

💼

02/2021 - 10/2021

Programmatore software

Adesso.it (prima era WebScience srl)

Esperienza nell'analisi AS-IS e TO-BE, evoluzioni SEO ed evoluzioni website per migliorare le performance e l'engagement degli utenti.

🎓

2018 - 2025

Laurea in Informatica

Università degli Studi di Bari Aldo Moro

Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.

📚

2013 - 2018

Diploma - Sistemi Informativi Aziendali

Istituto Tecnico Commerciale di Maglie

Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.

Contattami

Hai un progetto in mente? Parliamone! Compila il form qui sotto e ti risponderò al più presto.

* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.

06 - Prompt Engineering per IDE AI: Scrivere Prompt Efficaci

C'e una differenza netta tra uno sviluppatore che usa un AI coding assistant e uno che sa comunicare con esso. Il primo ottiene risultati mediocri, richiede molte iterazioni e finisce per correggere manualmente il codice generato. Il secondo ottiene output precisi al primo o al secondo tentativo, accelera il proprio workflow e costruisce sistemi di istruzioni persistenti che migliorano nel tempo. La differenza sta tutta nel prompt engineering.

Nel contesto del vibe coding, il prompt non e solo un input: e la principale interfaccia di comunicazione tra sviluppatore e AI. La qualità di un prompt determina la qualità del codice generato, la pertinenza dei suggerimenti, la profondità dell'analisi di un bug e la solidita di un refactoring. Eppure, la maggior parte dei developer usa prompt improvvisati, vaghi e privi di struttura, poi si lamenta dei risultati.

Questo articolo esplora il prompt engineering come disciplina tecnica applicata allo sviluppo software: dalle basi anatomiche di un prompt efficace ai pattern avanzati come chain-of-thought e meta-prompting, dalla configurazione dei file di sistema (CLAUDE.md, .cursorrules, .github/copilot-instructions.md) al prompt chaining per task complessi. Con esempi concreti in TypeScript e Python per ogni scenario.

Cosa Imparerai

L'anatomia di un prompt efficace: Contesto, Vincoli, Output
I pattern fondamentali: zero-shot, few-shot, chain-of-thought, meta-prompting
Come configurare CLAUDE.md, .cursorrules e copilot-instructions.md
Prompt specifici per Claude Code, Cursor e GitHub Copilot a confronto
Prompt efficaci per refactoring, debugging e testing con esempi reali
Prompt chaining per decomporre task complessi in step gestibili
Gli anti-pattern più comuni e come evitarli
Metriche per misurare la qualità dei tuoi prompt

L'Anatomia di un Prompt Efficace

Un prompt efficace per un AI coding assistant non e una semplice frase in linguaggio naturale. E una struttura informativa che fornisce all'AI esattamente quello di cui ha bisogno per produrre output di qualità. Ogni prompt efficace contiene tre componenti fondamentali: contesto, vincoli e output atteso.

1. Contesto: Cosa Sa l'AI del Tuo Problema

Il contesto e la componente più critica e più spesso trascurata. L'AI non conosce il tuo progetto, la tua architettura, i tuoi standard di codice o i requisiti di business. Senza contesto, produce codice generico che potrebbe funzionare in astratto ma non nel tuo specifico caso. Il contesto efficace include:

Stack tecnologico: linguaggio, framework, versioni specifiche
Architettura corrente: pattern usati, struttura del progetto
Codice rilevante: funzioni, classi, interfacce collegate al problema
Obiettivo di business: perchè stai facendo questa modifica
Stato attuale: cosa funziona, cosa non funziona, qual è il problema esatto

2. Vincoli: I Limiti Entro Cui Operare

I vincoli definiscono i confini della soluzione accettabile. Senza vincoli, l'AI può proporre soluzioni tecnicamente corrette ma incompatibili con il tuo contesto: librerie diverse da quelle approvate, architetture che rompono la retrocompatibilita, pattern non allineati con gli standard del team. I vincoli tipici includono:

Librerie approvate o proibite
Compatibilità con versioni specifiche di Node, TypeScript, Python, ecc.
Limiti di performance (complessità algoritmica, dimensioni bundle)
Standard del team (naming conventions, test coverage minima)
Vincoli di sicurezza (no eval, no shell injection, validazione input)

3. Output Atteso: La Forma del Risultato

Specificare il formato dell'output e fondamentale. Un prompt che dice "migliorami questa funzione" può ottenere una risposta testuale, del codice inline, una lista di suggerimenti o un refactoring completo. Specificare cosa si vuole riduce l'ambiguità:

Formato: codice direttamente, spiegazione + codice, lista di modifiche
Scope: solo la funzione, l'intero modulo, con test inclusi
Livello di dettaglio: con commenti, con tipi TypeScript, con error handling
Azione successiva: applica la modifica, mostra un diff, spiega prima e poi implementa

Vediamo la differenza tra un prompt vago e uno ben strutturato per lo stesso task:

Confronto: prompt vago vs prompt strutturato

# PROMPT VAGO - Risultato imprevedibile
"Migliora questa funzione di autenticazione"

# PROMPT STRUTTURATO - Risultato prevedibile
"""
Contesto:
- Stack: TypeScript 5.4, Node.js 22, Express 5, JWT
- Funzione di autenticazione attuale (vedi sotto)
- Architettura: Repository Pattern, servizi separati da controller

Problema:
La funzione validateToken lancia eccezioni non tipizzate e non gestisce
il refresh token scaduto. In prod abbiamo avuto 3 crash nelle ultime 24h.

Vincoli:
- Non cambiare l'interfaccia pubblica (backward compatibility)
- Usare solo librerie già nel package.json (jsonwebtoken, zod)
- Mantenere compatibilità con Node.js 20+
- Test coverage minima 80%

Output atteso:
1. Funzione validateToken refactored con error handling tipizzato
2. Tipi personalizzati per gli errori (AuthError con codici specifici)
3. Unit test con Jest per i casi di errore principali

Codice attuale:
async function validateToken(token: string) {
  const decoded = jwt.verify(token, process.env.JWT_SECRET);
  return decoded;
}
"""

La Regola del Contesto Esplicito

Ricerche sul prompt engineering mostrano che fornire il contesto all'inizio e alla fine del prompt e significativamente più efficace che metterlo al centro. Il modello tende a dare più peso alle informazioni nelle posizioni di apertura e chiusura. Per prompt lunghi, ripeti il vincolo più critico alla fine con una formulazione come "Ricorda: non modificare l'interfaccia pubblica della funzione."

I Pattern Fondamentali del Prompt Engineering

I pattern di prompt engineering nascono dalla ricerca accademica sull'interazione con LLM, ma si applicano concretamente al lavoro quotidiano con AI coding assistant. Conoscerli permette di scegliere lo strumento giusto per ogni tipo di problema.

Zero-Shot Prompting

Il pattern più semplice: chiedi all'AI di eseguire un task senza fornire esempi. Funziona bene per task standard e ben definiti dove il modello ha abbondante training data. E il punto di partenza di qualsiasi interazione.

Zero-shot per generazione codice TypeScript

# Zero-shot efficace: task standard con contesto minimo
"""
Crea un custom hook React in TypeScript per gestire richieste HTTP con:
- Stato di loading, data, error tipizzato con generics
- Cancellazione automatica con AbortController al unmount
- Retry automatico con backoff esponenziale (max 3 tentativi)
- Cache in-memory per evitare richieste duplicate entro 30 secondi

Usa React 18+ e TypeScript strict mode.
"""

Few-Shot Prompting

Fornisci esempi del pattern che vuoi replicare. Particolarmente efficace per stabilire convenzioni di naming, strutture dati specifiche del progetto o stili di codice non standard. Il modello "impara" il pattern dagli esempi e lo applica al nuovo caso.

Few-shot per rispettare le convenzioni di naming del progetto

# Few-shot: stabilire il pattern di error handling del progetto
"""
Nel nostro progetto usiamo questo pattern per gli errori:

ESEMPIO 1 - Repository error:
class UserNotFoundError extends AppError {
  constructor(userId: string) {
    super(`User #123;userId} not found`, 'USER_NOT_FOUND', 404);
  }
}

ESEMPIO 2 - Validation error:
class InvalidEmailError extends AppError {
  constructor(email: string) {
    super(`Invalid email format: #123;email}`, 'INVALID_EMAIL', 422);
  }
}

ESEMPIO 3 - External service error:
class PaymentGatewayError extends AppError {
  constructor(provider: string, details: string) {
    super(`Payment failed via #123;provider}: #123;details}`, 'PAYMENT_FAILED', 502);
  }
}

Seguendo esattamente questo pattern, crea gli errori per il modulo
di autenticazione: TokenExpiredError, InvalidCredentialsError,
AccountLockedError e SessionLimitExceededError.
"""

Chain-of-Thought (CoT) Prompting

Chiedi all'AI di ragionare passo per passo prima di fornire il codice finale. Questo approccio e particolarmente efficace per problemi algoritmici complessi, ottimizzazioni di performance e debugging di bug difficili da individuare. La ricerca di Structured Chain-of-Thought (SCoT) mostra miglioramenti di accuratezza del 15.27% per task di code generation rispetto ai prompt standard.

Chain-of-thought per algoritmo di ottimizzazione

# Chain-of-thought: debugging di un problema di performance
"""
Ho una funzione Python che processa 50.000 record in ~40 secondi.
Devo portarla sotto i 2 secondi. Prima di scrivere codice, ragiona
passo per passo:

1. Analizza i colli di bottiglia nel codice attuale
2. Identifica le strutture dati subottimali
3. Valuta quali ottimizzazioni hanno il maggiore impatto
4. Solo dopo proponi l'implementazione ottimizzata

Codice attuale:
def find_duplicate_transactions(transactions: list[dict]) -> list[dict]:
    duplicates = []
    for i, t1 in enumerate(transactions):
        for j, t2 in enumerate(transactions):
            if i != j:
                if (t1['amount'] == t2['amount'] and
                    t1['merchant'] == t2['merchant'] and
                    t1['date'] == t2['date']):
                    if t1 not in duplicates:
                        duplicates.append(t1)
    return duplicates

Vincoli: Python 3.11+, nessuna libreria esterna oltre a quelle stdlib
"""

Meta-Prompting

Il meta-prompting usa l'AI per generare o migliorare i prompt stessi. E una tecnica avanzata particolarmente utile quando non sai esattamente come formulare un problema complesso, o quando vuoi ottimizzare un prompt esistente. L'AI diventa un collaboratore nella creazione del prompt.

Meta-prompting: chiedere all'AI di migliorare il tuo prompt

# Meta-prompt: ottimizzare un prompt per generare API REST
"""
Questo e il prompt che ho scritto per generare un'API REST:
"Crea un'API per gestire ordini e-commerce in Node.js con TypeScript"

Analizza questo prompt e:
1. Identifica le informazioni mancanti che renderebbero il risultato più preciso
2. Suggerisci una versione migliorata del prompt con le informazioni necessarie
3. Spiega perchè ogni aggiunta migliora il risultato finale

Non generare ancora l'API: prima ottimizziamo il prompt insieme.
"""

# L'AI risponde con un prompt migliorato come:
"""
[Suggerimento AI]: Il prompt migliorato dovrebbe includere:
- Framework specifico (Express vs Fastify vs NestJS)
- Pattern architetturale (MVC, Clean Architecture, DDD)
- Database (PostgreSQL, MongoDB) e ORM (Prisma, TypeORM)
- Autenticazione (JWT, OAuth2, API Key)
- Endpoint specifici del dominio ordini
- Requisiti di validazione e error handling
- Standard API (REST, JSON:API, HAL)
...
"""

Quale Pattern Scegliere?

Zero-shot: Task standard, ben definiti, con vocabolario tecnico chiaro
Few-shot: Convenzioni di progetto, pattern non standard, stili specifici
Chain-of-thought: Bug complessi, ottimizzazioni, decisioni architetturali
Meta-prompting: Quando il problema e mal definito, quando vuoi migliorare i tuoi prompt

System Prompts e File di Configurazione Persistenti

Uno degli errori più comuni nell'uso degli AI coding assistant e dover ripetere il contesto del progetto in ogni conversazione. I tool moderni permettono di definire istruzioni persistenti che vengono automaticamente incluse in ogni sessione. Questo e il livello dove si ottengono i maggiori guadagni di produttività a lungo termine.

CLAUDE.md: Il Sistema Operativo di Claude Code

CLAUDE.md e il file di configurazione letto da Claude Code all'inizio di ogni sessione. Secondo un'analisi di 328 file CLAUDE.md pubblici, le categorie più comuni sono: Architettura (72.6%), Linee guida di sviluppo (44.8%), Overview del progetto (39.0%), Testing (35.4%) e Comandi (33.2%). Un buon CLAUDE.md trasforma Claude da assistente generico a esperto del tuo specifico progetto.

CLAUDE.md - Struttura efficace per un progetto Angular/Node.js

# CLAUDE.md - Portfolio Angular + API Node.js

## Panoramica Progetto
Portfolio professionale con blog, developer tools e API.
Frontend: Angular 21 + SSR. Backend: Node.js 22 + Express 5.
Deploy: Firebase Hosting (frontend) + Cloud Run (API).

## Stack Tecnologico
- **Frontend**: Angular 21 standalone components, TypeScript 5.4, Signals
- **Backend**: Node.js 22, Express 5, TypeScript, Prisma ORM
- **Database**: PostgreSQL 16 (prod), SQLite (dev)
- **Testing**: Jest (unit), Cypress (e2e)
- **Linting**: ESLint 9 + Prettier

## Architettura Frontend
- Standalone components (no NgModules)
- Signals per stato reattivo (no RxJS dove possibile)
- OnPush change detection su tutti i componenti
- Lazy loading per tutte le route
- CSS scoped ai componenti (no global styles tranne design system)

## Architettura Backend
- Clean Architecture: routes -> controllers -> services -> repositories
- Repository Pattern per l'accesso ai dati
- Error handling centralizzato con AppError e globalErrorHandler
- Validazione input con Zod su tutti gli endpoint
- JWT + refresh token per autenticazione

## Comandi Essenziali
```bash
# Frontend
npm start          # dev server
npm run build      # production build con SSR
npm test           # unit tests

# Backend
npm run dev        # dev con hot reload
npm run migrate    # Prisma migrations
npm run seed       # seed database
```

## Standard di Codice
- TypeScript strict mode: sempre
- No `any`: usare tipi espliciti o generics
- Funzioni: max 30 righe. File: max 400 righe.
- Nomi: kebab-case per file, PascalCase per classi, camelCase per variabili
- Import: absolute paths con @ alias, non path relativi oltre 2 livelli

## Regole di Sicurezza CRITICHE
- MAI hardcodare secrets o chiavi API
- Validare SEMPRE l'input con Zod prima di processarlo
- Usare SEMPRE query parametrizzate (Prisma gestisce questo)
- Rate limiting su tutti gli endpoint pubblici
- CORS configurato con allowlist esplicita

## Testing
- Coverage minima: 80% per servizi e repository
- Test: should + comportamento (es: "should return 404 when user not found")
- Mock: solo dipendenze esterne (DB, API), non logica interna
- E2E: critical user flows (auth, checkout, API key creation)

## Pitfalls Noti
- SSR: usare isPlatformBrowser() per API browser-only (localStorage, window)
- Angular templates: escapare { con {{ }} Angolare in ngNonBindable
- Prisma: usare transazioni per operazioni multi-step
- JWT: refresh token deve essere httpOnly cookie, non localStorage

## Cross-References
Vedi @docs/architecture.md per diagrammi
Vedi @docs/api-patterns.md per convenzioni REST
Vedi @.env.example per variabili d'ambiente richieste

.cursorrules: La Configurazione di Cursor

Cursor usa un file .cursorrules nella root del progetto (o nella cartella .cursor/rules/ per regole più granulari) per personalizzare il comportamento dell'AI. Cursor supporta tre tipi di regole: Always (applicate a tutti i file), Auto-Apply (applicate ai file che matchano un glob pattern) e Agent Select (applicate occasionalmente su richiesta).

.cursorrules - Configurazione per progetto TypeScript/Angular

# .cursorrules - TypeScript Angular Project

## Ruolo
Sei un senior Angular developer. Conosci questo progetto e segui
le sue convenzioni senza eccezioni. Quando generi codice, rispetta
sempre questi standard.

## TypeScript
- strict mode abilitato: no implicit any, no unused variables
- Preferisci `interface` a `type` per oggetti
- Usa generics invece di `any` per funzioni riutilizzabili
- Destructuring dove possibile
- Async/await invece di Promise chains

## Angular Specifico
- SOLO standalone components, mai NgModules
- Signals per stato locale e computed values
- `inject()` invece di constructor injection
- OnPush change detection obbligatoria
- `ngOptimizedImage` per tutte le immagini statiche
- Lazy loading su tutte le feature routes

## Stile CSS
- CSS custom properties (variabili del design system in styles.css)
- BEM naming per classi custom
- No stili inline negli HTML template
- Mobile-first con breakpoints: 768px (tablet), 1024px (desktop)

## Codice da NON Generare
- NgModules o forRoot/forChild patterns
- Class-based guards o resolvers (usa functional guards)
- RxJS per stato semplice (usa signals)
- setTimeout o setInterval (usa RxJS timer se necessario)
- document.querySelector (usa ViewChild o renderer)

## Formato Output
Quando generi un componente, includi sempre:
1. Il file .ts con il componente
2. Il file .html con il template
3. Il file .css se ci sono stili specifici
4. Un file .spec.ts con test minimi

.github/copilot-instructions.md: Custom Instructions per Copilot

GitHub Copilot usa il file .github/copilot-instructions.md per le istruzioni persistenti a livello di repository. Secondo GitHub, questo file e progettato per "onboardare" il repository all'agente Copilot, fornendo le informazioni necessarie per lavorare efficientemente dalla prima interazione. A agosto 2025, Copilot ha introdotto la generazione automatica di custom instructions analizzando la struttura del repository.

.github/copilot-instructions.md - Esempio per team Node.js

# Copilot Custom Instructions

This is a TypeScript Node.js microservices project following Clean Architecture.

## Project Structure
- `src/domain/` - Business entities and domain logic (no framework dependencies)
- `src/application/` - Use cases and application services
- `src/infrastructure/` - Database, external APIs, repositories
- `src/presentation/` - HTTP controllers and routes

## Coding Standards
Always use TypeScript. Prefer `interface` over `type` for object shapes.
Use `Result<T, E>` pattern for error handling, never throw from business logic.
All public functions must have JSDoc with @param and @returns.

## Testing Requirements
Write Jest unit tests for all domain and application layer code.
Mock infrastructure dependencies. Target 85% coverage.
Test file naming: `*.spec.ts` co-located with source files.

## API Conventions
REST endpoints follow kebab-case: `/api/user-profiles` not `/api/userProfiles`.
All responses use the envelope: `{ data, error, meta }`.
HTTP status codes: 200 (success), 201 (created), 400 (validation),
401 (auth), 403 (authz), 404 (not found), 500 (server error).

## Security
Validate all input with Zod schemas at the presentation layer.
Never log sensitive data (passwords, tokens, PII).
Use parameterized queries via Prisma - never string concatenation.

## Dependencies
Approved: express, zod, prisma, jsonwebtoken, winston, jest
Restricted: lodash (use native JS), moment (use date-fns), axios (use fetch)
Forbidden: eval, vm, child_process (unless in dedicated worker)

      Dove Mettere le Istruzioni Persistenti
      
            Tool
            File
            Scope
          
            Claude Code
            CLAUDE.md (root) o ~/.claude/CLAUDE.md
            Progetto o globale
          
            Cursor
            .cursorrules o .cursor/rules/*.mdc
            Progetto o per-file-type
          
            GitHub Copilot
            .github/copilot-instructions.md
            Repository
          
            Windsurf
            .windsurfrules
            Progetto
          
            Tutti (standard)
            .ai-instructions.md + import
            Cross-tool (con tool specifici che lo importano)

Prompt per Task Specifici: Refactoring, Debugging, Testing

Ogni tipo di task di sviluppo ha caratteristiche diverse e richiede prompt strutturati in modo diverso. Vediamo le strutture ottimali per i tre task più comuni: refactoring, debugging e generazione di test.

Prompt per Refactoring

Un buon prompt di refactoring deve specificare la direzione del cambiamento (verso quale pattern o principio si sta migrando), i vincoli di compatibilità (cosa non deve cambiare) e il criterio di successo (come sapere che il refactoring e riuscito).

Template prompt per refactoring TypeScript verso Clean Architecture

# Template: Prompt per Refactoring
"""
Task: Refactoring verso [PATTERN TARGET]

Codice attuale:
[INCOLLA IL CODICE DA REFACTORARE]

Motivazione:
[Spiega perchè stai facendo questo refactoring]
Es: "Questo servizio fa troppe cose. Violare SRP rende difficile il testing."

Direzione del refactoring:
[Descrivi il pattern o principio verso cui vuoi migrare]
Es: "Separare la logica di business dalla persistenza con Repository Pattern"

Vincoli CRITICI (non modificare):
- L'interfaccia pubblica del servizio UserService deve rimanere invariata
- I test esistenti devono continuare a passare
- Nessuna dipendenza nuova oltre a quelle nel package.json

Criteri di successo:
- UserService non importa più Prisma direttamente
- IUserRepository e un'interfaccia iniettabile
- UserRepository può essere mockato nei test senza Prisma

Output atteso:
1. UserRepository interfaccia (src/domain/repositories/IUserRepository.ts)
2. PrismaUserRepository implementazione (src/infrastructure/repositories/)
3. UserService aggiornato che usa l'interfaccia
4. Test aggiornati con mock del repository
"""

Prompt per Debugging

Il debugging e il task dove il contesto e più critico. L'AI non ha visto il crash: deve ricostruire la situazione dai frammenti che le fornisci. Un prompt di debugging efficace fornisce il messaggio di errore completo, lo stack trace, il codice rilevante e il contesto ambientale.

Template prompt per debugging con stack trace

# Template: Prompt per Debugging
"""
Ambiente:
- Node.js 22.3.0, TypeScript 5.4, Express 5.0.1
- Database: PostgreSQL 16 via Prisma 5.14
- OS: Ubuntu 22.04 (prod), macOS 14 (dev) - bug in ENTRAMBI

Errore (messaggio completo):
TypeError: Cannot read properties of undefined (reading 'email')
    at UserController.createUser (src/controllers/user.controller.ts:47:28)
    at Layer.handle [as handle_request] (express/lib/router/layer.js:95:5)
    at next (express/lib/router/route.js:149:13)
    ...

Codice dove avviene l'errore (user.controller.ts, righe 40-55):
[INCOLLA LE RIGHE RILEVANTI]

Dati in input (dal log di debug):
Request body: { "name": "Mario", "role": "admin" }
Request headers: { "content-type": "application/json", "x-api-key": "..." }

Cosa ho già provato:
1. Aggiunto console.log a riga 46: body.email e undefined
2. Controllato il middleware: body-parser e configurato correttamente
3. Testato con Postman con email presente: funziona

Ipotesi:
Il validatore Zod potrebbe non trasformare correttamente i valori opzionali?
Lo schema accetta email come optional ma il controller assume che ci sia sempre.

Chiedo:
1. Identifica la causa root del problema
2. Spiega perchè si manifesta solo quando email manca
3. Proponi la correzione
4. Suggerisci come prevenire errori simili in futuro
"""

Prompt per Generazione di Test

I test generati dall'AI sono spesso troppo superficiali se non guidati correttamente. Un buon prompt per testing deve specificare il framework, il tipo di test (unitario, integrazione, e2e), i casi limite da coprire e il livello di coverage atteso.

Template prompt per generazione test unitari con Jest/TypeScript

# Template: Prompt per Test Generation
"""
Framework: Jest 29 + TypeScript. Testing library: @testing-library/react (se UI).
Tipo di test: Unit tests per la funzione seguente.

Funzione da testare:
export function calculateShippingCost(
  orderValue: number,
  destination: 'IT' | 'EU' | 'WORLD',
  weight: number,
  options: { express?: boolean; insurance?: boolean } = {}
): ShippingCost {
  // implementazione...
}

Business rules (da testare obbligatoriamente):
- Spedizione gratuita per ordini > 50€ in IT, > 100€ in EU
- Express: +50% sul costo base
- Insurance: 2% del valore ordine, min 2€
- Peso massimo: 30kg, oltre lancia WeightLimitExceededError
- Destinazione WORLD: sempre a pagamento, no free shipping

Casi da coprire OBBLIGATORIAMENTE:
1. Happy path: tutti i tipi di destinazione
2. Spedizione gratuita: threshold esatti (49.99€ vs 50.00€ vs 50.01€)
3. Opzioni combinate: express + insurance insieme
4. Casi limite: peso 0, peso 30, peso 30.01 (errore atteso)
5. Valori negativi: orderValue negativo (validazione attesa)
6. Arrotondamento: verificare che i prezzi abbiano max 2 decimali

Formato test:
describe('calculateShippingCost', () => {
  describe('[categoria]', () => {
    it('should [comportamento] when [condizione]', () => {
      // arrange - act - assert
    });
  });
});

Coverage attesa: 100% branch coverage sulla funzione.
"""

Prompt Chaining per Task Complessi

Il prompt chaining e la tecnica di suddividere un task complesso in una sequenza di sotto-task connessi, dove l'output di ogni step diventa l'input del successivo. E particolarmente efficace quando un singolo prompt lungo produce risultati inconsistenti o incompleti. La chiave e la decomposizione: identificare i punti di separazione naturali nel problema.

Esempio: Feature Completa con Prompt Chaining

Immagina di dover implementare un sistema di notifiche email con rate limiting, queue e retry. Un singolo prompt per l'intera feature produce spesso codice incompleto. Con il chaining:

Prompt chaining: sistema notifiche email (5 step)

# STEP 1: Design dell'architettura (nessun codice)
"""
Prima di scrivere codice, progetta l'architettura per un sistema
di notifiche email con queste caratteristiche:
- Rate limiting: max 100 email/ora per utente
- Queue persistente con Redis (Bullmq)
- Retry automatico con backoff esponenziale (max 3 volte)
- Template email con variabili
- Tracking: sent, failed, bounced, opened

Output atteso:
1. Diagramma testuale dei componenti e relazioni
2. Lista delle interfacce TypeScript (senza implementazione)
3. Schema del database per il tracking
4. Potenziali problemi e come li risolviamo

Non scrivere ancora codice: voglio validare l'architettura prima.
"""

# STEP 2: Interfacce e tipi (basato sull'output dello step 1)
"""
L'architettura approvata e quella che hai proposto nello step precedente.
Ora implementa SOLO le interfacce TypeScript:
- IEmailService con tutti i metodi
- IEmailTemplate con le variabili tipizzate
- INotificationJob per la queue
- IEmailTrackingEvent per gli eventi di tracking
- Tipi di errore specifici del dominio

Nessuna implementazione: solo interfacce e tipi.
File: src/domain/interfaces/email.interfaces.ts
"""

# STEP 3: Implementazione del core service
"""
Le interfacce sono definite. Implementa EmailService che implementa
IEmailService usando:
- nodemailer per l'invio
- Zod per validazione input
- Winston per logging

Assumi che IEmailTemplateRenderer e IEmailQueue esistano gia
come dipendenze iniettate. Usa i tipi definiti nello step 2.

Test: includi test unitari per i metodi send() e sendBulk()
mockando le dipendenze esterne.
"""

# STEP 4: Queue e rate limiting
"""
Implementa EmailQueue usando Bullmq che:
- Rispetti il rate limit di 100 email/ora per utente
- Implementi il retry con backoff: 1min, 5min, 15min
- Persista i job in Redis
- Emetta eventi per il tracking

Usa l'interfaccia IEmailQueue definita nello step 2.
Non reimplementare EmailService: usala come dipendenza.
"""

# STEP 5: Integrazione e test end-to-end
"""
Tutti i componenti sono implementati. Ora:
1. Crea il container DI che wires tutto insieme
2. Scrivi un test di integrazione che simula:
   - 150 email in 1 ora (deve rispettare il rate limit)
   - Un invio che fallisce 2 volte e riesce al 3° tentativo
   - Un invio che esaurisce i retry e va in dead letter queue
3. Crea un README.md per il modulo con setup e usage examples
"""

      Vantaggi del Prompt Chaining
      Controllo granulare: validi ogni step prima di procedere
Correzioni localizzate: se uno step e sbagliato, correggi solo quello
Contesto pulito: ogni step ha un contesto preciso e focalizzato
Output più affidabile: il modello si concentra su un problema alla volta
Tracciabilita: puoi ripartire da qualsiasi step della chain

    

Prompt Chaining Condizionale

Il chaining condizionale introduce decisioni basate sull'output degli step precedenti. E utile quando la strada da percorrere dipende dall'analisi iniziale dell'AI.

Prompt chaining condizionale: code review con branching

# STEP 1: Analisi preliminare
"""
Analizza questa funzione Python e classifica i problemi trovati
in tre categorie:
- CRITICO: bug o vulnerabilità che devono essere corretti immediatamente
- IMPORTANTE: design issues o violazioni di principi SOLID
- SUGGERIMENTO: ottimizzazioni o miglioramenti opzionali

def process_user_data(user_id, data):
    conn = sqlite3.connect('users.db')
    query = f"UPDATE users SET data = '{data}' WHERE id = {user_id}"
    conn.execute(query)
    conn.commit()
    conn.close()
    return True

Rispondi SOLO con la classificazione. Non proporre soluzioni ancora.
"""

# STEP 2a (se ci sono CRITICI): Fix immediati
"""
Hai trovato [N] problemi CRITICI. Inizia da quelli.
Per ogni problema critico:
1. Spiega la vulnerabilità specifica (es: SQL injection via f-string)
2. Mostra il codice vulnerabile evidenziato
3. Proponi il fix con spiegazione
4. Indica il CVE o OWASP category di riferimento

Dopo i critici, mostreremo gli altri in sessioni separate.
"""

# STEP 2b (se nessun CRITICO): Refactoring generale
"""
Non ci sono problemi critici. Procedi con il refactoring completo
indirizzando i problemi IMPORTANTI. Mantieni la stessa firma della funzione
per compatibilità con il codice chiamante.
"""

Claude Code vs Cursor vs Copilot: Prompt a Confronto

Ogni tool ha caratteristiche diverse che influenzano come strutturare i prompt. Conoscere queste differenze permette di adattare la comunicazione per massimizzare la qualità dell'output.

Claude Code: Prompt per Operazioni End-to-End

Claude Code opera nel terminale con accesso al filesystem, ai comandi bash e all'intero codebase. E ottimale per task autonomi end-to-end dove si vuole delegare completamente un sotto-task. I prompt per Claude Code tendono ad essere più dichiarativi e orientati agli obiettivi.

Claude Code: prompt per task end-to-end

# Claude Code: prompt efficace per task autonomo
"""
Implementa il modulo di autenticazione per questa API.

Requisiti funzionali:
- Registrazione con email/password (hash bcrypt, salt 12)
- Login con JWT access token (15min) + refresh token (7 giorni httpOnly cookie)
- Logout che invalida il refresh token
- Refresh token endpoint
- Password reset via email (token con scadenza 1h)

Stack: Node.js 22, Express 5, Prisma con PostgreSQL, Zod

Struttura attesa:
- src/modules/auth/ con controller, service, repository
- src/domain/interfaces/IAuthService.ts
- Migrations Prisma per la tabella refresh_tokens
- Test Jest per AuthService (unit) e auth routes (integration)
- Aggiornamento del README con i nuovi endpoint

Procedi autonomamente. Alla fine, mostrami un summary delle
modifiche apportate e come testare il risultato.
"""

Cursor: Prompt per Multi-File Editing

Cursor eccelle nelle modifiche coordinate su più file con il Composer. I prompt per Cursor sono efficaci quando specificano esplicitamente i file da modificare e le relazioni tra le modifiche.

Cursor: prompt per refactoring multi-file coordinato

# Cursor Composer: prompt per refactoring coordinato
"""
Refactoring: migra da class-based services a functional services con
dependency injection tramite closures.

File da modificare (in questo ordine):
1. src/services/userService.ts (classe attuale)
2. src/controllers/userController.ts (usa il servizio)
3. src/app.ts (DI container)
4. src/services/__tests__/userService.test.ts (aggiorna i mock)

Pattern target:
// PRIMA (class-based)
class UserService {
  constructor(private repo: UserRepository) {}
  async findById(id: string) {...}
}

// DOPO (functional)
const createUserService = (repo: IUserRepository) => ({
  findById: async (id: string) => {...},
});
type UserService = ReturnType<typeof createUserService>;

Mantieni la stessa interfaccia pubblica dei metodi.
I test esistenti devono continuare a passare senza modifiche
alla logica di test, solo ai mock/setup.
"""

GitHub Copilot: Prompt via Commenti e Chat

GitHub Copilot risponde ai commenti inline nel codice e alla chat integrata nell'IDE. I prompt più efficaci per Copilot sono quelli contestuali: il cursore posizionato nel punto giusto e un commento descrittivo sono spesso più efficaci di lunghe spiegazioni nella chat.

Copilot: prompt via commenti inline e chat contestuale

// TECNICA 1: Commenti come prompt (file: src/utils/validation.ts)
// Validate email with RFC 5322 standard, return detailed error object
// with field name, message, and IETF error code. No external deps.
export function validateEmail(email: string): ValidationResult {
  // Copilot suggerisce l'implementazione qui
}

// TECNICA 2: JSDoc come specifica (più contesto = più accurato)
/**
 * Calcola il prezzo finale con sconti a cascata applicati nell'ordine:
 * 1. Sconto per quantità (sopra 10: -5%, sopra 50: -10%, sopra 100: -20%)
 * 2. Sconto utente (0-30%, applicato al prezzo dopo sconto quantità)
 * 3. Codice promozionale (importo fisso, applicato per ultimo)
 *
 * @throws {InvalidDiscountError} se userDiscount > 30 o promoAmount < 0
 * @returns prezzo arrotondato a 2 decimali
 */
function calculateFinalPrice(
  basePrice: number,
  quantity: number,
  userDiscount: number,
  promoAmount: number
): number {
  // Copilot implementa seguendo la specifica JSDoc
}

// TECNICA 3: Chat Copilot con selezione codice
// [Seleziona il codice] poi in chat:
// "@workspace Refactoring questo metodo verso il pattern Result<T,E>
// che abbiamo nelle altre parti del progetto (vedi src/shared/Result.ts)"

Tool	Forza	Prompt Ottimale	Context Window
Claude Code	Task end-to-end, ragionamento profondo	Obiettivi dichiarativi, autonomia ampia	200K token
Cursor	Multi-file editing, codebase awareness	File specifici, pattern coordinati	128K token (Composer)
Copilot	Autocompletamento, inline suggestions	Commenti inline, JSDoc precisi	Contestuale al file
Windsurf	Contesto proattivo, esplorazione	Obiettivi ad alto livello, esplora autonomamente	128K token

Anti-Pattern: I Prompt che Non Funzionano

Conoscere gli anti-pattern e importante quanto conoscere i pattern. Questi sono i prompt che producono sistematicamente output di bassa qualità o risultati fuori contesto.

Anti-Pattern 1: Il Prompt Vago

Il prompt vago e il più comune. Chiede cambiamenti senza specificare la direzione, il vincolo o il criterio di successo. L'AI produce qualcosa di plausibile ma spesso non allineato con le reali esigenze.

Anti-pattern vs pattern corretto: prompt vaghi

# ANTI-PATTERN: vago e senza contesto
"Migliora questa funzione"
"Ottimizza le performance"
"Rendi il codice più pulito"
"Aggiungi error handling"
"Refactora questo"

# PATTERN CORRETTO: specifico e contestualizzato
"Ottimizza questa funzione Python che attualmente ha complessità O(n^2)
portandola a O(n log n) usando un heap. Mantieni lo stesso output ma
usa solo librerie stdlib. Includi benchmark prima/dopo con timeit."

"Aggiungi error handling a questo endpoint Express che al momento
lancia eccezioni non gestite. Usa il pattern AppError centralizzato
gia definito in src/errors/AppError.ts. Testa i casi 400, 401, 404, 500."

Anti-Pattern 2: Il Prompt Troppo Lungo

Paradossalmente, prompt eccessivamente lunghi (oltre 2.000 token) tendono a produrre risultati peggiori rispetto a prompt medi ben strutturati. Il modello può perdere il focus su dettagli critici sepolti nel mezzo del testo, o cercare di soddisfare troppi requisiti simultaneamente producendo codice mediocre su tutti i fronti.

Il Limite dei 2.000 Token per i Prompt

Ricerche empiriche suggeriscono che prompt superiori a 2.000 token per task singoli tendono a produrre risultati con qualità decrescente. Se il tuo prompt si avvicina a questa soglia, e un segnale che stai cercando di fare troppo in una volta sola. Suddividi il task con prompt chaining. L'eccezione e fornire codice sorgente come contesto: includere il file completo spesso migliora il risultato rispetto a estrarne solo una parte.

Anti-Pattern 3: Assumere il Contesto Implicito

L'AI non ricorda le conversazioni precedenti (tranne nel contesto della sessione corrente) e non conosce il tuo progetto specifico se non glielo hai descritto. Assumere che l'"ovvio" sia implicito e una fonte sistematica di prompt inefficaci.

Anti-pattern: contesto implicito vs esplicito

# ANTI-PATTERN: assume contesto implicito
"Aggiungi il campo 'status' al modello"
# L'AI non sa: quale modello? quale database? quale ORM?
# quale tipo per 'status'? quali valori ammessi? quale migration?

"Usa il nostro pattern standard per questo"
# L'AI non conosce il tuo "pattern standard"

"Come facciamo di solito con gli errori"
# L'AI non sa come gestite gli errori nel vostro progetto

# PATTERN CORRETTO: contesto sempre esplicito
"Aggiungi il campo 'status' al modello User in Prisma (prisma/schema.prisma).
Il tipo e un enum: ACTIVE, INACTIVE, SUSPENDED, DELETED.
Default: ACTIVE. Obbligatorio (non nullable).
Genera la migration Prisma. Aggiorna UserRepository.findByStatus(status).
Aggiorna i test esistenti."

Anti-Pattern 4: Il Mega-Prompt "Fai Tutto"

Chiedere all'AI di implementare un'intera feature in un unico prompt produce quasi sempre risultati incompleti o con lacune. Il modello e costretto a fare scelte su dettagli che tu non hai specificato, e le scelte non sempre corrispondono alle tue aspettative.

Anti-pattern: mega-prompt vs prompt chaining efficace

# ANTI-PATTERN: mega-prompt
"Implementa un sistema completo di gestione utenti con CRUD,
autenticazione JWT, ruoli e permessi, rate limiting, audit log,
password reset via email, 2FA con TOTP, OAuth2 con Google e GitHub,
sessioni multi-device, revoca token, GDPR export e deletion,
dashboard admin, test completi e documentazione API."

# Risultato: codice generico, incompleto, senza adattamento al tuo stack

# PATTERN CORRETTO: decomposizione e priorità
# Step 1: "Implementa CRUD base per User (POST/GET/PUT/DELETE) con Prisma"
# Step 2: "Aggiungi autenticazione JWT al modulo users esistente"
# Step 3: "Implementa il sistema di ruoli RBAC basato su questi requisiti..."
# Step 4: "Aggiungi rate limiting con Redis usando il pattern già in AuthController"
# Ogni step valida il precedente prima di procedere

Anti-Pattern 5: Non Specificare il Formato Output

Se non specifichi il formato dell'output, l'AI sceglie quello che ritiene appropriato. A volte va bene, ma spesso ottieni spiegazioni lunghe quando volevi solo il codice, o codice senza commenti quando ne avevi bisogno, o una soluzione parziale quando ti aspettavi quella completa.

Specificare il formato output in modo esplicito

# Formato output esplicito: esempi
"Mostrami SOLO il codice, senza spiegazioni."

"Fornisci prima una breve spiegazione dell'approccio (max 3 righe),
poi il codice completo, poi un esempio di utilizzo."

"Produce un diff nel formato git (+ per righe aggiunte, - per rimosse)."

"Mostrami solo le righe che cambiano, non l'intero file."

"Rispondi con un JSON nel formato:
{
  'analysis': 'breve analisi del problema',
  'solution': 'codice della soluzione',
  'tests': 'test unitari minimi',
  'caveats': 'limitazioni o assunzioni fatte'
}"

Metriche per Valutare la qualità dei Prompt

Come per il codice, anche i prompt possono essere migliorati iterativamente misurando la loro efficacia. Queste metriche ti permettono di capire oggettivamente se i tuoi prompt stanno migliorando nel tempo.

Metriche Quantitative

Metrica	Come Misurare	Target
Iterazioni per task	Conta i prompt necessari per un output accettabile	<3 per task standard
Tasso di accettazione	% di output accettato senza modifiche manuali	>60% per task ripetitivi
Test pass rate al primo run	% di codice generato che passa i test senza fix	>70%
Review time	Tempo medio per rivedere e approvare l'output	Decrescente nel tempo
Revert rate	% di commit AI-assisted che vengono poi revertiti	<5%

Metriche Qualitative

Oltre ai numeri, valuta periodicamente la qualità strutturale dei tuoi prompt rispondendo a queste domande:

Checklist di qualità per i tuoi prompt

# Checklist qualità prompt - Valutazione settimanale

CONTESTO
[ ] Ho specificato lo stack tecnologico con le versioni?
[ ] Ho incluso il codice rilevante (non tutto, ma quello collegato)?
[ ] Ho spiegato il contesto di business, non solo tecnico?
[ ] Ho specificato l'ambiente (dev/staging/prod)?

VINCOLI
[ ] Ho elencato cosa NON deve cambiare?
[ ] Ho specificato le librerie approvate/proibite?
[ ] Ho indicato i requisiti di performance o sicurezza?
[ ] Ho menzionato i vincoli di compatibilità?

OUTPUT ATTESO
[ ] Ho specificato il formato dell'output?
[ ] Ho indicato il livello di dettaglio (con test? con commenti?)?
[ ] Ho definito i criteri di successo?
[ ] Ho indicato cosa fare in caso di ambiguità?

STRUTTURA
[ ] Il prompt e focalizzato su un singolo problema?
[ ] E più corto di 2.000 token? (se no: usare chaining)
[ ] Il contesto critico e all'inizio e/o alla fine?
[ ] Ho usato il pattern giusto (zero-shot/few-shot/CoT)?

RED FLAGS
[ ] Sto usando parole vaghe come "migliorare", "ottimizzare", "pulire"?
[ ] Sto assumendo che l'AI conosca il mio progetto?
[ ] Sto chiedendo troppe cose contemporaneamente?
[ ] Sto omettendo il formato dell'output atteso?

Il Ciclo di Miglioramento Continuo

I prompt migliori non vengono scritti al primo tentativo: si evolvono nel tempo. Tratta i tuoi template di prompt come codice: versionali, testa le variazioni e aggiorna i file di configurazione persistenti quando scopri pattern che funzionano meglio.

Workflow di miglioramento continuo dei prompt

# Workflow: miglioramento iterativo dei prompt

# 1. Documenta i prompt che funzionano bene
# Salva in .claude/commands/ o in un docs/prompts/ folder

# 2. Quando un prompt fallisce, analizza perchè
"""
Post-mortem prompt fallito:
- Prompt: "Aggiungi logging al servizio"
- Problema: L'AI ha usato console.log invece di winston
- Causa root: non ho specificato la libreria di logging del progetto
- Fix CLAUDE.md: aggiunto "Logging: sempre winston, mai console.log"
"""

# 3. Aggiorna i file di configurazione persistenti
# CLAUDE.md aggiornato con:
# ## Logging
# SEMPRE usare winston (src/infrastructure/logger.ts)
# MAI usare console.log o console.error in produzione
# Livelli: error, warn, info, debug
# Formato: JSON strutturato con timestamp e request ID

# 4. Testa il prompt aggiornato
# 5. Misura il miglioramento (iterazioni necessarie)

Casi d'Uso Avanzati: Prompt per Scenari Complessi

Alcuni scenari di sviluppo richiedono approcci di prompting particolarmente sofisticati. Vediamo i più comuni con esempi concreti.

Prompt per Code Review Assistita

Usare l'AI come code reviewer richiede prompt che specificano il livello di rigore, le categorie di problemi da cercare e il formato del report.

Prompt per code review strutturata

# Prompt: code review sistematica
"""
Esegui una code review di questa Pull Request seguendo questi criteri.

Contesto PR:
- Feature: sistema di pagamento con Stripe
- Reviewer: sei un senior backend developer con focus su sicurezza
- Standard del team: Clean Architecture, Zod validation, 80% test coverage

Analizza il codice in questi ordini di priorità:

SICUREZZA (CRITICO - blocca la merge se trovato):
- Secrets o API keys hardcoded
- SQL injection o NoSQL injection
- Validazione input mancante o bypassabile
- Autenticazione/autorizzazione non corretta
- Esposizione di dati sensibili nei log o nelle risposte
- Riferimento OWASP Top 10 per ogni issue trovata

CORRETTEZZA (IMPORTANTE - richiede fix prima della merge):
- Bug logici o race conditions
- Error handling mancante per casi edge
- Violazioni delle invarianti di dominio
- Test mancanti per casi critici

DESIGN (MIGLIORAMENTO - fix in PR separata):
- Violazioni di principi SOLID
- Codice duplicato
- Nomi fuorvianti
- Complessità ciclomatica elevata (> 10)

Per ogni issue trovata, fornisci:
- File e riga
- Categoria (SICUREZZA/CORRETTEZZA/DESIGN)
- Descrizione del problema
- Codice problematico
- Suggerimento di fix con codice

Codice da revisionare:
[INCOLLA IL DIFF DELLA PR]
"""

Prompt per Migrazione Tecnologica

Le migrazioni tecnologiche (es: CommonJS a ES Modules, Prisma a Drizzle, Express a Fastify) richiedono prompt che gestiscono la complessità di una transizione graduale e retrocompatibile.

Prompt per migrazione graduale da CommonJS a ES Modules

# Prompt: migrazione tecnologica graduale
"""
Task: Migrazione graduale da CommonJS a ES Modules

Situazione attuale:
- 120 file .ts con require() e module.exports
- Node.js 22 (supporta ESM nativo)
- TypeScript 5.4 con "module": "commonjs" in tsconfig
- Build: tsc + ts-node per dev

Strategia richiesta: GRADUALE, non big-bang
- Non voglio migrare tutto in una PR
- I file CJS e ESM devono coesistere durante la transizione
- Zero regressioni durante la migrazione

Prima dimmi:
1. Qual è l'ordine ottimale di migrazione (quali file prima)?
2. Come configurare TypeScript per supportare entrambi i moduli?
3. Quali pattern CJS non hanno un equivalente ESM diretto?
4. Come gestire i __dirname e __filename nei moduli ESM?

Poi, partendo dall'analisi, migra SOLO questi 3 file come pilot:
- src/config/database.ts
- src/utils/logger.ts
- src/middleware/errorHandler.ts

Mostrami i file migrati e le modifiche a package.json e tsconfig.json.
"""

Best Practices: Il Decalogo del Prompt Engineering

Riassumiamo le pratiche più efficaci emerse dall'esperienza concreta con AI coding assistant in contesti di sviluppo professionale.

Contesto prima di tutto: ogni prompt deve iniziare con stack, versioni e architettura rilevante. Non dare nulla per scontato.
Un task per prompt: mantieni il focus. Se il task si estende su più dimensioni, usa il prompt chaining.
Specifica i vincoli esplicitamente: cosa non deve cambiare e importante quanto cosa deve cambiare.
Definisci il criterio di successo: come saprai che il risultato e accettabile? Indicalo nel prompt.
Usa file di configurazione persistenti: CLAUDE.md, .cursorrules e copilot-instructions.md sono investimenti con ROI alto nel lungo periodo.
Adatta il pattern al problema: zero-shot per task standard, few-shot per convenzioni custom, CoT per problemi algoritmici, meta-prompting per problemi mal definiti.
Posiziona il contesto critico all'inizio e alla fine: il modello da più peso alle posizioni di apertura e chiusura.
Itera sul prompt, non solo sul codice: se l'output non e quello atteso, spesso il problema e nel prompt, non nel modello.
Documenta i prompt che funzionano: crea una libreria di template per i task ricorrenti del tuo progetto.
Misura l'efficacia: tieni traccia del numero di iterazioni per task, del tasso di accettazione e del review time per migliorare continuamente.

Il Prompt Non Sostituisce la Revisione

Anche il prompt meglio strutturato non garantisce codice sicuro e corretto al 100%. Il 45% del codice AI-generated fallisce i test di sicurezza (Veracode 2025) indipendentemente dalla qualità del prompt. Il prompt engineering riduce il numero di iterazioni necessarie e migliora la qualità dell'output, ma la revisione umana critica rimane indispensabile, specialmente per codice che tocca autenticazione, autorizzazione, gestione di dati sensibili e logica finanziaria. Leggi l'articolo sulla sicurezza nel vibe coding per le linee guida specifiche.

Conclusioni: Il Prompt come Codice

Il prompt engineering per IDE AI non e un'arte misteriosa riservata a chi ha competenze particolari. E una disciplina tecnica con principi chiari, pattern riconoscibili e metriche misurabili. Come il codice, i prompt si scrivono, si testano, si refactorano e si migliorano nel tempo.

I developer che ottengono i migliori risultati dagli AI coding assistant hanno in comune un approccio sistematico: investono tempo nella configurazione dei file persistenti, usano pattern appropriati per ogni tipo di task, specificano contesto e vincoli in modo esplicito e trattano ogni prompt fallito come un'opportunità di miglioramento.

La differenza tra uno sviluppatore che "usa" l'AI e uno che "sa comunicare" con essa si misura in modo concreto: meno iterazioni per task, più output accettabili al primo tentativo, meno tempo speso a correggere manualmente il codice generato. Il ritorno sull'investimento nel prompt engineering e tra i più alti nell'intero ecosistema del vibe coding.

Il prossimo articolo della serie affronta il tema più critico di tutto questo paradigma: la sicurezza del codice AI-generated. perchè scrivere prompt perfetti che producono codice vulnerabile non e un miglioramento: e un pericolo più sottile del codice scritto male in modo visibile.

Prossimi Articoli della Serie

07 - Sicurezza nel Vibe Coding: I rischi del codice AI-generated, il 45% che fallisce i security test e le strategie di mitigazione concrete
08 - Il Futuro dello Sviluppo Agentico: Trend 2026, previsioni Anthropic sul ruolo dello sviluppatore e la roadmap degli agenti autonomi

      Punti Chiave da Ricordare
      Un prompt efficace ha tre componenti: Contesto, Vincoli, Output atteso
Usa zero-shot per task standard, few-shot per convenzioni custom, chain-of-thought
            per problemi algoritmici complessi
CLAUDE.md, .cursorrules e copilot-instructions.md sono investimenti ad alto ROI:
            configurali una volta, beneficiano ogni sessione
Il prompt chaining supera il mega-prompt per task complessi: un task per volta,
            valida ogni step
Gli anti-pattern più comuni sono: vaghi, troppo lunghi, contesto implicito,
            formato output non specificato
Tratta i prompt come codice: versionali, testali e migliorarli iterativamente
Il prompt migliore non sostituisce la code review: il 45% del codice AI fallisce
            i security test indipendentemente dalla qualità del prompt

    

      Articoli Correlati
      
          Serie Vibe Coding: Leggi gli altri articoli della serie per il
          quadro completo del vibe coding e sviluppo agentico
        
          Claude Code Deep Dive: Per padroneggiare la CLI di Anthropic e
          il suo sistema di configurazione CLAUDE.md
        
          Cursor IDE: Per la configurazione avanzata delle cursorrules e
          il workflow con Cursor Composer

Tool	File	Scope
Claude Code	`CLAUDE.md` (root) o `~/.claude/CLAUDE.md`	Progetto o globale
Cursor	`.cursorrules` o `.cursor/rules/*.mdc`	Progetto o per-file-type
GitHub Copilot	`.github/copilot-instructions.md`	Repository
Windsurf	`.windsurfrules`	Progetto
Tutti (standard)	`.ai-instructions.md` + import	Cross-tool (con tool specifici che lo importano)