How to Write an Effective Software Design Document. Un post molto dettagliato di qualche mese fa, da adattare all'era dell'AI agentica, su cosa mettere in un documento di progettazione di un software o di una feature software.
How to Write an Effective Software Design Document. Un post molto dettagliato di qualche mese fa, da adattare all'era dell'AI agentica, su cosa mettere in un documento di progettazione di un software o di una feature software.
Testimonianze che stanno girando su Twitter che frenano un po' il trend forzato che sta trasformando lo sviluppo software in pura velocità e quantità rimuovendo l'ingegneria:
I am done with this shit. It is over. The state of engineering right now is horrible. It has been half a month since I started a new role at a big company. Nobody knows anything here. The specs, code, tests, PRDs, tickets, resolution of those tickets, reports, etc., everything is made by Claude Code. Nobody on my team likes this. They are being forced to ship as much as they can. I have heard multiple times from higher management that pushing code is not a bottleneck, so why are we slow? People are working 12 to 13 hours a day just to press enter. Nobody is reading anything. Humans in corporate are doing nothing on their own. Everyone, literally everyone, from an L1 to an L7 engineer here is doing the same thing. Talk to Claude. There is no sense of victory. Nobody is resolving bugs. In reality, nobody is thinking anymore. Everything is done by LLMs. It is so soul-sucking. I would not mind it, to be honest, if we were at least given the time to check out the code and see what is going where. But no, the goal is to just ship. No matter what happens.
(@v0xium)
I’m slowly starting to hate AI code review.
Massive amounts of nitpicking and an ungodly amount of corner-case defensive programming. After a few rounds the intent of the code is lost under mountains of extra code forced by the reviewer.
I’m starting to be more agressive with implementer agents pushing back heavily for the reviewer agents to prove why their nitpick will make the code better, only for the reviewers to backtrack in frenzy. SO WHY DID YOU RAISE THIS IN THE FIRST PLACE?
All this because I still require that „this code must be readable and easily understandable”
"Il sistema TreC+ si ferma per manutenzione programmata" per 4 ore, comunica l'ASUIT.
Mi viene in mente questo thread Twitter dove Gergely Orosz argomenta come tirare giù i sistemi per ore, spesso di notte, è un forte segnale di scarsa cultura e maturità ingegneristiche. Si finisce per considerare "eroico" il lavoro degli sviluppatori e degli ingegneri che stanno svegli la notte, quando in realtà non è una buona pratica perché queste persone non imparano niente (e non ci si prende mai la briga di mirare a manutenzioni e migrazioni zero downtime e safe) e ci rimettono comunque inutilmente i clienti.
Mi segnalano che sono al 232° posto per quantità di commit su GitHub in Italia:
Non mi ritengo particolarmente prolifico, e ovviamente nelle statistiche della maggior parte degli utenti non compare l'attività privata, che di default è nascosta.
Per "contribution" totali sono invece al 75°:
I CTO si sono stufati di fare i CTO, scrive Gergely Orosz:
Unrealistic expectations, including about AI, by founders and CEOs are the leading cause of jobs turning bad for CTOs and VPEs right now in 2026:
- CTO expected to magically transform the company to be “AI-native”
- CTO must make significant engineering cost cuts of up to 20-50%, including morale-sapping job cuts
- “Do more with less” equals shipping more with fewer people (e.g., no backfills)
- CTO faces pressure on business results as AI coding bills rack up
- Founder slop: they want wonky AI prototypes shipped as full-blown products within weeks
I think the main reason many people (including me), very often, lack the motivation to read content that is likely generated by AI is the suspicion that it comes from a place of intellectual laziness.
afr0ck in un commento su Hacker News.
Pattern di UI per interfacce AI, beautifului.dev:
Of course, bad engineers were always a liability.
It has been like this for decades, well before OpenAI or Anthropic existed. Bad decisions compounded, unnecessary complexity accumulated and teams ended up maintaining systems nobody really understood.
The difference is that there used to be a limit to how fast you could do it.
Florian Herrengt in AI is removing the middle class of software engineering.
p99 0 ms* autocomplete for 240 million domain names. Strategia interessante per autocompletare un nome di dominio nella UI nel minor tempo possibile.
Telegram ha presentato silenziosamente Telegram Serverless, che permette di create bot senza gestire infrastruttura, con il codice eseguito su infrastruttura di Telegram. È inclusa la persistenza SQLite. L'accesso è limitato per ora.
Telegram Serverless lets you run backend code for your bot and Mini App directly on Telegram's infrastructure — no servers to provision, no containers to keep alive, no scaling to think about. You write plain JavaScript modules, deploy them with a single command, and Telegram runs them in a fast, isolated V8 sandbox that sits right next to the Bot API and a built‑in database.
Molto interessante per semplici bot.
Two database migrations and a divorce. Jack Ellis di Fathom Analytics spiega la migrazione di 65 miliardi di righe da SingleStore (database OLAP+OLTP) a ClickHouse (ClickHouse Cloud) per OLTP + MySQL/Vitess (PlanetScale) per OLAP, con un risparmio molto significativo e maggiore flessibilità.
I now periodically find myself reviewing a younger dev's code, leaving comments to teach some engineering - only to eventually realize I'm actually reading just yet another Claude's subpar output...
So who am I actually contributing my comments, suggestions, and knowledge to? Will they go back to Claude? Into the training set for the next frontier LLM? Or will at least some of it stick in the dev's mind? This is deeply demotivating, how did we end up like this...
Aleksandr Shvedov, JetBrains
Ho pubblicato un articolo su DMARCwise (Why DMARC's new "np" tag can fail with DNSSEC) che evidenzia come rilevare se un dominio esiste o meno è più complicato di quello che la RFC di DMARC suggerisce quando c'è di mezzo DNSSEC. Molti grossi provider DNS, come Cloudflare, NS1, AWS Route 53, Azure DNS, Oracle Cloud DNS e Bunny DNS, usano il metodo NSEC "black lies" o "compact denial of existence" (RFC 9824) per semplificare la generazione della risposta DNS negativa, rinunciando però così al codice di risposta NXDOMAIN, che è il metodo con cui storicamente si rilevava la mancata esistenza di un dominio.
Visto che di questi tempi serve dirlo, ho scritto l'articolo di 3.500 parole a mano impiegandoci più di 8 ore di lavoro. Ho usato Codex con GPT-5.5 per revisionare typo, sintassi, grammatica e correttezza del contenuto, applicando qualche correzione qua e là.
L'ho pubblicato ieri su Hacker News, dove di domenica è più facile ottenere attenzioni, e ora ha 50 punti e 20 commenti. Posizione massima in homepage, numero 10:
Il traffico è stato di circa 1.000 visite ma con un impatto essenzialmente irrilevante sul resto del sito (zero nuove iscrizioni):
Powering Evernote AI features with vLLM. Ludovico Papavassiliou di Bending Spoons spiega come sono state implementate alcune feature AI di Evernote (9 miliardi di note, 100 milioni di note aggiunte ogni anno), in particolare per quanto riguarda la trascrizione audio (800mila trascrizioni audio al mese più altre 200mila con riconoscimento speaker). Sono passati da WhisperX a vLLM, sull'infrastruttura interna condivisa tra i prodotti (K8s GCP), e il costo giornaliero è sceso da picchi di 1000 $ al giorno a poco più di 100 $ (solo 0,03 $ per ora di audio). Per le trascrizioni con diarization usano invece ElevenLabs scribe-v2 perché la qualità giustifica il costo.
Making Electron apps feel native on Mac. Segnalibro per una lista di trucchi per rendere un'app Electron il più vicina possibile al feeling nativo.
Stop Using Conventional Commits. Ah, finalmente ho trovato il mio club. I conventional commit sono inutili nella maggior parte dei casi.
Agentic AI is a fascinating mirror. It can code as well as the user who drives it. If that user is a junior engineer, now you have a faster junior engineer. If the user is a staff engineer, now you have a faster staff engineer.
What agentic AI doesn’t do is magically convert a junior engineer into a staff engineer, because the user driving it still needs enough experience to know what a good solution looks like.
A staff engineer in the US at a large company a The Pragmatic Engineer.
It used to be if you found a GitHub repository with a hundred commits and a good readme and automated tests and stuff, you could be pretty sure that the person writing that had put a lot of care and attention into that project.
And now I can knock out a git repository with a hundred commits and a beautiful readme and comprehensive tests of every line of code in half an hour! It looks identical to those projects that have had a great deal of care and attention. Maybe it is as good as them. I don’t know. I can’t tell from looking at it. Even for my own projects, I can’t tell.
Simon Willison in Vibe coding and agentic engineering are getting closer than I’d like.
Idempotency Is Easy Until the Second Request Is Different. Deep dive nell'implementazione di idempotency nelle API HTTP.
Leggo cose buone su RWX, nuova piattaforma di CI/CD pensata per velocizzare i processi nell'era dell'AI engineering, con parallelizzazione automatica, esecuzione delle pipeline prima del commit e altre ottimizzazioni.