Most developers let their AI assistant guess how to write Node.js. No context, no constraints, no history, just vibes and generic output. The result is code that ignores the event loop, skips proper error handling, and looks nothing like how senior engineers actually build. The question is: can you actually teach your AI to code like you?

In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina dive into the emerging AI toolchain for Node.js development, from Agent Skills to coding agents like OpenClaw and Pi. Matteo shares his own personal skills repository (mcollina/skills), a collection of battle-tested Node.js, Fastify, and TypeScript best practices that any AI coding assistant can load and apply out of the box.

In this episode, we cover:

✅ What Agent Skills are and why the open standard changes how AI-assisted development works

✅ Why Matteo got frustrated with AI slop and built his own skills repo — and what's inside it

✅ How to install and use mcollina/skills with Claude Code, GitHub Copilot, OpenAI Codex, and more

✅ What OpenClaw and Pi are, and how they fit into the Node.js AI toolchain

✅ The practical question: what should a JavaScript developer actually install today to code with AI effectively?

✅ The difference between prompting from scratch every time vs. encoding your expertise once and reusing it everywhere

The takeaway? AI-assisted development isn't just about which model you use, it's about the context you give it. Skills are how you stop training your AI from zero on every project and start shipping faster, with fewer corrections. If you're building with Node.js and you're not using skills yet, this episode will change how you set up your workflow.

Workflows look easy… until they corrupt your data.

Durable workflows in Node.js promise retries, persistence, and long-running execution. On platforms like Vercel, everything just works. But the moment you move to Kubernetes, a hidden problem appears: version mismatch. A small code change can replay the wrong steps, mix results, and silently break your system.

The question: how do you run durable workflows safely in production?

Luca Maraschi and Matteo Collina dive into workflow orchestration in Node.js and the real challenges behind deterministic execution. From Workflow DevKit to Platformatic World, they break down how version-safe workflows work on Kubernetes, ensuring every run is pinned to the exact code version that created it, even across deployments, retries, and long-running jobs.

In this episode, we cover:

✅ Why durable workflows break on Kubernetes and not on Vercel

✅ How deterministic replay works and why it can corrupt data

✅ The hidden problem of versioning in long-running workflows

✅ How Platformatic World enables version-safe orchestration

✅ Why queue routing is critical for workflow correctness

✅ What zero-config workflows look like in real production systems

If you're building with Node.js, Kubernetes, or event-driven architectures, this episode is for you. Durable workflows are powerful, but without version safety, they’re a risk. This is what it actually takes to run them in production.

Node.js delivers high-performance I/O, moving data fast between network and disk. But today’s cloud-native, serverless, and AI-driven workloads hit a wall: the filesystem isn’t virtual. That means you can’t import in-memory modules, sandbox tenants, or bundle assets into a single executable without bloating binaries. The question: how do we unlock these capabilities?

Luca Maraschi and Matteo Collina dive into Node.js Virtual File System (VFS): from @platformatic/vfs in userland to the upcoming node:vfs in core. VFS enables in-memory testing, sandboxed multi-tenancy, AI agents, and code-generation pipelines, features that standard fs simply can’t deliver.

In this episode, we cover:

✅ The limitations developers face without a virtual filesystem and why traditional workarounds fall short

✅ How VFS plugs into Node.js fs and module loader to enable dynamic modules for AI and runtime code

✅ VFS architecture: providers, mounts, overlays, and seamless import/require integration

✅ Real-world use cases: single executables, isolated tests, AI agents, plugins, and codegen workflows

✅ Why VFS belongs in core Node.js, and what sets core apart from userland.

If you need flexibility, isolation, or advanced runtime power in Node.js, this is for you. Virtualizing the filesystem is a game-changer for developers, enterprise teams, and AI platforms.

AI applications are shifting from experiments toward real-world systems. As teams move to production, common challenges come up, such as managing low latency, handling concurrent requests, and integrating with different data sources and APIs. But beyond the models and prompts, there’s an important infrastructure question: Which runtime can handle AI workloads at scale and still be easy for developers to use?

In this episode of “The Node (and more) Banter,” Luca Maraschi and Matteo Collina talk about why Node.js has become a key instrument for modern AI applications. Whether it’s managing LLM APIs, streaming responses, or building real-time agent systems and scalable AI backends, Node.js is at the heart of many production AI platforms.

We’ll discuss why Node.js’s event-driven design works so well for AI workloads, how developer productivity speeds up AI development, and what enterprise teams should think about when building reliable AI services.

Here’s what we’ll cover:

✅ Why most AI applications are about orchestration, not simply building models

✅ How Node.js manages streaming, concurrency, and real-time AI responses

✅ The role JavaScript plays in connecting models, APIs, and user interfaces

✅ Why developer speed matters in the fast-changing world of AI

✅ What enterprise teams need to think about when running AI workloads in production

If you’re building or leading teams working on AI-powered products, this conversation will show why Node.js is becoming a key part of today’s AI stack.

Every deployment is a gamble. A user mid-session hits a new backend. A renamed field breaks a form. A shared TypeScript interface diverges between client and server, and suddenly your support queue is full, and three teams are in a bridge call trying to figure out who broke what. This is version skew, and it's been quietly slowing down engineering teams on Kubernetes for years.

In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina introduce Skew Protection in Platformatic's Intelligent Command Center (ICC), bringing the deployment safety that frontend teams love about Vercel, directly into your existing Kubernetes setup. No migrations. Use the tools you're already using for your CI/CD pipeline. Just safer, faster shipping.

We'll explore:

✅ Why version skew is a developer velocity problem disguised as a reliability problem

✅ How broken deployments silently erode user trust, and what it costs enterprises at scale

✅ How ICC pins users to their session version using cookie-based, version-aware routing

✅ The Active → Draining → Expired lifecycle that makes zero-downtime deploys predictable

✅ Why immutable per-version Deployments change how teams think about risk

✅ How Prometheus traffic monitoring automates cleanup. No manual rollback babysitting

✅ What this means for teams running Next.js, Remix, or monorepos on Kubernetes

The big picture?

Fear of breaking changes leads to bigger, rarer deployments, and that's where velocity goes to die. ICC's skew protection gives enterprise dev teams the confidence to ship smaller, ship faster, and stop making users pay the price for infrastructure gaps. Kubernetes just got a lot less scary.

AI adoption is accelerating across enterprises, powering automation and smarter decisions. But without auditability, AI quickly turns into a black box. Hard to trust, and difficult to govern. Transparent, traceable AI is not optional. It’s how you build trust, reduce risk, and meet real-world compliance needs.

On this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina break down how to build AI apps that are fast, scalable, and crucially auditable while taking advantage of Platformatic OpenSource. We go deep into real strategies: designing for traceability, logging every decision, and making AI explainable from the ground up.

We will explore:

✅ How to structure Node.js-based AI applications for auditability and compliance

✅ Best practices for logging, tracking, and versioning AI models

✅ How Platformatic tools simplify building traceable APIs and data flows

✅ Balancing performance, scalability, and transparency in AI applications

✅ Why auditability is critical for enterprise adoption of AI

✅ What this means for the future of trustworthy AI systems

The takeaway?

Auditability isn’t a box to tick. It’s a real need for developers and operators. If you’re building AI for regulated industries, at scale, or for multi-tenant platforms, you need traceability built in. This episode shows how auditable design drives trust, cuts risk, and speeds up adoption across your teams.

Node.js performance discussions usually revolve around CPU and latency. Memory often receives less attention. But memory footprint directly affects cost, scalability, cold starts, and container density. Cutting memory usage in half fundamentally changes how efficiently you can run Node.js in production.

In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina are joined by James Snell, Principal System Engineer at Cloudflare, core contributor to Node.js, and member of the Node.js Technical Steering Committee. Together, they unpack how we reduced Node.js memory consumption by 50 percent and what this reveals about V8 internals, runtime behaviour, and modern deployment environments. This conversation goes beyond surface-level tuning. It explores how JavaScript engine design decisions influence real-world infrastructure costs and architectural choices.

We will explore:

✅ How V8 manages memory and where Node.js applications typically waste it

✅ What pointer compression is and why it has such a dramatic impact

✅ The tradeoffs between memory layout, performance, and compatibility

✅ How memory footprint influences Kubernetes density and serverless efficiency

✅ Why these optimizations matter for large scale and edge deployments

✅ What this means for the future of Node.js runtime evolution

The takeaway?

Memory is not just a technical detail. It is a strategic lever. If you are running Node.js in containers, serverless platforms, edge environments, or high-density clusters, this episode explains how reducing memory usage can unlock meaningful efficiency gains across your entire stack.

Performance in enterprise systems isn’t just about fast code. It’s about making the right architectural choices. Surprisingly, caching is still often skipped, leaving applications slower, more expensive, and harder to scale.

In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina dig into why caching is so often overlooked, when it actually delivers value, and how enterprises can adopt it effectively without adding complexity.

We’ll explore:

✅ The main reasons companies avoid caching, and whether those reasons hold up

✅ How caching impacts scalability, cost, and system reliability

✅ Different caching strategies and when to apply them

✅ Pitfalls to avoid when introducing caching into existing systems

The big picture?

Caching isn’t just a technical tweak. It’s a strategic lever. Done right, it drives performance, efficiency, and scalability, giving enterprises a competitive edge in high-demand systems.

Running HTTP requests and consuming messages from queues or brokers in the same Node.js process may seem convenient—but it often leads to unpredictable latency, resource contention, and fragile systems.

In this episode of The Node (& More) Banter, Luca Maraschi & Matteo Collina explore how Platformatic Watt enables entirely new patterns for modern Node.js architectures, from sagas to actors.

We’ll dive into:

✅ Why mixing HTTP and queue workloads can hurt reliability and throughput

✅ How Watt allows you to isolate workloads while fully leveraging Node.js’ event loop and threads

✅ New architectural patterns Watt makes possible for sagas, actors, and event-driven systems

✅ How predictable, multi-threaded execution simplifies coordination in complex distributed workflows

✅ Lessons from real-world systems on separating concerns without complicating your code

If you’re building Node.js services that orchestrate multiple message flows or implement durable workflows, this episode explains how Watt unlocks patterns that were previously impossible—enabling stable, scalable, and maintainable systems.

Node.js performance in production isn’t about a single number — it’s about understanding the signals that drive scaling, stability, and cost. Event Loop Utilization (ELU) sounds simple, but once you add Kafka consumers, Kubernetes autoscaling, streams, and worker threads, things get complicated fast.

In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina dig into Node.js metrics through the lens of real-world, event-driven systems. We focus on how ELU behaves in Kafka-heavy workloads, how it correlates with CPU, memory, and I/O, and why choosing the right metrics matters when you’re running Node.js on Kubernetes — especially with architectures like Watt.

We’ll explore:

✅ What Event Loop Utilization really measures — and why it’s a better signal than CPU alone

✅ How ELU behaves for Kafka consumers and stream-based workloads

✅ The relationship between ELU, memory pressure, and I/O saturation

✅ Why Kubernetes autoscalers struggle with Node.js — and where ELU fits in

✅ When worker threads help, and how to reason about ELU across workers

✅ How Kafka client design impacts event loop health and throughput

✅ Why Watt’s architecture aligns naturally with metric-driven scaling in K8s

The big picture?

Metrics shape architecture. If you run Node.js with Kafka on Kubernetes, this episode helps you understand which signals actually reflect load, how to avoid misleading autoscaling decisions, and why Watt was designed around these realities from day one.