Forem: Paolo

Everyone Can Vibe Code. Do You Know What's Under the Hood?

Paolo — Tue, 14 Apr 2026 08:39:08 +0000

A deep dive into Node.js internals — V8, libuv, Turbofan JIT, and why TypeScript is not just about DX.

In the age of vibe coding — where anyone can spin up a full-stack app by chatting with an AI agent — I decided to go against the trend and look down, not up.

Who hasn't seen JavaScript code at this point? It's everywhere. But if today everyone can create software, what sets us developers apart? I'd argue it's understanding why things work, not just that they work.

So I spent a few days digging into TypeScript, Node.js, V8, and libuv at a low level. Here's what I found.

Node.js: A Wikipedia Definition That Tells You Nothing

We all know the textbook one:

Node.js is an open-source, cross-platform, event-driven JavaScript runtime built on Google Chrome's V8 engine.

Cool. But what does that actually mean? How does the most widely used language in the world get executed on a server?

It's C All the Way Down

Here's the first thing that surprised me: Node.js is made of C and C++ programs. And that's not a coincidence.

JavaScript is a web scripting language — it was born inside the browser. By itself, it can't touch your filesystem, open a network socket, or spawn a process. It has no idea what an operating system even is.

So how does it do all of that in Node? Two pieces of software make it happen:

V8 — Google's JavaScript engine, written in C++. It parses, compiles, and executes your JS code.
libuv — a C library that provides asynchronous I/O and acts as the bridge between JavaScript and the operating system.

V8 + libuv = Node.js. That's the whole recipe.

"Single-Threaded" — But Not How You Think

Yes, Node is single-threaded by design. Your JavaScript code runs on one thread — the event loop.

But Node is not limited to a single thread. Under the hood, libuv maintains a thread pool (4 threads by default) to handle blocking I/O operations — things like filesystem reads, DNS lookups, and compression. These run in the background and return results to the event loop when they're done.

On top of that, you can explicitly spawn worker threads or child processes when you need true parallelism.

So the "Node is single-threaded" take is only half the story.

Why TypeScript Is Not Just a DX Choice

In 2026, why would you still write plain JavaScript instead of TypeScript? Many teams adopt TS for the developer experience — autocompletion, refactoring, catching bugs before runtime. That's reason enough.

But there's a deeper, performance-level argument for TypeScript that most people never talk about. It comes down to how V8 compiles your code.

V8's Compilation Pipeline

When V8 runs your JavaScript, it doesn't just interpret it line by line. Here's the simplified flow:

Ignition (interpreter) — parses your code and generates bytecode. Fast startup, slow execution.
Sparkplug — a baseline compiler that produces slightly optimized machine code without heavy analysis.
Turbofan (JIT compiler) — the heavy hitter. It monitors which functions are called often ("hot functions"), profiles their behavior, and compiles them into highly optimized machine code, bypassing bytecode entirely.

The key: Turbofan's optimizations depend on type consistency. If a function always receives the same shapes and types, V8 can make aggressive assumptions and generate fast machine code.

But if the types change mid-execution? V8 has to deoptimize — throw away the optimized code and fall back to the slower bytecode path. This is expensive.

The Code That Proves It

// GOOD: consistent types → Turbofan optimizes aggressively
function addNumbers(a: number, b: number): number {
  return a + b;
}

// V8 sees this function called thousands of times
// always with numbers → marks it as "hot" → compiles to
// optimized machine code
for (let i = 0; i < 100_000; i++) {
  addNumbers(i, i + 1); // always numbers ✓
}

// BAD: inconsistent types → deoptimization
function add(a, b) {
  return a + b;
}

// V8 profiles this, assumes numbers, optimizes...
for (let i = 0; i < 100_000; i++) {
  add(i, i + 1);
}

// ...then this happens:
add("hello", " world"); // string?! → DEOPTIMIZE
// V8 discards the optimized machine code,
// falls back to bytecode interpretation,
// and has to re-profile from scratch

With TypeScript, you're enforcing type consistency at the source level. This means V8's profiler encounters monomorphic call sites — functions that always see the same types — far more often. Turbofan loves this. The result is faster, more stable machine code.

So TypeScript isn't just about catching bugs. It's about giving the engine what it needs to go fast.

TypeScript Helps Your AI Agent Too

Here's a thought that feels very 2026: types don't just help you — they help your AI coding agent.

When an agent generates or modifies code in a typed codebase, the type system acts as a set of guardrails. The agent can't silently pass a string where a number is expected, or return an object with a missing field. The compiler catches it immediately. In an untyped codebase, that same mistake slips through silently and shows up as a runtime bug three days later.

Types are essentially a contract — for humans, for V8, and now for AI agents. The more explicit your codebase is about its intent, the more reliably any contributor (human or not) can work within it.

Why Fundamentals Still Matter

Understanding how things work under the hood isn't just intellectual curiosity. It changes how you write code and how you think about the infrastructure running it.

When you know that libuv has a thread pool of 4, you understand why CPU-heavy tasks can block your Node process. When you know about Turbofan deoptimization, you think twice about writing functions with wildly inconsistent types.

Whether it's you writing the code or your AI agent — understanding what's happening under the surface is what lets you make informed decisions, optimize where it matters, and justify your architectural choices.

Bonus: Node.js Isn't the Only Game in Town

Node isn't the only JavaScript runtime out there. But one that caught my attention recently is Bun.

Bun is an all-in-one toolkit: runtime, test runner, bundler, and package manager — all packed into a single binary. It doesn't use V8. Instead, it's built on JavaScriptCore (the engine behind Safari) and written in Zig, a low-level systems language.

The performance numbers are hard to ignore: startup times around 5ms (vs Node's ~50ms), HTTP throughput up to 2-3x higher, and package installs that are 6-10x faster than npm. It also runs TypeScript natively — no transpilation step needed.

Is it mature enough to replace Node in production? For complex, battle-tested systems with deep dependency trees — probably not yet. But for new projects, CLI tools, or if you're curious and want to experiment with a modern frontend setup, Bun is absolutely worth a look.

Go Deeper

There's a lot more I could cover — the event loop phases, the microtask queue, how async/await interacts with libuv, V8's hidden classes and inline caches. If you have a few hours to spare, I'd encourage you to explore these topics. The deeper you go, the more the pieces connect — and the better engineer you become.

In an era where everyone can generate code, understanding what the code does at the machine level is what makes the difference.

If you found this useful or have anything to add, drop a comment — I'd love to hear what low-level topic you'd dig into next.

I built a Laravel package to stop explaining my database to AI tools every single day

Paolo — Wed, 11 Mar 2026 13:36:23 +0000

Anyone who lives in the software world knows that, even in the AI era, every day we rely on packages built by other developers instead of coding everything from scratch — especially if we want to have a shot at respecting client deadlines, which are always set "a day before yesterday". I'm a Freelance Software Engineer, and like most of us, I had used hundreds of Laravel packages but had never built one myself.

Recently, while working on a client project with a small team, I kept running into the same problem: understanding the database structure across new commits and features was painful, and every time someone changed a migration I had to re-explain the whole schema to my AI tools — what changed, what relationships existed, what columns were added. Repetitive, messy, and honestly quite annoying after the tenth time.

I searched for a package that could help. I didn't find anything that fit my needs. So I did what every developer does when they can't find a solution: complain for a few days, then build it.

Why a package, and why now

Two reasons pushed me over the edge.

The first was practical: I wanted the database structure to be always available as a single exportable file, something an AI agent could read immediately without requiring me to paste half the project into a prompt.

The second was personal: I had been looking for an excuse to go deeper into how Laravel works internally. Building web applications is great, but at some point you want to understand what's happening under the hood, not just consume what the framework provides.

So I opened a new repo, knowing that if I got stuck I could ask my friend Claude.

Designing before writing a single line

Before writing a single line of implementation, I did two things.

First, I went to the Reddit community and asked what actually convinces developers to use a package. The answers were unsurprisingly consistent: clear documentation, a focused scope, good test coverage, a codebase that doesn't make you want to close the tab immediately. Nothing revolutionary, but hearing it directly from real users before building was valuable.

Then I spent time studying other Laravel packages — not to copy them, but to understand what a package built for others to install actually looks like, because it's genuinely different from what you build for yourself. You can't hide the messy parts in a public repo.

Only once the structure was clear in my head did I start implementing. I know AI could have designed it for me, but I didn't want that. I wanted to actually understand it.

The architecture

My main goal was to keep things simple but extendable. Not a script that works for my specific database and breaks the moment someone has a different setup, but something the community could grow over time by adding new formats or integrations.

Two design patterns ended up being a perfect fit for what I needed.

The first is the Strategy Pattern, used for renderers. The package supports multiple output formats like Mermaid diagrams and dbdiagram syntax, and potentially more in the future. Instead of hardcoding the rendering logic inside the core, each format is a separate class implementing a common interface. Adding a new format in the future means adding a new class, nothing more. The core doesn't change.

The second is the Template Pattern, used for the translation process. Even though the output formats are different, the overall process is always the same: analyze the schema, iterate through tables, process columns and relationships, generate the output. Defining this structure once and letting each renderer fill in only its specific parts kept everything consistent without duplicating logic.

Using my friend Claude as a coding assistant

Once the design was locked, I used Claude to speed up the implementation — specifically to write the renderer formats and unit tests. This is where having a clear architecture paid off immediately: with well-defined interfaces and a structured plan, the AI could produce solid code without going off the rails.

To make sure it actually did, I set up a strict set of Composer scripts before writing any implementation: linting, static analysis, 100% type coverage, 100% code coverage, and an auto-refactoring check. Every output had to pass all of them. No exceptions, no "we'll fix it later".

"scripts": {
    "test:lint": "pint --test",
    "test:type-coverage": "pest --type-coverage --exactly=100",
    "test:unit": "pest --coverage --exactly=100",
    "test:types": "phpstan",
    "test:refactor": "rector --dry-run",
    "test": [
        "@test:lint",
        "@test:type-coverage",
        "@test:unit",
        "@test:types",
        "@test:refactor"
    ]
}

This kept both me and my AI friend honest. And it compressed what might have been a week of work into a couple of days, which, given the usual client deadline situation, was exactly what I needed.

What the package actually does

The idea is simple: one command, one file, full database structure in a format your tools can immediately use.

php artisan er:generate

There are three main scenarios where this becomes useful.

The first is giving AI agents database context without going insane. Instead of pasting migrations or manually describing tables at the start of every session, you generate a structured file that contains the full schema. The AI reads it once and has everything it needs — tables, columns, relationships, indexes, all in one place.

The second is database documentation that doesn't require you to actually write documentation. In projects where the schema evolves frequently, having an always-up-to-date exportable reference is genuinely useful — for clients, for new team members, for yourself three months later when you've completely forgotten what that column is for.

The third is visualizing complex schemas without any additional tooling. Mermaid and dbdiagram formats let you render a full ER diagram instantly, which is particularly helpful when onboarding on a legacy project or reviewing a PR that touches fifteen tables at once.

What I actually learned from this

Building a Laravel package is far less intimidating than it appears from the outside. The mechanics are straightforward once you understand how Composer autoloading and service provider discovery work. The harder part is thinking about how other people will use your code, not just how you use it yourself — that shift in perspective is where most of the design decisions live.

The other thing that became very clear very quickly: spending time on architecture before writing code is not wasted time. Every feature I added after the initial structure was in place fit naturally because the extension points were already there. It's one of those things you hear constantly and don't fully believe until you experience it.

This is just the beginning

The package is not perfect, and I'm genuinely fine with that. The goal was never to ship a flawless tool on the first try. It was to understand how Laravel packages work from the inside, and to solve a real problem that was annoying me every single day.

There are already many directions it could go from here: additional export formats, better diagram generation, deeper schema analysis, integration with more AI tools. Open source is also about learning from developers more experienced than you, and I'm genuinely happy to receive contributions, suggestions, or even just someone pointing out that I did something in a completely wrong way.

If you want to try it:

composer require paolobellini/laravel-er

https://github.com/paolobellini/laravel-er