DEV Community: Renato Silva

Riverpod vs Bloc: Fixing the FutureBuilder Anti-Pattern

Renato Silva — Thu, 01 Oct 2026 15:55:35 +0000

🔧 The Problem

If you've worked on a Flutter codebase for more than a few sprints, you've seen this pattern:

dart
class UserProfileScreen extends StatelessWidget {
final String userId;
const UserProfileScreen({required this.userId, super.key});

Future _fetchUser() => UserRepository().getUser(userId);

@override
Widget build(BuildContext context) {
return FutureBuilder(
future: _fetchUser(),
builder: (context, snapshot) {
if (snapshot.connectionState == ConnectionState.waiting) {
return const CircularProgressIndicator();
}
if (snapshot.hasError) {
return Text('Error: ${snapshot.error}');
}
return UserCard(user: snapshot.data!);
},
);
}
}

It looks harmless. It even looks idiomatic — it's in every Flutter tutorial. But _fetchUser() is called inside build(), which means it reruns on every rebuild that touches this widget. Scroll the parent ListView, trigger a setState two levels up, rotate the device — and congratulations, you just refetched the user, flashed a loading spinner over good data, and maybe hit your API rate limit.

The usual "fix" is to hoist the future into a late final field or initState, which helps — until the widget gets rebuilt by its parent with a new key, or the userId changes and nothing refreshes because the future was already memoized. Now you've got stale data instead of redundant fetches. Either way, the async lifecycle is coupled to the widget lifecycle, and widget lifecycles are not a reliable place to put business logic.

🕵️ Why This Keeps Biting Teams

The core issue isn't FutureBuilder itself — it's a well-built widget. The issue is where the future is created. Widgets rebuild for reasons that have nothing to do with your data: theme changes, MediaQuery updates, a sibling's setState, hot reload. None of those should restart a network call, but if the future lives in build(), they will.

The real fix is architectural: async operations belong in a layer that outlives individual widget rebuilds and has an explicit, observable lifecycle. That's exactly what Riverpod and Bloc are for — they just get there differently.

🧩 Riverpod: AsyncValue as a First-Class Citizen

Riverpod's FutureProvider (or AsyncNotifier for anything more than a one-shot fetch) moves the async call out of the widget tree entirely. The provider is keyed by its arguments, cached, and only re-executes when its dependencies actually change.

dart
@riverpod
Future user(UserRef ref, String userId) {
return ref.watch(userRepositoryProvider).getUser(userId);
}

dart
class UserProfileScreen extends ConsumerWidget {
final String userId;
const UserProfileScreen({required this.userId, super.key});

@override
Widget build(BuildContext context, WidgetRef ref) {
final userAsync = ref.watch(userProvider(userId));

return userAsync.when(
  data: (user) => UserCard(user: user),
  loading: () => const CircularProgressIndicator(),
  error: (err, stack) => Text('Error: $err'),
);

}
}

The win here is subtle but important: ref.watch(userProvider(userId)) doesn't re-run the future on rebuild. The provider is cached against the userId argument. If a parent rebuilds and this widget rebuilds with it, Riverpod just hands back the existing AsyncValue — no new HTTP call. If userId changes, Riverpod recognizes it as a different provider instance and fetches fresh data automatically. You get request deduplication and cache invalidation almost for free, and AsyncValue.when forces you to handle loading/error/data explicitly, which eliminates the "forgot to check snapshot.hasError" class of bugs.

The trade-off: you're leaning on code generation (@riverpod) and a mental model of providers-as-dependency-graph, which has a real learning curve if your team hasn't used DI-flavored patterns before. Debugging "why did this provider rebuild" sometimes means reading ref.watch chains across multiple files.

🧱 Bloc: Explicit States for Explicit Transitions

Bloc takes a more ceremonial but arguably more auditable approach: you model every async phase as a discrete state, and a Cubit or Bloc owns the transition logic.

dart
sealed class UserState {}
class UserInitial extends UserState {}
class UserLoading extends UserState {}
class UserLoaded extends UserState {
final User user;
UserLoaded(this.user);
}
class UserError extends UserState {
final String message;
UserError(this.message);
}

class UserCubit extends Cubit {
final UserRepository repository;
UserCubit(this.repository) : super(UserInitial());

Future loadUser(String userId) async {
emit(UserLoading());
try {
final user = await repository.getUser(userId);
emit(UserLoaded(user));
} catch (e) {
emit(UserError(e.toString()));
}
}
}

dart
class UserProfileScreen extends StatelessWidget {
final String userId;
const UserProfileScreen({required this.userId, super.key});

@override
Widget build(BuildContext context) {
return BlocProvider(
create: (_) => UserCubit(context.read())..loadUser(userId),
child: BlocBuilder(
builder: (context, state) => switch (state) {
UserLoading() || UserInitial() => const CircularProgressIndicator(),
UserLoaded(:final user) => UserCard(user: user),
UserError(:final message) => Text('Error: $message'),
},
),
);
}
}

Because loadUser is called once in create, not on every build, the fetch is decoupled from widget rebuilds the same way Riverpod decouples it — just via explicit lifecycle methods instead of dependency-graph caching. BlocProvider guarantees the Cubit instance (and its in-flight future) survives rebuilds of the subtree, as long as you don't recreate the provider higher up the tree.

The trade-off is verbosity: four state classes for one fetch, plus boilerplate if you need to refetch when userId changes (you'd typically do that with a didUpdateWidget check or a BlocListener reacting to a parent-level event). In exchange, you get a state machine that's trivially testable with bloc_test and a transition log you can replay for debugging — genuinely valuable in regulated or high-incident-rate codebases where "what sequence of states did we actually go through" matters.

⚖️ The Actual Trade-off

Both solve the same root problem — stop constructing futures inside build() — but they optimize for different failure modes:

Riverpod optimizes for correctness with less code: caching, deduplication, and parameterized providers are handled by the framework. You pay for it with a steeper initial learning curve and less explicit control over state transitions.
Bloc optimizes for auditability and testability: every state change is a named, inspectable event. You pay for it with more files and manual wiring for things like argument-based refetching.

If your team is small, iterates fast, and wants async logic colocated with minimal ceremony, Riverpod's AsyncNotifier usually wins. If you're on a larger team, need strict separation between "what happened" and "how the UI reacts," or already have Bloc conventions baked into code review checklists, stick with it — just make sure you're creating the Bloc/Cubit outside of build(), same rule as Riverpod providers.

What neither pattern tolerates is the original sin: constructing async work inside the widget's build() method. That's the actual anti-pattern, not FutureBuilder itself — FutureBuilder is just the symptom you see first.

🗣️ Over to You

Which pattern has actually survived contact with your production incidents — Riverpod's cached providers or Bloc's explicit state machine? Or have you found a third way (raw ChangeNotifier, signals, flutter_hooks) that handles this better than either?

Your AI Code Reviewer Needs a Test Suite Too

Renato Silva — Thu, 24 Sep 2026 13:58:17 +0000

🤖 The Problem

You plugged an LLM into your PR pipeline. It leaves comments about SQL injection, N+1 queries, missing null checks. Everyone's thrilled for about two sprints, and then someone notices it stopped catching the exact same bug pattern it used to flag. A prompt got tweaked. A model version got bumped upstream. Someone added "be more concise" to the system prompt and it started skipping the security section entirely.

Nobody noticed because nobody was checking. The AI reviewer is running in production, making judgment calls on every PR in your org, and it has zero test coverage. That's the part that should bother you more than it probably does.

🕳️ Why This Gap Exists

We test the code the AI reviews. We don't test the reviewer itself, because it feels fuzzy — "it's an LLM, how do you even assert against prose?" But that's a cop-out. You don't need to assert on exact wording. You need to assert on behavior: given a diff with a known bug, does the reviewer flag it, in the right file, with the right severity, without three false positives burying the real issue?

That's a testable claim. It just requires building fixtures the same way you'd build fixtures for any other system with non-deterministic-ish output — like testing a search ranking algorithm or a fraud-detection model.

🧪 Building a Golden-Diff Suite

The core idea: collect real PRs (or synthetic ones) with known, labeled defects, and treat them like golden files. Run each one through your reviewer, then assert the output contains — or doesn't contain — specific findings.

Here's a minimal structure using Python and pytest, since most review pipelines are just a script wrapping an LLM call:

python

reviewer/client.py

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

SYSTEM_PROMPT = open("prompts/review_system.md").read()

def review_diff(diff_text: str) -> str:
response = client.chat.completions.create(
model="gpt-4.1",
temperature=0,
messages=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": f"Review this diff:\n\n{diff_text}"},
],
)
return response.choices[0].message.content

Note temperature=0. You're not eliminating nondeterminism, but you're minimizing it — this matters a lot when you're about to assert against the output.

📁 Structuring the Fixtures

Each fixture is a known-bad diff plus a manifest describing what should get flagged:

fixtures/
sql_injection_raw_query/
diff.patch
expected.yaml
missing_await_async_call/
diff.patch
expected.yaml
hardcoded_secret_in_config/
diff.patch
expected.yaml

yaml

fixtures/sql_injection_raw_query/expected.yaml

must_flag:

category: security file: app/db/queries.py line_range: [42, 45] keywords: ["injection", "parameteriz", "sanitiz"] must_not_flag:
category: style keywords: ["variable naming"] max_total_comments: 4

The must_not_flag block matters as much as must_flag. A reviewer that comments on everything technically "catches" every bug, but it's useless noise. You want to pin down both precision and recall.

✅ Writing the Assertions

Since the output is prose, not structured data, you have two options: force structured output (JSON mode, function calling) or parse loosely with keyword/semantic matching. I'd push hard for structured output — it makes the whole test suite dramatically less brittle.

python

reviewer/schema.py

from pydantic import BaseModel

class Finding(BaseModel):
category: str
file: str
line_start: int
line_end: int
message: str
severity: str

class ReviewResult(BaseModel):
findings: list[Finding]

python

tests/test_golden_diffs.py

import yaml
import pytest
from pathlib import Path
from reviewer.client import review_diff
from reviewer.schema import ReviewResult

FIXTURE_DIR = Path("fixtures")

def load_fixtures():
for folder in FIXTURE_DIR.iterdir():
diff = (folder / "diff.patch").read_text()
expected = yaml.safe_load((folder / "expected.yaml").read_text())
yield pytest.param(diff, expected, id=folder.name)

@pytest.mark.parametrize("diff,expected", load_fixtures())
def test_reviewer_catches_known_bug(diff, expected):
raw = review_diff(diff)
result = ReviewResult.model_validate_json(raw)

for must in expected.get("must_flag", []):
    matches = [
        f for f in result.findings
        if f.category == must["category"]
        and f.file == must["file"]
        and any(kw in f.message.lower() for kw in must["keywords"])
    ]
    assert matches, f"Reviewer missed expected finding: {must}"

for forbidden in expected.get("must_not_flag", []):
    matches = [
        f for f in result.findings
        if any(kw in f.message.lower() for kw in forbidden["keywords"])
    ]
    assert not matches, f"Reviewer raised noise it shouldn't have: {forbidden}"

max_comments = expected.get("max_total_comments")
if max_comments is not None:
    assert len(result.findings) <= max_comments

This is a regression suite in the truest sense: every time someone edits the system prompt, swaps the model, or adjusts temperature, this runs and tells you exactly what broke. "Prompt change reduced recall on SQL injection cases from 100% to 60%" is a real, actionable CI failure — not a vibe.

🔄 Running It in CI

The expensive part is the LLM calls, so don't run this on every commit to every branch. Run it:

On any PR that touches prompts/, reviewer/, or model config
Nightly, to catch silent drift from provider-side model updates
Before promoting a new prompt version to production, as a hard gate

yaml

.github/workflows/reviewer-regression.yml

name: reviewer-regression
on:
pull_request:
paths:
- "prompts/"
- "reviewer/"
schedule:
- cron: "0 6 * * *"
jobs:
golden-diffs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- run: pip install -r requirements.txt
- run: pytest tests/test_golden_diffs.py -v
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

⚖️ Trade-offs Worth Naming

This isn't free, and it's not perfectly deterministic even with temperature=0 — different model versions can still shift slightly. A few honest trade-offs:

Fixture rot: real-world bug patterns evolve. Budget time to add new fixtures whenever a bug slips past the reviewer in production — that miss becomes your next test case.
Cost: a suite of 50 fixtures run nightly against GPT-4-class models adds up. Consider a cheaper model for the regression suite if it's representative enough, and reserve the expensive model for prod.
False confidence: passing the golden-diff suite doesn't mean the reviewer is good, only that it hasn't regressed on the specific patterns you've thought to encode. Treat it as a floor, not a ceiling.
Structured output constraints: forcing JSON schemas can sometimes make models slightly less thorough in free-form reasoning. Worth A/B testing structured vs. prose output against your fixture set before committing.

None of these are reasons to skip this. They're reasons to scope it like any other test suite — start with the five bug patterns that have bitten you hardest in production, not fifty hypothetical ones.

🚀 Wrap Up

If your AI reviewer has opinions about your code quality, it deserves the same scrutiny you'd apply to any other piece of logic sitting between a developer and a merge button. A golden-diff suite is cheap to start — a handful of real bugs pulled from your git history and a YAML file describing what "catching it" looks like.

What's the bug pattern your AI reviewer has already let through that you haven't turned into a test case yet? That's usually fixture #1.

NPU, DPU, QPU: Which One Actually Belongs in Your Stack

Renato Silva — Mon, 21 Sep 2026 15:35:37 +0000

Every hardware vendor keeps mailing you a new three-letter acronym like it's a subpoena. NPU. DPU. QPU. Somewhere a marketing team is very happy. Somewhere else, you're trying to figure out if any of this actually changes what you deploy on Tuesday.

Short answer: two of these are already earning their keep in production today, and one is still mostly a research toy wearing a lab coat. Let's separate the hype from the workload.

🧠 NPU — Yes, If You're Doing On-Device Inference

An NPU (Neural Processing Unit) is a chip optimized for the matrix-multiply-and-accumulate operations that dominate neural network inference. The pitch is real: NPUs deliver way better performance-per-watt than a CPU, and often better perf-per-watt than a GPU too, specifically for low-precision (int8/int4) inference workloads.

Where it actually matters:

Mobile and edge apps — on-device transcription, camera segmentation, keyword spotting. Apple's Neural Engine, Qualcomm's Hexagon NPU, and Intel's AI Boost are all built for exactly this.
Battery-constrained inference — anything running continuously (wake-word detection, always-on vision) where GPU power draw would murder your battery life.
Privacy-sensitive workloads — keeping inference local instead of round-tripping to a cloud GPU.

Where it doesn't matter:

Training. NPUs are inference-first. If you're fine-tuning, you're still on GPU or TPU.
Server-side batch inference where you can amortize GPU cost across many requests. A GPU with good batching will often out-throughput an NPU designed for single-stream, low-latency edge inference.
Anything using fp32/fp64. NPUs are built around quantized, low-precision math. If your model isn't quantization-friendly, you'll fight the toolchain more than you save on power.

Here's what actually shipping to an NPU looks like today, using ONNX Runtime with a hardware-specific execution provider:

python
import onnxruntime as ort

Falls back gracefully, but explicitly requests NPU execution first

providers = [
("QNNExecutionProvider", {"backend_path": "QnnHtp.dll"}), # Qualcomm NPU
"CPUExecutionProvider",
]

session = ort.InferenceSession("keyword_spotter_int8.onnx", providers=providers)

output = session.run(
None,
{"audio_frame": frame.astype("int8")},
)

The honest trade-off: you're trading model flexibility and easy debugging for power efficiency and latency. If your model is a quantized int8 CNN or small transformer running continuously on a phone or embedded board, the NPU is the correct answer. If you're prototyping on fp32 weights and want fast iteration, stay on CPU/GPU until the model is locked.

🌐 DPU — Yes, If Your Network/Storage Path Is the Bottleneck

DPUs (Data Processing Units — NVIDIA BlueField, AMD Pensando, Intel IPU) offload the stuff your CPU is bad at anyway: packet processing, TLS termination, storage virtualization, RDMA, and vSwitch logic. The core insight is that a modern 100/200Gbps NIC generates more interrupts and per-packet overhead than a general-purpose CPU core can chew through without falling over.

Where it actually matters:

Multi-tenant infrastructure — cloud providers offloading virtual switching so tenant VMs don't steal CPU cycles from the host for networking.
Storage-heavy clusters — NVMe-oF, erasure coding, and compression offloaded so your storage nodes' CPUs are free for actual application logic.
High-throughput security — inline TLS/IPsec at line rate without eating into compute you're paying for.

Where it doesn't matter:

A typical web service doing < 10Gbps. Your kernel network stack and CPU are fine. A DPU here is solving a problem you don't have.
Small clusters without a dedicated infra team. DPUs come with real operational overhead — you're now managing another programmable device with its own firmware, OS (often a stripped Linux running on ARM cores), and failure modes.

A representative DPU workload is offloading flow classification with something like DPDK or P4, rather than handling it in kernel space:

c
// Simplified P4 match-action rule offloaded to DPU ASIC/FPGA pipeline
table classify_flow {
key = {
hdr.ipv4.src_addr: exact;
hdr.ipv4.dst_addr: exact;
hdr.tcp.dst_port: exact;
}
actions = {
forward_to_vm;
drop_flow;
mirror_to_ids;
}
size = 65536;
}

apply {
classify_flow.apply();
}

The trade-off here is capex and complexity versus CPU headroom. If your bottleneck is genuinely network/storage I/O stealing cycles from application logic, a DPU is a straightforward win. If you're not saturating a 25Gbps link, you're buying a Ferrari to sit in traffic.

⚛️ QPU — Not Yet, and Probably Not Soon

Here's where I'll be the buzzkill. QPUs are real, IBM, IonQ, and Rigetti will happily give you cloud access, and quantum algorithms like Shor's and Grover's are mathematically legitimate. But "belongs in your stack today" implies a production workload with a favorable cost/benefit versus classical hardware. That doesn't exist yet for essentially any commercial application.

Current NISQ-era (Noisy Intermediate-Scale Quantum) hardware has:

Qubit counts in the hundreds, not the millions needed for meaningful error-corrected computation.
Decoherence times measured in microseconds, meaning circuit depth is severely limited.
No demonstrated quantum advantage on a problem anyone is actually paid to solve in production — optimization, chemistry simulation, and cryptanalysis demos are all still research-scale.

What you can legitimately do today is experimentation and skill-building, which has real value if quantum ever matures on your timeline:

python
from qiskit import QuantumCircuit
from qiskit_aer import AerSimulator

qc = QuantumCircuit(2, 2)
qc.h(0)
qc.cx(0, 1)
qc.measure([0, 1], [0, 1])

sim = AerSimulator()
result = sim.run(qc, shots=1000).result()
print(result.get_counts())

Notice this ran on a simulator, not real quantum hardware — and for almost every "quantum experiment" blog post you'll see this year, that's the honest state of things. If you're doing quantum chemistry research or working at a place with a dedicated quantum team, real QPU access via cloud APIs (Qiskit Runtime, Braket) makes sense as R&D. For a normal product stack, a QPU line item is a research budget decision, not an engineering one.

🔧 The Actual Decision Framework

Strip away the vendor decks and it's a simple filter:

Chip	Real workload today	Ask yourself
NPU	Quantized inference at the edge	Is this model quantized, latency-sensitive, and running on battery?
DPU	Line-rate network/storage offload	Is my CPU actually saturated by I/O, not application logic?
QPU	Research and algorithm exploration	Am I doing this for a paper/PoC, or do I actually have a production problem it solves?

Most teams reading this don't need any of the three — a well-tuned GPU or even CPU inference path, a beefy NIC with kernel bypass, and zero quantum anything will outperform premature specialization. The chips earn their keep only when the workload characteristics (precision, throughput, or problem class) actually demand it.

What's the acronym you've seen misapplied the hardest — teams reaching for specialized silicon before checking if the boring hardware was actually the bottleneck? Drop your war story below.

SSH Tunnel Manager in Rust: CLI vs Native GUI Trade-offs

Renato Silva — Thu, 17 Sep 2026 14:02:56 +0000

🔧 The Problem

A few weeks ago a Swift-based macOS SSH tunnel manager started making the rounds here — a menu bar app that lets you spin up local/remote port forwards without touching a terminal. It's a genuinely nice pattern: SSH tunnels are one of those tools everyone reaches for constantly (jump boxes, database access, staging environments) but nobody wants to remember the flag syntax for.

bash
ssh -N -L 5432:db.internal:5432 -i ~/.ssh/jump_key jumpbox.example.com

That command is fine until you have twelve of them across three environments, and you forget which one you killed last Tuesday.

I wanted the same convenience but without being locked to macOS, so I built it twice in Rust: once as a CLI with a TOML-driven tunnel registry, and once as a native GUI using tauri. This post is about what that comparison actually cost me — not in "which is better" terms, but in concrete trade-offs around distribution, process management, and platform integration.

🧱 The Core: Managing SSH as a Child Process

Both versions share the same backend logic. Rust doesn't have a native SSH client library that's production-ready enough for arbitrary key/agent auth quirks, so both versions shell out to the system ssh binary and manage it as a subprocess — same approach the Swift app uses under the hood, incidentally.

rust
use std::process::{Command, Child, Stdio};
use std::collections::HashMap;

pub struct Tunnel {
pub name: String,
pub local_port: u16,
pub remote_host: String,
pub remote_port: u16,
pub ssh_host: String,
process: Option,
}

impl Tunnel {
pub fn start(&mut self) -> std::io::Result<()> {
let forward = format!("{}:{}:{}", self.local_port, self.remote_host, self.remote_port);
let child = Command::new("ssh")
.args(["-N", "-L", &forward, &self.ssh_host])
.stdout(Stdio::null())
.stderr(Stdio::piped())
.spawn()?;
self.process = Some(child);
Ok(())
}

pub fn stop(&mut self) -> std::io::Result<()> {
    if let Some(mut child) = self.process.take() {
        child.kill()?;
        child.wait()?;
    }
    Ok(())
}

pub fn is_alive(&mut self) -> bool {
    match &mut self.process {
        Some(child) => matches!(child.try_wait(), Ok(None)),
        None => false,
    }
}

}

pub type TunnelRegistry = HashMap;

This part was identical effort in both builds. The divergence starts the moment you decide how a human is supposed to interact with it.

🖥️ The CLI Path

The CLI version uses clap for argument parsing and a TOML config file for tunnel definitions:

toml
[tunnels.staging_db]
ssh_host = "jumpbox.example.com"
local_port = 5432
remote_host = "db.internal"
remote_port = 5432

[tunnels.staging_redis]
ssh_host = "jumpbox.example.com"
local_port = 6379
remote_host = "cache.internal"
remote_port = 6379

bash
tunlctl up staging_db
tunlctl status
tunlctl down staging_db
tunlctl up --all

What this bought me:

Distribution is trivial. cargo install tunlctl, or a single static binary via cross for Linux/macOS/Windows. No code signing, no notarization, no App Store review queue.
Scriptability for free. People immediately asked for tunlctl up staging --json to pipe into other tooling. A GUI can't casually do that.
Persistence via existing tools. Backgrounding and keeping tunnels alive after the CLI exits meant either double-forking or leaning on systemd/launchd unit files I generate on demand. That's more plumbing than a GUI app gets automatically just by staying resident.

What it cost me:

No visual "this tunnel died" signal. You either poll tunlctl status or you don't find out until your app starts throwing connection refused errors.
No system tray indicator, no click-to-toggle. For a tool used dozens of times a day, keystrokes and cognitive load add up in a way a menu bar icon avoids entirely.

🪟 The GUI Path

The Tauri version wraps the same Tunnel struct behind commands, and Rust plus a lightweight HTML/CSS frontend for the tray menu and window:

rust

[tauri::command]

fn toggle_tunnel(name: String, state: tauri::State) -> Result {
let mut registry = state.registry.lock().map_err(|e| e.to_string())?;
let tunnel = registry.get_mut(&name).ok_or("tunnel not found")?;

if tunnel.is_alive() {
    tunnel.stop().map_err(|e| e.to_string())?;
    Ok(false)
} else {
    tunnel.start().map_err(|e| e.to_string())?;
    Ok(true)
}

}

What this bought me:

Ambient status. A tray icon that turns green/red per tunnel, updated by a background poller, is genuinely better UX than typing a status command. This is the single biggest reason the Swift app resonated with people.
Process lifetime is free. The app itself is the long-running process; tunnels live and die with it, no daemon management needed.
Native feel where it matters, e.g. macOS keychain integration for SSH passphrases instead of relying on ssh-agent being configured correctly.

What it cost me:

Distribution got real overhead. Unsigned builds trigger Gatekeeper warnings on macOS and SmartScreen on Windows. Signing a macOS app means an Apple Developer account, notarization via xcrun notarytool, and a CI step that didn't exist in the CLI world at all.
Bundle size and build complexity jumped. Tauri is far lighter than Electron, but you're still shipping a webview-based frontend, dealing with tauri.conf.json, and debugging IPC serialization between Rust and JS for things that were plain function calls in the CLI.
Cross-platform tray behavior is not actually uniform. Linux tray icon support depends on the desktop environment having a functioning StatusNotifierItem implementation. It's a smaller thing than you'd hope for a "cross-platform" story.

⚖️ The Actual Trade-off

If I had to compress this into one sentence: the CLI wins on time-to-ship and the GUI wins on time-to-use.

For a tool I'm building for myself and a small team that already lives in a terminal, tunlctl shipped in an afternoon and required zero ongoing signing infrastructure. For something meant to be handed to less terminal-comfortable teammates, or anyone who wants "click icon, tunnel appears," the GUI's ambient status indicator justified every bit of the notarization pain.

My actual answer ended up being both, sharing the same core crate — the CLI is the source of truth and the automation-friendly interface, and the GUI is a thin, optional shell around it for people who want the tray icon. That's not a cop-out; it's the same reason docker has both a CLI and Docker Desktop.

🙋 Over to You

If you've built or maintained an internal dev tool that started as a CLI and grew a GUI (or vice versa) — where did the complexity actually show up for you? Was it distribution, state management, or something else entirely?

If you want to poke at the code, the tunnel-management core described here is intentionally backend-agnostic — happy to expand on the daemon/launchd integration in a follow-up if there's interest.

I Profiled 1M Goroutines So You Don't Have to

Renato Silva — Mon, 14 Sep 2026 15:35:12 +0000

🔧 The Problem

Every Go dev has heard "goroutines are cheap." True, relative to OS threads. But cheap isn't free, and at scale the bill comes due in ways that don't show up until you're staring at a memory graph wondering why your service that spawns a goroutine per request just OOM'd at 800k concurrent connections.

I wanted actual numbers, not vibes. So I spun up 1,000,000 goroutines in a few different shapes, profiled them with go tool pprof and runtime.MemStats, and tried to separate two costs that get lumped together as "goroutine overhead":

Stack memory — the growable per-goroutine stack
Scheduler bookkeeping — the g struct, sudogs, run queue entries, and GC scanning overhead

These are different cost centers with different scaling behavior, and conflating them leads to bad capacity planning.

🧪 The Setup

Here's the baseline harness — goroutines that block forever on a channel, so they stay alive and scheduled but don't do work:

go
package main

import (
"fmt"
"os"
"runtime"
"runtime/pprof"
)

func main() {
const n = 1_000_000
block := make(chan struct{})

var readyWg = make(chan struct{}, n)
for i := 0; i < n; i++ {
    go func() {
        readyWg <- struct{}{}
        <-block
    }()
}
for i := 0; i < n; i++ {
    <-readyWg
}

var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Printf("HeapAlloc: %d MB\n", m.HeapAlloc/1024/1024)
fmt.Printf("StackInuse: %d MB\n", m.StackInuse/1024/1024)
fmt.Printf("NumGoroutine: %d\n", runtime.NumGoroutine())

f, _ := os.Create("heap.pprof")
pprof.WriteHeapProfile(f)
f.Close()

<-make(chan struct{}) // hang so we can attach pprof live too

}

Run with GODEBUG=madvdontneed=1 off (default) and GOGC=400 to reduce GC noise while we measure steady state, then:

bash
go run main.go &
go tool pprof -top -alloc_space heap.pprof
go tool pprof http://localhost:6060/debug/pprof/goroutine

(Yes, I added the standard net/http/pprof import for the live endpoint — don't forget the underscore import or you'll wonder why /debug/pprof/ 404s.)

📊 What `MemStats` Actually Shows

With 1M blocked goroutines doing nothing but sitting on a channel receive:

HeapAlloc: 366 MB
StackInuse: 2147 MB
NumGoroutine: 1000000

That StackInuse number is the headline: ~2.1KB per goroutine, even though the default initial stack is 2KB and these goroutines do almost nothing. That checks out — Go's runtime allocates the initial stack up front, and a goroutine parked on a channel receive still holds onto that stack because the scheduler needs somewhere to resume execution.

The HeapAlloc — 366MB — is the part people forget about. That's not stack, that's the runtime.g structs, the sudog entries used for channel waiters, and assorted bookkeeping. Divide it out: ~384 bytes per goroutine in pure scheduler/heap overhead, separate from the stack.

So per goroutine, roughly:

2KB — initial stack (grows if the function needs more)
~200-450 bytes — g struct + scheduler metadata
~48-100 bytes — sudog if blocked on a channel/mutex/select

That second bucket is the one that surprises people, because it scales with goroutine count, not with what the goroutine is doing. You can't shrink it by simplifying your goroutine's logic. It's the tax for existing.

📈 Where pprof Actually Helps

go tool pprof -alloc_space on the heap profile shows the scheduler overhead concretely:

(pprof) top10
Flat Flat% Sum% Cum Cum% Name
312MB 85.2% 85.2% 312MB 85.2% runtime.malg
38MB 10.4% 95.6% 38MB 10.4% runtime.acquireSudog
9MB 2.5% 98.1% 9MB 2.5% runtime.newproc.func1

runtime.malg — goroutine struct allocation — dominates. This is the smoking gun for "scheduler overhead," separate entirely from the stack memory pprof doesn't even show you here (stack isn't heap-allocated in the traditional sense pprof tracks by default; you have to cross-reference StackInuse from MemStats to see it).

That's the key methodological point: pprof's heap profile and MemStats' StackInuse are answering different questions, and if you only look at one you'll misdiagnose the bottleneck. I've seen postmortems blame "goroutine leaks" on stack growth when the actual driver was thousands of goroutines each holding a sudog because they were blocked on a busy mutex.

🐘 What Happens When Goroutines Actually Do Something

Blocked-on-channel goroutines are the cheap case. Let's make it more realistic — recursive work that grows the stack:

go
func recurse(n int, block <-chan struct{}) {
if n == 0 {
<-block
return
}
var buf [64]byte
_ = buf
recurse(n-1, block)
}

Spawning 1M of these with recurse(50, block) pushes StackInuse from ~2.1GB to ~4.6GB — stacks grew from the 2KB default to accommodate the recursion depth, and Go doesn't shrink them back down eagerly unless a GC cycle happens to trigger shrinkstack on that goroutine (checked during stack scanning, roughly every other GC if the stack is <1/4 utilized). Under GOGC=400 that shrink check happens rarely, so stacks stay bloated far longer than you'd expect.

This is the practical takeaway: if your workload has bursty deep call stacks (recursive JSON parsing, deep middleware chains, reflection-heavy code), the stack growth sticks around as a memory cost long after the burst ends, independent of the flat per-goroutine scheduler tax. Lowering GOGC or calling debug.FreeOSMemory() after a burst can reclaim it, at the cost of more frequent GC cycles overall — a real trade-off, not a free win.

🧮 The Cost Model, Summarized

Cost center	Scales with	Reclaimed how
Initial stack (2KB)	goroutine count	goroutine exit
Stack growth	max call depth reached	GC-triggered `shrinkstack`, rare under high GOGC
`g` struct / scheduler	goroutine count	goroutine exit
`sudog`	count of blocked goroutines	unblock or exit

If you're doing capacity planning for a goroutine-per-connection server, the number that matters isn't "goroutines are ~2KB each" — it's closer to 2.5-3KB steady state for idle blocked goroutines, and potentially multiples of that if your request handlers recurse or allocate large local buffers before blocking.

🙋 Over to You

Have you actually hit a goroutine-count wall in production, or is 1M goroutines mostly an academic exercise for your workloads? I'd genuinely like to know where the real-world breakpoint sits — 100k? 10M? Drop your numbers (and your GOMAXPROCS) in the comments.

If you want to reproduce this, the full harness plus the recursive-stack variant is about 80 lines — worth running locally with your own GOGC and GOMAXPROCS settings, because scheduler contention at 1M goroutines on a 4-core box behaves noticeably differently than on 64 cores, and that's a whole separate profiling story.

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.

DEV Community: Renato Silva

Riverpod vs Bloc: Fixing the FutureBuilder Anti-Pattern

🔧 The Problem

🕵️ Why This Keeps Biting Teams

🧩 Riverpod: AsyncValue as a First-Class Citizen

🧱 Bloc: Explicit States for Explicit Transitions

⚖️ The Actual Trade-off

🗣️ Over to You

Your AI Code Reviewer Needs a Test Suite Too

🤖 The Problem

🕳️ Why This Gap Exists

🧪 Building a Golden-Diff Suite

reviewer/client.py

📁 Structuring the Fixtures

fixtures/sql_injection_raw_query/expected.yaml

✅ Writing the Assertions

reviewer/schema.py

tests/test_golden_diffs.py

🔄 Running It in CI

.github/workflows/reviewer-regression.yml

⚖️ Trade-offs Worth Naming

🚀 Wrap Up

NPU, DPU, QPU: Which One Actually Belongs in Your Stack

🧠 NPU — Yes, If You're Doing On-Device Inference

Falls back gracefully, but explicitly requests NPU execution first

🌐 DPU — Yes, If Your Network/Storage Path Is the Bottleneck

⚛️ QPU — Not Yet, and Probably Not Soon

🔧 The Actual Decision Framework

SSH Tunnel Manager in Rust: CLI vs Native GUI Trade-offs

🔧 The Problem

🧱 The Core: Managing SSH as a Child Process

🖥️ The CLI Path

🪟 The GUI Path

[tauri::command]

⚖️ The Actual Trade-off

🙋 Over to You

I Profiled 1M Goroutines So You Don't Have to

🔧 The Problem

🧪 The Setup

📊 What MemStats Actually Shows

📈 Where pprof Actually Helps

🐘 What Happens When Goroutines Actually Do Something

🧮 The Cost Model, Summarized

🙋 Over to You

Git Worktrees: The Missing Piece for Parallel AI Agents

🔧 The Problem

🌳 Worktrees in Practice

from your main checkout

see what's active

/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]

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

!/usr/bin/env bash

spawn-agent.sh

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

⚠️ The Gotchas Nobody Mentions

🚀 Putting It Together

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

🔧 The Problem

🐢 Polling: the boring baseline

📡 SSE: push, but only one way

🔌 WebSockets: when you actually need two-way

📊 Honest comparison

🧠 The part that actually matters: consistency, not transport

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

🎯 The Setup

🔧 The Problem

🕸️ Modeling Feedback as a Graph

🔍 The BFS Implementation

🐘 Doing It in Postgres Instead

⚖️ Complexity Trade-offs at Small Scale

🚀 Where This Goes Next

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

🔧 The Problem

🧩 What Changed

1. One deployable concern per PR

2. Feature flags instead of long-lived branches

3. A self-review checklist before I hit merge

📊 What `MemStats` Actually Shows