architecture on Saurabh Kumar

How the Claude Code team does code review

Sat, 17 Oct 2026 12:00:00 +0000

How the Claude Code team does code review. Claude writes ~90% of Claude Code, so nobody reads every diff. They swapped “did a human read it?” for “which check, automated or human, should catch what could go wrong here?”, and optimise for the least human time per change, with revert and incident rates as the guardrail.

The bit I missed on first read: review noise costs more when the author is an agent. A person waves off a nit in seconds; an agent fixes every one, which is a new commit and another full review. One PR ran 50+ rounds overnight, and ~59% of later findings were on code already there at round one. Fix: cap at three rounds, re-review only the new diff, flag the class of bug, never repeat a finding.
The bot posts findings, never approvals. Human approvals (zero, one or two) are set by the change’s risk, not by who wrote it. Whoever prompted the agent counts as a reviewer, and an approval covers one commit, so an agent’s next push dismisses it.
Their reviewer’s eval is their own past incidents and reverts, run daily. Noise is measured by what authors did with each comment: fixed it, said it was wrong, intentional, or not worth it.
Versus Ankit Jain’s review layers I noted in April: this is the production version, with no spec-review layer and fast rollback under everything.
Read the numbers carefully: the share of PRs reverted fell 40% while PR volume doubled, so the count of reverts still rose (~1.2x). Also: the authors sell the reviewer.
Where I push back: “nobody needs a full mental model, ask Claude for an explainer of the slice you’re changing.” An explainer recovers what the code does, not why it was built that way, which is the comprehension debt Addy Osmani (a co-author here) wrote about. People should spend review on whether to ship it and on direction, not line-level correctness.
How I read it: had Claude explain it against my notes, then quiz me. The question I got wrong taught me the most.

Pi Pocket's subagent implementation

Fri, 09 Oct 2026 12:00:02 +0000

Pi Pocket’s subagent implementation gives each worker a retained conversation and uses durable tasks to deliver messages and report answers. Request IDs and recorded answer IDs prevent duplicate delivery and reporting after restart. The idea worth stealing: make the handoff durable, not just the worker.

Pi Durable

Wed, 07 Oct 2026 12:00:00 +0000

Pi Durable is Earendil’s experimental agent harness, shipped alongside Pi 1.0. TannerMidd/pi-pocket is a mobile-first, multiplayer web app for Pi built on it.

Every model call and tool call is a task that checkpoints to storage (SQLite, JSONL, or memory) before moving on. Kill the process and a new one opens the same file and resumes.
Recovery is per step: a cut-off model request is resent with the partial answer kept and marked aborted. A cut-off tool call reruns only if it is replay-safe; otherwise the model is told it was interrupted.
A requestId makes a submission exactly-once, so a client retrying after a crash gets the original back.
Forks see the parent transcript up to the fork point without copying it.
~15k lines total, small enough for an agent to read end to end.
pi-pocket: restart the server mid-run and the work continues. Several people can watch, steer, or queue messages on the same session.
npm start -- --access tailscale binds only to the tailnet address, so my phone gets it with no tunnel.
The shift: the session lives in a SQLite file, not a terminal process, so the phone is just another client. Could replace my Moshi + tmux setup.
Caveat: anyone who can steer runs shell commands as you.

jetify-com/typeid

Sat, 26 Sep 2026 12:00:00 +0000

jetify-com/typeid is a spec for Stripe-style IDs: user_01h2xcejqtf2nbrexx3vqjhp41 is a snake_case type prefix, _, then a UUIDv7 in 26 chars of Crockford base32 (hex UUIDs take 36). Time-ordered, so B-tree inserts stay local, unlike UUIDv4. Double-click selects the whole ID, and a serializer expecting user_ rejects a pasted post_ ID. Strip the prefix and you get a valid UUIDv7 back, so the database never has to know. Cheap way to adopt: keep the column a native 16-byte uuid (DEFAULT uuidv7() on Postgres 18, uuid.uuid7() on Python 3.14) and encode/decode only at the API edge, e.g. a DRF serializer field on top of typeid-python. If PKs are already uuid, no schema change, and IDs explain themselves in logs and support tickets.

Three Things That Bite You When You Ship gRPC to Production

Fri, 24 Jul 2026 00:00:00 +0000

I recently spent some time going deeper into gRPC, past the quickstart and into HTTP/2 framing, Protobuf encoding, and the parts of the system that sit around the service itself. I came away liking it. Contract-first APIs are useful, generated clients remove an entire class of mistakes, and streaming is part of the protocol rather than something attached later.

I also came away with a list of things I wish the quickstart had made harder to miss. They are not obscure bugs, and they are not arguments against gRPC. They are direct consequences of the choices that make it good.

Connections Are Not Requests

For a long time I carried a simple model of load balancing: a request arrives, the load balancer picks a backend, and the backend handles it. That model is often close enough for HTTP/1.1 systems, even though the machinery underneath is balancing TCP connections rather than individual requests.

gRPC makes the difference visible. It usually keeps an HTTP/2 connection open and carries many concurrent RPCs over that connection as streams. Reusing the connection avoids handshakes and lets several calls make progress at once. This is one of the reasons gRPC performs well.

An L4 load balancer cannot see those streams. It sees one TCP connection, chooses one backend when that connection opens, and keeps sending the connection there for its lifetime. If a client resolves a single virtual IP and holds one long-lived connection to it, hundreds or thousands of calls can remain pinned to one backend while other instances have very little to do.

The metrics look absurd: one pod is hot, several pods are quiet, and adding more pods changes almost nothing. The cluster has capacity, but the client has no path to it.

It is like assigning a delivery truck to a warehouse when it leaves the depot, then insisting that every package on that truck go to the same warehouse. Adding warehouses does not help. The decision was already made at the wrong level.

The fix is to balance one level higher. A gRPC client can resolve individual backends, keep subchannels to them, and choose one for each RPC with a policy such as round_robin. In Kubernetes that often means a headless service rather than a normal ClusterIP service. An HTTP/2-aware proxy such as Envoy, or a service mesh built around one, can also distribute streams across backend connections.

Both approaches work, and both add something I now have to operate: endpoint discovery and health checking in the client, or another proxy in the request path. That may be a good trade. It is still a trade.

A load balancer that understands connections does not necessarily understand gRPC.

Browser HTTP/2 Is Not gRPC

I made what seemed like an obvious inference: gRPC uses HTTP/2, browsers support HTTP/2, therefore browser JavaScript can call a gRPC service.

It cannot, at least not as native gRPC through the browser APIs available to application code.

The browser may speak HTTP/2 on the network, but JavaScript does not control that connection as an HTTP/2 peer. gRPC places its final status and error details in trailing headers after the response body, and fetch and XMLHttpRequest do not give application code the trailer behavior native gRPC expects. Client streaming and bidirectional streaming also need the request and response to remain active together, with the client writing while it reads. Browser request APIs have historically not offered that form of full-duplex transport in a portable way.

The browser owns the connection. My code gets a window into it, not the keys.

grpc-web exists to bridge that boundary. It adapts the protocol so trailers can travel inside the response body as a marked frame that browser code can read. A proxy such as Envoy commonly translates between grpc-web on the browser side and native gRPC on the service side, although some servers support grpc-web directly. Unary calls work, and server streaming can work, but client and bidirectional streaming remain constrained by the browser transport.

Connect takes a different approach. A Connect server can expose browser-friendly HTTP alongside gRPC and grpc-web, with JSON or Protobuf payloads, and the browser can call it with ordinary fetch. That removes a dedicated translation proxy in many deployments and makes a service much easier to inspect with tools such as curl. It does not grant JavaScript arbitrary control over the browser’s HTTP/2 connection; available streaming modes still depend on the browser transport.

I do not consider this a flaw in gRPC. It was designed primarily for environments where both ends are programs with control over their network stack, and server-to-server RPC is where its tradeoffs make the most sense. A browser is someone else’s runtime, with someone else’s security model and someone else’s API surface.

The mistake is not that gRPC has a boundary. The mistake is drawing an architecture diagram that pretends the boundary is not there.

Field Numbers Never Forget

Protobuf field names are for people. Field numbers are for the wire.

message User {
 string name = 1;
 string email = 2;
}

The encoded message does not contain the words name or email. It contains field numbers, wire types, and values. Renaming name to full_name while keeping field number 1 does not change the wire contract. Changing the number does.

This is easy to understand while looking at one version of a .proto file. It becomes harder after field 2 was deleted two years ago, the person who deleted it has moved to another team, and the current file makes number 2 look pleasantly unused.

It is not unused. It is retired.

Suppose a later version reuses field 2 for another length-delimited value:

message User {
 string name = 1;
 bytes avatar_hash = 2; // reused field number
}

An old client can still send an email address in field 2. The new server sees the same field number and a compatible wire type, and accepts those bytes as avatar_hash. Protobuf cannot object because the old meaning is not present on the wire. Unless validation catches it, perfectly valid bytes can acquire the wrong meaning and travel further into the system.

That is worse than a failed decode.

The fix is a tombstone:

message User {
 reserved 2;
 reserved "email";

 string name = 1;
 bytes avatar_hash = 3;
}

reserved tells the compiler that the number and name may not be used again. It turns historical knowledge into a rule the tooling can enforce. Without it, the only thing protecting the schema is memory, and organizational memory is not a compatibility mechanism.

The rest of the discipline follows from the same fact. I do not renumber fields. I reserve every removed number and name. I prefer additive changes while old and new binaries must coexist, and I introduce a new message or RPC when the meaning genuinely needs to break. Proto3’s removal of required fields came from the same hard-earned lesson: one service should not make every older peer invalid merely by evolving its schema.

A field number is small, but it is permanent.

The Abstraction Ends Somewhere

These three problems looked unrelated to me at first. One was about Kubernetes, one about browsers, and one about schema files. The common thread is that gRPC’s guarantees stop at the layer that understands them.

A TCP load balancer does not understand HTTP/2 streams. Browser JavaScript does not control the browser’s HTTP/2 implementation. Protobuf understands field numbers and wire types, but it does not understand that some bytes used to mean an email address and now mean an avatar hash.

Put those boundaries together and gRPC becomes less forgiving than its clean interface suggests. The generated method call may look like a local function, but it still crosses a network, a load balancer, a runtime, and a schema history. Each layer has constraints the service design needs to account for.

I still like gRPC, especially for internal communication across services written in different languages. The contract is real, the tooling is mature, and native streaming is valuable. I do not want to give those things up merely because the surrounding system needs care.

I need to account for those boundaries when choosing clients, load balancers, and schema changes.

Go interfaces are implicit: a type satisfies an interface by having the right…

Sun, 19 Jul 2026 12:00:00 +0000

Go interfaces are implicit: a type satisfies an interface by having the right methods, no implements keyword.

Closest Python equivalent is typing.Protocol (structural subtyping, checked by mypy), but Go enforces it at compile time, not via a separate type checker.
Sharp edge: a nil concrete pointer wrapped in an interface value is not nil. var dog *Dog = nil; var s Speaker = dog gives s != nil because the interface holds (*Dog, nil), a typed pair. Bites hardest when returning error interfaces.
Go proverb: “the bigger the interface, the weaker the abstraction.” Keep them to 1-3 methods, define where consumed not where implemented.

Ankit Jain on automated AI code review

Wed, 22 Apr 2026 12:00:00 +0000

A good collection of practices on automated AI code reviews by Ankit Jain

The Scalability Crisis: Manual post-PR review is no longer viable. AI agents have nearly doubled code output, causing human review time to spike by 91%, creating a bottleneck that traditional workflows cannot solve.
The Upstream Pivot: Human value must shift from reviewing implementation to defining intent. Instead of checking syntax, humans spend their energy writing rigorous specs and acceptance criteria before the code is written, which the machine then uses to self-verify.
The Swiss-Cheese Defense: Rather than one “perfect” human gate, the model uses a stack of imperfect automated layers. By layering signals like agent competition, deterministic guardrails, and adversarial “red-team” agents, the system catches errors where their individual failure modes don’t overlap.

Django Modern REST

Thu, 02 Apr 2026 12:00:00 +0000

Django Modern REST seems to be an emerging REST API library with focus on performance, scalability and pluggable serializers. Supporting msgpack, CBV and less of sync_to_async. Might evaluate it against the my current preferred django-ninja. gemini

Every layer of review makes you 10x slower

Tue, 17 Mar 2026 12:00:00 +0000

Every layer of review makes you 10x slower via apenwarr

UIPC and SIPC on blockchain

Thu, 05 Feb 2026 12:00:02 +0000

On blockchain, UIPC (Universal IPC) and SIPC (Secure IPC) are frameworks that allows different network to talk to each other using a standard protocol. While UIPC acts as the universal courier, SIPC acts as the security guard. Together, they create “Internet of Blockchains”. Gemini

Cosmos IBC & Polkadot - XCM are two industry leading protocols for UIPC
For the SIPC, Zero-Knowledge Proofs and Rollup architecture also “Trustless bridges” or “Cross-rollup communication” are often more frequently used terms in blockchain literatures.

Designing Data-Intensive Applications

Thu, 05 Feb 2026 12:00:00 +0000

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann manages to be both rigorous technical manual and something approaching a philosophical treatise on the nature of truth, consistency, and trust in distributed systems. [Claude][https://claude.ai/chat/0f58f2f6-bd56-41a1-a785-8267afa5a3d1]

Foundation. He starts by asking the questions “What do we actually want in our data systems”, answers them as - reliability, scalability and maintainability.
- Reliability. The question isn’t whether failure will happen, it will, but the whether the systems can survive them.
- Scalability. It’s not a binary question of whether a system is “scalable” or “not scalable”. Ask - “What happens when specific load parameter increase?”
- Maintainability - most underappreciated of the three, he argues the majority of cost isn’t in initial development but in ongoing maintainence.
The data model wars - the skill isn’t in choosing the “best” database but in understanding which tradeoffs matter for your specific problem.
Storage engines. Two major approaches to read & write data from disk, neither is universally better.
- Log-structured storage (like LSM-trees) optimizes for writes, every write is appended and the merged/compacted later.
- Page-oriented storage (like B-trees) optimizes for reads, data is stored in fixed-sized block, which then get updated in-place, more like filing cabinet with each document has a designated slot.
Instead of asking “how do I build this?” ask “what does it mean for this to work correctly?”

How AI assistance impacts the formation of coding skills

Sat, 31 Jan 2026 12:00:00 +0000

Notes on “How AI assistance impacts the formation of coding skills” Article HN

AI speeds up coding but reduces deep understanding and mastery
Juniors (1-3 years experience) showed speed improvements with AI, but 4+ year developers showed no difference
Modern software work is more about requirements, specs, documentation, and communication than raw coding skill
Small sample size (n<8) and study design limitations make results questionable
Takeaways:
1. Use AI for high-scoring interaction patterns: Ask conceptual questions and request explanations rather than just code generation
2. Adopt AI for documentation and specs: Multiple developers report dramatic improvements in tickets, PRs, and documentation quality
3. Be deliberate about learning: If using AI, actively practice explaining concepts and avoid pure copy-paste workflows
4. Use AI to reduce grunt work: Let it handle boilerplate, test writing, and repetitive tasks while focusing on architecture and requirements
The research confirms what many suspected: AI coding assistants create a real trade-off between speed and skill development, but the practical significance is hotly contested. The critical question isn’t whether AI reduces learning (it does), but whether deep coding skill remains as valuable as expressing requirements clearly—and whether we’re comfortable with a generation of developers who can’t function without AI assistance.

Thoughtworks - Technology Radar vol 33

Mon, 22 Dec 2025 12:00:02 +0000

Notes from Thoughtworks - Technology Radar vol 33

text-to-sql solutions aren’t working as expected
pnpm, langGraph, and pydantic recommended for adoption

Inversion of Control

Mon, 22 Dec 2025 12:00:00 +0000

Inversion of Control principle – “Don’t call us, we’ll call you”.

This design principle is used widely in Web Frameworks, GUI programs, etc in the form of event listeners, dependency injections, callbacks to avoid boilerplate code, resuability and testability.
Some popular examples are DOM, Flask, NestJS, Angular, etc.

Choose Boring Tech

Fri, 19 Dec 2025 12:00:02 +0000

“Choose Boring Tech” by Dan McKinley

“The failure mode of boring tech are well-understood”

Django rapid architecture

Fri, 19 Dec 2025 12:00:01 +0000

Notes from “Django rapid architecture”

Recommends organizing the codebase with interfaces at the top layer followed by readers and “actions”, Finally, ‘data’ as the bottom layer to organize Django codebase to allow for a simple code structure that allows for scaling