"Learn AI." "Get comfortable with the cloud." "Master the fundamentals." Every skills-for-next-year list runs on the same three, and none of them is a skill. They're categories. You cannot practise a category on Tuesday and be measurably better at it by Friday, which is the only test that matters for advice about what to learn.
A skill has a failure mode you can name, a way to notice you're bad at it, and a drill. "Learn AI" has none of those — it's the career-advice equivalent of telling someone to get good at computers. So here are six that pass the test, each with the specific thing that goes wrong when you don't have it.
If somebody tells you to "learn AI" and stops there, ask them which part. Fine-tuning a model, writing an eval harness, reviewing generated diffs, and designing a retrieval index are four unrelated jobs that share a marketing term. The advice is popular precisely because it's unfalsifiable — nobody can tell you you've failed at it.
Reading generated code adversarially
The single most valuable habit right now is treating model output like a pull request from a stranger who is extremely confident and has never seen production.
The evidence that this is the bottleneck is unusually clean. In the 2025 Stack Overflow Developer Survey, the top AI-related frustration — cited by 66% of respondents — was "AI solutions that are almost right, but not quite," and 45% said debugging AI-generated code takes more time than writing it themselves. More developers actively distrusted AI accuracy (46%) than trusted it (33%).
"Almost right" is the important half. Models fail in a specific shape: the structure is correct, the library choice is sensible, the naming is better than yours, and the boundary condition is wrong. That's the worst possible failure profile for a human reviewer, because everything your eye uses to judge quality at a glance is exactly what the model is best at.
So the drill is to stop reading generated code top-to-bottom for correctness and start reading it for absence. Concretely, four things worth checking on every generated diff:
- Boundary conditions the prompt didn't mention. Empty list, single element, exactly-at-the-limit. These are where the training data thins out and the model interpolates.
- Error paths that swallow. A
catchthat logs and continues is the most common thing a model adds unprompted, and it converts a loud failure into a silent one. - Retries on non-idempotent operations. Ask for "add retry logic" and you will frequently get a loop wrapped around a POST that charges a card.
- Methods that don't exist. Still happens, still passes review when the name is plausible enough (
.findOneOrFail(),.toSorted()on the wrong type).
METR ran a randomized controlled trial in early 2025 with experienced open-source developers on their own mature repositories. Developers using AI tools were 19% slower — and estimated afterwards that they'd been 20% faster. METR itself now flags the result as historical and not necessarily representative of current tooling, which is fair. The finding that survived is the gap between the two numbers, not the sign of the first one: your sense of your own speed while using these tools is not a measurement.
Writing code that a machine can work on without asking questions
This one is new enough that it still sounds like a joke, and it isn't. A meaningful share of the edits to your codebase now originate from something that cannot ask a follow-up question, cannot read the Slack thread, and will not admit confusion. It will just guess, confidently, and open a PR.
That changes what "readable" means. Readable-for-humans tolerates ambiguity because humans resolve it by asking. Readable-for-agents does not, because the resolution step is a silent guess.
The practical differences are small and boring:
- Names that don't lie about side effects. A function called
getUserthat also writes an audit row will get called inside a loop. A human would have noticed the surprise; an agent reads the name and believes it. - Types that narrow.
stringfor an ID tells a model nothing. A branded type or a discriminated union removes an entire category of guess. - Files small enough to be read whole. Not for elegance — for the mundane reason that partial context produces confident local edits that break invariants defined 800 lines away.
- One convention per problem, grep-able. If half the codebase uses one error-handling pattern and half uses another, the model will pick by proximity, and you get both forever.
There's now a standard place to write down the parts that aren't inferable from the code. AGENTS.md was published in August 2025 as a joint format from OpenAI, Google, Cursor, Factory and Sourcegraph; by December 2025 it was in more than 60,000 repositories and supported by 20-plus tools, and it became one of three founding projects of the Agentic AI Foundation alongside MCP. Whether that specific filename wins long-term is not the point — the skill is knowing which of your project's rules live in someone's head and writing them down.
Knowing what one more request actually costs
Ask a team what it costs to serve one more request and you usually get a shrug and a monthly total. That gap is where architecture decisions get made on vibes.
The number that most often surprises people is a NAT Gateway. In us-east-1 it's $0.045 per hour, which nobody notices, plus $0.045 per GB of data processed, which is charged on traffic that has already been billed as transfer. Pull container images from a public registry through a private subnet, or ship logs to a third party, and you are paying a per-gigabyte tax on your own egress that appears nowhere in any architecture diagram.
The point isn't NAT Gateways specifically. It's that most stacks have one or two line items with this shape — metered per unit of a thing you do constantly, invisible at design time — and knowing yours changes real decisions.
37signals is the most-cited case here and worth reading carefully rather than as a slogan. Their cloud spend went from $3.2M to $1.3M a year after moving off, roughly $2M annually, and they bought 18PB of Pure Storage for about $1.5M against operating costs of under $200k a year to replace S3 — projecting past $10M in savings over five years. What makes it useful evidence is that they had the per-unit numbers first. Repatriation isn't the lesson; the lesson is that they could do the arithmetic at all, which is what let them notice their workload was a bad fit for a model priced around elasticity they never used.
If you can't state your cost per thousand requests, per GB stored, and per GB egressed within an order of magnitude, you're not choosing an architecture. You're choosing an aesthetic.
Reading the spec instead of the summary of the summary
Spec literacy was always a differentiator. It got sharply more valuable in the last two years, for a slightly perverse reason: when you ask a model a protocol question, you get something like a weighted average of every blog post ever written about it — including the majority that were wrong in the same direction.
The canonical example is HTTP caching. Almost everyone believes Cache-Control: no-cache means "don't cache this." It doesn't. RFC 9111 §5.2.2.4 says a no-cache response "MUST NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response" — store it, but revalidate every time. The directive that means don't store it is no-store, in §5.2.2.5. That misconception is old, widespread, and thoroughly represented in training data, which is exactly why asking rather than reading is unreliable here.
A second one, cheaper to check and just as commonly fumbled: Semantic Versioning clause 4 says major version zero is for initial development and "anything MAY change at any time." Package managers encode that exemption, so ^1.2.3 and ^0.2.3 do not mean the same thing — the second only accepts 0.2.x, because in 0.x the minor position is treated as breaking. Plenty of teams pin ^0.x dependencies believing they've allowed compatible updates and are surprised either way. (Our semver version calculator will show you the resolved range if you want to check a specific one without reasoning about it.)
The drill is small: next time you're about to search for how a header or format behaves, open the RFC's index and read the two paragraphs instead. They are usually shorter than the blog post, and they are the thing the blog post was summarizing.
Debugging one layer below your application
There is a whole class of bug that produces zero application-level evidence, and the instinct that serves you well everywhere else — add more logging — actively wastes time on it.
Two examples that show up constantly in container-shaped systems:
Exit code 137. Your logs end mid-sentence, there's no stack trace, no error, no exception handler fired. That's because nothing in your process was involved: the kernel OOM killer sent SIGKILL, which cannot be caught. The evidence lives in the cgroup memory limit and the pod's lastState, not in your app. The reason people burn hours here is that "no error in the logs" reads as "the logs are broken" rather than "the process was executed."
The Kubernetes ndots tax. Pods default to ndots:5 in /etc/resolv.conf, meaning any hostname with fewer than five dots is tried against the cluster's search domains first. So api.stripe.com — three dots — generates four guaranteed-NXDOMAIN lookups before the real query goes out. It's deliberate, it makes internal short names work, and it's invisible in application traces because your HTTP client reports the whole connect phase as one number.
# what the resolver actually does with your hostname
dig +search +trace api.stripe.com
# what it does when you tell it the name is already complete
dig api.stripe.com.
That trailing dot is the fix, incidentally — a fully qualified name has an implicit empty root label and skips the search list entirely.
The general skill is knowing which layer to interrogate and having one tool per layer you can use without a tutorial: dig for name resolution, ss -s for socket exhaustion, strace (or dtruss on macOS) for "it's hanging and I don't know on what," and reading the cgroup limits directly for memory. Four commands. Engineers who seem uncannily fast at debugging usually aren't smarter — they just don't spend the first hour at the wrong altitude.
Treating your dependency tree as an attack surface
Supply chain security stopped being a compliance checkbox in September 2025 and became an operational concern with a name.
On 15 September 2025, the Shai-Hulud worm hit npm: self-replicating malware that stole maintainer credentials, then used them to publish itself into further packages. It reached over 500 packages including widely-used ones like @ctrl/tinycolor, and CISA issued an alert on 23 September. A substantially evolved variant appeared 24 November 2025. A later wave in May 2026 spanned npm and PyPI simultaneously.
The uncomfortable detail is what didn't help. npm audit queries a database of disclosed vulnerabilities — it has nothing useful to say about a legitimate package whose newest version was published by a real maintainer's real token an hour ago. Teams that ran audits religiously were no better protected than teams that didn't.
What actually reduces exposure is unglamorous:
npm ci, nevernpm install, in CI. Install can resolve to something your lockfile never saw.--ignore-scriptswherever you can tolerate it. Nearly every one of these worms executes via a lifecycle script at install time. This is the single highest-leverage line.- Trusted publishing / OIDC instead of long-lived tokens. A stolen npm token is a publish credential with no expiry. Short-lived, workload-bound credentials make the worm's core propagation mechanism much harder.
- A cooldown on new versions. Most of these campaigns are detected within hours to days. Not installing anything published in the last 72 hours is a crude filter that would have caught every wave so far.
FAQ
Do I need to learn a specific AI framework, or the underlying concepts?
Neither, mostly — unless you're building AI products, in which case learn the concepts. For everyone else, the framework question is a distraction: the skills above that touch AI (reviewing generated diffs, structuring code for agents) require no framework at all. If you are building on models, learn tokenization, context limits, embeddings and evaluation, and treat the SDK as an implementation detail — the frameworks in this space have a half-life measured in months and the concepts don't.
Is this list different for junior versus senior developers?
The list is the same; the order isn't. If you're early, the two with the steepest payoff are spec literacy and debugging below the app layer, because they compound and they're the two most-skipped. They're also the ones that generated code cannot substitute for — a model can produce a plausible implementation, but it cannot tell you whether your production incident is a DNS problem, and being the person who can is disproportionately valuable early.
If you're senior, cost per request is probably the gap. It's the one most likely to be nobody's job on your team.
Isn't "read generated code carefully" just code review?
Yes, with a different prior. Human code review is calibrated on human failure modes — you look hardest where the author was likely rushed or unfamiliar. Model output inverts that: it's most polished exactly where it's most wrong, because fluency and correctness are produced by different mechanisms. Same activity, retargeted.
The thing all six have in common
None of these is about a technology. They're all about the same underlying move: being the person who checks the actual thing rather than the description of it — the spec instead of the summary, the resolver instead of the trace, the per-GB line item instead of the monthly total, the boundary condition instead of the plausible-looking function.
That's an unfashionable answer to "what should I learn in 2026," and it's the only one I've seen hold up as the tooling churns underneath it. Generated code made it more valuable, not less, because the volume of confident, plausible, unverified output going into codebases went up by an order of magnitude and the number of people willing to check it did not.
Cover photo by Naboth Otieno on Pexels.