Agentic Code Review

Addy Osmani · 2026-06-15 · 25 min read

TLDR: AI coding tools produce ~4x more code but only ~12% more actual delivered value — the gap is unreviewed risk, not productivity. Code review is now the highest-leverage engineering skill precisely because it's the one step that didn't get faster, and the data shows teams are already losing control: defect rates up 6x, incidents up 242%, and a third more PRs merging with zero review. The right response isn't less AI, it's treating review as the critical bottleneck it now is, scaled appropriately to your blast radius.

Continual Learning for AI Agents: From Failures to Durable Improvements - Soheil Feizi, RELAI

AI Engineer · 2026-07-05

This video introduces Verifiable Continual Learning (VCL) for AI agents, a framework for improving agents from their experiences without forgetting past knowledge. VCL addresses two core challenges: acquiring actionable feedback from production logs and effectively optimizing the agent across its model, harness, and memory layers. The framework emphasizes making learning replayable, ensuring improvements are holistic and targeted to the right layer, facilitating lifelong learning by preventing regressions, and ensuring the process is efficient to run continuously.

read more

Soheil Feizi introduces Verifiable Continual Learning (VCL) for AI agents, drawing an analogy to how humans learn from experience by acting, getting feedback, and improving without forgetting. The goal of VCL is to enable AI agents to continuously improve from their experiences without forgetting past learnings.

The architecture of an AI agent is typically broken down into three main layers: the Model (e.g., LLMs, weights, model selection), the Harness (e.g., prompts, skills, tools, code, workflow), and Memory (e.g., in-session state, persistent knowledge). The agent interacts with the World, which includes users, tools, and data policies, generating logs and outputs.

Feizi identifies two fundamental challenges in continual learning: 1. Getting Feedback (P1): How do we know if the agent performed well, and if not, what should it have done instead? In development, this is often handled with curated benchmarks and evaluators. In production, however, raw logs are not explicit feedback. Feedback can be generated automatically by an LLM or code analyzing the log, which scales to every session. Alternatively, human experts can provide critical feedback on a lower volume of sessions, catching subtle correctness, policy, and taste issues. Even with logs plus feedback, a significant gap remains: it's not directly testable. 2. Agent Optimization (P2): Given feedback, which layer or components of the agent should be changed, and how? Simply having log+feedback isn't enough; what's needed is a replayable learning environment. This environment is an inferred distribution that replays what happened and defines what success means. It comprises: Observed trace + feedback (what happened), Mocked/real tools (what the agent can call), a Synthetic user (what interaction repeats), and Evaluators (what success means). The output of this environment is executable, allowing candidate agents to be run against it, and fixes kept only if they pass.

Feizi outlines three layers for improving the agent: Model: Updating the weights of LLMs or other models, or selecting different models. Techniques like Supervised Fine-Tuning (SFT) (imitating correct trajectories with labeled examples) and Reinforcement Learning (RL) post-training (sampling, scoring against a reward/preference signal, reinforcing what wins, e.g., DPO, GRPO, RLVVR) are used. LoRA (Low-Rank Adaptation) can limit the set of parameters that change, leading to cheaper and safer updates. Model updates are generally the most expensive option and require benchmarks + evaluators. Harness: Editing prompts, skills, and code around the model. Trace-to-harness involves a coding agent rewriting prompts, adding tools, or patching workflows based on log+feedback. This is mostly vibe-based as there's no test to confirm the change helped. GEPA (Generalized Evolutionary Programming for Agents) & prompt search mutates prompts, scores candidates, and keeps winners through evolutionary optimization. This is testable but requires a benchmark to score against, which means creating a replayable learning environment. * Memory: Storing facts and learned skills so the agent doesn't rediscover them. Information memory (e.g., Letta, mem0) stores facts or corrections (e.g., "always confirm the date before booking"). Skill distillation (e.g., skills.md) compresses successful trajectories into reusable "how-to" packets. Memory updates are the cheapest and fastest and work directly on log+feedback, but are usually unverified.

A good learning engine asks for the smallest durable change at the right layer.

Feizi introduces four principles for Verifiable Continual Learning (VCL): 1. Replayable: Turn a log + feedback into a testable learning environment. This fixes the fundamental problem of getting actionable feedback. 2. Holistic: Route each fix to the right layer—model, harness, or memory. A single failure can have multiple causes and repairs, so the fix must be applied where it most effectively addresses the root cause with the smallest durable change. 3. Lifelong: Improve without regressing on what already worked. This means integrating regression-aware learning within the agent optimization loop, not as a post-hoc check. The goal is to maximize performance on new failures (E_k+1) subject to no regression on past successes (E_1...E_k). 4. Efficient: Pick the smallest fix that works, so the loop runs continuously. Updates should be prioritized based on cost: memory writes (cheap) -> skill/prompt edits (low-mid) -> search over harness (mid) -> model updates (expensive).

RELAY's learning loop incorporates these principles: Signals (logs, feedback, prompts) are transformed into Replayable learning environments. Root-cause analysis routes the fix to the correct layer (Holistic). Regression-aware optimization ensures Lifelong improvements. The process generates a Reviewable, versioned update, closing the loop.

Feizi demonstrates VCL in practice with a Meridian Support Agent, a reproducible testbed for continual learning in a tool-using support agent. This benchmark features a single source of truth (fixed company policy and database define correct actions) and interacting policies (refunds, escalation, etc.). It uses deterministic evaluators, treats decisions as tool calls, and is regression-sensitive by design.

An example illustrates creating a learning environment from a prompt (e.g., an adversarial customer demanding an unauthorized refund). RELAY CLI creates a simulator (persona, intent, mocked/real tools) and evaluators (pass/fail metrics with feedback), all from one interactive command. Simulating the current agent shows struggles (e.g., failing to route escalation, latency budget issues). Running `relai optimize` improves the average score significantly (e.g., +10% average improvement, 97% average score from 87%). The change, such as canonicalizing refund-escalation arguments, is applied on the live tool and subject to online regression control. This demonstrates compounding lifelong agent improvements where each update is tested, every gain is measured, and nothing that already worked is broken.

In summary, agent continual learning is not just model fine-tuning; useful updates can occur in the harness or memory. Production logs are not learning environments and must be transformed into replayable tasks. The frontier is regression-aware continual improvement, fixing new failures while verifying old ones are preserved. Verifiable Continual Learning = replayable + holistic + lifelong + efficient.

sqlite-utils 4.0rc2, mostly written by Claude Fable (for about $149.25)

Simon Willison · 2026-07-05 · 13 min read

TLDR: Using Claude Fable via Claude Code, Willison completed the sqlite-utils 4.0 release through 37 prompts and ~$149 in compute, catching a serious data-loss bug (`delete_where()` silently leaving connections in an uncommitted transaction state) that had slipped past his own review. The most actionable takeaway: cross-model review (having GPT-5.5 audit Claude's work and vice versa) consistently surfaces real bugs—here it caught two additional transaction correctness issues in `db.query()` after Fable had already done a full pass.

The New Software Lifecycle

Addy Osmani · 2026-06-16 · 10 min read

TLDR: The biggest shift in AI-assisted development isn't the model — it's everything around it. Agent performance is determined ~90% by the "harness" (instructions, tools, memory, orchestration, guardrails), meaning most failures are configuration problems you can fix today. Consequently, the real engineering discipline becomes context design and verification: treating what you load into the agent's context as a versioned architectural decision, and using evals (not demos) as your quality bar.

AI demands more engineering discipline. Not less

Charity Majors · 2026-06-15 · 19 min read

TLDR: The shift to AI-generated code mirrors the move to immutable infrastructure — the correct response isn't to abandon engineering discipline, but to relocate it. When code becomes disposable and instantly regenerable, the rigor moves downstream into production validation, observability, and system-level understanding rather than line-by-line code review. Engineers who resist this shift aren't being rigorous — they're applying rigor to the wrong layer.

AI enthusiasts are in a race against time, AI skeptics are in a race against entropy

Charity Majors · 2026-06-02 · 18 min read

TLDR: The real problem isn't AI skeptics vs. enthusiasts — it's that the wins and the costs land on different people, so there's no natural feedback loop forcing honest accounting. Teams shipping AI-generated code fast enough to clear backlogs often don't see the reliability debt and institutional knowledge loss they're creating downstream, while skeptics only hear the inflated wins and tune out entirely. The fix starts with telling the whole story: report the productivity gains and the cleanup cost, the way Intercom did when they 3x'd output but also honestly tracked 18 months of code quality decline before it turned around.

Potpourri: Lessons from an AI Leadership Conference

Kent Beck · 2026-04-13 · 1 min read

Kent Beck attended Gene Kim's Enterprise AI Summit and distilled his observations into a survey of current AI topics he considered addressing in his closing keynote. For a senior engineer, this matters because Beck's pattern-recognition across leadership-level AI discussions can surface which organizational and technical AI concerns are actually gaining traction at the decision-making layer, as opposed to the usual hype cycle noise.

Extreme Time Value of Money: Late-stage Career Planning

Kent Beck · 2026-04-21 · 7 min read

TLDR: As you age, your personal "discount rate" for future money isn't constant — it spikes sharply and eventually becomes infinite past the horizon where you're likely alive and healthy enough to enjoy it. This means standard tech compensation structures (4-5 year vesting, illiquid equity, decade-long payoff timelines) are a genuinely bad deal for senior engineers in their 60s, not just an inconvenience. The rational response is to aggressively prioritize near-term, liquid income over long-term upside that may arrive too late to matter.

Why your teams aren’t really empowered (and how to fix It)

Henrik Kniberg · 2024-11-07 · 8 min read

TLDR: True team empowerment means giving teams a problem to solve, not a solution to implement — most companies only grant autonomy over technical details while decisions about what to build remain centralized. For empowerment to work, leaders must pair meaningful, measurable objectives with strategic context, direct customer access, clear constraints, and genuine psychological safety to experiment and fail. Without that full environment, handing teams "ownership" is just theater.

A Virtual Brainfuck Machine In Go

Thorsten Ball · 2017-01-04 · 27 min read

TLDR: Brainfuck is an ideal teaching tool for understanding how programming language runtimes work because its minimal design (8 instructions, 30,000 memory cells, a data pointer, and an instruction pointer) maps directly and transparently onto the components of a virtual machine. Building an interpreter for it in Go demonstrates core VM concepts — fetch-decode-execute loops, memory models, and I/O streams — without the complexity that obscures these mechanisms in real-world languages.