Come uso Kiro ogni giorno — e non per scrivere codice

Sono un AWS Champion Authorized Instructor. Tengo più di 100 corsi all'anno, formo circa 3.000 professionisti, e gestisco piattaforme e-learning in italiano. Non sono un full-time developer.

Eppure Kiro è diventato lo strumento che apro per primo ogni mattina.

Non lo uso per scrivere app. Lo uso per produrre — copioni, quiz, audio, demo, pipeline. E funziona meglio di qualsiasi alternativa che ho provato.

Il problema che avevo

Ogni corso AWS ha circa 500 slide. Per ognuna devo avere:

• Un copione in italiano (per leggere in aula come un "gobbo digitale")
• Un file audio narrato (Amazon Polly, voce Adriano)
• Una presentazione con audio embedded che parte da sola
• Opzionalmente, un video MP4

Fare tutto manualmente è un incubo. Servono trascrizioni dei video instructor, allineamento con le slide, traduzione, formattazione per il TTS, generazione audio, embedding nel PPTX.

Prima di Kiro ci mettevo settimane. Ora un giorno lavorativo per corso.

Come Kiro ha cambiato il mio flusso

1. Spec-driven per la pipeline

Quando ho dovuto costruire la pipeline "Gobbo Digitale" (trascrizione → copione → audio → PPTX → video), ho usato lo sviluppo guidato da specifiche di Kiro.

Ho scritto in chat:

create a spec for a pipeline that takes AWS instructor enablement videos, 
transcribes them, generates Italian speaker notes slide-by-slide, 
and produces MP3 audio with Amazon Polly

Kiro ha generato requirements, design e tasks. Poi ha implementato gli script Python uno alla volta — generate_audio.py, embed_audio_all_modules.py, generate_videos.py — ciascuno con gestione errori, chunking per il limite di 3000 caratteri di Polly Neural, e tag SSML per la pronuncia dei termini inglesi.

Non ho scritto quegli script da zero. Li ho guidati.

2. Sub-agent per i quiz

Per il mio certification coach, processo 200+ domande d'esame. Ogni domanda va analizzata, tradotta, categorizzata per dominio e difficoltà, e trasformata in formato interattivo.

Uso il pattern sub-agent di Kiro: un agente principale orchestrala pipeline, delegando a sotto-agenti specializzati (traduzione, classificazione, generazione feedback). Il tutto con checkpoint di sessione — se si interrompe, riparte da dove era rimasto.

Nessun altro IDE mi dà questa capacità di orchestrazione su task non-coding.

3. Demo live in aula

Nel corso "Developing Generative AI Applications on AWS" c'è un modulo sugli agenti. La demo ufficiale AWS prevede di mostrare Amazon Bedrock Agents nella console.

Io faccio di meglio: apro Kiro davanti agli studenti e scrivo:

create a spec that adds a REST API endpoint for listing AWS certifications

In 3 minuti gli studenti vedono Kiro generare requirements, design, tasks, e poi implementare un'API funzionante con FastAPI. Avvio il server, apro Swagger UI, e testo le API live.

Il messaggio è chiaro: spec-driven development non è teoria, è un flusso di lavoro concreto.

Perché non Cursor, non Copilot

Ho provato entrambi. Funzionano bene per il coding puro. Ma il mio lavoro non è coding puro.

Cursor è veloce per scrivere codice, ma non ha il concetto di spec. Non posso dirgli "prima pensa, poi progetta, poi implementa". Parte subito a scrivere.

Copilot è ottimo come autocomplete, ma non orchestra. Non gestisce sessioni lunghe con centinaia di file da processare senza perdere il contesto.

Kiro mi dà:

• Struttura (specs) prima del codice
• Autonomia (autopilot) per task ripetitivi
• Contesto persistente (steering files) che gli dice chi sono, cosa faccio, come lavoro
• Hooks che lanciano automaticamente i miei script quando salvo un file

Per un trainer che produce contenuti, questa combinazione è imbattibile.

Numeri reali

Cosa consiglio a chi vuole provare

1. Non partire dal codice. Parti da una spec. Scrivi create a spec that... e descrivi cosa vuoi ottenere. Kiro ragiona meglio quando gli dai un obiettivo, non un'istruzione.

2. Usa steering files. Metti in .kiro/steering/ un file che descrive il tuo progetto, il tuo stile, le tue convenzioni. Kiro lo legge ad ogni interazione e mantiene coerenza.

3. Non trattarlo come ChatGPT. Non è una chat. È un agente. Dagli task, lascialo lavorare in autopilot, controlla il risultato. Se lo interrompi ogni 30 secondi, perdi il vantaggio.

4. Prova con un task non-coding. Un template email, una pipeline di processing, un generatore di contenuti. Kiro brilla quando il problema è di orchestrazione, non solo di syntax.

Conclusione

Kiro non è "l'ennesimo IDE con AI". È il primo strumento che mi permette di lavorare come penso: prima i requisiti, poi il design, poi l'esecuzione. Lo uso ogni giorno per produrre materiale che arriva davanti a migliaia di persone.

Se sei un trainer, un content creator tecnico, o qualcuno che lavora con volumi di contenuto strutturato — Kiro non è un'opzione. È un moltiplicatore.

Luca D'Addeo — AWS Champion Authorized Instructor, Leader AWS User Group Novara, 16x AWS Certified

Se vuoi vedere Kiro in azione, i miei repo sono pubblici: kiro-demos | cloud-ops-toolkit | kiro-certification-coach