Gitbar - Italian developer podcast

Brainrepo
  • 0,0 (0)
  • Hobiji
  • Svakog tjedna

Chiacchiere sincere tra quelli che una volta erano developer e oggi si chiedono se il codice lo stiamo ancora scrivendo noi o se siamo diventati i prompt-sitter di intelligenze artificiali capricciose. Le bestemmie, almeno quelle, restano artigianali e 100% umane.

  1. Ep.238 - Guidare agenti, guidare team. Come fare? Boh. con Alfonso Graziano (Nearform)

    23. lip

    Ep.238 - Guidare agenti, guidare team. Come fare? Boh. con Alfonso Graziano (Nearform)

    Di generazione di codice con l'AI si parla quasi sempre dalla prospettiva del singolo sviluppatore eroico, ma cosa succede quando entrano in gioco un intero team e un'organizzazione da centinaia di persone? In questo episodio con Alfonso Graziano (e l'incursione di Luca) ci infiliamo proprio nella zona meno raccontata: come introdurre lo Spec Driven Development partendo da zero, perché una spec ha livelli diversi per umani e macchine, e dove finisce la spec review e dove inizia la code review. Parliamo del nostro engineer che diventa un po' product, un po' QA e un po' risk manager, del meccanismo auto-apprendente che distilla pratiche dalla fase di planning, e di quella sensazione tossica e addictive di sentirsi supereroi mentre orchestriamo cinque agenti in parallelo fino al meltdown del cervello. Chiudiamo con l'esperienza di un upskilling obbligatorio su 400 persone, il ruolo del tech lead come bussola più che timone, e un balocco molto contro-corrente: spegnere il computer e andarsene in moto.

    2 h 1 min
  2. Ep.237 - Ohmyzsh e terminale con Carlo Sala Gaucho

    29. svi

    Ep.237 - Ohmyzsh e terminale con Carlo Sala Gaucho

    In questo episodio apriamo il cofano di uno strumento che quasi tutti abbiamo lanciato con un copia-incolla senza chiederci cosa ci fosse sotto: Oh My Zsh. Con Carlo, matematico di Barcellona e maintainer del progetto, parliamo di cosa significhi davvero portare avanti un progetto open source nato vent'anni fa nel tempo libero, della valanga di pull request generate dall'AI che sta travolgendo i maintainer, e di come si tiene in piedi un'architettura fatta di 350 plugin, temi e una libreria comune. Ci raccontiamo anche la seconda giovinezza del terminale: gli agent come Claude Code e Codex stanno riportando le persone sulla command line, e ci ricordiamo che a volte una pipe e due righe di bash valgono più di un'intera web app messa in piedi a colpi di token. In mezzo, una bella riflessione su università e matematica, e su quanto certe basi tornino utili quando meno te lo aspetti.

    1 h 13 min
  3. Ep.236 - Harness, consulenza e dintorni con Matteo Vaccari (Thoughworks)

    22. svi

    Ep.236 - Harness, consulenza e dintorni con Matteo Vaccari (Thoughworks)

    In questo episodio ci sediamo al bar con Matteo Vacari, Technical Principal in ThoughtWorks, per provare a smontare insieme l'hype intorno all'AI engineering e ragionare su come stia davvero cambiando il nostro mestiere. Parliamo di harness — feed forward, sensori di feedback deterministici e LLM as a judge — di perché l'inversione di dipendenza (l'AI come collega scomodo che ti critica, non come servo che obbedisce) sia la chiave per non spegnere il cervello, e di token driven development tra modelli di frontiera per pianificare e modellini deboli per eseguire. Ci infiliamo nel ginepraio dello spec driven development, del perché gli acceptance test contino più dei test unitari nell'era del codice generato, e della modularità che l'AI mette spietatamente a nudo. Chiudiamo guardando al futuro della consulenza, al rischio slop su scala industriale e a un ritorno inaspettato dell'Extreme Programming come bussola etica e organizzativa.

    1 h 7 min
  4. Ep.235 - Event Storming e context modeling nell'era ai con Alberto Brandolini (Avanscoperta)

    14. svi

    Ep.235 - Event Storming e context modeling nell'era ai con Alberto Brandolini (Avanscoperta)

    OspiteAlberto Brandolini (aka zio Brando), padre dell'Event Storming, autore della celebre Legge di Brandolini (principio di asimmetria delle stronzate) e una delle voci più autorevoli al mondo su Domain-Driven Design e modellazione di dominio. Di cosa parliamoIn questa puntata facciamo un viaggio in profondità nel mondo del domain modeling attraversando la Legge di Brandolini e la sua riedizione nell'era degli LLM, l'asimmetria fra aggiungere e togliere codice, il Phoenix Development, i bounded context, l'Event Storming nelle sue tre forme e il ruolo che l'AI può (e non può) giocare nella discovery del dominio. Una conversazione che mette al centro l'apprendimento come atto deliberato, l'importanza della politica nei progetti software e perché capire il dominio resta un'attività profondamente umana.

    1 h 14 min
  5. Ep.234 - Discovery, iniziare il lavoro da un cliente nuovo

    7. svi

    Ep.234 - Discovery, iniziare il lavoro da un cliente nuovo

    Mauro racconta come ha costruito EXO Skeleton, un sistema AI per gestire il carico cognitivo durante l'onboarding su nuovi clienti. Il problema di partenza è quello classico del consulente: entrare in un dominio sconosciuto, pieno di acronimi, decisioni non documentate e persone nuove, mentre il cliente ti valuta già dal giorno zero. Il concetto chiave è la distinzione tra esoscheletro (l'AI amplifica le tue capacità finché ne hai bisogno, poi la togli) ed endoscheletro (l'AI sostituisce il tuo giudizio, creando dipendenza). Il sistema è costruito su Claude Code + Crisp via MCP e ruota attorno a tre comandi giornalieri: standup la mattina per riconnettersi al contesto, teardown a fine giornata come brain dump strutturato, callprep prima di ogni meeting per prepararsi con domande mirate e coaching comunicativo ancorato ai meeting precedenti. Il processo doc genera in background quattro artefatti: FAQ con stato di risposta, glossario acronimi, task list e changelog. Il tutto alimenta un documento worldview che ricostruisce il dominio usando DDD, Event Storming e Continuous Discovery Habits di Teresa Torres. L'obiettivo finale: quando la discovery è matura, l'esoscheletro si toglie e la knowledge base diventa documentazione utile per chi entra dopo.

    54 min
  6. Ep.233 - LLM e refactoring, uno sgardo ai paper

    23. tra

    Ep.233 - LLM e refactoring, uno sgardo ai paper

    In questa puntata ci infiliamo fino al collo nel refactoring con gli LLM, partendo dall'ingenua tentazione di dire a Claude "migliora questo codice" e finendo a scoprire che la definizione di Fowler fa acqua da più parti. Ci rendiamo conto che "qualità del codice" è una coperta cortissima fatta di dieci attributi che spesso si pestano i piedi a vicenda, e che migliorarne uno può tranquillamente peggiorarne un altro. Giriamo intorno ai vari approcci di prompting — zero shot, two shot, rule based, step by step, objective based — per scoprire che le regole e gli step vincono quasi sempre, e ci tuffiamo nel paper Mantra che propone un sistema multi-agente dove la storia di Git diventa il miglior training set contestuale possibile. Chiudiamo con un'idea che ci frulla in testa: se lo human in the loop resta la chiave, perché non inchiodare il refactoring come hook alla fine di ogni azione di sviluppo, stile "implementa poi semplifica" delle skill di Osmani.

    58 min
  7. Ep.232 - Calvino e il refactoring 5 anni dopo - Regenerative Software

    16. tra

    Ep.232 - Calvino e il refactoring 5 anni dopo - Regenerative Software

    ContestoEpisodio nato last-minute. L'idea: riprendere un episodio di 5 anni fa e commentare cosa è cambiato da allora. Spoiler: è invecchiato male. Temi principaliDal muratore al guardiano. Nel 2020 si criticava la tendenza a concentrarsi sui dettagli implementativi (cappello del muratore) invece che sul sistema (cappello dell'ingegnere). Oggi il lavoro micro sta sparendo: servono nuovi cappelli, quello dell'addestratore (guidare l'LLM) e quello del guardiano (custodire l'intento). Code review insostenibili. Il codice generato dagli LLM è troppo per essere revisionato riga per riga. Il carico cognitivo non è più sostenibile. Lo "human in the loop" come lo conosciamo potrebbe sparire. Mauro cita Caveman, una skill che fa comunicare l'LLM come un cavernicolo: zero fronzoli, solo fatti. Test come nuova guardia. Luca ha cambiato approccio: prima di tutto scrive test. Se una coverage del 95% si ottiene in 12 minuti con tre prompt, concetti che davamo per assodati vanno ripensati. Qualità del codice ≠ qualità del software. Leggibilità e facilità di modifica erano i parametri per valutare il codice. Ma se un LLM può spiegare e modificare qualsiasi codice, quei parametri perdono rilevanza. La qualità del software (funziona, è efficiente, fa quello che deve) resta. Phoenix Architecture e codice disposable. Il concetto centrale: il codice non è più l'asset da proteggere, l'intento lo è. Scrivere codice costa quasi nulla, comprenderlo diventa costoso. Il codice diventa immutabile: invece di modificarlo, lo riscrivi da zero. Il developer passa da "curare un albero" a "guardiano della foresta". Tracciabilità causale. Manca il collegamento tra specifica → implementazione → evaluation. Mauro immagina un futuro dove passando su un blocco di codice si vede: da quale spec è nato, con quali test/eval è stato validato, cosa ha triggerato l'ultimo cambiamento. Potenziale idea startup: "end-to-end observability dell'agent-driven coding". Skill per il futuro. Capacità di adattamento, comprendere domini diversi, pensare da imprenditori. Mauro vede opportunità nel product management e nel ponte tra digitale e mondo fisico (meccatronica). Paese dei BalocchiCLI Anything (Luca): repository GitHub (31k stelle), collezione di CLI per interagire via AI con programmi come GIMP, LibreOffice, OBS, Zoom, DrawIO"L'Ultimo Programmatore" di Angelo Frascella (Luca): racconto sci-fi pre-2020 dove nessuno sa più leggere il codice tranne una persona"Regenerative Software" dal blog The Phoenix Architecture (Mauro): in un mondo dove generare è abbondante, la cosa più costosa è possedere codice che hai paura di cambiare

    1 h 24 min
  8. Ep.231 - Il cazziatone è servito: istruzioni per non esplodere

    10. tra

    Ep.231 - Il cazziatone è servito: istruzioni per non esplodere

    Hai mai aperto una mail alle 8 di mattina e sentito il sangue salire alla testa? In questo episodio smontiamo pezzo per pezzo un classico "cazziatone professionale" e lo trasformiamo in un'opportunità, usando le stesse tecniche che l'FBI usa per negoziare con i sequestratori. Spoiler: la prima cosa da fare è non fare niente. Di cosa parliamoIl caso studio: un messaggio aggressivo da un capo, un cliente o un collega. Tono duro, deadline imposta, zero domande. Il classico pugno nella casella di posta. La regola zero: non rispondere subito. Il silenzio dinamico applicato a sé stessi è la prima arma. Quando siamo arrabbiati, il cervello lavora al 30%. Non pensa soluzioni, pensa risposte. L'analisi da negoziatore: come leggere tra le righe di un messaggio aggressivo cercando tre indizi chiave: l'uso ossessivo del pronome "io" (segnale di insicurezza, non di potere)la deadline generica senza dettagli (spesso negoziabile)l'assenza totale di domande (modalità sfogo, non problem-solving)Il toolkit: le 6 tecniche1. Accusation Audit Anticipare tutte le accuse possibili prima che l'altro le faccia. "Probabilmente penserai che non abbiamo preso sul serio le tue indicazioni..." L'effetto? L'altro risponde "ma no, non esagerare" e inizia a moderarsi. 2. Labeling Dare un nome alle emozioni dell'altro con formule come "Sembra che...", "Ho la sensazione che...". Mai dire "io penso che": il focus deve restare sull'altro. Funziona anche al contrario: il mislabeling (etichettare di proposito l'emozione sbagliata) spinge l'altro a correggerti, rivelando il vero problema. 3. Mirroring Ripetere le ultime 1-3 parole chiave dell'altro con tono curioso, poi silenzio. La tecnica più semplice e più potente per far parlare le persone senza fare domande dirette. 4. Domande calibrate Domande che iniziano con "come" o "cosa", mai con "perché". Il "perché" accusa, il "cosa" esplora. La domanda killer per le deadline: "Cosa succede se non riusciamo a rispettarla?" Se la risposta è vaga, la deadline non era reale. 5. Parafrasi e Summary La parafrasi riformula con parole tue. Il summary aggiunge una label alla fine. L'obiettivo è far dire all'altro "è proprio così" (that's right), che è molto diverso da "hai ragione" (you're right, che spesso significa "smettila di parlare"). 6. Tono di voce (e di scrittura) Quattro toni: assertivo (da evitare sempre), DJ notturno (per calmare), sorridente e giocoso (da usare il 90% del tempo), analista (per i momenti chiave). Nella scrittura vale lo stesso principio: prima di premere invio, chiediti "con che tono sentiresti questa mail letta ad alta voce?"

    41 min
Pogledajte sve (238)

Opis

Chiacchiere sincere tra quelli che una volta erano developer e oggi si chiedono se il codice lo stiamo ancora scrivendo noi o se siamo diventati i prompt-sitter di intelligenze artificiali capricciose. Le bestemmie, almeno quelle, restano artigianali e 100% umane.

Informacije

Također bi vam se moglo svidjeti