Adventures in Nodeland
adventures.nodeland.dev · English
I write about my journey as a core contributor of Node.js, an author, and a maintainer of many modules - including Fastify and Pino. I will also write about my journey as the Co-Founder & CTO of Platformatic. In addition, I speak at conferences and will add links to all my talks in case you missed one. If you like my Open Source work, consider sponsoring me on GitHub
rss2 indieweb atom
https://adventures.nodeland.dev/rss
- Last post
- Aug 9, 2026
- Posts in 24 h · 7 days · 30 days
- 0 · 0 · 0
- Our last check
- Answering
- Served from
- United States
- Text score at discovery
- 13,855
- Format
- rss2
- Features in the feed
- atom
- Community
- indieweb
Posts
What our queue read from this feed. Open one to read it here, or go to the site that published it.
- Triaging the AI Horde
Aug 9, 2026 · original
Hey Everyone! This edition is a bit different. I want to talk about something that takes up a surprising amount of my week: triaging security vulnerabilities. I receive 20-40 reports to triage a week. That's work that must be done, and there are plenty of other people doing it too, but I try to pull my fair share. Here's the thing that's changed: almost all of those reports are now AI-written. On top of that, we usually receive 3-5 duplicates. Linus Torvalds has an opinion on the matter, too: "We're making it clear that AI detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved – and only makes that duplication worse because the reporters can't even see each other's reports." May 20, 2026, Open Source Summit North America keynote panel Sometimes there is a competent human behind the AI doing the research. Ot - No, We Can't Harden Node.js Against Prototype Pollution
Jul 19, 2026 · original
Every few weeks, a security report lands that follows the same template. Someone has found a new gadget: a spot where code reads a property it expected to be absent and does something dangerous with it. child_process picking up a shell it was never passed. A router honouring an option out of nowhere. An ORM resolving a field it should not. Sometimes the gadget is in Node.js core; more often it is in a library three levels down your dependency tree. It does not much matter which. The write-up is careful, the proof-of-concept works, and the ask at the bottom is always the same: please harden this so it can't happen. My answer is always the same too, and people do not love it. You cannot harden against this. Not because the maintainer is lazy, and not because the gadget isn't real. Because every one of these reports has the same precondition buried in step zero: the application already has - CVE-2026-48931 Shouldn't Have Been a CVE
Jul 2, 2026 · original
I reported and fixed the HTTP/1.1 response queue poisoning issue in Node.js http.Agent that became CVE-2026-48931 , and the Node.js team reviewed it and shipped it through the security process. Looking back, two things about that were mistakes, and one of them broke a lot of people's deploys. This post is me owning the parts that were mine. The short version: The underlying behavior is real and worth hardening against. The guard I added is good defense in depth and should stay. Treating it as a vulnerability and pushing it onto the security-release track was the wrong instrument for the problem. This is something HTTP/1.1 does by design, not a bug specific to http.Agent . The fix I wrote carried a publicly observable side effect that made node-fetch@2 emit false ERR_STREAM_PREMATURE_CLOSE errors, which cascaded into Google API auth, Firebase, Backstage, and the official Docker images. Th - Why “Trusted Publishing” Can’t Save Us from Social Engineering
May 2, 2026 · original
Hey Everyone! I want to talk about something that’s been bothering me since the Axios compromise . This issue goes beyond just one package. First, a quick definition: In the npm ecosystem, “trusted publishing” means using tools (like Sigstore and OIDC) to confirm that a package was published by a verified identity and built using a verified process, typically through a secure continuous integration (CI) pipeline. The idea is to give consumers cryptographic proof of who published the package and with what workflow. It’s about the main promise of npm “trusted publishing” and why, given the attacks we’re seeing now, it’s a risky illusion. Here’s the short version: Trusted publishing checks who published something, but it doesn’t check if that person actually meant to publish it. Right now, that difference is the most important thing for supply chain security. What Just Happened You probably - The Economics of Judgment
Apr 12, 2026 · original
In recent months, I’ve shared thoughts on the human role in AI , the future of software engineering , what these changes mean for businesses , and why coding skills still matter . My perspective comes from hands-on experience: maintaining projects like Node.js , Fastify , Pino , and Undici , building Platformatic , and reviewing thousands of pull requests where AI handled the code and I made the final calls. I recently found an academic paper that puts a formal structure to the trends I’ve noticed. “The Economics of Digital Intelligence Capital” by Yukun Zhang and Tianyang Zhang treats the AI industry as a new kind of economy. Their model uses solid math to explain patterns I’ve seen in practice and introduces ideas I hadn’t thought about before. I’d like to share their main ideas and link them to my own experiences. Together, their theory and what we see in real life give us a clearer s - The DCO Debate: Who Is Responsible for AI-Generated Code?
Mar 18, 2026 · original
AI-assisted development is already a reality, and the open source community is coming together to figure out how to manage it. Many major projects and organizations now agree on a few key ideas: people must stay accountable, being open builds trust, and existing contribution rules like the Developer Certificate of Origin (DCO) still matter. The Linux kernel community, Red Hat’s legal team, and the OpenJS Foundation have all come to similar conclusions. AI can help with development, but people are still responsible for what they submit. This is the real situation shaping software development today. The question is no longer if we should use AI, but how to use it in a responsible way. Against that backdrop, a recent discussion in the Node.js project explored how these principles apply in practice. The Trigger PR #61478 adds a Virtual File System to Node.js core , spanning amost 19,000 line - Software Engineering Splits in Three
Mar 15, 2026 · original
A few weeks ago, I wrote about the human in the loop and why review is now the bottleneck in software development. Then I wrote about what this means for careers and students entering the field. But one question kept coming up in conversations: what does this mean for organizations? Not startups. Not tech companies. Enterprises. The banks, insurers, manufacturers, and retailers that run on software but don't think of themselves as software companies. The Old Model Is Breaking A major regional bank spent months weighing whether to build or buy a new payment reconciliation system. Stakeholders wavered, unable to make a clear decision. In the meantime, a processing error went undetected, delaying thousands of business transactions and triggering a $2 million regulatory fine and weeks of negative headlines. The cost of getting this decision wrong isn't just about overspending on a vendor; it - Your Coding Agent Keeps Making the Same Mistakes. I Built a Fix
Mar 8, 2026 · original
Hey Everyone! I've been thinking about something for a while: can coding agents stop making the same mistakes? You know the drill — you fix a bug, then three weeks later you hit the exact same issue in a different file. Or your AI assistant forgets a lesson you taught it yesterday. Frustrating, right? Well, I built something to fix that. Introducing pi-self-learning — a pi extension that gives your coding agent a git-backed memory. What it does After each completed agent task, it automatically: - Extracts what went wrong and how it was fixed - Appends the entry to a daily markdown file - Updates core/CORE.md with top-ranked durable learnings - Writes full history to long-term-memory.md - Commits everything to a dedicated memory git repository The memory folder layout looks like this: .pi/self-learning-memory/ ├── .git/ ├── daily/YYYY-MM-DD.md ├── monthly/YYYY-MM.md ├── long-term-memory.m - My Personal Skills for AI-assisted Node.js Development
Mar 1, 2026 · original
Hey Everyone! I've been working on something I want to share with you. As you know, I've started relying on AI assistants to do most of my coding, but I review everything that is being generated . I've grown frustrated by the slop being generated and the amount of corrections I had to do. After years of building with Node.js, Fastify, and TypeScript, I've learned a lot: patterns that work, tools that save time, and gotchas that bite you when you least expect it. I need my AI assistants to match (or at least get close) my expectations. I decided to organize all of this into a collection my AI assistant can use to help me work faster. Here is my skills repo that you can start using with a simple: npx skills add mcollina/skills . This repo encode my preferences and best practices so I don't have to repeat myself every time. You might find it useful as well. What's inside? The repo includes - Yes, Learning to Code Is Still Valuable
Feb 15, 2026 · original
Every few weeks, someone shares a bold opinion: "Don't bother learning to code, AI will do it all." I've seen this from VCs, influencers, and people who have never actually shipped a production system. They're wrong. In the past few weeks, I've written about the human-in-the-loop , the future of software engineering , and what these changes mean for enterprise organizations . The core point across all three: AI moved the bottleneck from coding to review, from doing the work to making decisions. Here's what many people miss: you can't develop good judgment without first learning to code. You Can't Review What You Don't Understand My daily workflow looks different now. When an issue comes up, my first thought is to let AI handle it. Security problems in Undici, bugs in Fastify, new features for Platformatic: AI handles the coding for me. But I still review every change, every behavior upda - The Future of the Software Engineering Career
Feb 2, 2026 · original
A few weeks ago, I wrote about the human in the loop and why review is now the bottleneck in software development. That post triggered a lot of conversations, and one question kept coming up: What does this mean for someone starting their career today? If you're a student, a career changer, or someone advising young people on their path into tech, this post is for you. Fundamentals Matter Again For the past decade, the industry focused on rapid delivery to employment. Learn React in twelve weeks. Build a portfolio. Get hired. Figure out the rest on the job. That worked when companies needed bodies to type code. When the bottleneck was implementation speed, you could learn just enough to be useful and pick up the deeper knowledge later. That world is gone. When AI can implement features faster than any junior developer, what becomes valuable is the judgment to know whether the implementat - Building GitHuman: An AI-Coded Tool for Reviewing AI Code
Jan 27, 2026 · original
Like everyone else, I had to build something over the end-of-year break. I wanted to fix a burning problem I had: how could I review the code my agents produced before I pushed. GitHuman was born. AI coding agents are transforming how we write software. Cursor, Copilot, Claude Code: they can generate hundreds of lines in seconds. But there's a problem: by the time you've pushed to a branch and opened a PR, you've already committed to an approach. The review happens too late. I'm a firm believer that human interaction is key. A few days ago, I wrote about the human in the loop and why review is now the bottleneck in software development. GitHuman is that idea turned into a tool. Introducing GitHuman: Review AI-Generated Code Before You Commit 🌐 githuman.dev | 📦 GitHub A local-first tool that moves the code review checkpoint from "after push" to "before commit" GitHuman fixes this by mov - The Human in the Loop
Jan 18, 2026 · original
Mike Arnaldi wrote a thought-provoking piece titled " The Death of Software Development ." I respect Mike a lot. Effect is brilliant work, and his analysis of the current AI moment is sharper than most. But I think he's missing something critical. My Workflow Has Changed Let me be clear: I'm not here to argue that AI isn't transforming our industry. It is. My own workflow has changed dramatically. When an issue lands in my queue today, my first instinct is to throw it at AI. Security vulnerabilities in Node.js or Undici . Bugs in Fastify . New features for Platformatic . AI handles the implementation. I've shipped dozens of fixes this way in the past few months. But here's the thing Mike glosses over: I review every single change. Every behavior modification. Every line that ships. The Bottleneck Has Shifted Mike writes that he built a Polymarket analysis tool in 2 hours, writing zero li - Noop Functions vs Optional Chaining: A Performance Deep Dive
Oct 21, 2025 · original
Hi Folks, This week I want to talk about something that might surprise you: the performance cost of optional chaining in JavaScript. A question came up recently about whether using a noop function pattern is faster than optional chaining, and the answer might make you rethink some of your coding patterns. After a pull request review I did, Simone Sanfratello created a comprehensive benchmark to verify some of my thinking on this topic, and the results were eye-opening. The Setup Let's start with a simple scenario. You have two approaches to handle optional function calls: // Approach 1: Noop function function noop () {} function testNoop () { noop (); } // Approach 2: Optional chaining const a = {} function testOptionalChaining () { a . b ? . fn ? .(); } Both accomplish the same goal: they execute safely without throwing errors. But how do they compare performance-wise? The Numbers Don't - From fast-redact to slow-redact
Oct 9, 2025 · original
Today I'm announcing slow-redact , a new package that provides the same API as fast-redact but with a crucial difference: immutability guarantees . This package was born out of necessity after a spurious CVE filing against fast-redact and our decision to prioritize safety in the pino ecosystem. Protecting Sensitive Data in Logs Log redaction is a critical security feature for production logging systems because applications routinely process sensitive data that must never appear in logs—including passwords, API keys, authentication tokens, credit card numbers, and personally identifiable information (PII). Without proper redaction, this sensitive data can be exposed in log files, which are often stored in less secure locations, shared across teams, sent to third-party monitoring services, or retained for long periods. A single leaked password or API key in a log file can compromise an ent - Node.js: easy to learn, hard to master - perfect for AI
Feb 27, 2025 · original
Many years ago, I got incredibly excited about a new technology for writing any application: Node.js. What made it special then (and now)? I firmly believe that its scripting nature, its “tolerance” to mistakes, the easiness of reusing code, and the “good enough” performance make a combination of speed, flexibility, and ease of use that is hard to resist, like a Swiss Army knife for developers, offering a “good enough” tool for every job. But there’s a catch– while easy to get started with, mastering Node.js is an entirely different beast. And with AI-assisted development re-shaping software engineering, this learning gap is growing exponentially. Let’s unpack it. JavaScript is a weakly typed programming language, meaning that most code you’d throw together would not error. This is why TypeScript was created: to bring back some structure when none existed. Most code that TypeScript fails - You should not use URLPattern to route HTTP requests on the server
Feb 4, 2025 · original
URLPattern is a Web Specification, which recently landed in Node.js thanks to the outstanding work of Yagiz Nizipli and Daniel Lemire in Ada v3 . It will soon be available in Node.js v23. You can see the evolution of the spec at https://github.com/whatwg/urlpattern . The API was designed with client side routing in mind and did not consider the use case of servers and the learnings of running Node.js at scale for many years. The Problem URLPattern was designed around the path-to-regexp module, which is the basis of the popular express framework. All the analyses I will do apply to both - and all other libraries that apply the same concepts. URLPattern and path-to-regexp converts path patterns into regular expressions that are then matched against actual URLs. Therefore, if you have 100 routes, your router will test your incoming URL with all the regexps, in order. This is very flexible . - Workskipping is a great technique. What happens when you can't skip it?
Jun 24, 2024 · original
123 Hi Folks, This issue covers how adding a "fast path" to make some benchmark shine can confuse users and introduce "traps" that could be extremely surprising if not properly documented. Hono RegExpRouter and TrieRouter analysis A month ago, a question about Hono claims of their router performance was made into the find-my-way repository. I set up to investigate because I thought there wasn't room for such a massive improvement over find-my-way . Hono has a great design that combines different routers for different situations. They have a very fast router called RegExpRouter , a TrieRouter , and a LinearRouter . The latter is only focused on a fast startup scenario (workers), so I didn't investigate that. I updated the "old" benchmarks that Tomas della Vedova did years ago and added hono . Here are the numbers I saw: ➜ router-benchmark git:(master) ✗ node benchmarks/find-my-way.js ==== - What happens when a major npm library goes commercial?
Jun 17, 2024 · original
Hi Folks, A few weeks have passed, and I've been so busy catching up with my backlog. As this issue goes out, I'd be back at inbox zero. I'm glad I had some time to catch up, as the last few months have been incredibly hectic. This issue covers a topic that is very dear to me: OSS sustainability. We have seen plenty of ways to fund Open Source in the last few years, and a move to commercial software is happening. This is now happening to libraries in npm as well. ua-parser-js switching to AGPL+commercial. Welcome my-ua-parser. What happens when a library with 54 million monthly downloads switches from MIT to an AGPL+commercial license? We are about to find out as this license combo is very restrictive and it rules out any commercial SaaS usage (or any other usage that does not involve releasing the full source code). In issue #680 , Faisal Salman explains the reasoning behind the change - Node.js v22, AI-Warp, A deep dive on setImmediate, and many other Adventures in Nodeland
May 20, 2024 · original
Hi Folks, I have been silent for long, and I've lost the habit of writing my thoughts in this newsletter. The weekly frequency that once was my target has been slipping for the last six months, leading to two months and a half of silence. I need to get back my writing mojo, and keep you all up to date. This edition includes: An in-depth explanation of why deferring work with setImmediate() worsen your application application performance long term. Fastify v5 release preparation starts! asyncforge , a new module to implement improssive Developer Experiences. ...and the usual summary of OSS releases and interesting articles. What's new in Node.js v22? A performance trick that would backfire: setImmediate In 2017, Tomas della Vedova added a change to Fastify that seemed to drastically improve benchmarks: deferring all responses by an event loop with setImmediate() . This technique can give
Discovered by the rss-feed-index crawler, which checks each feed at most once a month.
Same record as JSON: https://api.agentalog.com/api/feeds/fd_adventures_nodeland_dev_3d47cd80f3f2dbb4. More from this site: adventures.nodeland.dev in the Feeds tab.