SPARklE manages real users' energy data and provides guidance with direct financial impact. In this context human control isn't negotiable. But that doesn't mean giving up on AI: it means building the right foundations before delegating. The project started as a EU/PNRR-funded research initiative, with four companies involved and features explored freely. When WellD decided to turn it into a product, we found ourselves with a completely different backlog than expected, and an architecture that showed the marks of the research phase's pace. Two practices helped us rebuild solidity without slowing down development. First: a formal Architecture Decision Record system where developers and architects discuss a decision with AI, stress-test it with explicit alternatives and trade-offs, and submit it to adversarial review by the team before moving forward: decisions are more solid, shared, and traceable. Second: Spec-Driven Development, which forces us to refine requirements before writing code and which lets us delegate part of the development to dedicated agents, while keeping human supervision and quality verification on every step. This isn't a full multi-agent system yet. It's the infrastructure a multi-agent system needs to operate reliably in a domain where mistakes have a real cost. Key takeaways: In domains with sensitive data and financial impact, AI gets introduced by building control foundations, not bypassing them. ADRs with adversarial review make architectural decisions more solid and shared, with or without AI Spec-Driven Development is the practical prerequisite for delegating development to agents while keeping human oversight SPARklE manages real users' energy data and provides guidance with direct financial impact. In this context human control isn't negotiable. But that doesn't mean giving up on AI: it means building the right foundations before delegating. The project started as a EU/PNRR-funded research initiative, with four companies involved and features explored freely. When WellD decided to turn it into a product, we found ourselves with a completely different backlog than expected, and an architecture that showed the marks of the research phase's pace. Two practices helped us rebuild solidity without slowing down development. First: a formal Architecture Decision Record system where developers and architects discuss a decision with AI, stress-test it with explicit alternatives and trade-offs, and submit it to adversarial review by the team before moving forward: decisions are more solid, shared, and traceable. Second: Spec-Driven Development, which forces us to refine requirements before writing code and which lets us delegate part of the development to dedicated agents, while keeping human supervision and quality verification on every step. This isn't a full multi-agent system yet. It's the infrastructure a multi-agent system needs to operate reliably in a domain where mistakes have a real cost. Key takeaways: In domains with sensitive data and financial impact, AI gets introduced by building control foundations, not bypassing them. ADRs with adversarial review make architectural decisions more solid and shared, with or without AI Spec-Driven Development is the practical prerequisite for delegating development to agents while keeping human oversight Sat, 10 Oct 2026 00:00:00 -0400 https://speakerdeck.com/smirne/before-delegating-to-agents-adrs-and-spec-driven-development-as-the-foundation-for-ai-in-the-team https://speakerdeck.com/smirne/before-delegating-to-agents-adrs-and-spec-driven-development-as-the-foundation-for-ai-in-the-team Le reti elettriche europee stanno affrontando una crisi silenziosa: la domanda di energia cresce rapidamente, spinta dall'adozione di veicoli elettrici, pompe di calore ed elettrificazione industriale, mentre le fonti rinnovabili immettono energia in modi per cui la rete non è stata progettata. Il risultato è un sistema sotto pressione da entrambi i lati. Adeguare l'infrastruttura costerebbe miliardi. L'alternativa più intelligente è software che rende l'infrastruttura esistente più flessibile, ed è esattamente quello che fa SPARklE. SPARklE è una piattaforma cloud-native a microservizi (Java/Spring Boot per i servizi core, Python per algoritmi di forecasting e ottimizzazione) che gestisce Comunità Energetiche Rinnovabili (CER) e partecipa ai mercati della flessibilità energetica per conto dei Distribution System Operator. In questo talk partiremo dal problema di dominio che ha guidato le nostre scelte architetturali, per poi entrare nel dettaglio delle decisioni tecniche che hanno reso il sistema funzionante in produzione. Approfondiremo tre aree: - multitenancy: perché abbiamo scartato l'approccio con clausole WHERE e implementato PostgreSQL Row-Level Security con propagazione di variabili di sessione attraverso un connection pool — inclusi i problemi sottili che abbiamo incontrato lungo la strada. - dati time-series su larga scala: come le hypertable e le retention policy di TimescaleDB hanno gestito l'ingestione ad alta frequenza da smart meter e sistemi di accumulo su più comunità. - ottimizzazioni delle immagini docker dei microservizi SpringBoot: come ridurre dimensione e startup time con jdeps, jlink e AOT Cache - GitOps in un progetto che coinvolge più aziende: come FluxCD su Kubernetes ha portato ordine nei deployment quando il sistema integra moduli e componenti di proprietà di partner esterni. Un talk sui trade-off reali di un team piccolo che costruisce infrastruttura che impatta direttamente il flusso di energia rinnovabile nella rete. Include live demo. Video of presentation at JUG Milano - 2026/06/18 : https://www.youtube.com/watch?v=sNWVQHHGc6w&t=316s Le reti elettriche europee stanno affrontando una crisi silenziosa: la domanda di energia cresce rapidamente, spinta dall'adozione di veicoli elettrici, pompe di calore ed elettrificazione industriale, mentre le fonti rinnovabili immettono energia in modi per cui la rete non è stata progettata. Il risultato è un sistema sotto pressione da entrambi i lati. Adeguare l'infrastruttura costerebbe miliardi. L'alternativa più intelligente è software che rende l'infrastruttura esistente più flessibile, ed è esattamente quello che fa SPARklE. SPARklE è una piattaforma cloud-native a microservizi (Java/Spring Boot per i servizi core, Python per algoritmi di forecasting e ottimizzazione) che gestisce Comunità Energetiche Rinnovabili (CER) e partecipa ai mercati della flessibilità energetica per conto dei Distribution System Operator. In questo talk partiremo dal problema di dominio che ha guidato le nostre scelte architetturali, per poi entrare nel dettaglio delle decisioni tecniche che hanno reso il sistema funzionante in produzione. Approfondiremo tre aree: - multitenancy: perché abbiamo scartato l'approccio con clausole WHERE e implementato PostgreSQL Row-Level Security con propagazione di variabili di sessione attraverso un connection pool — inclusi i problemi sottili che abbiamo incontrato lungo la strada. - dati time-series su larga scala: come le hypertable e le retention policy di TimescaleDB hanno gestito l'ingestione ad alta frequenza da smart meter e sistemi di accumulo su più comunità. - ottimizzazioni delle immagini docker dei microservizi SpringBoot: come ridurre dimensione e startup time con jdeps, jlink e AOT Cache - GitOps in un progetto che coinvolge più aziende: come FluxCD su Kubernetes ha portato ordine nei deployment quando il sistema integra moduli e componenti di proprietà di partner esterni. Un talk sui trade-off reali di un team piccolo che costruisce infrastruttura che impatta direttamente il flusso di energia rinnovabile nella rete. Include live demo. Video of presentation at JUG Milano - 2026/06/18 : https://www.youtube.com/watch?v=sNWVQHHGc6w&t=316s Tue, 23 Jun 2026 00:00:00 -0400 https://speakerdeck.com/smirne/ita-scaling-smart-energy-building-a-cloud-native-platform-for-renewable-communities https://speakerdeck.com/smirne/ita-scaling-smart-energy-building-a-cloud-native-platform-for-renewable-communities Europe's electrical grids face a dual crisis: surging demand from EVs and heat pumps, combined with volatile renewable supply. Upgrading physical infrastructure would cost billions. The smarter alternative is software-driven flexibility, and that's where SPARklE comes in. SPARklE is a cloud-native microservice platform (Java/Spring Boot core, Python optimization algorithms) that manages Renewable Energy Communities (RECs) and participates in energy flexibility markets. This talk explores the domain challenges that shaped our architecture and the production engineering decisions behind them. We will dive into three core areas: Time-Series Data at Scale: TimescaleDB hypertables and retention policies for high-frequency IoT ingestion from smart meters. Hardened Multi-Tenancy: PostgreSQL Row-Level Security with session variable propagation through a connection pool (and some subtle edge cases we hit). GitOps via FluxCD: Kubernetes deployments in a multi-party project where components are owned by external partners. An honest look at production trade-offs made by a small team building software that impacts real-world grid stability. Includes a live demo. Target Audience: Java/backend developers, DevOps engineers, and architects working on data-intensive or multi-tenant systems. No prior energy domain knowledge required. Key Takeaways: Production-tested PostgreSQL RLS multi-tenancy; real TimescaleDB adoption patterns at IoT scale; GitOps strategies for multi-party projects. Europe's electrical grids face a dual crisis: surging demand from EVs and heat pumps, combined with volatile renewable supply. Upgrading physical infrastructure would cost billions. The smarter alternative is software-driven flexibility, and that's where SPARklE comes in. SPARklE is a cloud-native microservice platform (Java/Spring Boot core, Python optimization algorithms) that manages Renewable Energy Communities (RECs) and participates in energy flexibility markets. This talk explores the domain challenges that shaped our architecture and the production engineering decisions behind them. We will dive into three core areas: Time-Series Data at Scale: TimescaleDB hypertables and retention policies for high-frequency IoT ingestion from smart meters. Hardened Multi-Tenancy: PostgreSQL Row-Level Security with session variable propagation through a connection pool (and some subtle edge cases we hit). GitOps via FluxCD: Kubernetes deployments in a multi-party project where components are owned by external partners. An honest look at production trade-offs made by a small team building software that impacts real-world grid stability. Includes a live demo. Target Audience: Java/backend developers, DevOps engineers, and architects working on data-intensive or multi-tenant systems. No prior energy domain knowledge required. Key Takeaways: Production-tested PostgreSQL RLS multi-tenancy; real TimescaleDB adoption patterns at IoT scale; GitOps strategies for multi-party projects. Tue, 02 Jun 2026 00:00:00 -0400 https://speakerdeck.com/smirne/from-grid-saturation-to-gitops-engineering-a-renewable-energy-community-platform https://speakerdeck.com/smirne/from-grid-saturation-to-gitops-engineering-a-renewable-energy-community-platform Quickie Talk at Voxxed Days Ticino 2016 about repetition in Java code. Quickie Talk at Voxxed Days Ticino 2016 about repetition in Java code. Sat, 18 Apr 2015 00:00:00 -0400 https://speakerdeck.com/smirne/repetition-is-bad-repetition-is-bad https://speakerdeck.com/smirne/repetition-is-bad-repetition-is-bad