DEV Community: Matías Denda

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

The four decisions every team makes about Git (whether they realize it or not)

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

Most teams think they have a "Git workflow." What they actually have is a set of habits that accumulated over time, often made by people who left the company years ago, based on assumptions that no longer hold.

Ask three developers on the same team to explain "how we use Git" and you'll get three different answers. Not because anyone is wrong — because the team never actually made the decisions explicitly. They made them by accident.

This article is about surfacing those decisions. Not telling you what's right — telling you what you're implicitly choosing, so you can choose deliberately.

The four decisions

Every team, whether they know it or not, has made a choice about four things:

Branching strategy — How does code move from idea to production?
Tracking methodology — How do you decide what to work on and measure progress?
Release cadence — How often does code reach users?
Automation level — How much of the workflow is human-driven vs event-driven?

Each decision constrains the next. Each one, if not made explicitly, gets made implicitly — and implicit decisions tend to contradict each other.

Decision 1: Branching strategy

Your options, roughly:

Trunk-based development — everyone commits to (or merges small changes into) main, multiple times a day
GitHub Flow — feature branches, short-lived, merged via PR to main
GitLab Flow — feature branches + environment branches (staging, production)
Git Flow — long-lived develop + main branches, release branches, hotfix branches
Custom hybrid — some combination of the above

Most tutorials frame this as "which is best?" The honest answer is: it depends on the next three decisions. Git Flow with continuous deployment is a contradiction. Trunk-based with a monthly release train is a waste.

The right question isn't "which strategy should we use?" — it's "which strategy supports the other three decisions?"

Decision 2: Tracking methodology

This one most teams think they've decided, but haven't.

Scrum — sprints, story points, planning/retro ceremonies
Kanban — continuous flow, WIP limits, no sprints
Waterfall or phase-gated — requirements → design → build → test → deploy
SAFe or other scaled framework — multiple teams coordinating via ARTs or similar

The question that reveals your actual methodology: what triggers work to start?

If it's "this sprint's plan" → you're doing Scrum (or pretending to)
If it's "capacity is available and this is prioritized" → you're doing Kanban (or should be)
If it's "this phase is complete and signed off" → you're doing Waterfall (admit it)
If it's "a manager said so" → you're in a methodology vacuum, which is its own problem

The implications for Git are direct. Scrum with 2-week sprints wants branches that close before sprint end. Kanban doesn't care about time — it cares about WIP limits. Waterfall expects phase-gated tags. These are incompatible constraints on how your branches live.

Decision 3: Release cadence

This is the one most teams lie to themselves about.

Continuous deployment — every merge to main goes to production (with canary, feature flags, etc.)
Continuous delivery — every merge to main is production-ready, but deployment is a manual trigger
Release train — scheduled releases (weekly, biweekly, monthly)
Ad-hoc releases — "when it's ready," which usually means "when someone has time"

The diagnostic question: how long from a developer's merge to users seeing the change?

Hours → you're on continuous deployment
A day or two → continuous delivery
Consistent schedule → release train
"Varies" → ad-hoc (and your lead time is probably terrible)

Release cadence is the cruellest decision to get wrong, because it interacts with everything:

Long cadence + trunk-based = huge batch risk
Short cadence + Git Flow = unnecessary overhead
Ad-hoc + Scrum = sprint goals that never ship at sprint end

Decision 4: Automation level

Unlike the others, this is a spectrum, not a discrete choice. But at a high level:

Fully automated — PR opens → CI runs → auto-merge on approval → auto-deploy to staging → auto-promote to prod (with gates)
Event-driven — Git events trigger most transitions; humans handle exceptions
Semi-manual — CI runs, humans approve and merge, humans decide when to deploy
Fully manual — every step requires a human action

The test of your automation level: what happens at 2 AM when a hotfix needs to ship?

If the answer is "we page someone who manually runs the deploy script," your automation level is semi-manual at best. If the answer is "the hotfix workflow handles it; we review the result in the morning," you're much closer to the automated end.

The decision table

Here's what it looks like when a team makes all four decisions consistently:

Team Type	Branching	Tracking	Release	Automation
SaaS startup	Trunk-based	Kanban	Continuous	High
Regulated fintech	GitLab Flow	Scrum	Biweekly	Medium
Enterprise product	Git Flow	SAFe	Quarterly	Medium-high
Open source project	GitHub Flow	Issue-driven	Ad-hoc	High
Regulated hardware	Custom	Waterfall-hybrid	Milestone-based	Low-medium

Notice that each row is internally consistent. The branching strategy supports the cadence. The tracking methodology matches the release frequency. The automation level is appropriate for the regulatory context.

Natural combinations that work

Trunk-based + Kanban + continuous deployment + high automation. This is the SaaS ideal. Works when the team is small-to-medium, the product tolerates continuous change, and there's sufficient test coverage. Fastest feedback loop, but requires discipline.

GitHub Flow + Scrum + continuous delivery + medium-high automation. The most common mid-size-team setup. Feature branches align with sprint items. Continuous delivery means each sprint can ship if the business decides. Good for product teams at B2B SaaS companies.

Git Flow + SAFe + release train + medium automation. Enterprise reality. Multiple teams coordinating, scheduled releases, version-branching for support of multiple production versions. Unfashionable, but genuinely correct for some contexts.

Combinations that create friction

Git Flow + continuous deployment. Your long-lived develop branch creates unnecessary batching. Why have develop if you deploy on every merge? You're paying the cost of Git Flow without getting its benefits.

Trunk-based + quarterly release train. You're merging to main continuously, but users don't see the changes for 3 months. Either deploy more often, or use longer-lived branches. The current setup batches risk without batching value.

Scrum + ad-hoc releases. You commit to sprint goals, but the output doesn't reach users at sprint end. The team's measurement of success (sprint completion) is divorced from actual delivery. Over time, developers stop believing sprints matter.

Kanban + Git Flow. Kanban is about continuous flow; Git Flow creates flow-blocking integration points. Every release branch is a ceremony Kanban is designed to eliminate.

The test: can you write down your answer?

Here's a diagnostic exercise that takes 10 minutes and is worth more than most consulting engagements:

Write down the four decisions for your team, as one sentence each.

"We use GitHub Flow."
"We use Scrum with 2-week sprints."
"We release every Thursday at 2 PM."
"PR opens trigger CI automatically; merges trigger deploy-to-staging automatically; promotion to production requires manual approval."

If you can write these four sentences confidently, and every senior person on the team would write approximately the same four sentences, you have a workflow.

If different people would write different sentences, or if you find yourself writing "it depends," or "we kind of do X but sometimes Y" — you don't have a workflow. You have accumulated habits pretending to be a workflow.

And that's fine to discover. The discovery is the start of fixing it.

Your workflow will evolve

One more thing: these four decisions aren't permanent. Teams grow, products mature, regulations change.

A startup that started with trunk-based + continuous deployment may, at 50 developers, realize that coordination requires feature branches. That's not a failure — that's scale demanding a new set of decisions.

A mature enterprise product might, after adopting feature flags and improving test coverage, discover it can move from quarterly release trains to biweekly. That's not a rebellion — that's capability unlocking a new set of decisions.

The mistake isn't in the specific decisions. The mistake is making them implicitly, letting them drift, and then wondering why delivery is slow and everyone's frustrated.

Make them explicit. Revisit them quarterly. Change them when the context changes.

That's how you go from "we have a Git workflow" to actually having one.

This post is adapted from Git in Depth: From Solo Developer to Engineering Teams, a 658-page book with a full chapter on the complete map connecting board columns, Git states, and deployment environments — plus decision frameworks for choosing the right combination for your team.

N! Ways to Hide a Message: Multi-Carrier Encoding in Rust

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

Post 2 of 6 in the series on building Anyhide, a Rust steganography tool. This post is about a small feature that multiplies your adversary's work by a factorial.

I like features that give you an outsized security improvement for very little code. Multi-carrier encoding is one of those. The implementation is maybe twelve lines. The effect is that the set of carriers you use becomes an ordered secret — and getting that order wrong produces deterministic garbage, which an attacker can't distinguish from using the wrong files entirely.

Let me explain.

The single-carrier recap

In a normal Anyhide flow, both parties share one file. They use it as a reference, and the sender encodes a message by computing byte positions into that file. Single file, single shared secret.

But "the carrier is the file we both have" is a constraint I wanted to relax. What if the carrier is a set of files? What if the set is ordered, and the order itself is a secret nobody but the two parties knows?

That's multi-carrier encoding.

The API

From the command line, you just pass -c multiple times:

# Sender
anyhide encode \
  -c song.mp3 \
  -c photo.jpg \
  -c document.pdf \
  -m "meeting moved to 9pm" \
  -p "passphrase" \
  --their-key bob.pub

# Receiver needs the SAME files in the SAME order
anyhide decode \
  --code "..." \
  -c song.mp3 \
  -c photo.jpg \
  -c document.pdf \
  -p "passphrase" \
  --my-key bob.key

If Bob swaps photo.jpg and document.pdf, he does not get an error. He gets garbage — random-looking bytes that happen to decode cleanly from the wrong carrier. He won't know whether the message was the wrong passphrase, the wrong key, the wrong files, or the wrong order of the right files.

The math

The number of ways to order N distinct files is N! (N factorial). That means if an adversary has all four of your carrier files and the passphrase and the private key, they still have to try up to 24 orderings to recover a 4-carrier message.

N carriers	Orderings to try
2	2
3	6
4	24
5	120
7	5,040
10	3,628,800

This isn't cryptographic security — factorial growth is polynomial next to exponential keyspaces. But it's not meant to be. It's an additional layer of ambiguity, and more importantly, it's ambiguity that an attacker can't distinguish from other failures. They can't test "is this the wrong order?" without a ciphertext oracle, which they don't have.

The implementation

Here's the actual code. It lives in src/text/carrier.rs and is 17 lines:

/// Creates a carrier from multiple files concatenated in order.
///
/// *Order matters!* Different order = different carrier = different decoding result.
/// This provides N! additional security combinations for N carriers.
///
/// - Single file: Delegates to `from_file()` (preserves text vs binary detection)
/// - Multiple files: All read as bytes and concatenated (always binary carrier)
pub fn from_files(paths: &[std::path::PathBuf]) -> std::io::Result<Self> {
    if paths.is_empty() {
        return Ok(Carrier::from_bytes(vec![]));
    }

    if paths.len() == 1 {
        return Self::from_file(&paths[0]);
    }

    // Multiple files: read all as bytes and concatenate in order
    let mut combined = Vec::new();
    for path in paths {
        let data = std::fs::read(path)?;
        combined.extend(data);
    }
    Ok(Carrier::from_bytes(combined))
}

That's it. Read each file as bytes, concatenate them in the provided order, hand the resulting buffer to the binary carrier machinery, and move on. The rest of the encoder and decoder doesn't even know it's dealing with multiple files — to them, it's just a longer buffer.

Why the single-file branch matters

Notice the early return at paths.len() == 1. Without it, a single-carrier call would lose the text/binary autodetection that from_file gives you. A .txt with one carrier would be treated as binary, and suddenly substring matching becomes byte matching. The search still works, but you lose the case-insensitive lookup that text carriers give you for free.

Keeping the single-file case routed through from_file means the multi-carrier feature is a pure extension — existing callers and existing encoded codes are untouched. This is the kind of thing I care about when adding features to a tool people might already depend on.

Why ordered concatenation instead of something cleverer

I considered a few alternatives while designing this:

Hashing the carrier set and using the hash as a seed. Too indirect. The whole appeal of Anyhide is that the carrier is the file, not a digest of it. Hashing would also make the "why wrong order gives garbage" property harder to reason about.
Interleaving bytes from each file in a passphrase-derived pattern. More complex, marginally better, and it made the error surface much bigger. Every bug would be a silent decoder failure, which is exactly what Anyhide is designed to never surface.
Each carrier gets its own search, and fragments are distributed across carriers. Elegant on paper, but it changes the security model: now partial knowledge of one carrier compromises the whole message instead of just its fraction. Worse.

Concatenation in caller-provided order is the simplest model that works and the easiest to reason about. Boring. Correct.

Plausible deniability across the factorial

Here's where this gets fun. Imagine you encode a message with [A, B, C]. Six orderings are possible:

[A, B, C]  → "meeting at 9pm"  (real)
[A, C, B]  → garbage
[B, A, C]  → garbage
[B, C, A]  → garbage
[C, A, B]  → garbage
[C, B, A]  → garbage

All five "wrong" orderings produce outputs indistinguishable from random. An attacker who recovers your files, your key, and your passphrase — but not the ordering — sees six plausible-looking plaintexts. None of them says "ERROR". One says "meeting at 9pm". The other five say things like \x8f\x3aq#w....

Now pair this with the duress-password feature from Post 3 and the adversary's problem gets harder still: they can't tell whether a given output is "the real message in the right order", "the decoy message in the right order", or "the wrong ordering producing noise".

A note on testing

The integration test that verifies this is one line of logic:

#[test]
fn test_multi_carrier_wrong_order_produces_garbage() {
    let msg = "top secret";
    let carriers = vec!["a.txt", "b.txt", "c.txt"];
    let code = encode_with(carriers.clone(), msg);

    // Wrong order
    let wrong = vec!["b.txt", "a.txt", "c.txt"];
    let decoded = decode_with(wrong, &code);

    // Does not return Err(); returns Ok with garbage
    assert_ne!(decoded, msg);
    // And it's "garbage" in the sense that re-encoding it
    // wouldn't round-trip either
}

The interesting assertion isn't assert_ne!. It's that the function returns Ok with bytes, not an error. That's the "never-fail decoder" invariant Anyhide is built around, and multi-carrier inherits it for free because it's just a longer buffer going through the same pipeline.

What you get for 17 lines of Rust

To recap:

N! additional orderings an adversary must exhaustively search through.
Zero impact on single-carrier code paths (backwards compatible by design).
Order is a new secret, composable with the passphrase, key, and (see Post 3) duress password.
Wrong order produces garbage indistinguishable from any other failure mode.

The lesson for me, writing this: the best additions to a security tool are the ones you can explain in two sentences and implement without touching the core. If your new feature reshapes the pipeline, you've probably made a mistake.

Next up in the series: Post 3 — Plausible Deniability and Duress Passwords. How to encode two messages under two different passphrases, so that under coercion you can reveal a decoy that's cryptographically indistinguishable from the real one. Dropping in two weeks.

Repo: github.com/matutetandil/anyhide. If you spot a way multi-carrier breaks the security properties I claimed above, open an issue — I want to know.

Stop estimating in hours. Start estimating in complexity.

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

Stop Estimating in Hours. Start Estimating in Complexity.

There's a quiet truth every developer knows but nobody says out loud at sprint planning:

When we estimate in hours, we always estimate low.

Always. The senior estimates low because they want to look efficient. The junior estimates low because they don't want to seem slow. The team estimates low because the PM is in the room. And then the sprint ends, half the tickets roll over, and everyone pretends to be surprised.

After years of watching this play out across teams, languages, and stacks, I've come to believe that the problem isn't that we're bad at estimating hours. The problem is that hours are the wrong unit.

Let me explain why I now estimate in complexity, and why I think it leads to better software, better teams, and — surprisingly — better deadlines.

The misunderstanding at the core

Here's the trap most teams fall into: they treat complexity and time as the same thing measured with different rulers. They're not. They're two independent axes.

Consider translation. Translating a paragraph from English to Spanish is easy. There's almost no complexity. But translating the entire Bible? That's still easy — the per-sentence cognitive load hasn't changed — it's just long. Easy doesn't mean fast.

Now flip it. A complex distributed-systems migration sounds like it should take weeks. But if your platform happens to have the right tooling already in place, you might pull it off in an afternoon. Complex doesn't mean slow.

Once you internalize this, the whole hour-based estimation game starts looking absurd. You're collapsing two dimensions into one and pretending the result is meaningful.

So what is complexity, then?

In the teams I've worked on, we settled on a Fibonacci-ish scale: 3, 5, 8, 13. Anything bigger than 13 wasn't an estimate — it was a signal to break the task down.

The numbers themselves don't matter much. What matters is what they represent:

3 — Well-understood. We've done this kind of thing before. Few moving pieces. Low risk.
5 — Some unknowns, or more pieces involved, but nothing scary.
8 — Several systems touched, real risk, or genuinely new territory.
13 — Too big. Stop. Break it apart.

You can layer in dimensions like uncertainty, coupling, blast radius, dependencies, team familiarity — but the goal isn't to build a precise rubric. The goal is to give the team a shared vocabulary for talking about how hard something is, separate from how long it takes.

The real magic isn't the number — it's the conversation

Here's what nobody tells you about story points: they're not better than hours because they're more accurate. Honestly, they're probably less accurate in absolute terms.

They're better because they change the conversation.

When you ask someone "how long will this take?", the conversation is individual and defensive. Whoever knows the most throws out a number. Everyone else nods. The junior who's actually going to do the work quietly panics, because they know they can't hit that number, but pushing back means admitting they're slower.

When you ask "how complex is this?", the conversation is collective. Why is this a 5 and not a 3? What pieces does it have? What could go wrong? Juniors learn by watching seniors reason through problems. Seniors occasionally discover that something they called "trivial" wasn't trivial at all. The team understands what they're about to build before they build it.

That's what hours don't give you, no matter how precise they are.

The split that changes everything

Here's the part of my workflow that I think is genuinely underrated:

The team estimates complexity. The individual developer estimates their own hours.

Complexity is a property of the problem. Hours are a property of the person solving it.

I'm a senior architect. A junior on my team is not going to take the same time I do on the same task. That's not a flaw — it's reality. Telling a junior "this should take you 3 hours because the senior said so" is one of the cruelest, most counterproductive things we do in this industry. They burn out trying to hit a number that was never theirs to hit.

So instead: the team agrees this task is a 5. Then the developer who picks it up estimates their own hours. Those hours are mostly for them — to plan their day, to learn calibration, to flag early when they're slipping. We sum them as a sanity check against the sprint capacity, but the commitment to the business doesn't come from those numbers. It comes from velocity (more on that in a sec).

Junior devs get the low-complexity tasks first. Not because we don't trust them, but because low-complexity tasks are where it's cheap to be wrong. That's where you learn to estimate without blowing up the sprint.

"But the junior will estimate wrong too"

Yes. They will. That's the point.

I get this objection every time I describe this system: "if the dev estimates their own hours, they can still get it wrong — for any of the reasons people get hours wrong in the first place." True. A junior estimating their own hours will probably underestimate 9 times out of 10. A senior in unfamiliar territory will do the same.

The difference isn't that the estimate magically becomes correct. The difference is what happens when it's wrong.

When hours are imposed top-down by whoever-knows-most, a missed estimate is a personal failure. The junior is just behind. Tough luck, work weekends.

When the dev estimates their own hours, a missed estimate is a calibration signal. It's the moment the team lead — the architect, the TL, the assigned senior — steps in. Not to scold, but to give context. To explain what the dev didn't see. To walk through why this task that looked like 4 hours was actually 12.

This is where the didactic side of the senior matters, and where teams really differ. Some leads let juniors slam their heads against the wall and call it "learning by doing". Others sit down and unpack the problem with them. The system doesn't fix that for you — but at least it makes the moment visible, instead of burying it under a missed deadline that nobody wanted to admit was unrealistic from the start.

Over time, the junior's estimates get sharper. Not because they got faster, but because they learned to see more of the task before starting it. That's a skill hours-based estimation never teaches, because in hours-based estimation, the junior never gets to estimate at all.

What about the unknown?

Every estimation system breaks at the same place: how do you estimate something nobody has done before?

You don't. You spike it.

A spike is a timeboxed investigation. "Spend 4 hours figuring out if this is feasible, then come back." The output isn't an estimate — the output is enough understanding to estimate. And honestly, half the time the spike basically solves the problem, because the hard part wasn't the doing, it was the figuring out.

This is the part I think most teams miss. They try to estimate the unknown anyway, padding numbers "just in case", and end up with stories that are 80% mystery and 20% work. Spikes are the escape valve. Use them.

How to actually do this

If you're sold on the idea but wondering how it looks in practice, there's no single right answer. Here are a few techniques teams use — pick whichever fits your group's vibe:

Planning poker. Everyone on the team has a deck of cards with the values (3, 5, 8, 13, plus a "?" for "I have no idea, we need a spike"). Someone reads the task. Everyone picks a card face-down, then reveals at the same time. If the numbers diverge wildly, the highest and lowest explain their reasoning, and you re-vote. The simultaneous reveal is the whole point — it stops people from anchoring on whatever the most senior person said first.
T-shirt sizes. Same idea, but with S / M / L / XL instead of numbers. Useful for teams that find numbers feel falsely precise, or for early-stage estimation where you just want a rough bucket. You can always map sizes to points later if you need velocity tracking.
Affinity estimation. Print all the tasks on cards, lay them on a table, and have the team physically group them by relative complexity — "this feels about as hard as that one". Fast for large backlogs, and surprisingly accurate, because humans are much better at comparing than at measuring.

You can mix these. Some teams use affinity estimation for backlog grooming and planning poker for sprint refinement. Others just default to a quick t-shirt sizing in a 15-minute meeting and call it done.

The technique matters less than the conversation it produces. If your team is genuinely talking about the problem — surfacing risks, sharing context, learning from each other — the format is just scaffolding. Pick whatever scaffolding gets you there.

"But the business needs dates"

This is the objection that always comes up, and it's a fair one.

The answer is velocity. Track how many points your team actually completes per sprint over time. After a few sprints, you have a reasonable estimate. Multiply points-remaining by velocity and you have a date range.

I want to be honest, though: velocity isn't magic. It has real problems. It can be gamed by inflating points. It assumes a stable team — when people leave or join, it breaks. It works badly for highly exploratory work. And in the wrong hands it stops being a planning tool and becomes a productivity stick to beat people with.

But used carefully, it gives you something hour-based estimation never does: a system that gets more accurate over time instead of less. The curve is bumpy at first, and then it smooths out. With hours, the curve never smooths out, because the underlying signal was noise from the start.

When this doesn't apply

I'm not selling a silver bullet. Complexity-based estimation is overkill when:

Your team is 1–3 people and you all have the same context anyway
The work is repetitive (pure bug fixing, low-novelty maintenance)
You're in an early prototype phase where everything is changing every day

In those cases, hours — or no estimates at all — are probably fine. Don't impose ceremony where it doesn't earn its keep.

The honest summary

After years of doing this, I don't think estimating in complexity is more accurate than estimating in hours. Probably it isn't. But that was never the right question.

The right question is: what kind of conversation do you want your team to have?

When you estimate in hours, the conversation is individual and defensive. Whoever knows the most throws out a number, everyone nods, and the person with the least experience ends up trapped trying to hit a commitment they never had a real say in. Nobody learns. Nobody talks about the problem itself. Numbers just get distributed.

When you estimate in complexity, the conversation is about the problem. Why is this a 5 and not a 3. What's hiding inside it. What risks it carries. Juniors learn by watching seniors reason. Seniors sometimes realize the "trivial" thing wasn't trivial. The team understands what they're about to do — together — before they do it.

That's what hours don't give you, no matter how precise.

If your team estimates in hours and it works for you, great — keep going. But if you find yourselves fighting estimates that never land, devs burning out, and PMs disappointed sprint after sprint, maybe the hours aren't being measured wrong.

Maybe hours are just the wrong question.

What does estimation look like on your team? Do you fight with hours, swear by points, or have you found something else that works? I'd love to hear it in the comments.

Your team isn’t slow — your WIP is too high (Little’s Law explained)

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

A team with 20 open PRs is mathematically slower than a team with 3.

Not “feels slower.” Not “probably slower.”

Is slower.

If your tickets take two weeks to cross the board while coding takes a few hours, the problem isn’t effort — it’s how much work your team keeps in flight at the same time.

And there’s a 65-year-old law that explains exactly why.

The equation

Little’s Law, proven by MIT professor John Little in 1961, applies to any stable flow system over a long enough interval.

Lead Time = WIP / Throughput

In plain English:

Lead Time — how long it takes for a ticket to go from started → merged → deployed
WIP — Work In Progress, the number of items currently in flight
Throughput — how many items your team completes per unit time (usually per week)

This is not a metaphor. It governs factories, airport security lines, and fast-food drive-throughs.

It also governs your Git workflow — whether you acknowledge it or not.

The example that breaks the illusion

Let’s run the numbers on a real team.

Priya’s team closes 10 PRs per week on average (measured over the last 8 weeks). At any given moment, they have 20 PRs open (in progress + in review).

Their lead time is:

20 WIP / 10 PRs per week = 2 weeks

That means every ticket entering the system today is guaranteed to take about two weeks to ship — even if the code itself takes 3 hours.

When someone asks:

“Why does this take two weeks if coding takes half a day?”

This is the answer.

The code is not slow.

The developers are not slow.

The queue is long.

The part that actually changes how you work

If throughput is roughly stable (your team works at a certain pace), then:

Lowering WIP lowers lead time proportionally.

Same team:

WIP 20 → 10 → lead time drops from 2 weeks to 1 week
WIP 20 → 6 → lead time drops to ~3 days

Nothing else changes.

No overtime.

No process overhaul.

Just finishing work before starting new work.

This is why WIP limits exist in Kanban — not as a constraint on developers, but as a way to shorten delivery time by physics.

“If I limit WIP, people will sit idle”

This is the most common objection — and it’s backwards.

A team with 10 open PRs is slower than a team with 3.

Why?

Context switching is expensive

Every open branch is cognitive load. Ten branches means ten partial states competing for attention.
Half-done work has zero value

A PR at 90% is still 0% delivered.
Waiting PRs are inventory, not progress

In manufacturing, inventory is waste. In software, a PR sitting in review for days is exactly that.

Limiting WIP forces a simple rule:

Finish something before starting something new.

That alone compresses your delivery timeline.

You can measure this from Git (no fancy tools needed)

You don’t need Jira dashboards or expensive analytics. You can get all three variables directly from Git.

Throughput — PRs merged per week

gh pr list --state merged --limit 200 \
  --json mergedAt \
  --jq '[.[] | .mergedAt | fromdate | strftime("%Y-W%V")] 
        | group_by(.) 
        | map({week: .[0], count: length})'

Average the last 8 weeks for a stable number.

WIP — what’s currently in flight

# PRs in review
gh pr list --state open | wc -l

# Branches not yet merged (likely in progress)
git fetch --prune
git branch -r --no-merged origin/main | wc -l

Add both — that’s your WIP.

Lead time — created → merged

gh pr list --state merged --limit 50 \
  --json number,createdAt,mergedAt \
  --jq '.[] | {n: .number, hours: (((.mergedAt|fromdate) - (.createdAt|fromdate))/3600|floor)}'

Don’t just look at the average — look at the spread. A few PRs taking 10+ days can dominate the system.

What to do with the numbers

Once you have all three:

If the equation matches your lead time → your system is stable. Lower WIP to go faster.
If your lead time is longer → you have bottlenecks (reviews, CI, environments). Fix those first.
If it’s shorter → you’re likely measuring WIP wrong or hiding variance.

If you’re leading a team and this number is higher than expected, you’re not alone — most teams never measure it.

A practical starting point for WIP limits

There’s no universal number, but these are solid defaults:

In Progress ≈ team size
In Review ≈ team size ÷ 2

Example (6 devs):

In Progress = 6
In Review = 3

From there, adjust slowly. Not weekly — quarterly. The signal takes time.

If lead time is too long:
Don’t add people — lower WIP.

When perception and math disagree

This is the uncomfortable part.

A team with:

WIP = 20
Throughput = 5/week

Has a 4-week lead time.

It doesn’t matter if individual PRs “feel fast.”

Users don’t feel individual PR speed.

They feel system lead time.

When the board says “we’re delivering” but the math says 4 weeks — the business experiences 4 weeks.

The takeaway

You don’t need a new process.

You don’t need better estimates.

You need a constraint:

Stop starting. Start finishing.

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.

Little’s Law looks simple — until you apply it and realize your entire workflow is shaped by it. In the book, I go deeper into how this connects to branching strategies, PR flows, and why some teams get faster as they scale while others slow down.