Gitbar - Italian developer podcast

Brainrepo

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.232 - Calvino e il refactoring 5 anni dopo - Regenerative Software

    1일 전

    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시간 24분
  2. Ep.231 - Il cazziatone è servito: istruzioni per non esplodere

    4월 10일

    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분

소개

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.

좋아할 만한 다른 항목