AI coding agents make architecture-shaped changes faster than teams can notice. Treat their ADR drafts as diagnostic mirrors first, then keep only the decisions a human is willing to own and route back into future work.
Stop playing tennis with bad AI PRs. The only correction that scales is the one a reviewer never has to make twice. Everything else just moves the work around.
The biggest risk in AI adoption isn’t moving too slowly. It’s mandating too hard, watching it backfire, and oscillating between full commitment and full retreat. The organizations that found their footing got better at paying attention, not better at writing policy.
AI tools are flooding PR queues and the instinct everywhere is to call review the bottleneck. I think that’s the wrong question. The reviewer is the last sync point before production changes. The goal shouldn’t be how to remove the gate, but how to make it cheaper to operate.
An agent reviewed a Go PR and confidently said ‘skip.’ Six words from a human triggered the re-analysis that found a 10% optimization it had missed. That failure mode of pattern-matching on the wrong things shows up consistently across 200+ sessions.
When AI is let loose on porting a large complicated rule-matching library from Go to Rust; you find some contractors across hundreds of sessions, and a few hard lessons.
Every high-stakes industry independently invented the same communication protocol. They work because they serialize intent into a shape that fits working memory. But none of them describe what wrong looks like — they didn’t need to, the human receiver would ask. Agents don’t.
Simon Willison ships most of his code from his phone via agents. Same here—twelve PRs on a Rust automaton engine this week through Claude Code. CI scaffolding is what earns the confidence to merge, and the investment compounds faster than expected.
Porting Tim Bray’s quamina from Go, most things translated cleanly. Then I hit cyclic state machines, and a benchmark smell led somewhere unexpected.
A production-ready Rust port of quamina that’s 1.7x faster than Go and 2.1x faster than Java. 369 tests, formal verification with Kani, and memory safety validation with Miri.
Using AI coding assistants feels productive until you’re spending more time reviewing generated code than you saved writing it. That’s the verification tax, and it explains why teams succeed with narrow use cases but struggle to scale AI adoption.
Comprehensive UIs meant to give operators full visibility often create the cognitive load that degrades their decision-making. Automation that narrows what humans need to evaluate beats automation that tries to show everything.
SQLite maintains 590 times more test code than production code. That extreme ratio enables a 3-person team to maintain billions of deployments while making fearless changes. Understanding when that trade-off pays off reveals the economics of software quality.
Scheduling everything forces confrontation with finite capacity. The real constraint is organizational: the expectation that you can be both deeply focused and constantly interruptible.
When leadership says ‘do more with less,’ they usually mean find higher-leverage work. Teams often hear ‘work harder or parallelize everything,’ which misses the point entirely.
When Frank Drake’s colleagues couldn’t decode his own message to aliens, it revealed a universal problem that compression requires a shared decompression algorithm. You can’t verify your encoding works until someone without your context tries to decompress it.
When agents handle implementation, experienced engineers shift from typing code to architectural guidance. The division is about what gets delegated and what requires human judgment.
Moving fast doesn’t mean finishing projects quickly. It means iterating fast enough to avoid wasting time on components that don’t matter. Faster mistakes mean faster learning, and slow execution locks you into obsolete approaches.
The explosion of AI-generated pull requests is less of a capacity problem and more a specification problem. Small-task constraints improve automation accuracy across every domain, from LLMs to robotics to continuous integration. Constraint is a necessary design tool.
Ten posts diagnosed why review bottlenecks under AI. This one is about what you can actually do Monday with your constraints, your role, and your actual power level.
AI review tools show 73.8% acceptance rates but add 2h 28m to PR closure time. Teams adopt them hoping to solve the bottleneck, configure them to gather accuracy data, then never redesign the workflow. The question isn’t whether the tools work but whether you’re stuck running testing configuration in production.
Stacked PRs promise to unblock authors and parallelize reviews. But the coordination overhead is real, and whether stacking helps or hurts depends on stack depth, tooling, and how fast your PRs already merge.
Batching is more than a productivity hack. It’s an architectural decision that works under specific conditions. Research on email batching shows when scheduled review blocks succeed versus when they break down.
AI changes what breaks, not just how much breaks. Research shows nearly half of AI-generated code has security flaws, but they’re different flaws than human code produces. Here’s what to look for.
While continuous integration does catch bugs, and it’s more impactful by fundamentally changing who is responsible for what aspects of code quality. When automation becomes reliable enough to trust, it creates an implicit agreement about what reviewers should focus on. But when it fails, that social contract breaks down.
Fast code review response seems to conflict with thorough review. But research from Meta, Google, and others suggests response time and review quality aren’t actually trade-offs. They’re measuring different things. The tension only appears when PRs exceed cognitive capacity.
Part of your attention stays on the previous task. For code review, this creates an impossible choice: batch reviews to protect focus, or respond quickly to unblock developers?
Code review effectiveness falls off a cliff instead of gradually. Research says at 450 lines per hour, 87% of reviews miss defects. The threshold feels more biological than cultural or process-related because working memory holds about four chunks, and you can’t review past your cognitive capacity.
A 1961 queuing theorem predicts the bottleneck we’re seeing: AI doubles code arrival rate while review capacity stays fixed. But the math is worse than it looks. AI code is also harder to review.
Assigning PRs to a team feels collaborative, but it triggers diffusion of responsibility. Research shows individual assignment cuts review time and the same psychological principle that explains why bystanders freeze in emergencies.
The same discipline ops teams learned about gradual automation applies to AI agent integration. Do-nothing scripts and incremental agent collaboration share the same core pattern: decomposition, verification, and incremental replacement.
GitHub’s spec-driven development pattern treats specifications as executable source code that AI compiles into implementation. When the spec is the source of truth, you solve vibe coding and documentation drift simultaneously.
Multiple signals suggest a development paradigm shift: code deletion as progress, throwaway work as strategy, tools as artifacts. Unclear if this transfers beyond AI companies building AI tools, but the patterns enable genuinely more agile practices.
AI-driven optimization needs reliable verifiers, which means testing becomes the most important thing. But the harder problem is choosing what to verify in the first place.
The efficiency-thoroughness trade-off explains why ‘carefully review AI output’ is useless advice. Infrastructure beats admonitions, but the trade-off never goes away.
Shopify’s production agent system hit the same problem we’ve seen with config files and god objects-monolithic prompts become unmaintainable. Just-in-Time instructions treat context as a modular system, not a pile of special cases.
Teams iterate on prompts by changing everything and hoping it’s better. No isolation, no clear signal. Same mistake we made debugging code before we learned to use debuggers.
Just like we learned to compress search queries from sentences to operators, AI tool usage shows the same fluency curve. Watch for command compression as a signal of real adoption.
Developers who break tasks into sub-tasks and work iteratively with agents succeed at 83% vs 38% for one-shot prompts. The pattern mirrors microservices decomposition, but for cognitive work instead of code.
AI doesn’t fix broken processes-it amplifies them. Without standardized workflows and strong operational foundations, organizations risk embedding inefficiencies deeper into their operations at scale.
How the IETF’s approach to technical consensus could transform how engineering teams make decisions, especially in async environments where traditional voting falls apart.
Current AI agent discussion focuses on replacing humans, but the real value is treating agents like microservices - small, focused, with clear boundaries. Conway’s Law applies just as much to agent architectures as it does to traditional systems.
Progressive rollouts feel safer, but fine-grained rollouts can actually make incidents harder to detect and diagnose, turning safety practices into safety theater.
The obsession with AI productivity gains obscures what actually makes engineering effective. Instead of measuring ‘more/faster,’ we should focus on better decisions and fewer technical objections.
AI coding tools respond to the quality of your input. If you can’t explain what you want in plain English, you probably don’t understand the problem well enough to solve it.