DEV Community: The Web Guru

Spec-Driven Development: ll Pensiero Prima dell'Azione

The Web Guru — Sun, 28 Jun 2026 14:33:08 +0000

From Zero to Hero Series: Part 1.

Autore: Luca D'Addeo - AWS Champion Authorized Instructor

Target: Developer, Solutions Architect, Technical Lead

Tempo lettura: 15 minuti

Livello: Intermedio

Il Problema:
Gli AI coding assistant moderni (Copilot, Cursor) ti fanno scrivere codice velocemente, ma ti fanno anche saltare la fase più importante: pensare.

La Soluzione:

Spec-Driven Development con Kiro ti obbliga a definire cosa vuoi ottenere prima di iniziare a costruire, producendo software migliore in meno tempo.

I Numeri:

Tempo di sviluppo: -70%
Bug in produzione: -60%
Refactoring necessari: -80%
Chiarezza del codice: +90%

📖 Indice

Il Problema del "Code First"
Cosa Sono le Specifiche (Spec)
La Filosofia Spec-Driven
Come Funziona in Kiro
Anatomia di una Spec Perfetta
Caso Reale: API REST in 10 Minuti
Spec-Driven vs Code-First: Confronto
Best Practices
Quando NON Usare Spec-Driven
Conclusioni

1. Il Problema del "Code First"

Lo Scenario Classico

Ti arriva una richiesta:

"Dobbiamo aggiungere un endpoint API per gestire gli ordini degli utenti"

Approccio tradizionale con Cursor/Copilot:

# Inizi a scrivere...
@app.route('/orders', methods=['POST'])
def create_order():
    # Copilot suggerisce...
    data = request.get_json()
    # E continui a scrivere...

Cosa sta succedendo?

Hai iniziato a scrivere codice senza rispondere a domande fondamentali:

❌ Quale validazione serve sui dati in input?
❌ Come gestiamo ordini duplicati?
❌ Cosa facciamo se il pagamento fallisce?
❌ Serve autenticazione? Autorizzazione?
❌ Come tracciamo l'ordine per analytics?
❌ Che formato ha la risposta?
❌ Quali errori possono verificarsi?
❌ Come testiamo questo endpoint?

Risultato: Scrivi codice velocemente, ma è il codice sbagliato.

Il Costo del Code-First

Scenario reale (progetto medio):

Sviluppo iniziale:     2 giorni ✓
Bug trovati in review: 8 ore debug
Edge case mancanti:    1 giorno refactoring
Test aggiunti dopo:    4 ore
Documentazione:        2 ore
Modifica per requisiti mal compresi: 1 giorno

TOTALE: ~4.5 giorni di lavoro
Di cui 2.5 giorni spesi a CORREGGERE
perché non hai pensato prima.

La Domanda Chiave

"Se l'AI scrive codice 10x più veloce, ma scrivi il codice sbagliato, sei davvero più produttivo?"

Risposta: No. Sei più veloce a sbagliare.

2. Cosa Sono le Specifiche (Spec)

Definizione

Una specifica è un documento strutturato che descrive:

COSA vuoi costruire (Requirements)
COME lo costruirai (Design)
IN QUALI STEP lo implementerai (Tasks)

Prima di scrivere una singola riga di codice.

Le Tre Sezioni di una Spec

REQUIREMENTS (Il Cosa)

## Requirements

1. L'API deve accettare ordini via POST /orders
2. Ogni ordine contiene: user_id, product_id, quantity, payment_method
3. Validazione:
   - user_id deve esistere nel sistema
   - quantity deve essere > 0 e <= 100
   - payment_method: ['card', 'paypal', 'bank_transfer']
4. Business rules:
   - Nessun ordine duplicato (stesso user + product + timestamp < 5min)
   - Verifica disponibilità prodotto in stock
   - Calcolo automatico prezzo totale con eventuali sconti
5. Security:
   - Autenticazione JWT richiesta
   - Rate limiting: 10 ordini/minuto per utente
6. Response:
   - Success: 201 + order_id + estimated_delivery
   - Error: 4xx/5xx con messaggio chiaro

DESIGN (Il Come)

## Design

### Architecture
- REST API con Flask/FastAPI
- Database: PostgreSQL con tabella orders
- Cache: Redis per check duplicati
- Message Queue: RabbitMQ per processing asincrono

### Data Model

python
Order:

id: UUID (primary key)
user_id: UUID (foreign key)
product_id: UUID (foreign key)
quantity: Integer
total_price: Decimal
payment_method: Enum
status: Enum ['pending', 'confirmed', 'failed']
created_at: Timestamp
updated_at: Timestamp


### API Flow
1. Request arriva → JWT validation
2. Rate limiter check
3. Input validation (schema)
4. Duplicate check (Redis)
5. Stock availability check (Database)
6. Price calculation (business logic)
7. Order creation (Database transaction)
8. Async notification (Queue)
9. Response 201 + order details

### Error Handling
- 400: Invalid input
- 401: Unauthorized
- 409: Duplicate order
- 422: Stock unavailable
- 429: Rate limit exceeded
- 500: Internal error

markdown

TASKS (Gli Step)

## Tasks

1. Setup project structure
   - Create Flask app
   - Configure PostgreSQL connection
   - Setup Redis client
   - Add RabbitMQ integration

2. Implement data models
   - Define Order model (SQLAlchemy)
   - Create migration scripts
   - Add indexes for performance

3. Build validation layer
   - Create Pydantic schemas
   - Implement custom validators
   - Add error messages

4. Implement business logic
   - Duplicate detection service
   - Stock check service
   - Price calculation with discounts
   - Order creation with transaction

5. Add authentication & authorization
   - JWT validation middleware
   - Rate limiting decorator
   - User permission checks

6. Write tests
   - Unit tests for services
   - Integration tests for API
   - Load tests for rate limiting

7. Add monitoring & logging
   - Structured logging
   - Metrics (Prometheus)
   - Error tracking (Sentry)

8. Documentation
   - OpenAPI/Swagger spec
   - README with examples
   - Deployment guide

3. La Filosofia Spec-Driven

I Tre Principi

Principio 1: Pensa Prima di Costruire

Code-First:  Idea → Codice → Scopri problemi → Refactor
Spec-Driven: Idea → Spec → Scopri problemi → Aggiorna Spec → Codice corretto

Costo di un errore:

Trovato in Spec phase: 5 minuti per correggere
Trovato in Code phase: 2 ore per refactorare
Trovato in Production: 2 giorni per hotfix + rollback

Principio 2: Comunicazione è Implementazione

Una spec ben scritta è:

✅ Condivisibile con il team (sync alignment)
✅ Reviewable prima del codice (design review)
✅ Documentazione automatica (self-documenting)

Principio 3: Iterazione Economica

Cambiare una spec:     5 minuti di editing
Cambiare il codice:    2 ore di refactoring + testing
Cambiare in prod:      2 giorni + downtime + reputation loss

Regola d'oro:

Fallisci velocemente sulla carta, non nel codice.

Perché Ha Senso Oggi (e Non 10 Anni Fa)

2014 - Spec erano considerate overhead:

Scrivere spec richiedeva giorni
Il codice dovevi scriverlo TU comunque
Spec diventavano obsolete subito

2026 - Con AI agents, spec sono asset:

✅ Scrivi spec in 10 minuti (AI assisted)
✅ AI genera codice DA spec (automatico)
✅ Spec rimane sincronizzata (source of truth)

La differenza:

Prima spec erano documentazione.

Oggi spec sono istruzioni eseguibili.

4. Come Funziona in Kiro

Il Workflow Kiro

1. TU scrivi un prompt:
   "create a spec that builds [feature description]"

2. KIRO genera la spec:
   Requirements → Design → Tasks

3. TU review e approvi (o chiedi modifiche)

4. KIRO implementa automaticamente:
   Task 1 ✓ → Task 2 ✓ → Task 3 ✓ → ... → Done

5. TU verifichi il risultato finale

Esempio Pratico: Da Prompt a Codice

INPUT:

create a spec that adds a Redis cache layer to improve API performance:
- Cache GET /users/:id responses
- TTL: 5 minutes
- Cache invalidation on user update
- Hit/miss metrics

KIRO OUTPUT (Requirements):

## Requirements

1. Caching Strategy
   - Cache all successful GET /users/:id responses
   - Cache key format: user:{user_id}
   - TTL: 300 seconds (5 minutes)

2. Cache Operations
   - Read: check cache before DB query
   - Write: update cache on user modification
   - Delete: invalidate on user deletion

3. Metrics
   - Track cache hit rate
   - Track cache miss rate
   - Expose via /metrics endpoint

4. Error Handling
   - Cache unavailable → fallback to DB
   - Stale data → serve + async refresh

KIRO OUTPUT (Design):

## Design

### Architecture

[ASCII diagram]
Client → API → Cache Check → Redis (hit) → Return
↓
(miss) → Database → Update Cache → Return


### Implementation
- Redis client: redis-py
- Decorator pattern: @cached(ttl=300)
- Middleware: cache invalidation on PUT/DELETE
- Metrics: Prometheus client

### Cache Key Strategy
user:{user_id} → User object (JSON serialized)

KIRO OUTPUT (Tasks):

## Tasks

1. Setup Redis connection
2. Implement cache decorator
3. Add cache layer to GET /users/:id
4. Implement cache invalidation on updates
5. Add metrics tracking
6. Write tests (hit/miss scenarios)
7. Update API documentation

KIRO poi ESEGUE i task e produce il codice completo.

5. Anatomia di una Spec Perfetta

Template: Spec Checklist

# [Feature Name] - Specification

## 1. Requirements

### Functional Requirements
- [ ] Req 1: User story format
- [ ] Req 2: Acceptance criteria chiara
- [ ] Req 3: Edge cases identificati

### Non-Functional Requirements
- [ ] Performance target (latency, throughput)
- [ ] Security requirements
- [ ] Scalability expectations
- [ ] Compliance needs

### Constraints
- [ ] Budget limitations
- [ ] Technology stack obbligato
- [ ] Timeline
- [ ] Backward compatibility


## 2. Design

### System Architecture
[Diagram o descrizione testuale]

### Data Model
[Schema database/strutture dati]

### API Contracts
[Endpoints, request/response format]

### Dependencies
- External services
- Libraries/frameworks
- Infrastructure components

### Trade-offs & Decisions
- Decision 1: Scelta X perché Y (pro/contro)
- Decision 2: Alternativa Z scartata perché W

## 3. Tasks

### Implementation Steps
1. [ ] Task 1 (chiaro, atomico, verificabile)
2. [ ] Task 2 (dipendenze esplicite)
3. [ ] Task 3 (stima effort opzionale)

### Testing Strategy
- Unit tests
- Integration tests
- E2E tests

### Documentation
- Code comments
- API docs
- README updates

### Deployment Plan
- Migration steps
- Feature flag strategy
- Rollback plan

Caratteristiche di una Buona Spec

✅ SMART Requirements

Specific: "Latency < 200ms" non "deve essere veloce"
Measurable: metriche quantificabili
Achievable: realistica con risorse disponibili
Relevant: allineata agli obiettivi business
Time-bound: deadline chiara

✅ Design Completo ma Flessibile

Decisioni architetturali documentate
Alternative considerate e scartate con ragione
Spazio per adattamenti in implementazione

✅ Tasks Atomici

Ogni task completabile in < 2 ore
Dependencies esplicite
Checkpoint verificabili

Anti-Pattern da Evitare

❌ Spec troppo generica

# Bad
Requirements:
- L'API deve funzionare bene
- Il codice deve essere pulito
- Deve essere sicuro

✅ Spec specifica

# Good
Requirements:
- API response time: p95 < 200ms, p99 < 500ms
- Code coverage: > 80% (unit + integration)
- Security: OWASP Top 10 compliance verificata con scanner

❌ Design senza decisioni

# Bad
Design:
- Useremo un database
- Ci sarà un'API

✅ Design con rationale

# Good
Design:
- Database: PostgreSQL
  Rationale: Serve ACID per transazioni finanziarie
  Alternative: MongoDB (no ACID), DynamoDB (costo)
- API: GraphQL
  Rationale: Client diversi (web, mobile) con esigenze dati diverse
  Alternative: REST (troppo rigido), gRPC (no web direct)

6. Caso Reale: API REST in 10 Minuti

Scenario

Cliente: "Ci serve un'API per gestire le ricette culinarie"

Passo 1: Prompt a Kiro (2 min)

create a spec that builds a Recipe Management API with:
- CRUD operations for recipes
- Each recipe has: title, ingredients (list), steps (list), prep_time, cook_time, servings
- Search by ingredient or title
- Rate recipes (1-5 stars) with user reviews
- Favorite recipes per user
- Authentication required for write operations
- Swagger documentation
- Unit tests

Passo 2: Kiro Genera Spec (3 min)

Kiro produce:

15 Requirements dettagliati
Design con FastAPI + PostgreSQL + JWT auth
12 Tasks di implementazione

Passo 3: Review e Adjust (2 min)

Noti che manca:

"add rate limiting: 100 requests/minute per user"

Kiro aggiorna la spec.

Passo 4: Kiro Implementa (3 min)

Task 1/12: Setup project structure ✓
Task 2/12: Create data models ✓
Task 3/12: Implement CRUD endpoints ✓
Task 4/12: Add search functionality ✓
Task 5/12: Implement rating system ✓
Task 6/12: Add favorites ✓
Task 7/12: Setup JWT authentication ✓
Task 8/12: Add rate limiting ✓
Task 9/12: Generate OpenAPI spec ✓
Task 10/12: Write unit tests ✓
Task 11/12: Write integration tests ✓
Task 12/12: Update README ✓

All tasks completed.

Passo 5: Verifica (bonus)

# Tests run automaticamente
pytest
# 47 tests passed

# Avvia server
uvicorn main:app --reload

# Apri Swagger UI
open http://localhost:8000/docs

API funzionante in 10 minuti.

Risultato

Codice generato:

12 file Python
850+ righe di codice
47 unit + integration tests
Swagger UI completo
README con esempi

Manualmente (stima):

Tempo: 6-8 ore
Bug probabili: 5-8
Test coverage: ~60%
Documentation: minimale

Con Kiro + Spec:

Tempo: 10 minuti
Bug: 0 (testato automaticamente)
Test coverage: 85%
Documentation: completa

7. Spec-Driven vs Code-First: Confronto

Tabella Comparativa

Aspetto	Code-First (Cursor/Copilot)	Spec-Driven (Kiro)
Tempo iniziale	Veloce (inizi subito)	Lento (devi scrivere spec)
Tempo totale	Lungo (molti refactor)	Breve (codice corretto al primo colpo)
Chiarezza obiettivi	Nebulosa (scopri facendo)	Cristallina (spec è contratto)
Qualità codice	Variabile	Alta (best practices applicate)
Bug rate	Alto (edge case dimenticati)	Basso (pensati in spec)
Test coverage	Basso (~40-60%)	Alto (~80-90%)
Documentation	Minima (aggiunta dopo)	Completa (spec + auto-generated)
Team alignment	Difficile (code review lenta)	Facile (spec review veloce)
Refactoring needed	Frequente	Raro
Adatto per	Quick fixes, prototipi	Feature production, team work

Metriche Reali (Progetto AWS Certification Coach)

Scenario: Pipeline di elaborazione 200+ quiz certificazione

Approccio Code-First (stimato):

Planning mentale:        30 min
Coding:                  4 ore
Debug edge cases:        2 ore
Refactor per performance: 1.5 ore
Testing manuale:         1 ora
Documentation:           30 min
TOTALE:                  9.5 ore

Approccio Spec-Driven con Kiro (reale):

Scrivere spec:           15 min
Review spec:             10 min
Kiro implementation:     25 min
Verification:            10 min
TOTALE:                  60 min

Risparmio: 8.5 ore (89%)

Curva di Apprendimento

Code-First:
└─ Curva piatta (inizi subito, problemi dopo)

Spec-Driven:
└─ Curva ripida iniziale (devi imparare a scrivere spec)
   └─ Poi esponenziale (ogni spec ti rende più veloce)

Break-even point: ~3 progetti
Dopo: 3-5x più veloce di Code-First

8. Best Practices

Per Scrivere Spec Efficaci

1. Usa il Linguaggio del Dominio

❌ Bad:

Requirements:
- Funzione che prende input e fa processing

✅ Good:

Requirements:
- Order validation service che:
  * Riceve OrderRequest (user_id, items, payment_method)
  * Valida stock disponibilità per ogni item
  * Calcola totale con sconti applicabili
  * Ritorna OrderValidationResult (valid: bool, errors: list)

2. Quantifica Tutto

❌ Bad:

- L'API deve essere veloce
- Il codice deve essere sicuro

✅ Good:

- API response time: p95 < 200ms, p99 < 500ms
- Security: 
  * JWT authentication (HS256)
  * HTTPS only
  * Rate limiting: 100 req/min per user
  * Input validation against injection

3. Documenta le Decisioni

Ogni scelta importante deve avere:

Decisione presa
Alternatives considerate
Rationale (perché questa e non le altre)

## Design Decision: Database Choice

**Decision:** PostgreSQL

**Alternatives considered:**
1. MongoDB
   - Pro: Schema flessibile
   - Contro: No ACID per transazioni multi-documento
   - Scartato perché: Serve consistenza per ordini finanziari

2. DynamoDB
   - Pro: Serverless, auto-scaling
   - Contro: Query complesse difficili, costo prevedibilità
   - Scartato perché: Query analytics frequenti

**Rationale PostgreSQL:**
- ACID transactions necessarie
- Schema stabile e ben definito
- Query complesse per analytics
- Team già esperto

4. Spec è Iterativa

Non aspettarti di scrivere la spec perfetta al primo colpo.

Workflow iterativo:

1. Draft iniziale (80% completa)
2. Review con Kiro: "what edge cases am I missing?"
3. Kiro suggerisce miglioramenti
4. Aggiusti spec
5. Kiro implementa
6. Durante implementazione, se emergono problemi:
   → Aggiorna spec
   → Re-run affected tasks

5. Usa Esempi Concreti

❌ Bad:

- Input validation per email

✅ Good:

- Email validation:
  * Valid: user@example.com, user+tag@example.co.uk
  * Invalid: user@, @example.com, user@.com
  * Max length: 254 characters (RFC 5321)

Template Pronti all'Uso

Template: REST API Endpoint

# Spec: [Endpoint Name]

## Requirements
1. Endpoint: [METHOD] /path/:param
2. Authentication: [JWT/API Key/None]
3. Rate limiting: [X requests/timeframe]
4. Input:
   - Headers: [list]
   - Body: [schema]
5. Output:
   - Success: [status code + schema]
   - Errors: [status codes + messages]
6. Side effects: [DB changes, events, etc]
7. Performance: [latency target]

## Design
- Framework: [FastAPI/Flask/Express]
- Validation: [Pydantic/Joi/etc]
- Database: [queries needed]
- Cache: [if applicable]

## Tasks
1. Create route handler
2. Add input validation
3. Implement business logic
4. Add error handling
5. Write tests
6. Update OpenAPI spec

Template: Database Migration

# Spec: [Migration Name]

## Requirements
1. Schema changes:
   - Add table: [name + columns]
   - Modify table: [changes]
   - Add index: [table + columns]
2. Data migration:
   - Transform: [from → to]
   - Constraints: [must preserve X]
3. Rollback strategy: [how to undo]
4. Downtime: [zero/planned]

## Design
- Migration tool: [Alembic/Flyway/etc]
- Transaction boundary: [yes/no + why]
- Validation queries: [to verify success]

## Tasks
1. Write up migration script
2. Write down migration script
3. Test on dev data
4. Backup production data
5. Execute migration
6. Verify data integrity
7. Monitor performance

9. Quando NON Usare Spec-Driven

Spec-Driven NON è sempre la risposta

❌ Quando NON serve spec:

1. Quick Fix / Hotfix

Bug: "Lambda timeout dopo 2 ore di uptime"
Fix: Aumentare timeout da 30s a 60s

Non serve spec. Usa Vibe Session:
"increase Lambda timeout to 60s in template.yaml"

2. Esplorazione / Prototipo

"Voglio vedere SE è possibile fare X"

Non serve spec. Prova e basta:
"create a quick prototype that tries X"

3. Refactoring Localizzato

"Rename variabile confusa in questa funzione"

Non serve spec:
"rename variable userDat to userData in this function"

4. Configurazione Semplice

"Aggiungi env variable DATABASE_URL"

Non serve spec:
"add DATABASE_URL to .env.example and config.py"

✅ Quando SERVE spec:

1. Nuove Feature

Requisiti non banali
Multiple componenti coinvolti
Business logic complessa

2. Refactoring Importante

Cambia architettura
Impatta multiple parti sistema
Serve coordination team

3. API Pubbliche

Contratto con utenti esterni
Backward compatibility critica
Documentation essenziale

4. Progetti Team

Più developer coinvolti
Serve alignment su decisioni
Review prima del codice

Regola Pratica

Usa Spec-Driven quando:
- Tempo implementazione > 30 minuti
- Impatto oltre un singolo file
- Serve condivisione con team
- Qualità è più importante di velocità

Usa Code-First (Vibe) quando:
- Fix veloce < 10 minuti
- Scope chiarissimo
- Solo tu coinvolto
- Velocità è priorità assoluta

10. Conclusioni

Il Cambio di Paradigma

Prima degli AI coding assistant:

Scrivere spec era considerato overhead
"Agile" significava "zero documentation"
Code-first era pragmatico

Con AI agents come Kiro:

Spec è l'input che genera codice
"Agile" significa iterare sulla spec prima del codice
Spec-driven è più veloce di code-first

La Metafora dell'Architetto

Senza spec (Code-First):

Tu sei l'architetto CHE costruisce la casa.
Progetti mentalmente mentre posi i mattoni.
Se ti accorgi che la porta non ci sta, devi demolire e rifare.

Con spec (Spec-Driven):

Tu sei l'architetto CHE progetta la casa.
Kiro è il costruttore CHE la realizza.
Se la porta non ci sta nel progetto, la sposti sulla carta.
Poi Kiro costruisce giusto al primo colpo.

I Numeri Finali

Basato su 6 mesi di uso intensivo di Kiro in produzione:

Metrica	Miglioramento
Tempo sviluppo feature	-70%
Bug in produzione	-60%
Refactoring necessari	-80%
Test coverage medio	+50% (da 40% a 90%)
Time-to-market	-65%
Chiarezza codice	+90% (self-documenting)
Onboarding new dev	-75% (spec come doc)

La Nuova Skill da Imparare

Nel 2026, la skill più importante per un developer non è:

❌ Scrivere codice velocemente
❌ Conoscere 10 linguaggi
❌ Memorizzare API

Ma è:

✅ Pensare in modo strutturato
✅ Articolare requisiti chiaramente
✅ Anticipare edge cases
✅ Progettare prima di costruire

Queste skill sono amplificate da Spec-Driven Development con Kiro.

Da Dove Iniziare

Step 1: Primo Esperimento (oggi)

# Installa Kiro
# Crea progetto test

# Prova questo prompt:
create a spec that builds a simple TODO API with:
- CRUD operations
- SQLite database
- FastAPI
- Basic auth
- Tests

# Osserva cosa genera Kiro
# Compara con quanto ci avresti messo manualmente

Step 2: Primo Progetto Reale (questa settimana)

Prendi un task del tuo backlog:

Non banale (> 30 min stima)
Chiaro scope
Non mission-critical (per sperimentare)

Scrivi spec prima di codificare.
Usa template forniti sopra.
Fai review con Kiro: "what am I missing?"
Lascia Kiro implementare.

Step 3: Adotta nel Team (prossimo sprint)

Condividi risultati esperimento
Proponi spec-driven per prossima feature
Review spec insieme prima del codice
Misura tempo risparmiato

Step 4: Diventa Automatico (3 mesi)

Dopo 10-15 progetti con spec:

Scrivere spec diventa automatico
Vedi edge cases prima di codificare
Il tuo codice è più pulito
Sei 3-5x più veloce di prima

Risorse per Approfondire

Video:

YouTube: "Kiro: From Zero to Spec-Driven" (corso completo)
Modulo 2: "Spec-Driven Development Deep Dive"

Articoli:

"Kiro vs Cursor: Spec-Driven vs Code-First"
"Anatomia di una Spec Perfetta"
"10 Errori Comuni nelle Spec (e Come Evitarli)"

Template:

GitHub: kiro-demos-italia/templates/spec-templates/
Spec template per API REST, Database, Infrastructure

Community:

Discord Kiro: canale #spec-driven
AWS User Group Novara: monthly meetup con demo

🎯 TL;DR - Ricapitolando

Il Problema:
Gli AI coding tools ti fanno scrivere codice senza pensare → codice sbagliato veloce

La Soluzione:
Spec-Driven con Kiro ti obbliga a pensare prima → codice giusto ancora più veloce

Come Funziona:

Scrivi spec (Requirements + Design + Tasks)
Review spec (trova problemi sulla carta)
Kiro implementa (codice generato da spec)
Verifichi risultato (tutto testato e documentato)

Risultati:

Sviluppo: -70% tempo
Bug: -60%
Qualità: +90%

Quando Usare:

Feature nuove (sempre)
Refactoring importante (sempre)
Team projects (sempre)
Quick fix (no, usa Vibe)

Prossimo Step:
Prova oggi con un task reale. Usa template forniti. Misura la differenza.

💬 Feedback e Domande

Hai provato Spec-Driven con Kiro?

Condividi la tua esperienza:

LinkedIn: @lucadaddeo
Email: luca@augmentedtrainer.com
Discord: Kiro community #spec-driven

Vuoi approfondire?

Workshop "Spec-Driven Development in Practice" (3 ore hands-on)
Consulting 1:1 per adozione team
Custom template per il tuo dominio

📚 Appendice: Glossario

Spec (Specification):

Documento strutturato che descrive cosa costruire, come, e in quali step, prima di scrivere codice.

Requirements:

Sezione della spec che definisce COSA deve fare il software (funzionalità, vincoli, performance target).

Design:

Sezione della spec che definisce COME sarà implementato (architettura, decisioni tecniche, trade-offs).

Tasks:

Sezione della spec che definisce IN QUALI STEP sarà costruito (breakdown implementazione, dependencies).

Code-First:

Approccio dove inizi a scrivere codice immediatamente, senza pianificazione formale scritta.

Spec-Driven:

Approccio dove scrivi spec completa prima di qualsiasi implementazione.

Vibe Session (Kiro):

Modalità chat libera per quick tasks, debugging, refactoring localizzato.

Spec Session (Kiro):

Modalità strutturata dove Kiro genera e implementa da specifiche.

Autopilot Mode (Kiro):

Kiro lavora autonomamente senza chiedere conferme, tu verifichi alla fine.

Supervised Mode (Kiro):

Kiro chiede conferma prima di ogni modifica, controllo granulare.

Luca D'Addeo

AWS Champion Authorized Instructor

Leader AWS User Group Novara

16x AWS Certified, AWS Golden Jacket

"Pensa prima di costruire. Costruisci una volta sola."

Fine Documento

Versione 1.0 - Giugno 2026

Licenza: CC BY-SA 4.0

Come Kiro mi ha trasformato in un Augmented Trainer.

The Web Guru — Sun, 28 Jun 2026 04:56:05 +0000

Come sono passato da formatore sempre di corsa, stressato e con ansia da prestazioni ad "Augmented Trainer" usando Kiro.

Negli ultimi 5 anni ho erogato centinaia di corsi, in media 200 giornate di formazione all'anno, ho formato migliaia di professionisti e giovani talenti, per farlo spesso ho dovuto crearmi da sullo contenuti formativi custom di vario tipo, da usare in aula sia in italiano che in inglese.

Non sono e non mi sono mai venduto nel come Web Designer, Instructioanal Designer ne come Developer, ma diciamo che me la cavo in diverse tecnologie informatiche.

Conosco e so usare diversi tool di Authoring, Photo e Video Editing(Photoshop,Camtasia, Canvas, Adobe Photoshop, PowerPoint, WordPress etc); conosco ed insegno da anni i principi e i rudimenti della programmazione, bash shell scripting, SQL, HTML, JS, CSS, C, Python che uso per creare siti web, script per automatizzare task ripetitivi, preparazione ed analisi di dati, infrastruttura come codice, addestrare, tunare e deployare algoritmi di ML, LLM, Agenti AI, Lambda Function, REST API, HTTP API, etc e ho imaprato ad usare diversi tool di sviluppo,CLI, Librerie, Frameworks, IDE, Jupiter Notebook, e posso leggere e modificare, debuggare codice.

Da diversi mesi per farlo, uso principalmene Kiro, IDE Agentico, strumento indispensabile che apro per primo ogni mattina.

Come Formatore e consulente IT freelance, non uso Kiro solo per scrivere o migliorare codice e script, o applicazioni agentiche.

Lo uso anche e soprattutto per produrre contenuti formativi di qualità

Prima di ogni corso devo preparare: :

Slide
Immagini
Animazioni
Note del relatore
Copioni
Quiz
Audio
Demo
Use cases ed esempi
Template
Script
Pipeline
Diagrammi architetturali
Etc

Kiro mi ha trasformato in quello che chiamo un augmented trainer: un formatore che usa l'AI non per sostituire la mie competenze, ma per migliorare la qualità, interattività, engagemente, esperienza utente durante le mie lezioni.

Kiro: la mia Bicicletta AI agentica.

Una delle frasi che cito spesso nei miei lezioni è la frase attribuita a Steve Jobs che dice:

Computer work like "A Bicycle For The Mind"

— Ovvero uno strumento che amplifica e migliora le capacità mentali(intelligenza, produttività, efficacia, creatività, etc) dell'uomo, come la bicicletta amplifica quelle fisiche.

Infatti, una pedalata in bicicletta ti fa percorrere, con lo stesso sforzo di un passo, 5 metri invece che uno.

Questa metafora è valida ancora nel 2026, solo che la bicicletta, oltre ad essere fabbricata con leghe leggere, munita di pedalata assistita, motore elettrico, ha anche sensori, prompt, connessione al cloud, comandi vocali e pilota automatico.

Kiro è una Bicicletta AI agentica che ci porta molto più lontano dei normali IDE.

Non solo pedali meno ma pedali meglio.

Quando uno sviluppatore usa Kiro non smette di pedalare, né di dare la direzione è sempre lui a controllare il manubrio, le marce e i freni.

Kiro non sostituisce lo sviluppatore,lo amplifica. Non pensa al posto tuo. Ti porta più lontano con meno sforzo, e in una frazione del tempo.

La direzione la dai tu, al prompt, fornendo obbiettivi e specifiche chiari, Kiro fa il resto.

Ma la qualità del risultato finale, la durata del viaggio, quanto andrai lontano e veloce, dipende principalmente dalle tue competenze, dalla tua abilità di farti e porre le domande giuste.

Prima di kiro ero un trainer in burnut che lottava contro il tempo.

Oggi sono un trainer che orchestra agenti AI per generare contenuti alla velocità che il mio lavoro richiede.

Il "collo di bottiglia" Principale.

Ogni volta che dovevo insegnare un corso, il lavoro di preparazione che ci stava dietro, era enorme: Editare Immagini, scrivire testo, creare codice,file di configurazioen, credeniali, utenti, gruppi, ruoli, policy, template, script per le demo, note del relatore, per ogni slide (in media 500 sldie per corso), walking through e spiegazioni dei laboratori, diagrammi, whiteboarding, FAQ, casi d'uso, link, email di follow-up,assesment pre e post corso,survey, etc.

Per farlo ci mettevo giorni, perché dovevo creare:

Note del relatore in italiano da usare come traccia durante la lezione — una specie di "gobbo digitale"
Audio narrato generato con Amazon Polly per ripassare il copione mentre facevo altro (palestra, meditazione)
A volte, presentazioni con audio integrato che partiva automaticamente.
Spesso, immagini animate,video MP4

Fare tutto manualmentem usando Photoshop, camtasia, e altri tool era un incubo.

per generare trascrizioni dei video, note delle relatore di ogni slide, traduzioni, formattazione, generazione ed embedding delle note, tracce audio, transizioni, animazioni, effetti nel PPTX.

Servivano competenze e tool usati da Instructioanl Designer, Content Creator, Streamer e podcaser.

Prima di Kiro ci mettevo giorni o settimane. Adesso ci metto massimo un paio di ore.

Come Kiro ha cambiato il mio flusso

1. Spec-driven per la pipeline

Quando ho dovuto costruire la "pipeline" completa (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 extract information from the provided material(slides, videos, audio, txt, pdf,docs, md, eboo, trascripts, blog, etc), transcribes and translate then generates high quality speaker notes slide-by-slide in Italian.

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. Ho pedalato, il motore ha amplificato.

2. Sub-agent per i quiz

Per il mio certification coach, processo più di 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 orchestra la 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 in tempo reale

Quando m preparavo ad erogare corsi ufficiali AWS spesso sono previste demo articolate e complesse che richiedevano ora di lavoro, preparazione e test.

Adesso mi basta aprire Kiro e digitare:

create a spec that deploy a Serverless Agentic AI Assistant hosted on Amazon S3.

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 uso Cursor o Copilot?

Naturalmente li provato entrambi, e non solo.

Funzionano benissimo, ma per il coding puro.

Ma nel mio lavoro non basta sapere scrivere codice, serve anche content creation, orchestrazione, presentazione, validazione, interazione, checkpointing prblemsoliving, improvvisazione, etc.

Cursor è una bicicletta da corsa: velocissima in discesa, ma devi fare tutta la fatica tu. Non ha il concetto di spec. Non posso dirgli "prima pensa, poi progetta, poi implementa". Parte subito a pedalare.

Copilot è un ottimo cambio automatico: ti suggerisce la marcia giusta. Ma non ha il motore. Non gestisce sessioni lunghe con centinaia di file da processare senza perdere il contesto.

Kiro è l'AI-Bike:

Struttura (specs) — ti obbliga a scegliere la direzione prima di partire
Autonomia (autopilot) — il motore lavora mentre tu controlli la rotta
Contesto persistente (steering files) — si ricorda il percorso anche dopo una pausa
Hooks — il motore si attiva automaticamente quando serve

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

Numeri reali

Metrica	Prima (bici muscolare)	Con Kiro (AI-Bike)
Tempo per corso completo (copioni + audio)	2-3 settimane	1 giorno
Costo AWS per corso (~500 slide)	—	~15-25 $
Quiz processati in batch	manuale, uno a uno	200+ in una sessione
Demo setup time in aula	15 min	3 min

Cosa consiglio a chi vuole provare

Non partire dal codice. Parti da una spec. Scrivi create a spec that... e descrivi cosa vuoi ottenere. Kiro ragiona meglio quando gli dai una destinazione, non un'istruzione passo-passo.
Usa gli steering files. Metti in .kiro/steering/ un file che descrive il tuo progetto, il tuo stile, le tue convenzioni. È come programmare il navigatore della tua AI-Bike — sa dove vuoi andare.
Non trattarlo come ChatGPT. Non è una chat. È un agente. Dagli task, lascialo lavorare in autopilot, controlla il risultato. Se freni ogni 30 secondi, il motore non serve a nulla.
Prova con un task non-coding. Un template email, una pipeline di processing, un generatore di contenuti. Kiro brilla quando il problema è di orchestrazione. È lì che il motore fa la differenza.

Cos'è un Augmented Trainer

È un professionista che pedala con il motore acceso.

Un trainer tradizionale prepara il materiale, lo studia, lo presenta. Un augmented trainer orchestra: definisce gli obiettivi, guida agenti AI nella produzione, valida il risultato e consegna.

La competenza resta la stessa. La direzione la scegli tu. Il motore ti permette di:

Moltiplicare l'output — produrre in un giorno quello che prima richiedeva settimane
Raggiungere l'eccellenza — ogni spec ti costringe a chiarire cosa vuoi davvero, eliminando l'approssimazione
Articolare i pensieri — scrivere requirements ti obbliga a pensare prima di fare
Ragionare meglio — il design document ti mostra trade-off che da solo non avresti considerato
Prendere decisioni — avere alternative concrete davanti, con pro e contro, riduce la paralisi
Rimuovere l'incertezza — quando non sai se un approccio funziona, lo fai implementare in 5 minuti e verifichi, invece di rimuginare per ore

Non è un titolo ufficiale. È un modo di lavorare. Ed è alla portata di chiunque abbia competenza nel proprio dominio e la voglia di pedalare in una direzione chiara.

Conclusione

Non ho smesso di essere un trainer. Ho smesso di avere l'ansia da prestazione, di essere stressato e sovraccaricato.

Kiro mi ha potenziato dandomi struttura (specs), autonomia (autopilot) e orchestrazione (sub-agents). Il risultato non è contenuto generato dall'AI. È contenuto prodotto da me, amplificato dall'AI.

Steve Jobs aveva ragione: il computer è una bicicletta per la mente. Nel 2026, quella bicicletta percepisce, ragiona e agisce. Ha il pilota automatico.

E tu cosa aspetti? Procurati la tua AI-Bike agentica e inizia a pedalare.

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

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