The vibe coding hangover
Early last year, Andrej Karpathy gave a bad habit a good name. "Vibe coding," he called it: fully giving in to the vibes, forgetting the code even exists, accepting whatever the model hands back. It was funny because it was true, and it spread everywhere. Collins Dictionary made it their word of the year.
Nine months later, the same guy posted something a lot less funny: he'd never felt this far behind as a programmer. The tools didn't get worse. They got good enough, fast enough, that keeping a mental model of your own codebase became the harder job.
That's the honest starting point for 2026. The tools aren't the story anymore. The story is who still knows what "right" looks like when the model doesn't.
Context engineering ate prompt engineering
Somewhere in the middle of last year, prompt engineering quietly got demoted. The term making the rounds now is "context engineering," coined, tellingly, not by a researcher but by Shopify's CEO: the art of loading a model with everything it needs to plausibly get the job right.
Chroma tested that idea instead of just asserting it. They ran well over a dozen models and found something uncomfortable: quality degrades as context grows, well before you hit the window limit, and unevenly. Stuff buried in the middle of a long prompt gets ignored more than stuff at the edges. Everyone's been calling this "context rot" ever since. Now it's a thing you design around, not something that just happens to you.
Some of the best-regarded agent setups in 2026 are boring on purpose. One widely-read postmortem argued you don't need a memory layer, a vector database, or a stack of MCP servers. A plain folder of status-tagged files and the read/write tools every agent already has will get you further than infrastructure will. One account making the rounds: a team that went all-in on MCP in early 2025 spent the second half quietly ripping it back out for a stripped-down pipeline that ran faster and cost less. Every tool definition you load is context you're spending, and most agents are carrying a wallet full of cards they never swipe.
RAG vs. fine-tuning, mostly resolved
This fight is basically over. Fine-tune for behavior: tone, format, how the model uses tools. Retrieve for facts, especially ones that change. If your data changes weekly, no amount of fine-tuning keeps up with a retrieval pipeline pointed at the source of truth.
The one place people still get burned is assuming fine-tuning fixes bad retrieval. It doesn't. One practitioner put it more bluntly than we will: "'Just fine-tune your embeddings,' they said. 'It'll fix your RAG system,' they said. They were wrong." Almost every broken RAG pipeline we've seen has a boring root cause: bad chunking, missing metadata, a query that needed rewriting before it ever hit the vector store. Nobody wants to debug a vector store. Reaching for the fine-tuning budget feels like progress. It isn't.
Multi-agent systems: nobody agrees yet
Here's a fun one. Within days of each other last year, two credible engineering teams published opposite conclusions about the same architecture decision. Cognition, the team behind Devin, wrote a piece called "Don't Build Multi-Agents," arguing that splitting work across sub-agents fragments shared context and produces decisions that don't add up. Anthropic published their own account of building a multi-agent research system right around the same time. Their conclusion was the opposite: separate agents with their own tools and their own exploration paths were exactly what let them tackle problems a single agent couldn't hold in its head.
Both are right, for different jobs. Nobody has settled this, and anyone telling you it's settled is selling something. If your task is one coherent piece of reasoning, keep it in one context. If it genuinely decomposes into independent explorations, multiple agents can out-think one. The mistake is picking the architecture before you've figured out which kind of problem you actually have.
Code got cheap. Judgment didn't.
Generating code has never been less of a bottleneck, and that turned out to be a trap of its own. The line going around Hacker News says it best: code is cheap, but maintenance, support, and security aren't. Every generated line is still tomorrow's technical debt, whoever typed it.
One team's code-review agent confidently suggested "optimizations" for a GPU driver that were already implemented, and told them to disable others that were actively helping. That's the whole model, not a bug: an LLM pair programmer writes with total conviction whether it's right or not, and won't tell you when it's wrong. That discipline is entirely on you now. Teams that treat linters, type checkers, and loud test failures as guardrails for the agent, not just for humans, report meaningfully fewer of these moments. The ones that don't are watching review time balloon: agent-authored pull requests are widely reported to take several times longer to clear review than the ones written by people, because "technically works" and "I understand why this works" are not the same bar.
There's a quieter cost too. Junior engineers historically got good by getting stuck: sitting with a broken build until they understood why it broke. Hand that struggle to an agent every time, and you get someone who can produce working code without ever building the instinct for why it works. Skip the struggle enough times and you don't raise a junior engineer. You raise a senior title with a junior's instincts.
The hype, the KPIs, and the paycheck
Not everything from the last year is a lesson in craft. Some of it is just funny, in a wincing kind of way. One engineer described sitting through a vendor demo where the presenter pasted live database credentials into a config on stage, and when the "natural language to SQL" tool returned different results on two identical runs, waved it off as "the AI improved." Another described leadership tracking prompts-per-developer as a literal productivity metric, as if typing more into a chat box were the point of the job.
None of that is a reason to write off the technology. It's a reason to be honest about where it actually works. The most rigorous study on this so far, METR's randomized trial of experienced open-source developers, found something almost nobody expected: using AI tools made them measurably slower on real tasks in codebases they already knew well, even though they walked away convinced they'd been faster. AI is a rocket for zero-to-one work. On a mature codebase somebody already understands, it can quietly cost you time you'll swear you saved.
The job title arrived before the job description
The "Agentic Engineer" title got handed out faster than anyone agreed on what it means, which is why so many developers are asking, in public, how to prove they're qualified for a job with no settled definition. Here's the shape it's actually taking: knowing how to drive Cursor or Claude Code well stopped being a differentiator sometime last year. It's table stakes now, the way knowing your editor's keyboard shortcuts always was.
The scarce skill is what sits around the model: building the retrieval pipeline, designing the eval suite that tells you when a change actually helped, architecting the agent so it fails safely instead of confidently. And the one nobody puts on a conference slide: cutting a production AI bill in half without anyone noticing the quality dropped.
It's also, bluntly, a discipline that still needs a human standing behind every line that reaches a real repository. The model can write the line fine. Someone still has to own what happens when it's wrong. That's the part of 2026 that isn't going away, no matter how good the phase shift gets: the tools moved. Judgment is still the job.