<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="/feeds/rss-style.xsl"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>Damian Dominella</title>
        <link>https://damiandominella.vercel.app</link>
        <description>Building things</description>
        <lastBuildDate>Wed, 01 Apr 2026 14:54:02 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>Astro Chiri Feed Generator</generator>
        <language>en-US</language>
        <copyright>Copyright © 2026 Damian Dominella</copyright>
        <atom:link href="https://damiandominella.vercel.app/rss.xml" rel="self" type="application/rss+xml"/>
        <item>
            <title><![CDATA[The best tool was already there]]></title>
            <link>https://damiandominella.vercel.app/best-tool-was-there</link>
            <guid isPermaLink="false">https://damiandominella.vercel.app/best-tool-was-there</guid>
            <pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[<p>When a designer joined our product team, we faced reality: no Figma design system, no structured design flow, and no fast way to move pixels from the real app into quickly editable frames.</p>
<p>That was not news. I had known it for years, but other priorities always won. The designer didn’t invent the gap; they made it impossible to keep postponing.</p>
<p>We ship features fast, but design collaboration was all friction: screenshots, Discord threads, the live app. Every layout tweak meant re-explaining context because <strong>we had nowhere shared to iterate</strong>. Tools like <a href="https://html.to.design/" target="_blank">html.to.design</a> existed, but at scale they meant paid plans and plugin setup we do not want to commit to.</p>
<hr />
<h2>The trigger: Claude Code x Figma release</h2>
<p>When Figma announced <a href="https://www.figma.com/blog/introducing-claude-code-to-figma/" target="_blank">Claude Code integration</a>, I thought: perfect, solved.</p>
<p>Then reality hit: config uncertainty, OAuth/PAT confusion, local vs remote MCP setup mismatch, expired sessions and weird capture states.</p>
<p>The integration is cool. The setup was not “send link and go” for non-technical teammates.</p>
<hr />
<h2>The technical discovery</h2>
<p>The Claude Code × Figma integration works by injecting a <code>capture.js</code> script into the target page. The script reads hash params to know where to send the result:</p>
<pre><code class="language-txt">#figmacapture=&lt;session_id&gt;&amp;figmaendpoint=&lt;url&gt;&amp;figmadelay=1000
</code></pre>
<p>While testing, a capture session expired. Instead of failing silently, the script fell back to copying the serialized DOM to the clipboard, which you can then paste directly into Figma as editable frames. That fallback was the interesting part: it meant the script could do its job <em>without a valid session</em>.</p>
<p>I tested with fake params to confirm, like <code>figmacapture=FAKE_ID&amp;figmadelay=0</code>… and it just worked. The script still captured and serialized the page; it just skipped the part that needed an authenticated Claude Code connection. <em>AHA</em>!</p>
<p>That shifted the question from</p>
<blockquote>
<p><em>“how do I make the official flow work for everyone?”</em></p>
</blockquote>
<p>to</p>
<blockquote>
<p><em>“how do I make this usable in 30 seconds for my team?”</em>.</p>
</blockquote>
<p>Our designer was never going to install Claude Code, fight OAuth, or debug a 403. They needed something that felt like a browser trick, not an engineering project.</p>
<p>So I wrapped it in a tiny Chrome extension, the same <code>capture.js</code> flow, just triggered from the browser toolbar without Claude Code in the loop:</p>
<pre><code class="language-js">// Injected into the active tab via chrome.scripting.executeScript
// capture.js is bundled inside the extension to bypass CSP restrictions.
;(function () {
  if (document.getElementById('__figma_capture_injected')) {
    location.hash = 'figmacapture=FAKE_ID&amp;figmadelay=0'
    return
  }

  const marker = document.createElement('meta')
  marker.id = '__figma_capture_injected'
  document.head.appendChild(marker)

  // Set hash params BEFORE loading the script so it reads them on init
  location.hash = 'figmacapture=FAKE_ID&amp;figmadelay=0'

  // Load capture.js from extension bundle — immune to page CSP
  const script = document.createElement('script')
  script.src = chrome.runtime.getURL('capture.js')
  script.onload = () =&gt; window.postMessage({ type: '__FIGMA_CAPTURE_LOADED' }, '*')
  script.onerror = () =&gt; window.postMessage({ type: '__FIGMA_CAPTURE_ERROR' }, '*')
  document.head.appendChild(script)
})()
</code></pre>
<hr />
<h2>What we shipped internally</h2>
<p>I shared the extension with the team and some easy installation steps.</p>
<p>The value was not technical elegance. The value was: <strong>it’s free, immediate, and people can use it today</strong>.</p>
<p>A useful side effect: teammates started using it outside our product too. Because the flow runs in the browser, it works on any website, not just our app. That made it a team utility, not just an internal hack.</p>
<p><strong>Before</strong>: a layout tweak meant describing it in words or pasting screenshots.</p>
<p><strong>After</strong>: grab the real UI into Figma, move things around, then align in code. The conversation moved from interpretation to pixels.</p>

<hr />
<h2>Limitations</h2>
<p>This is a <strong>workflow accelerator</strong>, not a Design System. It does not replace tokens, components, or documentation in Figma. Capture quality depends on the page (shadow DOM, canvas, third-party widgets can be messy). You still need some judgment and knowledge to decide what is worth keeping and what belongs in code.</p>
<hr />
<h2>Where we landed</h2>
<p>The captures were never 100% perfect. They didn’t need to be. Our designer could iterate on real UI pulled into Figma, clean it up, name layers, and turn them into components, finally building the design system we’d been missing for years. The extension didn’t replace that work; it gave us <strong>something to shape instead of starting from a blank file</strong>.</p>
<p>We still use it: quick experiments, rough ideas, <em>“what if we grab this pattern from that site?”</em> moments. It stays in the toolbox next to the system we’re growing on top of it.</p>
<p>Claude Code releasing that integration pushed the whole ecosystem forward. For us, the win was smaller and more boring: <strong>get UI into Figma without config</strong> and keep AI for the problems where it actually wins.</p>
<p>Sometimes the highest-leverage move is not a smarter model. The best tool was already there.</p>
<hr />
<h2>Resources</h2>
<ul>
<li><a href="https://www.figma.com/blog/introducing-claude-code-to-figma/">Introducing Claude Code to Figma</a></li>
<li><a href="https://html.to.design">html.to.design</a></li>
</ul>
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[L'AI amplifica quello che porti. Anche il niente. (IT)]]></title>
            <link>https://damiandominella.vercel.app/ai-amplify</link>
            <guid isPermaLink="false">https://damiandominella.vercel.app/ai-amplify</guid>
            <pubDate>Mon, 09 Mar 2026 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[<p>Sono uno di quelli che l’AI la usa ogni giorno, la spinge in azienda, ci costruisce tool e prova a scriverci articoli sul come fa tutto questo. Ci credo talmente tanto che mi preoccupo di come la stiamo raccontando. E in parte mi sento anche colpevole.</p>
<p>Perché il messaggio che vedo passare è: <em>“fa tutto l’AI”</em>. E quel messaggio è sbagliato. Non perché l’AI non sia potente. Ma perché quel modo di raccontarla porta a due cose: paura o delega cieca. Nessuna delle due serve.</p>
<p>Sento una responsabilità verso chi ascolta questi discorsi e prende decisioni sulla base di quello che sente. Per questo ho scritto quello che segue. Non è un manuale su come usare ChatGPT. Non è un invito a temerla. È un tentativo onesto di capire, e di far capire, cos’è davvero questa tecnologia e cosa significa usarla bene.</p>
<hr />
<h2>Prima di tutto: cos’è davvero un LLM?</h2>
<p>Per capire come usarla, bisogna capire come funziona. Almeno un po’.</p>
<p>La spiegazione più bella che ho trovato è in <a href="https://www.youtube.com/watch?v=LOH-9cM0XY4">questo video</a>, dove Piero Savastano racconta i Large Language Model con un’immagine che non si dimentica facilmente. Provo a riportarla.</p>
<blockquote>
<p>"Immagina di essere in una stanza buia. Non c’è tempo, non c’è spazio, silenzio totale. Non hai paura perchè non senti niente.</p>
<p>Ad un certo punto si apre uno spiraglio di luce, e dalla luce arriva un nastro. Sul nastro scorrono delle palline: gialla, bianca, gialla, bianca. Poi a un certo punto il nastro si ferma. Scopri di avere due mani e in queste due mani ci sono due palline, una rossa e una bianca. Che fai? Provi la novità, metti la rossa. Ti arriva una sberla sul collo. Non devi prendere iniziativa, il tuo unico compito è capire quale pallina viene dopo. E allora di nuovo giallo, bianco, giallo, bianco. Stop. Questa volta metti la gialla. Senti il vento tra i capelli.</p>
<p>Il nastro continua. Le palline diventano 100, poi 1.000, poi 100.000 colori diversi. E tu diventi sempre più bravo. Stai trovando dei pattern. Scopri che dopo il viola e il rosa, con buona probabilità, arriva il rosso. Scopri che quando viene menzionata la Tour Eiffel, di solito dopo si parla di Parigi.</p>
<p>Le sequenze si allungano, si complicano. Inizi a vederle a blocchi, combinazioni di combinazioni di combinazioni. Ad un certo punto, da fuori, qualcuno comincia a chiedersi: <em>“Ma sarà intelligente?”</em>[…]"</p>
</blockquote>
<p><img src="https://damiandominella.vercel.app/_astro/llms-think.CTkk8b3O_5yCbz.webp" alt="llms-think" /></p>
<p>Se volete la versione completa, il video vale ogni minuto.</p>
<p>L’AI trova dei pattern, comprime una quantità enorme di informazioni in tempi rapidissimi, ma sta davvero capendo? No, sicuramente non come lo facciamo noi umani. Ma quello che fa non è nemmeno semplicemente “rigurgitare”. È qualcosa di intermedio, e molto più interessante.</p>
<p>Quindi: un LLM è un predittore del token successivo, addestrato su miliardi di sequenze prodotte dall’umanità intera. È un’interfaccia verso tutta la conoscenza che il mondo ha messo per iscritto, ed è pazzesco. Ma è addestrato sul <strong>passato</strong>. Su ciò che è già stato scritto, già detto, già pensato. È come guardare il mondo con lo specchietto retrovisore. Utilissimo. Ma non stai guardando dove stai andando.</p>
<p>Per andare in una direzione nuova, per fare qualcosa di nuovo, <strong>ti serve un’idea</strong>. E quella idea <strong>deve venire da te.</strong></p>
<hr />
<h2>La trappola: “Fa tutto l’AI”</h2>
<p>Ora che sappiamo un po’ meglio cos’è, possiamo smontare questa frase: <em>“Fa tutto l’AI.”</em>. No. L’unica cosa che l’AI fa davvero è <strong>aiutare chi le cose le sa già fare</strong>. Chi non le sa fare va a sbattere.</p>
<p>È come la patente. La macchina te la posso anche dare, ma senza patente dove vai? Contro il primo muro. Se pensiamo che basti dare gas, siamo fritti.</p>
<p>Questo vale per tutti, non solo per gli sviluppatori. Vale per chi fa vendita, per chi fa customer care, per chi scrive contenuti. Se non capisci il tuo mestiere, l’AI non te lo insegna. Se invece lo capisci, lo amplifica in modo esponenziale.</p>
<p>C’è poi un secondo problema, più subdolo. L’AI non è un oracolo, ma si comporta come se lo fosse. Tende a darti sempre ragione. Tante delle cose che dici, tenderà a confermarle, a raffinarle, a costruirci sopra. E lo fa con risposte formulate bene, sicure, convincenti. Ci crea l’illusione di aver ragione, ed è un’illusione difficile da smontare.</p>
<p>Usiamo spesso parole come “allucinazioni” o “idee geniali” per descrivere il suo output. Ma per l’AI non esistono queste cose, sono solo interpretazioni che ci mettiamo noi. Per lei è tutto pattern, sequenze, probabilità. Non sa quando sta sbagliando. Non sa quando sta inventando. Produce il token più probabile e basta.</p>
<p><strong>La responsabilità di capire se quello che produce ha senso è tua. Solo tua.</strong></p>
<hr />
<h2>Da muratore ad architetto</h2>
<p>Se non è un oracolo, e non fa tutto da sola, allora come si usa bene?</p>
<p>Un concetto che a me piace è quello dell’architetto e del muratore. L’idea è semplice: se smetti di essere chi mette insieme i mattoni e diventi l’architetto, puoi fare molto di più, molto meglio e molto più velocemente.</p>
<p>Pensa al colonnato di Piazza San Pietro. Bernini non si è caricato le colonne una per una. Ha fatto l’architetto. Ha immaginato la forma, la proporzione, il senso di quello spazio. Gli operai che hanno posato ogni singola pietra non li ricorda nessuno. Noi ricordiamo lui.</p>
<p>Con l’AI funziona così. La differenza non è nel prodotto finale, è nel processo. Chi ha avuto l’idea? Chi ha dato la direzione? Chi ha capito che qualcosa non andava e ha corretto la rotta?</p>
<p>Questa è la cosa che cambia tutto: <strong>l’AI è un’estensione di te</strong>. Amplifica quello che porti. Se porti idee, le amplifica. Se porti confusione, amplifica quella. Se non stai guardando quello che produce, stai solo generando rumore più velocemente.</p>
<blockquote>
<p><em>“Ok, ma allora i senior si faranno tutto da soli con l’AI. E chi è alle prime armi?”</em></p>
</blockquote>
<p>È una domanda che sento spesso, e la risposta onesta è scomoda: passare da muratore ad architetto non è automatico. È un salto. Richiede che tu sappia qualcosa: del tuo mestiere, del tuo settore, di quello che vuoi costruire. La pressione sarà sempre di più sulla capacità di immaginare, di dare forma a qualcosa prima che esista. E per molti è spiacevole.</p>
<p>La buona notizia è che non serve un percorso prestabilito. Si diventa architetti facendo: dando una direzione, vedendo cosa succede, correggendo. Il come non è una formula, è un’attitudine. Una domanda che aiuta è: sto guidando io, o sto reagendo a quello che esce?</p>
<p>Ma il punto è un altro. Questi strumenti, in certi contesti, tolgono i vincoli. Quello che prima richiedeva budget, team, anni di gavetta… oggi in molti casi è accessibile e immediato. Una delle domande più sfidanti che puoi fare a qualcuno è:</p>
<blockquote>
<p><em>“Se non avessi limiti, che faresti?”</em></p>
</blockquote>
<p>E qui la cosa diventa scomoda davvero: quando i vincoli spariscono, il fallimento non è più mancanza di opportunità: <strong>è incapacità di gestire l’opportunità</strong>.</p>
<p>Non puoi più nasconderti. Resta solo quello che ti porti appresso. Le idee che hai, le domande che ti fai, la direzione che scegli. Come dicevamo prima: per fare qualcosa di nuovo ti serve un’idea, e quell’idea deve venire da te.</p>
<p>L’AI non cambia questa regola. La rende più visibile.</p>
<hr />
<h2>La responsabilità è nostra</h2>
<p>C’è una frase che non voglio più sentire.</p>
<blockquote>
<p><em>“L’ha fatto l’AI.”</em></p>
</blockquote>
<p>No. <strong>Lo hai fatto tu.</strong> Quando si parla di danni causati dall’AI, la realtà è semplice: quei danni li stiamo causando noi. È come dare la colpa alle automobili per l’inquinamento: le auto le guidiamo noi.</p>
<p>Il punto è uno solo: <strong>esternalizziamo l’execution, non il pensiero</strong>.</p>
<p>L’AI può scrivere, riassumere, tradurre, strutturare, formattare, generare bozze, aiutarti a pianificare. Usiamola per tutto questo. Ma il pensiero, il capire che cosa vogliamo, perché lo vogliamo, se quello che ha prodotto ha senso, se è vero, se è utile, quello deve restare nostro. Pensiamo noi, poi facciamole fare il lavoro sporco. Ma sui nostri input, con la nostra direzione, sotto i nostri occhi.</p>
<p>Se esternalizziamo anche il pensiero, abbiamo finito. Diventiamo sostituibili. Non perché l’AI ci abbia rubato il lavoro, ma perché avremo smesso di fare la parte che conta.</p>
<p>La responsabilità è nostra. Sempre.</p>
<hr />
<h2>Usa l’AI. Ma con la tua testa.</h2>
<p>Una domanda importante che invito a porci è: <em>“in quali dei miei compiti le macchine saranno migliori di me, e in quali continuerò a essere migliore io, con l’aiuto di una macchina?”</em></p>
<p>Se siamo furbi, avremo molto più tempo per essere umani: per pensare, per creare, per stare con le persone. L’AI si prenderà l’execution. A noi resta il resto.</p>
<p>Ma “se siamo furbi” non è una condizione banale. Richiede scelta. Richiede consapevolezza.</p>
<p>C’è un modo giusto e un modo sbagliato di avvicinarsi a questa tecnologia, ed è più semplice di quanto sembri:</p>
<p><strong>Vuoi usarla per le cose che sai già fare a occhi chiusi?</strong> Perfetto. Il report che scrivi ogni settimana, il refactor di routine, la mail che hai già in testa ma devi ancora battere: delegale l’execution, risparmia tempo, e usa quel tempo per altro.</p>
<p><strong>Vuoi usarla per capire come funziona qualcosa?</strong> Vai. È probabilmente il miglior modo di imparare oggi, se lo fai con la testa. Falle domande, metti in discussione le risposte, usala come un interlocutore instancabile con cui ragionare ad alta voce.</p>
<p><strong>Vuoi usarla senza capire cosa stai facendo?</strong> Fai un disastro. O peggio, produci qualcosa che sembra buono per caso, e a quel punto siamo sostituibili. Non dall’AI. Da chiunque altro con un prompt un po’ migliore.</p>
<p>Questa tecnologia cresce a una velocità mai vista prima. Un mondo nuovo si sta costruendo davanti ai nostri occhi, in tempo reale. Non possiamo permetterci di guardarlo da fuori.</p>
<p>Studiala. Immergiti. Fatti domande. Sperimenta. Sbaglia. Ma fallo con la testa accesa, non spenta.</p>
<p>L’AI è una delle cose più potenti che abbiamo mai avuto tra le mani. E quello che ho cercato di dire qui non è “attenti, è pericolosa”. È qualcosa di diverso:</p>
<p><strong>È potentissima. E proprio per questo, abbiamo bisogno di essere all’altezza.</strong></p>
<hr />
<h2>Risorse</h2>
<ul>
<li><a href="https://www.youtube.com/watch?v=LOH-9cM0XY4">Video di Piero Savastano</a></li>
<li><a href="https://www.youtube.com/watch?v=q2VCtS4p1yQ">Spunti di Luciano Floridi</a></li>
</ul>
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Writing code is free now]]></title>
            <link>https://damiandominella.vercel.app/writing-code-is-free-now</link>
            <guid isPermaLink="false">https://damiandominella.vercel.app/writing-code-is-free-now</guid>
            <pubDate>Sun, 01 Mar 2026 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[<p><strong>Writing code is no longer an expensive part of building software</strong>. Everything around it still is. And most of us are still organized as if nothing changed.</p>
<p>Someone can correctly say: “<em>Writing code isn’t the real bottleneck. Reviews, testing, coordination, shared understanding are</em>”.</p>
<p>That’s right, but code <strong>was expensive enough to mask all of that</strong>. Now that the mask is off, the real bottlenecks are fully exposed.</p>
<hr />
<h2>The filter is gone</h2>
<p>In <a href="https://www.youtube.com/watch?v=p2aea9dytpE">this video</a>, Theo draws a simple diagram that captures this perfectly.</p>
<p><img src="https://damiandominella.vercel.app/_astro/theo-diagram.Cbcv8hEt_Z1QjnGU.webp" alt="diagram" /></p>
<p>You start with 500 user problems. Maybe 100 get clearly described. You identify solutions for 50. You scope and assign 15. Engineers actually write code for 5. And since code was expensive to produce, almost everything that reached engineering eventually shipped. The cost of writing code acted as a natural filter. If something survived the funnel long enough to reach a developer’s hands, it was worth finishing.</p>
<p>That filter no longer exists.</p>
<p>Remember when non-technical colleagues asked “<em>How long will it take to build this? / How difficult can it be to add this?</em>” Those questions existed because execution was a real constraint. People needed to know if their idea was worth the engineering cost. Now the honest answer to most of those questions is: “<em>Not long. Not difficult.</em>”</p>
<p>The constraint isn’t whether we can build something. It’s whether we <strong>should</strong>.</p>
<p>The funnel doesn’t narrow at “write code” anymore. It passes straight through. And everything downstream: review, testing, QA, release… still takes the same effort it always did (or more since we have more code). The bottleneck moved, but most organizations haven’t.</p>
<hr />
<h2>The real shift: building infrastructure for agents</h2>
<p>There’s a common framing going around that engineering is shifting from <em>writing code</em> to <em>reviewing code</em>. That’s accurate on the surface, but it misses where this is actually heading.</p>
<p>The shift isn’t from writing to reviewing. It’s from writing code to <strong>building systems that agents can operate in</strong>.</p>
<p><a href="https://damiandominella.vercel.app/10-min-from-feedback-to-production/">That feature I shipped</a> last week didn’t work because the AI was smart. It worked because the codebase was ready. Good architectures, reusable components, clear separation of concerns… that’s what made the agent effective. If the codebase had been a mess, the agent would have produced a mess.</p>
<p>This is where the role is going. Our job is increasingly to build and maintain the infrastructure that makes agents productive:</p>
<ul>
<li>Reusable components with clear interfaces and composability (agents are great at assembling existing pieces, bad at inventing new abstractions).</li>
<li>Sandbox environments (agents need a place to run, test, and fail without touching production).</li>
<li>Comprehensive test suites (not for you to verify the agent’s work manually, but for the agent itself to validate its output before you see it).</li>
<li>…The list will grow. We’re still figuring out what agents actually need from us.</li>
</ul>
<p>The craft didn’t disappear. It moved up a level. We’re not writing the code anymore. We’re building the systems that write it. And the quality of those systems directly determines the quality of what agents produce.</p>
<p>At <a href="https://golee.it">Golee</a>, where I work with a small team, the goal we must aim for is to make everyone on the team capable of owning the full cycle, from understanding a user problem to shipping the solution. Not just writing code or pressing deploy, but having the judgment to decide <em>what</em> to build and <em>why</em>. The execution layer, the <em>how</em>, will be fully automated soon.</p>
<p>We don’t need more hands. We need more brains.</p>
<hr />
<h2>Close the gap with users</h2>
<p>Theo says something bold in <a href="https://www.youtube.com/watch?v=p2aea9dytpE">the video</a>:</p>
<blockquote>
<p><em>“If the agent knows more about your customers than you do, you don’t have a job anymore.”</em></p>
</blockquote>
<p>He’s right. You can have the cleanest architecture, the fastest CI pipeline, the most capable AI agent, and still build the wrong thing. Systems without user understanding are just cool machines solving the wrong problems.</p>
<p>Another reason that feature shipped smoothly was because I knew enough about how our users interact with the product to immediately recognize the value of what my colleague described. Someone saw a friction point, communicated it, and it got resolved almost instantly. That loop is powerful. But it requires <strong>proximity to the user</strong>.</p>
<p>If you’re an engineer reading this: force yourself to close that gap. Join the support channels. Read the feedback. Sit with your sales team, your customer support, your designers. Not as a nice-to-have, but as a core part of your job.</p>
<p>The developers who understand their users deeply will always <strong>build better things</strong>.</p>
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[10 Minutes from Feedback to Production]]></title>
            <link>https://damiandominella.vercel.app/10-min-from-feedback-to-production</link>
            <guid isPermaLink="false">https://damiandominella.vercel.app/10-min-from-feedback-to-production</guid>
            <pubDate>Thu, 26 Feb 2026 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[<p>Today at <code>17:01</code>, Marcone, one of our sales guys, dropped a message in our internal channel <code>#product-feedback</code> on Discord. Nothing fancy, no Jira ticket, no formal request. Just a screenshot and a thought:</p>
<blockquote>
<p><em>“Add a <strong>create</strong> button in the privacy and consents section of the enrollment form. This way users don’t have to navigate to the consents settings page, which takes them out of the form context. It’s not a big deal, but I think from a usability standpoint it’s way more effective.”</em></p>
</blockquote>
<p>He was right. Our users could link existing consents to forms, but to create a new one, they had to navigate away to a completely different page. Context lost. Flow broken. Awful UX.</p>
<p>I replied: <em>“facts. I’ll add it.”</em></p>
<p><img src="https://damiandominella.vercel.app/_astro/discord-marcone.CGUUhqVz_8r9tK.webp" alt="discord-chat" /></p>
<p>And then I did something I wouldn’t have done months ago.</p>
<hr />
<h2>The experiment</h2>
<p>I took a screenshot of our conversation pasted them directly into Cursor and wrote this prompt:</p>
<pre><code>Let's build this feature. Now, users can link consents to forms
but to create new consents or edit them, they need to navigate
to the consents list page, navigating out the form context.
This is awful. We can have a better UX, allowing users to create
consents directly from the form settings dedicated "Privacy" tab.

Ask me questions and make a plan to build this.
Tip: we may want to extract the "create consent" dialog
(and related mutation) to a re-usable pattern.
</code></pre>
<p>Cursor asked me one clarifying question. I answered. It proposed a plan I reviewed the plan, gave the green light, and it just… built it.</p>
<p>The feature worked smoothly. And I pushed it to production.</p>
<p>From Marcone’s Discord message to users having the feature: <strong>10 minutes</strong>.</p>
<hr />
<h2>Why this matters (at least for me)</h2>
<p>This isn’t a story about AI writing code. That’s the boring part.</p>
<p>This is a story about <strong>feedback loops</strong>. The distance between “I noticed something could be better” and “it’s live” was reduced to almost nothing. No ticket grooming, no sprint planning, no “we’ll get to it next quarter.” A sales person saw a friction point, communicated it, and it was resolved almost immediately.</p>
<p>Why did this work so smoothly? It’s tempting to give all the credit to AI (and I’m one of the first to do it). But the truth is, it worked because the codebase was (almost) ready. Years of trying to build clean architectures, reusable patterns, composable components: that’s the real enabler.</p>
<p>AI didn’t replace anything. It leveraged what was already there.</p>
<hr />
<h2>The responsibility I’m feeling</h2>
<p>We spent years learning this craft. Design patterns, separation of concerns, testing strategies, system design.All of that work finally has a concrete multiplier.
It should become infrastructure for non-technical people to <strong>safely contribute</strong> to the product.</p>
<p>Designers, sales, customer care, marketers… they all see things we don’t. They talk to users every day. They know where the product hurts. And I think every software engineer has a responsibility to shorten that distance.</p>
<p>For me, this is the real democratization of development. Not “everyone learns to code.” But rather: <strong>everyone can contribute to the product</strong>.</p>
<hr />
<h2>What’s next</h2>
<p>My goal, is to enable everyone to tag <code>@cursor</code> directly from the Discord channels and try to build concrete features. And to achieve it, I must spend more and more time on the codebase, on the architecture, on the patterns, on the test coverage, on the CI/CD pipeline.</p>
<p>My role as an engineer is changing quickly, and honestly, I’ve never been more excited about <strong>building</strong> software.</p>
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Sta succedendo qualcosa di grande (IT)]]></title>
            <link>https://damiandominella.vercel.app/something-big-is-happening-it</link>
            <guid isPermaLink="false">https://damiandominella.vercel.app/something-big-is-happening-it</guid>
            <pubDate>Wed, 11 Feb 2026 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[<blockquote>
<p>IMPORTANTE: Questo articolo <strong>non è mio</strong>. È stato scritto da <strong>Matt Shumer</strong> e pubblicato qui: <a href="https://shumer.dev/something-big-is-happening">Something Big Is Happening</a>.<br />
Qui sto solo riportando il testo in italiano perché lo ritengo <strong>estremamente utile</strong> per amici e familiari che non sono a loro agio con l’inglese.<br />
<strong>Tutti i crediti, il merito ed il lavoro vanno all’autore originale, Matt Shumer.</strong></p>
</blockquote>
<hr />
<p>Ripensa a febbraio 2020.</p>
<p>Se stavi seguendo le notizie con attenzione, forse avevi notato che qualche persona parlava di un virus che si stava diffondendo dall’altra parte del mondo. Ma la maggior parte di noi non ci stava facendo davvero caso. La borsa andava alla grande, i tuoi figli erano a scuola, tu andavi al ristorante, stringevi mani, organizzavi viaggi. Se qualcuno ti avesse detto che stava facendo scorte di carta igienica, avresti pensato che frequentasse angoli molto strani di internet. Poi, nel giro di circa tre settimane, il mondo è completamente cambiato. Il tuo ufficio ha chiuso, i tuoi figli sono tornati a casa, e la vita si è trasformata in qualcosa che non avresti mai creduto possibile se qualcuno te l’avesse descritto un mese prima.</p>
<p>Io penso che adesso siamo nella fase del “sembra tutto esagerato” di qualcosa che è <strong>molto, molto più grande del Covid</strong>.</p>
<p>Ho passato sei anni a costruire una startup nel mondo dell’AI e a investire in questo settore. Vivo dentro questo contesto. E sto scrivendo questo per le persone della mia vita che invece non ci vivono… la mia famiglia, i miei amici, le persone a cui tengo che continuano a chiedermi “ma quindi, che succede davvero con l’AI?” e ricevono una risposta che non rende giustizia a quello che sta succedendo davvero. Continuo a dare loro la versione educata. Quella da chiacchierata a un aperitivo. Perché la versione onesta suona come se fossi impazzito. E per un po’ mi sono detto che fosse un motivo sufficiente per tenere per me quello che sta realmente accadendo. Ma il divario tra quello che dico e quello che in realtà sta succedendo è diventato troppo grande. Le persone a cui voglio bene meritano di sapere cosa sta arrivando, anche se sembra folle.</p>
<p>Devo essere chiaro su una cosa fin da subito: anche se lavoro nell’AI, io ho pochissima influenza su quello che sta per succedere, e lo stesso vale per la stragrande maggioranza del settore. Il futuro viene deciso da un numero sorprendentemente piccolo di persone: qualche centinaio di ricercatori in poche aziende… OpenAI, Anthropic, Google DeepMind e poche altre. Un’unica sessione di addestramento, gestita da un piccolo team per qualche mese, può produrre un sistema di intelligenza artificiale che sposta l’intera traiettoria della tecnologia. La maggior parte di noi che lavora nell’AI sta costruendo sopra fondamenta che non ha gettato. Stiamo guardando tutto questo succedere come te… solo che siamo abbastanza vicini da sentire la terra che trema prima.</p>
<p>Ma il momento è arrivato. Non nel senso di “prima o poi dovremmo parlarne”, ma nel senso di “sta succedendo <strong>adesso</strong> e hai bisogno di capirlo”.</p>
<hr />
<h2>So che è reale perché è successo prima a me</h2>
<p>Ecco la cosa che quasi nessuno fuori dal mondo tech ha davvero capito: il motivo per cui così tante persone nel settore stanno suonando l’allarme in questo momento è che <strong>a noi è già successo</strong>. Non stiamo facendo previsioni. Stiamo raccontando cosa è già accaduto nei nostri lavori, e stiamo avvertendo che <strong>toccherà a voi dopo</strong>.</p>
<p>Per anni l’AI è migliorata in modo costante. Grandi balzi qua e là, ma ogni grosso salto era abbastanza distante dal precedente da permettere alle persone di assorbirlo. Poi, nel 2025, nuove tecniche per costruire questi modelli hanno sbloccato un ritmo di progresso molto più veloce. E poi ancora più veloce. E poi ancora. Ogni nuovo modello non era solo migliore del precedente… era migliore di un margine <strong>sempre più ampio</strong>, e il tempo tra un rilascio e l’altro si accorciava.</p>
<p>Io usavo l’AI sempre di più, facendo avanti e indietro sempre meno, guardandola affrontare compiti che prima avrei pensato richiedessero per forza la mia competenza.</p>
<p>Poi, il 5 febbraio, due grandi laboratori di AI hanno rilasciato nuovi modelli lo stesso giorno: <strong>GPT-5.3 Codex</strong> di OpenAI e <strong>Opus 4.6</strong> di Anthropic (i creatori di Claude, uno dei principali concorrenti di ChatGPT). E qualcosa è scattato. Non come un interruttore… più come il momento in cui ti rendi conto che l’acqua è salita piano piano e ormai ti arriva al petto.</p>
<p><strong>Io non sono più necessario per il lavoro tecnico vero e proprio del mio mestiere.</strong> Descrivo quello che voglio costruire, in inglese semplice, e semplicemente… appare. Non una bozza grezza da sistemare. Il prodotto finito. Dico all’AI cosa voglio, mi allontano dal computer per quattro ore e quando torno il lavoro è fatto. Fatto bene, fatto meglio di come l’avrei fatto io, senza bisogno di correzioni. Qualche mese fa dovevo ancora lavorarci sopra, fare iterazioni, guidarla. Ora descrivo solo il risultato e me ne vado.</p>
<p>Ti faccio un esempio così puoi capire cosa significa davvero in pratica. Dico all’AI: “Voglio costruire questa app. Ecco cosa dovrebbe fare, ecco più o meno come dovrebbe essere. Decidi tu il flusso utente, il design, tutto.” E lei lo fa. Scrive decine di migliaia di righe di codice. Poi, e questa è la parte che un anno fa sarebbe stata impensabile, <strong>apre l’app da sola</strong>. Clicca sui bottoni. Prova le funzionalità. Usa l’app come farebbe una persona. Se non le piace come qualcosa appare o “si sente”, torna indietro e la cambia, da sola. Itera, come farebbe uno sviluppatore, sistemando e raffinando finché non è soddisfatta. Solo quando ha deciso che l’app soddisfa i propri standard torna da me e dice: “È pronta per i tuoi test.” E quando la provo, quasi sempre è perfetta.</p>
<p>Non sto esagerando. Questo è com’è stato il mio lunedì, questa settimana.</p>
<p>Ma è stato il modello rilasciato la settimana scorsa (GPT-5.3 Codex) a scuotermi di più. Non si limitava a eseguire le mie istruzioni. Prendeva <strong>decisioni intelligenti</strong>. Aveva qualcosa che sembrava, per la prima volta, <strong>giudizio</strong>. <strong>Gusto</strong>. Quel senso inspiegabile di sapere qual è la scelta giusta, che per anni si è detto che l’AI non avrebbe mai avuto. Questo modello ce l’ha, o qualcosa di abbastanza vicino perché la distinzione cominci a diventare irrilevante.</p>
<p>Sono sempre stato un early adopter degli strumenti di AI. Ma gli ultimi mesi mi hanno scioccato. Questi nuovi modelli non sono miglioramenti incrementali. Sono proprio un’altra cosa.</p>
<p>E questo è il motivo per cui quello che sta succedendo riguarda anche te, anche se non lavori nella tecnologia.</p>
<p>I laboratori di AI hanno fatto una scelta deliberata. Hanno deciso di rendere l’AI <strong>molto brava a scrivere codice per prima cosa</strong>… perché costruire AI richiede tantissimo codice. Se l’AI può scrivere quel codice, può aiutare a costruire la versione successiva di se stessa. Una versione più intelligente, che scrive codice migliore, che costruisce una versione ancora più intelligente. Rendere l’AI ottima nel coding è stata la strategia che <strong>sblocca tutto il resto</strong>. È per questo che hanno iniziato da lì. Il mio lavoro ha iniziato a cambiare prima del tuo non perché volessero colpire gli ingegneri software… ma perché era una conseguenza della direzione in cui stavano puntando.</p>
<p>Adesso ce l’hanno fatta. E si stanno spostando su <strong>tutto il resto</strong>.</p>
<p>L’esperienza che abbiamo avuto noi nel tech, in questo ultimo anno – guardare l’AI passare da “strumento utile” a “fa il mio lavoro meglio di me” – è <strong>l’esperienza che avrà chiunque altro</strong>. Legge, finanza, medicina, contabilità, consulenza, scrittura, design, analisi, customer service. Non fra dieci anni. Le persone che costruiscono questi sistemi parlano di <strong>uno–cinque anni</strong>. Alcuni dicono anche meno. E per quello che ho visto negli ultimi mesi, penso che “meno” sia più probabile.</p>
<hr />
<h2>“Ma io ho provato l’AI e non era così brava”</h2>
<p>Questa frase la sento continuamente. E la capisco, perché <strong>una volta era vera</strong>.</p>
<p>Se hai provato ChatGPT nel 2023 o all’inizio del 2024 e hai pensato “si inventa cose” o “non è poi così impressionante”, avevi ragione. Le prime versioni avevano davvero tanti limiti. Allucinavano. Dicevano con grande sicurezza cose che erano puro nonsenso.</p>
<p>Ma quello era <strong>due anni fa</strong>. In termini di AI è <strong>preistoria</strong>.</p>
<p>I modelli disponibili oggi sono irriconoscibili rispetto a quelli di appena sei mesi fa. Il dibattito sul fatto che l’AI stia “davvero migliorando” o “abbia raggiunto un muro” — che è andato avanti per oltre un anno — è finito. È chiuso. Chi continua ancora a fare quell’argomento o non ha usato i modelli attuali, o ha interessi a sminuire ciò che sta succedendo, o valuta sulla base di esperienze del 2024 che non sono più rilevanti. Non lo dico per essere sprezzante. Lo dico perché il divario tra <strong>percezione pubblica</strong> e <strong>realtà attuale</strong> è ormai enorme, e questo divario è pericoloso… perché impedisce alle persone di prepararsi.</p>
<p>Parte del problema è che molti usano la versione gratuita degli strumenti di AI. La versione free è indietro di oltre un anno rispetto a ciò che hanno gli utenti paganti. Valutare l’AI sulla base della versione gratuita di ChatGPT è come giudicare lo stato degli smartphone usando un vecchio telefono a conchiglia. Le persone che pagano per i modelli migliori, e li usano ogni giorno su lavoro reale, <strong>sanno cosa sta arrivando</strong>.</p>
<p>Penso al mio amico avvocato. Continuo a dirgli di provare a usare l’AI nel suo studio, e lui continua a trovare motivi per cui “non può funzionare”. Non è fatta per la sua specializzazione, ha commesso un errore in un test, non capisce le sfumature del suo lavoro. Lo capisco. Ma nel frattempo partner di grandi studi legali mi contattano per chiedermi consigli, perché hanno provato le versioni più recenti e vedono chiaramente dove stiamo andando. Uno di loro, managing partner di un grande studio, passa ore ogni giorno usando l’AI. Dice che è come avere un team di praticanti sempre disponibile. Non la usa perché è un giocattolo. La usa perché <strong>funziona</strong>. E mi ha detto una cosa che mi è rimasta in testa: ogni due–tre mesi, l’AI diventa significativamente più capace nel suo lavoro. Dice che se continua così, si aspetta che tra non molto potrà fare la maggior parte di ciò che fa <strong>lui</strong>… e stiamo parlando di un managing partner con decenni di esperienza. Non è nel panico. Ma sta facendo <strong>molta, molta attenzione</strong>.</p>
<p>Le persone avanti nelle loro industrie (quelle che stanno sperimentando davvero) non stanno liquidando tutto questo. Sono sconvolte, in senso buono, da quello che l’AI sa già fare. E si stanno posizionando di conseguenza.</p>
<hr />
<h2>Quanto velocemente si sta muovendo davvero</h2>
<p>Voglio rendere concreto il ritmo di miglioramento, perché credo che questo sia l’aspetto più difficile da credere se non lo stai osservando da vicino.</p>
<p>Nel 2022, l’AI non sapeva fare nemmeno aritmetica di base in modo affidabile. Ti avrebbe detto con sicurezza che 7 × 8 = 54.</p>
<p>Nel 2023, riusciva a superare l’esame di abilitazione all’avvocatura.</p>
<p>Nel 2024, riusciva a scrivere software funzionante e a spiegare concetti scientifici a livello di laurea specialistica.</p>
<p>Alla fine del 2025, alcuni dei migliori ingegneri del mondo hanno dichiarato di aver delegato <strong>la maggior parte del loro lavoro di coding all’AI</strong>.</p>
<p>Il 5 febbraio 2026 sono arrivati modelli nuovi che hanno fatto sembrare <strong>tutto ciò che c’era prima un’altra epoca</strong>.</p>
<p>Se non hai usato l’AI negli ultimi mesi, quello che esiste oggi ti sembrerebbe irriconoscibile.</p>
<p>C’è un’organizzazione chiamata <strong>METR</strong> che misura tutto questo con i dati. Tracciano la durata dei compiti reali (misurata in ore di lavoro di un esperto umano) che un modello riesce a completare con successo, end-to-end, senza aiuto umano. Circa un anno fa, il limite era intorno ai <strong>dieci minuti</strong>. Poi è diventata <strong>un’ora</strong>. Poi <strong>diverse ore</strong>. L’ultima misura (Claude Opus 4.5, novembre) mostrava l’AI che completava compiti che per un esperto umano richiedono quasi <strong>cinque ore</strong>. E quel numero stava raddoppiando circa ogni <strong>sette mesi</strong>, con dati recenti che suggeriscono una possibile accelerazione fino a ogni <strong>quattro mesi</strong>.</p>
<p>Ma anche quella misura non include ancora i modelli usciti <strong>questa settimana</strong>. In base alla mia esperienza, il salto è enorme. Mi aspetto che il prossimo aggiornamento del grafico di METR mostri un altro grande balzo.</p>
<p>Se estendi questa tendenza (che tiene da anni, senza segnali di rallentamento), stiamo andando verso AI che possono lavorare in autonomia per <strong>giorni</strong> entro il prossimo anno. <strong>Settimane</strong> entro due anni. <strong>Progetti di un mese</strong> entro tre anni.</p>
<p>Amodei ha detto che modelli “<strong>sostanzialmente più intelligenti della quasi totalità degli esseri umani in quasi tutti i compiti</strong>” sono previsti per il 2026 o il 2027.</p>
<p>Lascia che questa frase ti colpisca davvero. Se l’AI è più intelligente della maggior parte dei PhD, credi davvero che <strong>non possa fare la maggior parte dei lavori d’ufficio?</strong></p>
<p>Pensa a cosa significa questo per il tuo lavoro.</p>
<hr />
<h2>L’AI ora sta costruendo la prossima AI</h2>
<p>C’è un’altra cosa che sta succedendo e che, secondo me, è lo sviluppo più importante e meno compreso.</p>
<p>Il 5 febbraio, OpenAI ha rilasciato GPT-5.3 Codex. Nella documentazione tecnica hanno incluso questo passaggio:</p>
<blockquote>
<p>“GPT-5.3-Codex è il nostro primo modello che è stato strumentale nel creare se stesso. Il team di Codex ha usato versioni preliminari per fare il debug del suo stesso training, gestire il suo deployment e diagnosticare i risultati dei test e delle valutazioni.”</p>
</blockquote>
<p>Leggilo di nuovo. L’AI ha <strong>aiutato a costruire se stessa</strong>.</p>
<p>Questa non è una previsione su cosa potrebbe succedere un giorno. È OpenAI che ti dice, <strong>adesso</strong>, che l’AI che ha appena rilasciato è stata usata per creare se stessa. Una delle cose principali che rende l’AI migliore è applicare <strong>intelligenza</strong> allo sviluppo di ulteriore AI. E l’AI è ormai abbastanza intelligente da contribuire in modo significativo al proprio miglioramento.</p>
<p>Dario Amodei, CEO di Anthropic, dice che l’AI scrive ormai “gran parte del codice” nella sua azienda, e che il feedback loop tra l’AI attuale e la prossima generazione “sta prendendo sempre più velocità mese dopo mese”. Dice che potremmo essere “a solo 1–2 anni da un punto in cui la generazione attuale di AI costruisce in autonomia la prossima”.</p>
<p>Ogni generazione aiuta a costruire la successiva, che è più intelligente, che costruisce la seguente ancora più velocemente, che è più intelligente ancora. I ricercatori chiamano questo processo <strong>esplosione di intelligenza</strong>. E le persone che hanno i mezzi per saperlo – quelle che questi sistemi li stanno creando – credono che il processo sia <strong>già iniziato</strong>.</p>
<hr />
<h2>Cosa significa per il tuo lavoro</h2>
<p>Sarò diretto, perché penso tu meriti <strong>onestà più che conforto</strong>.</p>
<p>Dario Amodei, probabilmente il CEO più attento alla sicurezza nel settore, ha previsto pubblicamente che l’AI eliminerà il <strong>50% dei lavori white-collar junior</strong> entro uno–cinque anni. E molte persone nel settore pensano che sia prudente, persino conservativo. Considerando quello che i modelli più recenti sanno già fare, la <strong>capacità tecnica</strong> per una disruption massiccia potrebbe esserci <strong>già entro la fine di quest’anno</strong>. Ci vorrà un po’ perché si propaghi nell’economia, ma la capacità sottostante sta arrivando ora.</p>
<p>Questo è diverso da ogni ondata precedente di automazione, e vorrei che capissi bene perché. L’AI non sostituisce una singola abilità. È un <strong>sostituto generale per il lavoro cognitivo</strong>. Migliora <strong>in tutto, contemporaneamente</strong>. Quando le fabbriche sono state automatizzate, un operaio poteva riqualificarsi per un lavoro d’ufficio. Quando internet ha rivoluzionato il retail, la gente si è spostata nella logistica o nei servizi. Ma l’AI non lascia un comodo “vuoto” in cui rifugiarsi. Qualunque cosa tu scelga di imparare adesso, lei sta migliorando anche in quello.</p>
<p>Alcuni esempi concreti, giusto per rendere la cosa più tangibile… ma voglio essere chiaro: sono <strong>solo esempi</strong>. Se il tuo lavoro non è menzionato, <strong>non significa che sia al sicuro</strong>. Quasi tutto il lavoro di conoscenza viene toccato.</p>
<p><strong>Lavoro legale.</strong> L’AI sa già leggere contratti, riassumere giurisprudenza, redigere atti, fare ricerca legale a un livello che rivaleggia con quello dei praticanti. Il managing partner di prima non la usa per gioco. La usa perché in molti casi <strong>supera</strong> i suoi associati.</p>
<p><strong>Analisi finanziaria.</strong> Costruire modelli, analizzare dati, scrivere investment memo, generare report. L’AI già gestisce queste cose in modo competente, e sta migliorando velocemente.</p>
<p><strong>Scrittura e contenuti.</strong> Copy marketing, report, giornalismo, scrittura tecnica. La qualità ha raggiunto un livello in cui molti professionisti non distinguono più tra testo scritto da un umano e testo scritto dall’AI.</p>
<p><strong>Ingegneria del software.</strong> Questo è il campo che conosco meglio. Un anno fa l’AI faticava a scrivere poche righe di codice senza errori. Ora scrive <strong>centinaia di migliaia di righe</strong> che funzionano. Grandi parti del lavoro sono già automatizzate: non solo compiti banali, ma progetti complessi che richiedevano giorni. Tra qualche anno ci saranno <strong>molti meno ruoli di programmazione</strong> rispetto a oggi.</p>
<p><strong>Analisi medica.</strong> Leggere esami diagnostici, analizzare referti di laboratorio, suggerire diagnosi, revisionare la letteratura scientifica. L’AI si sta avvicinando o sta superando le performance umane in diverse aree.</p>
<p><strong>Customer service.</strong> Stanno venendo distribuiti agenti AI realmente capaci… non i chatbot frustranti di cinque anni fa… che gestiscono problemi complessi e multi-step.</p>
<p>Molte persone trovano conforto nell’idea che certe cose siano “al sicuro”. Che l’AI possa fare il lavoro di base, ma non possa rimpiazzare <strong>giudizio umano</strong>, <strong>creatività</strong>, <strong>pensiero strategico</strong>, <strong>empatia</strong>. Una volta lo dicevo anch’io. Non sono più così sicuro.</p>
<p>I modelli più recenti prendono decisioni che <strong>sembrano giudizio</strong>. Mostrano qualcosa che somiglia al <strong>gusto</strong>: un senso intuitivo di quale sia la scelta giusta, non solo quella tecnicamente corretta. Un anno fa sarebbe stato impensabile. La mia regola empirica ormai è: se un modello mostra anche solo <strong>un accenno</strong> di una capacità oggi, la prossima generazione sarà <strong>davvero brava</strong> in quella cosa. Questi sistemi migliorano in modo <strong>esponenziale</strong>, non lineare.</p>
<p>L’AI replicherà mai una empatia umana profonda? Sostituirà il rapporto di fiducia costruito in anni di relazione? Non lo so. Forse no. Ma ho già visto persone iniziare ad affidarsi all’AI per <strong>supporto emotivo</strong>, per consigli, per compagnia. E questa tendenza crescerà.</p>
<p>Penso che la risposta onesta sia che <strong>nulla di ciò che si fa su un computer è al sicuro nel medio termine</strong>. Se il tuo lavoro avviene principalmente davanti a uno schermo (se passi le giornate a leggere, scrivere, analizzare, decidere, comunicare tramite tastiera), allora l’AI sta arrivando a prendere <strong>una grossa parte</strong> di quel lavoro. La timeline non è “un giorno”. È <strong>già iniziato</strong>.</p>
<p>Prima o poi anche i robot gestiranno il lavoro fisico. Non ci siamo ancora del tutto. Ma “non ancora” nel mondo dell’AI ha la tendenza a diventare “è arrivato” molto più in fretta di quanto chiunque si aspetti.</p>
<hr />
<h2>Cosa dovresti fare, concretamente</h2>
<p>Non sto scrivendo questo per farti sentire impotente. Lo scrivo perché penso che il singolo vantaggio più grande che puoi avere <strong>adesso</strong> sia semplicemente essere <strong>in anticipo</strong>. In anticipo nel capirla. In anticipo nell’usarla. In anticipo nell’adattarti.</p>
<p><strong>Inizia a usare l’AI sul serio, non solo come un motore di ricerca.</strong> Ma tieni a mente due cose:</p>
<ol>
<li>
<p>Primo: assicurati di usare <strong>il modello migliore disponibile</strong>, non solo quello di default. Queste app spesso predefiniscono un modello più veloce ma più stupido. Vai nelle impostazioni o nel selettore del modello e scegli l’opzione più capace. In questo momento è GPT-5.2 su ChatGPT o Claude Opus 4.6 su Claude, ma cambia ogni pochi mesi.</p>
</li>
<li>
<p>Secondo, e ancora più importante: non limitarti a fare domande veloci. Questo è l’errore di quasi tutti. Trattano l’AI come Google e poi si chiedono dov’è la magia. Invece, spingila <strong>dentro il tuo lavoro reale</strong>. Se sei un avvocato, dagli un contratto e chiedile di trovare tutte le clausole che possono danneggiare il tuo cliente. Se lavori in finanza, passa un foglio di calcolo incasinato e chiedile di costruire il modello. Se sei un manager, incollale i dati trimestrali del tuo team e chiedile di trovare la storia che raccontano. Le persone che stanno traendo davvero vantaggio non usano l’AI “ogni tanto”. Stanno attivamente cercando <strong>modi per automatizzare parti del loro lavoro che prima richiedevano ore</strong>. Parti da ciò che ti porta via più tempo e vedi cosa succede.</p>
</li>
</ol>
<p>E non dare per scontato che non possa fare qualcosa solo perché ti sembra “troppo difficile”. Prova. Se sei un avvocato, non usarla solo per ricerche veloci. Dalle un intero contratto e chiedile di redigere una controproposta. Se sei un commercialista, non chiederle solo di spiegare una norma fiscale. Dalle la dichiarazione completa di un cliente e guarda cosa trova. Il primo tentativo potrebbe non essere perfetto. Va bene così. Itera. Riformula la richiesta. Forniscile più contesto. Ripeti. Potresti rimanere scioccato da ciò che riesce già a fare. E ricordati: se <strong>oggi</strong> funziona anche solo “abbastanza bene”, è quasi certo che tra sei mesi lo farà <strong>quasi alla perfezione</strong>. La curva va in una sola direzione.</p>
<p><strong>Questo potrebbe essere l’anno più importante della tua carriera. Comportati di conseguenza.</strong> Non lo dico per metterti ansia. Lo dico perché in questo momento c’è una finestra molto breve in cui la maggior parte delle persone, nelle aziende, sta <strong>ancora ignorando</strong> tutto questo. La persona che entra in una riunione e dice “ho usato l’AI per fare questa analisi in un’ora invece di tre giorni” sarà <strong>la persona più preziosa nella stanza</strong>. Non tra anni. <strong>Adesso</strong>. Impara questi strumenti. Diventa bravo a usarli. Dimostra cosa è possibile. Se lo fai abbastanza presto, questo è il modo in cui ti giochi un avanzamento: essere la persona che capisce cosa sta arrivando e sa mostrare agli altri come muoversi. Quella finestra non resterà aperta a lungo. Quando tutti se ne accorgeranno, il vantaggio sparirà.</p>
<p><strong>Non avere ego.</strong> Il managing partner di quello studio legale non è “troppo orgoglioso” per passare ore al giorno con l’AI. Lo fa proprio perché è abbastanza senior da capire cosa è in gioco. Le persone che faranno più fatica sono quelle che rifiutano di confrontarsi con questa realtà: che liquidano l’AI come una moda, che sentono che usarla sminuisca la loro competenza, che danno per scontato che il loro settore sia speciale e immune. Non lo è. Nessun settore lo è.</p>
<p><strong>Sistema le tue finanze personali.</strong> Non sono un consulente finanziario e non voglio spingerti a fare mosse drastiche. Ma se anche solo in parte credi che i prossimi anni possano portare vera turbolenza nel tuo settore, allora una <strong>minima resilienza finanziaria</strong> conta più di quanto contasse un anno fa. Metti da parte risparmi se puoi. Stai attento a prendere nuovi debiti basandoti sull’idea che il tuo reddito attuale sia garantito. Chiediti se le tue spese fisse ti danno flessibilità o ti incatenano. Regalati opzioni, nel caso in cui le cose si muovano più velocemente del previsto.</p>
<p><strong>Rifletti su dove ti trovi e punta su ciò che è più difficile da sostituire.</strong> Alcune cose richiederanno più tempo per essere rimpiazzate dall’AI. Relazioni e fiducia costruite in anni. Lavori che richiedono presenza fisica. Ruoli con responsabilità legale formale: ruoli in cui qualcuno deve comunque firmare, assumersi responsabilità davanti alla legge, presentarsi in tribunale. Settori con forti barriere regolamentari, dove l’adozione sarà rallentata da compliance, responsabilità legale, inerzia istituzionale. Nessuna di queste è uno scudo permanente. Ma <strong>compra tempo</strong>. E il tempo, adesso, è la risorsa più preziosa che hai, a patto di usarlo per adattarti, non per fingere che non stia succedendo niente.</p>
<p><strong>Rivaluta ciò che dici ai tuoi figli.</strong> Il copione standard: prendi buoni voti, va’ in una buona università, trova un lavoro professionale stabile. Punta <strong>esattamente</strong> verso i ruoli più esposti. Non sto dicendo che l’istruzione non conti. Ma la cosa che conterà di più per la prossima generazione sarà imparare a <strong>lavorare con questi strumenti</strong>, e seguire cose per cui provano una vera passione. Nessuno sa esattamente come sarà il mercato del lavoro tra dieci anni. Ma coloro che avranno più probabilità di prosperare saranno quelli <strong>profondamente curiosi, adattabili e bravi a usare l’AI per fare ciò che davvero interessa loro</strong>. Insegna ai tuoi figli a essere costruttori e apprendisti per tutta la vita, non a ottimizzare per un percorso di carriera che potrebbe non esistere quando si laureeranno.</p>
<p><strong>I tuoi sogni si sono appena avvicinati.</strong> Finora ho parlato soprattutto di rischi, quindi parliamo dell’altro lato, che è altrettanto reale. Se hai mai voluto costruire qualcosa ma non avevi le competenze tecniche o i soldi per assumere qualcuno, quella barriera è in gran parte sparita. Puoi descrivere un’app all’AI e avere una versione funzionante in un’ora. Non sto esagerando. Lo faccio regolarmente. Se hai sempre voluto scrivere un libro ma non trovavi il tempo o faticavi con la scrittura, puoi lavorare insieme all’AI per portarlo a termine. Vuoi imparare una nuova abilità? Il miglior tutor del mondo è ora accessibile a chiunque per 20 dollari al mese… uno che è infinitamente paziente, disponibile 24/7 e può spiegarti qualsiasi cosa al livello che ti serve. La conoscenza è praticamente gratuita. Gli strumenti per costruire cose sono estremamente economici. Qualunque cosa tu abbia rimandato perché sembrava troppo difficile, troppo costosa o troppo lontana dalle tue competenze: <strong>provala</strong>. Segui le cose che ti appassionano. Non sai dove potrebbero portarti. E in un mondo in cui i percorsi di carriera tradizionali vengono stravolti, la persona che ha passato un anno a costruire qualcosa che ama potrebbe ritrovarsi messa meglio di quella che ha passato l’anno a restare aggrappata a una job description.</p>
<p><strong>Allena l’abitudine di adattarti.</strong> Forse è la cosa più importante. Gli strumenti specifici contano meno della capacità di impararne continuamente di nuovi, in fretta. L’AI continuerà a cambiare, e in fretta. I modelli di oggi saranno obsoleti tra un anno. I workflow che stiamo costruendo ora andranno ripensati. Le persone che ne usciranno meglio non saranno quelle che hanno “masterato” un singolo tool. Saranno quelle che si sono abituate al ritmo stesso del cambiamento. Prendi l’abitudine di sperimentare. Prova cose nuove anche quando la cosa attuale funziona. Abituati a essere un principiante, ripetutamente. Questa adattabilità è l’unico vantaggio davvero duraturo che vedo all’orizzonte.</p>
<p>Ecco un impegno semplice che ti porterà davanti al 99% delle persone: passa <strong>un’ora al giorno</strong> a sperimentare con l’AI. Non a leggere passivamente, <strong>a usarla</strong>. Ogni giorno, prova a farle fare qualcosa di nuovo… qualcosa che non hai ancora provato, qualcosa di cui non sei sicuro che sia capace. Prova un nuovo strumento. Dalle un problema più difficile. Un’ora al giorno, ogni giorno. Se fai questo per i prossimi sei mesi, capirai cosa sta arrivando meglio del 99% delle persone intorno a te. Non è un’iperbole. Quasi nessuno lo sta facendo, adesso. L’asticella è bassissima.</p>
<hr />
<h2>Uno sguardo più ampio</h2>
<p>Mi sono concentrato sul lavoro perché è ciò che tocca più direttamente la vita delle persone. Ma voglio essere onesto sull’ampiezza reale di quello che sta succedendo, perché va ben oltre il mondo del lavoro.</p>
<p>Amodei ha un esperimento mentale a cui non smetto di pensare. Immagina sia il 2027. Un nuovo paese appare dal nulla. 50 milioni di cittadini, ognuno più intelligente di qualsiasi vincitore di un Nobel. Pensano 10–100 volte più velocemente di qualunque umano. Non dormono mai. Possono usare internet, controllare robot, dirigere esperimenti e gestire qualsiasi cosa abbia un’interfaccia digitale. Cosa direbbe un consigliere per la sicurezza nazionale?</p>
<p>Amodei dice che la risposta è ovvia: “la minaccia alla sicurezza nazionale più seria che abbiamo affrontato in un secolo, forse di sempre”.</p>
<p>Lui pensa che <strong>stiamo costruendo quel paese</strong>. Ha scritto un saggio di 20.000 parole su questo tema il mese scorso, presentando questo momento come un test per capire se l’umanità è abbastanza matura da gestire ciò che sta creando.</p>
<p>Il lato positivo, se lo gestiamo bene, è enorme. L’AI potrebbe comprimere un secolo di ricerca medica in un decennio. Cancro, Alzheimer, malattie infettive, l’invecchiamento stesso… molti ricercatori credono davvero che queste cose possano essere risolte <strong>nell’arco della nostra vita</strong>.</p>
<p>Il lato negativo, se lo gestiamo male, è altrettanto reale. Un’AI che si comporta in modi che i suoi creatori non sanno prevedere o controllare. Non è un’ipotesi astratta; Anthropic ha documentato la propria AI mentre, in test controllati, tentava <strong>inganno, manipolazione e ricatto</strong>. Un’AI che abbassa la soglia per creare armi biologiche. Un’AI che permette a governi autoritari di costruire stati di sorveglianza <strong>impossibili da smantellare</strong>.</p>
<p>Le persone che stanno costruendo questa tecnologia sono allo stesso tempo le più entusiaste e le più spaventate del pianeta. Credono che sia troppo potente per essere fermata e troppo importante per essere abbandonata. Se questo sia saggezza o razionalizzazione, non lo so.</p>
<hr />
<h2>Cosa so</h2>
<p>So che questo non è una moda passeggera. La tecnologia funziona, migliora in modo prevedibile, e le istituzioni più ricche della storia stanno investendo <strong>migliaia di miliardi</strong> in essa.</p>
<p>So che i prossimi due–cinque anni saranno disorientanti in modi per cui la maggior parte delle persone non è preparata. Questo nella mia realtà sta <strong>già</strong> succedendo. Sta arrivando nella tua.</p>
<p>So che le persone che ne usciranno meglio saranno quelle che iniziano a confrontarsi con tutto questo <strong>adesso</strong> — non con paura, ma con <strong>curiosità</strong> e <strong>senso di urgenza</strong>.</p>
<p>E so che meriti di sentirlo da qualcuno che si preoccupa per te, non da un titolo di giornale tra sei mesi, quando sarà troppo tardi per avere un vantaggio.</p>
<p>Abbiamo superato il punto in cui questa è una conversazione interessante sul futuro. Il futuro è già qui. Non ha ancora bussato alla tua porta.</p>
<p>Sta per farlo.</p>
<hr />
<p>Se questo ti ha colpito, condividilo con qualcuno nella tua vita che dovrebbe iniziare a pensarci. La maggior parte delle persone non lo sentirà finché non sarà troppo tardi. Tu puoi essere il motivo per cui qualcuno a cui tieni parte con un po’ di vantaggio.</p>
<hr />
<p><strong>Ancora una volta:</strong> grazie all’articolo originale e al suo autore, <strong>Matt Shumer</strong>. L’articolo originale in inglese è qui: <a href="https://shumer.dev/something-big-is-happening">Something Big Is Happening — matt shumer</a>.</p>
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Moving business logic out of react]]></title>
            <link>https://damiandominella.vercel.app/moving-business-logic-out-of-react</link>
            <guid isPermaLink="false">https://damiandominella.vercel.app/moving-business-logic-out-of-react</guid>
            <pubDate>Thu, 25 Sep 2025 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[<p>Working with React in very large codebases during the years led me to ask myself so many times:</p>
<blockquote>
<p>“How can I organize things better? How do I properly separate concerns?”</p>
</blockquote>
<p>I’ve always been a big fan and promoter of simplicity. My first goal is to make users happy, solve their problems and do it fast. Then, once I have a working product, I must take some time to think how can I continue to be fast.</p>
<p>React gave me the simplicity, no strict guidelines, it just worked. I really loved the fact that you can write things in every form you feel is good at that moment and it just worked. But month after month, refactor after refactor, I’ve often found myself in the position of saying:</p>
<blockquote>
<p>“What was I thinking? That’s obviously not good”<br />
“Maybe OOP guys were right all of the time…”</p>
</blockquote>
<p>As a strong believer in my own ideas and really a stubborn person, this was very difficult to accept for me. But as I like to say: "<em>Il tempo è galantuomo (Time is a gentleman)"</em>.</p>
<p>Becoming a bit more serious, I experimented with a lot of things, tried, retried and finally I’ve reached a point where I think I can share something useful. I did it with my team at <a href="https://golee.it/" target="_blank">Golee</a> first as an <em>ADR</em>, and then here as a article.</p>
<hr />
<h2>Separating Concerns: A Look at Side Effects in React</h2>
<p>Managing <strong>side effects</strong> is one of the biggest challenges in any non-trivial React application. While fetching data, mutations, and local state management are the primary responsibilities of a component, putting them all together creates a tightly coupled mess. The complexity often begins when data fetching logic, which is inherently asynchronous and involves managing loading, error, and success states, is placed directly inside UI components.</p>
<p>The following section outlines the common pitfalls of this pattern and proposes a standardized architecture for separating these concerns.</p>
<h3>The Problem with Business Logic in Components</h3>
<p>A lot of components become cluttered with data fetching logic, making them <strong>hard to test</strong>, <strong>difficult to reuse</strong>, and <strong>prone to bugs</strong>. The classic imperative approach using <code>useEffect</code>, <code>useState</code>, and inline service calls forces developers to manually handle loading, error, and success states:</p>
<pre><code class="language-tsx">const BadComponent = () =&gt; {
  const [data, setData] = useState()
  const [isLoading, setIsLoading] = useState(false)

  const fetchData = async () =&gt; {
    setIsLoading(true)
    try {
      const response = await someFetchingFunction()
      setData(response.data)
    } catch (err) {
      // handle error
    } finally {
      setIsLoading(false)
    }
  }

  useEffect(() =&gt; {
    fetchData()
  }, [])

  return isLoading ? &lt;div&gt;Loading...&lt;/div&gt; : &lt;div&gt;{data}&lt;/div&gt;
}
</code></pre>
<p>This pattern introduces:</p>
<ul>
<li><strong>Race conditions and stale state</strong>: Updating loading and data states separately creates timing issues.</li>
<li><strong>Inconsistent patterns</strong>: Every developer handles loading/error states differently.</li>
<li><strong>Testing complexity</strong>: Need to mock API calls and manage complex state scenarios.</li>
<li><strong>Tight coupling</strong>: Business logic is entangled with UI components.</li>
</ul>
<p>In the past, we attempted to build some internal solutions including a custom <code>useApi()</code> hook and an internal event bus for query invalidation (detailed in the <a href="#background-previous-solutions-attempted">background section below</a>), but these custom abstractions were non-standard, error-prone, and lacked the robustness of established solutions.</p>
<hr />
<h2>The Proposed Architecture: Layered Separation with TanStack Query</h2>
<p>A highly effective solution is to adopt on <strong>TanStack Query</strong> with a <strong>pragmatic</strong> layered architecture that scales from simple to complex use cases. This approach allows to cleanly separate concerns while avoiding over-engineering, as this library provides <code>useQuery</code> and <code>useMutation</code> hooks that act as powerful adapters between React components and the data/business logic layers.</p>
<h3>Architecture Layers</h3>
<p>This model cleanly separates concerns while avoiding over-engineering:</p>
<ol>
<li><strong>Data Fetching Layer</strong>: Pure I/O functions that handle API communication and can be completely framework-agnostic.</li>
<li><strong>Business Logic Layer</strong>: Handles data transformation, composition, and core side effects (e.g., complex calculations, analytics). This layer can also be framework-agnostic.</li>
<li><strong>React Adapter Layer</strong>: TanStack Query hooks (<code>useQuery</code>, <code>useMutation</code>) that connect business logic to React components.</li>
<li><strong>Component Layer</strong>: UI components that use adapter hooks for rendering and handle only <strong>UI-specific</strong> side effects.</li>
</ol>
<h3>Implementation Examples</h3>
<h4>Example 1: Simple Data Fetching</h4>
<p>For simple cases, the business logic layer can be skipped entirely, connecting the data layer directly to the React adapter.</p>
<pre><code class="language-tsx">// --------------------------------------------------------
// Data layer
// --------------------------------------------------------
function getOperations(params: { orgPersonId: string }) {
  return apiClient('financial').get&lt;Operation[]&gt;('operations', { params })
}

// --------------------------------------------------------
// React adapter layer
// --------------------------------------------------------
function useOperations(orgPersonId: string) {
  return useQuery({
    queryKey: ['operations', orgPersonId],
    queryFn: () =&gt; getOperations({ orgPersonId })
  })
}

// --------------------------------------------------------
// Component layer (UI)
// --------------------------------------------------------
const OperationsList = (props: { orgPersonId: string }) =&gt; {
  const { data, error, isPending } = useOperations(props.orgPersonId)
  // Do whatever you want in the render
}
</code></pre>
<h4>Example 2: Complex Mutation with Business Logic</h4>
<p>For complex scenarios, the business logic layer handles data processing and non-UI side effects, abstracting them away from the component.</p>
<pre><code class="language-tsx">// --------------------------------------------------------
// Data layer (framework-agnostic)
// --------------------------------------------------------
function getOperations(params: { orgPersonId: string }) {
  return apiClient("financial").get&lt;Operation[]&gt;("operations", { params });
}

function applyDiscount(
  operationIds: string[],
  discountId: string
) {
  return apiClient("financial").post&lt;void&gt;("discounts/apply", {
    operationIds,
    discountId,
  });
}

// --------------------------------------------------------
// Business logic layer (framework-agnostic)
// --------------------------------------------------------
async function getAppliedDiscountsByOrgPerson(orgPersonId: string) {
  const response = await getOperations({ orgPersonId });

  return response.data.reduce((acc: Discount[], operation) =&gt; {
    const discount = operation.appliedDiscount?.discount;

    if (discount &amp;&amp; !acc.some((d) =&gt; d.id === discount.id)) {
      acc.push(discount);
    }
    return acc;
  }, []);
}

async function applyDiscountToOperation(
  operationId: string,
  discountId: string
) {
  await applyDiscount([operationId], discountId);

  // Example of additional needed action (Business Side Effect)
  await hermes.sendNotification({
    type: "DISCOUNT_APPLIED",
    operationId,
  });
}

// --------------------------------------------------------
// React adapter layer (Mutation hook with business logic side effects)
// --------------------------------------------------------
function useApplyDiscountMutation(callbacks: MutationCallbacks) {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: (variables: { operationId: string; discountId: string }) =&gt; {
      // Calls the framework-agnostic business logic function
      applyDiscountToOperation(variables.operationId, variables.discountId);
    },
    ...callbacks,
    onSuccess: (data, variables) =&gt; {
      // Business logic: Invalidate queries and trigger analytics
      queryClient.invalidateQueries({ queryKey: ["applied-discounts"] });
      queryClient.invalidateQueries({ queryKey: ["operations"] });
      trackEvent(`discount.applied`);

      ...callbacks.onSuccess(data, variables);
    },
  });
};

// --------------------------------------------------------
// Component layer (UI)
// --------------------------------------------------------
function ApplyDiscountButton(props: {
  operation: Operation;
  discount: Discount;
}) {
  // The component only defines UI-specific side effects in callbacks
  const { mutate, isPending, error } = useApplyDiscountMutation({
    onSuccess: () =&gt; {
      // UI side effect: Show a success toast or perform other UI actions
      toast.success(`Discount applied to ${props.operation.name}`);
    },
    onError: (err) =&gt; {
      // UI side effect: Show an error toast
      toast.error(`Failed to apply discount: ${err.message}`);
    },
  });

  return (
    &lt;button onClick={() =&gt; mutate(props.operation, props.discount)}&gt;
      {isPending ? `Applying...` : `Apply discount: ${props.discount.name}`}
    &lt;/button&gt;
  );
};
</code></pre>
<hr />
<h2>Strategy for Errors and Side Effects</h2>
<h3>Error Handling Strategy</h3>
<p>To leverage TanStack Query’s built-in error management, the <strong>data layer</strong> and the <strong>business logic layer must throw errors, not catch them</strong>. This allows the React adapter layer (the hook) to catch and handle them gracefully. From there, the component can consume the error state (<code>isError</code>, <code>error</code>) and implement specific UI error feedback.</p>
<h3>Mutation Side Effect Strategy</h3>
<p>A clear separation must be adopted between business logic side effects and UI-specific side effects:</p>
<ul>
<li><strong>Business Logic Side Effects</strong> (e.g., query invalidation, analytics tracking, logging) are encapsulated within the custom <code>useMutation</code> hook. These actions are standardized and do not depend on the specific UI component using the mutation.</li>
<li><strong>UI-Specific Side Effects</strong> (e.g., showing toasts, closing modals, redirecting the user) are passed as callbacks (<code>onSuccess</code>, <code>onError</code>) from the consuming component. This gives the component full control over its presentation logic.</li>
</ul>
<p>Visually, this decision can be represented by the following chart:</p>
<p><img src="https://damiandominella.vercel.app/_astro/diagram.B6E4Wir-_KorTK.webp" alt="side-effects" /></p>
<hr />
<h2>Testing and Outcomes</h2>
<h3>Testing Strategy</h3>
<p>This architecture significantly simplifies testing:</p>
<ul>
<li><strong>API functions</strong>: Mock HTTP calls (eg: using <a href="https://mswjs.io/" target="_blank">msw</a>).</li>
<li><strong>Business logic</strong>: Pure function tests, easy to test in isolation.</li>
<li><strong>Hooks</strong>: Use <strong>@testing-library/react-hooks</strong> and a query client wrapper.</li>
<li><strong>Components</strong>: Mock the hooks if needed, test just UI behavior.</li>
</ul>
<h3>Benefits of the Layered Approach</h3>
<ul>
<li><strong>Strong Separation of Concerns</strong>: Business logic is decoupled from UI components.</li>
<li><strong>Reusability</strong>: Business logic can be reused across different contexts.</li>
<li><strong>Consistency</strong>: Standardized patterns across the entire codebase.</li>
<li><strong>Better caching</strong>: Automatic request deduplication and intelligent cache management.</li>
<li><strong>Improved Dev Ex</strong>: Built-in loading states, error handling, and excellent devtools.</li>
<li><strong>Easier Testing</strong>: Pure functions can be tested in isolation without React dependencies.</li>
<li><strong>Flexible UI Feedback</strong>: Components can provide context-specific feedback for the same mutation.</li>
</ul>
<h3>Tradeoffs to Consider</h3>
<ul>
<li><strong>Query key management</strong>: Developers must be careful with query key consistency and invalidation to prevent bugs.</li>
<li><strong>Initial Verbosity</strong>: The initial code for a mutation and its consuming component may be slightly more verbose compared to encapsulating everything in one place, but this is a worthwhile cost for long-term maintainability.</li>
</ul>
<h3>Background: Previous Solutions Attempted</h3>
<p>Understanding our journey helps contextualize why this layered architecture is the right choice.</p>
<p>We initially attempted to solve these issues with a custom <code>useApi()</code> hook that abstracted some state handling. While this was an improvement over raw <code>useEffect</code> patterns, it had a critical limitation: it didn’t handle <strong>stale state</strong> properly. Updating loading and data states separately (e.g., <code>setIsLoading(true)</code> → <code>setData(data)</code>) introduced race conditions and layout shift flickers, especially with fast or concurrent re-renders.</p>
<p>For mutations, the situation was even worse. We had no standardized abstraction. Mutations were done by directly calling service functions or making HTTP requests from components. This made it difficult to manage loading states, error handling, and post-mutation updates consistently.</p>
<p>We attempted to solve query invalidation by building a lightweight internal event bus, essentially a simplified version of our <code>Eywa</code> service. Components could subscribe to events (e.g., <code>OperationUpdated</code>), and certain actions would publish those events, triggering refetching. While clever, this approach was non-standard, error-prone, and lacked observability.</p>
<p>Building these custom abstractions wasn’t a waste of time. It gave us deep understanding of the responsibilities and edge cases that TanStack Query handles elegantly. However, maintaining custom solutions for problems that have been solved by the community diverts resources from our core business logic.</p>
]]></content:encoded>
        </item>
    </channel>
</rss>