Gli strumenti di codifica AI sono ancora in fase di ricerca e sviluppo

Secondo il sondaggio di Stack Overflow del 2024 , il 76% degli sviluppatori utilizza o pianifica di utilizzare strumenti di intelligenza artificiale: ormai sono solo una parte del lavoro. Aiutano con compiti banali, ma possono essere fastidiosi quando generano con sicurezza assurdità. Mentre gli YouTuber creano "startup da miliardi di dollari" con prompt ChatGPT e gli agenti di intelligenza artificiale conquistano il mondo ogni settimana, i team reali stanno ancora cercando di capire come utilizzare questi strumenti in modo efficace. Oggigiorno, padroneggiare l'assistenza dell'intelligenza artificiale è fondamentale quanto la codifica o la progettazione di sistemi: dobbiamo adattarci e in fretta.

Il problema è che questi strumenti sono essenzialmente ancora in una fase di R&S: cambiano costantemente, si copiano a vicenda e meritano di essere riconosciuti per aver risolto problemi precedentemente irrisolti. Sono tutti privi di chiare guide all'uso. Anche Copilot, nonostante sia più affermato, non ha tutorial e best practice chiari. La soluzione? Faremo ciò che gli sviluppatori sanno fare meglio: organizzare e creare un framework noi stessi.

Cambiamento di gioco

...e anche " Salto quantico ", " Cambio di paradigma ", " Arrivano gli agenti ", e così via. Mentre questi strumenti stanno effettivamente trasformando il nostro flusso di lavoro, il cambiamento è più pratico: gli sviluppatori ora operano come team leader, gestendo gli assistenti AI invece di scrivere direttamente il codice. Le competenze di base si sono spostate verso progettazione, pianificazione, descrizione e revisione.

I principali concetti UX introdotti da questi strumenti sono:

1. Suggerimenti in linea : il modello di integrazione più naturale. Quando funzionano, sono fluidi, ma quando interrompono il codice, si verifica un'interruzione immediata della produttività.
2. Chat : approccio classico in cui gli LLM interagiscono con la tua base di codice tramite prompt guidati
3. Composer (" Copilot Edit ", " Cline act ") - il nuovo concetto che molti trovano confuso . È uno spostamento verso agenti autonomi. Composer lavora su diversi file e può applicare modifiche e iterare automaticamente in base a errori, problemi di linting ecc.
4. Agenti : la prossima evoluzione prevista: assistenti AI completamente autonomi e personalizzati, integrati direttamente nel tuo IDE.

Familiarizzare con i " suggerimenti " non è complicato. Gli assistenti AI hanno iniziato con loro, che hanno attirato per primi la nostra attenzione. Le chat sono semplici: inserisci i file nel contesto, itera, applica e convalida i risultati.

Gli strumenti di tipo Composer presentano maggiori sfide da padroneggiare, richiedendo una curva di apprendimento e alcuni approcci non ovvi. Attualmente, l' editor Cursor offre lo strumento "compositore" più accessibile, mentre Copilot segue da vicino con " Copilot Edits ", avendo recentemente introdotto flussi di lavoro basati su agenti.

Per diventare esperti di composizione, è necessario comprendere tre concetti chiave:

1. Istruzioni
2. Regole
3. Contesto

Esaminiamoli uno per uno.

Istruzioni

Come team leader, piuttosto che semplici sviluppatori, dovremmo iniziare qualsiasi nuovo progetto o funzionalità importante creando un Design Document o un Product Requirements Document chiaro. Questa pratica sviluppa un solido pensiero ingegneristico e di prodotto, risparmiando al contempo un tempo di implementazione sostanziale. La parte migliore è che questi documenti possono essere:

1. Generato con AI
2. E poi utilizzato come istruzioni per i compositori

Per creare questi documenti, prima raccogli i requisiti dagli umani , quindi consulta il modello di ragionamento in Chat. Sia Copilot che Cursor hanno modelli di ragionamento integrati adatti a questo compito. o1 e o3-mini di OpenAI sono disponibili di default, mentre Chat di Cursor supporta DeepSeek-R1 (anche se non ancora nel suo Composer ), tutti strumenti eccellenti per questo scopo.

Una buona pratica è quella di archiviare i documenti di progettazione al livello superiore del tuo repo (utilizzeremo una cartella requirements ) organizzati per funzionalità, con un ProjectOverview.md nella root. Ecco un esempio di struttura per i requisiti di un'app web di Twitter:

 requirements/ ├── ProjectOverview.md # Core product description └── Features/ ├── Authentication.md # User registration ├── Tweet.md # Tweet CRUD ├── UserProfile.md # Profile management ├── Engagement.md # Likes, retweets ├── Infrastructure.md # Storage, caching, etc └── ...

Se tutto è impostato correttamente, aggiungere un documento di progettazione per una nuova funzionalità è semplice come scrivere questo prompt:

Memorizzare le istruzioni nella tua base di codice offre chiari vantaggi: controllo delle versioni, facile manutenzione e flusso di lavoro PR standard. Tuttavia, i membri del team non tecnici come Product Owner, manager e UX designer potrebbero aver bisogno di accesso senza usare git. Ecco tre soluzioni:

1. Memorizza tutto in Notion, pubblica le pagine di istruzioni e inseriscile come documentazione utilizzando la scorciatoia @Docs

2. Crea una pipeline che converte le pagine Notion in file .md e le memorizza nel repository
3. Insegna al tuo team a usare git: l'opzione più vantaggiosa per l'intero team

Una volta che le tue istruzioni sono accessibili nel tuo editor, passa al compositore e inizia a implementare. Questo ci porta a organizzare le Regole .

Regole

Attualmente, solo Cursor supporta " rules ", ovvero istruzioni di implementazione diretta per file/cartelle specifici. Questa funzionalità verrà probabilmente estesa ad altri editor, tra cui VSCode Copilot, che attualmente offre solo " file prompt " che non possono essere direttamente allegati alla base di codice.

Le regole di Cursor sono più complete: immagina CONTRIBUTING.md combinato con le regole linter e potenziato dalle capacità LLM. Queste regole sono indipendenti dal prodotto, condivisibili e trasferiscono efficacemente conoscenze, best practice e dettagli di implementazione tra team e utenti della libreria.

Le regole possono essere create tramite la palette dei comandi e sono archiviate nella cartella .cursor/rules del tuo progetto con un'estensione .mdc . Questo formato abilita funzionalità avanzate come @mentioning file specifici nella tua base di codice. È altamente consigliato inviare queste regole al tuo repository e collaborare per migliorarle. Ecco il flusso di lavoro per l'utilizzo delle regole:

1. Cerca le regole del cursore specifiche per il tuo stack tecnologico, iniziando con elenchi curati come riferimenti. Ad esempio, puoi trovare regole del cursore ben scritte per Next.js e React che fungono da buoni modelli.
2. Aggiorna le regole in modo proattivo durante lo sviluppo. Quando noti un pattern che potrebbe essere formalizzato in una regola durante la scrittura del codice, documentalo immediatamente nel tuo file di regole.
3. Impara dai migliori nel campo. Un nuovo approccio per i creatori di librerie per condividere la conoscenza e aumentare l'adozione è la creazione di regole specializzate per gli assistenti AI. Conosco poche aziende che lo fanno: Convex si distingue per la creazione di regole sia per i modelli OpenAI che Anthropic e per la loro condivisione nella loro documentazione . Sebbene non abbia utilizzato il loro prodotto, la loro attenzione al miglioramento dell'esperienza degli sviluppatori tramite l'integrazione AI è convincente. Supabase è un altro ottimo esempio .

Molte librerie hanno urgente bisogno di regole AI. Dal punto di vista di uno sviluppatore frontend, ne trarrei beneficio per TanStack Query , React Spring , Firebase e molti altri. Queste regole farebbero risparmiare molto tempo e aiuterebbero a prevenire errori comuni che gli sviluppatori commettono quando apprendono nuove tecnologie.

Contesto

Ricordati di includere tutto il contesto pertinente: più dati di qualità fornisci, migliori saranno i risultati che otterrai. L'editor di cursori ha un vantaggio rispetto a Copilot in questo caso, consentendo diversi tipi di contesto:

1. Documentazione: funziona davvero bene, basta fornirgli un punto di accesso a qualsiasi documentazione, la scaricherà, la analizzerà e la salverà per esigenze future
2. Ricerca sul Web: non strettamente contestuale, fornisce un rapido accesso alle risorse online
3. Vari strumenti di sviluppo: commit git specifici, errori lint, blocchi note e altri artefatti
4. I server MCP possono fornire contesto in tempo reale. Sebbene la configurazione possa essere un po' complicata, sono preziosi quando hai bisogno di accesso ai dati in tempo reale.

Dopo aver padroneggiato questi strumenti, il passo successivo è ottimizzare le prestazioni individuali e di squadra. Ma qual è il percorso da seguire da qui?

Cline e Roo-Code. Il controllo

Ti troverai sempre di fronte a un compromesso tra semplicità e controllo, tra soluzioni automatizzate e processo decisionale manuale. Se sei disposto a tuffarti in profondità e non hai paura di affrontare bug, sfide di prestazioni e spigoli, prendi in considerazione di provare Cline (o il suo fork Roo-Code , che ha una filosofia leggermente diversa).

Entrambi gli strumenti sono progettati per fornire la massima trasparenza possibile su ciò che accade realmente sotto il cofano:

1. Sono open source e senza abbonamento. Invece, utilizzi le tue chiavi API LLM o servizi come OpenRouter , pagando solo per ciò che utilizzi.
2. Cline mostra chiaramente tutte le sue operazioni, compresi i file che legge e modifica.
3. Cline fornisce approfondimenti dettagliati sulle comunicazioni LLM, sullo stato della finestra di contesto e sul costo di ogni sessione di chat.
4. È dotato di modalità intuitive Pianifica/Agisci: un approccio logico che altri strumenti dovrebbero prendere in considerazione.

La caratteristica più interessante è che Cline può effettivamente eseguire ed effettuare il debug della tua applicazione: è reale e funzionale, come vedrai quando lo proverai.

Se tutto questo vi interessa, date un'occhiata al recente articolo di Addy Osmani , che fornisce un'eccellente introduzione a questi editor.

Conclusione

Adottare questi strumenti non è un percorso semplice e non aspettatevi di scrivere "l'intero progetto da zero in meno di 5 minuti". Tuttavia, questa è una chiara strada da seguire.

La tecnologia è già lì, ma ci manca un flusso di lavoro solido e integrato con l'IA che organizzi l'intero team, non solo gli sviluppatori, ma soprattutto i manager e i designer, attorno a questi nuovi strumenti. L'IA può sembrare intimidatoria e condividere il suo impatto può sembrare scomodo all'inizio (come dire al tuo team leader che l'IA ha scritto l'80% di una funzionalità tramite un'attenta configurazione). Tuttavia, lo sviluppo software si evolverà solo quando questi strumenti diventeranno parte integrante dei flussi di lavoro del team. Le transizioni di maggior successo si verificano nei team che promuovono una discussione aperta sulle esperienze di IA, l'esplorazione collaborativa degli strumenti e contribuiscono attivamente con le loro best practice apprese alla più ampia comunità di sviluppo.