Every few months this field renames something and half of us roll our eyes. This time I think the rename earns its keep. In late June, Andrej Karpathy came out in favor of “context engineering” over “prompt engineering”, describing it as “the delicate art and science of filling the context window with just the right information for the next step”. Shopify’s CEO Tobi Lütke had been pushing the same term as a core skill, Simon Willison endorsed it within days, and by the end of September Anthropic had shipped an entire engineering guide called Effective context engineering for AI agents. When that many practitioners converge inside one summer, a word has usually caught up with reality.

Here is my confession. I have spent much of the past year building chatbots and RAG pipelines at work, and a good share of my “prompt engineering” sessions were me fiddling with wording while the real problem sat somewhere else entirely: stale chat history, retrieved chunks nobody asked for, tool output dumped three turns ago still squatting in the window. The prompt was never the whole system. Naming the rest of it is oddly liberating.

Every coding agent I have picked up this summer has asked me the same question in a different accent. Codex CLI goes looking for an AGENTS.md. Gemini CLI wants a GEMINI.md. Claude Code reads CLAUDE.md. Cursor keeps its own rules folder. Four tools, four filenames, one identical need: tell me how this repo works before you let me loose in it.

A few weekends ago I opened one of my side projects and counted the instruction files piled up in the root. Three of them. All saying roughly the same thing in three dialects. That is when it clicked: my repos need onboarding documents for robots now, the same way they have always needed a README for humans.

Sometime in early February, Andrej Karpathy finally gave the thing a name. Vibe coding, he called it — giving in to the vibes, embracing exponentials, and forgetting that the code even exists. Four months later the phrase is everywhere, and like most catchy terms it is doing real work: it separates “I reviewed every line” from “I typed a prompt and it ran”.

And the tools caught up faster than anyone expected. Two weeks ago OpenAI put Codex into ChatGPT as a research preview — a cloud agent that takes your repository, works on tasks in its own sandbox, and opens pull requests for you to look at. Claude Code arrived as a terminal agent back in February. Copilot quietly grew an agent mode too. Meanwhile Y Combinator’s Garry Tan said that for about a quarter of their Winter ‘25 batch, 95% of the code was written by LLMs. Not a typo, apparently.

Here is my honest position after a few months of living like this: generating code has stopped being the bottleneck. Reading it is. And that flips a lot of assumptions about what code review is for.

The DeepSeek-R1 release in January felt like a moment. Not just because a Chinese lab dropped an open-weight reasoning model that matches o1 on benchmarks — but because they released the whole family. Six distilled models, from 1.5B to 70B parameters. MIT license. API pricing that makes o1 look expensive. And critically, the community had GGUF quantizations ready within days.

I’ve been running local LLMs since the llama.cpp early days. My daily driver is a Lenovo IdeaPad 3 with a Core i3-1115G4 and 16 GB of RAM. No discrete GPU. Just integrated graphics and system memory. It’s the kind of machine most developers actually have, not the 4090 rigs you see in benchmark posts.

So when the DeepSeek-R1 distilled models landed, the question wasn’t theoretical. Could I run a reasoning model — one that actually shows its chain of thought — on this thing?

It is the second week of January 2025. The holiday dust has settled, the first sprint planning of the year is done, and I am staring at a familiar problem: how do I actually get an LLM to do something useful with our internal systems without writing a bespoke integration for every single data source?

If you have built anything with LLMs in the past year, you know the drill. You want the model to look up a customer record in Postgres. You write a function. You want it to search Confluence. Another function. Slack? Another function. GitHub? You get the picture. Every new capability means more glue code, more maintenance, more surface area for things to break. In a regulated environment like ours, every integration is also a compliance review, a data-classification exercise, and an audit trail requirement.

OpenAI dropped o1-preview and o1-mini in mid-September. Two months in, the hype has settled into something more useful: a clearer picture of where these “reasoning models” actually fit in a practitioner’s toolkit — and where they don’t.

I’ve been building LLM-backed features inside a regulated financial institution for the better part of this year. That means every model choice runs through a mental checklist: latency budgets, cost per thousand calls, data residency, audit trails, and whether the thing hallucinates less than the last one. o1 is the first model that made me update that checklist in a while.