Not a feed #

Think of it as RSS for agents,* except that instead of telling you what's new, it tells you what a page says. RSS is a subscription. It tells a reader what changed. The copy does not replace the feed. A browser's reader mode guesses which part of a page is the content. The publisher states it, instead of the browser guessing.

The web was built for people sitting in front of a browser, and nearly everything about a modern page assumes one: the nav bar, the sticky header, the related-posts rail, the analytics scripts. A growing share of the readers on those pages are now software acting for someone. An assistant summarizing a page, a coding agent checking a reference before it writes a call, a research tool pulling twenty articles into one answer. Those agents receive the same page a person does, pay for all of it in tokens, and then guess which part was the article. Sometimes the guess is right. Often it keeps the footer and drops the code sample.

Altdown, short for Alternate Markdown, is small on purpose. A site publishes a Markdown copy of each page's main content as a plain file next to the page, and the page announces that copy with one line in its <head>. There is no server logic, no proxy, and no custom HTTP header.

This site does that. The New SDLC announces its copy like this:

<link rel="alternate" type="text/markdown" href="/posts/new-sdlc.md">

The copy is at https://www.vivekchopra.com/posts/new-sdlc.md. Its metadata, without the description and generator lines, looks like this:

---
altdown: 1
canonical: https://www.vivekchopra.com/posts/new-sdlc
title: The New SDLC
published: 2026-04-26T00:00:00Z
updated: 2026-04-26T00:00:00Z
lang: en
author: Vivek Chopra
signals: search=yes, ai-input=yes, ai-train=no
---

The link element is the same pattern RSS autodiscovery has used for twenty years. That is the part worth borrowing. The job is not. A site should have both. This one does: the feed and the copies.

What an agent gets #

An agent that follows the link reads the content and nothing else. The publisher decides what the main content is, because the publisher knows. The copies on this site leave out the header, the footer, and the related posts. The home page's copy, https://www.vivekchopra.com/index.md, is the introduction and the list of posts.

A site can also publish an index of every copy, with a last-modified time on each, announced from robots.txt. An agent that wants the whole site reads the index, fetches the copies, and on its next visit stops when it reaches a date it has already seen. The same way a feed reader syncs a feed. On this site the line sits next to the sitemaps:

Sitemap: https://www.vivekchopra.com/sitemap.xml
Sitemap: https://www.vivekchopra.com/feed.xml
Altdown: https://www.vivekchopra.com/altdown.json

The index is https://www.vivekchopra.com/altdown.json. It lists the copies. It does not contain them.

The copy may contain only text a person can see on the page. A publisher cannot add keywords, hidden text, or instructions addressed to software, and cannot leave out part of the main content. The one exception is an optional description, capped at 300 characters, which an agent must treat as a hint. The page and the copy also point at each other: the link names the copy, the copy's canonical names the page, and both live on the same origin. If that check fails, the agent reads the HTML. A site that adopts Altdown badly loses nothing it had before.

search, ai-input, and ai-train reuse Cloudflare's content signal names. A missing signal means unspecified, so publishing a copy never implies consent to training. Altdown does not decide who may fetch a site. That is still robots.txt. It does not let an agent act on a site. It also differs from llms.txt, a description of the site at a fixed path that nothing checks against the pages. Altdown is a copy of each page, announced by the page and checkable against it. The two can coexist.

Status #

This is version 1.0 in draft. The full specification is at altdown.org/spec, or as Markdown. altdown.org publishes every page in the format it describes. I would like to hear from publishers who try it on a real site, and from people building agents that read the web. Open an issue with what breaks.

The same discipline as in the days before AI coding tools applies: define clear product requirements and acceptance criteria, think through the technical design, write down the architecture, break the work into smaller tasks, and implement incrementally with checks and reviews. This post covers that approach: four documents for the architecture, one ADR, a plan, and the tasks, used to steer the coding agent.

The four documents #

Each document has a singular purpose:

The architecture document describes what exists today. Not where the system is headed. Not what was considered and rejected. The moment it mixes current state with future plans, it stops being a reference. Keep the diagram as text (PlantUML or Mermaid) so it lives in git and an agent can update it in the same commit as the code.

An ADR records one decision. The context states the constraints. The decision is one sentence. For example: "We will inject sleep and now into the client." Every serious alternative appears, including the obvious shortcut, with the reason it loses. Consequences include the cost. A Confirmation section lists checks a later reviewer or agent can run. Not every change needs an ADR. Write one when a change alters a contract, a service boundary, a lifecycle, or an owner, or when it locks in something hard to reverse. Bug fixes do not qualify.

The plan describes the work and its boundaries. The boundaries matter as much as the stack. A plan that only lists what to build accumulates scope as the agent reads it, because "why not add auth while I'm here" is a natural inference for a model. Writing down what is out of scope closes that door.

A task is verifiable or it is not a task. "Improve API handling" is a mood. This is a task:

- [ ] T021 Parse rel="next" from the GitHub Link header — src/rate_limited_cli/pagination.py — verify: uv run pytest tests/test_pagination.py

You can read that checklist after the agent runs and know whether the work happened without opening a single source file. Add Do not … tasks where the work could drift past an ADR, and make the verify step the ADR's own Confirmation check. The rule is then enforced by a test rather than by memory.

Acceptance criteria round out the set. Define "done" before the agent starts: a 404 prints "user not found," not a traceback; three mocked pages produce exactly three requests; tests pass with no network. The agent then checks against a list you wrote while you were thinking clearly, not one it invents while trying to make tests green.

Where everything lives #

The layout separates the permanent record from the per-feature working set. Permanent documents sit at the top of docs/. Everything tied to one feature sits in one folder named after that feature.

.
├── AGENTS.md                      # the one file every agent reads first
├── CLAUDE.md                      # one line: "Read AGENTS.md"
├── .cursor/rules/                 # Cursor rules, scoped by glob
├── .claude/commands/plan.md       # /plan: turn an accepted ADR into a plan and tasks
├── .github/PULL_REQUEST_TEMPLATE.md
├── docs/
│   ├── ARCHITECTURE.md            # the system as it exists today
│   ├── adr/
│   │   ├── README.md              # index, status legend, when an ADR is required
│   │   └── 2026-10-30-split-github-client-into-collaborators.md
│   ├── features/
│   │   ├── v1-repos-command/      # PLAN.md, TASKS.md, ACCEPTANCE.md, PROMPTS.md
│   │   └── resilient-github-client/
│   └── templates/                 # ADR, PLAN, TASKS, ACCEPTANCE, PROMPTS sources
├── src/
└── tests/

Three choices in that tree are deliberate.

ADRs use a date-slug filename, not a sequence number. 2026-10-30-split-github-client-into-collaborators.md is the ADR's ID. Two engineers on two branches can each add an ADR without a merge conflict over who gets 0007. The filename sorts chronologically and reads as a sentence in a PR title.

Each feature owns one folder. docs/features/<slug>/ holds the plan, the task list, the acceptance criteria, and the bounded prompts for that feature. When the branch merges, the folder stays as a record of how the change happened. Nobody reads it by default, and that is fine. The plan links to its ADRs; the ADRs never link back to a plan, because an ADR outlives any one plan.

The architecture doc is singular and lives at the top. There is one current system, so there is one description of it. Every feature branch that moves a boundary updates it in the same PR, and the PR template asks for that update by name.

The product spec sits outside the repo, in whatever tracker the team uses. The ADR and plan link to it. Scope, deferred items, and the success measure are copied from the spec into the plan, never inferred.

From decision to merge #

flowchart LR
    A[Spec in the tracker] --> B[ADR opened: Proposed]
    B --> C[Reviewed in a PR]
    C --> D{{Status: Accepted}}
    D --> E["/plan: plan and tasks"]
    E --> F[One phase per prompt]
    F --> G[Review the diff]
    G -->|next phase| F
    G --> H[Merge, with ARCHITECTURE.md updated]

The decision is reviewed before any code exists. The code is reviewed one phase at a time.

1. The spec names the problem, the v1 scope, the deferred list, and one success measure. It lives in the tracker, not the repo.
2. The engineer opens a PR that adds one ADR with Status: Proposed. The PR contains no code.
3. A reviewer accepts or rejects from the file alone. On rejection the reason goes under Decision and the status becomes Rejected. The file stays as a record.
4. On agreement the status becomes Accepted. Open questions must be empty first.
5. /plan docs/adr/<id>.md reads the accepted ADR and the spec, inspects the anchors in the code, and drafts the plan and the tasks. It reports gaps instead of filling them. A gap reported is useful. A gap filled with a guess is an unreviewed architectural decision.
6. Each prompt names one phase: which tasks to implement, what not to implement, which tests to run, and where to stop. Phase 0 is foundation and blocks the rest. Each later phase is one user-visible slice with its own independent check.
7. You review the diff at the phase boundary. A diff that spans five decisions is a diff whose reasoning you have lost.
8. The PR that merges the feature also updates ARCHITECTURE.md. The PR template asks for it.

The gate is step 4. Nothing downstream begins until a human has accepted the decision in writing.

A worked example: rate-limited-cli #

To make this concrete, the template repo builds a small Python CLI twice. The first pass is v1. The second is a feature branch that adds the parts v1 deliberately left out.

rate-limited-cli repos octocat

The command fetches every public repository for a GitHub user, follows pagination, and prints a summary: repo count, stars, forks, and remaining API quota. GitHub is a good sample API because its edge cases are real. Unauthenticated requests are capped at 60 an hour. Rate limit state arrives in x-ratelimit-* headers. List endpoints paginate through a Link header, and GitHub tells you to follow rel="next" rather than increment a page number yourself.

v1 needs no ADR. It is the first version of a small tool, and nothing in it is hard to reverse. It needs a plan, a task list, and acceptance criteria. The plan fixes the stack (Python 3.12, uv, Typer, httpx, pytest with respx, Ruff) and the surface (repos USER --limit --json). It also says what v1 excludes: no authentication, no retry engine, no persistent cache. The client does the minimum correctly. It follows Link: rel="next" until the link disappears and stops early when --limit is reached.

The second pass is where ADRs earn their keep. The feature branch adds token authentication, rate-limit handling, retry with backoff, ETag caching, and clearer diagnostics. The design question has changed. It is no longer "how do I call GitHub." It is how five concerns interact without turning GitHubClient into one large method that does all of them badly. That is a hard-to-reverse decision, so it gets an ADR.

The ADR records the priority order for rate limits. If Retry-After is present, honor it. If the primary limit is exhausted, wait until reset, but only up to a bound. Otherwise treat it as a secondary limit and back off exponentially. It records the split of GitHubClient into four collaborators: AuthConfig, RateLimitPolicy, RetryPolicy, and CacheStore. And it records what lost. Inlining everything in the client is untestable. Always sleeping until reset means a CLI hangs for 40 minutes because that is when the quota resets. A --token flag puts a secret in shell history, so GITHUB_TOKEN from the environment wins. A plugin framework is not needed, so it is not built.

One detail from the ADR is worth keeping concrete, because it decides whether retry code is testable or miserable. Do not call time.sleep and time.time directly. Inject them.

class GitHubClient:
    def __init__(self, *, sleep=time.sleep, now=time.time):
        ...

A test passes sleep=delays.append and a fixed now, then asserts delays == [5] after a mocked 429 with Retry-After: 5. The suite never waits five seconds. The ADR's Confirmation section turns this into a check an agent can run: grep the client for time.sleep( and expect zero matches. A Do not … task in TASKS.md carries that same check as its verify step.

ARCHITECTURE.md changes in the same branch. The diagram that showed CLI -> GitHubClient -> GitHub now shows the four collaborators. The ADR says why the split happened. The architecture doc says what the system looks like now. If the same sentence appears in both, one of them is redundant, and it is usually the architecture doc trying to be a decision log.

Wiring the agent to the documents #

The documents only help if the agent reads them. Every tool has its own instruction file, and the fastest way to drift is to maintain four copies of the same rules. Keep one source and point everything else at it.

Three rules keep the instruction files useful.

Tell the agent what to read, in order. AGENTS.md lists docs/ARCHITECTURE.md, then the ADRs the current branch cites, then the feature folder. An agent that reads the plan before the architecture doc will propose a plan for a system that does not exist.

Tell the agent when to stop. Every bounded prompt ends with "Update only completed task checkboxes. Stop." The /plan command stops if the ADR is not Accepted, if the spec cannot be opened, or if a plan file already exists. A procedure without a stop condition becomes a procedure that runs until something breaks.

Treat TASKS.md as the agent's memory. Agents lose context between sessions. A task list with checkboxes and verify commands lets the next session pick up one unfinished task, run its verify step, and mark it done. That is the same pattern Anthropic describes for long-running agents: an initializer turns the request into a feature list and a progress file, and each later session works one item and leaves the file updated for the next.

What survives the merge #

The plan and the task list are useful while the branch is open and mostly useless six months later. Nobody reviewing the code in a year needs docs/features/resilient-github-client/TASKS.md to understand why caching works the way it does. They need the README, the current ARCHITECTURE.md, and the ADR. The feature folder stays in the repo as a record of how the change happened. It is not the primary documentation.

This is not about producing more documentation. It is about making the design decisions before the agent makes them for you by default. Writing the ADR first is slower than typing "add retry logic with backoff" into a prompt. It is also the difference between reviewing a plan you agree with and reverse-engineering a decision from a diff.

The template repo, with the ADR and plan templates, the /plan command, the agent instruction files, and both passes of the sample CLI, is vivekchopra/rate-limited-cli. Clone it, delete the sample feature, and keep the structure.

References #

Decision records

• Michael Nygard, Documenting Architecture Decisions (2011). The original ADR post: context, decision, status, consequences.
• MADR: Markdown Architectural Decision Records. The template this ADR shape most resembles, including decision drivers, considered options, and a Confirmation section.

Spec, plan, and tasks

• GitHub Spec Kit. Constitution, spec, plan, tasks, implement. Source of the T001 numbering, [P] parallel markers, phased tasks, and a cross-artifact consistency check before implementation.
• Spec Kit issue #1934. Proposes explicit (depends on T001) suffixes, because [P] alone does not tell an agent which tasks are safe to run together.
• AWS Kiro: Specs. Requirements, design, and tasks files. Each task lists the requirement IDs it covers, and independent tasks run in dependency-ordered waves.

Agents working across sessions

• Anthropic, Effective harnesses for long-running agents. An initializer turns the request into a feature list, a progress file, and git history; each later session picks one unfinished feature, verifies it, then marks it done.
• Anthropic, Claude Code: Best practices for agentic coding. Plan before coding, and keep a checklist in a file for multi-step work.
• AGENTS.md. The open convention for a single agent instruction file that Codex, Cursor, and others read.

Sample project

• vivekchopra/rate-limited-cli. The sample CLI and the docs that shaped it.
• GitHub REST API: Using pagination and Rate limits. The upstream behavior the sample client is built against.

The upside is obvious: higher velocity. As an engineering manager, how do you mitigate the downside? Will an AI-generated change break production? Worse: will it pass every unit test, integration test, and CI check you have and still introduce a bug that surfaces weeks later? And what happens to the architecture itself as the rate of code change climbs and the half-life of design assumptions shrinks?

I increasingly see AI-generated code fail in ways that differ from human-authored code: confident calls to APIs that do not exist, change sets much larger than a human would typically author for the same task, and tests that pass because they encode the same incorrect assumptions as the implementation itself. I have been working through a layered model of guardrails to mitigate some of these issues:

1. Scope and authority: what the AI is allowed to touch.
2. Structural: what the code must look like before it reaches review.
3. Behavioral: what the code must prove it actually does.
4. Human verification: what a person must check before merge.

(My deeper concern though is architectural drift: AI systems are good at producing locally reasonable changes, but they do not naturally preserve long-term consistency across an entire system. Over time, this creates what I think of as “architecture slop”: a codebase where each individual change makes sense in isolation while the overall structure gradually loses coherence. More on that in a follow-up post!)

Layer 1: Scope and authority #

Define as engineering policy what AI can do without escalation, what requires review, and what should be largely human-authored.

• Green zones: This is where AI can generate code freely. POCs/prototypes, Internal tooling, test scaffolding, documentation, greenfield features behind a feature flag, build scripts, log parsers, one-off data migrations.
• Yellow zones: AI can suggest, but a human authors the final commit. User-facing flows, database schemas, public APIs, anything that crosses a service boundary.
• Red zones: AI can draft or assist with review, but never authors the final commit, and a senior reviewer signs off in addition. Terraform scripts, Authentication and session handling, payment processing, anything that touches PII or regulated data, security-sensitive code paths, cryptographic primitives.

A concrete example: SQL migrations. An AI agent can be good at drafting them, but they belong in a yellow zone, which means the agent can draft the migration but a human has to read it, run it locally, and sign off before it runs against staging. The agent does most of the rote work, and the human catches the one in twenty cases where the migration would have locked a high-traffic table during business hours or dropped an index that some downstream report was depending on. Putting migrations fully into the green zone would make those rare failures much more dangerous.

Across all three zones, the engineer who merges the change owns it, whether or not an AI wrote it.

The other dimension worth defining is the scope of any single change. Adding a new endpoint that lives in its own module is a bounded change with a contained blast radius. Refactoring the request pipeline across twenty files is not. The first is fine for AI to handle; the second is exactly where AI tends to make confident, sweeping mistakes that take hours to unpick.

As an example, engineering policies could limit AI-generated code to one new module per PR, and require authors to write a summary in their own words for any PR that crosses module boundaries or changes more than 300 lines.

Layer 2: Structural guardrails #

These are automated checks that run before a human ever reviews the code, and they catch the bad habits AI-generated code tends to exhibit.

Dependency policy checks #

AI-based coding tools are enthusiastic about pulling in libraries. They often import something that solves a problem you already have a solution for, or pick an abandoned package that has not seen a commit in years. A written justification for any new dependency, even one or two lines in the PR description, makes someone stop and ask whether the dependency is actually needed. Every new dependency should be a deliberate choice and not just an autocomplete.

Hallucinated API checks #

These checks matter most in dynamically typed languages, where calls to non-existent methods only surface when the code actually runs. An undefined-symbol linter (pyflakes, ESLint's no-undef) catches the easy cases: importing a module that does not exist, or calling a function that is not defined in the codebase or its dependencies. A type checker in strict mode (mypy, pyright, the TypeScript compiler) catches the harder ones, including invented methods on real objects (user.getDisplayName() when the real method is user.displayName) and return values used as if they could not be None.

Take the last case as a worked example. The AI generates:

def get_user_email(user_id: str) -> str:
    user = db.users.find_one({"id": user_id})
    return user.email

mypy or pyright in strict mode rejects this immediately: find_one returns Optional[User], not User, so user.email will throw on the unhappy path. A human reviewer would probably miss it on first read because the code looks reasonable. A type checker catches it on every run, and most editors flag it in real time as the engineer types.

Layer 3: Behavioral guardrails #

The traditional testing pyramid puts unit tests at the wide base, integration tests in the middle, and end-to-end tests at the narrow top. It emphasized unit tests because they are fast, relatively stable, and cheap to run repeatedly. End-to-end tests, by contrast, have historically been slower, more brittle, and more expensive to maintain.

AI systems are extremely good at generating unit tests that appear thorough while proving very little, because the tests often encode the same assumptions and blind spots as the implementation they are validating.

Large agent-coded refactors can pass full unit-test suites and pre-merge checks and still break critical end-to-end behavior. Unit tests will still have a role, but the key guardrail needs to shift to end-to-end and behavioral tests.

I see two major shifts happening in how we test.

The first is around test scope. There is a class of bugs in AI-generated systems that will routinely escape unit-test guardrails. For example, an endpoint may call the correct helpers, but in the wrong order. Every unit test against those helpers will still pass because each helper behaves correctly in isolation. An end-to-end test is often the only thing that catches that the system as a whole no longer behaves the way users expect. For every user-facing workflow that matters, there should be at least one end-to-end test that exercises the full stack.

Historically, end-to-end tests were avoided because they were slower, flakier, and more expensive to maintain. That tradeoff is beginning to shift now that AI systems themselves can generate and maintain large portions of the test suite.

The second shift applies across every level of testing. Tests should validate what the system does, not how the implementation happens to be organized internally. A behavioral test passes when the system produces the correct output for a given input. A structure-coupled test passes only when the internals follow a particular shape: a specific field was mutated, a helper was called, or a sequence of operations occurred in a specific order.

Consider a function that calculates shipping cost. Both tests below are unit tests; the difference is in what they assert.

def calculate_shipping(order: Order) -> Decimal:
    weight = sum(item.weight for item in order.items)
    zone = lookup_zone(order.destination)
    base = WEIGHT_TABLE[zone][weight_bucket(weight)]
    return base + tax_for(order.destination, base)

A structure-coupled test might look like this:

def test_calculate_shipping_calls_dependencies():
    mock_zone = patch("shipping.lookup_zone", return_value="ZONE_A")
    mock_tax = patch("shipping.tax_for", return_value=Decimal("1.50"))
    with mock_zone, mock_tax:
        result = calculate_shipping(sample_order)
    assert mock_zone.called
    assert mock_tax.called_with("US-CA", Decimal("10.00"))

This test passes only when the internals are arranged a specific way. The moment you regenerate the function and the AI inlines lookup_zone or combines the tax calculation into the base lookup, the test breaks even though the code is still correct. The test is punishing you for refactoring.

A behavioral test for the same function:

def test_calculate_shipping_returns_correct_total():
    order = Order(
        items=[Item(weight=Decimal("2.5"))],
        destination="US-CA",
    )
    assert calculate_shipping(order) == Decimal("12.47")

This passes whenever the function produces the right answer, regardless of how it gets there. The implementation can be regenerated repeatedly, and as long as the behavior remains correct, the test continues to pass.

Structure-coupling matters more under AI-generated code than it did under human-authored code because of a higher rate of implementation churn. A human refactoring a module often has a mental model of how that code should be organized and code tends to preserve that shape over time. An AI regenerating the module will happily restructure things in ways that are functionally equivalent but structurally very different. Tests coupled to structure become noisy with every code regeneration, and will end up being ignored.

What about unit tests? #

This does not mean unit testing should be abandoned. End-to-end tests do not tell you where the breaking change is, and the combinatorial logic paths in your code cannot all be exercised by end-to-end tests alone.

You need to understand which unit tests should be kept. A useful heuristic: if you regenerated this code tomorrow, would the test still make sense? If yes, keep it. If it would break just because the internal implementation shifted, then rewrite it against the public interface or delete it.

Practical behavioral test guardrails #

• Require integration tests for new public interfaces. Every new endpoint, queue handler, or exported function gets at least one test that calls it the way a real caller would. One happy path and one realistic failure case are usually enough to catch the things mocks let through.
• Use property-based tests for combinatorial logic. Tools like Hypothesis in Python or fast-check in JavaScript generate inputs the AI did not think of, which is precisely the failure mode AI-generated code is prone to: empty inputs, unicode strings, negative numbers, off-by-one boundaries at the limits of an integer range.
• Require additional human review whenever AI-generated changes modify both implementation and behavioral expectations test simultaneously. One common failure mode is an AI system “fixing” a failing test by weakening the assertions rather than addressing the underlying issue.
• Measure coverage on the diff, not the whole codebase. Whole-codebase thresholds are easy to game: engineers add tests to easy code to keep the number up, and the hard code stays untested. Coverage on changed lines is honest. Setting the threshold at 80% on changed code routinely takes coverage of new code from the mid-40s to the high-70s within a quarter, with the only visible behavior change being that engineers stop shipping untested branches.

Layer 4: Human verification #

The last layer is what a human must do before code merges. Generic code review is not enough, because reviewers skim AI-generated code the same way they skim human code, and AI code is plausible-looking in ways that defeat skimming. The classic failure is the reviewer who approves with “LGTM” on a 400-line AI-generated diff.

How deep human review needs to go depends on the zone (Layer 1). In green zones, an AI code reviewer in CI is enough on its own; the volume of internal tooling and test scaffolding being generated does not justify pulling a human onto every PR, and the blast radius if something is wrong is small. In yellow zones, the AI reviewer clears the obvious issues but a human reviewer is required on top, with the three practices below. In red zones, the AI reviewer is advisory at best, never gating: a senior reviewer with explicit authority over the code path signs off in addition to the three practices, and for the most sensitive code (payments, auth, crypto, regulated data) a second human reviewer is worth the friction.

Three practices may help reviewers avoid skim mode on yellow- and red-zone AI-generated PRs (especially red zone!):

• Require the reviewer to write or modify at least one test as part of the review. This forces engagement with the behavior, not just the diff. If you cannot write a test for it, you do not understand it well enough to approve it. This sounds like overhead, and it is, but the time it costs is small compared to the time spent debugging things that were rubber-stamped.

• Require a written justification for any new dependency in the PR description before review starts. This is the same practice from Layer 2 but enforced by a human reviewer, and it catches cases the linter does not, such as a dependency added through a transitive upgrade rather than a direct import. The forcing function matters more than the prose itself; even one sentence is usually enough to prevent the fifth date library from landing in package.json.

• Require the PR author to write the diff explanation in the description without AI assistance, for any change above a certain size. An author who cannot do this has not read the code carefully enough to ship it. This is uncomfortable to enforce, but it forces the engineer to spend time understanding the change.

Planning for a shrinking architectural half-life #

Guardrails keep individual changes safe. They do not solve the longer-term problem, which is that all software architecture ages. Most codebases start showing their age around the two-year mark, when accumulated decisions and shifting business requirements begin to outgrow the architecture they were originally built around.

Several forces are compressing the effective lifespan of software architecture at the same time.

The first is sheer code volume. AI dramatically lowers the cost of producing code, which means systems accumulate complexity much faster than before.

The second is implementation churn. Decisions that teams previously deferred for months can now be regenerated in an afternoon. Each individual change may be locally reasonable, but over time the cumulative effect pushes the architecture in inconsistent directions.

The third is faster product cycles. AI lowers the cost of shipping software, which means competitors iterate faster, customer expectations shift faster, and requirements evolve more rapidly.

The fourth is what I think of as “local coherence with global drift”. Each individual change looks reasonable because the AI optimized it against the immediate context it was given. But no single mind consistently holds the broader architectural model in view, so consistency gradually erodes: patterns emerge that were never deliberately chosen, conventions drift, and abstractions appear that nobody consciously designed. Over time, the codebase begins to resemble a city where every block was designed independently, without a shared plan. That is what I would describe as “architecture slop”.

Taken together, these forces likely compress the traditional two- to three-year architectural refactor cycle significantly, especially in fast-moving products. Refactoring at a two-year mark may itself become too slow and too expensive to keep pace.

More on this in a follow-up post!

Closing thoughts and caveats #

Most of us are still figuring out what effective guardrails for AI-generated code actually look like. The ideas above are not a finished framework, but rather an exercise in thinking in public.

What is clear though is that we are dealing with far larger volumes of code, much higher rates of change, and failure modes that differ from traditional human-authored software. The next couple of years of engineering management are going to be about figuring out which practices need to change, and how.

That led to an interesting question in the comments: if the SDLC is changing this dramatically, what happens to Scrum?

My short answer on LinkedIn: probably not in the form most teams practice today. This post expands on that with a bit more reflection and some predictions.

What the original Agile Manifesto got right #

In 2001, seventeen software developers met at Snowbird, Utah and wrote a 68-word document that reshaped how we build software. The Agile Manifesto valued:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The important thing is that these were principles, not procedures.

I believe that the manifesto and the twelve principles behind these values still hold up: continuous delivery of valuable software, welcoming change, sustainable pace, technical excellence, self-organizing teams, and regular reflection. The core insight still holds: teams doing uncertain work need fast feedback loops.

Scrum is what got built on top #

Over twenty-five years, "agile" became Scrum, Scrum became ceremonies, ceremonies became calendar invites, and calendar invites became overhead. Most engineering teams today practice some version of Scrum: sprint planning, daily standups, sprint reviews, retrospectives, story point estimation, velocity tracking, burndown charts, backlog grooming.

The original manifesto warned about this in its first value, individuals and interactions over processes and tools. The warning did not survive contact with enterprise project management.

This is not a screed against Scrum, which I have been guilty of in the past. Scrum solved real problems. It was an implementation strategy optimized for the economics of software development in the early 2000s: expensive engineering capacity, slow feedback loops, difficult deployments, and limited visibility into work. It gave teams a regular cadence, made work visible, and created accountability without micromanagement. For a generation of engineering teams, it was a meaningful improvement over what came before. The question is whether the conditions that made Scrum useful still hold.

What Scrum was actually for #

Most of Scrum's machinery exists to manage handoffs and coordinate scarce engineering capacity.

• Sprint planning exists because humans cannot reliably predict how long work will take. Story points and planning poker were never really about precision. They were social tools for surfacing disagreement and forcing conversations about uncertainty.
• Standups exist because work is distributed across people who cannot see each other's progress. The ritual creates a forced synchronization point to surface blockers early.
• Sprint reviews exist because product, engineering, and stakeholders do not have a shared view of what is being built. The demo is the moment of truth.
• Retrospectives exist because teams need a structured space to examine their own process, away from the pressure of delivery.
• Backlog grooming and triage exist because issues enter the system in inconsistent shape and someone has to do the work of reading, refining, and routing them.
• Sprint metrics like velocity, burndown, and cycle time exist because leadership needs predictability and visibility into work that is otherwise opaque.

Each of these solved a real problem: coordinating between humans is expensive, and software organizations evolved processes to manage that cost.

What changes when agents enter the system #

AI tools change the underlying conditions:

• Mechanical implementation capacity is becoming dramatically less scarce. Translating requirements into working software increasingly takes hours instead of weeks. The bottleneck shifts from writing code to deciding what should exist, validating it, and safely operating it. The constraint is no longer "how do we maximize the throughput of our limited engineering team" but "how do we ensure what gets generated is correct, safe, and worth shipping."
• Estimation is becoming vestigial. When implementation collapses to hours, the question is no longer "how long will this take" but "is this worth doing" and "is the spec good enough to execute against." Story points are an answer to a question we are no longer asking.
• Handoffs are being absorbed into agents. Triage, grooming, routing, and even initial drafting can be done by agents that have access to customer feedback, internal context, and the codebase. Linear is already building for this with Intake and the broader vision they describe for issue tracking: support tickets, Slack threads, and customer call transcripts can be auto-converted into well-scoped issues, deduplicated, routed, and labeled. It does not eliminate product thinking or engineering judgment, just the procedural translation work. The triage meeting becomes optional.
• Coordination overhead changes shape. Teams still need architectural alignment, operational ownership, security review, and prioritization. What shrinks is the amount of procedural synchronization required just to keep implementation moving.
• Sprint cadence is increasingly arbitrary. Two-week sprints made sense when shipping was hard. When deployment is continuous and validation is automated, the sprint boundary increasingly becomes a calendar artifact rather than a delivery constraint.

The original manifesto is not wrong, but the rituals that grew on top of it were optimized for a constraint that is dissolving.

A new manifesto? #

If we wrote the Agile Manifesto today, knowing what we know about AI-assisted development, the values would not change much. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.

The manifesto ages surprisingly well, but the Scrum workflows built around it do not:

• Specs and intent over tickets and stories. When code can be generated in minutes, the scarce thing is the precise description of what to build. Engineering judgment moves from implementation to specification.
• Continuous flow over sprint cadence. When work moves at the speed of agent throughput and validation is continuous, fixed sprints become less meaningful as the primary unit of planning and delivery. The discipline shifts from "what fits in this sprint" to "what is worth doing now and what does done look like."
• Validation and safety over raw throughput. As implementation accelerates, the bottleneck increasingly shifts to testing, review, security, observability, and release confidence. The challenge is no longer generating code quickly, but ensuring what gets generated is correct, safe, maintainable, and production-ready.
• Outcomes over velocity. Velocity measures how much a team produces, which made sense when production was the bottleneck. The new bottleneck is whether what gets produced is correct, useful, and shipped. Track outcomes, not output.
• Human judgment over human throughput. When agents do more of the procedural work, the human contribution shifts toward intent, taste, judgment, and accountability. The team structure that made sense for human throughput does not necessarily fit a world where one engineer with strong domain knowledge and good agent orchestration can often execute work that previously required multiple coordinated implementation roles.

How do we evolve the engineering team toward this?

Gradual evolution #

The shift will likely not happen all at once, and most teams will resist it for the same reason most teams resisted agile in 2003: the existing process is what they are comfortable with, and the new one is unfamiliar and unproven. Given this, some practical changes that could work and are not too disruptive:

1. Start with intake, not sprints. The most leveraged early change is automating triage and intake. Agents can convert support tickets, Slack threads, and customer calls into well-scoped issues with the right labels and routing. This reduces the meeting load immediately and proves out the pattern that agents can do procedural work well.

2. Replace estimation with prioritization. Stop running estimation rituals. Instead, ask two questions for each piece of work: is this worth doing, and is the spec good enough that someone (human or agent) can execute against it. If the answer to either is no, the work is not ready. Story points add no information that a yes/no on these two questions does not already provide.

3. Make (most) standups async. The daily standup is the easiest ceremony to retire. Replace it with an async update from issue tracker activity. Keep a weekly sync for things that genuinely need synchronous discussion (architecture, blockers, customer issues), and let the rest happen through writing.

4. Treat the spec as the artifact. Code review will not scale if the team is generating ten times more code. The leverage point moves earlier in the process and spec review becomes the new code review. The questions the spec review should answer:

   • What behavior are we expecting
   • What are the important edge cases
   • What non-functional constraints matter (e.g. security, reliability, performance)
   • How will we know the result is correct

   An engineer and a PM should align on this before any code is generated.

5. Keep sprint reviews, but reframe retrospectives. Demos still matter: showing working software to stakeholders and customers is one of the most valuable things a team does. Keep those. Retrospectives also matter, but the focus shifts from "how did our process work" to "what should change in our process." Use retros to question the rituals themselves, not just refine them.

6. Be deliberate about which ceremonies to keep. Retiring all of Scrum at once is a bad idea. Some ceremonies serve a real purpose beyond coordination, especially as a team is learning to work this way. Keep the ones that do, and gradually drop the ones that have become routine. The test should be simple: if the meeting were canceled, would anything actually break?

Metrics for the new world #

The old Scrum metrics measured human throughput inside a fixed cadence. They are mostly the wrong metrics now.

The metrics that will survive the transition are the ones tied to outcomes and flow:

• Lead time i.e. time from idea to production. This is the most important metric: as you compress the SDLC with AI tooling, lead time should shrink visibly. If it is not shrinking, what you are doing is not delivering value at the pace it should.
• Cycle time from in-progress to done, per piece of work. This is useful for finding bottlenecks. If cycle time is going up while lead time is going down, work is sitting in queues somewhere (most commonly: in review).
• Defect escape rate. Bugs found in production divided by bugs found before production. As code generation accelerates, this is the canary metric for whether your validation is keeping up.
• Spec quality. This is harder to measure quantitatively, but observable: how often does work get rejected at spec review, how often does generated output need significant rework, how often does a finished feature not match the original intent. These are leading indicators of whether the team is treating the spec as the primary artifact.
• Time to validate a hypothesis. From "we think users want X" to "we have evidence one way or the other." As prototyping gets faster and feedback loops tighten, this number should shrink dramatically. If it is not shrinking, you are using faster tools without faster thinking.
• Validation latency. Cycle time measures total time in progress. Validation latency measures specifically how long work waits in testing, review, security checks, and deployment validation queues before it is trusted enough to ship to production. As code generation accelerates, this is where most of the cycle time will live.
• Customer-reported issues per release. This is an old metric, but it is still valuable, and is the ultimate test of whether faster shipping is also better shipping.

The metrics to retire or deprioritize:

• Velocity assumes humans are the bottleneck and story points are the unit of throughput: both of which are decreasingly true.
• Sprint burndown assumes a fixed sprint boundary, which is increasingly artificial.
• Planned-to-done ratio measures how good a team is at predicting work in a sprint, which matters less when sprints are less rigid.

These metrics measure the wrong layer: they tell you how predictable your sprint is, not whether you are building the right thing or shipping it well.

Principles, not procedures #

The Agile Manifesto's four values and twelve principles will survive intact. The principles translate, but the Scrum procedures built on top of them won't. These were tools optimized for a world where implementation throughput and human coordination were the dominant constraints. As those constraints dissolve, the tools become overhead.

The original Agile Manifesto came out of frustration with waterfall. The next evolution will come from teams who realized parts of Scrum had become ceremony for ceremony's sake and started adopting workflows that better match how software gets built with AI-assisted tools.

Right now, most teams are layering new tools onto old processes. What you get is a faster version of the same process, not a different one.

Over the past decade, most mature engineering teams have converged on a shared understanding of what a well-run software development lifecycle should look like to build software that meets customer requirements, and is reliable, supportable, scalable, and secure.

The process usually starts with getting to a clear understanding of what should be built and why. That is where the Product Manager or Product Team comes in. This initial phase, often called product discovery, involves customer interviews to refine the problem, and may also include building Figma prototypes or a simple mocked UX to gather customer feedback. The output of this phase is a set of requirements for the engineering team.

Once there is confidence in the product direction, the team moves into a more structured flow. Requirements are written down in a way that engineering can act on, typically as a Product Requirements Document (PRD). Work is then broken into smaller pieces with clear acceptance criteria, often tracked as tickets in tools like Jira or Linear. At this point, engineering teams also start thinking about how the feature will be tested. What are the critical paths? Where are the edge cases? What would failure look like?

In parallel, the design team works on wireframes, some of which may have been used during product discovery, and evolves them into a more refined user experience and pixel-perfect UI. This ideally builds on an existing design system, which provides a centralized set of reusable components and standards.

Mature engineering organizations typically create an engineering design document at this stage. This document is reviewed by other engineers, and key technical decisions are recorded. The design also includes security and reliability considerations. This may involve building a lightweight threat model to think through how the system could be misused. Where does data enter the system? What are the trust boundaries? What happens if users try to access something they should not?

The team also defines a test and release strategy. Testing includes unit tests for core logic, integration tests for service interactions, and end-to-end tests for critical workflows. Smoke tests are defined to ensure that core functionality does not break with new changes.

During implementation, a well-run SDLC requires that every change goes through code review. A good reviewer looks at correctness, coding standards, security concerns, and scalability. These checks are often supported by automations run in the Continuous Integration (CI) pipeline. These include functional checks (typically unit tests) as well as Application Security (AppSec) checks: static analysis tools scan for common vulnerabilities, and dependency scanners flag outdated or insecure libraries on every change.

After code is merged into a designated branch for a release candidate, the release validation process includes running a broader set of automated tests along with manual exploratory testing. Performance testing may also be conducted at this stage. The goal is to validate that the release is ready for production.

Deployment is typically handled in a controlled manner. Techniques such as canary releases and feature flags allow teams to roll out changes gradually and limit the impact if something goes wrong.

Once the code is running in production, the operations/site reliability function, whether a dedicated team or a rotating responsibility within engineering, focuses on monitoring and alerting. This includes tracking error rates, latency, and overall system health.

The security counterpart to site reliability/operations, the Security Operations (SecOps) team, monitors production for unusual behavior such as repeated failed logins or unexpected access patterns. Periodic penetration testing may be conducted to simulate real-world attacks and uncover issues that automated tools might miss.

While this diagram gives the impression of a waterfall process, modern engineering teams run the process far more iteratively. Design and engineering are involved during discovery, security and QA planning starts at design time, QA runs alongside implementation, and deployment is a continuous capability rather than a discrete phase. Feedback loops exist at every stage.

Even with all of these feedback loops in place, shipping complex software changes still took weeks. AI-assisted development tools are compressing that cadence enough that the shape of the SDLC process itself starts to change.

How AI Will Change the Way We Build Software #

The future is already here — it's just not evenly distributed. ~ William Gibson

The core structure of the SDLC described above does not go away: teams will still need to understand the problem, design a solution, build it, test it, and run it in production. What will change is the speed of iteration, the shape of the work, and the boundaries between roles.

Product: Faster Validation, Tighter Loops #

The PM's job will move from writing detailed requirements to driving rapid validation.

Tools like v0, Lovable, and Bolt let product teams generate mockups and working prototypes in an afternoon without pulling in engineering. Perplexity accelerates competitive research and customer insight synthesis. Feedback cycles that used to take weeks will take days.

Requirements do not go away, but they get lighter. You still need a clear problem definition, success metrics, and the constraints that matter.

The risk is that faster prototyping gets mistaken for faster thinking. Compressing the discovery cycle is only valuable if the team is still asking the hard questions: whether the problem is real, whether the solution fits, whether the assumptions hold. Moving quickly through discovery without that discipline does not shorten the path to a good product. The teams getting this right use the faster tools to run more experiments, not fewer conversations.

Engineering: From Writing Code to Validating It #

The development team is where this gets most disruptive. AI tools can generate large amounts of code quickly. This increases velocity, but it also increases the need for discipline. The role will shift from writing code to validating it. Less time spent generating implementations, more time spent thinking through correctness, edge cases, and system behavior.

In practice, this means using tools like Cursor, Claude Code, or GitHub Copilot to generate initial implementations, iterating quickly on small changes instead of writing everything from scratch, and spending more time reviewing logic, edge cases, and failure modes.

Best practices for AI-assisted development are still evolving. On one end, engineers are learning to be more deliberate in how they prompt, making assumptions and constraints explicit rather than leaving gaps for the model to fill. On the other end, more formal approaches are emerging. Spec-driven development treats a written spec defining inputs, outputs, and constraints as the primary artifact, with code following from it rather than the other way around. AI development platforms like Kiro are making spec-driven development more accessible: instead of starting from a blank page, you describe what you want in natural language, and Kiro generates a structured first pass at requirements, architecture, and an implementation plan. From there, engineers refine it into a spec they can actually build against. Another approach is to use contract testing, such as Pact. Contracts are defined upfront, and implementations are validated against them. When agents are writing code, this gives you a clear guardrail by shifting the focus away from reviewing every line toward verifying that the code satisfies the contract.

Regardless of the approach, the underlying principle is the same: define guardrails for AI-assisted development. When code can be generated in minutes, the scarce resource is not the implementation but the precise description of what it must do. Whether that means a formal spec, a contract, a test written before the code, or simply a more explicit prompt, the goal is the same: give the model something to execute against rather than gaps to fill.

Code review will matter more, not less, but the nature of it will change. Reviewers are running into a scaling problem. If an engineer can generate ten times more code in the same amount of time, the review load grows just as fast, but reviewer attention does not scale with it. Reviews risk becoming superficial, and a rubber-stamped review is worse than no review because it creates a false sense of safety. This is where a new class of AI-assisted code review tools is emerging. Tools like Optimal AI's Optibot, CodeRabbit, and Qodo sit inside the pull request flow, flagging breaking changes, risky patterns, and logic issues with awareness of the broader codebase rather than just the lines being changed. They bring context a human reviewer would need to go find manually: cross-repo dependencies, past decisions, related components. The reviewer still makes the call, but starts from a better position.

But tooling alone will not solve the underlying challenges. More of the safety net needs to shift toward things that scale automatically: tests that actually exercise behavior, complexity metrics that flag hard-to-reason-about code, and static analysis that catches entire classes of issues without human intervention. Code review will still matter, especially for architecture decisions and sensitive areas. But relying on it as the primary quality gate for the volume of code AI can produce is a shaky assumption.

Engineers will need to move up a level of abstraction: less time spent writing code, more time spent thinking through correctness and system behavior. Most engineering teams are still hiring, training, and structuring work for the old version of the job.

QA: From Gatekeeper to Continuous Validation #

Because shipping velocity is higher, quality checks need to be stronger and more automated. QA teams already define test strategies early and build continuous regression coverage. What changes is that test generation itself gets automated.

Newer tools like Meticulous and Reflect are going further than traditional testing frameworks like Playwright and Cypress, automatically generating regression tests by observing how users actually interact with a product rather than requiring engineers to write every scenario by hand. The goal is coverage that keeps pace with the rate at which code is being produced.

QA will become less of a technical function and more of a product one. When test generation is largely automated, the value is no longer in writing and running tests. It is in knowing which edge cases matter, what a failure actually means for a user, and where automated coverage is likely to be shallow. That requires someone who deeply understands the product, not just the testing framework.

The role does not disappear, but teams that keep defining it around test execution will find it increasingly hard to justify.

Design: From Artifact Production to User Experience Decisions #

AI tools are compressing the design function faster than most design teams have anticipated. Tools like v0 and Lovable mean that a PM or engineer can generate a working UI in an afternoon without a designer in the room. The prototyping phase, which used to be a core design deliverable, is now something almost anyone can produce.

So will we still need designers?

What these tools cannot reliably do is make good decisions about information hierarchy, user mental models, or accessibility. Those are judgment calls that require understanding users deeply.

If design is defined around producing artifacts, AI tooling will replace it. If it is defined around user experience decisions, skipping it shows up later as a product that feels incoherent.

The teams that get it right will use faster tooling to get to higher-fidelity feedback sooner, with design involved at the decision-making level rather than the artifact-production level.

Security: More Surface Area, Legacy Controls #

Generated code can include insecure patterns, outdated libraries, and incorrect assumptions about authentication or data handling. These tools are built to produce working code, not necessarily safe code, and what used to surface over weeks of development can now appear in a single afternoon session.

The threat landscape is also moving faster. AI models are accelerating the pace at which vulnerabilities are discovered and exploited. They are already being used to analyze codebases and identify attack surfaces at a speed and scale that human security researchers cannot match, which means the window between a vulnerability being introduced and being exploited is shrinking. AI-driven attacks are becoming more sophisticated. Models are being used to craft more convincing phishing attempts and automate reconnaissance. They can also adapt to defenses at a pace manual attackers could not match.

Application security tooling has to evolve in response. Static analysis (SAST) has historically been pattern-based and signature-driven. Traditional tools like Semgrep and Snyk work well for known vulnerability classes but struggle with the context-dependent issues that AI-generated code tends to introduce. A newer class of AI-assisted security tools is emerging to fill that gap. Tools like Optimal AppSec Agent, Aikido, and Socket review pull requests and dependencies with broader codebase context, catching issues that pattern-based tools miss because they have no awareness of how the system fits together.

The same shift is happening in dynamic testing (DAST). Traditional tools like Burp Suite and ZAP run defined payloads against defined endpoints, relying on the human running them to interpret findings and chain them together. Newer AI-driven tools like XBOW and Pynt can reason about application context, generate targeted test cases based on what an endpoint actually does, and chain findings the way a human pen tester would. The category is earlier than AI-assisted SAST, but evolving along the same path.

The tooling shift alone does not address the broader problem. Shipping velocity and manual security processes are on a collision course. AppSec and SecOps will need to be largely automated. The focus will shift to designing the right controls upfront rather than auditing after the fact.

AI agents also introduce a threat vector that the traditional SDLC did not have to account for. When an agent can read files, execute commands, and operate with some autonomy, the questions around access control, least privilege, and trust boundaries become significantly more complicated. What can the agent modify? What happens if it is manipulated through a prompt injection in a file it is asked to process? Most teams do not yet have good answers, and the industry is still working out what the right patterns even look like. How you scope agent permissions, how you defend against prompt injection, how you audit what an agent actually did: these are open problems, and the conventions that will eventually govern them are still being written.

Threat modeling at the design stage and penetration testing in production still matter. But as shipping velocity increases, any manual process sitting in between becomes a bottleneck.

The Faster Horses Are Here #

If I had asked people what they wanted, they would have said faster horses. ~ Henry Ford (allegedly)

Cursor, v0, Lovable, Claude Code: each of these tools compress steps that used to take days into hours. But they fit into the existing models: the engineer still writes and reviews code, the product manager still owns the requirements, and the QA engineer still runs tests. The roles are intact (for now); the work just moves faster.

The open question is whether what comes next is an even faster horse, or something else entirely.

This happens more often than you would think. A maintainer fixes a serious security bug, writes something vague in the changelog like "redacted tokens" or "increase encryption work factor," and moves on. The LLM's job was to read that deliberately obfuscating language, figure out what it actually meant, cross-reference it against public CVE databases, and flag the gaps. Because these were never published as CVEs, downstream developers had no way of knowing they were running vulnerable versions.

Over the course of 2024, Aikido's pipeline uncovered more than 500 undisclosed vulnerabilities in open-source packages, and 67% were still undisclosed months after the fix had shipped. Over half of the high and critical ones had never been disclosed at all. These were not obscure libraries: they found undisclosed vulnerabilities in Axios (56 million weekly downloads), Apache's echarts, Chainlit. Remote code execution was the most common category among the critical findings.

"We have to assume that the bad guys have done this too, and that they can find and exploit these vulnerabilities before organizations patch them."
Mackenzie Jackson

From reading about bugs to actually finding them #

Aikido's work was clever, but it operated within a defined boundary. The LLMs were not discovering new vulnerabilities so much as surfacing ones that humans had already found and fixed but neglected to disclose. The model was a very sophisticated reader of commit diffs and release notes.

That boundary did not last long. In October 2025, OpenAI unveiled Aardvark, an autonomous security agent built on GPT-5. Aardvark did not just read changelogs. It read actual source code, analyzed entire repositories, built threat models from scratch, scanned incoming commits for security implications, and then attempted to exploit what it found in a sandboxed environment to confirm the vulnerability was real. In benchmark testing it identified 92% of known and synthetically introduced vulnerabilities, and it had already earned ten CVE identifiers from bugs it found in open-source projects on its own.

This was a qualitative shift: the LLM was no longer a passive reader spotting what humans had missed disclosing. It was an active hunter finding what humans had missed entirely, doing the full loop from discovery through exploitation through patch generation without a human in the chair. Aardvark, by every subsequent measure, turned out to be a modest preview of what was coming.

The vulnerability avalanche #

In 2024 alone, over 40,000 CVEs were reported, already overwhelming security teams worldwide. The time between disclosure and exploitation had been compressing for years, and the window defenders relied on was narrowing toward zero. But all of that assumed the bottleneck was on the discovery side: vulnerabilities were hard to find, expensive to analyze, and required deep human expertise to weaponize. Remove that bottleneck by handing the job to a model that can read millions of lines of code in minutes and reason about memory corruption, type confusion, and race conditions, and the math changes in a way that does not have a gentle term for it.

Open source was particularly exposed. We all remember Log4j in 2021: a single critical library maintained by a handful of volunteers, buried four layers deep in the dependency tree, turned out to be the load-bearing wall for half the internet. But Log4j was found by a human researcher at Alibaba who happened to notice something odd. The question now on the table was: what happens when models can systematically audit every package on PyPI, npm, and crates.io in parallel, around the clock?

Mythos and Project Glasswing #

On April 7, 2026, Anthropic published something that read less like a product announcement (which it was!) and more like a threat briefing.

Project Glasswing brought together AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks around a single premise: AI models have reached a level of coding capability where they can surpass all but the most skilled humans at finding and exploiting software vulnerabilities, and the clock is ticking before those capabilities proliferate beyond responsible actors.

At the center of the announcement was Claude Mythos Preview, an unreleased frontier model that had discovered thousands of zero-day vulnerabilities, including some in every major operating system and every major web browser. Not shadow patches in changelogs, not synthetic bugs in benchmark repos, but real, previously unknown, exploitable flaws in the software that runs the actual world.

A few of the disclosed examples: Mythos found a 27-year-old vulnerability in OpenBSD, an OS whose entire reputation is built around being security-hardened, that allowed an attacker to remotely crash any machine just by connecting to it. It found a 16-year-old bug in FFmpeg in a line of code that automated testing tools had hit five million times without catching. It independently discovered and chained together multiple Linux kernel vulnerabilities to escalate from ordinary user access to full system control. These are the kinds of bugs that win Pwn2Own competitions and command six-figure bounties. The model found them autonomously.

On the CyberGym benchmark for vulnerability reproduction, Mythos scored 83.1% compared to Opus 4.6's 66.6%. On SWE-bench Verified it hit 93.9%. Anthropic is not making Mythos Preview generally available. Instead it is being provided to launch partners and over 40 organizations that build or maintain critical software infrastructure, backed by up to $100 million in usage credits and $4 million in direct donations to open-source security organizations. The operational focus is defensive: vulnerability detection, black-box testing, endpoint security, penetration testing.

The dual-use problem #

Every capability that makes Mythos valuable to defenders (the ability to reason about code semantics, chain together subtle bugs across subsystems, generate working exploits) is exactly what makes it valuable to attackers. The only real question is who gets there first.

Anthropic was explicit about this, noting that it will not be long before such capabilities proliferate beyond responsible actors and that the fallout for economies, public safety, and national security could be severe. CrowdStrike's CTO Elia Zaitsev put it more directly: the window between a vulnerability being discovered and being exploited has collapsed from months to minutes with AI, and that is not a reason to slow down but a reason to move together, faster.

The trajectory from BSides SF 2025 to Project Glasswing is a story in three parts of a future that arrived faster than anyone expected. First, LLMs learned to read what humans had written about bugs. Then they learned to find bugs that humans had missed entirely. Then they got better at it than all but the very best humans alive.

The old model of human-paced vulnerability research, disclosure, and patching cannot survive contact with systems that operate at machine speed and machine scale. The software ecosystem has accumulated decades of technical debt, patching at scale remains painful, and attackers only need to find one bug while defenders need to find all of them.

Or, if you are a glass half-full kind of person:

This is the core problem with how most teams use AI coding tools. You open a chat, describe what you want, get code back, iterate. For small isolated tasks that's fine. It breaks down when the problem has real constraints or multiple steps, because the model is filling gaps with reasonable guesses that may have nothing to do with how your system actually works. You then spend the session correcting those guesses: "no, we use pnpm not npm," "no, don't modify the migrations directly," "no, errors go through ApiError not raw throws." Those corrections vanish when the session ends. Next session, same thing.

The fix is not better prompts. It is giving the model the context it needs. There are three ways to do that.

AGENTS.md: tell the model about your codebase once #

AGENTS.md is an open standard (stewarded by the Linux Foundation, supported across Claude Code, Cursor, GitHub Copilot, Codex CLI, and Gemini CLI) for committing project context directly to your repository. Every AI tool that reads it gets the same starting point. CLAUDE.md is Claude Code's native equivalent with some additional capabilities, but Claude Code reads AGENTS.md as a fallback, so one file covers most tools.

The right mental model is a README written for an AI rather than a human. Not an exhaustive specification of everything about the project, but the specific things the model cannot infer from the code itself: build and test commands, hard constraints, architectural decisions that aren't obvious from the directory structure.

Three things that are worth knowing before you write one. First, keep it human-written and short. ETH Zurich researchers tested context files across four AI agents and found that LLM-generated files hurt performance, reducing task success rates while increasing inference cost. Human-written files showed roughly a four percentage point improvement. Auto-generate your AGENTS.md and you're paying more to get worse results. Second, don't put code style rules in it. That's your linter's job, and it does it deterministically and cheaply. Third, be aware that frontier models can follow around 150-200 instructions reliably. Claude Code's own system prompt already uses roughly 50 of those, so every line you add to AGENTS.md is competing for a finite budget. Include only what matters universally.

# AGENTS.md

## Project
E-commerce API. Node.js 22 / TypeScript strict / Fastify 5 / PostgreSQL 16 via Drizzle ORM.

## Commands
- `pnpm test` — unit tests
- `make test-integration` — integration tests (requires local DB)
- `pnpm lint` — ESLint + Prettier

## Hard constraints
- Never modify files in /migrations directly
- All handlers must validate input with Zod schemas
- API errors use ApiError class, never raw throws
- Do not modify anything in vendor/

## Architecture
- /src/api — route handlers only
- /src/services — business logic, no DB access
- /src/db — Drizzle schema and queries only

If your team uses multiple AI tools, maintain AGENTS.md as the single source of truth and have CLAUDE.md reference it with only Claude-specific additions. One file to keep current rather than several slowly drifting apart.

Spec-driven development: tell the model what you're building #

AGENTS.md handles persistent project context. Spec-driven development handles the context for a specific piece of work. The idea is simple: write a spec before you ask for code. Not a lengthy design document, just an explicit statement of what the thing should do, what goes in, what comes out, and what the constraints are. Then generate code from that.

The reason this matters is that a vague prompt forces the model to make assumptions. Ask for "a function to process customer transactions" and the model will produce something plausible, but it will guess at error handling, edge cases, and output format. You iterate to correct those guesses, which is slow and produces code that reflects the model's assumptions more than your requirements. Define the inputs, outputs, deduplication rules, and error behavior upfront, and the model is executing against a contract instead of guessing. You get something usable on the first pass instead of something you spend an hour correcting

GitHub's Spec Kit formalizes this into four phases: specify (what you're building and why), plan (stack, architecture, constraints), tasks (break it into reviewable chunks), implement (the agent works through tasks one at a time). Each phase produces artifacts that feed the next, and each has a checkpoint where you review before moving on. The insight in their framing is that the spec is the primary artifact and the code is a derivative, which inverts where most teams spend their attention. You should be reviewing the spec carefully and letting the code follow from it, not the other way around.

For more complex multi-step work, the BMAD method extends this thinking across the full development lifecycle. Rather than a single spec for a feature, you work through problem definition, spec, design, and task breakdown before any code is written. Each step's output becomes the next step's input. The practical benefit is that errors get caught early: a flawed spec is much cheaper to fix than flawed code, and the model has continuity across the whole effort rather than starting fresh at each turn.

Screenshots: tell the model what you can see #

For UI and visual work, screenshots are one of the most underrated tools for giving a model precise context. Describing a visual problem in words is surprisingly hard. "The button is too close to the header" is ambiguous in ways you don't realize until the model fixes the wrong button on the wrong screen. A screenshot with the element visible removes most of that ambiguity in a way that text cannot.

Claude handles image input well. The prompt pattern that works is straightforward: attach the screenshot, point at the specific element that needs to change, and describe what you want differently. Reference what you can see in the image rather than class names or component names the model may not recognize from the codebase. The same applies to design references. If you have a Figma frame or a screenshot of how something should look, attaching it is almost always more precise than trying to describe the visual in words.

The pattern #

All three of these are the same idea at different levels. AGENTS.md closes the gap between the model and your project. A spec closes the gap between the model and your intent for a specific feature. A screenshot closes the gap between the model and what you can see but struggle to describe. In each case you are replacing the model's guesswork with your actual requirements.

Get this right and the model does what you actually want. Get it wrong and you spend most of your time correcting assumptions the model should never have had to make. A clever prompt on top of thin context is still thin context.

Something has changed over the past two months.

The first thing is a formalization of how to actually do development with AI tools that I've been playing with: spec-driven development. Rather than just prompting and iterating, you invest upfront in a living specification to capture intent, and use that to drive the implementation. It changes the dynamic considerably. Instead of the AI guessing what you want, it has something to reason against.

More fundamentally though, it is the models themselves.

Claude Opus 4.6 in particular feels like a different category, not just an incremental improvement. Seems I'm not the only one who thinks so. Professor Knuth just published a paper titled "Claude's Cycles" describing how Opus 4.6 solved an open graph theory problem he had been working on for several weeks, in about an hour. He ends the paper with "Hats off to Claude!"

Clearly, I'm not the only one noticing this!

The Gaps #

Too much power, not enough context #

Once an agent gets an OAuth token it can keep firing off API calls — often far beyond what the user had in mind. Scopes like calendar.readwrite can't express intent like "only book meetings on weekdays between 9–5."

Who actually pressed the button? #

OAuth tokens tell you which user is behind a request, but not which agent (or sub-agent) made it. We need "actor" tokens that travel with each call for true accountability.

One-time consent vs. continuous decision-making #

Humans can't approve every micro-action an always-on agent takes. We need real-time checks and step-up permissions — not a static "yes" at login.

Standing access vs. just-in-time access #

Long-lived tokens give an agent perpetual power it may need only once a week. That "standing privilege" is a gift to attackers using prompt-injection and other techniques. Agents should instead request short-lived, task-scoped tokens on the fly and drop them when the job is done — zero standing privilege (ZSP) for agents.

OAuth 2.0/2.1 is a great starting point, but on its own it can't guarantee that AI agents stay inside the guardrails. What is needed is layered controls: task-scoped tokens, policy engines, and audit hooks to keep AI agents safe and aligned.

Working Paper #

I've outlined the gaps and a proposed layered mitigation strategy in full below, and on TechRxiv. Feedback welcome!

For an engineering team, the two questions I want to be able to answer at any point are: are we a high-performing team that is shipping customer value with a low failure rate, and how are our customers actually experiencing the service? Everything else is secondary.

What makes a metric good #

A good metric is:

• Relevant to the questions you are trying to answer, not just easy to collect.
• Actionable in the sense that if it moved in the wrong direction, you would know what to do about it. If the answer is no, it is probably measuring the wrong thing.
• Quantifiable and comparable over time, so you can tell whether things are getting better or worse.
• Measuring outcomes, not output. Output is what the team produced. Outcomes are the effect that production had on customers and the business. This is the criterion teams most often get wrong.

The traps to avoid #

• Vanity metrics look good but tell you nothing actionable. Story point velocity is a classic example. If the team completed 1,385 points in a quarter, up from 991 the quarter before, that looks like progress. But it bundles customer-facing features, bug fixes, and internal refactors into a single number. You cannot tell from it whether customers got more value or whether the team just worked harder.
• Watermelon metrics are green on the outside and red on the inside. A team reports 97% support SLA compliance, which sounds healthy until you look at which bugs are actually being fixed on time. If the P1s are handled but the P3s are quietly accumulating into a backlog that degrades the product experience, the headline number is misleading you.
• Too many metrics is its own failure mode. When everything is measured, nothing is prioritized. Teams spend time maintaining dashboards instead of acting on them. Pick a small number that between them answer your most important questions, and be ruthless about adding new ones.
• Metrics not aligned to business outcomes create perverse incentives. If engineers are measured on tickets closed, they will close tickets. If they are measured on features adopted by customers, they will think harder about whether what they are building actually solves the problem.

A worked example: change failure rate #

Change failure rate is the percentage of deployments that cause a failure in production, measured by rollbacks, patches, and hotfixes. It satisfies almost every criterion for a good metric: it is quantifiable, comparable week over week, directly tied to customer experience, and highly actionable.

When we first started tracking it on one of my teams, the number came back at 27%. The benchmark for a healthy engineering team is under 1%. That gap was uncomfortable, but discomfort is exactly what a good metric should produce when something is wrong. We could look week by week at which deployments failed, trace them back to specific changes, and course-correct on code review practices, test coverage, and deployment process. Within two quarters we were under 1%, and we would not have known where to start without that number in front of us.

An example metric set #

Here is how I structured engineering metrics for a 25-30 person engineering org, but the broad principles apply to larger and smaller orgs. Essentially, there were two questions that I was trying to answer: (a) Are we a high-performing engineering org? (b) How do customers experience our product?

Are we a high-performing engineering org? #

A high-performing engineering org consistently ships value to customers over time, with a low change failure rate. The metrics that answer this question are:

• Value shipped (story points of completed customer-facing feature work). The benchmark we used was 1 point per developer per day, giving a quarterly target of roughly 1,040 points for a 16-person team working across a 65-day quarter. If this number drops, the next question is why, which leads to the diagnostic metrics below.
• Value vs. KTLO ratio. KTLO ("keep the lights on") covers bug fixes, reliability work, onboarding, and tech debt. A team spending most of its time on KTLO is not shipping much customer value, and that ratio is worth tracking explicitly. We started with total story point velocity and then broke it into these two buckets from Q2 onwards, which made the number considerably more useful.
• Planned vs. unplanned work. A high proportion of unplanned work is a signal that the team is being pulled off roadmap commitments by fires, and that the system is less stable than it should be.
• Change failure rate. The share of deployments that result in an incident, rollback, or failure, calculated as (number of failed changes / total number of changes) * 100. Benchmark is under 1%. When we started tracking this we were at 27%, which was the clearest possible signal that something needed to change in how we were testing and reviewing code.

How do customers experience the product? #

• Bug impact score. Rather than counting raw bug numbers, this is a weighted sum by severity, so a P0 bug counts for much more than a P3. It is a proxy for the impact product quality has on customers, and more honest than a simple bug count that treats all issues the same. Our target was a weekly bug impact score below 10.
• Support SLIs. Timeliness in fixing customer-reported bugs, by criticality. The targets we used: P0 bugs mitigated within 0 to 1 business days, P1 bugs within 3 business days. Without severity-based targets, teams naturally optimize for closing the easy tickets, which inflates overall SLA compliance while the high-severity issues sit.
• Uptime. Measured as (total available time / total time) * 100, with availability defined as the ability to log in and have the application load within baseline latency. For a SaaS product with contractual uptime commitments, this is non-negotiable to track continuously rather than in periodic reports.

Leading vs. lagging indicators #

Leading indicators are input-oriented and measure things that predict future outcomes, like deployment frequency or test coverage. Lagging indicators are output-oriented and measure results, like uptime or customer retention. You need both. Lagging indicators tell you how you did; leading indicators tell you where you are headed. A team that only tracks lagging metrics is always looking in the rearview mirror, finding out about problems only after they have already landed on customers.

Cadence #

A metric reviewed quarterly is not a management tool, it is a retrospective artifact. For metrics to actually change behavior, they need to be reviewed at a cadence short enough to act on. Change failure rate is worth looking at weekly. Uptime warrants continuous monitoring. Velocity makes sense at the sprint level. The right cadence depends on how quickly the underlying thing can change, but if you cannot do anything with a metric between reviews, you are reviewing it too infrequently.

The practical approach: start by asking what questions you most need to answer, then work backwards to the metrics that would answer them. Three to five metrics that between them address shipping velocity, quality, and reliability is usually enough for an engineering team. Add a metric only when you can articulate what decision it will help you make, and be willing to retire the ones that no longer drive action. The goal is not a comprehensive picture of everything the team is doing. It is enough signal to run the team well.

I'm sharing it here because the questions it tries to answer come up constantly in hiring, in onboarding, and in the day-to-day of running an engineering org. If any of it is useful to other teams, all the better.

Download as PDF

Engineering Culture #

Culture is what the team defaults to without being told. It shows up in how people respond to an outage, how they handle disagreement, and whether they fix the broken thing they stumbled across or walk past it. Three values anchor how I want the team to operate.

Ownership #

You build it, you operate it. If you see something broken, you fix it. Ownership is not limited to your service or your ticket but is a mindset: the difference between observing that something is broken and doing something about it.

Agency #

Agency is the degree of control individuals and teams have over their work and their ability to influence outcomes. High agency looks like reaching out to unblock yourself and pressing on rather than sitting on a ticket waiting for another team to respond.

Customer Empathy #

Engineers need to feel customer pain directly, not through two layers of abstraction. Rotation through support and customer-facing roles creates a virtuous loop that feeds back into engineering design, and the reminder worth repeating is that we are solving a problem, not writing code.

Engineering Principles #

These are the principles that guide how we design, build, and operate. They are not rules to be followed blindly but the condensed output of hard lessons.

• Start small, iterate, refine. Design for the future, but be pragmatic about what needs to be built today, bias for action over lengthy analysis, and learn by iterating on both the business side (adoption, customer demand) and the technical side.
• Speed is good; velocity is better. Speed is a scalar but velocity is a vector: it has magnitude and direction, and the team needs to be aligned on where it is going, not just how fast it is moving.
• Our job is to solve customer problems, not write code. If open source or commercial software already does what we need, use it and do not reinvent the wheel. Ask why before asking how.
• Focus is everything. Spreading thin sets us up for failure, so stack rank the work and resist the trap where everything is top priority, which means nothing is. Avoid yak shaving.
• Write things down. Documenting decisions, designs, and meeting notes with precision brings a level of clarity that verbal discussions do not, supports remote work, and reduces single points of failure on people.
• Automate all the things. Automation brings repeatability, reliability, and scalability, and if you are doing something manually more than twice, it should be automated.
• Measure outcomes, not effort. Have quantifiable goals measured at a regular cadence and make the metrics actionable. When quality trends the wrong way, pause feature development to address it, because customer-facing features shipped matters more than tickets closed.
• Debate vigorously, then commit. Be open to ideas that are not your own, and once a decision is made, commit to it as a team rather than continuing to relitigate it.
• Shift left on quality, security, and observability. These are not afterthoughts to be bolted on at the end but are built in during the initial planning and implementation phase.

Getting There #

Culture does not change by writing a document. It changes by changing what gets rewarded, and some questions worth asking honestly are: Are engineers rewarded for shipping fast or for writing maintainable, scalable code? Are managers rewarded for velocity or for building strong, sustainable teams? Are teams rewarded for fixing outages quickly or for preventing them in the first place?

What you reward gets repeated. The culture described here is the one we are working toward, and holding ourselves to these principles in practice, especially when it is inconvenient, is how we get there.

The most common of these is the "sandwich method" — negative feedback wrapped between two pieces of positive feedback. There is plenty of empirical evidence that it doesn't work. The negative part gets buried or ignored, and the person leaves the conversation unsure what you actually wanted them to change.

The purpose of feedback is to effect change. For that it needs to be timely (given when the behavior happens, not weeks later), specific, and focused on the action rather than the person. One piece of feedback at a time — a long list is hard to act on.

A Framework That Works #

My Toastmasters club uses a template for speech feedback that translates surprisingly well to almost any situation. It breaks feedback into three sections: what you saw, what you heard, what you felt.

What you saw: Gestures, use of space, eye contact, mannerisms. Pick the one observation that has the most value to learn from.

What you heard: Structure, opening, conclusion, tone, inflection, emphasis. Again, pick the one that matters most.

What you felt: What was the impact on you? Did you feel moved, engaged, lost, bored?

The specifics are for speeches, but the structure is widely applicable. It's detailed, it's actionable, it addresses behavior rather than character, and it forces you to prioritize the one or two things that will actually move the needle rather than cataloguing everything.

How to Phrase It #

Direct feedback doesn't have to be delivered harshly. People respond better to being encouraged to improve than to being criticized for what they did. Two approaches from the same Toastmasters playbook:

• Focus on improvement: "What would have made this even better..."
• Walk with the person: "I've had the same challenge, and here is what helped me..."

The second one is underused. It's honest, it's human, and it tends to land well.

If you want to parse a colon-delimited file like /etc/passwd, all you need is:

IFS=':'

IFS is the Internal Field Separator. Set it to your delimiter and word splitting does the rest.

In Practice #

line='nobody:foo:-2:-2:Unprivileged User:/var/empty:/usr/bin/false'
IFS=":"
array=($line)

echo "username: ${array[0]}"
echo "uid:      ${array[2]}"
echo "home:     ${array[5]}"
echo "shell:    ${array[6]}"

Note the single quotes around $line. Double quotes would let the shell expand the * wildcard to filenames in the current directory.

Here's a complete script you can invoke as script.sh < /etc/passwd:

#!/bin/bash

while read line
do
  # skip comment lines
  [[ ${line} == \#* ]] && continue

  set -f  # disable globbing so '*' isn't expanded to filenames

  IFS=':'
  array=(${line})

  username="${array[0]}"
  uid="${array[2]}"
  gid="${array[3]}"
  info="${array[4]}"
  home="${array[5]}"
  shell="${array[6]}"

  echo "$username  uid=$uid  home=$home  shell=$shell"

  set +f  # re-enable globbing
done

Other Useful Array Tricks #

Iterate over elements:

for element in "${array[@]}"; do echo "$element"; done

Iterate with index:

for index in "${!array[@]}"; do echo "$index ${array[index]}"; done

Count elements:

echo "${#array[@]}"

Here Be Dragons #

Shell arrays have no safety wires. You can unset individual elements or insert at arbitrary indices, which means the array you're working with may be sparse:

unset "array[5]"    # remove element 5
array[9]="ha ha"    # insert at index 9, skipping 7 and 8

So this will silently give you the wrong answer:

# breaks on sparse arrays
count=${#array[@]}
last_index=`expr $count - 1`
echo "${array[$last_index]}"

Use this instead:

# Bash 2.05b+
echo "${array[@]: -1:1}"

# Bash 4.2+
echo "${array[-1]}"

Shell arrays: powerful, footgun-adjacent.

Scrum is not suited for all types of projects #

Lest this sound like heresy, let me clarify. Scrum expects that the team is left relatively undisturbed to work on tasks picked up during a sprint. If a team's work is largely reactive (and this is the case for teams handling a fair number of customer issues), there are methodologies that fit better, like Kanban.

Customer issues are also notoriously hard to estimate. Triage, reproduction, fix, verification: traditional scrum estimation techniques (t-shirt sizing, planning poker) often fall apart here.

Inspect and adapt instead of blindly following the rules #

I've lost count of how many times I've heard the complaint about "not doing scrum right" when the team is faced with changing business priorities mid-sprint. If your scrum master starts quoting rules by chapter and verse, you may be doing it wrong.

Think about the spirit of the law, not the letter. The agile manifesto is worth rereading:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

You refactor code all the time. You should not be afraid to refactor your process based on what does or doesn't work for your situation.

Some questions worth asking in retrospectives: Does your process make you wait until the end of a sprint to push to production? Since tasks are worked on in priority order, is it OK for high-priority items completed early to sit waiting for lower-priority items? For a SaaS product delivering value continuously, how does a rigid two-week sprint cycle actually help?

On unexpected high-priority customer issues: do you invoke "abnormal sprint termination" as a weapon, or tell the customer to wait until the next planning meeting? Teams can handle this pragmatically. Adding a ticket mid-sprint is fine occasionally, as long as you drop something of equal weight. Let the product owner make that call; it also forces an honest assessment of the interruption's actual priority.

Make standups matter #

A peer manager once disparaged the standup as ten minutes of people going around saying "I ate yesterday, I will eat today, nothing is blocking me from eating." (He didn't use the word "eat," but you get the idea.)

What a standup is not good for:

• Status updates. Status belongs in tickets.
• Raising blockers. Don't wait until tomorrow to surface something blocking you today. That's a wasted day.

What it is good for: refocusing the team on what matters, and passing the baton between team members. Five minutes or less. First thing in the morning, before anyone context-switches into deep work. Ideally the only recurring meeting the team attends in a day.

Use the right metrics #

Scrum tooling tends to push teams toward velocity as the headline metric: tickets closed per sprint. That's a vanity metric. The right measure is customer value delivered.

Done means shipped #

Scrum teams often congratulate themselves in review meetings on the number of tickets "accepted" by the product owner. Code that passed review and tests feels done. But for a customer, it means nothing until it's in their hands.

Done means the code is shipped. For a SaaS product that means migration scripts, release notes, runbook updates, and supporting the path through staging to production. Keeping a ticket open through those stages forces you to track the metric that actually matters: customer value delivered.

Watch the big picture #

The rapid develop-demo-feedback loop works well for execution and allows quick course correction. But it is also one of the sources of trouble on agile projects.

Scrum focuses on small steps and bite-sized chunks of functionality. That's a good idea, but only if the overarching architecture and roadmap have been defined up front. Without that, small steps can walk the team off a cliff: delivering product that is hard to support, extend, or scale.

A good technical leader needs to hold the big picture in their head, articulate it clearly to the team, and make sure it guides day-to-day decisions.

Broken windows #

Backlog prioritization means the team only works on high-value issues. Small, low-priority problems (an inconsistent form field label, misaligned UI elements, a confusing error message) never get picked up in a backlog of sufficient depth.

That's not a problem by itself. But a collection of these things, over time, is exactly the broken windows effect: individually minor, collectively the thing that makes a product feel shoddy and unmaintained.

A good product manager keeps these from falling through the cracks permanently: rolling them into a higher-priority usability story, using them as onboarding exercises for new engineers, or carving out a cleanup sprint now and then.