Shell is a fine language for gluing programs together. It is a terrible language for doing it safely unless you tell it to be, and telling it to be takes six lines.

the preamble#

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

What each one prevents:

set -e — exit on any command that fails. Without it, a script continues merrily after cd /nonexistent and then runs the rest of its commands in the wrong directory. This is how a cleanup script deletes the wrong thing.

set -u — error on an undefined variable. Without it, rm -rf "$BUILD_DIR/" with an unset BUILD_DIR expands to rm -rf /. This has happened to real people, at real companies, more than once.

set -o pipefail — a pipeline fails if any stage fails, not just the last one. Without it, curl bad-url | jq . succeeds, because jq was happy with the empty input.

IFS=$'\n\t' — stop splitting on spaces. This is what makes filenames with spaces stop being a source of bugs.

Four lines. They convert an entire category of silent wrong behaviour into loud failure.

the next four things#

Quote every expansion. "$var", not $var. Always, including inside [[ ]] where it usually does not matter, because "usually" is not a rule anyone remembers correctly.

Use "${var:?message}" for required inputs.

: "${DATABASE_URL:?DATABASE_URL is required}"

One line, fails immediately with a useful message rather than three steps later with a confusing one.

Make it idempotent. A script that is safe to run twice is a script that is safe to run at all. mkdir -p, rm -f, check-before-create. The second run is the one that happens during an incident when nobody is sure whether the first one worked.

Clean up with trap.

tmp="$(mktemp -d)"
trap 'rm -rf "$tmp"' EXIT

Now the temporary directory is removed whether the script succeeds, fails, or is interrupted.

the usability part#

A script that other people run needs the same courtesy as any other interface:

usage() {
  cat <<'EOF'
Usage: deploy.sh ENVIRONMENT [--dry-run]

  ENVIRONMENT   staging | production
  --dry-run     print what would happen, change nothing

Requires: awscli >= 2, jq. Reads DEPLOY_ROLE from the environment.
EOF
}
[[ $# -eq 0 || "${1:-}" == "-h" ]] && { usage; exit 0; }

Add a dry-run mode to anything destructive. It costs one conditional and it is the difference between a script people trust and a script people read three times before running.

Echo what you are about to do. set -x is the crude version and it is better than silence. A script that prints "deleting 4 objects from s3://bucket/prefix/" before doing it lets a human catch the mistake.

when to stop using shell#

Shell is right for: calling other programs in sequence, moving files, gluing a pipeline together. Under about a hundred lines.

Switch to a real language when you need:

• Data structures. Bash arrays are a trap and associative arrays are worse.
• Any arithmetic beyond counting.
• Error handling with recovery, rather than exit-on-failure.
• Parsing anything structured. If you are pulling JSON apart with sed, stop.
• Tests. You can test shell, and almost nobody does, which tells you something.

Python or Go for anything past that line. The rewrite is an hour and it pays back the first time somebody has to change it.

the check that costs nothing#

shellcheck scripts/*.sh

Run it in CI. It catches unquoted expansions, useless cat, subshell variable scoping, and roughly a dozen other things that produce silent wrong behaviour.

Every shell script I have ever run it against had at least one real finding. It takes five minutes to add and it is the highest-value linting available for the least-linted language in most repositories.

Size matters for real reasons: pull time on cold start, registry cost, deployment speed when you are scaling out under load, and attack surface — every package in the image is something that can have a CVE you have to answer for.

the six causes#

1. You shipped the build toolchain.

The compiler, the headers, the package manager cache, the source tree, the test fixtures. All of it needed to build, none of it needed to run.

Multi-stage builds fix this completely:

FROM golang:1.24 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /app ./cmd/server

FROM gcr.io/distroless/static-debian12
COPY --from=build /app /app
ENTRYPOINT ["/app"]

Final image: the binary, plus CA certificates and timezone data. Tens of megabytes.

2. You started from a full distribution image.

FROM ubuntu is roughly 80 MB before you install anything, and it includes a package manager, a shell, and a hundred utilities you will never invoke.

The ladder, from largest to smallest:

• Full distribution — 80 MB+
• -slim variants — 30–80 MB
• Alpine — 5–10 MB, with musl libc, which will occasionally surprise you
• Distroless — just the runtime, no shell, no package manager
• scratch — nothing at all, for static binaries

The Alpine caveat, since it bites people: musl's allocator and DNS resolver behave differently from glibc's. Python performance in particular can be significantly worse, and some binary wheels do not exist for musl. Test rather than assume.

3. Your layers are ordered wrong.

Each instruction creates a layer. A layer is invalidated when it or anything before it changes.

# bad — any source change reinstalls every dependency
COPY . .
RUN npm ci

# good — dependencies are cached until the lockfile changes
COPY package.json package-lock.json ./
RUN npm ci
COPY . .

This does not shrink the final image but it dramatically speeds up builds, which is usually what people actually care about.

4. You deleted things in a later layer.

RUN apt-get install -y build-essential   # layer 1: +400 MB
RUN apt-get remove -y build-essential    # layer 2: marks deleted, image unchanged

Layers are additive. Deleting a file in a later layer hides it and does not remove it. The bytes are still in the image and still transferred on pull.

Everything must happen in one RUN:

RUN apt-get update \
 && apt-get install -y --no-install-recommends build-essential \
 && make \
 && apt-get purge -y build-essential \
 && apt-get autoremove -y \
 && rm -rf /var/lib/apt/lists/*

Better: use a multi-stage build and do not install the toolchain in the final image at all.

5. You have no .dockerignore.

COPY . . copies .git, node_modules, build artifacts, test fixtures, and your local .env.

.git
node_modules
dist
*.log
.env*
**/__pycache__
coverage

The .git directory alone is frequently hundreds of megabytes on a mature repository, and it is in a lot of images.

6. Your dependencies are enormous.

Sometimes it is genuinely the dependencies — machine learning stacks with CUDA libraries are legitimately multiple gigabytes.

Check whether you need the GPU variant. torch with CUDA is roughly 2.5 GB; the CPU build is a fraction of that. If you are serving on CPU, you are shipping GPU libraries for nothing.

finding out where it went#

docker history --no-trunc <image>       # size per layer

Or use a layer inspection tool that shows you which files are in which layer and how much space is wasted. Ten minutes with one of those tells you exactly what to fix.

the security dimension#

Every package in the image is potential CVE surface, and your scanner will report all of them regardless of whether the code is reachable.

A distroless image has almost nothing to report, which means the reports you do get are signal rather than noise. That is worth more than the size reduction — a vulnerability report with three entries gets read; one with four hundred does not.

The trade-off: no shell means you cannot docker exec in to debug. Use ephemeral debug containers that attach to the running pod's namespaces instead, which is a better practice anyway because it means your production image is not a debugging toolkit.

the target#

• Compiled language, static binary: under 30 MB.
• Interpreted with dependencies: under 200 MB.
• Anything over a gigabyte without a machine learning stack: something is wrong and it is one of the six above.

That was an accurate assessment of the tools at the time. The tools are substantially different now and the assessment has not updated.

what changed#

Flow-sensitive analysis became standard. Older linters matched patterns in the syntax tree. Modern analyzers track values through the control flow graph, which means they can tell that a variable was checked for null on line 12 and therefore is not null on line 40. That single capability eliminates the largest source of false positives.

Language servers made it interactive. A warning in your editor while you type is a different product from a report generated in CI. You fix it in context, in seconds, instead of triaging a list a week later.

Type systems absorbed much of it. A lot of what static analysis used to catch is now caught by the compiler in a typed language, for free, with no false positives at all.

The defaults got sane. Modern tools ship with a curated recommended set rather than everything enabled. clippy, ruff, biome, staticcheck and their peers are opinionated about what is worth reporting.

They got fast. Analyzers written in compiled languages run over a large codebase in seconds. Speed matters more than people credit — a check that takes two minutes gets run in CI, and a check that takes two seconds gets run on every save, which is where it actually changes behavior.

what to actually run#

A fast linter with a good default set, on save, in the editor. ruff for Python, clippy for Rust, biome or eslint for JavaScript, staticcheck for Go.

A typechecker in strict mode, in CI. This is the highest-value item on the list for a gradually-typed language, and the non-strict modes permit exactly the holes that make the guarantees unreliable.

A security-focused analyzer if you handle untrusted input. Taint tracking — does data from a request reach a SQL query, a shell command, or a template without sanitization — is the specific capability worth having, and it is a genuinely different analysis from ordinary linting.

A dependency scanner, ranked by reachability if your tooling supports it. A critical CVE in code you never call is lower priority than a medium in your request path, and a scanner that cannot tell you which is which produces a queue nobody reads.

the adoption sequence#

Turning on a full rule set against an existing codebase produces thousands of warnings and gets the tool disabled. The sequence that works:

1. Run it in report-only mode. Get the number. Do not fix anything yet.

2. Enable a small subset that has near-zero false positives and fix those. Usually: unused variables, unreachable code, obviously wrong comparisons, missing awaits. Twenty rules, not four hundred.

3. Make it blocking for new and changed code only. Most tools support this, either natively or through a diff-aware wrapper. This is the key move — the existing violations do not block anyone, and the codebase stops getting worse immediately.

4. Burn down the backlog opportunistically. When you touch a file, fix its warnings. No cleanup sprint, no dedicated project.

5. Add rules gradually, one at a time, each with a burn-down.

Steps three and four are where most adoptions succeed or fail. A tool that blocks the whole team on a pre-existing backlog gets turned off; one that only blocks new violations is uncontroversial.

the rules worth arguing about#

Some checks are genuinely contested and you should decide deliberately rather than accepting the default:

Cyclomatic complexity limits. Sometimes a function is legitimately complex because the domain is. A hard limit produces artificially split functions that are harder to read, not easier.

Line length. Real disagreement, formatter should handle it, not worth a rule.

Naming conventions. Worth enforcing, and pick your convention rather than the tool's default if they differ.

Anything with more than a few percent false positives. A rule that is wrong one time in ten trains people to ignore it, and that habit generalizes to the rules that are right.

the honest limits#

Static analysis finds a specific class of bug: local, syntactic, pattern-matchable. It does not find logic errors, wrong business rules, race conditions in most cases, or performance problems.

It is not a substitute for tests, review, or thought. It is a way to spend zero human attention on the errors that do not require human attention, which frees attention for the ones that do.

That framing — attention allocation rather than bug finding — is the one that makes it worth the setup.

the new reason it matters#

Machine-generated code has a characteristic error profile: plausible, syntactically valid, and wrong in specific recurring ways. Unchecked errors, missing awaits, resource leaks, off-by-one in boundary conditions.

Those are exactly the errors static analysis is good at. Running a strict analyzer over generated code is verification you get for free, and it is one of the few places where the verification bottleneck has an automated answer.

Turn it on.

the failure pattern#

1. Platform team forms to reduce duplicated infrastructure work.
2. They build an abstraction over the cloud provider.
3. The abstraction covers 80% of cases well.
4. The remaining 20% is impossible, and the escape hatch is either absent or punished.
5. Product teams work around the platform.
6. Platform team responds by mandating the platform.
7. Everyone is unhappy and the platform is now a tax.

Every step follows from the previous one. The root is step four.

the four properties of platforms that work#

1. An escape hatch that is not punished.

The platform covers the common case. It cannot cover every case, and pretending otherwise is what breaks trust.

There must be a supported path for "I need something the platform does not do," and taking that path must not require an exception process, a meeting, or an apologetic Slack message.

The best platforms make the escape hatch cheap and then compete on being better than it. The worst make it forbidden, which does not eliminate the need — it drives it underground.

2. Adoption is voluntary, at least at first.

A platform that teams choose is a platform that is good. A platform teams are required to use never gets the feedback that would make it good, because the feedback mechanism — people leaving — has been disabled.

If you cannot get voluntary adoption, that is information. Mandating it does not fix the underlying problem; it hides it and converts a product problem into a political one.

Mandate later, when it is genuinely better, and the mandate will be uncontroversial because everyone already uses it.

3. The abstraction leaks deliberately, not accidentally.

Every abstraction leaks. The question is whether you planned for it.

A good platform lets you drop a level when you need to: use the paved path for the deployment, and reach the underlying resource directly when you need something specific. A bad one hides the underlying system entirely, so that when it fails you cannot debug it and neither can the platform team, because now there are two systems to understand.

Concretely: if your platform generates infrastructure configuration, let people see it. If it wraps a cloud API, let people access the underlying resource. If it runs their container, give them the logs from the actual runtime, not a filtered view.

4. The platform team is measured on adoption and satisfaction, not on compliance.

If the platform team's metric is "percentage of services on the platform," they will optimize for mandating it.

If the metric is "would you use this if you had a choice," they will optimize for making it good.

Ask that question quarterly, anonymously, and publish the answer.

the specific things that generate resentment#

Slow escape. A team needs something the platform does not support. The answer is "file a request, we will look at it next quarter." Their deadline is Friday.

Breaking changes without migration paths. The platform is infrastructure. Break it and every team stops. Platform teams frequently hold themselves to a lower compatibility standard than they would accept from a vendor.

Opaque failures. The deploy failed. The error is a platform-internal message. The product engineer cannot debug it and must escalate, which means waiting.

Being a gate rather than a service. A platform that must approve things is a bureaucracy. A platform that makes the right thing easy is infrastructure.

Solving the platform team's problems. Standardization is valuable to the platform team and is not automatically valuable to product teams. If the pitch for a migration is "this makes our lives easier," expect a cool reception.

the framing that works#

You are building a product. Your users are engineers. They have alternatives.

That framing produces the right behaviors automatically: user research before building, documentation that assumes nothing, onboarding that works, support that responds, and a roadmap driven by what users need rather than by architectural preference.

The platform teams I have seen work best behave exactly like a startup selling to a skeptical market, and they say so out loud.

The ones that fail behave like an internal standards body, and they are usually correct about the standards and wrong about how to get them adopted.

the measurement that matters#

Time from "a new engineer joins" to "their code is running in production."

That single number captures most of what a platform is for, it is measurable, and it is the thing product teams actually care about. If it is going down, the platform is working, regardless of what the adoption dashboard says.

the distribution advantage, compounding#

The thing no competitor can replicate is that Google can ship a capability into products that billions of people already open daily, on launch day.

That is worth more than a benchmark lead and it is becoming more visible each year. A model that is marginally better but reaches users through a signup flow loses to a model that is marginally worse and is already in the search box.

The strategic implication for everyone else — including the other frontier labs — is that raw capability is not the competition anymore. Distribution, price, and integration are.

the search question, again#

Every year this conference makes the same thing more true: informational queries are increasingly answered on the results page rather than by sending someone to a site.

For anyone who publishes on the web, the consequences are now well past theoretical:

• Referral traffic to informational content keeps falling. This is measurable and it is not recovering.
• Your documentation is being summarized by a system you do not control, and users are acting on the summary.
• The feedback loop is broken. You cannot see what people asked, what answer they got, or whether it was right.

I do not have a satisfying answer. The mitigations available to an individual project are marginal: write documentation that is hard to summarize badly, keep a machine-readable changelog, make error messages self-explanatory so they do not require a search at all.

The structural problem — that the economic model funding web content is being removed without a replacement — is not solvable by any individual publisher, and the people who could solve it have no incentive to.

the developer surface#

The genuinely useful announcements, as always, are the boring ones:

Model pricing and the cheap tier. The cost-per-capability at the small end continues falling, and Google's TPU position means they can price below what competitors renting accelerators can match. If you run high-volume inference, the arithmetic is worth redoing quarterly.

Longer context, better retention. Incremental and real. The practical question is always the degradation curve, not the maximum, and that continues to improve.

Agent tooling in the cloud. Same category everyone is building: runtimes, memory, identity, observability. Evaluate against a real problem rather than a demo.

the thing to actually do#

The recommendation has not changed in two years and I will keep repeating it because it keeps being right:

Have an eval set in your repository. Fifty examples from your real domain, with expected outputs, run against every candidate model.

Every conference like this produces a new model that is claimed to be better. With an eval harness, evaluating that claim for your workload takes an hour. Without one, it takes a week of impressions and you will get it wrong.

This is a day of setup that pays back on every model release, forever, and the number of teams that have done it remains surprisingly small.

the honest summary#

A very good model, deployed extremely well, in a company with structural advantages that are getting stronger.

Whether that is good for the web is a separate question, and I keep arriving at the same uncomfortable answer.

the strategy#

1. Meet developers where they are, including on other people's platforms.
2. Adopt other people's standards rather than inventing competing ones.
3. Open-source the layers where control is not worth the friction.
4. Monetize the cloud underneath.

Every Build for a decade has been an execution of that, and the cumulative result is that a company which was actively hostile to open source in 2005 is now the largest corporate contributor to it and owns the default editor, the default code host, and a large share of the developer toolchain.

the agent infrastructure#

The substantive announcements this year continue the theme of putting agent capabilities at the operating system layer rather than in an application: a permission model for what agents may reach, an identity model for agents acting on a user's behalf, and audit surfaces for what they did.

That is the right layer for it. The alternative — every application implementing its own agent permission model — produces exactly the inconsistency that made mobile permissions a mess for a decade before the platforms standardized.

The questions that matter and that a keynote cannot answer:

Granularity. "Filesystem access" is not a permission, it is a surrender. Does the model support "read from this directory for this task"?

Consent fatigue. If the prompts are frequent, users click through them, and the control is theater. The design problem is asking rarely and meaningfully.

Revocation and audit. Can a user see what an agent did and undo it? This is the part that is hardest and gets the least attention.

I will believe the security model when someone publishes an analysis of it, not when it is demonstrated on a stage.

the enterprise angle#

The genuinely differentiating position Microsoft has is that they can offer agent capabilities inside an enterprise's existing identity, compliance, and audit infrastructure.

That is worth more to a large organization than raw capability. An agent that works within the existing access control model, logs to the existing audit system, and is governed by the existing data policies clears procurement. An agent that requires a new trust boundary does not, regardless of how good it is.

This is the same advantage that won enterprise cloud and it is being applied identically.

what a developer should actually do with this#

If you build on Windows: the tooling story is genuinely good now — WSL, the terminal, winget, PowerShell 7 — and if your Windows support has been a grudging afterthought since 2018, it is worth revisiting.

If you build agent-adjacent products: design against the OS permission model rather than around it. Products that require users to disable platform protections do not get enterprise adoption.

If you are evaluating anything announced here: wait for the second version. Microsoft's first releases in a new category are consistently rough and consistently improved within a year. That is a reasonable pattern and it means the launch-day evaluation is not the useful one.

the pattern to watch#

The layer where the industry is currently fighting is not the model. It is the control plane for agents: who they are, what they may do, on whose behalf, with what audit trail.

Every platform vendor is building this. The one that becomes standard will have the same kind of position that identity providers have today, and it will be very durable.

That is the strategic story of the next three years and it is being fought in permission dialogs rather than benchmarks.

the levels#

Level 0: LIKE '%query%'.

Works for tiny datasets. No ranking, no stemming, no typo tolerance, and a full table scan on every query.

Fine for an admin tool with a thousand rows. Not fine for anything a customer touches.

Level 1: your database's full-text search.

Postgres tsvector, MySQL full-text, SQLite FTS5. You get stemming, stop words, ranking, and index support.

ALTER TABLE articles ADD COLUMN search tsvector
  GENERATED ALWAYS AS (
    setweight(to_tsvector('english', coalesce(title,'')), 'A') ||
    setweight(to_tsvector('english', coalesce(body,'')), 'B')
  ) STORED;

CREATE INDEX ON articles USING GIN (search);

SELECT id, title, ts_rank(search, q) AS rank
FROM articles, websearch_to_tsquery('english', $1) q
WHERE search @@ q
ORDER BY rank DESC LIMIT 20;

The setweight calls are the part people miss: a match in the title should outrank a match in the body, and without weighting it does not.

This handles most applications. If you have under a few million documents and your users search for terms that appear in them, stop here. One system, no synchronization problem, joins to your relational data.

Level 2: a dedicated search engine.

Elasticsearch, OpenSearch, Typesense, Meilisearch. You get: typo tolerance, faceting, synonyms, custom analyzers, distributed scaling, and much better relevance tuning.

The cost is a second system with a synchronization problem. Your search index is now eventually consistent with your database, and every write path must update both. That inconsistency will produce bugs — a deleted item still appearing in results is the classic — and handling it correctly is real work.

Level 3: hybrid semantic search.

Vector embeddings alongside keyword search, combined with reciprocal rank fusion or a learned reranker.

This handles the case where the user's words are not the document's words. "How do I cancel" should find "Terminating your subscription."

Important: hybrid, not pure vector. Pure semantic search is bad at exact matches — product codes, error numbers, names, function names — precisely the queries where users are most certain about what they want and least tolerant of a wrong answer.

what makes search actually good#

The engine is the easy part. Relevance is the hard part, and it is mostly not about the algorithm.

Weight your fields. Title beats body. Exact phrase beats individual terms. Recent beats old, for content where recency matters.

Use behavioral signals. What users clicked on for similar queries is the strongest relevance signal available, and it requires logging queries and clicks from day one. Retrofitting this means starting your data collection from zero.

Handle the empty result. "No results for X" is a failure. Show something: did-you-mean, related content, popular items, a way to browse. An empty page is where users leave.

Handle the head queries manually. A small number of queries make up a large share of volume. Look at your top hundred, check what they return, and pin the correct answer where it is wrong. This is unglamorous, takes an afternoon, and improves perceived quality more than any algorithmic change.

Log everything. Query, result count, position clicked, whether anything was clicked. The searches that return nothing and the searches where nobody clicks are your improvement backlog, delivered for free.

the instrumentation that matters#

Three metrics:

1. Zero-result rate. Should be low. Every zero-result query is a user who did not find what they wanted.
2. Click-through rate, and the position clicked. If people consistently click the fifth result, your ranking is wrong.
3. Query refinement rate. Users who search, then immediately search again with different words, did not find it the first time.

Most teams have none of these and are tuning relevance by intuition.

the recommendation#

Start at level 1. Postgres full-text search with weighted fields covers more applications than people expect, and it does not introduce a synchronization problem.

Move to level 2 when you have a specific complaint you cannot fix — typo tolerance, faceting at scale, or performance. Move to level 3 when you have evidence that users search for concepts rather than terms.

And whatever level you are at: log the queries. That data is the input to every future improvement and you cannot get it retroactively.

1. You are not caching, or your cache never hits#

By far the most common. Not "we have no cache" — teams have caches. The caches do not hit.

Cache keys that include a timestamp, a branch name, a commit SHA, or anything else that changes every run will produce a 0% hit rate while looking like a working cache. Worse than nothing, because you also pay the upload.

Measure the hit rate first. Most CI systems report it and almost nobody looks. If it is not above 80% on a typical branch build, fix the key before you do anything else.

The key should be a hash of the inputs that actually determine the output: the lockfile for dependencies, the source files for a compilation unit. Nothing else.

2. You are rebuilding things that did not change#

If your build runs everything on every commit, you are paying for the whole repository to verify a one-line change in one module.

The fix is a build graph that knows what depends on what and only rebuilds the affected subtree. This is what Bazel, Buck, Nx, Turborepo, and Gradle's configuration cache exist for.

The cost is real — adopting a graph-aware build system is a project, and for a small repository it is not worth it. The threshold is roughly when your full build exceeds five minutes and most changes touch one small part.

3. Your tests are serial, or parallel badly#

Two separate failures.

Serial: you have 4,000 tests running one after another on one core. Almost every test framework has a parallel mode and it is frequently off by default because parallel tests expose shared state.

If your tests fail when run in parallel, that is a bug in the tests — shared fixtures, a common database, an order dependency — and fixing it is worth doing regardless of speed.

Parallel badly: you split tests into eight shards by file count, and one shard takes six minutes while the others take ninety seconds. Your suite takes six minutes.

Split by historical duration, not by count. Most CI systems support this and it frequently halves the wall clock for free.

4. You are doing full clones#

- uses: actions/checkout@v4
  with:
    fetch-depth: 1

A repository with a long history and large binary files can take minutes to clone. Almost no build step needs history. If one does — a changelog generator, a version-from-tags scheme — give that one job the full clone and shallow-clone everything else.

5. Your runners are too small#

The least satisfying answer and frequently the correct one.

Engineer time is expensive. A larger runner that halves your build time pays for itself immediately at any reasonable team size, and the arithmetic is easy to do:

build minutes/day × engineers × wait fraction × hourly cost
    vs.
extra runner cost

The extra runner is almost always cheaper. Teams resist this because compute cost is a visible line item and engineer waiting is not.

6. You are compiling in the container build#

If your Dockerfile runs npm install and then a compile, and you are not using BuildKit cache mounts and multi-stage builds properly, you are redoing work on every image build.

# cache mount survives across builds
RUN --mount=type=cache,target=/root/.npm \
    npm ci

Layer ordering matters too: copy the lockfile and install before copying source, so a source change does not invalidate the dependency layer. This is well known and consistently gotten wrong.

the measurement#

Before fixing anything, get the breakdown:

queue wait     ← runner capacity or concurrency limits
checkout       ← clone depth, LFS
dependency install ← caching
build          ← incrementality
test           ← parallelism
publish        ← usually fine

Most teams find that one stage is 60% of the time and they had assumed it was a different one.

the target#

Under ten minutes for the check that gates merge. Under two minutes if you can get there.

The reason for the ten-minute line is behavioral: past it, people stop waiting, start batching, and the whole delivery process degrades in ways that are hard to attribute back to the build.

Not everything has to be in that ten minutes. Split the blocking check from the exhaustive one. Lint, typecheck, and unit tests gate the merge. Integration, e2e, and the full platform matrix run after and page someone on failure.

That single split is usually the largest available improvement and it requires no new tooling.

The names varied — AGENTS.md, CLAUDE.md, .cursorrules, .github/copilot-instructions.md — and the format did not. It is prose. The model reads it. That is the whole protocol.

A convention that emerges independently in five products in one year is telling you something about the shape of the problem.

what actually belongs in it#

I have written and rewritten these a dozen times. The version that works is shorter than you think and more specific than you want.

Commands. The exact invocations. Not "run the tests" — the command, including the flags, including how to run one test file.

## commands
- install: `pnpm install --frozen-lockfile`
- test: `pnpm vitest run`
- test one file: `pnpm vitest run src/foo.test.ts`
- typecheck: `pnpm tsc --noEmit`
- lint: `pnpm biome check --write .`
- dev server: `pnpm dev` (port 5173)

This section alone eliminates most wasted agent turns. Without it, the agent guesses, guesses wrong, and spends four tool calls discovering your test runner.

Non-obvious structure. Where things live, when it is not inferable. "Database migrations are in db/migrations and must be created with pnpm db:new, never by hand." "The legacy/ directory is frozen — do not modify it."

Conventions that a linter does not enforce. If your linter catches it, do not write it down; the linter will tell the agent. Write down the things that are policy rather than syntax: "prefer composition over inheritance in src/domain", "all public functions in api/ need a docstring", "we do not use default exports".

Things that will break. "Do not run pnpm build — it takes 12 minutes and is not needed for tests." "The integration tests require Docker; skip them if it is not running." "Never modify schema.sql directly."

Boundaries. What the agent may not touch without asking. Production configs, migration files, anything with a security review requirement.

what does not belong#

Your entire architecture document. The agent reads this every session. A three-thousand-word essay costs tokens on every single request and dilutes attention across a lot of text that is irrelevant to most tasks.

Keep it under about 200 lines. If you need more, put it in a separate document and reference it: "for the event pipeline design, read docs/events.md before changing anything in src/events/."

Anything the code already says. Do not restate the type signatures. The agent can read.

Aspirations. "We value clean code" is not an instruction. "Functions over 40 lines get split" is.

Rules you do not actually follow. If the codebase contradicts the file, the codebase wins in the model's attention, and now your instructions are noise.

the part I did not expect#

Writing these has improved my documentation for humans.

The discipline of writing "here is exactly how to run the tests, here are the things that will surprise you, here is what not to touch" is precisely what a new engineer needs on day one, and it is precisely what most onboarding documents fail to contain because they were written by someone who already knew.

An agent is an infinitely patient new hire who will follow instructions literally and never ask a clarifying question out of politeness. That turns out to be an excellent test of whether your instructions are any good.

Several teams I know have merged their onboarding doc and their agent file into one. That is the correct end state.

the standardization question#

There is an ongoing effort to consolidate on AGENTS.md as the common name, with tools reading it as a fallback. That would be good and it is a coordination problem, which means it will take longer than it should.

In the meantime: write one file, symlink the rest. It costs nothing.

ln -s AGENTS.md CLAUDE.md

the model#

Strong across reasoning, multimodal understanding, and coding benchmarks. A "Deep Think" mode for the hardest problems. The million-token context window carries over.

The benchmark numbers are competitive at the frontier. At this point that sentence describes every major release, which is the actual news — the frontier is a cluster, not a leader.

What differentiates a release now is not the top-line capability. It is:

• Price per unit of capability, where Google's TPU position is a real structural advantage.
• Context handling at length, where Google has led for a while.
• Multimodal, where native training rather than adapters keeps paying off.
• Distribution, where shipping into Search on day one is something no competitor can do.

That last one deserves emphasis. Google put a new frontier model into the search product used by billions of people on launch day. The previous norm was a staged rollout over months. That is a capability nobody else has and it is the reason Google's position looks different than it did in 2023.

Antigravity#

An agent-first IDE — a VS Code derivative where the primary interaction is directing agents rather than editing text, with a manager surface for orchestrating multiple agents in parallel across editor, terminal, and browser.

The interesting design decision is artifacts: agents produce task lists, plans, screenshots, and browser recordings as reviewable outputs, rather than requiring you to read a raw transcript to figure out what happened.

That addresses the actual problem with delegated agents, which I have written about before: review is the bottleneck. A transcript of four hundred tool calls is not reviewable. A plan, a diff, and a recording of the browser test passing is.

Whether this specific implementation is good, I do not know yet — first releases of IDEs rarely are. The direction is right, and it is the first serious attempt I have seen at designing for review rather than for generation.

the bundling#

Model, IDE, CLI, cloud, and search distribution, from one vendor, priced aggressively.

This is the classic platform playbook and Google is executing it more coherently than they have on anything in a decade. The pieces reinforce each other: the IDE drives model usage, the model drives cloud usage, the cloud subsidizes the free tiers, and the search distribution provides the consumer volume that funds all of it.

The competitive question for everyone else is whether best-of-breed beats integrated. Historically it has, in developer tools, because developers choose their own tools and choose the best one. It has not, in enterprise procurement, where bundles win.

Both markets exist. The bundle is going to do well in one of them.

the practical advice#

Same as every model release, and I will keep repeating it because it keeps being the right answer:

Run your evals. Gemini 3 is likely better than what you are using on some dimensions and different on all of them. The migration cost is a day if you have an eval harness and a week of guessing if you do not.

Try Antigravity on a real task, not a demo task. Agent IDEs differ enormously in how they handle a twenty-minute task versus a two-minute one, and the demos are all two-minute tasks.

why linking matters#

For a large Rust binary, linking is frequently the dominant cost of an incremental build. You change one line, the compiler recompiles one crate quickly, and then the linker spends several seconds stitching together a hundred megabytes of object files and debug information.

GNU ld is old, single-threaded in the parts that matter, and was designed for a different era of binary sizes. lld is parallel, substantially faster, and has been production-ready for years — it is the default on several other platforms already.

Reported improvements vary by project, with the largest gains on debug builds of large dependency trees. Two to five times faster linking is a common range. If your edit-compile-run loop is four seconds and linking was two of them, you feel this every single time.

how to check#

cargo build --timings

Opens an HTML report showing where time went, including link time as a distinct phase. Most people have never looked at this and are surprised by what it says.

If you were already opting into lld or mold via .cargo/config.toml, nothing changes for you. If you were not — which is most people, because the configuration was obscure and required knowing it existed — you get the improvement for free on upgrade.

the general lesson#

Defaults are the most impactful thing a toolchain ships.

A faster linker has been available for years. Anyone could have configured it. The instructions were in a blog post. Almost nobody did, because it required knowing the option existed, knowing it was safe, and caring enough to edit a config file.

Changing the default delivers the improvement to everyone at once. That is worth more than a decade of documentation.

This generalizes. If you maintain a tool and you find yourself writing documentation explaining how to enable a better behavior, ask whether the better behavior should be the default. The answer is usually yes, and the reason it is not is usually caution about breaking a small number of unusual setups — which is a real concern that should be handled with a flag to opt out, not a flag to opt in.

the rest of 1.90#

• Cargo workspace publishing — cargo publish --workspace publishes multiple interdependent crates in the correct order. Anyone maintaining a multi-crate project has written a shell script for this. Now you can delete it.
• Demoted target tiers for several less-used platforms.
• x86_64-apple-darwin demoted to tier 2 with host tools still provided, which reflects where Apple hardware has actually gone.
• The usual const stabilizations and API additions.

the trend line#

Rust's reputation for slow compilation is the single most cited objection to adopting it, and it has been steadily addressed for years: incremental compilation, parallel front-end work, the new trait solver, better caching, and now the linker.

Compile times are meaningfully better than they were three years ago and still slower than Go. That gap is partly fundamental — monomorphization and the amount of optimization Rust does are not free — and partly still addressable.

Anyone who tried Rust in 2021 and bounced off the build times should try again. The numbers are different now.

the actual question#

Not "one repository or many." The question is:

Can you make a change that spans multiple components, atomically, with a single review and a single test run?

If yes, you have the property that matters. If no, you do not, regardless of how many repositories you have.

You can have one repository where every service has its own pipeline, its own version, and its own release train — and get none of the benefit, because a cross-cutting change still requires coordination. That is a polyrepo wearing a monorepo's directory structure.

You can have separate repositories with a workspace tool that checks them all out and builds them together, and get most of the benefit.

what atomicity buys#

Refactoring at scale becomes possible. Renaming a function used by twelve services is one commit. In a polyrepo it is twelve pull requests, a deprecation period, a compatibility shim, and a cleanup task nobody does. This is the single biggest difference and it compounds over years — polyrepo codebases accumulate interface debt because changing an interface is expensive.

One version of every dependency. No "service A is on library v2, service B is on v4, and the shared types are subtly incompatible." Upgrading is a single change that either passes CI everywhere or does not.

Discoverability. Grep works. Find-references works. A new engineer can read the whole system.

what it costs#

Tooling. Above a certain size, standard tools break. git status gets slow. Your IDE indexes forever. CI running everything on every commit becomes infeasible. You need build graph analysis to test only what changed. That is real infrastructure investment and it never ends.

Coupling by default. Shared code is easy, so shared code happens, and suddenly a change to a "utility" function affects nine teams. Polyrepo makes coupling expensive, which is a crude but effective forcing function.

Access control. One repository means one permission boundary, mostly. Fine for a company, not fine for open source with contractors.

Blast radius on the build system. Everyone depends on it. When it breaks, everyone stops.

the honest heuristic#

• Under ~50 engineers: monorepo, almost always. The tooling cost has not kicked in and the coordination benefit is immediate.
• 50 to 500: monorepo if you are willing to staff a build/platform team. If you are not, the tooling debt will eat you.
• Over 500: whatever you already have, improved. Migrating a large organization between these models is a multi-year project with a poor track record, and the energy is better spent on making the current arrangement work.
• Open source with external contributors: polyrepo, usually. The access control and contribution-scope arguments dominate.

the thing both sides get wrong#

Monorepo advocates point at Google and Meta. Those companies have hundreds of engineers working full-time on build infrastructure. You do not. Their approach is not transferable without their investment, and citing them is like citing an F1 team's pit strategy for your commute.

Polyrepo advocates point at microservice independence. Then they build a shared library, and a shared types package, and a shared client SDK, and now every service is coupled through three packages with independent release cycles and version skew — which is strictly worse than the coupling they were avoiding.

what to actually do#

Whichever you have, invest in the property you are missing.

In a monorepo: enforce boundaries. Ownership files, dependency rules that fail the build, and a rule that a module's public API is explicit. Physical colocation must not mean logical coupling.

In a polyrepo: invest in cross-repo change tooling. A script that opens coordinated pull requests. A dependency dashboard. A way to run integration tests across repositories before merge. This is unglamorous and it is the difference between a polyrepo that works and one that slowly ossifies.

The repository count is a detail. The workflow is the thing.

The free tier is the story. This is a competitive move priced at zero.

what it does#

The familiar shape: a terminal agent with filesystem access, shell execution, git awareness, and web search. It reads a GEMINI.md for project-specific instructions. It supports MCP servers for extending its tool set.

npx https://github.com/google-gemini/gemini-cli

Sign in with a Google account and you are running. No API key, no billing setup, no credit card.

why free#

Two reasons, both strategic.

TPU economics. Google serves its own models on its own silicon in its own datacenters. The marginal cost of inference is genuinely lower for them than for anyone renting Nvidia capacity, and they can afford a free tier that competitors cannot match without eating a loss.

Developer mindshare is a leading indicator. The developers who adopt a tool today choose the platform their company standardizes on in two years. Google has lost that fight repeatedly — to AWS in cloud, to OpenAI in AI APIs — and this is a deliberate attempt to not lose it again.

the open source part#

Apache 2.0 on the whole client. That means you can fork it, audit it, run it against a different model endpoint if you rewire it, and inspect exactly what it sends where.

That last one matters more than people acknowledge. A terminal agent has filesystem and shell access. "What does this thing actually transmit" is a question a security team will ask, and "here is the source" is a much better answer than a data processing addendum.

I expect the open-source-ness to be adopted as table stakes. It is very hard to argue for a closed terminal agent when a competitive one is Apache 2.0.

the current state of the category#

By my count there are now four credible terminal-based coding agents from major vendors, plus several from startups, plus a healthy open-source contingent. All shipped within about six months.

They are converging fast on the same feature set: filesystem tools, shell, project instruction files, MCP support, permission prompts, git integration. The differences that remain:

• Model quality on long-horizon tasks, which is the real one.
• Context handling — how they decide what to read and when to compact.
• Permission ergonomics — how annoying the safety prompts are, which sounds trivial and determines whether people turn them off.
• Price, where Google just set an aggressive anchor.

the practical advice#

Try more than one on the same task. They differ more in practice than the feature lists suggest, and the differences show up on tasks that take twenty minutes, not on tasks that take two.

And whichever you use: sandbox it. Container, VM, or at minimum a dedicated user account without your production credentials in its environment. The tooling is good. The failure modes are still real, and "the agent ran a command I did not read carefully" is a bad way to learn that.

what they actually built#

Cursor's technical differentiation is real and it is mostly not the model.

Codebase indexing that works. Semantic search over the whole repository, kept fresh, so the model gets relevant context without you selecting files. This is harder than it sounds at repository scale and it is where a lot of competitors are visibly worse.

Fast apply. A specialized model that takes a proposed edit and applies it to the existing file correctly. Sounds trivial. Is not. Getting a large model to reproduce an entire file with one changed function is slow and error-prone; a small model trained specifically on edit application is fast and reliable.

Tab completion that predicts your next action, including where you are about to move the cursor, not just what you are about to type.

All three are inference-layer engineering rather than model training, and all three are the kind of thing that is unglamorous to build and immediately obvious in daily use.

the bear case#

Cursor is a fork of VS Code, and VS Code is made by the company that owns GitHub Copilot, GitHub, and a large share of the developer's toolchain. Microsoft has been shipping the same features, more slowly, with better distribution and a bundled price.

Cursor also pays for inference on models it does not own, from vendors who are themselves building competing products. That is a structurally uncomfortable position: your primary cost is paid to your competitor, and your gross margin depends on their pricing decisions.

And the switching cost is approximately zero. It is an editor. Your settings sync in five minutes.

the bull case#

Distribution in developer tools is earned by being better, not by being bundled — which is why VS Code beat Atom, why Git beat SVN, and why every attempt to push a mandated IDE on a team has failed. Cursor is currently better at the specific thing developers do all day, and developers are unusually willing to switch tools and unusually vocal when they do.

The valuation implies the IDE becomes the control point for AI-assisted development — the place where context lives, where policy is enforced, where every model call routes through. If that is true, whoever owns it has a durable position regardless of which model wins.

my read#

The category is real and enormous. The specific defensibility is unclear. And the whole category has a structural problem that nobody has solved: as models get better at long-horizon delegated work, the editor becomes less central, because you are not editing. You are reviewing.

The product that wins the next phase might not be an editor at all. It might be whatever tool makes reviewing twelve agent-generated pull requests tolerable, and that looks a lot more like a code review interface than an IDE.

Nobody has built a good version of that yet. That is where I would be looking.

AI Mode in Search#

A tab in Google Search that runs a conversational, multi-step research flow instead of returning ten blue links. Rolling out broadly in the US.

This is the announcement with the largest downstream consequences and almost none of them are technical.

If a meaningful share of informational queries get answered in the results page, the traffic that funded the open web's content layer for twenty-five years goes away. Publishers have been shouting about this since AI Overviews launched and the shouting is going to get louder, because the data is going to get worse.

For developers specifically: your documentation site's traffic is going to fall, and the answers people get about your project will be synthesized from your docs by a model you do not control. The mitigations are unsatisfying — write docs that are hard to summarize badly, keep a changelog that is machine-readable, make sure your error messages contain enough context to be searchable — but the structural shift is not something an individual project can opt out of.

Veo 3#

Video generation with synchronized audio — dialogue, sound effects, ambience — generated together rather than dubbed on afterward. The quality jump is substantial and the audio integration is the part that makes it feel different.

Ethically this is the loudest thing at the conference and it got the least discussion time. SynthID watermarking is included, which is genuinely better than nothing and is not a solution, because watermarks survive exactly as long as nobody is motivated to remove them.

Jules#

An asynchronous coding agent. Clones your repo into a VM, works on a task, opens a pull request. Same shape as Codex and Copilot's agent mode. Everybody arrived at the same product within a month of each other, which tells you the capability threshold was crossed at roughly the same time for everyone.

Gemini 2.5 Deep Think#

An enhanced reasoning mode for 2.5 Pro that explores multiple hypotheses in parallel before answering. Aimed at the hardest math and coding problems.

The technique — parallel sampling with selection, rather than one longer chain — is a different axis of test-time compute than "think longer," and I suspect it generalizes better. A single long chain compounds its own errors. Multiple independent attempts do not.

Android XR#

A headset with Gemini integrated, plus glasses in development with Warby Parker and Gentle Monster as partners. Google has attempted this category twice and failed twice. The bet is that a genuinely useful assistant is the app that makes the form factor worth wearing.

Possible. The failure mode for the last decade has been that the hardware was uncomfortable and the software was a solution looking for a problem. This addresses the second one.

the throughline#

Google's problem for the last two years was never capability. It was that OpenAI had the mindshare and Google had the users but was afraid to touch them.

This was the conference where they stopped being afraid. Whether that is good for the web is a separate question, and the answer is probably no.

WSL is open source#

The Windows Subsystem for Linux is now open source at github.com/microsoft/WSL. Not all of it — some Windows-side components remain closed — but the substantial majority, including the init system, the networking daemons, and the file sharing layer.

This was the single most requested item on the WSL issue tracker for years. The practical effect is that people can finally debug the parts of WSL that go wrong, which historically meant filing an issue and waiting.

The strategic read: WSL won. It is how a very large number of developers run Linux tooling on a Windows machine, it removed most of the reason to dual-boot, and open-sourcing it costs Microsoft nothing now that the position is secure. It is a mature move from a company that spent the nineties doing the opposite.

GitHub Copilot coding agent#

Copilot gets a delegated mode: assign an issue to it, and it opens a pull request. It runs in GitHub Actions, follows repository instructions in .github/copilot-instructions.md, and its pull requests go through normal review and CI.

Notably it cannot approve its own pull requests and its Actions runs require approval. Those are the correct guardrails and it is good that they shipped with them rather than after an incident.

The integration point is the interesting bit. An agent that operates on issues and pull requests slots into a workflow every team already has, rather than requiring a new one. That is a much lower adoption barrier than "install this IDE."

MCP in Windows#

Windows gets native support for the Model Context Protocol: an MCP registry, built-in servers exposing filesystem, windowing, and shell capabilities, and a permission model gating what an agent can reach.

An operating system vendor adopting a protocol that a model company published six months ago is fast by any standard. It also tells you Microsoft has concluded that the agent-to-system interface is going to be standardized and would rather be the platform for it than fight it.

The security model is where this gets interesting and where I would like to see more detail. An OS-level MCP surface means any agent with the right permission can drive the machine. The consent flow, the scoping granularity, and the audit trail are the whole ballgame, and "there is a permission model" is not yet enough information to evaluate it.

also announced#

NLWeb, a project to let websites expose a natural-language query interface with MCP underneath. Positioned as "HTML for the agentic web." Ambitious; adoption is everything and adoption is unknowable.

Edit, a new command-line text editor for Windows, open source, small. A genuine gap — Windows has had no default CLI editor since edit.com — and filling it is a nice piece of housekeeping.

Windows AI Foundry, the rebranded local model runtime story, with Foundry Local for running models on-device.

the pattern#

Microsoft's developer strategy for a decade has been: meet developers where they are, adopt other people's standards, open-source the layers where control is not worth the friction, and monetize the cloud underneath.

It keeps working. Build 2025 was more of it, executed well.

This is a different product shape from the coding assistants we have been using, and the difference is worth being precise about.

the three shapes#

Completion. The model suggests the next few lines as you type. Copilot's original form. Latency budget: milliseconds. You stay in control of everything.

Conversational. You describe a change, the model proposes an edit, you accept or reject. Latency budget: seconds. You review each step.

Delegated. You describe a task, close the tab, and come back to a pull request. Latency budget: minutes to tens of minutes. You review the result, not the process.

Codex is firmly the third. So is Claude Code in its non-interactive mode, so is Devin, and so is what GitHub is building into Copilot. This is where the category is going.

why the shape matters#

Delegated agents change the unit of work from "edit" to "task," and that changes everything downstream:

• You cannot course-correct mid-flight. If the agent misunderstood the task, you find out after twenty minutes of work. That makes the task description vastly more important than a prompt in a chat.
• Parallelism becomes free. Five tasks running at once is the same wall-clock as one. That is a genuine multiplier and it is the actual value proposition.
• Review becomes the bottleneck. If an agent produces five pull requests an hour and you can meaningfully review two, you have not multiplied throughput. You have created a queue.

That last point is where I think most teams are going to struggle. The constraint on software delivery in most organizations was never typing speed. It was understanding, coordination, and review. Delegated agents attack the part that was not the bottleneck.

the sandbox is the good part#

Codex runs in a container with no network access during execution — dependencies are preloaded, then the network is cut. That is a meaningful security design and more products should copy it.

The threat model: an agent that can read your repository and reach the internet can exfiltrate your repository. It does not have to be malicious; a prompt injection in a dependency's README is enough. Cutting network access after setup eliminates a whole class of attack for the cost of some inconvenience.

the practical guidance#

For delegated agents to be worth it, you need:

1. Tasks with clear acceptance criteria. "Fix the flaky test in test_payments.py::test_retry" works. "Improve the payment system" does not.
2. A test suite that actually gates. The agent's self-verification is only as good as your tests. If your tests pass on broken code, you will get broken code that passes tests.
3. A review culture that has not been eroded. See above. This is the hard part and it is organizational, not technical.

Start with the tasks you have been putting off: dependency upgrades, test coverage on a neglected module, migrating a deprecated API call across a hundred files. Mechanical, verifiable, tedious. That is where this technology is already clearly worth it, today, without any argument about whether it will replace anyone.

That is the moment a protocol stops being a vendor's format and starts being infrastructure.

what MCP is, briefly#

A protocol for connecting language models to external context and tools. A server exposes three primitive types:

• Resources — data the model can read (files, database rows, API responses).
• Tools — functions the model can call, with JSON Schema parameters.
• Prompts — reusable templates the user can invoke.

The transport is JSON-RPC 2.0 over stdio for local servers or HTTP with server-sent events for remote ones. That is deliberately unexciting; the value is in the shape of the interface, not the wire format.

{
  "jsonrpc": "2.0", "id": 3, "method": "tools/call",
  "params": {
    "name": "query_db",
    "arguments": { "sql": "select count(*) from orders where day = '2025-03-25'" }
  }
}

why this mattered enough to win#

The problem MCP solves is combinatorial. Before it, connecting M AI clients to N data sources meant M × N bespoke integrations, each one a slightly different function-calling schema with slightly different auth. Every new assistant had to rebuild every connector.

MCP makes it M + N. Write one server for your internal ticketing system and every MCP-speaking client can use it. That is the same argument that won for LSP in editors, and it won for the same reason: the integration burden was crushing the ecosystem and everyone knew it.

The LSP comparison is not incidental — MCP's designers cite it explicitly, and the JSON-RPC choice is a direct inheritance.

the security part, which is underdiscussed#

An MCP server is a program you run that a model can invoke. That is a substantially larger attack surface than it appears.

• Prompt injection through resources. If a server returns content from an untrusted source, that content is now in the model's context and can attempt to influence tool calls. This is the central unsolved problem of the entire agent category and MCP does not fix it.
• Tool description poisoning. The tool descriptions themselves go into the model's context. A malicious server can write a description that manipulates behavior.
• Over-broad servers. A filesystem server with root access is a filesystem server with root access. The convenience of "just point it at my home directory" is how this goes wrong.

Practical guidance while the ecosystem matures: run servers with the narrowest possible scope, treat any server you did not write as untrusted code, and do not combine a server that reads untrusted content with a server that can take destructive action in the same session. That last one is the composition hazard and it is easy to walk into.

what happens next#

Expect: an official governance structure, a registry, and a fight about authorization semantics. Expect every developer tool company to ship a server within a quarter. Expect at least one significant security incident involving a popular community server, because that is what happens to every successful plugin ecosystem, without exception.

Standards win when the alternative is worse for everyone including the people who would prefer to own the standard. That happened here, unusually fast.

Here is the short list. Not the complete list — the list where each item changes how you work.

1. git rebase -i#

The one that matters most. Interactive rebase lets you rewrite your local history before anyone sees it: squash the four "fix typo" commits, reorder, split a commit that did two things, reword a message you wrote badly at 6 p.m.

git rebase -i main   # everything since you branched

The rule that makes this safe: rewrite history that only exists on your machine or your own branch. Never rewrite a shared branch. That is the entire safety model and it is not complicated.

2. git add -p#

Stage hunks instead of files. This changes how you commit, because it removes the excuse for the giant mixed commit. You made an unrelated fix while working? Stage it separately, commit it separately.

y to stage, n to skip, s to split the hunk smaller, e to edit it by hand.

3. git log -S#

Search history by code, not by message. "When did this string get introduced?" "Who deleted this function?"

git log -S "retryPolicy" --oneline
git log -S "retryPolicy" -p -- src/http.ts    # with diffs

This is the single fastest way to answer "why is this here," and it beats git blame because blame only shows you the last change to a line.

4. git bisect#

Binary search for the commit that broke something. It feels like a niche tool until the first time it saves you a day.

git bisect start
git bisect bad                 # current is broken
git bisect good v2.3.0         # this was fine
# git checks out a midpoint; test it; say good or bad
git bisect run ./test.sh       # or automate it entirely

That last form is the good one. Give it a script that exits nonzero on failure and it finds the culprit unattended.

5. git reflog#

The undo button for everything. Every position HEAD has occupied for the last ninety days, including states unreachable from any branch.

git reflog
git reset --hard HEAD@{4}

Deleted a branch, botched a rebase, hard-reset over uncommitted work you meant to keep? Reflog. The number of people who have re-cloned a repository over something reflog would have fixed in ten seconds is very large.

6. git worktree#

Multiple branches checked out simultaneously in different directories, sharing one object store.

git worktree add ../myrepo-hotfix hotfix/urgent

No stashing, no switching, no rebuilding your entire dependency tree because you had to jump to a different branch for one review. This has become dramatically more useful in the age of coding agents, where you may want two working copies being edited at once.

7. git rerere#

"Reuse recorded resolution." Turn it on once and git remembers how you resolved a given conflict, then replays that resolution automatically the next time the same conflict appears.

git config --global rerere.enabled true

If you maintain a long-lived branch that rebases repeatedly, this saves you from resolving the same three conflicts every single time.

8. git commit --fixup and --autosquash#

Found a problem in an earlier commit on your branch? Do not amend it out of order and do not write "fix review comment."

git commit --fixup=a1b2c3d
git rebase -i --autosquash main   # squashes it into a1b2c3d automatically

the meta-lesson#

Git's model is small: commits are immutable snapshots, branches are pointers, everything is content-addressed. The porcelain is inconsistent and the error messages are famously unhelpful, but the underlying model is simple enough to hold in your head completely.

Spend an afternoon learning the model rather than memorizing commands, and every one of the above becomes obvious rather than magic.

the model#

3.7 Sonnet is a hybrid reasoning model: one model that can answer immediately or think first, with the thinking budget controllable via the API. That is a different product shape from having a separate reasoning model, and it is the right one — the routing decision belongs to the caller, who knows whether this particular request is worth the latency.

The API exposes a token budget for extended thinking. You set it per request:

message = client.messages.create(
    model="claude-3-7-sonnet-20250219",
    max_tokens=8000,
    thinking={"type": "enabled", "budget_tokens": 4000},
    messages=[{"role": "user", "content": "..."}],
)

The coding numbers are strong, particularly on agentic software engineering benchmarks where a model has to navigate a real repository rather than complete a function in isolation. That distinction is the one that matters for actual work and it is the one most benchmark discourse ignores.

the terminal thing#

Claude Code is more interesting than the model, because it is a bet on a particular shape of tool that runs against the industry's current instinct.

Everyone else is putting the agent in the IDE. Anthropic put it in the terminal, with direct filesystem access, the ability to run commands, and git integration. No editor plugin, no separate UI, no sidebar.

The argument for the terminal is that it is the lowest common denominator that already has everything: your shell history, your credentials, your build tools, your test runner, your deployment scripts. An agent in the terminal inherits your entire working environment for free. An agent in an IDE inherits the IDE's model of your project, which is always partial.

The argument against is that terminals are a bad UI for reviewing a multi-file diff, and a bad UI for anything requiring a mental model of parallel state.

Both are correct. My guess is the terminal wins for the "do this task" workflow and the IDE wins for the "help me while I work" workflow, and in two years both exist and nobody thinks this was ever a debate.

the part to be careful about#

An agent with shell access on your development machine is a genuinely different security posture than an autocomplete. It can rm. It can curl | sh. It can commit and push.

The mitigations that matter, in order:

1. Run it in a container or VM for anything you did not write.
2. Do not give it credentials it does not need. Especially not production ones.
3. Read the diff before you commit. Every time. The moment you stop reading diffs is the moment the tool becomes a liability.

That third one is the hard one, because the whole value proposition is not having to. The discipline that keeps this useful is treating agent output exactly like a pull request from a fast, capable, slightly overconfident junior engineer: worth reviewing, usually right, occasionally catastrophically wrong in a way that looks fine.

Call it T. If T is two minutes, your team behaves one way. If T is thirty minutes, it behaves completely differently, and the difference is not "things take twenty-eight minutes longer."

what actually happens as T grows#

Below ~2 minutes, you wait. You keep the change in your head, you see the result, you fix it. The loop is tight enough that debugging is interactive.

Between 2 and 10 minutes, you context switch. You go read something else. When the result comes back you have to page the change back in. The reload cost is real and it is roughly proportional to how complex the change was — which means it is worst exactly when you can least afford it.

Past 10 minutes, behavior changes qualitatively. People start batching. They stop pushing small commits because the feedback is too expensive per commit, so they push bigger ones, which are harder to review and more likely to fail, which makes each failure more expensive to diagnose. It is a doom loop and it is entirely emergent from one number.

Past 30 minutes, people route around CI. They test locally in ways that diverge from CI, they merge on green-ish, they add [skip ci], and eventually somebody proposes a nightly build as the "real" signal, at which point you have given up.

the diagnostic#

Before optimizing, measure the right thing. Not average pipeline duration — p90 time-to-signal for the check that actually blocks merge. Most teams measure the wrong thing here and optimize a stage nobody was waiting on.

Then break it down:

queue wait      ← runners are saturated or your concurrency limit is wrong
checkout        ← you're doing a full clone of a repo with 200k commits
dependency install ← almost always the biggest fixable chunk
build           ← is anything cached? really?
test            ← is it parallel? is it parallel *well*?

the fixes, roughly in order of return#

1. Cache dependencies properly. Not "we have a cache step." Verify the hit rate. A cache that misses on every branch because the key includes the branch name is worse than no cache, because it also uploads.
2. Shallow clone. fetch-depth: 1 unless you genuinely need history. If you need history for one job, do it in one job.
3. Split the blocking check from the exhaustive check. Lint, typecheck, and unit tests block merge. Integration, e2e, and the full matrix run after, and page someone if they fail. Not everything needs to gate.
4. Parallelize by timing, not by file count. Splitting tests evenly by count gives you one shard that takes four times as long as the others. Split by historical duration.
5. Kill the flaky tests. A test that fails 2% of the time in a suite of 50 parallel jobs means your pipeline fails constantly. Quarantine them the day they are identified. A quarantined test is a bug ticket; a flaky test in the blocking path is a tax on everyone forever.
6. Bigger runners. This is the least intellectually satisfying fix and often the best one. Engineer time costs more than compute. Do the arithmetic before you spend a sprint on a clever solution.

the cultural part#

Someone has to own T. Not "the platform team should look at CI sometime." A named person, a dashboard, and a number that goes in the same review as uptime.

Because the alternative is that it degrades a little every sprint — one more test, one more dependency, one more required check — and nobody notices until it is thirty minutes and everybody has quietly stopped trusting it.

what's new#

A built-in S3 client. Bun.s3 gives you presigned URLs, streaming reads and writes, and it works against any S3-compatible endpoint — R2, MinIO, Backblaze, the actual thing.

import { s3 } from "bun";

const file = s3.file("uploads/report.pdf");
await file.write(pdfBytes, { type: "application/pdf" });
const url = file.presign({ expiresIn: 3600 });

A built-in Postgres client. Bun.sql is a tagged-template SQL interface with connection pooling, prepared statements, and parameter binding that does not require you to think about $1 ordering.

import { sql } from "bun";
const users = await sql`select * from users where team = ${teamId} limit 20`;

Node compatibility as a first-class metric. Bun now publishes its pass rate against Node's own test suite and treats regressions as bugs. That is a much more honest signal than a feature checklist, and the number went up substantially in this cycle.

Text-based lockfile. bun.lock replaces the binary bun.lockb as the default. Reviewable in a pull request, diffable, mergeable. This was the single most common complaint about adopting Bun in a team setting and it is now gone.

the strategic read#

Node's answer to the same problem has been to add capabilities to the runtime incrementally and carefully: a built-in test runner, --watch, a permission model, and now stable-ish TypeScript stripping. Deno's answer was to bundle everything from the start and then spend years walking back the parts of its opinionated design that made adoption hard.

Bun's answer is to bundle everything and be compatible with Node's ecosystem rather than replacing it. That is a harder engineering problem and a much easier sales problem. Nobody has to rewrite anything. You point bun at an existing Express app and it mostly runs.

the honest caveats#

Bun's ecosystem edge cases still bite. Native modules that assume V8 internals will not work, because Bun is JavaScriptCore. Some observability agents assume Node. Long-tail packages that reach into process.binding or undocumented internals will surprise you.

The pattern for adoption in 2025 looks like: use Bun as the package manager and test runner immediately, because those are drop-in and dramatically faster; use the runtime in production when your dependency tree is one you actually understand.

That is not a hedge. That is just what shipping looks like.