MediaMeeting.it
AI per attività e professioni

AI per sviluppatori: crea prompt migliori per codice, debug e sviluppo

Configura prompt tecnici per analizzare codice, correggere errori, fare refactoring, generare query e documentare software.

01

Preset di partenza

Scegli un modello pronto e personalizzalo in base alle tue esigenze.

Scegli un punto di partenza

Il preset prepara i campi: potrai modificarli prima di generare.

02

AI di destinazione e impostazioni iniziali

Scegli l’AI e personalizza il tipo di output.

Modalità
Formato del prompt
03

Compila i campi

Fornisci le informazioni richieste per personalizzare il prompt.

Creare un endpoint REST che restituisca gli ordini filtrati.
Implementare una funzione per validare e normalizzare un payload.
Aggiungere paginazione accessibile a una tabella.
Scrivere un comando CLI per importare un file CSV.
Creare un componente riutilizzabile per [funzionalità].
Scrivere una descrizione efficace per una pagina servizio.
Preparare una guida introduttiva su [argomento].
Creare una comunicazione chiara per il lancio di [prodotto].
Riassumere un tema complesso per un pubblico non specializzato.
Definire un piano di lavoro pratico per raggiungere [risultato].
MySQL 8.0.
MariaDB 10.6.
PostgreSQL 16.
SQLite per l’ambiente di test.
Motore SQL già configurato nel progetto.
PHP 8.2 senza framework.
TypeScript con React 18.
Java 21 con Spring Boot.
Go 1.23 con libreria standard.
Python 3.12 con FastAPI.
PHP 8.2.
TypeScript.
SQL compatibile con MySQL 8.
Java 21.
Go 1.23.

Non inserire password, API key, token o altri dati riservati.

Incolla qui la funzione o la classe da analizzare.
Inserisci il componente che presenta il problema.
Riporta la query e il codice che la esegue.
Aggiungi il test che attualmente fallisce.
Incolla soltanto il frammento minimo riproducibile.
users(id, email, status, created_at); orders(id, user_id, total, status).
products(id, sku, name, price); stock(product_id, quantity).
posts(id, title, published_at); tags(id, name); post_tags(post_id, tag_id).
events(id, starts_at, venue_id); venues(id, name, city).
tickets(id, priority, assignee_id, closed_at); users(id, display_name).
Piccole imprese che vogliono migliorare la propria presenza online.
Persone che si avvicinano per la prima volta a [argomento].
Professionisti con poco tempo e conoscenze intermedie.
Clienti che conoscono il problema ma non ancora la soluzione.
Un team interno che deve prendere una decisione condivisa.
Sviluppatori che conoscono PHP ma non questo progetto.
Nuovi membri del team tecnico.
Integratori esterni che useranno l’API.
Amministratori di sistema con conoscenze intermedie.
Contributori open source alla prima installazione.

Riporta il messaggio completo e descrivi quando si verifica.

Al secondo invio compare un record duplicato.
Con un input vuoto viene restituito un errore 500.
L’ultimo elemento non appare nella risposta.
Il filtro viene perso cambiando pagina.
Il processo supera il limite di memoria con file grandi.
Individua bug, regressioni e rischi di sicurezza.
Valuta chiarezza, testabilità e casi limite.
Controlla compatibilità e impatto sulle API pubbliche.
Verifica query, transazioni e gestione degli errori.
Concentrati sulle modifiche della patch, non sul refactoring generale.
Separare validazione, accesso dati e rendering.
Eliminare duplicazioni tra due flussi equivalenti.
Ridurre la complessità senza cambiare comportamento.
Rendere il componente testabile senza dipendenze globali.
Sostituire condizioni sparse con una configurazione centrale.
Un array PHP con id, nome e stato.
Un payload JSON conforme allo schema allegato.
Una stringa UTF-8 e un limite massimo di lunghezza.
Parametri da CLI e variabili d’ambiente.
Record provenienti da una query preparata.
Il salvataggio deve completarsi una sola volta.
Il filtro deve aggiornare i risultati mantenendo la pagina corrente.
Il comando deve ignorare righe vuote e segnalare quelle non valide.
La sessione deve scadere dopo il periodo configurato.
L’utente deve ricevere un errore chiaro senza perdere i dati inseriti.
Registrazione utenti, ruoli e gestione profilo.
Catalogo, ricerca, filtri e preferiti.
Dashboard, esportazione CSV e notifiche.
Prenotazioni, disponibilità e promemoria.
Area amministrativa, audit log e permessi.
PHP 8.2.
PHP 8.1 o superiore.
La versione indicata in composer.json.
PHP 8.3 con strict_types.
Stessa versione dell’ambiente di produzione.
PHP 8.2.12 su Windows con Apache.
Node.js 20 LTS su Ubuntu.
Chrome stabile su Android.
MySQL 8 in container Docker.
Ambiente di staging equivalente alla produzione.
WordPress 6.6.
WordPress 6.5 o superiore.
Versione corrente del sito di staging.
Ultime due versioni principali supportate.
Versione minima dichiarata nel plugin.
Plugin per gestire eventi e iscrizioni.
Tema child per un sito editoriale.
Plugin con endpoint REST personalizzati.
Blocco Gutenberg per mostrare una scheda prodotto.
Plugin amministrativo senza output pubblico.
id, status, created_at e user_id.
email, role e last_login_at.
sku, price, stock e category_id.
title, slug, published_at e author_id.
order_id, amount, currency e payment_status.
Creazione, modifica, visualizzazione ed eliminazione.
Accesso valido, credenziali errate e sessione scaduta.
Importazione completa, parziale e file non valido.
Ricerca senza risultati, con un risultato e con più pagine.
Pagamento riuscito, rifiutato e webhook duplicato.
Solo record attivi degli ultimi 30 giorni.
Filtra per stato e intervallo di date opzionali.
Escludi righe senza relazione valida.
Raggruppa per cliente e ordina per totale decrescente.
Restituisci solo risultati visibili all’utente corrente.
Il servizio è già disponibile e il pubblico conosce solo in parte il problema.
Il contenuto verrà pubblicato sul sito e riutilizzato nella newsletter.
Il progetto è in fase iniziale e occorre chiarire priorità e passaggi.
Sono già disponibili dati interni, ma devono essere organizzati.
La comunicazione deve essere utile anche a chi non conosce il settore.
Input vuoto, duplicati e caratteri Unicode.
Timeout, risposta parziale e servizio non disponibile.
Zero risultati, una sola riga e ultima pagina.
Date al cambio d’ora e fusi orari diversi.
Utente non autorizzato e sessione scaduta.
Un array ordinato senza duplicati.
Una risposta JSON con dati e metadati di paginazione.
Una patch minima accompagnata da test.
Una query parametrizzata e il relativo indice consigliato.
Un piano di implementazione con criteri di verifica.
Consulente esperto nel settore.
Editor specializzato in contenuti divulgativi.
Analista capace di distinguere fatti, ipotesi e raccomandazioni.
Formatore che usa un linguaggio semplice e concreto.
Project manager orientato a priorità e risultati misurabili.
Servizi piccoli con responsabilità singola.
Architettura modulare senza introdurre un framework.
Repository per l’accesso dati e controller sottili.
Componenti riutilizzabili con dipendenze esplicite.
Approccio semplice, testabile e coerente con il progetto.
Ho invalidato la cache e verificato la configurazione.
Ho isolato il problema con un test minimo riproducibile.
Ho controllato log applicativi e risposta HTTP.
Ho provato con dati diversi ottenendo lo stesso errore.
Ho aggiornato la dipendenza senza risolvere il problema.
Usa le tabelle esistenti senza migrazioni.
Salva lo stato in PostgreSQL con transazione.
Mantieni una cronologia append-only.
Usa cache solo come ottimizzazione, non come fonte primaria.
Nessuna persistenza: i dati vivono per la singola richiesta.
Sessione sicura, CSRF e rigenerazione dell’identificativo.
OAuth 2.0 con ruoli utente e amministratore.
Accesso tramite magic link con scadenza breve.
Autenticazione a due fattori per gli amministratori.
Nessuna autenticazione nella prima versione locale.
PHP 8.2, PDO e PHPUnit.
React 18, TypeScript e Vitest.
Node.js 20, Express e PostgreSQL.
WordPress core e API REST.
Solo librerie già presenti nel progetto.
API REST per pagamenti e webhook firmati.
Servizio email con autenticazione tramite token.
Endpoint interno per catalogo e disponibilità.
OAuth 2.0 con refresh token.
Nessuna integrazione esterna nella prima versione.
Un esempio minimo e uno con gestione degli errori.
Tre casi d’uso con input e output atteso.
Un esempio CLI e uno tramite API.
Un caso standard e due casi limite.
Un frammento completo ma privo di dipendenze superflue.
Simula solo il client HTTP esterno.
Usa un database temporaneo invece di mockare PDO.
Sostituisci orologio e generatore di identificativi.
Non usare mock: testa l’unità con input deterministici.
Fornisci stub minimi per filesystem e coda.
Copri almeno i rami principali e tutti gli errori noti.
Aggiungi test per valori limite e input vuoti.
Copri il flusso autenticato e quello non autorizzato.
Verifica almeno un caso valido e tre casi non validi.
Mantieni la copertura attuale senza imporre una percentuale.
Risposta sotto 300 ms per 10.000 record.
Elabora il file senza caricarlo interamente in memoria.
Evita query N+1 nella pagina elenco.
Supporta 100 richieste concorrenti senza stato condiviso.
Mantieni invariato il numero di chiamate esterne.
Utenti, catalogo, ordini e notifiche.
Autenticazione, dashboard e report.
Importazione, validazione ed esportazione.
API, backoffice e audit log.
Plugin principale, blocco editor e impostazioni.
Massimo 500 parole; evita termini troppo tecnici.
Usa solo le informazioni fornite e segnala ciò che manca.
Non inventare dati, fonti o risultati.
Mantieni frasi brevi e una struttura facile da scansionare.
Distingui chiaramente fatti, ipotesi e suggerimenti.
Prerequisiti, installazione, configurazione, esempio e problemi comuni.
Panoramica, API pubblica, esempi e limiti.
Procedura passo passo con verifica finale.
Decisione, contesto, alternative e conseguenze.
Guida rapida seguita da riferimenti tecnici.
Nomi espliciti e funzioni con una sola responsabilità.
Commenti solo sulle decisioni non ovvie.
Evita annidamenti oltre tre livelli.
Mantieni lo stile già usato nel repository.
Preferisci codice lineare a catene difficili da debuggare.
PHP, Composer e database configurato.
Node.js LTS e variabili d’ambiente disponibili.
Permessi di amministratore su WordPress.
Accesso in lettura al repository e al log applicativo.
Dataset di esempio privo di dati sensibili.
Prepared statement, escaping output e controllo CSRF.
Validazione server-side e autorizzazione per risorsa.
Segreti solo in variabili d’ambiente.
Rate limit e log senza dati sensibili.
Password con password_hash e cookie di sessione sicuri.
PHP 8.1+, MySQL 8 e MariaDB 10.6.
Browser evergreen e Safari delle ultime due versioni.
WordPress 6.5+ senza dipendenze premium.
Node.js 20 LTS in ambiente Linux.
Compatibilità con l’API pubblica esistente.
Riduci duplicazioni mantenendo nomi espliciti.
Separa accesso dati e logica applicativa.
Mantieni funzioni brevi e dipendenze visibili.
Evita astrazioni non necessarie.
Rendi semplici l’aggiunta di nuovi casi e i test.
Mantieni invariata la firma pubblica del metodo.
Non modificare il formato della risposta JSON.
Conserva supporto per PHP 8.1 e versioni successive.
I link esistenti devono continuare a funzionare.
Evita modifiche allo schema del database.
Concentrati sulla condizione di gara durante il salvataggio.
Verifica la gestione dei valori nulli.
Controlla il calcolo dell’indice nell’ultimo elemento.
Analizza la perdita dello stato dopo il redirect.
Individua perché l’errore compare solo al secondo invio.
Segui PSR-12 e usa strict_types.
Mantieni le convenzioni già presenti nel repository.
TypeScript strict senza any.
API REST con nomi coerenti e risposte prevedibili.
CSS senza framework e classi orientate al componente.
Restituisci errori tipizzati senza dettagli interni.
Registra il contesto tecnico e mostra un messaggio neutro.
Gestisci timeout con un solo tentativo controllato.
Usa codici HTTP coerenti e una risposta JSON stabile.
Interrompi l’operazione e conserva lo stato precedente.
Il comando termina con exit code 0 e produce l’output atteso.
La pagina funziona da 320 px in su senza scroll orizzontale.
Gli errori sono gestiti senza esporre dettagli sensibili.
I test coprono percorso principale, casi limite ed errori.
La soluzione mantiene compatibilità con la versione corrente.
Non modificare il database o le API pubbliche.
Escludi autenticazione e pagamenti.
Non introdurre nuove dipendenze.
Non riscrivere i componenti non coinvolti.
Non includere deployment o configurazione server.

Scorciatoie utili

Aggiungi istruzioni rapide per definire meglio come deve rispondere l’AI.

Puoi selezionarne fino a 5.

Suggerimenti per risultati migliori

  • Sii specifico e fornisci contesto.
  • Indica il tono di voce desiderato.
  • Aggiungi il contesto davvero utile.
  • Definisci chiaramente l’obiettivo.
  • Verifica sempre dati e condizioni.
Dati e sicurezza

Condividi solo il codice necessario

Rimuovi password, API key, token, dati personali e configurazioni riservate prima di incollare qualsiasi estratto.

Applicazioni concrete

Cosa puoi fare con l’AI nello sviluppo

01

Generazione di codice

Crea funzioni, script e componenti a partire da requisiti chiari.

02

Progettazione di app e funzionalità

Trasforma un’idea in requisiti, architettura e piano di sviluppo.

03

Debug e analisi errori

Fornisci codice, messaggio e comportamento atteso per ottenere una diagnosi mirata.

04

Comprensione del codice

Adatta la spiegazione al livello di chi legge e concentra l’analisi sui passaggi importanti.

05

Refactoring

Definisci obiettivi e compatibilità prima di chiedere modifiche incrementali.

06

SQL

Descrivi schema, condizioni e risultato per produrre query verificabili.

07

Test

Trasforma casi principali e limiti in una suite coerente.

08

Documentazione

Crea guide e riferimenti calibrati sui destinatari reali.

Controllo tecnico

Errori da evitare

Il builder struttura la richiesta, ma codice e query devono essere revisionati e testati nel loro ambiente reale.

  1. Incollare codice senza spiegare il problema o il risultato atteso.
  2. Omettere versioni, framework e dipendenze che cambiano la soluzione.
  3. Chiedere una riscrittura completa quando basta una correzione circoscritta.
  4. Accettare codice generato senza testarlo e revisionarlo.
  5. Condividere password, token, chiavi API o altri dati riservati.