DEV Community: Renato Silva

Git Worktrees: The Missing Piece for Parallel AI Agents

Renato Silva — Mon, 31 Aug 2026 16:38:50 +0000

🔧 The Problem

If you're running more than one AI coding agent at a time — Claude Code in one terminal, Aider in another, maybe a Cursor background agent chewing on a refactor — you've probably hit the same wall: they all want to work on the same repo, but they can't share a working directory without stepping on each other.

The usual workarounds are all bad:

git stash juggling — you stash, switch branches, let the agent work, unstash, repeat. Fine for one agent. A nightmare for three running concurrently, because stash is a single shared stack and agents don't know how to negotiate over it.
Cloning the repo N times — works, but now you've got N full copies of .git, N sets of dependencies to install, and N places for config drift to sneak in. On a large monorepo this is also just slow.
One giant branch with agents committing to subdirectories — merge conflicts waiting to happen, and agents lose the ability to see a clean diff of just their own work.

What you actually want is N independent working directories, backed by one .git, so history, remotes, and object storage stay unified while the checked-out files stay isolated. That's exactly what git worktree gives you, and it's been sitting in Git core since version 2.5 (2015), mostly ignored until "run four agents at once" became a normal Tuesday.

🌳 Worktrees in Practice

The core workflow is boring in the best way:

bash

from your main checkout

git worktree add ../myapp-agent-a feature/agent-a
git worktree add ../myapp-agent-b feature/agent-b
git worktree add ../myapp-agent-c fix/flaky-test

see what's active

git worktree list

/home/dev/myapp abcd123 [main]

/home/dev/myapp-agent-a ef01234 [feature/agent-a]

/home/dev/myapp-agent-b 5678aaa [feature/agent-b]

/home/dev/myapp-agent-c 9911bbb [fix/flaky-test]

Each directory is a real, complete checkout — you can cd into it, run tests, open it in an editor, point an agent at it — and none of them affect each other's index or working tree. Behind the scenes they all share .git/objects, so you're not duplicating blobs, and any commit made in one worktree is immediately visible to git log in the others (once you fetch/checkout).

Cleaning up is just as direct:

bash
git worktree remove ../myapp-agent-c

or, if the agent left the directory dirty and you don't care:

git worktree remove --force ../myapp-agent-c

For an agent-driven workflow, I wrap this in a small script so I'm not hand-typing branch names every time I spin one up:

bash

!/usr/bin/env bash

spawn-agent.sh

set -euo pipefail

task="$1"
branch="agent/${task}"
worktree_path="../$(basename "$(pwd)")-${task}"

git worktree add -b "$branch" "$worktree_path" main
cd "$worktree_path"

per-worktree setup so agents don't fight over node_modules etc.

cp ../.env.example .env
npm install --prefer-offline

echo "Worktree ready at $worktree_path on branch $branch"

Now "give the agent a sandbox" is a single command, and tearing it down after review/merge is another single command. No stash stack, no second clone, no confusion about which branch is checked out where.

⚠️ The Gotchas Nobody Mentions

Worktrees are not a free lunch, and the failure modes are exactly the kind of thing that eats an afternoon if you don't know to look for them.

Shared package manager caches can lie to you. node_modules, .venv, and build caches are not shared between worktrees by default — each one needs its own install. If your agents are installing dependencies in parallel across worktrees pointed at the same global npm/pip cache, you can get lock contention or, worse, a half-written cache entry that silently corrupts a build in a different worktree. Pin a per-worktree cache directory if you're running installs concurrently:

bash
npm install --cache "$(pwd)/.npm-cache"

IDE indexing goes haywire. VS Code, JetBrains IDEs, and language servers built with a single-repo assumption will happily index every worktree directory you open as if it's an unrelated project — which is technically correct but means you're running 4x the TypeScript server memory, 4x the file watchers, and sometimes 4x the "go to definition" confusion if symlinks or path aliases assume a fixed repo root. If you're not actively reading code in a worktree, don't leave it open in the IDE — close the window when the agent is just running headless.

Branches can't be checked out twice. This one bites people immediately: Git will refuse to let two worktrees point at the same branch.

fatal: 'feature/agent-a' is already checked out at '/home/dev/myapp-agent-a'

This is a feature, not a bug — it's the mechanism that prevents two agents from independently committing to the same branch and creating divergent history in two places at once. But it does mean your orchestration script needs a real branch-per-agent naming scheme, not "reuse main for everything."

Detached HEAD surprises. If an agent (or you) checks out a commit instead of a branch, you get a detached HEAD in that worktree — harmless, but if the agent then commits and you forget to create a branch before removing the worktree, git worktree remove will happily let you lose those commits to garbage collection. Always git branch tmp-recovery before tearing down a detached-HEAD worktree you're unsure about.

Submodules and .git hooks need extra care. Hooks live in the shared .git directory by default (or .git/worktrees/<name> for some internals), so a hook that assumes $(pwd) is the repo root can misbehave across worktrees. If you use submodules, git worktree add doesn't initialize them for you — add --recurse-submodules or run git submodule update --init explicitly per worktree.

🚀 Putting It Together

The pattern that's worked well for me running 3-4 agents concurrently:

One "orchestrator" checkout (your normal working directory) that never runs an agent directly — it's just for review and merging.
One worktree per active task, named after the task, not the agent.
A teardown step that force-removes the worktree and deletes the branch once merged, so git worktree list doesn't slowly fill up with zombie sandboxes.

bash
git worktree remove --force ../myapp-agent-a
git branch -d agent/task-a # or -D if the agent's commits got squashed on merge

It's not a glamorous feature — worktrees have existed for a decade specifically for things like hotfix-while-mid-feature workflows — but it maps almost perfectly onto "isolated sandbox per autonomous process" once you swap the human for an agent. The shared object store keeps disk usage sane, and the isolated working trees keep agents from corrupting each other's in-progress edits.

How are you isolating your parallel agents right now — worktrees, containers, or something else entirely? And if you've hit a worktree gotcha that isn't on this list, I'd genuinely like to hear about it in the comments.

SSE vs WebSockets vs Polling: Real-Time Sync From the Backend

Renato Silva — Thu, 27 Aug 2026 19:23:10 +0000

There's been a nice trick going around: use BroadcastChannel in the browser to sync state across tabs without a server round-trip. It's elegant, but it only solves half the problem — it syncs tabs on one device. The moment you have two different users, or one user on a phone and a laptop, you need the server to be the source of truth and push updates out.

So let's flip it: how do you actually push consistent state to N connected clients from a Node API, and which transport should you reach for?

🔧 The Problem

Say you're building something boring and real: a shared cart, a live dashboard, a "someone else is editing this" indicator. Multiple clients need to see the same state change at roughly the same time, without everyone hammering GET /state every 500ms.

You've got three realistic options:

Polling — client asks, server answers, repeat
SSE (Server-Sent Events) — server pushes a one-way stream over plain HTTP
WebSockets — full duplex, server and client both push

Each one has a different cost model, and picking the "cool" one (WebSockets) is often the wrong call.

🐢 Polling: the boring baseline

Polling gets a bad reputation it doesn't fully deserve. It's stateless, trivially horizontally scalable, works through every proxy and CDN ever built, and requires zero special infrastructure.

javascript
// client
setInterval(async () => {
const res = await fetch('/api/state');
const state = await res.json();
renderState(state);
}, 2000);

The honest trade-off: latency is bounded by your interval, and cost scales linearly with (clients × interval). Ten thousand clients polling every 2 seconds is 5,000 requests/sec hitting your server even when nothing changed. Fine for a demo, painful at scale, and it never actually feels "real-time" — there's always a visible lag.

📡 SSE: push, but only one way

SSE is the underrated option. It's just an HTTP response that never closes, with a text protocol on top. No new protocol, no special client library, works over regular HTTP/1.1 and HTTP/2, and reconnects automatically via EventSource.

Here's a minimal Node/Express version that keeps a registry of connected clients and broadcasts state changes:

javascript
import express from 'express';
const app = express();

let state = { count: 0 };
const clients = new Set();

app.get('/events', (req, res) => {
res.set({
'Content-Type': 'text/event-stream',
'Cache-Control': 'no-cache',
Connection: 'keep-alive',
});
res.flushHeaders();

// send current state immediately so late joiners aren't out of sync
res.write(data: ${JSON.stringify(state)}\n\n);

clients.add(res);
req.on('close', () => clients.delete(res));
});

function broadcast(newState) {
state = newState;
const payload = data: ${JSON.stringify(state)}\n\n;
for (const res of clients) res.write(payload);
}

app.post('/increment', express.json(), (req, res) => {
broadcast({ count: state.count + 1 });
res.sendStatus(204);
});

app.listen(3000);

javascript
// client
const source = new EventSource('/events');
source.onmessage = (e) => renderState(JSON.parse(e.data));

That's the whole system. No socket library, no handshake upgrade dance, no ping/pong heartbeat logic to babysit — the browser handles reconnects for you.

The catch: SSE is one-directional. Clients still need a normal POST/fetch to send actions back. For a lot of real apps (dashboards, notifications, live scores, cart sync) that's not a limitation, it's a feature — you get a clean separation between "write path" (REST) and "read/subscribe path" (SSE).

Also worth knowing: browsers cap concurrent EventSource connections per origin (6 over HTTP/1.1), and some corporate proxies buffer streaming responses, which can delay delivery. HTTP/2 mostly fixes the connection-limit problem since it multiplexes over one TCP connection.

🔌 WebSockets: when you actually need two-way

WebSockets are the right tool when the client needs to push frequently too — collaborative editing, multiplayer cursors, chat, game state. Otherwise they're often overkill: you now own a stateful, bidirectional connection with your own reconnect logic, your own heartbeat, and your own message framing.

javascript
import { WebSocketServer } from 'ws';
const wss = new WebSocketServer({ port: 8080 });

let state = { count: 0 };

wss.on('connection', (ws) => {
ws.send(JSON.stringify(state));

ws.on('message', (raw) => {
const msg = JSON.parse(raw);
if (msg.type === 'increment') {
state = { count: state.count + 1 };
const payload = JSON.stringify(state);
for (const client of wss.clients) {
if (client.readyState === client.OPEN) client.send(payload);
}
}
});
});

This works fine on one process. The real cost shows up when you scale horizontally: connections are pinned to whichever server instance accepted them, so a broadcast has to fan out across processes too — usually via Redis pub/sub, NATS, or a managed service like Pusher/Ably. That's infrastructure SSE and polling don't force on you nearly as early.

📊 Honest comparison

	Polling	SSE	WebSockets
Direction	client-pull	server-push (one-way)	bidirectional
Transport	plain HTTP	plain HTTP (streamed)	own protocol over TCP
Reconnect handling	trivial (just retry)	built into `EventSource`	you build it
Horizontal scaling	trivial (stateless)	needs shared client registry	needs pub/sub fan-out
Proxy/firewall friendliness	best	good	can be blocked/downgraded
Good fit	low-frequency, infrequent updates	dashboards, notifications, live state	chat, collab editing, multiplayer

A pattern I keep coming back to: start with SSE for anything that's fundamentally "server tells clients what changed." Only reach for WebSockets once you have a genuine, frequent client-to-server-to-other-clients requirement that a POST + SSE combo can't express cleanly. Polling is still the right call for admin dashboards or anything where a few seconds of staleness is genuinely fine and you'd rather not run a persistent-connection service at all.

🧠 The part that actually matters: consistency, not transport

Here's the thing none of the three options solve for you: what happens when two broadcasts race, or a client reconnects mid-update and misses a message? The transport is the easy 20%. The hard part is designing your broadcast payload so a client can always recover a consistent view — either by sending full state snapshots (like the example above) instead of deltas, or by including a version/sequence number so clients can detect gaps and request a resync.

If you only ever broadcast diffs, a single dropped message means every client after it is silently wrong forever. That's the bug that doesn't show up in your demo and absolutely shows up in production three weeks later.

What's your default pick for this kind of problem — do you reach for SSE first, or do you go straight to WebSockets out of habit? Curious how many people are still shipping raw polling in 2024 and just not talking about it.

Graph Search Isn't Just a LeetCode Trick: BFS in Prod

Renato Silva — Mon, 24 Aug 2026 09:40:56 +0000

Every few months "six degrees of separation" and graph traversal puzzles trend again, and every time the comments split into two camps: people who think BFS/DFS are pure interview theater, and people quietly using them in production without telling anyone. I'm in the second camp. Here's a real feature — "related feedback threads" — built on a boring Node/Postgres stack, where breadth-first search turned out to be exactly the right tool.

🎯 The Setup

We run a support/feedback tool where users can link feedback items to each other: "this is related to that," "this duplicates that," "this was split off from that." Over time these links form a graph. Individually each link is trivial — a row in a join table. But support agents kept asking a very reasonable question:

"If I'm looking at ticket #4521, what's the full cluster of stuff connected to it, even indirectly?"

That's not a JOIN. That's a graph traversal.

🔧 The Problem

Our schema looks like this:

sql
CREATE TABLE feedback (
id SERIAL PRIMARY KEY,
title TEXT NOT NULL,
created_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE feedback_links (
source_id INT REFERENCES feedback(id),
target_id INT REFERENCES feedback(id),
relation TEXT NOT NULL, -- 'related', 'duplicate', 'split_from'
PRIMARY KEY (source_id, target_id)
);

A single feedback item might link to 3 others, each of which links to 2 more, and so on. Agents don't just want direct neighbors — they want the whole connected component up to some reasonable depth, because context that's two or three hops away is often exactly what explains why a bug report and a feature request are secretly the same underlying issue.

The naive fix — recursive JOINs pulled straight into application code with no depth limit — either times out on a dense cluster or returns way more noise than an agent can use in a support ticket sidebar.

🕸️ Modeling Feedback as a Graph

Once you say "connected component up to N hops," you've already described BFS. Depth-first search would work too, but it explores one branch all the way down before backtracking, which is the wrong shape for "show me everything within 3 degrees, closest first." BFS naturally processes nodes in order of distance from the source, which maps directly onto the UI requirement: show closest-related items first, and stop expanding once you hit the depth cap.

🔍 The BFS Implementation

We pull the edges relevant to the starting node's component lazily, level by level, straight from Postgres, and do the traversal logic in Node:

javascript
async function findRelatedFeedback(pool, startId, maxDepth = 3, maxResults = 50) {
const visited = new Set([startId]);
const result = [];
let frontier = [startId];
let depth = 0;

while (frontier.length > 0 && depth < maxDepth && result.length < maxResults) {
const { rows } = await pool.query(
SELECT source_id, target_id, relation FROM feedback_links WHERE source_id = ANY($1) OR target_id = ANY($1),
[frontier]
);

const nextFrontier = [];

for (const row of rows) {
  const neighbor = frontier.includes(row.source_id) ? row.target_id : row.source_id;
  if (!visited.has(neighbor)) {
    visited.add(neighbor);
    nextFrontier.push(neighbor);
    result.push({ id: neighbor, depth: depth + 1, relation: row.relation });
  }
}

frontier = nextFrontier;
depth++;

}

return result;
}

This is textbook BFS with two production-shaped guardrails bolted on: maxDepth so a densely connected cluster can't blow up the response, and maxResults so a single mega-hub node (some "general feedback" catch-all ticket with 200 links) can't turn one API call into a full graph dump. Those two limits are doing more work for user experience than the algorithm itself.

🐘 Doing It in Postgres Instead

You can also push the whole traversal into the database with a recursive CTE, which is worth knowing even if you don't end up using it:

sql
WITH RECURSIVE related AS (
SELECT source_id AS id, 0 AS depth
FROM feedback WHERE id = $1
UNION
SELECT id, 0 FROM feedback WHERE id = $1

UNION ALL

SELECT
CASE WHEN fl.source_id = r.id THEN fl.target_id ELSE fl.source_id END,
r.depth + 1
FROM feedback_links fl
JOIN related r
ON fl.source_id = r.id OR fl.target_id = r.id
WHERE r.depth < 3
)
SELECT DISTINCT id, MIN(depth) AS depth
FROM related
WHERE id <> $1
GROUP BY id
ORDER BY depth;

We tried this first. It's elegant and it's fewer round trips. But recursive CTEs don't cleanly enforce a "stop after N total nodes visited, regardless of depth" limit — you can cap depth, but capping total breadth requires awkward window functions or a hard row limit that can cut off a level halfway through and give you an inconsistent-looking result set. Doing BFS in application code, level by level, gave us a natural point to check "have I collected enough?" between each round trip. More queries, but more control.

⚖️ Complexity Trade-offs at Small Scale

Here's the part that actually matters for a "boring CRUD app with a graph feature" like ours: at our scale (tens of thousands of feedback items, average node degree under 4), textbook BFS complexity of O(V + E) is a non-issue. We're not traversing millions of edges. The real costs are:

Round trips, not Big O. Each BFS level is a network hop to Postgres. At depth 3 that's at most 3 queries, which is fine. If we ever needed depth 10, we'd batch differently or move to a native graph store.
Fan-out nodes, not graph size. The actual risk isn't "the graph is too big," it's "one node has too many neighbors." A single popular feedback thread with 80 links can make one BFS level return more rows than three normal traversals combined. This is why maxResults matters more than maxDepth in practice.
Cycles are silent but real. Feedback links can form loops (A relates to B relates to C relates back to A), and without the visited set, plain recursive traversal would infinite-loop or duplicate work. It's the kind of bug that doesn't show up in a demo with 5 tickets and absolutely shows up once support agents start linking things liberally.

We explicitly did not reach for Neo4j or any dedicated graph database. The join table plus application-level BFS handles our volume with room to spare, and it means one less piece of infrastructure to operate. If our average node degree climbed into the hundreds, or if we needed shortest-path-with-weighted-relations queries across millions of edges, that calculus would flip. Picking the graph database on day one for a feature that queries at most a few thousand edges is optimizing for a scale problem we don't have yet.

🚀 Where This Goes Next

The obvious next step is weighting edges by relation type — a "duplicate" link probably matters more than a "loosely related" one — which turns this from plain BFS into something closer to Dijkstra territory. We haven't needed it yet, but it's a good sign that starting with the simplest correct algorithm leaves you room to grow instead of boxing you in.

Have you shipped a "basic" algorithm like BFS or DFS in a real feature and had people be surprised it wasn't over-engineered? I'd like to hear what problem it solved for you — and whether you eventually outgrew it.

Why I Started Rejecting My Own Giant PRs on a Solo Project

Renato Silva — Thu, 20 Aug 2026 09:28:25 +0000

I don't have teammates on this project. No one is waiting on my PRs, no one is blocked by my branch, and technically I could just push straight to main and call it a day. For about eight months, that's exactly what I did. Then I started opening pull requests against myself, refusing to merge them until they passed a checklist, and my bug count dropped hard enough that I'm never going back.

This isn't a productivity larp. It's a direct response to something I kept doing on a Node.js backend for a side project that grew into something people actually pay for: writing 1,200-line PRs that touched routing, database schema, auth middleware, and a new queue system all at once, then merging them at 1am because "it works locally."

🔧 The Problem

Here's an actual PR title from my own history, from back when I didn't bother with PRs at all, just commits:

commit 4a9f2c1
Author: me

add subscription billing, refactor user model, switch to bullmq, fix cors bug

One commit. Four unrelated concerns. When something broke in production three weeks later — turned out the user model refactor silently changed how email uniqueness was enforced — I had no way to bisect it cleanly. git bisect pointed at a commit that also happened to introduce a queue system, so I spent an hour reading unrelated BullMQ code before I found the actual bug in a Mongoose schema change two files away.

The mega-PR problem people are complaining about on GitHub right now — the 4,000-line diff nobody can meaningfully review — isn't really a GitHub problem. It's a batching problem. Solo devs get it too, we just don't call it a "review bottleneck" because there's no reviewer to bottleneck. The cost shows up later, as debugging tax instead of review tax.

🧩 What Changed

I started treating my own future self as the reviewer. Concretely, that meant three habits, in order of how much they actually helped.

1. One deployable concern per PR

Not one file. One concern. A PR can touch six files if they all serve the same change. It cannot touch six unrelated changes even if it's technically "one file."

Before:

feat: subscription billing, user model refactor, bullmq, cors fix

After, same work, split into four PRs merged over two days:

fix: cors origin whitelist for staging subdomain
refactor: normalize email field before uniqueness check
feat: add BullMQ queue for email jobs (behind flag)
feat: enable Stripe subscription billing on user model

Each of those is independently revertible. When the queue system had a memory leak two weeks later, git revert on one commit fixed it without touching billing.

2. Feature flags instead of long-lived branches

The old instinct was to keep a branch alive for a week while I built something big, then merge it all at once — the exact mega-PR pattern. Now I merge small, working pieces behind a flag, even when the feature isn't done.

javascript
// config/flags.js
const flags = {
QUEUE_EMAIL_JOBS: process.env.FLAG_QUEUE_EMAIL_JOBS === 'true',
};

module.exports = flags;

javascript
// services/emailService.js
const { QUEUE_EMAIL_JOBS } = require('../config/flags');

async function sendWelcomeEmail(user) {
if (QUEUE_EMAIL_JOBS) {
await emailQueue.add('welcome', { userId: user.id });
} else {
await mailer.sendNow(user.email, 'welcome');
}
}

This let me merge the BullMQ integration in small pieces — queue setup, worker process, retry logic — over four separate PRs, none of which changed production behavior until I flipped FLAG_QUEUE_EMAIL_JOBS to true in one final, tiny, easy-to-review PR:

diff

FLAG_QUEUE_EMAIL_JOBS=false
FLAG_QUEUE_EMAIL_JOBS=true

If that broke something, the rollback was a one-line env change, not a git revert across four commits with merge conflicts.

3. A self-review checklist before I hit merge

This is the part that actually changes behavior, because it forces a pause. Mine lives in .github/pull_request_template.md and I fill it out even though I'm the only one who reads it:

markdown

Self-review checklist

[ ] This PR does ONE thing. If I can't summarize it in one sentence, split it.
[ ] No schema change and feature logic in the same PR.
[ ] New code path is behind a flag if it touches billing, auth, or queues.
[ ] I ran this against the staging DB dump, not just local seed data.
[ ] Rollback plan: revert commit / flip flag / neither needed.
[ ] Diff is under ~300 lines, or I have a good reason it isn't.

That last checkbox alone killed most of my mega-PRs. "Under 300 lines" isn't a magic number — it's just small enough that I can actually reread the whole diff in one sitting and notice the thing I got wrong, instead of skimming because I already know what I meant to write.

📉 Before / After, With Real Numbers

I pulled stats from my own git log across a 3-month window before and after adopting this.

	Before	After
Avg lines changed per PR	640	145
Production incidents traced to a merge	6	1
Time to `git bisect` a regression	~45 min avg	~8 min avg
PRs reverted in full	3	0 (partial reverts only)

The incident count matters most. Five of those six "before" incidents were bugs sitting quietly inside a large diff, unrelated to the actual thing I thought I was shipping. Smaller diffs didn't make me a better programmer overnight — they just made my mistakes smaller and easier to isolate.

🚦 Where I Still Cut Corners

I'm not going to pretend this is pure discipline. Genuine one-off scripts, migrations I'll run exactly once, or throwaway debug endpoints still go straight to main sometimes. The checklist is for anything touching auth, billing, data integrity, or anything a customer would notice if it broke. Applying full ceremony to a typo fix in a README would just be theater.

🙋 Your Turn

If you're a solo dev or work on a small team with light review culture — do you actually PR your own work, or is main still your review process? I'm curious whether feature flags feel like overhead to people working on smaller CRUD apps versus something like billing or queues where the blast radius of a bad merge is bigger.

Drop your workflow in the comments, especially if you've got a better checklist item than mine — I'm always looking to steal a good one.

Your API Doesn't Have an AI Problem, It Has a Design Problem

Renato Silva — Wed, 19 Aug 2026 19:48:44 +0000

Every week there's a new post about "adding AI to your API" — a chat endpoint, a summarization feature, an autocomplete widget. And every week, teams discover the same thing: the AI feature isn't the hard part. The hard part is that their API was never designed to answer real questions in the first place.

AI doesn't create bad architecture. It just puts a spotlight on it and asks it to perform live, in front of an audience.

🔥 The Pattern Nobody Wants to Admit

Here's the usual sequence:

Team builds a CRUD API around whatever tables were easiest to model.
Product asks for an AI feature — "summarize customer sentiment," "suggest a response," "cluster similar feedback."
Engineering discovers the API can't answer "similar to what?" or "sentiment over what time window, grouped how?" without a pile of N+1 queries, ad hoc joins, or a background job nobody wants to own.
Someone ships a /ai/summarize endpoint that quietly does three database round trips, a Python script, and a prayer.

The AI didn't break the system. The AI just needed the system to answer real, compositional questions — and it turns out the system was only ever designed to answer "give me row 42."

🧩 Case Study: minimalist-feedback-api

Let's make this concrete with a small, honest example — a feedback API that looks totally reasonable at first glance.

sql
CREATE TABLE feedback (
id SERIAL PRIMARY KEY,
message TEXT NOT NULL,
rating INTEGER,
submitted_at TIMESTAMP DEFAULT now(),
user_email TEXT
);

And the API surface:

http
GET /feedback
GET /feedback/:id
POST /feedback
DELETE /feedback/:id

This is fine for a v1. It's minimal, it's CRUD, it ships fast. The problem is what it's missing: there's no concept of a category, no tags, no source (web, mobile, support ticket), no status (new, triaged, resolved), and no relationship to a product area or feature. rating is a bare integer with no scale documented anywhere except a Slack message from eight months ago.

Nobody complained, because the only client was an admin dashboard doing SELECT * FROM feedback ORDER BY submitted_at DESC LIMIT 50.

🤖 Where the AI Feature Broke Everything

Then someone asks for: "Can we get an AI summary of feedback trends by feature area, this week vs. last week?"

Suddenly every missing modeling decision becomes a blocking issue:

There's no feature_area, so the LLM prompt starts doing keyword matching on free text ("if message contains 'checkout'...") — which is just a worse, slower, non-deterministic version of a foreign key.
rating isn't validated or scaled consistently, so "average sentiment" is comparing 1–5 stars against some rows where someone typed -1 two years ago and it never got caught.
There's no submitted_at index strategy for range queries, so "this week vs last week" becomes two full table scans through a text-heavy table, on every request, because there's no caching layer and no aggregation endpoint either.
The endpoint that gets built to serve this, /ai/summary, ends up doing the query, the grouping, the prompt construction, and the LLM call all inline, with no separation between "fetch relevant data" and "generate summary," which means you can't cache the first part or test it independently of the model.

http
GET /ai/summary?range=week

{
"summary": "Feedback improved slightly...",
"note": "best effort, based on keyword matching, may be wrong"
}

That note field is the tell. It's an apology baked into the response schema.

🛠 The Actual Fix: Model the Domain, Not the Table

The fix has almost nothing to do with AI. It's the modeling work that should have happened before anyone typed CREATE TABLE.

sql
CREATE TABLE feedback (
id SERIAL PRIMARY KEY,
message TEXT NOT NULL,
sentiment_score NUMERIC(3,2), -- normalized -1.0 to 1.0, computed once
source TEXT NOT NULL, -- 'web', 'mobile', 'support'
feature_area_id INTEGER REFERENCES feature_areas(id),
status TEXT NOT NULL DEFAULT 'new',
submitted_at TIMESTAMP NOT NULL DEFAULT now(),
user_id INTEGER REFERENCES users(id)
);

CREATE INDEX idx_feedback_submitted_at ON feedback (submitted_at);
CREATE INDEX idx_feedback_feature_area ON feedback (feature_area_id);

And the endpoint set stops being pure CRUD and starts modeling actual questions people ask:

http
GET /feedback?feature_area=checkout&since=2024-05-01&until=2024-05-08
GET /feedback/aggregate?group_by=feature_area&range=week
GET /feature-areas/:id/trend?window=30d

Notice what changed: the aggregation is a first-class resource (/feedback/aggregate), not something invented inline inside an AI endpoint. Now the AI feature is almost boring:

python
def generate_weekly_summary(feature_area_id: int) -> str:
trend = api.get(f"/feature-areas/{feature_area_id}/trend?window=7d")
prompt = build_summary_prompt(trend) # deterministic, testable
return llm.complete(prompt)

The LLM call is now the last step, operating on well-shaped, pre-aggregated, already-correct data. If the summary is wrong, you can tell immediately whether it's a data problem or a prompting problem — because they're separated.

📐 What Good Looks Like

A few concrete rules that fall out of this case study, not as abstract principles but as things you can check in a PR review:

If an AI feature needs a join your API can't express, that join was always missing. The AI request just made it visible faster than a human analyst would have.
Aggregation endpoints are not optional sugar. /resource/aggregate or /resource/:id/trend should exist before anyone builds a summarization feature on top, not as a side effect of building one.
Free text fields are where schema debt hides. message being a TEXT blob is fine; using string matching against it as a substitute for a feature_area_id is a design smell wearing an AI costume.
Normalize before you summarize. If rating or sentiment_score isn't validated at write time, no amount of prompt engineering downstream will make the aggregate trustworthy.
Keep the retrieval and the generation separate, and testable separately. If your only way to verify the LLM's output is to eyeball it, you've merged two very different failure modes into one.

None of this is AI-specific advice. It's just API design discipline that AI features are unusually good at exposing, because they demand compositional answers instead of row lookups.

💬 Over to You

If you added an AI feature to an existing API recently — what actually broke first? Was it the schema, the missing aggregation layer, or something in how endpoints were shaped around CRUD instead of around the questions people actually ask?

The uncomfortable version of this post is: if the AI feature made your API look bad, the API was already bad. AI is just an unusually blunt code reviewer.

Rate Limiting Lessons From a 100K-Request Meltdown

Renato Silva — Fri, 14 Aug 2026 20:05:16 +0000

🔥 The Story That Made Every Backend Dev's Stomach Drop

You probably saw it: a developer shipped a React component with a useEffect that had a missing dependency array (or a state update that retriggered itself), and it quietly hammered their API with over 100,000 requests before anyone noticed. No malicious actor, no botnet — just a bracket in the wrong place and a hook that fired on every render.

The internet had a good laugh, but every backend dev reading that thread had the same intrusive thought: "my API would've just... died."

That's the uncomfortable truth. A self-inflicted traffic spike from a buggy client is functionally indistinguishable from a DDoS if your server has no defenses. The fix isn't "tell frontend devs to be careful" — it's "assume they won't be, and build accordingly."

This post walks through the three layers I now consider non-negotiable for any Node/Express API: token-bucket rate limiting, circuit breakers, and defensive defaults. I'll also talk about a real (much smaller, thankfully) spike that hit my side project, minimalist-feedback-api, and what actually saved it.

🪣 Why Token Bucket Beats Fixed Windows

Most people's first rate limiter is a fixed window: "100 requests per minute per IP." It's easy to reason about and easy to implement badly. The problem is the boundary. If your window resets at :00, a client can send 100 requests at 11:59:59 and another 100 at 12:00:01 — 200 requests in two seconds, technically "within limits."

Token bucket fixes this by modeling capacity as a continuously refilling resource instead of a hard reset:

js
// tokenBucket.js
class TokenBucket {
constructor({ capacity, refillRatePerSec }) {
this.capacity = capacity;
this.tokens = capacity;
this.refillRate = refillRatePerSec;
this.lastRefill = Date.now();
}

_refill() {
const now = Date.now();
const elapsedSec = (now - this.lastRefill) / 1000;
const refillAmount = elapsedSec * this.refillRate;
this.tokens = Math.min(this.capacity, this.tokens + refillAmount);
this.lastRefill = now;
}

tryConsume(cost = 1) {
this._refill();
if (this.tokens >= cost) {
this.tokens -= cost;
return true;
}
return false;
}
}

module.exports = TokenBucket;

Then the Express middleware, keyed per client (IP, API key, whatever identifies the caller):

js
// rateLimitMiddleware.js
const TokenBucket = require('./tokenBucket');

const buckets = new Map();

function getBucket(key) {
if (!buckets.has(key)) {
buckets.set(key, new TokenBucket({ capacity: 20, refillRatePerSec: 2 }));
}
return buckets.get(key);
}

function rateLimit(req, res, next) {
const key = req.ip; // swap for API key if you have auth
const bucket = getBucket(key);

if (bucket.tryConsume(1)) {
return next();
}

res.status(429).set('Retry-After', '1').json({
error: 'Too many requests. Slow down.',
});
}

module.exports = rateLimit;

The key insight: capacity 20 with a refill rate of 2/sec means a client gets a burst allowance (handles legitimate rapid-fire usage like a form autosave) but can't sustain more than 2 requests/sec indefinitely. That's exactly the shape of a runaway useEffect loop — it doesn't send 100 requests once, it sends them in a tight, sustained burst. Token bucket catches that pattern where a naive fixed window might not, depending on where the boundaries land.

For anything beyond a single process, don't keep buckets in memory — use Redis (via something like rate-limiter-flexible) so limits survive restarts and work across horizontally scaled instances. In-memory Map is fine for a single-instance side project; it's a liability the moment you run two replicas behind a load balancer, because each instance tracks its own bucket and your effective limit doubles per replica.

🧯 Circuit Breakers: The Second Line of Defense

Rate limiting protects your API from too many incoming requests. Circuit breakers protect your API (and its downstream dependencies) from cascading failure once something's already struggling — usually a database, a third-party API, or an internal service call that's gone slow or unresponsive.

Here's the pattern with opossum, a solid circuit breaker library for Node:

js
const CircuitBreaker = require('opossum');
const db = require('./db');

async function fetchFeedback(id) {
return db.query('SELECT * FROM feedback WHERE id = $1', [id]);
}

const breakerOptions = {
timeout: 3000, // fail fast after 3s
errorThresholdPercentage: 50, // trip if 50% of requests fail
resetTimeout: 10000, // try again after 10s
};

const breaker = new CircuitBreaker(fetchFeedback, breakerOptions);

breaker.fallback(() => ({ error: 'Feedback service temporarily unavailable' }));

app.get('/feedback/:id', async (req, res) => {
const result = await breaker.fire(req.params.id);
res.json(result);
});

Without this, a slow database under load doesn't just cause slow responses — it causes request pileup. Every incoming request holds a connection open waiting on a query that's never coming back fast enough, you exhaust your connection pool, and now healthy requests fail too. The circuit breaker trips, starts returning fast fallbacks immediately, and gives the database room to recover instead of getting buried under retries.

Rate limiting stops the flood at the door. Circuit breakers stop one struggling dependency from taking the whole system down with it. You want both — they solve different failure modes.

🛡️ Defensive Defaults I Now Bake Into Every Express API

Beyond the two big patterns above, there's a checklist of small things that cost nothing to add and save you on a bad day:

js
const express = require('express');
const helmet = require('helmet');
const compression = require('compression');

const app = express();

// Cap body size — don't let a malformed client send you a 500MB payload
app.use(express.json({ limit: '100kb' }));

// Basic security headers
app.use(helmet());

// Compress responses to reduce bandwidth under load
app.use(compression());

// Global request timeout so nothing hangs forever
app.use((req, res, next) => {
res.setTimeout(10000, () => {
res.status(503).json({ error: 'Request timed out' });
});
next();
});

// Always have a catch-all error handler, even if it feels redundant
app.use((err, req, res, next) => {
console.error(err);
res.status(500).json({ error: 'Something went wrong' });
});

None of this is exciting. That's the point — defensive defaults are boring on purpose. The bracket-typo story went viral precisely because the API had no boring safety net, and 100,000 requests met zero resistance.

📈 The Day minimalist-feedback-api Got Hit

minimalist-feedback-api is a small feedback-collection service I built as a learning project — nothing fancy, just an endpoint for apps to POST feedback and a dashboard to read it. It's not built to handle enterprise traffic, but I treated it like production because that's where you actually learn this stuff.

A few months in, one integrator's frontend had a retry loop with no backoff — every failed request immediately retried, and a brief blip in their own network turned into a sustained burst against my /feedback endpoint. It wasn't 100,000 requests, but it was enough (a few thousand in under a minute) to be a real stress test.

What actually saved it wasn't anything clever — it was the boring stuff: the token bucket limiter returned 429s immediately instead of letting requests queue up, the body size cap meant even the retries were cheap to reject, and the circuit breaker around my database call meant the brief connection pressure never turned into a full outage. The service degraded gracefully (some legitimate requests got 429'd too) instead of falling over entirely. That's the tradeoff you're signing up for: rate limiting means occasionally rejecting a request that would've been fine, in exchange for never going fully down.

🤔 What Would Your API Do?

Honestly ask yourself: if a client-side bug sent your busiest endpoint 100,000 requests in five minutes right now, what would happen? Would it 429 gracefully, or would your database connection pool just... give up?

If you're not sure, that uncertainty is the signal to add a rate limiter today — even a basic one. It's a couple hours of work that turns a viral "oops" story into a boring non-event. What's your go-to rate limiting setup, and have you ever had a spike (accidental or not) actually test it for real? I'd love to hear the war stories in the comments.

I Stopped Trusting AI Agents With My API

Renato Silva — Fri, 14 Aug 2026 19:51:29 +0000

🤖 The Problem

A few weeks ago I wired an LLM agent up to minimalist-feedback-api, my little side project for collecting product feedback. The pitch to myself was simple: let a support-bot agent read feedback threads and occasionally write a triage note or close a stale ticket, without me manually reviewing every call.

It took about two days for the agent to do something I didn't ask for.

Nothing catastrophic — it bulk-updated the status of a dozen feedback items because it decided, on its own, that they were "resolved" based on a fuzzy read of the conversation. Technically it used an endpoint I'd exposed to it. Technically the request was authenticated. But nobody had actually agreed that an agent should be allowed to do bulk writes, and there was no record of why it thought that was a good idea.

That's the part that got me. With a human client, a bad API call is a bug. With an agent, a bad API call is a decision, made by a system that can also decide to make it again, faster, in a loop, at 3am.

So I stopped trusting agents with the same trust model I give human-driven clients, and built a gatekeeper middleware specifically for tool-calling traffic.

🔐 What "Trust" Even Means for an Agent

Before writing code, I had to get concrete about what I was actually worried about. It came down to three things:

Scope — an API key belonging to "the support agent" should not be able to call every write endpoint just because it's authenticated.
Rate — agents don't get bored or embarrassed. A misbehaving loop can hit your API way harder than a person ever would.
Audit — when something weird happens, I need to reconstruct not just what was called, but which agent, with what identity, doing what it claimed to be doing.

Regular auth middleware answers "who are you." This needed to answer "are you allowed to do this specific thing, right now, at this rate, and is someone going to know about it."

🏗️ The Shape of the Middleware

minimalist-feedback-api has a handful of write endpoints: create feedback, update status, delete feedback, bulk operations. I treated agent access as a distinct concern from normal API auth — it sits after authentication and before the route handler.

js
// middleware/agentGatekeeper.js
const agentScopes = {
'agent:support-triage': ['feedback:update-status', 'feedback:read'],
'agent:analytics-readonly': ['feedback:read'],
};

function requireAgentScope(action) {
return (req, res, next) => {
const agentId = req.headers['x-agent-id'];
const agentToken = req.headers['x-agent-token'];

if (!agentId) {
  // Not an agent request, let normal auth handle it
  return next();
}

if (!verifyAgentToken(agentId, agentToken)) {
  return res.status(401).json({ error: 'invalid agent credentials' });
}

const allowed = agentScopes[agentId] || [];
if (!allowed.includes(action)) {
  return res.status(403).json({
    error: `agent '${agentId}' is not scoped for action '${action}'`,
  });
}

req.agent = { id: agentId, action };
next();

};
}

module.exports = { requireAgentScope };

The key decision here: scopes are actions, not endpoints. feedback:update-status and feedback:delete are separate permissions even though they might hit similar routes, because "update a status field" and "permanently delete a record" are very different risk levels. My support-triage agent gets the former, never the latter. No agent in this system currently has delete access, on purpose — if it needs to happen, a human does it.

🚦 Rate-Limiting Per Agent, Not Per IP

Standard rate limiters key off IP address, which is close to useless for agents — they usually run from the same handful of server IPs as your other backend traffic. I keyed limiting off the agent identity instead, with tighter windows than I'd ever apply to a human-facing key:

js
const rateLimit = require('express-rate-limit');

Five writes a minute felt aggressive when I set it, but it's forced something useful: if the agent legitimately needs to do more than that, it should be batching its reasoning into fewer, larger, more deliberate calls — not firing off a write per sentence of its own chain of thought.

📝 Auditing: The Part I Actually Use Every Day

Scopes and rate limits prevent damage. The audit log is what lets me trust the system incrementally instead of all-or-nothing. Every agent-originated write gets logged with enough context to answer "why did this happen" without me guessing:

js
function auditAgentWrite(req, res, next) {
const original = res.json.bind(res);
res.json = (body) => {
if (req.agent) {
logAgentEvent({
agentId: req.agent.id,
action: req.agent.action,
method: req.method,
path: req.originalUrl,
requestBody: req.body,
statusCode: res.statusCode,
timestamp: new Date().toISOString(),
});
}
return original(body);
};
next();
}

Wiring it all together on a real route looks like this:

js
router.patch(
'/feedback/:id/status',
requireAgentScope('feedback:update-status'),
agentWriteLimiter,
auditAgentWrite,
updateFeedbackStatus,
);

The log entries go to a plain table (agent_audit_log) rather than a generic app log stream, because I wanted to query it directly: "show me every write agent:support-triage made in the last 24 hours" is a query I actually run now, especially after a prompt or model change.

⚖️ Trade-offs I'm Consciously Accepting

This isn't zero-cost. Static scope tables mean I have to redeploy to change what an agent can do — I'm fine with that friction on purpose, because "redeploy to expand agent permissions" is a feature, not a bug, at this stage. A more dynamic, database-backed scope system would remove the friction and also remove the forcing function that makes me think twice.

I also don't do anything fancy with the audit data yet — no anomaly detection, no auto-revocation. It's a log I read. That's deliberately unglamorous; I'd rather have a boring, reliable trail than a clever system I don't fully understand when it fires.

🙋 Over to You

If you're letting an agent call real write endpoints today, what's actually stopping it from doing something scoped, rate-limited access wouldn't have caught anyway? I'm curious whether people are seeing failure modes that permission systems can't touch — like an agent staying within scope but still making bad judgment calls.

Happy to share the full minimalist-feedback-api gatekeeper module if there's interest — it's small enough to drop into most Express projects in an afternoon.

Is Node.js Losing Its Crown? The Rise of Bun, Deno, and Native Runtimes

Renato Silva — Mon, 10 Aug 2026 09:26:08 +0000

For more than a decade, if you wanted to build a JavaScript or TypeScript backend, there was only one real answer: Node.js.

It revolutionized web development, gave birth to the massive npm ecosystem, and powered millions of applications worldwide. But nothing in tech stays static forever.

In recent times, we’ve seen a massive shift. Developers are no longer taking Node.js for granted. Tools like Bun and Deno are no longer experimental projects—they are mature, production-ready runtimes that are directly challenging the king.

Why is this happening, and should you consider switching your next project away from Node.js?

1. The Speed Dilemma (Zig & Rust vs. C++)

Node.js is built on top of Google's V8 engine and C++. It’s fast, but it carries over 15 years of legacy architecture.

Deno was created by Ryan Dahl (the original creator of Node.js!) using Rust to fix the security and architectural design flaws he regretted in Node.
Bun was built from scratch using Zig and the JavaScriptCore engine (from Safari), specifically optimized for raw speed, lower memory footprint, and instantaneous cold starts.

When you run benchmarks on HTTP server throughput, package installation speeds, or file I/O operations, Bun often leaves Node.js in the dust. Running bun install feels like a magic trick compared to npm install.

2. All-in-One Tooling vs. "Tooling Fatigue"

To build a modern TypeScript backend in Node.js, you usually need a constellation of extra tools:

tsc or esbuild for TypeScript compilation.
tsx or ts-node for running scripts during development.
dotenv for environment variables.
Jest or Vitest for running tests.

Bun and Deno completely eliminate this friction.

Both runtimes feature native TypeScript support out of the box—no transpilation step required. They include built-in test runners, environment variable support, and even native bundlers. You clone a project, run one command, and everything just works.

3. The Counter-Attack: Node.js Isn't Standing Still

If you think the Node.js core team is sitting idly by, think again. The competition from Bun and Deno has been the best thing to happen to Node.js in years!

Node.js has been aggressively shipping modern features to stay competitive:

Native .env file parsing support.
Built-in test runner (node --test).
Experimental support for running TypeScript files directly.
Significant performance improvements in HTTP and file system operations.

Node’s biggest superpower remains its unmatched ecosystem and stability. Enterprise companies with millions of lines of code aren't going to migrate away from Node.js overnight just for a few milliseconds of performance gain.

The Verdict: Which One Should You Use?

Use Node.js if you are building enterprise applications where long-term stability, massive community support, and ecosystem compatibility are non-negotiable.
Use Bun if you are building high-performance microservices, CLI tools, or want an insanely fast development cycle with zero-config TypeScript.
Use Deno if security, strict web-standard APIs, and modern runtime architecture are your top priorities.

The "monopoly" of Node.js is over, and that’s a win for all developers. Competition breeds innovation.

What about you?

Have you tried Bun or Deno in production, or are you sticking with Node.js for your daily work? What’s keeping you from making the switch?

Drop your thoughts and benchmarks in the comments below! ⚡👇

How to Survive a Live Coding Interview Without Having a Panic Attack

Renato Silva — Sun, 28 Jun 2026 15:16:40 +0000

It’s the moment every developer dreads.

You passed the initial screening, you know your tech stack inside out, and now you’re sitting on a Zoom call. The interviewer drops a link to a shared editor and says: "Alright, here is the problem. Please share your screen and code the solution while explaining your thought process."

Suddenly, your hands start sweating. Your mind goes completely blank. You forget how a basic for loop works, and you start questioning if you even know how to program at all.

If you have ever experienced this, let me tell you a secret: You are not a bad developer. Live coding is just a fundamentally unnatural way to write software.

Here is a survival guide on how to manage the anxiety, prepare effectively, and turn the interview into a conversation rather than an interrogation.

1. Shift Your Mindset: It’s Not About the Solution

The biggest mistake candidates make is thinking that if they don’t finish the code or if it has a small bug, they failed.

In 90% of professional tech interviews, the interviewer cares much more about how you think than whether you get a 100% perfect syntax on the first try. They want to see:

How do you react when you get stuck? (Do you panic, or do you ask questions?)
Can you break a big problem into smaller pieces?
Are you pleasant to work with?

Remember: They are looking for a future colleague, not a compiler.

2. The "Think Out Loud" Framework (Your Superpower)

Silence is your worst enemy during a live coding session. If you are silent, the interviewer has no idea if you are thinking of a brilliant solution or completely lost.

Force yourself to speak. Explain your chaotic thoughts:

"Okay, I’m thinking we need to filter this array first, but since the data structure is nested, I might need to normalize it. Let me try a simple approach first, and we can optimize it later."

If you say this out loud, two amazing things happen:

It slows your heart rate down because you are pacing yourself.
If you are going down a completely wrong path, a good interviewer will usually drop a hint to guide you back ("That makes sense, but what if the array is empty?").

3. The Practical Checklist to Stay Calm

Ask Clarifying Questions First: Never start typing immediately. Spend the first 3 minutes asking about edge cases. "Can the input be null?", "Should this handle negative numbers?" This gives your brain time to calm down and process the problem.
Write Pseudo-code: Before writing syntax, write comments.
```
// 1. Get the category ID from the input
// 2. Check if the category exists in the database
// 3. Return error or proceed
```
This gives you a roadmap. If you freeze mid-way, you just need to look at your next comment.
Admit What You Don't Know: If you forget a specific JavaScript method name, don't fake it. Say: "I can't recall the exact native method name for this right now, so I'm going to create a placeholder function/variable called formatData and come back to it." Interviewers respect this level of honesty.

4. How to Actually Prepare (Without Burning Out)

Don't just grind 500 LeetCode problems. That will only increase your anxiety. Instead:

Practice talking while coding: Open an old project or a simple challenge, record yourself on Zoom, and force yourself to explain your code out loud to an empty room. It feels silly, but it builds the muscle memory.
Mock Interviews: Ask a developer friend to give you a random problem and watch you solve it for 30 minutes.

Live coding is a performance. And just like any performance, the more you practice the act of performing, the less terrifying it becomes.

Over to you...

What is your relationship with live coding interviews? Do you think they are a valid way to test a developer's skills, or should the industry ban them forever?

Share your worst (or best) interview stories in the comments! 👇

Your node_modules is Heavier Than a Black Hole (And How to Fix It)

Renato Silva — Tue, 16 Jun 2026 18:16:30 +0000

We’ve all seen the meme: a black hole, a highway collapsing, or the universe warping under the unimaginable weight of a single folder named node_modules.

It used to be a joke. Today, it’s a production hazard.

If you create a fresh project using some modern meta-frameworks or tools, before you even write your first console.log(), you already have tens of thousands of files sitting in your directory. We have reached a point where we need thousands of external packages just to render text on a screen or route a basic HTTP request.

How did the JavaScript ecosystem become so heavily dependent on others, and why is this breaking modern software engineering?

The "Left-Pad" Trauma and the Security Nightmare

A few years ago, the internet famously broke because a developer unpublished a tiny 11-line package called left-pad. Today, the problem is much worse, but it’s silent. It hides under the name of Supply Chain Attacks.

When you install a major framework, you aren't just trusting that framework. You are trusting the hundreds of anonymous open-source developers who wrote the micro-dependencies that the framework relies on.

Every time you run npm install, you are playing roulette with:

Malicious packages disguised as typos.
Deprecated code running in your production environment.
The infamous Found 87 vulnerabilities (12 critical) message that nobody actually knows how to completely clear.

The Art of "No-Dependency" Coding

A silent revolution is happening. Senior developers are actively looking at their package.json and asking: "Can I write this myself in 10 lines of code instead of installing a 5MB package?"

Modern runtimes like Node.js (with its native test runners and .env support), Bun, and Deno are trying to cure this sickness by built-in tools that eliminate the need for basic third-party utilities.

Look at our backend stacks:

Do you really need a massive utility library just to capitalize a string or filter an array? No, native JavaScript array methods are incredibly fast now.
Do you need a dependency to format a date? Often, the native Intl.DateTimeFormat API does exactly what you want.

Keeping your code close to the metal (or native to the runtime) makes your application faster, secure, and infinitely easier to upgrade.

Finding the Sweet Spot

Don't get me wrong. I am not saying you should build your own ORM instead of using Prisma, or rewrite Fastify from scratch. Frameworks and complex tools solve massive, hard problems, and they deserve to be in your project.

The problem is the micro-dependency addiction. Installing an entire package just to check if a number is even (yes, is-even is a real package with millions of downloads) isn't smart engineering—it's laziness.

The next time you are tempted to run npm install <package>, take 2 minutes to think: Can I write a simple, typed function to handle this? Your deployment speed, your security team, and your laptop's hard drive will thank you.

Time to confess...

What is the most ridiculous, tiny package you have ever found buried deep inside your node_modules? Are we too lazy to write plain JavaScript/TypeScript nowadays?

Let’s discuss (and share our dependency horror stories) below! 📦👇

How I Stopped Losing Track of Clients, Invoices, and Money as a Freelancer (And the System I Built to Fix It)

Renato Silva — Wed, 10 Jun 2026 16:29:42 +0000

If you've been freelancing for more than a few months, you know the feeling: a client emails asking about an invoice you're not sure you sent. A project deadline sneaks up because it was buried in a note somewhere. You check your bank account and can't tell if that deposit was from the March project or the April one.

It's not that you're disorganized. It's that freelancing forces you to be a designer AND an accountant AND a project manager AND a sales team — all at once, with no system holding it together.

I spent way too long managing my freelance work across scattered tools: spreadsheets for invoices, a to-do app for tasks, email threads for client info, a notes app for project details. Everything lived somewhere different, and nothing talked to anything else.

So I built a system in Notion that connects everything into one workspace. Here's the framework behind it — whether you use my template or build your own.

The 5 things every freelancer needs to track

After trying dozens of setups, I landed on five core areas. Not more, not less. Every piece of freelance admin falls into one of these:

1. Clients

Not just names and emails — you need to see a client's full picture at a glance. Are they a lead, active, or past? What's their rate? What projects have you done for them? What invoices are outstanding?

Most freelancers track this in their head until they have 5+ clients. Then things start slipping.

The fix: A single client database where every client links to their projects and invoices. You click on "Acme Co" and see everything — every project, every invoice, every payment — without searching.

2. Projects

Every piece of work needs a status (not started, in progress, completed, on hold), a deadline, a fee, and a connection to the client who's paying for it.

The key insight: projects aren't tasks. "Website Redesign" is a project. "Design the homepage" is a task inside that project. Mixing these up is why most freelancer to-do lists become unusable.

The fix: A project pipeline with both a table view (for detail) and a kanban board (for a visual overview of what's where). Each project links to its client.

3. Tasks

The daily work. Each task belongs to a project, has a priority, a due date, and a status. You need two views: a flat list for "what do I need to do today?" and a board for dragging things between To Do, In Progress, and Done.

The fix: A task database linked to projects, with a kanban board view. Filter by "not done" and you have your daily action list.

4. Invoices

This is where most freelancers lose money — literally. You finish a project, forget to invoice for two weeks, then can't remember the exact amount or what it was for.

Every invoice should link to both the client AND the project, have a clear status (draft, sent, paid, overdue), and show the amount and dates.

The fix: An invoice tracker that connects to both clients and projects. You can see all unpaid invoices in one view, and every invoice traces back to the work it covers.

5. Finances

Income and expenses in one place. The critical feature most freelancers miss: linking income entries to their invoices. When a payment lands, you mark which invoice it covers. Now you can trace the full path: Client → Project → Invoice → Payment.

Expenses get tracked separately with categories (software, marketing, education, office). Come tax time, you have everything in one place instead of scrolling through bank statements.

The fix: A finance database with income linked to invoices, and expenses categorized. You can see your net position at any time without opening a spreadsheet.

Why connected databases matter

The magic isn't in any single database — it's in the links between them. When you click on a client, you see their projects. Click a project, you see its tasks and invoices. Click an invoice, you see the payment.

This means:

You never lose track of what you owe or what you're owed
Every task traces back to a project and a paying client
Your finances connect to real work, not just anonymous numbers
Status changes in one place make sense everywhere else

If you've tried building something like this in spreadsheets, you know it falls apart fast. Spreadsheets don't link. Notion does.

The system I built

I put this exact framework into a Notion template called Freelance OS. It has all five databases pre-built and connected, filled with sample data so you can see how it works before swapping in your own info.

It includes:

Client manager with status tracking
Project pipeline (table + kanban)
Task manager with priority levels and board view
Invoice tracker linked to clients and projects
Finance tracker with income linked to invoices
Setup guide to get running in 5 minutes

It works on Notion's free plan and takes about 5 minutes to set up.

If you want to skip building this yourself: Get Freelance OS here

Or build your own

If you prefer to build it yourself, here's the order that works best:

Clients first — this is the foundation everything links to
Projects second — add a relation column pointing to Clients
Tasks third — add a relation column pointing to Projects
Invoices fourth — add relations to both Clients AND Projects
Finances last — add a relation to Invoices for income entries

Build in this order because each database links to the one before it. If you try to build finances first, you'll have nothing to connect it to.

The most important Notion feature to learn: relations and rollups. Relations link databases. Rollups pull data from linked entries (like summing all invoice amounts for a client). These two features turn five separate tables into one connected system.

The takeaway

Freelancing doesn't have to mean chaos. The moment you connect your clients to your projects to your invoices to your money, everything gets simpler. You spend less time on admin and more time on the work that actually pays.

Whether you build this yourself or grab the template, the framework is the same: five databases, all connected, one home for everything.

If you found this useful, I'm building more tools for freelancers. Follow me here or check out Freelance OS on Gumroad.

The Cloud is a Scam (For 90% of Your Projects)

Renato Silva — Mon, 08 Jun 2026 20:10:15 +0000

For the past seven years, we’ve been brainwashed into believing that if your app isn’t deployed across multiple AWS availability zones, using serverless functions, and managed via an intricate mesh of cloud-native tools, you aren’t doing "real" modern development.

We were promised infinite scalability, zero maintenance, and pay-as-you-go pricing.

But nobody told us about the hidden costs:

The $500 surprise bill because an infinite loop triggered a serverless function overnight.
The nightmare of debugging "cold starts" that make your API feel sluggish.
The reality that 95% of applications will never need to scale dynamically to millions of users in seconds.

The tech industry is finally waking up from the cloud hangover, and the "De-clouding" movement is officially here.

The Rise of the $5 VPS and the "Local-First" Database

Companies like Basecamp famously saved $1.5 million a year by leaving the cloud and buying their own hardware. But you don't need to buy a physical server rack to benefit from this mindset shift.

Lately, there’s a massive resurgence in keeping things incredibly lean:

The Revenge of SQLite: For years, SQLite was treated as a "toy" database. Today, with tools like Prisma and modern storage, devs are realizing that a local, single-file SQLite database running on a tiny virtual private server (VPS) can handle hundreds of concurrent requests per second with zero network latency. No AWS RDS required.
Predictable Pricing: Deploying a standard Node.js/Fastify monolith on a flat-rate provider (like Hetzner, DigitalOcean, or a simple Render instance) means you know exactly how much you will pay at the end of the month. No complex math, no bandwidth tax.

Why We Fell for the Hype

We mistook architectural complexity for engineering maturity.

We started designing infrastructure for the scale of Netflix while having the traffic of a local bakery. Serverless and micro-cloud architectures are fantastic tools for highly unpredictable, massive workloads. But for a standard SaaS, a portfolio, or a business API? It's just an expensive layer of friction.

Bringing Sanity Back to the Backend

Going back to basics isn't "regression"; it's pragmatism.

When you build an API with a straightforward framework, protect it with a local memory rate-limiter, and write to a local or predictable database, you remove 90% of the moving parts that could break. You spend less time configuring YAML files and more time actually writing features.

Let's talk numbers...

Are you still fully bought into the serverless/cloud-native dream, or have you started moving your side projects (and company apps) back to simpler, predictable hosting? What’s the craziest cloud bill you’ve ever seen?

Let’s debate in the comments below! 💸👇