Staying Current in AI Engineering Without Drowning in Hype
A sustainable system for keeping up with AI engineering: what to follow, how to test new models with your own evals, how to adopt changes safely, and what stays stable.
On this page· What changes and what does not
Why this matters
AI tooling changes monthly: new models, new API features, new frameworks, and a constant stream of announcements claiming everything is now different. Trying to follow all of it leads to anxiety and shallow knowledge. Ignoring it means missing real improvements, like a model that halves your costs. The goal is a system: a few trusted sources, a habit of small experiments, and a safe process for adopting changes, measured with your own evals rather than headlines.
What changes and what does not#
Most of what makes a good AI engineer changes slowly. Invest most of your learning there.
| Changes fast (track it lightly) | Changes slowly (invest deeply) |
|---|---|
| Model names, prices, and benchmark rankings | Software engineering: types, testing, APIs, databases |
| API parameters and new features | Retrieval fundamentals: chunking, search, ranking |
| Frameworks and wrappers | Evaluation: datasets, graders, measuring quality |
| Prompting tricks | Clear instructions and good context |
| Agent frameworks | The agent loop, tools, permissions, human oversight |
| Reliability, security, cost, and observability |
When something new appears, ask: which slow-changing problem does it solve better? A new vector database is retrieval; a new agent framework is the agent loop. You already know how to judge it.
Sources worth following#
Prefer primary sources over commentary:
- Official documentation, release notes, and changelogs of the APIs and SDKs you use. Watch the SDK repositories' releases on GitHub.
- Model and deprecation pages of your providers, so retirements never surprise you.
- Engineering blogs from the teams building the models and tools: they explain why features exist and how to use them well.
- A few practitioners who publish evidence (code, numbers, evals), not just opinions.
- Papers, selectively: read the abstract and results of work that touches your problems; skip the rest.
Set a budget: for example, 30 minutes twice a week for reading, and one hour every two weeks for a hands-on experiment.
Experiments over opinions#
Reading tells you what is possible; experiments tell you what works for your use case. Keep a small "lab" repository with your eval cases and a script to compare configurations. When a new model or feature arrives, run it on your cases before forming an opinion.
You can even let code tell you when there is something to look at. This script lists the models your API key can access and flags anything you have not reviewed yet, as well as configured models that are no longer listed:
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();
// Models your app uses, and models you have already evaluated and decided about.
const IN_USE = ["claude-opus-5-5", "claude-sonnet-5-5", "claude-haiku-4-5"];
const REVIEWED = new Set([...IN_USE, "claude-fable-5-1"]);
const available: { id: string; name: string; created: string }[] = [];
for await (const model of client.models.list()) {
available.push({ id: model.id, name: model.display_name, created: model.created_at.slice(0, 10) });
}
const ids = new Set(available.map((m) => m.id));
const fresh = available.filter((m) => !REVIEWED.has(m.id));
const missing = IN_USE.filter((id) => !ids.has(id) && !available.some((m) => m.id.startsWith(`${id}-`)));
for (const m of fresh) console.log(`NEW ${m.id} (${m.name}, ${m.created}): run your evals on it`);
for (const id of missing) console.log(`MISSING ${id}: check the deprecation schedule and plan a migration`);
if (!fresh.length && !missing.length) console.log("Nothing new. Your model list is current.");Run it weekly in CI, or as a scheduled job that posts to your team chat.
Adopting a new model safely#
Hover or tap a component to see what it does.
Show text descriptionHide text description
Staying current is a process, not a news feed. This is the process for the most common change: a new model.
- New release: Read what changed: new capabilities, removed parameters, pricing, deprecation dates.
- Run evals: Your eval suite on the new model, unchanged. Your data beats any public benchmark.
- Compare: A small table: pass rate, p95 latency, cost per task. Decide with numbers.
- Canary: Route a small share of real traffic to the new model and watch errors, feedback, and cost.
- Promote: Make it the default, keep the old model as a fallback for a while, and record the decision.
The process for the most common change, a new model:
- Read the release notes and migration guide. New models sometimes remove parameters, change defaults, or behave differently with old prompts.
- Run your evals unchanged, then with prompt adjustments if the notes recommend them.
- Compare quality, latency, and cost on your cases, not on public benchmarks.
- Canary: send a small share of real traffic to the new model and watch errors, feedback, and cost.
- Promote or roll back, and write down why.
The comparison step is easy to automate. Given two eval runs in the format from the evals article, this function reports the overall change and every case that regressed:
export interface CaseResult {
id: string;
passRate: number;
tokens: number;
}
export interface Run {
version: string;
overall: number;
results: CaseResult[];
}
export interface Comparison {
overallDelta: number;
tokenRatio: number;
regressions: { id: string; before: number; after: number }[];
improvements: { id: string; before: number; after: number }[];
verdict: "adopt" | "investigate" | "reject";
}
export function compareRuns(baseline: Run, candidate: Run, threshold = 0.34): Comparison {
const before = new Map(baseline.results.map((r) => [r.id, r.passRate]));
const regressions: Comparison["regressions"] = [];
const improvements: Comparison["improvements"] = [];
for (const r of candidate.results) {
const b = before.get(r.id);
if (b === undefined) continue;
if (b - r.passRate >= threshold) regressions.push({ id: r.id, before: b, after: r.passRate });
if (r.passRate - b >= threshold) improvements.push({ id: r.id, before: b, after: r.passRate });
}
const tokens = (run: Run) => run.results.reduce((s, r) => s + r.tokens, 0);
const overallDelta = candidate.overall - baseline.overall;
const verdict = regressions.length === 0 && overallDelta >= 0 ? "adopt" : overallDelta < -0.05 ? "reject" : "investigate";
return { overallDelta, tokenRatio: tokens(candidate) / Math.max(1, tokens(baseline)), regressions, improvements, verdict };
}import { test } from "node:test";
import assert from "node:assert/strict";
import { compareRuns, type Run } from "./lib/compare-runs.ts";
const run = (version: string, rates: Record<string, number>, tokens = 1000): Run => {
const results = Object.entries(rates).map(([id, passRate]) => ({ id, passRate, tokens }));
return { version, overall: results.reduce((s, r) => s + r.passRate, 0) / results.length, results };
};
test("adopts a candidate that is better everywhere", () => {
const c = compareRuns(run("old", { a: 0.33, b: 1 }), run("new", { a: 1, b: 1 }, 800));
assert.equal(c.verdict, "adopt");
assert.equal(c.improvements[0]?.id, "a");
assert.equal(c.tokenRatio, 0.8);
});
test("investigates when one case regresses even if the average improves", () => {
const c = compareRuns(run("old", { a: 1, b: 0.33, d: 0.33 }), run("new", { a: 0.33, b: 1, d: 1 }));
assert.equal(c.verdict, "investigate");
assert.deepEqual(c.regressions.map((r) => r.id), ["a"]);
});
test("rejects a clearly worse candidate", () => {
assert.equal(compareRuns(run("old", { a: 1, b: 1 }), run("new", { a: 0.33, b: 0.67 })).verdict, "reject");
});A regression on one important case can matter more than a better average: that is why the verdict is "investigate", not "adopt", when anything got worse.
Learning habits that compound#
- Build small things often. A one-evening experiment with a new feature teaches more than a week of reading about it.
- Keep a lab notebook: date, what you tried, the numbers, the conclusion. It becomes material for writing about your work.
- Teach what you learn in a short post or a talk to your team; it exposes gaps in your understanding.
- Revisit fundamentals yearly. Reread this wiki's foundations and production sections; you will see them differently with more experience.
Common mistakes#
- Chasing every announcement. Most changes do not affect your product. Filter by the problems you have.
- Switching models based on public benchmarks. Your evals are the only benchmark that matters for your product.
- Rewriting on every new framework. Adopt tools that solve a problem you have measured.
- Missing deprecations. Track retirement dates for every model you use.
- Neglecting fundamentals. The engineers who adapt fastest have strong foundations.
Try it
Set up your system
- Pick three primary sources and schedule two 30-minute reading slots per week.
- Run
check-models.tsagainst your account and record which models you have evaluated. - Run your eval suite on two models, compare them with
compareRuns, and write a five-line decision note.
Check your understanding
Key takeaways
- Invest deeply in slow-changing skills; track fast-changing details lightly.
- Follow a few primary sources on a schedule, and prefer experiments to opinions.
- Detect new and missing models automatically, and adopt new models through evals, comparison, and canaries.
- Build small things often and write down what you learn.
Next steps#
Finished this article? Track it to see your progress on the roadmap.
Related articles
- LLM Evals in TypeScript: Datasets, Graders, LLM-as-Judge, and CIBuild an eval suite for an LLM feature: real-case datasets, code graders, a calibrated LLM judge, repeated trials, baseline comparison, and a CI gate in TypeScript.
- Choosing LLMs and Providers: Capability vs Cost vs LatencyHow to pick an LLM per feature by capability, cost, and latency: the current Claude lineup, effort levels, routing, and a harness to benchmark your own tasks.
- An AI Engineer Portfolio That Gets InterviewsBuild a portfolio for AI full-stack roles: which projects to show, how to write a README hiring managers read, how to prove quality with numbers, and how to share it.