Come uso l'AI da sviluppatrice full-stack: il mio vero stack di automazione
Non è un post hype su "10x con l'AI". Un percorso concreto su dove l'AI si trova davvero nel mio lavoro quotidiano da sviluppatrice full-stack — codice, pipeline di contenuti, traduzioni, test, deploy — e dove faccio ancora il lavoro io stessa.
Mi fanno una versione della stessa domanda: "costruisci siti web e soluzioni AI, quindi quanto del tuo lavoro fa davvero l'AI?" La risposta onesta è a più livelli. L'AI scrive gran parte della prima bozza del mio codice. Non prende nessuna delle decisioni di giudizio. Fa girare intere pipeline in questo progetto senza supervisione. Non tocca mai la produzione senza che un umano legga prima il diff. Sotto c'è lo stack reale, non la versione da pitch.
1. Codice: pair programming, non pilota automatico
La maggior parte del mio uso quotidiano dell'AI è Claude Code seduto accanto a me nel terminale, dentro proprio questo repository. Descrivo un componente, un bug, un refactoring nelle sette cartelle di lingua sotto src/app, e lui abbozza la modifica. Leggo ogni diff prima che atterri — allo stesso modo in cui revisionerei la PR di una junior. L'AI è molto brava in "applica questo pattern in modo coerente a 40 file" e sensibilmente peggiore in "decidi se questo pattern dovrebbe esistere". Quindi tengo per me questo secondo lavoro.
I vantaggi concreti: costruire una volta una nuova page factory e lasciare che l'AI cablasse da lì ogni variante di lingua, scrivere il primo passaggio di una suite Vitest per una nuova funzione di lib, tradurre uno stack trace in una causa radice in italiano semplice prima di mettermi io stessa a scavare, e abbozzare i messaggi di commit da un diff per non fissare un cursore vuoto.
2. Pipeline di contenuti e i18n che girano senza di me
Questo sito pubblica ogni articolo del blog fino a sette lingue: en, ua, de, fr, es, it, tr. Scrivo le versioni inglese e ucraina a mano — quella parte resta mia, perché tono e precisione tecnica contano e non voglio una voce tradotta a macchina spacciata per mia. Le lingue restanti vengono riempite da script in scripts/ che percorrono l'albero di contenuti localizzati e chiamano un'API di traduzione per ogni campo senza lingua, mettono in cache il risultato così le riesecuzioni non ripagano stringhe che ho già, e falliscono rumorosamente invece di scrivere silenziosamente una stringa vuota in una pagina.
Lo stesso istinto di automazione si vede anche fuori dal blog: sitemap.ts rigenera ogni rotta in ogni lingua al momento della build invece che io mantenga una lista a mano, il feed RSS e i file llms.txt / llms-full.txt sono derivati dagli stessi dati dei post, quindi non possono disallinearsi da ciò che è realmente pubblicato, e la CI esegue l'intero passaggio di test e lint a ogni push prima che qualcosa raggiunga il workflow di deploy nextjs.yml.
3. AI dentro il prodotto, non solo intorno
L'altra metà di "AI nel mio workflow" è ciò che consegno per il GEO — generative engine optimization, rendere un sito leggibile per un LLM allo stesso modo in cui la SEO lo rende leggibile per un crawler di ricerca. Concretamente: llms.txt e llms-full.txt descrivono questo sito in un formato che un agente può fare il parsing direttamente, dati strutturati JSON-LD sulle pagine di servizi e blog così un modello può estrarre fatti invece di indovinare dalla prosa, e un componente di markup dello schema che resta sincronizzato con il contenuto reale della pagina invece di un blocco statico che qualcuno ha dimenticato di aggiornare.
Questo è il confine che mi interessa davvero: l'AI che mi aiuta a costruire il sito è invisibile per una visitatrice. L'AI che aiuta il sito stesso a essere compreso da altre AI è una funzionalità che costruisco e testo esplicitamente — c'è una suite Vitest dedicata agli helper del feed GEO, proprio perché questo non si deteriori silenziosamente come finisce per fare qualsiasi integrazione non testata.
4. Dove tengo il posto umano
Niente di tutto ciò significa che l'AI decida cosa va in produzione. Non sceglie l'architettura delle informazioni, non sceglie quali pagine di servizi esistano, non decide che un modulo di contatto ha bisogno di una regola di validazione in più invece di tre campi in meno — quel giudizio è il vero lavoro, ed è esattamente ciò per cui i clienti pagano quando assumono una sviluppatrice invece di un generatore. L'AI abbozza; io faccio il merge. L'AI traduce; io scrivo la fonte. L'AI propone un refactoring; io decido se l'astrazione merita il suo posto, seguendo la stessa disciplina di non aggiungere struttura di cui la codebase non ha ancora bisogno.
Se stai cercando di capire dove l'AI fa davvero risparmiare tempo in un prodotto reale — rispetto a dove sposta solo l'onere della revisione — di solito è questa la domanda giusta da porsi prima di automatizzare qualsiasi cosa: quale decisione sto davvero togliendo a un essere umano, e sono d'accordo che quella decisione venga presa da uno script?
Vuoi che lo imposti anche per il tuo progetto?
Costruisco questo tipo di workflow assistito dall'AI e incentrato sull'automazione anche nei progetti dei clienti — dai deploy controllati dalla CI a una struttura di contenuti pronta per il GEO. Scrivimi tramite il modulo di contatto e dimmi quale parte del tuo processo ti sta ancora divorando la settimana.
Va costruito, non solo letto?
Soluzioni IA per il business: RAG, agenti, Next.js. Contraente diretta.
Parliamo del tuo progetto?
Sono un’ingegnera web senior, specializzata in React e Next.js - disponibile per progetti freelance in tutto il mondo.
Dove sono
Kyiv, Ucraina
Upwork
Vedi il profiloTelegram
ContattamiViber
Contattami