Ingegneria 80/20: Come Ho Ricostruito il Mio Sito in un Weekend

Lasciami svelarti un segreto: non ho riscritto il mio sito personale in un weekend perché fossi particolarmente veloce nel coding. L'ho fatto perché ho quasi del tutto evitato di scrivere codice.

Al contrario, ho passato la maggior parte del tempo a fare ciò che molti sviluppatori evitano come la peste — preparare. Documentare. Annotare ogni cosa. E quando finalmente ho aperto il mio editor e ho iniziato a lavorare con Codex di OpenAI, l'implementazione vera e propria è volata via come un trucco di magia ben rodato.

Questa è una storia su come fare l'80% del lavoro prima di scrivere una singola riga di codice e su come questo abbia cambiato tutto.

Perché Riscrivere il Sito?

Il mio sito girava su Qwik v3. Tecnologia solida, buone vibrazioni, ma volevo più flessibilità — specialmente nel routing. Ho fatto il passaggio a React Router in modalità framework. Una ricostruzione completa, non una semplice ristrutturazione. Nuova architettura, struttura dei file pulita, styling aggiornato (ciao Tailwind v4) e una base completamente bianca.

Ma ecco cosa mi ha sorpreso: la scrittura effettiva del codice ha richiesto circa 2–3 ore. Dall'inizio alla fine. E ha funzionato al primo tentativo.

Quindi, cosa è successo nelle altre 5 ore?

L'80%: Preparare Codex Come un Consulente Prepara un Pitch Deck

La maggior parte dello sforzo è andata nel costruire un "mega sistema di prompt" — non in un’interfaccia utente elegante, ma direttamente nella cartella del progetto. Ecco cosa ho fatto prima di chiedere a Codex di scrivere anche un solo componente:

• Ho scaricato tutta la documentazione di React Router e l'ho salvata in una directory /guides.

• Ho fatto lo stesso per Tailwind CSS v4, convertendo le pagine più rilevanti in Markdown usando Firecrawl.

• Ho scritto un file PROMPT.md contenente un overview del progetto:

  • "Il codice legacy risiede in /, il nuovo codice va in /app."
  • "Interfaccia utente ridotta al minimo, concentrati sulla logica di business."
  • "Usa Tailwind v4. Resta in modalità framework con React Router."
  • E così via.

Non era roba inutile. Era contesto operativo — il tipo di briefing dettagliato che daresti a un nuovo membro del team il primo giorno. Codex non stava indovinando cosa volevo. Aveva la documentazione nel repository. Aveva regole esatte in inglese semplice. Aveva vincoli.

Quando finalmente ho digitato:

"Leggi PROMPT.md. Prima, migra tutte le rotte nella nuova app."

Codex ha risposto come se avesse aspettato quell’incarico per tutta la vita.

Mega Prompt, Minime Allucinazioni

I risultati sono stati incredibili. Codex si è attenuto alle istruzioni. Non ha prodotto allucinazioni. Non ha tentato di inventare niente. Ha rispettato la direttiva "non concentrarti sulla UI". La logica server è stata migrata con precisione. La configurazione delle rotte sembrava scritta da me — se avessi avuto la pazienza di un compilatore.

Non si trattava solo di "prompt engineering". Si trattava di fondare Codex sulle specifiche reali e attuali. Non una lista vaga di compiti. Non una lista di funzionalità desiderate. Ma input strutturati, esempi chiari e accesso locale alla documentazione necessaria.

Cosa Ha Preso Tempo? Non il Codice

Una volta stabilite le fondamenta, il lavoro si è diviso in due fasi distinte:

1. Modalità Codex – esecuzione veloce, strutturata e ripetibile. Ha gestito migrazione, logica e perfino qualche impalcatura del layout con precisione quasi perfetta.
2. Modalità esplorazione design – lenta, manuale e senza limiti definiti. Questa era la parte umana: scegliere un look, provare layout, sperimentare con i componenti. Una volta ottenuto uno stile visivo funzionante, Codex è stato richiamato per propagare i pattern di design.

L’unico vero rallentamento è venuto dal fatto che io non sapevo bene come volevo che qualcosa apparisse — non come doveva funzionare.

La Vera Lezione: Codex è Buono Solo Quanto la Tua Preparazione

Questo weekend ha rinforzato un cambiamento che sto notando nel mio lavoro:

Scrivere codice sta diventando la parte facile. Pianificare è la parte difficile—e la più importante.

Per progetti di piccole e medie dimensioni, ora considero l’implementazione come un compito del 20%. L’80% è caricato in anticipo: raccogliere la documentazione, scrivere task incapsulati, costruire prompt contestuali.

Codex prospera con questo tipo di struttura. Se gli dai ambiguità, ti risponderà con ambiguità. Ma se costruisci l’ambiente con intenzione — documenti, vincoli, descrizioni chiare — si comporta come uno sviluppatore senior con memoria perfetta e senza ego.

Guardando Avanti: Tratta l’AI Come un Collega, Non Come una Lampada

Il messaggio è semplice: tratta i tuoi strumenti di codifica AI come collaboratori. Dagli gli stessi materiali che daresti a un vero ingegnere. Prepara il contesto. Sii specifico. Sii esaustivo.

La prossima volta, per un progetto più grande, andrò ancora oltre:

• Un documento master piano per definire l’intero ambito del progetto.
• Specifiche task individuali per sottomoduli o componenti.
• Un set funzionante di documenti markdown e file di esempio come base di riferimento locale.

Codex non ha bisogno di parole magiche — ha bisogno di struttura.

Vuoi costruire più velocemente? Inizia a non costruire. Pianifica prima. Poi prompta con intenzione.

L’Evoluzione del Design: Un Viaggio Visivo

Col tempo, il mio sito ha attraversato diverse trasformazioni — ciascuna riflettendo nuove idee, strumenti e lezioni apprese. Ecco un rapido tour visivo di come sono evolute le cose:

Versione 1: Il Punto di Partenza

Versione 2: Una Voce Più Definita

Versione 2.1: Ritocchi e Rifiniture

Versione 3: L’Era Qwik

Versione 4: Semplicità Focalizzata con Remix

Ogni versione ha portato nuove intuizioni su cosa rende efficace un sito — non solo nell’estetica, ma nella chiarezza, usabilità e manutenibilità. Il viaggio del design ha rispecchiato quello dello sviluppo: deliberato, iterativo e sempre proiettato al futuro.