LangChain has been the default since 2022. Large ecosystem, integrations for most models and vector stores, active community. If something exists in the LLM space, there is probably a LangChain wrapper for it. That breadth comes with accumulated abstractions — LCEL, LangGraph, chains — and you spend time learning which layer applies before you get to the actual problem.

Strands is AWS’s agent SDK, open-sourced in 2025. The model is simpler: tools are Python functions decorated with @tool, you point it at a Bedrock model, and the runtime handles the loop. No graph definitions. No chain configuration. A working agent is around twenty lines.

The rubric surfaces two clear splits.

Setup speed, agent-first design, and AWS fit all go to Strands. The surface area is small by design. Bedrock is the intended path and it works well if you’re already there.

Model flexibility and ecosystem go to LangChain. Dozens of providers, connectors for most databases and retrieval systems, and LangSmith for tracing. If your stack isn’t AWS or you need integrations Strands doesn’t have, LangChain is the safer choice.

Production simplicity is close. Strands wins on fewer moving parts. LangChain’s observability tooling is better, but it adds setup.

The decision reduces to two questions. Are you AWS-native? Do you need integrations Strands doesn’t cover?

If neither applies, start with Strands. You can always migrate out when you hit the ceiling.

Most teams already know these exist. The issue is remembering to run them.

A pre-commit hook fires on git commit, before anything is recorded. Failed check, commit stops. Style problems surface in your working directory rather than CI.

Drop this into .git/hooks/pre-commit:

#!/bin/sh
set -e
uv run ruff check . --fix
uv run ruff format .
uv run pyright

set -e exits on the first failure. --fix lets ruff correct what it can automatically. Make it executable:

chmod +x .git/hooks/pre-commit

For shared repos, version-control the hooks using pre-commit and a .pre-commit-config.yaml. Then everyone runs the same checks on every commit without a manual setup step.

repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.9.0
    hooks:
      - id: ruff
        args: [--fix]
      - id: ruff-format
  - repo: https://github.com/RobertCraigie/pyright-python
    rev: v1.1.390
    hooks:
      - id: pyright

Run pre-commit install once per clone.

The checks run when the commit runs. You stop scheduling them.

Code review, test coverage, staging environments, deployment approvals. These are trust infrastructure. They encode what your organisation learned from past failures.

Agent-generated code doesn’t change that question. It increases the volume and velocity at which it needs answering.

A team generating code 10x faster through an agent still needs to validate it. If your review process was already shallow — two-minute glances, no checklist, tests written after the fact — you haven’t changed the process. You’ve increased the throughput of it.

Consider a team with inconsistent test coverage and informal review norms. They adopt an agent-assisted workflow. Output doubles within a sprint. Review latency spikes. Reviewers feel the pressure to keep up. A two-second glance and a merge becomes the default. Within two months, defect rates climb and the blame lands on the AI.

The AI didn’t introduce the dysfunction but it dud scaled it.

Teams that adapt well tend to share one characteristic: deliberate validation design before adoption. Structured review checklists. Defined defect classes. Clear ownership of what automated testing covers and what it does not.

They also expect a J-curve. Early adoption slows throughput before it speeds it up. That dip is where trust infrastructure gets stress-tested.

The practical move is to audit your current pipeline before expanding agent usage. Identify where review is weakest. Fix that first. Then scale.

The sequence matters.

The same shift is happening with agentic code generation. And most delivery systems haven’t adjusted.

Dave Farley recently explained the Nyquist-Shannon Sampling Theorem in the context of software delivery¹. To reliably detect change, you must sample at twice the frequency of the change itself. If AI increases code output volume, and humans remain the primary sampling layer, review doesn’t scale. The human becomes the bottleneck by design.

The METR study² found developers using AI tools were 19% slower on average. The code changed. The delivery system didn’t. That mismatch is where the cost accumulates.

So where does validation move?

Three places. Contracts define expected behaviour before anything is written. External test coverage confirms the implementation meets those contracts. Runtime monitoring catches what slips through both. Together, they replace the pull request as the primary quality gate.

Teams on the frontier are already redesigning around this. They’re not reviewing every line of generated code. They’re investing in interface definitions, automated coverage thresholds, and production observability. The checkpoint moved.

If your team’s primary validation mechanism is still a pull request review, that process was built for a world where implementation speed was the constraint. It probably isn’t anymore.

Audit where your validation actually sits. That’s where to start.

That process was solving a real problem. The problem is changing.

When implementation becomes agentic, you stop managing variance between ten engineers. You’re managing a system that produces consistent output at volume, with failure modes that look nothing like what Jira was designed to track.

The compiler analogy holds here. Nobody reviews compiled bytecode in a pull request. You validate the source, trust the compiler, and monitor runtime behavior. Specification in. Behavior out. You test the contract, not the intermediate steps. Agentic code delivery is heading toward the same model.

Teams already operating near this boundary aren’t running two-week sprints. They’re investing in three things: prompt discipline (what goes in), evaluation frameworks (how correct output is defined), and observability (what happens at runtime). The constraint has moved from writing code to specifying behavior and catching drift when it occurs.

The Scrum Master role was an answer to a specific organisational problem. That problem is dissolving. New ones are forming around specification quality, automated validation, and governance of systems you didn’t write line by line.

Audit your ceremonies against the risks they were built to manage. Some of them no longer apply.