Skip to content
AI Full-Stack Wiki

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.

Difficulty: Beginner12 min readUpdated
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 rankingsSoftware engineering: types, testing, APIs, databases
API parameters and new featuresRetrieval fundamentals: chunking, search, ranking
Frameworks and wrappersEvaluation: datasets, graders, measuring quality
Prompting tricksClear instructions and good context
Agent frameworksThe 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:

check-models.ts
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#

Adopting a new model safelyWhen a new model is released, read the release notes and migration guide, run your eval suite against it, compare quality, latency, and cost with your current model, roll it out to a small share of traffic, and promote it only if production metrics hold.bettermetrics holdNew releasenotes, migrationRun evalsyour casesComparequality, latency, costCanary5% of trafficPromoteor roll back

Hover or tap a component to see what it does.

Adopting a new model safely: read the release notes, run your evals, compare quality, latency, and cost, canary on a small share of traffic, then promote or roll back.
Show 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:

  1. Read the release notes and migration guide. New models sometimes remove parameters, change defaults, or behave differently with old prompts.
  2. Run your evals unchanged, then with prompt adjustments if the notes recommend them.
  3. Compare quality, latency, and cost on your cases, not on public benchmarks.
  4. Canary: send a small share of real traffic to the new model and watch errors, feedback, and cost.
  5. 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:

lib/compare-runs.ts
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 };
}
compare-runs.test.ts
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

  1. Pick three primary sources and schedule two 30-minute reading slots per week.
  2. Run check-models.ts against your account and record which models you have evaluated.
  3. Run your eval suite on two models, compare them with compareRuns, and write a five-line decision note.

Check your understanding

What should decide whether you switch to a new model?
Which skill changes most slowly and deserves deep investment?
Why canary a new model on a small share of traffic?

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.