#architecture

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. discuss

• 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 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. discuss

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. discuss

• 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 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. discuss

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.

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 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 via apenwarr

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: 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?"

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.

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 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" by Dan McKinley

• "The failure mode of boring tech are well-understood"

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