Turning every review comment, rubber-stamped PR, and missed acceptance criterion into a process improvement.
TL;DR
- Large companies like Stripe, Uber, and Spotify merge thousands of agent-authored PRs a week. What’s unsolved is whether the organization gets smarter from them.
- AI helps with technical debt (in code) but accelerates cognitive debt (in people) and intent debt (in artifacts) because people accept AI output without building real understanding.
- Instead of removing the code review, this post suggests risk-stratified review by blast radius.
- What most teams are missing is an audit layer, e.g., a periodic scan of the last N merged PRs that tells you whether your review process is actually working.
- I have built a five-stage flywheel: a PR merges ->
ygs-learnextracts what reviewers taught the system -> the next agent run reads those learnings -> periodicygs-pr-auditandygs-code-auditruns surface systemic patterns.
Agentic Engineering Maturity Model
When I started using unit testing and test driven development decades ago, it taught me that tests don’t eliminate bugs. Instead, they create a feedback loop that makes the next bug less likely. For example, you may write a test as part of the development process or as a result of a production bug that you had to fix. With each test, you build a regression suite that acts as a quality gate, and serves as an institutional memory of every mistake the teams made. Agentic engineering needs the same thing where they don’t just write code but a flywheel that turns every review comment or incident into process or a skill so that the organization gets better over time. For example, I see three levels of how teams use AI in their development workflow:
- Pull systems: You ask an agent to do something, e.g., interactive sessions with Claude Code but the learning disappears when you close the session.
- Push systems (“software factories” or “ambient agents”): The system asks the agent to do things continuously, e.g., pick up issues, write code, open PRs. Humans are then looped in when a decision needs judgment.
- Learning systems: The push system that also records what it learned, closes the loop, and updates its own skills and guardrails. This allows the next run to get better because the organization’s captured knowledge improved.
I have been building automated workflows for the third level that I will share in this post.
What I’ve Already Built
Over the past year I’ve built three interconnected open-source systems, covered in two earlier posts:
- Formicary is a DAG-based orchestration engine that runs on Kubernetes. It handles scheduling, fault tolerance, retries, timeouts, artifact passing, and capacity management, so your AI workflows don’t have to. I wrote about this in Killing the State Machine: Declarative AI Coding Agents with an Orchestration System.
- ai-dev-tools is the Python harness that wires Claude Code into SDLC workflows like cloning repos, enriching PR data, routing to the right model based on task complexity, and posting results to Slack.
- you-got-skills is a library of 40+ Claude Code skills covering the full development lifecycle. Both are covered in Orchestrating Background AI Agents for Software Teams.
I have built several declarative AI workflow definitions based on these primitives:
ai-gh-implement.yaml — plan ? implement ? create-pr ? poll-pr
ai-gh-review.yaml — automated code review on a single PR
ai-standup-gh.yaml — daily standup brief from GitHub + Slack
ai-gh-pr-audit.yaml — PR gap analysis ? skill improvement PR ? learn
ai-codebase-audit.yaml — codebase archaeology across N commits
ai-gh-issue-picker.yaml — intelligent issue triage and selection
ai-jira-implement.yaml — same pipeline for Jira/Bitbucket repos
ai-jira-review.yaml — code review for Bitbucket PRs
ai-jira-pr-audit.yaml — PR audit for Jira-tracked repos
ai-adhoc.yaml — run any skill from a Slack commandI also built 40+ skills, including ygs-implement, ygs-code-review, ygs-review-deep, ygs-security-review, ygs-sre-review, ygs-learn, ygs-pr-audit, ygs-codebase-audit, ygs-standup, ygs-risk-scan, ygs-sprint-plan, ygs-estimate, ygs-qa, and ygs-ship.
Slack Is the Interface
I have been using Slack to interact with the orchestration engine, e.g., an engineer types a command in a channel, Formicary picks it up, runs the right workflow on Kubernetes, and threads all status updates and results:
Engineer: @bot implement acme/backend#142
Bot: ? Planning implementation for issue #142...
Bot: ? Plan ready — 3 files, estimated complexity: medium (using Sonnet)
Bot: ?? Implementing... (48 turns)
Bot: ? Self-review found 0 critical issues
Bot: ? PR #287 opened: https://github.com/acme/backend/pull/287
Bot: ? Watching PR for review comments...
[2 hours later, reviewer comments on PR]
Bot: ? Responding to 2 review comments, pushing fixes...
[reviewer approves, PR merges]
Bot: ? PR #287 merged. Running ygs-learn to extract learnings...
Bot: ? 1 new learning captured: "Cache invalidation must check ACL per-request"The ai-adhoc.yaml workflow lets engineers run any skill on demand so the full skill library is available without leaving Slack.
The Implement Pipeline
The workhorse workflow is ai-gh-implement, a six-task DAG:
plan ? implement ? self-review ? create-pr ? poll-pr ? doneIn above workflow, self-review is invoked after the agent implements a change to review its own diff against the plan and the issue’s acceptance criteria. It can loop in human review if it finds any issues and the engineer resolves it before the PR even opens. Also, it uses a complexity-based model routing where the plan step estimates task complexity (low, medium, high) and writes it to an artifact. The implement then picks the model to match to keep the costs proportional to difficult.
The Learning Skills
Following are learning workflows that I built:
ygs-pr-audit: analyzes the last N merged PRs across four dimensions (spec, design, skills, process), surfaces systemic gaps with evidence, and produces a list of recommended skill updates.ygs-codebase-audit: runs structural archaeology across N commits, detecting hotspots, knowledge silos, duplicate abstractions, test brittleness, and security gaps using git/grep/find commands against the codebase.ygs-learn: fires automatically when a PR merges insideai-gh-implement. Thepoll-prtask detects the merge and callsygs-learn, which extracts atomic learnings from review comments and writes learning documents that future agent runs read.
The ygs-learn is wired into poll-pr so every merged PR automatically triggers learning extraction.
The Factory Floor Problem
The Software factory or ambient agents create a system that proactively respond to events (a new issue, a failing test, a merged PR) instead of waiting for a human to ask. For example, Igor Ostrovsky shared common patterns where a software factory starts work from events and coordinates agents through engineering workflows like agents reading/writing specs/issues/pull requests while people approve key decisions. He models it as a graph, e.g., nodes are artifacts, edges are agent-driven transformations, and approvals and CI checks gate progress. This maps onto what Formicary does: a DAG of Kubernetes tasks, where each task produces artifacts the next one consumes with exit-code-based routing and human decision points. Uber shared a similar layering in their “agentic SDLC platform“, a context graph, an LLM gateway, and a governance layer underneath their agents. The Formicary / ai-dev-tools / you-got-skills setup is a smaller, open-source version of the same idea.
Other large companies are using similar software factories:
- Stripe’s Minions merge 1,000+ PRs per week in Ruby with human PR review as the gate.
- Uber’s Minion opens roughly 11% of company-wide PRs directly andover 70% of all PRs agent-attributed.
- Spotify’s Honk reports 650+ agent-authored merged PRs per month with up to 90% time savings on migration-style work.
Here’s what a Formicary workflow definition looks like in practice:
- task_type: poll-pr
method: KUBERNETES
timeout: 168h
dependencies:
- create-pr
- poll-pr # self-dependency: re-runs after PAUSE_JOB
script:
- python -m scripts.gh.check_pr_state --issue-id {{.IssueNumber}}
- python -m scripts.gh.fetch_comments --issue-id {{.IssueNumber}}
- python -m scripts.gh.respond_comments --issue-id {{.IssueNumber}}
on_exit_code:
3: PAUSE_JOB # PR still open — wait, then re-run
delay: "120s" # check every 2 minutesPAUSE_JOB allows a loop without blocking, e.g., poll-pr sees the PR is still open, it exits with code 3. Formicary pauses the task, waits 120 seconds, and re-runs it. When a reviewer leaves comments, the task fetches them, has Claude respond, and pushes fixes. When the PR merges, check_pr_state calls ygs-learn to extract learnings.
But none of above workflows answer a key question: What did the organization learn from the last 50 PRs that merged?Which review patterns are failing? Where are knowledge silos growing? What mistakes keep repeating? Are reviewers actually reviewing, or rubber-stamping?
The current wave of software factories optimizes the pipeline (issue to deploy) and treats code review as a throughput bottleneck to shrink. Some teams like StrongDM are removing it entirely. That may work for some organizations but it’s not practical for most enterprises. Code review isn’t just a quality gate. For example, Google’s internal engineering practices and a recent study of 3,100 practitioner opinions treat knowledge transfer as equally important as defect detection. Review is where junior engineers absorb senior engineers’ mental models and where architectural decisions are explained. It builds a shared understanding of how the system works or what Fred Brooks calls a conceptual integrity.
Three Kinds of Debt
Margaret-Anne Storey’s Triple Debt Model defined following terminology for what goes wrong when throughput outpaces understanding:
- Technical Debt (Code): This is already known term for poor implementation choices that make systems harder to change, tangled dependencies, missing abstractions, etc. However, AI is actually helping with technical debt with automated refactoring and AI-generated test suites.
- Cognitive Debt (People): Cognitive debt is the erosion of shared understanding across a team over time. The team can no longer confidently explain how the system works or predict the impact of a change. For example, when AI generates code, a developer might accept it without building real understanding of it. At scale, across a team, that becomes an accumulation of not knowing. Researchers call this cognitive surrender. In another follow-up post, Storey lists symptoms such as: engineers lose confidence making changes, debugging takes longer, onboarding takes longer, and code review overhead goes up. The fixes are inherently human: code review, pair programming, system walkthroughs, retrospectives.
- Intent Debt (Artifacts): Intent debt is the absence of externalized rationale that explain what a system is for and how it should evolve. In other words, nobody wrote down why the system works this way, so nobody. Addy Osmani’s blog on intent-debt explains that the cost of undocumented intent used to be paid by humans touching the code but now every agent pays it. My skills repository like the
docs/prd/,docs/adr/, anddocs/learnings/directories allow agents to make decisions based on what the system is actually trying to accomplish.
The Triple Debt in Practice
| Debt Type | Where It Lives | What Fixes It | What Accelerates It |
|---|---|---|---|
| Technical | Code | Tests, static analysis, refactoring | Shipping without testing |
| Cognitive | People | Review, pairing, walkthroughs, onboarding | AI-generated code accepted without understanding |
| Intent | Artifacts | ADRs, specs, skills, learnings | Every agent session that starts without captured rationale |
Generative AI reduce technical debt through automated refactoring and test generation but it accelerates cognitive and intent debt, because the team ends up producing code faster than it can build shared understanding of what that code does and why.
Why Humans Stay in Review
The answer isn’t to keep the review process as it was or remove it all together. It’s risk-stratified review based on risk and blast radius. For example, Meta published Automating Low-Risk Code Review (RADAR) that described a multi-stage funnel for deciding which changes can land without human review:
- Eligibility gates: is this diff type eligible for automation at all?
- Diff Risk Score: a machine-learned model predicting the likelihood of a production incident.
- LLM-based automated code review: an AI reviewer that can approve with high confidence.
- Deterministic validation checks: a final safety net.
Teams at Meta tune their own risk thresholds so that they can automate the low-risk changes and route the high-risk ones to humans. Qodo also ships a classifier that labels PRs by scope and sensitivity in context so that reviewers can triage their attention. That’s what we are trying to do in my organization so that for high-blast-radius changes like auth, billing, security plugins, etc., humans stay in the loop. Also, I built something that other doesn’t have: an audit layer that tells you whether your risk calibration is actually working.
The Audit Layer
RADAR-style gating prevents the risky merge from happening but my PR audit catches when the gating itself is failing. For example, when reviewers are rubber-stamping security changes, bot-flagged critical findings go unacknowledged, or when large architectural PRs ship with two comments. Here are examples of my PR audit runs (details anonymized):
| Metric | Value | Benchmark | Signal |
|---|---|---|---|
| Rubber-stamp rate (high blast-radius) | 50% | <10% healthy / >25% problem | ? Problem |
| Security review coverage | 0% | — | ? Gap |
| Bot-finding follow-through | ~80% | >90% healthy / <70% gap | ?? Warning |
| Human review burden | ~78% | <40% healthy / >70% overloaded | ?? Overloaded |
| Formal acceptance criteria coverage | 13% | >80% healthy / <50% reactive | ? Critical |
Half of the high-blast-radius PRs like auth, billing, and security got rubber-stamp approvals with little substantive comments. The code-review bot caught roughly 22% of substantive findings versus humans’ 78%, meaning the team was leaning heavily on human reviewers for architectural and security issues. In A practical guide to risk-based code review, Cortex’s research predicts that a reviewer’s ability to catch defects collapses past 200–400 lines of code. AI generates code faster than that threshold so approval rates rise while inline comments fall. The ygs-pr-audit skill identifies gaps in the automated review process so that we can improve skills, processes, specifications and other aspects of the development process.
The Flywheel for Learning Culture
In order to continuously improve your development process, you need a feedback loop for continuous learning. You can consider it as a learning flywheel for the workflows of entire software development process:
Stage 1: A PR merges. poll-pr detects it.
Every implementation workflow has a poll-pr task that checks PR state periodically. When the status flips to merged (or declined), the task exits the loop and triggers the next stage.
Stage 2: ygs-learn extracts learnings.
On merge, the system invokes ygs-learn in extract mode. Before touching review comments, it runs Phase 0: PR Health Check across five dimensions:
- Spec coverage: Did the linked issue have formal acceptance criteria?
- Design decisions: Were architectural choices documented, or did the PR just change code?
- Security/SRE: Did the PR touch security-sensitive paths?
- Review quality: How many substantive human comments? Was there a rubber-stamp?
- CI health: Did CI pass cleanly, or were there flaky retries?
Phase 0 produces a one-paragraph health summary that becomes metadata on the learning. It also catches the edge case where a PR merges with no review comments at all. After Phase 0, ygs-learn enters extract mode. It fetches every review comment from the merged PR and asks: does this reveal a recurring pattern, a gotcha that would apply to future work? For each actionable insight, ygs-learn sorts it into one of seven categories: Edge Case, Integration Gotcha, Performance Cliff, Security Trap, Process Friction, Domain Rule, or Tooling Quirk and writes a structured document:
# Guard Bypass After Cache: Security Gate Evaluated Once at Load Time
**Category:** Security Trap
**Date:** 2026-09-08
**Source:** Review feedback on PR #XXXX — reviewer caught that
the authorization check runs once at connection creation, not per query
## Learning
If a security gate (e.g., isFeatureAllowed()) is checked once at load time
and the result is cached, the gate must also be checked before every use
of the cached object. Otherwise, a permission revocation after initial
load is silently ignored.
## Evidence
Database connection manager called isAllowed() once in getConnection(),
cached the client, and returned the cached client on subsequent calls.
A reviewer identified that revoking the feature flag mid-session would
have no effect.
## Application
When reviewing code that caches authenticated/authorized resources:
check whether the authorization check is repeated before each use,
not just at creation time.Each learning is stored in docs/learnings/YYYY-MM-DD-slug.md with deduplication.
Stage 3: The next implementation run reads the learnings.
When the next ygs-implement pipeline runs, its planning and implementation steps load docs/learnings/ as context. If the last PR’s reviewer caught a cache-bypass vulnerability, the next agent run that touches caching code has that learning in front of it. This is similar to NVIDIA’s MAPE control loop for production AI agents: Monitor (poll-pr watches for the merge and collects review signals) -> Analyze (ygs-learn categorizes what happened and why it matters) -> Plan (writes learnings to docs/learnings/) -> Execute (the next implementation pipeline reads those learnings as context). Augment Code describes something similar like execute, coach, distill, improve in their Agent Learning Flywheel blog except their coaching happens synchronously in Slack but my extraction happens asynchronously after the PR closes.
Stage 4: ygs-pr-audit looks across many PRs and recommends systemic changes.
Individual learnings are useful but the real leverage comes from periodic audits that scan last N merged PRs at once and spot common patterns like is the rubber-stamp rate climbing or are bot findings getting ignored before merge? The key output for the flywheel is skill_improvements.json, a list of recommended changes to the repo’s skill files: create .claude/skills/security-review/SKILL.md, update .claude/docs/testing.md with a flaky-test-triage section, etc.
Stage 5: The audit opens a real PR with skill improvements.
The plan-skill-updates task reads the audit findings and writes an update plan. create-skill-pr implements those changes and opens a pull request against the repo. poll-pr then watches that skill-improvement PR, responds to human reviewer comments. The system learns from its own improvement process.
Every report includes a Positive Patterns section naming exemplary reviewers, e.g., the person who traced a security issue to its root cause, the reviewer who ran local tests to verify a bot-authored PR, etc. This is the blameless-postmortem move applied to code review. The postmortem maturity literature teaches that punishing people for incidents makes people stop surfacing incidents. Recognizing good work and documenting thoroughness are important design decisions.
Sharing Learnings Across the Organization
Though, individual repo learnings live in docs/learnings/ inside each repo but I created a shared skills repository you-got-skills for common skills like ygs-implement, ygs-code-review, ygs-security-review, and the rest. This shared repository is improved based on continuous learnings from the audit reports.
Inside the PR Audit: A Concrete Walkthrough
Let me show how the PR audit works in the format I used in Killing the State Machine, where every design choice is explained with its reasoning.
The workflow triggers from Slack:
@bot pr-audit acme/backend
or
@bot pr-audit acme/backend --focus skills --n-prs 30Formicary picks up the message, resolves it against the ai-gh-pr-audit job type, and runs a five-task DAG:
The audit-prs Task
The Python harness (run_pr_audit.py) does the heavy lifting before the LLM sees the data: clone the repo, fetch the last N merged PRs, classify every comment and check acceptance criteria. The LLM then invokes Claude with the ygs-pr-audit skill, which runs a disciplined 5-phase protocol:
- Phase 1 Setup. Load shared references, check whether the repo has its own skill overrides in
.claude/skills/and read the pre-computed PR data. - Phase 2 Four specialist passes. This is the core analysis for the most common failure mode. Each PR is scored across all four dimensions and the findings are tagged by dimension (
[SPEC],[DESIGN],[SKILL-GAP],[PRACTICE]). - Phase 2.5 Deep review escalation. Security-sensitive PRs and large, under-reviewed PRs get escalated to specialized deep-review skills.
- Phase 3 Verification gate. This is to remove any false positive, e.g., the instructions are blunt: re-examine every finding, re-read the cited evidence, confirm the conclusion actually follows from the data.
- Phase 4 Synthesis. Deduplicate findings, escalate severity, compute the metrics dashboard, and write the full report.
Here’s an anonymized executive summary from a real run:
[PRACTICE] Rubber-stamp approval on high blast-radius changes Confidence: HIGH | gap_type: process | impact: increases_risk Frequency: 4/8 high-blast-radius PRs (50%)
And here’s what a finding looks like in full:
[PRACTICE] Rubber-stamp approval on high blast-radius changes
Confidence: HIGH | gap_type: process | impact: increases_risk
Frequency: 4/8 high-blast-radius PRs (50%)
Evidence:
- PR #XXXX (infra registry, +587 LOC, 6 Terraform files):
4 approvers, all rubber-stamp with 0 substantive comments.
- PR #YYYY (billing metrics, 6 files, +359/-184 LOC):
2 approvers, both rubber-stamp, 0 substantive comments.
- PR #ZZZZ (security detection rule router, 12 files, +2058/-27 LOC):
1 rubber-stamp approver; only substantive comments were merge-conflict messages.
Recommendation: Require ?1 substantive technical comment from at least one
approver on PRs touching auth/billing/security plugins/infra.
Track rubber-stamp rate on high-blast-radius PRs as a team health metric.The most actionable part of the report is the Recommended Skill Updates table:
| Action | Skill Path | What to Add | Motivated By |
|---|---|---|---|
| Create | .claude/skills/security-review/SKILL.md | Validation patterns, RBAC header checks, IAM audit | PRs with auth gaps |
| Update | .claude/docs/testing.md | “Flaky test triage” section: root-cause classification, prohibition on removing regression assertions | 3 reactive flaky-test fixes in one day |
| Update | .claude/skills/sdet-pr-review/SKILL.md | Bot-authored PR review bar: reviewer must document what they validated | Bot PRs merged with zero substantive review |
| Create | .claude/docs/review-standards.md | High-blast-radius taxonomy, bot-finding acknowledgment policy | Rubber-stamp patterns |
These recommendations feed directly into plan-skill-updates, which writes concrete file changes, and create-skill-pr. The system doesn’t just report; it proposes, implements, and waits for human review before changing anything.
What the Engineer Sees in Slack
The full report posts to the Slack thread that triggered the audit:
? PR Audit Complete — acme/backend (50 PRs analyzed)
? 11 findings: 3 spec gaps · 2 design gaps · 2 skill gaps · 4 practice gaps
? Critical: 4/8 high-blast-radius PRs rubber-stamped
? Critical: 0% security review coverage
? Critical: Formal acceptance criteria missing in 94% of PRs
?? Warning: Bot findings acknowledged only ~80% of the time
? Skill improvement PR opened: #312
? Creates .claude/skills/security-review/SKILL.md
? Updates .claude/docs/testing.md
? Updates .claude/skills/sdet-pr-review/SKILL.md
Full report attached as pr_audit_report.mdEvery workflow like implement, review, audit, standup follows the same pattern: trigger from Slack, thread all updates back to the same conversation, post results to the same thread.
The Codebase Audit: Structural Archaeology
The PR audit examines process like how PRs were reviewed, what gaps appeared along the way. The codebase audit examines structure like what’s accumulated in the code itself across hundreds of commits.
Triggered from Slack:
@bot codebase-audit acme/backend --focus security
The codebase audit runs actual commands against the codebase like git log, grep, find and reports findings with file-and-line evidence. It covers seven dimensions:
- Hotspots: files changed most frequently, and files with the highest bug-fix ratio.
- Architecture: module coupling, dependency direction violations, abstraction leaks.
- Security: hardcoded credentials, missing input validation, auth pattern violations.
- Duplicates: near-identical implementations across different modules.
- Test health: missing test files, timing-based tests, coverage gaps.
- SRE: missing health checks, observability, alerting for new endpoints, improper error handling.
- Knowledge silos: single-contributor ownership of critical paths.
An anonymized finding:
[SILO] 83% of auth/ commits by a single contributor over 6 months
Severity: HIGH | Confidence: HIGH
Evidence: `git log --since="6 months ago" --format='%an' -- auth/ | sort | uniq -c | sort -rn`
147 alice.chen
18 bob.kumar
12 carol.jones
Impact: Bus factor of 1 for the authentication subsystem. If this contributor
is unavailable, the team has no one with deep context on auth token rotation,
session management, or the RBAC middleware.
Recommendation: Pair-rotate code review assignments for auth/ — ensure at
least 2 other engineers review every auth PR for the next quarter to build
shared understanding.A knowledge-silo finding might turn into a new pairing guideline in .claude/docs/review-assignments.md. A duplicate-abstraction finding might become a new entry in .claude/skills/gotchas/retry-patterns.md, telling future agent runs to reuse the existing retry mechanism. Between the two audits you get complementary views: the PR audit surfaces process failures, the codebase audit surfaces structural failures.
The Learning Maturity Ladder
Agentic engineering’s learning loop is still evolving. Here’s a maturity ladder, adapted from the postmortem maturity model:
- Level 0 No Capture. The same mistakes repeat across sprints.There’s no institutional memory beyond individual engineers’ heads.
- Level 1 Capture in Context. Comments happen in PRs and Slack. Knowledge exists but it’s scattered across dozens of closed PR threads and Slack channels.
- Level 2 Write-Only Knowledge Base. You have ADRs, learnings documents, or a wiki but nobody loads them as context for new work.
- Level 3 Active Context Loading. Learnings are automatically provided as context for agent runs. The planning step reads
docs/learnings/anddocs/adr/before writing a plan. - Level 4 Self-Modifying Skills. An audit layer periodically reads learnings, analyzes PR patterns, and proposes changes to the skills themselves. The system’s instructions evolve based on evidence.
My system sits between level 3 and 4 with skills like ygs-learn, ygs-code-audit and ygs-pr-audit, e.g., recommended skill is the beginning of Level 4.
Gaps in the skills
I am still learning from applying these skills and I have found several gaps:
- Audits are per-repo, per-batch. The PR audit analyzes the merged PRs in a single repository. It works when we have a monorepo like repository but it becomes more cumbersome with more repositories
- Rubber-stamp detection is a heuristic. The system matches common phrases (LGTM, +1, looks good, ship it, etc) and counts substantive comments. A reviewer who writes one terse but thoughtful sentence could get miscounted as rubber-stamping and vice verse.
- The learnings directory could become noise.
ygs-learndeduplicates before writing but this can still grow to a large size so some kind of pruning mechanism will be required. - Full automation may be right for some teams. There are teams shipping software nobody writes or reviews, and it works for them. Risk-based calibration is my stance for the organizations I work with large codebases, thousands of engineers and security-sensitive systems.
- Cost is not trivial. Running an Opus-class model for a 120-turn PR audit session is expensive. I use model routing like Sonnet for implementation, Opus for audits and deep reviews, Haiku for simple classification but this can still be expensive.
Closing
Testing didn’t get replaced when we bolted on CI pipelines, and coverage metrics. It means instead of saying no bugs in this release, we strengthened regression suite to prevent similar bugs. Agentic engineering is at the same inflection point. Instead of optimizing for just writing code fast, we can get better at writing code with a learning flywheel so that agents remember what they learned.
Related Reading
- Orchestrating Background AI Agents for Software Teams
- Killing the State Machine: Declarative AI Coding Agents with an Orchestration System
- Building Production-Grade AI Agents with MCP and A2A
- Building a Production-Grade Enterprise AI Platform with vLLM
- Agentic AI for Personal Productivity: Building a Daily Minutes Assistant with RAG, MCP, and ReAct
- Agentic AI for Automated PII Detection with LangChain and Vertex AI
- Agentic AI for API Compatibility with LangChain and LangGraph
- AI Writes Code, You Own the Design
- Building a Distributed Orchestration and Graph Processing System (Formicary)
- RADAR: Automating Low-Risk Code Review at Meta
- From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI
- What I’m Hearing About Cognitive Debt (So Far)
- Software Factories in September 2026
- Adaptive Data Flywheel: Applying MAPE Control Loops to AI Agents
- Agent Learning Flywheel: How AI Agents Improve
- A practical guide to risk-based code review
- 3,100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse
- Minions: Stripe’s one-shot, end-to-end coding agents
- Running a Software Factory Efficiently at Uber Scale
- Spotify’s Background Coding Agent, Part
- Assess Risk with Blast Radius
