DEV Community: Matías Denda

Building a P2P Chat over Tor with Rust's arti-client

Matías Denda — Tue, 23 Jun 2026 14:00:00 +0000

Post 5 of 6 on Anyhide. This post is about peer discovery and session setup over Tor.

There's a surprising amount of work between "I have a cryptographic protocol" and "two people can talk to each other." This post is about that work.

The protocol from Post 4 assumes Alice and Bob can send each other bytes. It does not explain how they find each other in the first place, how they agree on a session, or what happens when the network drops messages. For Anyhide's chat, the answer to all three questions involves Tor hidden services, and I'd never written a line of Tor code before starting.

I used arti-client, the Rust-native Tor implementation from the Tor Project. Most content about Tor integration assumes you're running tor as a separate daemon and talking to its SOCKS port. Arti is different: it's a library you embed directly. You get a real Tor client inside your process, running on your runtime, with circuits you can open and hidden services you can host.

It's also marked experimental by the Tor Project, which I'll come back to.

Why hidden services and not just a relay

The first question you'd ask: "Can't Alice just host a regular TCP server and let Bob connect through a Tor circuit?" Yes, but it doesn't give you what you want. A regular server has a public IP and a DNS name. The fact that Bob is anonymous to Alice doesn't help if Alice's server is indexed somewhere.

Hidden services (officially "onion services") flip the model: both endpoints are anonymous. The service has a .onion address, not an IP address. Clients connect through the Tor network to a rendezvous point, where the server is waiting via its own circuit. Neither side learns the other's IP. Neither side has to open a port on their router.

For a two-person chat where both participants want privacy, that's the only model that makes sense.

The .onion address, by hand

Arti gives you an HsId when you create a hidden service — it's a 32-byte Ed25519 public key. But humans expect an address string like abcdef123...onion. Arti doesn't hand you that directly, so I wrote the conversion. It's a nice little exercise:

// src/chat/transport/tor.rs

/// Convert an HsId to its .onion address string.
fn hsid_to_onion_address(hsid: &HsId) -> String {
    // HsId is a 32-byte ed25519 public key
    // The .onion address is: base32(PUBKEY | CHECKSUM | VERSION)
    // where CHECKSUM = SHA3_256(".onion checksum" | PUBKEY | VERSION)[:2]
    // and VERSION = 0x03

    use sha3::{Digest, Sha3_256};

    let pubkey: &[u8; 32] = hsid.as_ref();
    let version: u8 = 0x03;

    let mut hasher = Sha3_256::new();
    hasher.update(b".onion checksum");
    hasher.update(pubkey);
    hasher.update([version]);
    let checksum = hasher.finalize();

    let mut combined = [0u8; 35];
    combined[..32].copy_from_slice(pubkey);
    combined[32..34].copy_from_slice(&checksum[..2]);
    combined[34] = version;

    let encoded = base32_encode(&combined);
    format!("{}.onion", encoded.to_lowercase())
}

Some things worth calling out:

The checksum uses SHA3-256, not SHA-256. This got me on the first try. Tor v3 addresses were designed when SHA3 was still new and the spec authors wanted a Keccak-family hash. If you use SHA-256 here, you get an address that looks right but won't resolve through the network.

The string ".onion checksum" includes no null terminator, no trailing whitespace. Literal bytes. I spent a good twenty minutes debugging my first attempt because I had copied the string from a spec PDF and picked up an invisible character.

Base32 encoding is RFC 4648 with no padding, lowercase output. There are at least three base32 variants in the wild; using the wrong one gives you an address that parses but doesn't match.

These aren't bugs in arti — the library is doing the right thing. They're bugs in my first implementation because I treated "convert a pubkey to an onion address" as trivial. It's not. The Tor v3 spec is specific for a reason.

Starting the Tor client

Bootstrapping arti looks like this:

use arti_client::{TorClient, TorClientConfig};
use tor_rtcompat::PreferredRuntime;

pub struct AnyhideTorClient {
    client: TorClient<PreferredRuntime>,
}

impl AnyhideTorClient {
    pub async fn new() -> Result<Self, ChatError> {
        Self::with_profile(None).await
    }

    pub async fn with_profile(profile: Option<&str>) -> Result<Self, ChatError> {
        // build config, possibly with a profile-specific state dir
        // ...
        let config = TorClientConfig::builder().build()?;
        let client = TorClient::create_bootstrapped(config).await?;
        Ok(AnyhideTorClient { client })
    }
}

The first create_bootstrapped call is slow. It downloads the Tor network consensus, picks relays, builds initial circuits. On my laptop it takes 20-60 seconds depending on network quality.

The profile parameter was added because I wanted to run multiple Anyhide identities on the same laptop without them sharing circuit state. Each profile gets its own ~/.local/share/anyhide/tor/<name>/ directory for persistent state. This matters: if two identities share Tor state, an observer with the right vantage could correlate them.

Hosting a hidden service

Once the client is up, creating a hidden service is a handful of lines:

use tor_hsservice::{config::OnionServiceConfigBuilder, HsNickname};

let nickname = HsNickname::new("anyhide-alice".to_string())?;
let svc_config = OnionServiceConfigBuilder::default()
    .nickname(nickname)
    .build()?;

let (service, request_stream) = self.client
    .launch_onion_service(svc_config)?;

let hsid = service.onion_name().ok_or(...)?;
let onion_addr = hsid_to_onion_address(&hsid);
println!("Listening on: {}", onion_addr);

The request_stream is an async stream of incoming rendezvous requests. You drive it in a loop: each request becomes a DataStream (basically a TCP stream, but over Tor) that you hand off to the chat session handler.

Connecting to a hidden service is the dual:

let (stream, _) = self.client
    .connect((onion_addr.as_str(), 80))
    .await?;

That's it. Arti handles circuit building, rendezvous, all the Tor-specific machinery. You get a stream, you read and write bytes on it.

Bidirectional connection racing

Here's a design decision I'm not sure was right.

In a classic client/server model, one party listens and the other connects. Clean, obvious. But "who's the server" introduces an asymmetry I didn't like: the server has to be online first, the client has to know the server's address, and you end up with one side structurally more burdensome than the other.

I went a different way. In Anyhide chat, both parties are equal. Both host hidden services. Both know each other's .onion addresses. When Alice wants to talk to Bob, she simultaneously:

Listens on her own hidden service for incoming connections from Bob.
Dials out to Bob's hidden service.

Whichever succeeds first wins. The other attempt is cancelled. Both parties do this symmetrically, so it's a race between four potential connections collapsed down to one.

Pros:

Nobody has to be "the server."
You can kick off a chat without coordinating who goes first.
It works when both parties are behind NATs (Tor handles that for you).

Cons:

Double the circuits being built. On a cold Tor client, that means double the bootstrapping latency for the initial attempt.
The logic for "is this incoming stream the one we're expecting?" got hairy. A stranger can still try to connect to my hidden service — I have to figure out whether to accept based on whether I recognize their identity keys in the handshake.

I think on balance it was worth it. The UX is much more pleasant: you open the chat tab and it "just connects," regardless of who opened theirs first. But if I did it again I'd at least prototype the server model first to see whether the symmetry is worth the complexity.

The handshake

Once a stream is established, the two sides need to agree on a session. Anyhide uses a three-message handshake:

Initiator --[HandshakeInit]--> Responder
         <--[HandshakeResponse]--
         --[HandshakeComplete]-->

Each message carries ephemeral public keys, identity public keys, and an Ed25519 signature over the contents. The struct:

// src/chat/protocol/handshake.rs

/// Handshake initiation message (Initiator -> Responder).
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct HandshakeInit {
    pub version: u8,
    pub ephemeral_public: [u8; 32],
    pub identity_public: [u8; 32],
    pub config: ChatConfig,
    pub i_know_you: bool,
    pub signature: Vec<u8>,
}

The i_know_you field is interesting. It's a hint: the initiator tells the responder "I have you as a contact." The responder uses this to decide how to label the incoming connection in the UI (a known face vs. a stranger — which ties into the request/accept flow in Post 6).

The signature covers everything, binding the ephemeral key to the identity key. An attacker can't swap the ephemeral key mid-stream and re-use the signature, because the signed blob is the concatenation of everything that matters.

After the responder's HandshakeResponse, both sides have enough material to derive the session keys from Post 4. The third message — HandshakeComplete — exists mostly to acknowledge the carriers and finalize the state transition before real messages start flowing. It's not strictly required for key establishment, but it gives both sides a clear "we're done with setup, switch to message mode" signal.

What arti gives you, and what it doesn't

Arti is really good at:

Building and managing Tor circuits.
Hosting and connecting to hidden services.
Handling stream multiplexing.
Integrating with Tokio/async-std runtimes.

What it isn't yet:

Fully feature-parity with C-Tor for advanced use cases.
Marked "stable for security-critical workloads." The docs are explicit: arti's onion services are experimental and not as secure as C-Tor. I put that warning at the top of my transport module too.

For a side project like Anyhide, this trade-off is fine. For something handling real dissident traffic or journalism, you probably want C-Tor and a more battle-tested stack. Arti is going to get there — the Tor Project has been iterating hard — but at the time of writing it's a caveat that needs disclosing.

Async migration notes

Anyhide started as a synchronous CLI tool. Adding Tor meant going async, which meant either partitioning the codebase or going all-in on Tokio. I went all-in, which had one specific lesson I'll share:

Don't leak async into your crypto primitives. The kdf_chain function from Post 4 is synchronous. It takes bytes, returns bytes, does no I/O. Keep it that way. The moment your crypto is async, you start thinking about cancellation safety, and cancellation safety in crypto is how you end up with partial state bugs that compromise security.

The seam I drew was: transport (Tor, TCP) is async. Session state (the ratchet, the keys) is sync, wrapped in Mutex when shared across tasks. The chat session's main loop is async and does select! on incoming messages, user input, and timers, but the cryptographic work inside each branch is a normal function call.

This has worked out well. The parts of the code where async matters are small and localized. The parts where security matters are synchronous and testable.

What's next

Post 6 is the last in the series, and it's about the user interface: building a multi-contact terminal UI with ratatui. Tabs, a Doom-style command console, request-accept for incoming connections, and the UX decisions that go into making a TUI feel like a real app rather than a scripting exercise.

Repo: github.com/matutetandil/anyhide. If you've built on arti and want to compare, drop a comment — the ecosystem is small enough that everyone's insights matter.

Why git pull --rebase should probably be your default

Matías Denda — Wed, 17 Jun 2026 13:00:00 +0000

Most developers run git pull dozens of times a week without thinking about it. And most of the time, it works.

Then one day you open a PR and the reviewer says "can you clean up the merge commits?" You look at your branch and see three "Merge branch 'main' into feature/login" commits scattered through history. The feature itself is 5 commits. The log is a mess.

That mess comes from one decision: using git pull instead of git pull --rebase.

Here's what's actually happening, and why the rebase variant produces cleaner history for teams.

The setup: diverged history

You're working on feature/login. You commit two changes locally (X, Y). Meanwhile, your teammate pushes two commits to main (C, D).

Your branch and main have now diverged. Neither is a strict superset of the other. Git needs to reconcile them when you pull.

Shared history: A → B

Your local:     A → B → X → Y       (you added X, Y)
Remote main:    A → B → C → D       (teammate added C, D)

Git has two strategies for this reconciliation.

Strategy 1: `git pull` (merge)

A plain git pull creates a merge commit that joins your local history with the remote. Your commits and the remote's commits both appear in the log, connected by a merge node.

The git log reads:

M   Merge branch 'main' into feature/login
D   fix: timeout on slow connections
Y   feat: client-side validation
C   chore: upgrade eslint
X   feat: login form
B   (shared)
A   (shared)

This is honest history — it records exactly what happened: parallel development that was joined at a specific point.

But it's also noisy history — the merge commit has no meaningful changes, and the log interleaves commits that weren't conceptually related.

Strategy 2: `git pull --rebase`

With --rebase, Git takes a different approach. It:

Temporarily sets aside your local commits (X, Y)
Fast-forwards your branch to the tip of the remote (D)
Replays your commits on top, one by one, creating new commits (X', Y')

The git log reads:

Y'  feat: client-side validation
X'  feat: login form
D   fix: timeout on slow connections
C   chore: upgrade eslint
B   (shared)
A   (shared)

Linear. No merge commit. Your work appears as if you'd started from the latest main in the first place.

Why linear history matters

When your team reviews your PR, linear history means:

The diff is cleaner. GitHub/GitLab can show a straightforward diff of what your feature adds. No merge commits cluttering the view.

The PR itself applies cleanly. When a reviewer merges your PR, it becomes a simple fast-forward on main — or a clean --no-ff if your team uses that policy. No extra merge-of-merges.

History reads like a changelog. git log --oneline main reads like a list of features shipped, one per line, in order. That's what main should look like.

Compare that to a git log full of "Merge branch 'main' into feature/login" commits — it tells you when people synchronized their branches, not what was actually built.

The commits X' and Y' are new commits

This is the subtle part that trips people up.

With rebase, X' has a different hash than X. It has the same diff — same changes to the same files — but because its parent is now D instead of B, Git considers it a new commit.

This matters for one reason: rebase rewrites history.

The golden rule of rebase

Never rebase commits that other people may have pulled.

If you rebase commits that a teammate already pulled, their local copy has the old hashes and your copy has the new hashes. When they pull again, Git sees two different sets of "the same" commits and produces duplicates, conflicts, or confusion.

The safe pattern:

Your local, unpushed branch: rebase freely
Your pushed feature branch, if you're the only one on it: rebase + git push --force-with-lease
Shared branches like main or develop: never rebase ## Making rebase your default

If you want to use rebase for pulls without typing --rebase every time:

git config --global pull.rebase true

Now every git pull is actually git pull --rebase. Most teams that care about clean history do this. You can always override with git pull --no-rebase if you want a specific merge.

For even stronger safety, combine it with:

git config --global rebase.autoStash true

This auto-stashes your uncommitted changes before the rebase and pops them back after. Saves you from "cannot rebase: you have unstaged changes" errors.

When `git pull` (merge) is actually correct

There are cases where a merge is the right choice:

Long-lived feature branches. If your feature branch has been alive for weeks and multiple people have pushed to it, rebasing it rewrites history others depend on. Use merge.

Explicit integration points. Some teams like the merge commit to mark "we integrated main into feature at this point" as a deliberate milestone. That's fine — it's a conscious choice.

When you want the team to see what happened. If a feature took three sprints and main moved a lot during that time, the merge commits show that context. For most features, you don't need that — but for big ones, sometimes you do.

The mindset shift

Pull is a boring command that most developers run on autopilot. But behind that one word are two very different operations:

Merge pull preserves history, creating merge commits. History reflects what happened.
Rebase pull rewrites history, producing a linear log. History reflects the intent. For daily work on short-lived feature branches, the rebase approach almost always produces a better result — for your PR, for your reviewer, for whoever reads git log in six months.

Switch your default. Learn the golden rule. Don't look back.

This post is adapted from Git in Depth: From Solo Developer to Engineering Teams, a 658-page book covering Git the way it's actually used in real engineering teams.

git bisect: find the commit that broke production in minutes, not days

Matías Denda — Wed, 10 Jun 2026 13:00:00 +0000

Your CI was green last Friday. Today, the payments test is failing. Somewhere between Friday's merge and now, 47 commits landed on main. Which one broke it?

Most developers answer this the wrong way: they scroll through git log, check out suspicious commits one by one, and run the test manually. An hour later, they're still guessing.

There's a command built for this exact problem. It's called git bisect, and once you learn it, you'll never debug regressions the old way again.

How bisect works

git bisect is a binary search across your commit history. You tell Git two things:

A good commit (a known point where the bug didn't exist)
A bad commit (a known point where the bug exists — usually HEAD) Git then checks out the commit halfway between them. You test. You mark it as good or bad. Git narrows the range by half. Repeat.

With 47 commits between "good" and "bad", it takes at most 6 steps (log₂ 47) to find the exact commit that introduced the bug. Versus checking every commit manually, that's the difference between 5 minutes and an hour.

The manual workflow

# Start a bisect session
$ git bisect start

# Mark the current state (HEAD) as bad
$ git bisect bad

# Mark a known-good commit
$ git bisect good a3f1d22

# Bisecting: 23 revisions left to test after this (roughly 5 steps)
# [7e4b9c1] refactor: extract payment validator

# Git has checked out a commit in the middle. Run your test.
$ npm test -- --grep "payments"

# Test passed — mark this commit as good
$ git bisect good

# Bisecting: 11 revisions left to test after this (roughly 4 steps)
# [b2d8e11] feat: add retry logic to payment API

# Test failed — mark this commit as bad
$ git bisect bad

# ... continue until Git announces the first bad commit:
# b2d8e11 is the first bad commit
# commit b2d8e11
# Author: leo@company.com
# Date:   Tue Apr 15 11:42:03
#     feat: add retry logic to payment API

# Done — reset to where you started
$ git bisect reset

In 6 commands, you know exactly which commit broke the tests. No guessing. No archaeology through git log.

Automating bisect with a script

Here's where it gets powerful. If you have a test that can reliably detect the bug, you can hand the entire bisect to Git:

$ git bisect start
$ git bisect bad
$ git bisect good a3f1d22

# Git now runs your test automatically at each step
$ git bisect run npm test -- --grep "payments"

git bisect run expects a command that:

Exits 0 if the commit is good (test passes)
Exits non-zero (1-124, 126-127) if the commit is bad (test fails)
Exits 125 if the commit can't be tested (e.g., build broken — Git will skip it) Git runs the command at each bisect step, interprets the exit code, and narrows the range automatically. You walk away, come back 5 minutes later, and Git tells you which commit broke it.

For a codebase with 50+ commits to search and a full test suite that takes 2-3 minutes per run, this is genuinely life-changing.

Writing a bisect-friendly test script

If your test isn't a simple command, wrap it in a shell script:

#!/bin/bash
# bisect-test.sh — verify the search feature

# Install dependencies (in case they changed between commits)
npm install > /dev/null 2>&1 || exit 125   # 125 = skip this commit

# Run the build
npm run build > /dev/null 2>&1 || exit 125

# Run the specific test
npm test -- --grep "search returns correct results"
# npm test returns 0 on success, 1 on failure — perfect for bisect

Now bisect it:

$ git bisect start
$ git bisect bad HEAD
$ git bisect good v2.4.0
$ git bisect run ./bisect-test.sh

The exit 125 for build failures is important. If a commit doesn't build at all, you don't want Git to mark it as "bad" — you want it to skip to another commit.

Handling flaky tests

If your test is flaky (sometimes passes, sometimes fails, even on the same commit), bisect will give you wrong answers. The fix: retry in your script.

#!/bin/bash
# Try up to 3 times, succeed if any attempt passes

for i in 1 2 3; do
  npm test -- --grep "flaky test" && exit 0
done

exit 1

This is a hack, not a fix — you should eventually make your tests deterministic. But for finding a regression today, it works.

What bisect teaches you about your codebase

After running bisect a few times, you'll start making choices that make your future self's life easier:

Atomic commits matter. If one commit mixes a feature, a bugfix, and a refactor, bisect tells you "this commit broke it" — but which part? Small, focused commits make bisect precise.

Tests are investments. A codebase with good test coverage turns bisect into a fully automated tool. Without tests, bisect still works but requires manual testing at each step.

Main should stay green. If your main has frequent broken builds, git bisect run hits exit 125 everywhere and degrades into a crawl. Teams that protect main with required CI checks get the full benefit of bisect.

The mindset shift

The real insight from bisect isn't the command — it's the shift in how you debug regressions.

Without bisect: "Something changed. Let me scroll through the log and guess."

With bisect: "Something changed. I'll let Git find it for me in 6 steps."

Once you internalize that, every "when did this break?" question has a clear procedure. You stop guessing. You start finding.

This post is adapted from Git in Depth: From Solo Developer to Engineering Teams, a 658-page book covering Git the way it's actually used in real engineering teams.

Implementing Forward Secrecy in Rust: A Double Ratchet and Three Storage Formats

Matías Denda — Tue, 09 Jun 2026 14:00:00 +0000

Post 4 of 6 on Anyhide. This post is about forward secrecy: the property that even if your private key is later compromised, past messages stay unreadable.

Forward secrecy is one of those properties that sounds like it should be easy and absolutely is not.

The goal is simple: if Alice sends Bob ten messages and then Bob's laptop gets seized and his long-term private key is extracted, the attacker should not be able to decrypt any of the ten past messages. Not one.

The way you achieve this is by never using the long-term key to encrypt message content directly. Instead, both sides derive per-message keys from a chain, and they delete each key after it's used. Extracting the long-term key later gives you nothing, because the keys that actually encrypted the messages are gone.

Signal pioneered the standard design — the Double Ratchet — in 2014. Anyhide uses a variant of it. This post walks through what I built and why.

The cryptographic primitives

Anyhide's chat uses three primitives, all of which are in standard Rust crates:

X25519 (x25519-dalek) for Diffie-Hellman key exchange.
ChaCha20-Poly1305 (chacha20poly1305) for authenticated symmetric encryption.
HKDF-SHA256 (hkdf + sha2) for key derivation.

None of these are exotic. The interesting part is how they're composed.

The SessionKeys struct

After the handshake (more on that in Post 5), both parties derive a bundle of session keys from the initial DH shared secret. Here's the struct:

// src/chat/protocol/ratchet.rs

use zeroize::{Zeroize, ZeroizeOnDrop};

/// Session keys derived from the initial DH exchange.
#[derive(Zeroize, ZeroizeOnDrop)]
pub struct SessionKeys {
    /// Key for encrypting/decrypting message headers.
    pub header_key: [u8; 32],
    /// Initial sending chain key.
    pub send_chain: [u8; 32],
    /// Initial receiving chain key.
    pub recv_chain: [u8; 32],
    /// Chain for deterministic carrier selection.
    pub carrier_chain: [u8; 32],
    /// Derived passphrase for anyhide encoding (not user-provided).
    pub passphrase: [u8; 32],
}

A few things worth noting:

#[derive(Zeroize, ZeroizeOnDrop)] — when this struct drops, all five [u8; 32] arrays are overwritten with zeros before the memory is released. This isn't a perfect defense (memory can be paged to disk, copied by the compiler, etc.) but it closes the obvious hole. Every key-bearing struct in Anyhide has this.

Separate send and receive chains — Alice's "send" chain is Bob's "receive" chain, and vice versa. Both sides advance their own chain independently as they send and receive messages. Each message gets its own key from the current chain position.

A passphrase field — this is the part that's specific to Anyhide. Remember, chat messages still get encoded as positions in a carrier file. The encoder needs a passphrase. We don't want to reuse the user's chat passphrase (which might be short), so we derive a 32-byte secret from the DH exchange and use that as the passphrase. The user never sees it; it's just a high-entropy key.

The symmetric ratchet

The core "advance one step" operation is this function:

/// Advance a KDF chain and derive a message key.
///
/// This is the symmetric ratchet step. The chain key is updated and a message
/// key is derived for encrypting/decrypting a single message.
pub fn kdf_chain(chain_key: &[u8; 32]) -> ([u8; 32], [u8; 32]) {
    let hk = Hkdf::<Sha256>::new(None, chain_key);

    let mut new_chain = [0u8; 32];
    let mut message_key = [0u8; 32];

    hk.expand(LABEL_CHAIN_ADVANCE, &mut new_chain)
        .expect("32 bytes is valid output length");
    hk.expand(LABEL_MESSAGE_KEY, &mut message_key)
        .expect("32 bytes is valid output length");

    (new_chain, message_key)
}

Input: the current chain key. Output: a new chain key and a message key. The message key encrypts exactly one message and is then discarded. The new chain key replaces the old one.

The security property: given only new_chain, you cannot recover chain_key (HKDF is one-way). Given only message_key, you cannot recover chain_key either. And since the old chain key was overwritten by the new one, a later attacker who extracts memory sees only the current chain — not any of the past ones. Past message keys are unrecoverable.

Domain separation

Notice those LABEL_* constants. HKDF uses them as "info" parameters to distinguish different derivations from the same input. Anyhide has seven labels:

const LABEL_HEADER_KEY: &[u8]    = b"ANYHIDE-CHAT-HEADER";
const LABEL_SEND_CHAIN: &[u8]    = b"ANYHIDE-CHAT-SEND";
const LABEL_RECV_CHAIN: &[u8]    = b"ANYHIDE-CHAT-RECV";
const LABEL_CARRIER_CHAIN: &[u8] = b"ANYHIDE-CHAT-CARRIER";
const LABEL_PASSPHRASE: &[u8]    = b"ANYHIDE-CHAT-PASS";
const LABEL_CHAIN_ADVANCE: &[u8] = b"ANYHIDE-CHAT-CHAIN";
const LABEL_MESSAGE_KEY: &[u8]   = b"ANYHIDE-CHAT-MESSAGE";

Why so many? Because HKDF with the same input but different labels produces uncorrelated outputs. Using distinct labels for distinct purposes means that leaking, say, a carrier chain key doesn't help an attacker derive header keys, and vice versa.

This is cheap to get right and expensive to get wrong. If you reuse the same label for two different purposes, you can end up in the situation where two independent parts of your protocol derive the same key — and now the two parts can impersonate each other's outputs.

The rule I follow: every hkdf.expand() call gets a unique label that names its purpose. No exceptions.

The DH ratchet

The symmetric ratchet is half the story. It protects message keys within a single direction of the conversation. The other half is the DH ratchet: every time the conversation direction changes (Alice sends, then Bob replies), a new ephemeral keypair is generated and the chain keys are refreshed from a fresh DH output.

This is what gives you the "double" in Double Ratchet: symmetric KDF advances within a run of same-direction messages, DH refreshes when direction changes.

The practical effect: even if an attacker compromises the full session state at some point in the conversation, they lose access to future messages as soon as the next DH ratchet step happens. Because the new ephemeral secret is generated locally and immediately mixed into the chains, the attacker can't derive the post-ratchet keys without DH-negotiating with one of the parties.

Three storage formats (and why)

Here's the part I didn't see coming when I started building this. Once you have ephemeral keys, you have to store them somewhere. And "somewhere" turns out to depend a lot on the use case.

Anyhide supports three formats:

Format 1: Individual PEM files

alice.pub      -----BEGIN ANYHIDE EPHEMERAL PUBLIC KEY-----
alice.key      -----BEGIN ANYHIDE EPHEMERAL SECRET KEY-----

The header explicitly distinguishes ephemeral keys from long-term keys. If you accidentally try to use an ephemeral key as a long-term identity, the parser yells at you. This format is good for one-off file transfers where you hand-manage keys.

Format 2: Separate consolidated JSON

// mykeys.eph.key
{
  "version": 1,
  "contacts": {
    "bob":   { "key": "base64..." },
    "carol": { "key": "base64..." }
  }
}

// contacts.eph.pub
{
  "version": 1,
  "contacts": {
    "bob":   { "key": "base64..." },
    "carol": { "key": "base64..." }
  }
}

One file for your private ephemeral keys, another for the public keys you hold for each contact. This is good when you want to keep private key material in a separate, more-protected file.

Format 3: Unified JSON

// contacts.eph
{
  "version": 1,
  "contacts": {
    "bob": {
      "my_private":   "base64...",
      "their_public": "base64..."
    }
  }
}

One file per contact, containing both sides of the key pair. This is what the chat client uses, because during a live chat the two things you need — your private key for this contact and their public key — are always used together. Splitting them into separate files would just be pain.

Why three?

I tried to collapse these down. I couldn't. Each use case has a different access pattern:

Format 1 (individual PEM) is good for batch operations where you're moving keys between machines. PEM files are human-inspectable, work with standard tools, and can be attached to emails or printed to paper.
Format 2 (separate consolidated) is good for archival — you want many contacts in one file, but with clear separation between private and public material. The file you back up is different from the file you share.
Format 3 (unified per-contact) is good for runtime — the chat client needs fast access to the current key pair for one contact at a time. Having both halves co-located eliminates a class of bugs where a reply uses a mismatched pair.

Rather than force users into one pattern, I let each use case pick. The cost is some serde code and documentation. The benefit is that the tool never makes the user fight the storage model.

If I were writing this today, I'd probably unify them behind a KeyStore trait and let the caller pick a backend. Right now they're three different code paths with similar logic. Not the worst tech debt but it bothers me.

The ratchet in action

From the library API, using the ratchet looks like this:

use anyhide::{encode_with_config, EncoderConfig};

let config = EncoderConfig {
    ratchet: true,
    ..Default::default()
};

let result = encode_with_config(
    &carrier,
    "hello!",
    "pass",
    &bobs_current_public_key,
    &config,
)?;

// result.code is what you send on the wire.
// result.next_keypair is your new ephemeral keypair for the next round.
// Save it. When Bob replies, use next_keypair.secret to decrypt.

And when Bob decodes:

let decoded = decode_with_config(&code, &carrier, "pass",
                                  &my_secret_key, &DecoderConfig::default());

if let Some(next_public) = decoded.next_public_key {
    // Alice included her new public key for next round.
    // Store it and use it for your reply.
    update_contacts_file("bob", &next_public)?;
}

The ratchet metadata rides inside the encrypted payload, not alongside it. An attacker on the wire can't see that key rotation is happening, can't see the ephemeral public keys, can't distinguish a ratcheting session from a non-ratcheting one.

What's coming

Post 5 is about how two parties find each other in the first place and set up the initial session. That's the handshake, and it runs over Tor hidden services using the arti-client crate. I haven't seen a lot of content on building on top of arti, so I'll spend some time on the rough edges and on what Tor gives you (and what it doesn't).

Post 6 closes out the series with the terminal UI: ratatui, multi-contact tabs, a command console overlay modeled on Doom's, and the UX work to make cryptography not feel hostile to use.

Both dropping every two weeks.

Repo: github.com/matutetandil/anyhide. If you're building with the Double Ratchet or similar constructions in Rust, I'd love to compare notes.

Code review when half the PR is AI-generated

Matías Denda — Wed, 03 Jun 2026 13:00:00 +0000

Picture a reviewer opening a PR on Monday morning. The title says "Add user search endpoint." They click on the Files tab.

+847 −12

Eight hundred forty-seven lines added. The reviewer has maybe 15 minutes before the next meeting. They scroll through the diff. The code looks clean — variable names are descriptive, functions are reasonable length, there are tests. They skim, see nothing obviously wrong, and approve.

Three weeks later, the feature ships. Users complain the search is slow. Two weeks after that, the database team files an urgent ticket: a query is scanning 4 million rows on every request. The fix takes a day. The post-mortem blames "insufficient load testing."

The post-mortem is wrong. The problem was that a reviewer with 15 minutes can't meaningfully review 847 lines of AI-generated code. And that's the new reality for half the PRs most teams see in 2026.

The review problem AI created

Before AI, review bandwidth loosely tracked writing bandwidth. If your team wrote 5 PRs a day, they produced at roughly human speed, which meant they were reviewable at roughly human speed. Reviewers could read at the pace code was written.

AI broke that equation. Writers can now produce 10x more code in the same time. Reviewers still read at human speed. Same team, same number of reviewers, 10x more code to review.

The result is what every tech lead I've talked to confirms: review quality has dropped across the industry since AI adoption. Not because reviewers got lazier. Because the volume became impossible to review well at the bar they used to maintain.

What bad AI-generated code actually looks like

If you've reviewed AI-generated PRs, you've probably noticed the problem isn't the kind of thing that jumps out. AI rarely produces code that's obviously broken. The dangerous code looks fine.

Some patterns I see repeatedly:

The library that doesn't exist. AI invents a package. The code imports @acme/super-fast-cache, uses it throughout, and there's no such package. It fails at install time, so it gets caught — but the reviewer didn't catch it. The reviewer trusted that if it's imported, it exists.

The API that doesn't work that way. AI uses methods that don't exist on real libraries, or exist but with different signatures. redis.mget(keys, { default: 0 }) — Redis doesn't have a default option. The code runs, the option gets ignored, defaults don't apply, bugs surface in production.

The silent assumption. AI writes code that makes assumptions it doesn't verify. It assumes input is UTF-8. It assumes timestamps are in UTC. It assumes the database timeout matches the service timeout. A reviewer reading the code sees nothing wrong because the assumptions are invisible — they exist in what wasn't written.

The "works in the tutorial" pattern. AI produces code that works for the tutorial case and fails at scale. The pagination example. The authentication middleware that doesn't handle token refresh. The file upload that buffers everything in memory. Every one of these looks clean in isolation.

These are not the kinds of bugs a junior reviewer catches. They're the kinds a senior reviewer catches because they've seen them before.

The skill that suddenly got very valuable

If AI broke the writing-to-reviewing ratio, the people who unbreak it are reviewers who can go through large diffs fast without losing signal. That's a skill. It's always been valuable. It's now scarce.

What senior reviewers actually do that juniors don't:

They read diffs top-down, not linearly. Junior reviewers start at line 1 and read through. Senior reviewers scan structure first: What files changed? What's the shape of the change? Is the scope what the PR title claims? Only after they understand the shape do they drill into code.

They look for what's missing, not what's there. A reviewer who reads AI code line by line will find typos and style issues. A reviewer who asks "what tests would fail if I were trying to break this?" finds the real problems. Missing error handling, missing edge cases, missing cleanup in failure paths.

They flag assumptions, not just bugs. Senior reviewers comment: "What happens if the user list is empty?" "What's the behavior when the upstream service times out?" "Is this endpoint idempotent? If not, should it be?" These questions don't point to broken code — they point to the invisible choices AI made by default.

They know the 80/20 of the codebase. A senior reviewer who's been on a codebase for a year knows which files are load-bearing, which services are latency-sensitive, which modules have caused production incidents. They weight their attention accordingly — a one-line change in the payment service gets more scrutiny than a 100-line change in the marketing page.

None of this is new. All of it got more valuable.

What the review bar has to look like now

The reviewer's mandate has shifted. It used to be "catch obvious bugs." It now has to be "verify the code is correct for this codebase, at this scale, for this business."

Concrete changes that mature teams are adopting:

Smaller PRs, enforced. If AI lets developers write 800-line PRs in a morning, the team needs to cap PR size institutionally. Most teams landing on a ~400-line max, split across multiple PRs when exceeded. The rationale: a 400-line PR can still be reviewed well in 20-30 minutes; 800 lines cannot.

Required "context" section in PR description. Not just "what does this do" — but "what scale does this need to handle? What failure modes did you consider? What did AI write that you verified carefully?" Makes invisible decisions visible.

Pairing AI-heavy code with focused review. If a PR is substantially AI-generated, it gets a more experienced reviewer by default. Teams assign this through CODEOWNERS or routing rules.

Review budgets in schedules. Used to be that review was something engineers did in the cracks of their day. With AI volume, review is a first-class activity. Teams that take this seriously reserve 1-2 hours per day for deep review, protect it like any other focused work.

A practical setup

Here's a GitHub Actions snippet that enforces PR size limits:

# .github/workflows/pr-size-check.yml
name: PR size check
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-size:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Check PR size
        run: |
          CHANGES=$(git diff --shortstat origin/${{ github.base_ref }}...HEAD \
            | awk '{ print $4 + $6 }')
          echo "Total changed lines: $CHANGES"
          if [ "$CHANGES" -gt 400 ]; then
            echo "::error::PR exceeds 400 lines ($CHANGES). Split into smaller PRs."
            exit 1
          fi

This isn't a perfect tool. Some legitimate PRs are larger (big refactors, generated code). The point isn't to be strict — it's to force a conversation every time a PR exceeds a reasonable size. Sometimes the conversation concludes "yes, this one is fine." Often it concludes "this could be three PRs."

And a template for PR descriptions that surfaces invisible AI decisions:

<!-- .github/pull_request_template.md -->

## What changed

<!-- High-level summary -->

## Why this change

<!-- Business or technical reason -->

## Context that doesn't live in the code

*Expected scale:* <!-- e.g., 10k req/min, 1M rows -->
*Failure modes considered:* <!-- e.g., upstream timeout, DB unavailable -->
*AI-assisted sections:* <!-- Which parts used AI, and what you verified -->

## Testing
<!-- How you tested this beyond CI -->

## For the reviewer
<!-- What to pay special attention to -->

This template takes an extra 2 minutes to fill out. It saves reviewers far more than that, and forces the PR author to surface the context AI couldn't generate on its own.

The hardest thing about all this

The hardest thing about post-AI code review isn't technical. It's cultural.

Teams that were getting along fine with casual review are suddenly finding that their production incident rate is climbing, and the incidents trace back to merged PRs that looked fine. The temptation is to blame AI and argue that we should use it less. That's the wrong conclusion — AI is here, and the productivity gains are too real to forgo.

The right conclusion is harder: the review bar has to go up, and teams need to invest in reviewing like they invest in writing. That means explicit time budgeted, training for junior reviewers, pairing on complex reviews, and accepting that shipping 10x more code means spending more total time on quality, not less.

If you're a tech lead reading this: your team needs explicit guidance on what good review looks like in this new context. Nobody can figure it out on their own. The old instincts don't scale to AI-era volume.

If you're a senior IC: your review skill just became one of your most valuable assets. Invest in it. Slow down on your own writing if necessary. A thoughtful review that catches a scaling issue before production is worth more than a dozen PRs merged without one.

If you're a junior: reviewing is the fastest way to learn the codebase and develop senior judgment. Pair on reviews with people who catch what you don't. Ask them to explain their reasoning. That's where the real training happens now — not in writing code AI will increasingly write for you, but in evaluating whether AI's output is correct for your specific context.

Back to the amplifier

Two weeks ago I argued that AI amplifies what developers already are. The same applies to reviewers.

A senior reviewer using the new review practices — smaller PRs, explicit context, reserved time — catches 10x more issues than they used to, because they're reviewing higher-density code more deliberately.

A junior reviewer rubber-stamping AI-generated PRs misses 10x more issues than they used to, because the volume grew faster than their experience.

Same AI. Same reviewers. Radically different outcomes.

The fundamentals of code review — reading for missing cases, flagging assumptions, knowing your codebase — haven't changed. They've just become the thing separating teams that thrive in the AI era from teams drowning in production incidents.

Don't skip them. They're not optional. They're more important now than ever.

This post is part of a series on AI and engineering fundamentals. My book Git in Depth has a full chapter on code review — the principles that don't change whether code is human-written or AI-generated.

See all my articles on Git and engineering practice: dev.to/mdenda.

Most of Your Microservice Is Plumbing. What If You Stopped Writing It?

Matías Denda — Tue, 02 Jun 2026 14:00:00 +0000

TL;DR — Every microservice is mostly plumbing: an HTTP server, connection pools, marshalling, retries, health checks, wiring — the same in every service, rewritten with different nouns. Mycel is a declarative runtime that lets you declare that plumbing instead of writing it, then runs the result as a real production microservice. When I showed it off, almost everyone assumed "declarative = prototyping toy." This post is why that's backwards — and what the hard parts (auth, retries, migrations) look like when they're config instead of code.

Be honest about your last microservice

Think about the last service you wrote. A router. A handler. A DTO struct. A validation layer. A connection pool. A query. Marshalling the result back to JSON. Retry logic around the flaky call. A health endpoint that returns 200 whether or not the database is actually reachable. Then the next service, where you wrote the same dozen things again with different nouns.

Almost none of that is your service. It's plumbing — identical in shape across every microservice you'll ever write, just with the nouns swapped. The part that's genuinely yours — the handful of decisions that make this service this one and not some other — is a thin layer riding on a thick stack of boilerplate you've written a hundred times.

So a while ago I built a runtime where you declare the plumbing instead of writing it: you describe what connects to what, and it runs as a real microservice. I showed the three-file version in a previous post — and the response taught me something I didn't expect.

Everyone filed it under "prototyping" — and that's on me

The post got a generous, sharp response. And almost every serious reply said some version of the same thing:

"Love the concept for rapid prototyping and internal tools."
"zero-code-to-running-microservice is the fun demo… the honest test is what happens at file #4."
"excellent for validating concepts quickly… how does it handle complex logic as it scales beyond three files?"

Read those again and notice the vocabulary: prototyping, internal tools, the fun demo, validating concepts quickly. That's not three people describing my tool. That's three people describing a category — and concluding, reasonably, that production is where the category gives out.

I stared at this for a while not understanding why everyone landed on "toy." Then it clicked: they didn't land there. I put them there.

A reader forms a category in about five seconds, from the headline, before evaluating anything. My headline was "3 files, zero code." In the mental map of basically every engineer, "no code + something running instantly" is a settled drawer: no-code / low-code — Bubble, Zapier, Retool. And that drawer ships with a verdict already inside it: brilliant for prototypes and internal tools, quietly falls apart when you need a real production service.

So when I handed people "zero code," they didn't run the tool through their judgment and conclude "prototype-only." They dropped it in the drawer and the drawer answered for them. You can see it in the exact words they used — they were describing the shelf, not the software. And you can't argue someone out of a conclusion they imported wholesale with the label.

That's on me. "Zero code" is a true sentence that points at the wrong category. So let me throw the label out and say what the thing actually is.

What Mycel actually is

Mycel is a declarative microservice runtime. You describe what your service connects to and how data moves between those connections; the runtime interprets that config at runtime and runs as a real microservice.

Three things that drawer gets wrong about it:

It's not a visual builder. There are no boxes to click. It's config — text, in version control, reviewed in pull requests, diffable like any other code artifact. Closer in spirit to a Terraform config or an nginx.conf than to a drag-and-drop canvas. (That's the only place I'll lean on that comparison — not as a pitch, just to move you out of the wrong drawer.)

It's not a code generator. This is the one I most want to kill. One commenter put the fear precisely: "'zero code' quietly becomes 'a lot of code I didn't write and don't understand.'" That's a real and rational fear — of codegen. Scaffolding tools spray code you now own and can't fully read. Mycel generates nothing. There is no emitted Go sitting in your repo. The runtime reads your config and does the thing; "file #4" is more configuration, never a heap of opaque generated source. There's nothing to inherit because nothing was generated.

It's production-first, not demo-first. I don't run it to mock things up. I run it in production today — consuming from a hosted message broker, on Kubernetes, doing real work. The three-file version is the smallest legible example, not the ceiling.

The "file #4" test — where the engineering actually lives

The fairest pushback I got named the exact things that separate a demo from a service: validation beyond type-checking, retry logic with specific backoff curves, health checks that test downstream dependencies, env management across services — plus auth, migrations, rate limiting.

Here's the whole bet: those are configuration concerns, not code concerns. They stay declarative instead of becoming the 2,000 lines of glue you hand-write and maintain. Quick tour.

Validation beyond types — field constraints plus custom rules (regex, CEL, or WASM):

type "signup" {
  email    = string({ format = "email" })
  age      = number({ min = 18, max = 120 })
  password = string({ min_length = 12, pattern = "..." })
  plan     = string({ enum = ["free", "pro"] })
  tax_id   = string({ validator = "valid_vat" })   # custom CEL/WASM rule
}

Retry with real backoff curves — not just "try N times":

error_handling {
  retry {
    attempts  = 5
    delay     = "1s"
    max_delay = "30s"
    backoff   = "exponential"   # or linear / constant
  }
}

…plus a circuit breaker and per-error-class dispositions (ack / retry / requeue / reject).

Health that actually probes dependencies — /health/ready doesn't just return 200. It pings every connector (DB PingContext, Redis PING, and so on) and reports per-component status; mycel check runs the same probes before the service accepts traffic.

Env across services — an env() function, per-environment overlays (environments/prod.mycel), .env support, environment-aware defaults (debug logs + hot reload in dev; JSON logs + locked-down errors in prod), and connector profiles to swap backends per environment.

And the one that most clearly isn't a toy: a transactional, multi-statement write — clear previous rows, insert a parent, capture its autoincrement id, loop over N children that reference it, all atomic in one DB transaction — declared in config. That's the kind of "complex" that used to force you straight back into code.

Want file #4 for real instead of my word for it? The auth example in the repo is a single config with persistence, JWT, MFA, brute-force lockout, sessions, and audit. That's "what happens when you add the hard stuff," and it's still config.

The honest tradeoff

I'm not going to pretend complexity evaporates. It doesn't. Auth is inherently complex, so an auth config is genuinely more involved than a three-line flow.

But be precise about what the tradeoff is. It is not "clean demo → hidden code you didn't write." It's "clean demo → more config." What you trade is writing and maintaining the how for learning the vocabulary of the what. Your nginx.conf grows as you add TLS, caching, and rate limiting — but it never turns into C you have to maintain. Same shape here.

That's a real cost — there's a vocabulary to learn — but it's a fundamentally different cost than "a thousand lines of generated Go I'm now on the hook for."

When you outgrow the vocabulary

There's a ceiling, and I'd rather name it than pretend it away. When something genuinely doesn't fit declaratively, the escape hatch is a WASM plugin: you write that one piece in Rust or Go, compile it, and the runtime calls it. That is code you write and own.

I want that seam to be obvious, not hidden. The declarative layer handles the 90% that's plumbing; the escape hatch covers the 10% that's truly yours — and you never lose the ability to drop to real code for it. A tool that pretends it covers 100% of cases is lying; one with a clear seam is just being honest about where the line is.

Prototyping vs. production is the wrong axis

Here's the reframe I should have led with.

"Good for prototypes, bad for production" treats maturity as the axis. It isn't. The real axis is plumbing vs. logic that's genuinely yours. Every microservice is mostly plumbing — HTTP server, connection pools, marshalling, retries, health, wiring — with a handful of decisions on top that make it this service and not some other one.

Mycel removes the plumbing. That's just as true when you're prototyping as when you're on Kubernetes serving real traffic — it's the same tool doing the same job at both ends. It was never "a prototyping tool that struggles in production." It's a runtime that deletes the part of the work that was identical in both places, and leaves you the part that was always the point.

The three-file demo wasn't the product. It was the smallest honest look at the product. File #4 is where it gets interesting — and file #4 is still config.

Try it

Repo: https://github.com/matutetandil/mycel
File #4, for real: the auth example — persistence + JWT + MFA + brute-force + sessions + audit, in config
Docker: ghcr.io/matutetandil/mycel

If you read the last post and thought "nice toy," this one's my rebuttal — and I'd still rather have you try to poke holes in it than nod along. That's genuinely how it gets to production-grade. Next post: what happens to a service like this when the power actually goes out.

What happens when an AI agent commits to your repo

Matías Denda — Wed, 27 May 2026 13:00:00 +0000

A few weeks ago, I argued that AI is not a great equalizer — it's a great amplifier. It amplifies what developers already are, for better and for worse. Juniors with AI produce junior code at senior speed. Seniors with AI produce senior code at supernatural speed.

This post is about where that amplification becomes visible: your Git history.

Every team that's adopted AI coding assistants — Claude Code, Cursor, GitHub Copilot, Windsurf — has introduced a new kind of contributor to their repo. Sometimes it's tagged explicitly (co-authored-by: claude). Sometimes it's invisible. Either way, the commits AI produces (or AI-assisted developers produce) look different, and Git reveals the difference within weeks.

Here's what to watch for, and why the fundamentals of Git practice matter more now than ever.

The two kinds of AI-assisted commits

Open any repository that's been using AI assistance for a few months and run this:

git log --oneline --since="3 months ago" | head -50

You'll see two patterns emerge.

Pattern A — the junior-amplified commit:

a7f3c21 fix stuff
9e2b8f4 more changes
12a4e5c update
8d1f90b fix tests
f5a23de wip

Large commits, vague messages, no clear scope. The developer asked AI "fix this bug" and committed whatever AI produced. A month later, nobody knows what any of these commits actually do.

Pattern B — the senior-amplified commit:

a7f3c21 feat(search): add cursor-based pagination for users endpoint
9e2b8f4 perf(search): replace LIKE '%q%' with full-text index
12a4e5c test(search): add edge cases for empty query and unicode input
8d1f90b refactor(search): extract query builder into reusable module
f5a23de chore(deps): upgrade full-text-search-lib to 2.3.1

Small, atomic, well-described commits. The developer guided AI to produce focused changes, committed each unit separately, and wrote messages a future debugger will thank them for.

Same AI. Same prompts, roughly. Radically different commit history.

Why this matters

A Git history full of Pattern A commits is a Git history that can't be bisected, can't be reverted cleanly, can't be understood by anyone who joins the team later. Every tool that relies on commit granularity — git bisect, git revert, git blame, git log --follow — degrades to the point of uselessness.

Before AI, bad commits came from rushed developers. They were relatively rare because writing bad commits took effort too — a huge "fix stuff" commit still required the developer to write the code. Now, bad commits are effortless. AI produces working code fast, and if the developer doesn't pause to structure the commits, everything lands as one undifferentiated blob.

This is the amplification effect in its purest form: AI doesn't cause bad commit practice, but it removes the friction that used to limit how many bad commits a team could produce per day.

What senior AI-assisted developers do differently

If you've worked with a senior developer using Claude Code or Cursor for real production work, you'll notice they don't work the way demos suggest. Demos show a developer asking AI to build a feature, accepting the output, committing, done. Senior developers rarely work that way.

What they actually do:

They break work into commits before writing a single line. Before prompting AI, they think: "This feature needs three commits — the refactor, the new endpoint, the tests. I'll work on one at a time." Then they prompt AI per-commit, not per-feature.

They review AI output for what it didn't do. AI produces code that answers the prompt. It doesn't answer the things you didn't ask about. Seniors read AI output asking "what edge case is missing? what error isn't handled? what happens at scale?" — and iterate until the output is actually ready.

They rewrite commit messages by hand. Even when tools offer auto-generated messages, seniors rewrite them. Because the message needs to explain why, not what — and AI can see what changed but not why it was the right change.

They separate refactors from features. A change that both refactors existing code and adds a new feature is a bisect nightmare. Seniors do the refactor, commit it, verify nothing broke, then add the feature as a separate commit.

None of this is specific to AI. These are basic fundamentals of Git hygiene. AI just made them dramatically more important, because AI makes it easier to skip them.

What Git reveals, three months in

Run these queries on any team that's been using AI assistance for a while, and the amplification effect becomes quantifiable:

Commits per PR — the concentration test:

# How many commits does each PR typically have?
gh pr list --state merged --limit 100 --json commits \
  --jq '.[] | .commits | length' | sort | uniq -c | sort -rn

A healthy team, AI-assisted or not, has most PRs with 2-6 commits. If suddenly your team has half of PRs with 1 commit of 500+ lines, that's the junior-amplified pattern.

Commit message quality — the scoping test:

# Average commit message length
git log --since="3 months ago" --pretty=%s \
  | awk '{ sum += length($0); count++ } END { print "avg length:", sum/count, "chars" }'

Teams writing good commit messages average 50-80 characters on the subject line. Teams that rubber-stamp AI's first suggestion average 20-30. If your team dropped to the lower range after adopting AI, it's a signal.

Changed files per commit — the atomicity test:

# How many files does each commit touch on average?
git log --since="3 months ago" --name-only --pretty=format:'---' \
  | awk '/^---$/ { if (count > 0) print count; count = 0; next } { count++ } END { if (count > 0) print count }' \
  | awk '{ sum += $1; n++ } END { print "avg files per commit:", sum/n }'

Atomic commits touch 1-5 files. If your average jumped to 15+ after AI adoption, commits are no longer scoped to individual changes.

These aren't vanity metrics. Each one directly correlates with how debuggable, revertable, and understandable your codebase is.

Three practical habits that preserve commit quality

If you want your team to use AI without destroying your Git history:

1. Commit before asking AI to do the next thing. Treat each AI interaction as one logical unit of work. If the unit spans multiple concerns, the unit is too big — break it down first, commit as you go.

2. Write the commit message yourself. Tools that auto-generate messages from diffs are convenient, but they miss the "why." Spend 30 seconds writing the message in your own words. Future you will save hours.

3. Review the diff before committing, even if AI wrote it. Seniors do this automatically. It's the equivalent of proofreading a translation — AI translated intent to code, you verify the translation matches what you meant. Unreviewed commits are a liability, AI-generated or not.

A small convention that helps

Some teams have adopted a tag in commit messages to mark AI assistance explicitly:

feat(auth): add SAML SSO provider [ai-assisted]

Implemented SAML 2.0 response parsing using python-saml library.
Generated test cases for malformed responses and signature
validation failures.

AI helped with: SAML library integration, test generation
Human decisions: auth flow design, error handling strategy

This is optional and your team may or may not want it. But it makes two things explicit: that AI was involved, and what specifically the human brought to the table. When a bug surfaces months later and someone git blames the line, they can see immediately whether the code was AI-generated and what context the human applied.

It's not a defensive measure ("don't blame me, AI wrote it"). It's an informational one ("here's the context you need to understand this change").

The quiet thing seniors know

If you've been using AI assistants seriously for a year, you've probably noticed something that doesn't make the headlines: you're more careful about commit hygiene now than you were before.

Pre-AI, if you wrote sloppy commits, you paid the cost linearly. You produced maybe 5-10 commits a day, so sloppy habits had bounded blast radius. Post-AI, you produce 30-50 commits a day. Sloppy habits destroy the codebase in a quarter.

The seniors who thrive in this new environment aren't the ones using AI the hardest. They're the ones who realized early that AI's productivity gain has to be matched by increased discipline elsewhere. Every minute saved by AI in writing code gets spent in structuring, reviewing, and documenting that code.

That's the amplifier in action. Use it well, and your output multiplies. Use it carelessly, and your technical debt multiplies just as fast.

This post is part of a series on AI and engineering fundamentals. My book Git in Depth is 658 pages on the Git fundamentals that AI assumes you already know — including atomic commits, commit message anatomy, and bisect workflows.

See all my articles on Git and engineering practice: dev.to/mdenda.

I Built a REST Microservice With a Database in 3 Files — and Wrote Zero Code

Matías Denda — Tue, 26 May 2026 19:00:00 +0000

TL;DR — Mycel is an open-source runtime that turns configuration into a real microservice. You describe what you want (this endpoint reads from that database); Mycel handles the how (HTTP server, query, marshalling, validation, retries). Same binary for every service — only the config changes. It's pure Go, speaks standard protocols, and there's one running in production behind this post. Repo at the end.

The boilerplate tax

Be honest about how your last microservice started. A router. A handler. A DTO struct. A validation layer. A database pool. A query. Marshalling the result back to JSON. Error handling around all of it. Then the next service, where you write the same seven things again with different nouns.

Most microservices aren't interesting code. They're plumbing — data comes in through a protocol, gets reshaped and checked, goes out to a store or another service. We keep rewriting that plumbing because the shape changes even though the pattern never does.

What if you didn't write the plumbing at all? What if you just declared the shape and something else ran it — the way nginx runs a web server from a config file instead of making you write the socket loop?

That's Mycel.

The whole service, in three files

Here's a complete REST API backed by SQLite. Full CRUD. No application code — just configuration.

config.mycel — what the service is:

service {
  name    = "users-service"
  version = "1.0.0"
}

connectors/connectors.mycel — what it talks to:

# An HTTP server on :3000
connector "api" {
  type = "rest"
  port = 3000
}

# A SQLite database
connector "sqlite" {
  type     = "database"
  driver   = "sqlite"
  database = "./data/app.db"
}

flows/flows.mycel — how data moves:

flow "list_users" {
  from {
    connector = "api"
    operation = "GET /users"
  }
  to {
    connector = "sqlite"
    target    = "users"
  }
}

flow "get_user" {
  from {
    connector = "api"
    operation = "GET /users/:id"
  }
  to {
    connector = "sqlite"
    target    = "users"
  }
}

flow "create_user" {
  from {
    connector = "api"
    operation = "POST /users"
  }
  to {
    connector = "sqlite"
    target    = "users"
  }
}

That's it. A connector is a bidirectional adapter — it can be a source (data comes from it) or a target (data goes to it). A flow wires a source to a target. Read the config out loud and it tells you exactly what the service does: "GET /users reads from the users table."

Mycel scans the config directory recursively, so the file layout is yours to choose — one file or fifty. I keep one flow per file in real projects; here they're grouped to keep the example short.

Running it — in a container

SQLite needs its table to exist first (Mycel serves the schema you give it; it doesn't invent one). One command:

mkdir -p data
sqlite3 data/app.db 'CREATE TABLE users (
  id    INTEGER PRIMARY KEY AUTOINCREMENT,
  email TEXT,
  name  TEXT
);'

Now run Mycel as a container, mounting your config in and exposing the port:

docker run --rm \
  -v "$(pwd)":/etc/mycel \
  -p 3000:3000 \
  ghcr.io/matutetandil/mycel

It boots and tells you exactly what it wired up:

    ███╗   ███╗██╗   ██╗ ██████╗███████╗██╗
    ████╗ ████║╚██╗ ██╔╝██╔════╝██╔════╝██║
    ██╔████╔██║ ╚████╔╝ ██║     █████╗  ██║
    ██║╚██╔╝██║  ╚██╔╝  ██║     ██╔══╝  ██║
    ██║ ╚═╝ ██║   ██║   ╚██████╗███████╗███████╗
    ╚═╝     ╚═╝   ╚═╝    ╚═════╝╚══════╝╚══════╝
    Declarative Microservice Runtime v2.1.0

    Service: users-service v1.0.0
    Environment: development
    Port: 3000

    Connectors:
    ✓ api (rest) listening on :3000
    ✓ sqlite (database) → ./data/app.db

    Flows:
      GET    /users → sqlite:users
      GET    /users/:id → sqlite:users
      POST   /users → sqlite:users
    ✓ admin (http) health + metrics + debug on :9090

    ✓ Ready! Press Ctrl+C to stop.

Note the last line before Ready: you also got a /health, /metrics (Prometheus), and a debug endpoint on :9090 for free — nobody declared those. Now hit the API like any other REST service:

# Create a user
curl -X POST localhost:3000/users \
  -H 'Content-Type: application/json' \
  -d '{"email":"ada@example.com","name":"Ada Lovelace"}'
# {"affected":1,"id":1}

# List them
curl localhost:3000/users
# [{"email":"ada@example.com","id":1,"name":"Ada Lovelace"}]

# Fetch by id
curl localhost:3000/users/1
# [{"email":"ada@example.com","id":1,"name":"Ada Lovelace"}]

A working CRUD microservice. Zero lines of Go, JavaScript, or anything else. From the wire it's indistinguishable from one hand-written in Go or NestJS — it speaks plain HTTP and JSON, and a client can't tell the difference. That's the point.

(The write returns {"affected":1,"id":1} — rows affected and the new id — and reads come back as JSON arrays. That's the raw database flow talking; the next section is how you shape it into whatever contract you want.)

"Okay, but real services need more than raw CRUD"

They do. And this is where declarative stops being a toy. You add capabilities by declaring more inside the flow — not by dropping into code. Everything below lives in the same create_user flow you already saw.

Validation — define a type and attach it:

type "user" {
  email = string
  name  = string
}

flow "create_user" {
  from {
    connector = "api"
    operation = "POST /users"
  }

  validate {
    input = "type.user"
  }

  to {
    connector = "sqlite"
    target    = "users"
  }
}

Now a bad request is rejected before it ever reaches the database:

curl -X POST localhost:3000/users \
  -H 'Content-Type: application/json' \
  -d '{"email":"x@y.com"}'
# {"error":"validation error on 'name': field is required"}

Transforming the data — reshape the payload between from and to, with CEL expressions. The transform block sits inside the flow, right where the data passes through:

flow "create_user" {
  from {
    connector = "api"
    operation = "POST /users"
  }

  validate {
    input = "type.user"
  }

  transform {
    external_id = "uuid()"
    email       = "lower(input.email)"
    name        = "trim(input.name)"
  }

  to {
    connector = "sqlite"
    target    = "users"
  }
}

Each line is field = "<CEL expression>". Send a messy payload and watch it get normalized on the way in:

curl -X POST localhost:3000/users \
  -H 'Content-Type: application/json' \
  -d '{"email":"ADA@EXAMPLE.COM","name":"  Ada Lovelace  "}'

curl localhost:3000/users
# [{"email":"ada@example.com","external_id":"870339c1-9e53-498c-8217-c350556f284b","id":1,"name":"Ada Lovelace"}]

Email lowercased, name trimmed, a UUID generated — declared in three lines, applied before the write.

Retries with backoff — for when a downstream is flaky, add an error_handling block to the flow:

error_handling {
  retry {
    attempts = 3
    delay    = "1s"
    backoff  = "exponential"
  }
}

Want to swap SQLite for PostgreSQL? Change the connector — the flows don't move. Want to consume from RabbitMQ instead of HTTP? Change the from. The flow is the stable thing; the edges are pluggable. Mycel ships connectors for REST, PostgreSQL, MySQL, MongoDB, Kafka, RabbitMQ, gRPC, GraphQL (Federation v2), Redis, S3, WebSocket, and more — all behind the same connector block.

What this isn't

Two honest disclaimers, because the concept invites two wrong assumptions:

It's not an orchestrator. Mycel doesn't supervise other services — it is a microservice. If the process dies, Kubernetes (or Docker, or systemd) restarts it, exactly like any service in any language. What Mycel handles is keeping your in-flight data safe across that restart — broker redelivery, idempotency, retries. (That's its own post.)
It's not magic for genuinely custom logic. When you need behavior no connector or transform expresses, Mycel runs WASM plugins — you write that one piece in Rust or Go, compile to WebAssembly, and the runtime calls it. The declarative model bends to real logic; it doesn't pretend logic doesn't exist.

Why I built it

I got tired of the gap between "this service is conceptually trivial" and "this service is still 800 lines of boilerplate I have to write, test, and maintain." nginx closed that gap for web serving. Terraform closed it for infrastructure. Mycel closes it for microservices: the binary is the same everywhere, and the configuration is the program.

It's pure Go, no CGO, one static binary. There's a real service running on it in production right now — which is what convinced me this wasn't just a neat idea.

Try it

Repo: https://github.com/matutetandil/mycel
This example: it's in examples/basic — clone it and docker run (or grab the binary)
Docker: ghcr.io/matutetandil/mycel

If the idea of declaring a microservice instead of writing one is interesting (or infuriating), I'd genuinely like to hear it in the comments. Next post: what happens to a config-driven service when the power goes out — the part everyone assumes a declarative tool gets wrong.

Mycel is open source and early. Stars, issues, and "this would never work because…" arguments all welcome.

Plausible Deniability in Cryptography: Building a Duress Password in Rust

Matías Denda — Tue, 26 May 2026 14:00:00 +0000

Post 3 of 6 on building Anyhide, a Rust steganography tool. This post is about threat models where the adversary isn't a server or a middleman — it's a person with leverage.

Most cryptographic tools are designed against adversaries who intercept things. They sit on the wire and try to decrypt what they see. They mine keys out of RAM. They exploit implementation bugs.

But there's another adversary that most crypto doesn't help you with: the one who has you in a room and wants you to type the passphrase. This is called "rubber-hose cryptanalysis" in the literature, or sometimes "the $5 wrench attack" after an old xkcd. Neither phrase really captures it. The point is simple: if someone can compel you to unlock the ciphertext, the math doesn't save you.

What can save you — partially, imperfectly, but usefully — is plausible deniability. The idea: design the tool so that the passphrase you give under coercion reveals something, but not the real thing. And make sure the revealed thing is indistinguishable from what you'd get with the real passphrase.

In Anyhide this is called the duress password. This post is about how it works and how I implemented it.

The design goal

When you encode a message, you can optionally supply a second message and a second passphrase:

anyhide encode \
  -c carrier.mp4 \
  -m "the drop is at 0400 on wednesday" \
  -p "real-passphrase" \
  --decoy "nothing important here" \
  --decoy-pass "decoy-passphrase" \
  --their-key bob.pub

The encoder produces one ciphertext that contains both messages. When Bob decodes:

With real-passphrase → "the drop is at 0400 on wednesday"
With decoy-passphrase → "nothing important here"
With any other passphrase → random-looking bytes that decode cleanly but say nothing meaningful

The critical security property: an adversary who has the ciphertext can't tell which of the three cases a given output belongs to. The decoy is not marked as "decoy" anywhere. The real message is not marked as "real". They're both just plaintexts that fell out of a decoder which always returns something.

The never-fail decoder

This is the philosophy that makes duress passwords actually work. Most cryptographic libraries throw an InvalidTag or AuthenticationError when you give them a bad passphrase. This is great for debugging and terrible for deniability, because the error is itself a signal.

An adversary watching your screen sees "DECRYPTION FAILED" and now knows the passphrase you gave was wrong. They twist harder.

Anyhide's decoder has an explicit invariant: it never returns an error for any input. Any passphrase, any code, any carrier — the decoder produces bytes. If those bytes are a valid message, you see the message. If they aren't, you see what looks like random garbage, but is actually deterministic output of the same shape as a real message.

This means the attack surface for "figure out which passphrase is the real one" is reduced to: does this output look like natural language? And even that gets fuzzy when the real messages are short, encrypted, or structured.

The configuration

The duress feature is wired in through a tiny optional field on EncoderConfig:

// src/encoder.rs

/// Configuration for a decoy message (duress password feature).
#[derive(Debug, Clone)]
pub struct DecoyConfig<'a> {
    /// The decoy message to encode.
    pub message: &'a str,
    /// The passphrase for the decoy message.
    pub passphrase: &'a str,
}

/// Configuration for the encoder.
#[derive(Debug, Clone)]
pub struct EncoderConfig<'a> {
    // ... other fields ...

    /// Optional decoy message configuration (duress password).
    /// If provided, a second message is encoded with a different passphrase.
    /// Using the decoy passphrase reveals the decoy message instead of the real one.
    pub decoy: Option<DecoyConfig<'a>>,
}

The whole feature is opt-in. If you don't set decoy, encoding behaves exactly as before. Backwards-compatible by construction.

Under the hood

The encoding runs twice, once with each passphrase. The real message and decoy message are each converted into their own position sequences into the carrier. Both sequences are packed into the same output structure, and the decoder uses the passphrase you provide to select which sequence to extract.

The elegant part — the one that took me the longest to get right — is that an observer looking at the ciphertext cannot tell whether the decoy is present. There's no "decoy flag" or "has_decoy" field. The output size depends on message length, not on whether a decoy was used.

The bug I want you to learn from

Version 0.9.0 had a subtle flaw that I only spotted after shipping. Here's the scenario:

Anyhide supports signing messages with Ed25519. If Alice always signs her messages, Bob knows to trust only signed messages from her. Unsigned messages from her are probably forgeries or garbage.

Now: in v0.9.0, the real message was signed, but the decoy message was not.

Why? Because the decoy was meant to look like a normal message, and signing it felt like extra work. But consider what this hands an attacker:

Attacker seizes the laptop and the ciphertext.
Attacker forces Alice to reveal a passphrase.
Alice reveals the decoy passphrase. Ciphertext decodes to "nothing important here". No signature on that output.
Attacker knows Alice always signs her real messages.
Attacker: "The message you showed me wasn't signed. There must be another passphrase."

v0.9.1 fixed this by signing both the real and decoy messages with the same key. Now the signature attaches to whichever message the decoder produces, and an attacker sees a valid signature on whatever comes out — real or decoy — so the signature can't be used to distinguish them.

The lesson: when you're building a deniability feature, every observable property of the output must be identical across the real and decoy code paths. Not "mostly identical". Not "identical unless you squint". Identical. Anything else is a channel the adversary can use to distinguish real from decoy.

I wrote this up in the CHANGELOG at the time because I thought it was a nice case study:

v0.9.1 — Fix: sign decoy message with same key as real message. Previously only the real message was signed, decoy had no signature. An attacker who knows the sender always signs could distinguish real from decoy. Now both are signed with the same key.

If you're building security software, keep a public log of these. It's good for you (forces you to reason explicitly about what you broke), and it's good for your users (teaches them what the threat model looks like under stress).

The carrier helps too

There's a second layer that compounds with duress passwords, which I mentioned in Post 2: multi-carrier encoding. If you use three carrier files, the attacker now needs the right files, the right order, and the right passphrase. Any one of those being wrong produces garbage. Multiple of them being wrong still produces garbage. The adversary has no way to tell which axis they're off on.

The combined space looks like this:

Wrong passphrase + right order → garbage
Right decoy passphrase + right order → decoy message
Right real passphrase + wrong order → garbage
Right real passphrase + right order → real message
Wrong passphrase + wrong order → garbage

Five cases. Four of them produce garbage that looks alike. One produces the decoy. One produces the real thing. The attacker's job is to find the one that gives them the real thing, and nothing in the output helps them triangulate.

Does this actually work?

In a literal cryptanalysis sense: this does not replace strong encryption. The math is the math. What plausible deniability adds is a human-layer defense: a story you can tell that is internally consistent with the ciphertext you're holding.

Under coercion, you want a story that:

Is plausible (you can tell it without looking nervous).
Is consistent with the cryptographic artifacts the adversary has.
Leaves the adversary unable to prove you're lying without more evidence.

Duress passwords give you (2). You have to supply (1) yourself — the decoy has to be the kind of thing you'd actually say under normal circumstances. "Nothing important here" is weak. "Bring eggs on the way home, love you" is better. The contents matter as much as the crypto.

What I'd do differently

If I were starting over, I'd probably support multiple decoys instead of just one, with a shared-secret mechanism for choosing which one to reveal under which circumstances. This is more complex and I'm not sure it's worth the cognitive load. Single decoy covers most scenarios I can construct.

The other thing I'd consider: an explicit "panic mode" where one of the passphrases not only reveals a decoy but also zeroizes the real message from the code entirely. Right now both messages are present in the ciphertext forever; if the adversary finds the real passphrase later, they get the real message. Panic mode would destroy the real-message data on first decoy-passphrase use. I haven't implemented it because the UX is tricky — you don't want to accidentally wipe your real messages — but it's on the list.

Next up: Post 4 — Forward Secrecy and the Double Ratchet. How Anyhide rotates keys per message so that even if your long-term keys are later compromised, past messages stay unreadable. And why I ended up supporting three different storage formats for ephemeral keys.

Repo: github.com/matutetandil/anyhide. Issues and discussion welcome.

The lie of the 80%: why software progress charts don't work

Matías Denda — Thu, 21 May 2026 13:00:00 +0000

The lie of the 80%: why software progress charts don't work

Picture the ideal burndown chart. A clean diagonal line, descending steadily from "all the points" down to zero by the end of the sprint. Beautiful. Reassuring. Shareable in a stakeholder meeting.

Now picture an actual sprint you've lived through. Did the line ever look like that?

I'm going to guess: no. And not because your team was bad. Not because you're undisciplined. Not because the estimates were off. The reason no real burndown ever matches the ideal one is more fundamental: software isn't built like that.

Charts of progress assume a model of how software gets made that doesn't reflect reality. And once you see it, you can't unsee it.

Software isn't a brick wall

The mental model behind every progress chart — burndown, burnup, Gantt, percent-complete, you name it — is the same: development is a stack of bricks. You add one brick at a time. The wall gets taller. Eventually, it reaches the height you wanted, and you're done.

This metaphor is comforting and almost entirely wrong.

Real software development looks more like this: you build half a wall. You realize the foundation is in the wrong place. You tear the wall down. You build a different wall. You realize the room is in the wrong place. You spend three days reading and thinking and not laying any bricks at all. Then on day four, you build the entire wall in six hours because you finally understood the problem.

This isn't a failure mode. This is what software development is. Exploration, dead ends, tear-downs, breakthroughs. The progress is non-linear because the work is non-linear. Any chart that assumes a smooth descent from "not done" to "done" is lying about the shape of the work itself.

The 80% lie

Here's the most universally-told lie in software:

"It's basically done. Just need to finish that last 20%."

Every developer has said this. Every developer has heard this. And every developer has been on the receiving end of that 20% turning out to be 80% of the actual work.

It's not that we're all liars. It's that the way development actually unfolds — exploration phase, implementation phase, polish phase — doesn't map cleanly onto percentages. When you say "I'm 80% done", what you usually mean is "I've done a lot, and I have a vague sense that the remaining stuff is smaller than the stuff I did". That's not a measurement. That's a feeling.

The "remaining 20%" often contains:

The integration with the system you haven't talked to yet
The edge case that surfaces only when you wire it up end-to-end
The performance problem that shows up only at production scale
The thing the PM forgot to mention until you demoed

None of these are visible from where you stand at the supposed 80% mark. They're not in the chart. They can't be in the chart. They haven't been discovered yet.

Every metric is biased by who produces it

Here's a quieter problem with progress charts: the person reporting the metric always has a stake in what the metric says.

If you want to look productive, you inflate. If you want to avoid getting more work assigned to you, you deflate. If you're protecting a teammate, you smooth. If you're frustrated with management, you let the truth show through harder than it should.

This isn't dishonesty. It's people responding rationally to incentives. The metric isn't a mirror — it's a message. Once you understand that progress charts are a form of communication, not measurement, you stop expecting them to reflect reality. They reflect the politics of the team's relationship with whoever's reading the chart.

The fix isn't "be more honest". The fix is recognizing that any metric whose value depends on the reporter's interpretation will be shaped by the reporter's incentives. Always. Every time.

The fallacy of uniform effort

Charts also assume that everyone on the team is contributing in roughly the same way at roughly the same time. Sprint velocity. Points completed per developer. Burndown lines that smoothly descend.

Real teams don't work like that. Real teams have weeks where the frontend dev ships forty CMS templates because the work happened to be parallelizable, while the backend dev appears to be drinking mate and playing ping pong for two weeks. And then the next sprint flips: the backend ships a complex migration that took weeks to design, while the frontend dev waits, tests, and unblocks.

That's not dysfunction. That's how interdependent work looks.

If your chart shows uneven contribution and your interpretation is "the backend dev didn't pull their weight", your chart has lied to you. Maybe the backend dev was the reason the frontend could ship forty templates without blockers. Maybe they were doing the design work that makes next sprint possible. Maybe they were unblocking three other teams off-camera.

Charts can't see any of that. They show throughput per person and call it productivity. It isn't.

So who do these charts actually serve?

Once you've internalized all of the above, the question becomes hard to avoid: if these charts don't reflect the work, don't predict the future, and don't measure productivity — why do we still draw them?

The honest answer: because somebody with money needs to see them.

Stakeholders need a deliverable. Steering committees need slides. Procurement needs evidence the contract is being honored. Investors want a sense that the burn is producing output. None of these audiences are going to read the codebase. None of them are going to sit in your standup. They need a representation, and the chart is what we hand them.

That's fine. That's the corporate game, and pretending it can be opted out of is naive. But let's stop pretending the chart is a tool for the team. It isn't. It's a tool for the people the team has to report to. Calling it "project management" obscures what it actually is: status theater, dressed in the language of measurement.

The team doesn't need the chart to know how the project is going. The team knows. They're the ones doing it.

What actually works

If charts are theater, what's the alternative? Three things, in this order:

1. Demos over charts. The only honest measurement of progress is working software. Last week the product looked like this. This week it looks like this. Did it move? Did it move in the right direction? That's the question, and no chart in the world answers it as well as a five-minute demo. If you can't show anything that works, you're not progressing — no matter what the burndown says.

2. Narrative over numbers. Replace "we're 73% done" with "we explored approach A, it didn't pan out, we're now on approach B and we expect to know if it works by Thursday". This is harder than producing a chart, because it requires the reporter to actually understand the work. That's a feature, not a bug. The narrative forces honest engagement; the chart allows comfortable distance.

3. Output metrics as complement, not substitute. What did the user actually receive? Deploys to production. Features released. Bugs closed in the wild. These can be counted because they're real events with real artifacts. The user doesn't lie. The git log doesn't lie. Process metrics — story points completed, sprint percentage, velocity trends — measure the appearance of work. Output metrics measure work that left the building.

And if a stakeholder genuinely needs a number — sometimes they do, and that's fair — give them one. Just be honest about what it is. "Let's invent a number over a beer" is a more accurate framing than "based on our velocity-weighted forecast of remaining story points". They're often the same number. The first one tells the truth about its origins.

The elephant: but the stakeholders want the chart

I'm not naive. I know that in many companies, you can't just stop producing burndowns. The contract requires it. The PMO requires it. The CFO has a slide template with that chart shape on it and changing the slide is harder than changing the moon.

So produce the chart. Hand it over. Smile at the meeting.

But internally, don't let the team start believing the chart. That's where the real damage happens — when developers start optimizing for the line on the screen instead of for the product. When the chart becomes the goal, the chart will start telling you the team is doing great while the codebase is rotting in ways no chart can show.

The worst version of this is the team building its own charts. When developers start producing the very theater that's being used to manage them, the gap between "what we say is happening" and "what is happening" stops being a stakeholder problem and starts being an internal one. That's how you end up with teams that look productive on paper and ship nothing of value for two quarters.

The bottom line

A chart never built a product.

The people who build great software don't do it by staring at burndowns. They do it by talking to their teammates, watching the product grow, adjusting direction when something isn't working, and being honest with each other about what they don't yet understand. The chart is, at best, a translation layer between that work and the people who fund it.

Translation layers aren't bad. But they aren't the work, and they aren't where the work happens.

If you're a manager: the chart is for your audience, not your team. Don't manage by it.

If you're a developer: the chart is theater. Produce it if you have to, but don't let it shape how you actually think about the project.

And if you're at a company where the chart is the project — where decisions are made off the line on the screen and the actual code is invisible to everyone above the team lead — that's not a measurement problem. That's a much deeper one, and no better chart will fix it.

If your team genuinely needs a burndown chart to know how the project is going, the problem isn't the chart. It's that nobody is actually talking about the project.

What does your team use to track progress? Charts you trust, charts you tolerate, or something else entirely? I'd love to hear it in the comments.

Why AI made fundamentals more valuable, not less

Matías Denda — Wed, 20 May 2026 13:00:00 +0000

Two developers sit down to build the same feature: a search endpoint that returns users matching a query string. Both have Claude Code open. Both type roughly the same prompt: "build me a REST endpoint that searches users by name with pagination."

Five minutes later, both have working code. It compiles. The tests pass. The endpoint returns results.

But the code is not the same.

Developer A — three years of experience — accepts the first output. It uses SELECT * FROM users WHERE name LIKE '%query%' with LIMIT and OFFSET. It works in development with 50 users. It will break at 50,000 users and make the whole service slow at 500,000.

Developer B — twelve years of experience — reads the output, asks a follow-up: "What's our expected scale? And what's the user table's index strategy?" The revised code uses a full-text index, cursor-based pagination, proper query limits, a cache layer for popular searches, and a rate limiter. It works in development with 50 users. It also works at 5 million.

Same AI. Same prompt structure. Same amount of time. Radically different code.

This is not an indictment of AI. AI did exactly what it was asked to do — twice. This is about what developers bring to the interaction, and why the "AI democratizes coding" narrative is getting it backwards.

The assumption everyone made

When ChatGPT exploded in 2022, the dominant story in tech media was: "AI will level the playing field for developers." The junior who can prompt well will match the senior who can architect. Bootcamps will close the gap faster. The economic value of deep expertise will decline.

This was never true. It's now clearly not true. And the evidence is in every codebase that's been using AI assistance for the past eighteen months.

AI didn't level the playing field. It tilted it further.

What AI actually does

AI coding assistants are extraordinary at a specific kind of task: translating a human's clear intent into working code. That "clear intent" is the critical qualifier.

A developer who knows:

That their user table will have millions of rows
That LIKE '%query%' doesn't use indexes
That cursor-based pagination is safer than offset-based at scale
That search traffic will be spiky
That caching introduces consistency problems

...can prompt AI to produce code that reflects all of that knowledge. The prompt is short. The output is sophisticated. The developer spends their time on the parts that matter — decisions, architecture, review — while AI handles the mechanical translation.

A developer who doesn't know those things produces a prompt that doesn't reflect them. AI has no way to know what the developer didn't think to ask. AI fills in the blanks with the most common patterns in its training data — which are often appropriate for tutorials and small projects, and actively wrong for production systems.

The prompt is not the skill. The knowledge that shapes the prompt is the skill. AI just made that knowledge more valuable per hour, because now a single developer's knowledge can be applied to 10x more code.

The invisible gap

Here's the uncomfortable part. Before AI, the gap between junior and senior code was visible. You could see it in PR diffs. Senior code looked different — tighter, more thoughtful, better error handling, cleaner abstractions. A code reviewer could point at specific lines and say "this is why we do it differently."

With AI, the gap is hidden in the code that didn't get written. The junior's code might look clean. It passes linters. It has tests. A cursory review sees nothing wrong. But the architecture is subtly off. The edge cases weren't considered because AI wasn't asked about them. The scaling story doesn't exist because the developer didn't know to ask.

These bugs don't appear in staging. They appear six months later, at 3 AM, when the service starts timing out under load and nobody can figure out why.

The productivity gap between juniors and seniors used to be roughly 2-3x for typical code. With AI, it's easy to argue it's become 5-10x — not because seniors got faster (they did), but because juniors started producing code at senior speed that carries hidden problems only a senior would have caught.

What seniors quietly know

Talk to experienced engineers who've been using AI for a year, and they'll tell you something that sounds contradictory:

"AI has made me dramatically more productive."
"AI has made me more careful, not less."

Both are true. The productivity gain comes from AI handling boilerplate, tests, docs, and straightforward implementations. The increased care comes from knowing that AI will happily produce subtly-wrong code with 100% confidence, and there's no prompt you can write that eliminates this risk.

Seniors I've worked with treat AI output the way they treat a competent but unsupervised junior developer: trust, but verify aggressively. Every assumption checked. Every edge case considered. Every optimization decision made by a human who understands why.

The irony: AI didn't make seniors obsolete. It made them the critical quality filter in a pipeline that now produces code 10x faster.

What juniors are being sold vs. what's actually happening

The narrative sold to juniors is: "Learn AI tools, and you'll be employable. The AI does the coding; you orchestrate it."

The reality is harsher and more useful: AI makes your coding output visible much faster, which means your coding weaknesses are exposed much faster, too.

A junior shipping AI-assisted code in a professional environment gets feedback on bad code 10x faster than a junior who writes everything by hand. That's good — it's a faster learning loop. But it only works if the junior is actually learning from the feedback, not just accepting AI's next suggestion.

The juniors who will thrive in the next five years are the ones using AI as a learning tool — asking why the code works, challenging AI's suggestions, reading the documentation behind what AI produced, running experiments to verify assumptions. The juniors who will plateau are the ones using AI as a crutch — accepting output, shipping what passes, never understanding the underlying patterns.

AI didn't replace learning fundamentals. It made the difference between developers who learned them and developers who didn't more obvious, faster.

The skills that appreciated

If you had to invest in skills right now, knowing that AI will keep getting better, where would you invest?

The wrong answer: prompt engineering. Prompt skills are like knowing how to Google in 2008 — temporarily valuable, eventually invisible.

The right answer: anything AI can't do well, and won't do well for a long time.

System design. AI can produce components. It cannot yet decide what components should exist, how they should interact, or what boundaries to draw. This is architecture, and it's human work.

Debugging production issues. AI is remarkably bad at problems that require reading logs, correlating events across services, forming hypotheses, and testing them. The developer who can look at a 3 AM alert and narrow down the root cause in 10 minutes is 100x more valuable than the developer who asks AI for help and waits for a useful answer.

Code review under time pressure. As AI produces more code faster, the bottleneck becomes review. The developer who can skim a 400-line AI-generated PR and immediately spot the assumption that will fail at scale is indispensable.

Understanding systems deeply. How does your database's query planner work? What happens in your browser between a click and a re-render? What does git bisect actually do under the hood? AI can give you surface-level answers, but it can't give you the intuition that comes from building and debugging these systems. That intuition is what lets you write correct prompts in the first place.

Writing. Not just code — prose. The developer who can explain why a decision matters, write a clear RFC, document a system so the next person understands it, will outperform the developer who produces 5x more code that nobody can maintain.

Notice what these have in common: none of them are about AI. All of them are fundamentals that AI happens to highlight the value of.

The practical implication for your career

If you're a junior: AI is a fantastic learning tool if you use it as one. Ask AI to explain every line it produces. Ask why it chose this pattern over alternatives. Run the code and predict the behavior before executing. Challenge the first suggestion. If you're just shipping what AI produces and moving on, you're not learning — you're delegating your growth to a black box.

If you're a mid-level: This is the moment to invest in depth, not width. You probably know twelve frameworks superficially. Pick one area — a database, a protocol, a design pattern — and learn it to the level where you could write a book about it. That depth is what will differentiate you when AI makes surface knowledge free.

If you're a senior or tech lead: Your job description changed, and most companies haven't updated the title. You're no longer the person who writes the critical code — you're the person who ensures critical code is correct, no matter who or what produced it. The review bar has to go up. Your standards have to be explicit and enforced. Your juniors need more mentorship, not less, because AI can hide how much they still need to learn.

If you're hiring: Stop filtering candidates by "can they use AI tools?" That's a non-filter. Filter by "can they evaluate whether AI produced good code?" That's the job now.

What this means for what I write

You may have noticed that my book, Git in Depth, does not contain a chapter on AI. That wasn't an oversight — it was a deliberate choice.

The book covers fundamentals: how Git actually works, how teams coordinate, how CI/CD pipelines protect production, how to align methodology with workflow. These are the things AI assumes you already know when it produces code.

If AI is going to be my co-pilot on the next decade of engineering, I want the foundation under me to be solid. I want to understand what git bisect does well enough to know when AI's suggestion to use it is wrong. I want to understand branch strategies well enough to tell AI "no, we don't use Git Flow here, adapt the suggestion." I want to understand production debugging well enough to know when AI is guessing versus reasoning.

That's the book I wrote. And if the thesis in this post is right, it's more valuable today than it would have been three years ago.

The one-sentence version

AI is not a great equalizer. It is a great amplifier. It amplifies what you already are — for better and for worse. The developers who will thrive in the next decade are the ones who invested in fundamentals while AI was making surface skills look disposable.

Don't skip the fundamentals. They're not optional. They're more important now than ever.

I write about Git and engineering practice for working developers. My book Git in Depth is 658 pages of the fundamentals AI assumes you already know.

See all my articles on Git and engineering practice: dev.to/mdenda.

Procedurally generating marble dice textures with simplex noise

Matías Denda — Fri, 15 May 2026 16:27:29 +0000

I built a 3D dice roller as a Chrome extension and wanted dice that look like the marbled Chessex ones — those rich, swirling, Old-World-stone dice every tabletop player covets. The catch: the renderer (@3d-dice/dice-box) lets the user pick a color per die kind (d4 red, d6 blue, d20 gold, etc.), so the texture can't just be a flat painted bitmap. The marble pattern has to stay, but the color underneath has to follow whatever the user picked.

This post is the recipe for generating those textures from scratch with simplex noise — no Photoshop, no marble photo, just code that produces something like this for every die:

The pipeline is three layers stacked on top of plain noise, plus one trick about the alpha channel that took me a while to spot. Let's walk through it.

Layer 1: Multi-octave simplex noise

Start with the basic noise field. One sample of simplex noise gives you smooth, organic blobs that look more like cloud cover than rock. To get the multi-scale detail real marble has — broad slabs of color and fine hairline streaks — you sum several octaves of noise at doubling frequencies, halving the amplitude each time:

import { createNoise2D } from 'simplex-noise';
const baseNoise = createNoise2D(/* seeded PRNG */);

function sample(x, y) {
  let amp = 1;
  let freqX = BASE_FREQ * 0.7;  // mild horizontal stretch
  let freqY = BASE_FREQ * 1.3;
  let acc = 0;
  let totalAmp = 0;
  for (let o = 0; o < OCTAVES; o++) {
    acc += amp * baseNoise(x * freqX, y * freqY);
    totalAmp += amp;
    amp *= 0.5;
    freqX *= 2;
    freqY *= 2;
  }
  return acc / totalAmp;   // in roughly [-1, 1]
}

The slight asymmetry between freqX and freqY gives the streaks a hint of horizontal flow, like the grain in cut stone. Here's what that looks like as a grayscale field:

It's already organic-looking, but it's also too uniform — straight parallel-ish bands like wood grain, not the curling whorls of marble. Real marble veins bend, swirl, and double back on themselves. That's the next layer.

Layer 2: Domain warping

Domain warping is one of those tricks that feels like cheating because it's so simple and the result is so dramatic. Instead of sampling the noise on a straight (x, y) grid, you offset every (x, y) by another noise field before sampling:

const warpA = createNoise2D(/* different seed */);
const warpB = createNoise2D(/* yet another seed */);

const WARP_FREQ = 0.003;    // broad, slow swirls
const WARP_AMOUNT = 90;     // pixels of displacement at peak

for (let y = 0; y < H; y++) {
  for (let x = 0; x < W; x++) {
    const wx = warpA(x * WARP_FREQ, y * WARP_FREQ) * WARP_AMOUNT;
    const wy = warpB(x * WARP_FREQ, y * WARP_FREQ) * WARP_AMOUNT;
    const v = sample(x + wx, y + wy);
    // ...
  }
}

You're literally bending the input space before reading the noise. Two independent low-frequency noise fields (one per axis) push each pixel up to 90 pixels in some random direction, so the patterns above get twisted into curls. Same noise, same algorithm, different coords:

Now we're getting marble whorls. But the field is still soft — gradual gradients everywhere. Marble has veins: sharp edges where dark meets light. That's the third layer.

Layer 3: Ridged transform

The ridged transform is a one-line operation: 1 - |n|. It folds the noise field around zero and inverts it, so what used to be a smooth roll between -1 and +1 becomes a series of sharp peaks at every zero-crossing of the original noise. Mathematically, the zero-crossings of a smooth random field form a set of curves — and 1 - |n| lights those curves up.

function sample(x, y, ridged) {
  // ... octave summing as before ...
  const n = acc / totalAmp;
  return ridged ? 1 - Math.abs(n) : (n + 1) / 2;
}

Apply that and the soft swirls turn into something with backbone:

That's the geometry of marble veins — long, curving ridges with a clear edge between "vein" and "background". Now we have a usable pattern.

Composition: dual fields + thresholds

The actual marble texture uses two of these fields with different seeds — one for dark veins, one for light highlights — and per pixel picks whichever signal is stronger. Threshold each field at around 0.86 so only the sharpest ridge crests become streaks:

const darkStrength = Math.pow(
  Math.max(0, dn - DARK_THRESHOLD),
  STREAK_CONTRAST,
);
const lightStrength = Math.pow(
  Math.max(0, ln - LIGHT_THRESHOLD),
  STREAK_CONTRAST,
);

const darkAlpha = Math.min(MAX_DARK_ALPHA, darkStrength * DARK_GAIN);
const lightAlpha = Math.min(MAX_LIGHT_ALPHA, lightStrength * LIGHT_GAIN);

if (lightAlpha > darkAlpha) {
  // light streak wins
  r = g = b = 255;
  a = lightAlpha;
} else if (darkAlpha > 0) {
  // dark vein wins
  r = g = b = 0;
  a = darkAlpha;
} else {
  // nothing — see "the trick" below
  a = 0;
}

MAX_DARK_ALPHA is higher than MAX_LIGHT_ALPHA (215 vs 160) so the dark veins read as proper marbling and the light streaks stay subtle highlights — flip those and the dice look chalky.

The trick: alpha as the actual lever

Here's the part that bit me for half an evening. @3d-dice/dice-box's color shader is essentially this line of GLSL:

finalColor = mix(themeColor.rgb, textureColor.rgb, textureColor.a);

If the texture's alpha is 1.0 (opaque), the result is 100% texture, 0% themeColor. Which means: if you generate a normal RGB marble texture — black veins on a white background, fully opaque — the user's color choice (the themeColor) is completely invisible. Every die comes out the same washed-out gray, no matter what color is selected.

The fix isn't in the colors — it's the alpha channel.

Write the marble pattern into alpha, not RGB. Where you want a dark vein, the RGB is black and the alpha is high (the texture covers the themeColor). Where you want a light streak, RGB is white with moderate alpha. Where you want pure themeColor, alpha is zero and RGB doesn't matter. The texture is essentially a black-and-white-and-transparent stencil through which the themeColor shows.

That's why the snippet above sets r = g = b = 0 (or 255) and modulates the alpha. The alpha channel is doing the actual work; the RGB just decides whether visible pixels are "darker than themeColor" or "lighter than themeColor".

One more wrinkle: the original dice texture has numbers on the faces, and those need to stay readable. The fix is a simple override — wherever the source atlas has a high-alpha pixel (a number glyph), force the output to opaque black:

if (numbersAlpha[i] > 200) {
  r = g = b = 0;
  a = numbersAlpha[i];   // preserve anti-aliasing
  continue;
}

Numbers always win.

The result

Stack all of that — two warped, ridged, thresholded noise fields composed into a single texture with the alpha trick — and the renderer produces dice that share a consistent marble pattern but pick up whatever per-die color you've configured:

The whole texture-generation pass runs offline as a build step (one Node script with simplex-noise and sharp), so there's zero runtime cost — the extension just ships the resulting 1024×1024 PNG.

Try it / read the code

If you want to see this running in a real Chrome extension, I published the dice roller it's a part of here:

🎲 Dice Roller on the Chrome Web Store: https://chromewebstore.google.com/detail/dice-roller/oiknfbfchalpjggppamjfchhlplaieol

DEV Community: Matías Denda

Building a P2P Chat over Tor with Rust's arti-client

Why hidden services and not just a relay

The .onion address, by hand

Starting the Tor client

Hosting a hidden service

Bidirectional connection racing

The handshake

What arti gives you, and what it doesn't

Async migration notes

What's next

Why git pull --rebase should probably be your default

The setup: diverged history

Strategy 1: git pull (merge)

Strategy 2: git pull --rebase

Why linear history matters

The commits X' and Y' are new commits

The golden rule of rebase

When git pull (merge) is actually correct

The mindset shift

git bisect: find the commit that broke production in minutes, not days

How bisect works

The manual workflow

Automating bisect with a script

Writing a bisect-friendly test script

Handling flaky tests

What bisect teaches you about your codebase

The mindset shift

Implementing Forward Secrecy in Rust: A Double Ratchet and Three Storage Formats

The cryptographic primitives

The SessionKeys struct

The symmetric ratchet

Domain separation

The DH ratchet

Three storage formats (and why)

Format 1: Individual PEM files

Format 2: Separate consolidated JSON

Format 3: Unified JSON

Why three?

The ratchet in action

What's coming

Code review when half the PR is AI-generated

The review problem AI created

What bad AI-generated code actually looks like

The skill that suddenly got very valuable

What the review bar has to look like now

A practical setup

The hardest thing about all this

Back to the amplifier

Most of Your Microservice Is Plumbing. What If You Stopped Writing It?

Be honest about your last microservice

Everyone filed it under "prototyping" — and that's on me

What Mycel actually is

The "file #4" test — where the engineering actually lives

The honest tradeoff

When you outgrow the vocabulary

Prototyping vs. production is the wrong axis

Try it

What happens when an AI agent commits to your repo

The two kinds of AI-assisted commits

Why this matters

What senior AI-assisted developers do differently

What Git reveals, three months in

Three practical habits that preserve commit quality

A small convention that helps

The quiet thing seniors know

I Built a REST Microservice With a Database in 3 Files — and Wrote Zero Code

The boilerplate tax

The whole service, in three files

Running it — in a container

"Okay, but real services need more than raw CRUD"

What this isn't

Why I built it

Try it

Plausible Deniability in Cryptography: Building a Duress Password in Rust

The design goal

The never-fail decoder

The configuration

Under the hood

The bug I want you to learn from

Strategy 1: `git pull` (merge)

Strategy 2: `git pull --rebase`

When `git pull` (merge) is actually correct