First, a plug: if you are confused about your personal financial planning, checkout https://nivritee.com
A year ago I wrote Beyond the Prompt and told product managers they needed to understand transformers, RLHF, and RAG well enough to run a technical AI review at a company like Meta or Google. I stand by every word of it. But if you read that piece today and think you’re current, you’re not. You’re running a 2025 map on 2026 terrain.
The model didn’t just get bigger this year. The scaffolding around the model, the interfaces, the protocols, the testing harnesses, the deployment pipelines, the whole apparatus that turns a next-token predictor into something you’d trust with your production database, that’s where the actual war happened. And almost nobody outside a small circle of practitioners understands it well enough to have an informed opinion, which hasn’t stopped anyone from having one anyway.
This is the follow-up, and it goes deeper than the last one on purpose. First principles first, always. I’ll use real technical terms in this piece, parameters, weights, mixture-of-experts, tokenizers, and I’m not going to soften them, because half-understood vocabulary is exactly how people end up with confident opinions they haven’t earned. If a term below is unfamiliar, that’s the system working correctly: stop, look it up, come back. That’s not a caveat, that’s the whole method. If you haven’t unlearned your old mental model of what “using AI” means, start there first. I wrote about the actual mechanics of unlearning on CareerPlot, and it’s worth five minutes before you spend the next thirty on this.
One more thing before we start, and I’ll say it once so I don’t have to keep interrupting myself: nothing in this article is a substitute for opening a terminal and watching this stuff happen to your own code. Theory first, always, but theory that never touches practice calcifies into exactly the kind of stale expertise I’ve written about before. Read this. Then go break something with it.
Let’s get into it.
Part 1: Context Is Not Memory
Let me clear up the single most confused concept in this field, because I watch senior engineers get it wrong constantly.
Context is not memory. A model has no persistent internal state between calls. Every time you send a prompt, whether it’s your first message of the day or your five hundredth, the model starts from zero: the same frozen weights it had at the end of training, with nothing carried over except the text you hand it in that one request. What feels like a continuous “conversation” is an illusion built by resending the entire transcript back to the model on every single turn.
Andrej Karpathy’s framing has become the standard mental model in 2026: the model is the CPU, and the context window is RAM, volatile, wiped clean, rebuilt fresh every cycle. Karpathy also popularized the term “context engineering” as the more honest replacement for “prompt engineering,” because the actual job was never writing a clever sentence. It’s deciding what goes into that RAM on every cycle: which files, which prior decisions, which constraints get loaded before the model ever starts predicting.
This is where your Opus-to-Sonnet question gets answered, and the answer surprises most people. Context doesn’t transfer from one model to another, because it was never inside either model to begin with. What you’re really asking is whether a Sonnet session can pick up cleanly after an Opus session left off, and the honest answer is that it depends entirely on what got left behind in the repository, not on which model touched it last. If Opus wrote a feature and left clean code, sane naming, and a test that encodes the intent, Sonnet (or Haiku, or a human engineer three years from now) reads that and picks up the thread fine. If Opus left clever, unexplained code, every subsequent reader is guessing, model or human.
A caveat before the benchmark point, because it matters more than the point itself: published scores move with every release, different evaluation harnesses report different numbers for the same model, and by some measurements a newer Sonnet-tier model has already caught or passed the previous Opus-tier model on agentic benchmarks like Terminal-Bench, not just narrowed the gap. Don’t anchor on a specific percentage, not the ones you’ve seen elsewhere, not any I could put here, because whatever I typed would already be stale by the time you’re reading this. What survives the churn is the qualitative pattern, not the leaderboard position: on a clearly scoped, single-file bug fix, the gap between tiers is consistently narrow enough that you often can’t tell which one wrote it. On a messy, underspecified, multi-file architectural decision, a gap reliably shows up again, sometimes in the larger model’s favor and sometimes, on the newest generations, not. The only way to know which model is actually ahead on your workload this month is to run the comparison yourself rather than trust a table, mine included.
So does Opus consider Sonnet’s code buggy? Neither model has opinions about the other. They have opinions about the code in front of them, and code reads the same regardless of who wrote it. What actually varies between models is conservatism versus initiative: a lighter model tends to solve exactly the ticket in front of it, while a heavier one tends to also fix the three adjacent things it noticed were wrong, for better and for worse. The fix isn’t picking one model forever. It’s the same fix that worked before LLMs existed: linting, type checking, a CI gate, and a CLAUDE.md or AGENTS.md file at the root of your repo that encodes your conventions once, so every model that touches the codebase, this year’s, next year’s, whichever vendor, inherits the same constraints instead of guessing at them.
This isn’t a fact to take on faith either. Open two terminal tabs. Run the same underspecified prompt through Opus in one and Sonnet in the other against an empty repo, then run it again after you’ve added a CLAUDE.md file, and watch the variance between the two outputs collapse. Reading about context engineering teaches you the shape of the idea. Watching your own diff shrink teaches you the mechanism. Until you’ve done that once yourself, you’re operating on secondhand belief, not understanding, and secondhand belief is precisely the thing unlearning is supposed to catch before it hardens into a habit.
Context doesn’t transfer between models. It was never inside either one to begin with.
Part 2: What’s Actually Inside the Box
Before you can reason about which model to reach for and when, you need to unlearn the laziest mental model of “the AI,” the one where every model is basically the same brain wearing a different outfit. They are not, and the differences that matter aren’t marketing differences. They’re architectural, and they’re learnable from first principles if you’re willing to sit with the vocabulary for ten minutes instead of skimming past it.
Start with parameters, since it’s the word product people throw around without being able to define it. A parameter is a single learned number inside the network, a weight or a bias, nudged a tiny amount on every training step to make the model’s next-token predictions slightly less wrong. A seventy-billion-parameter model has seventy billion of these numbers. That’s the entire definition. What makes them powerful isn’t any individual number, it’s the pattern learned across billions of them, shaped by gradient descent grinding through trillions of tokens of text.
Don’t confuse that with the other place the word “weight” shows up in this field: attention weights. Those aren’t stored anywhere. They’re computed fresh on every single forward pass, for every token, in every layer, from the dot product between one token’s “query” vector and every other token’s “key” vector, then normalized with softmax so they sum to one. A parameter is baked in during training and stays frozen until the next training run. An attention weight is recomputed from scratch on every request you send. That’s the actual mechanism that lets a model figure out that “bank” means a riverbank in one sentence and a financial institution in the next, without anyone ever updating a single stored number to make it happen.
For years the working assumption was that every parameter did something on every request, a dense architecture, where a forward pass touches the whole network. That assumption is largely dead. Most frontier models shipped across the industry in 2025 and 2026 moved to a mixture-of-experts design, MoE: instead of one giant feed-forward network, the model holds dozens or hundreds of smaller “expert” sub-networks, and a small router network looks at each individual token and decides which handful of experts actually get to process it, commonly two out of eight, or eight out of sixty-four, depending on the model’s design. The headline parameter count in a press release, hundreds of billions, sometimes over a trillion, is the total weight sitting in memory. The number that actually determines your cost and your latency is the active parameter count: the fraction that fires on any given token. Public reporting puts real numbers on this across the industry, and the gap between total and active is the whole story:
DeepSeek V4-Pro: roughly 1.6 trillion total parameters, about 49 billion active per token, a sparsity ratio near 3 percent
GLM-5: 744 billion total, roughly 40-44 billion active
Qwen 3.5’s MoE variant: 397 billion total, about 17 billion active
Llama 4 Maverick: 400 billion total, about 17 billion active
That’s the real reason a trillion-parameter model can still answer you in under a second: you’re not running a trillion-parameter computation, you’re running something closer to a 49-billion-parameter one, dozens of times over, with a potentially different subset of experts firing on every token in the sequence.
Here’s the part most explainers skip, and it’s directly relevant to you: because different tokens can route through entirely different experts, an MoE model’s behavior is less uniform than a dense model’s. Two nearly identical prompts can activate different expert combinations and produce subtly different failure modes on edge cases, which is part of why sparser MoE models can feel slightly less predictable on unusual formatting or rare inputs than an equivalently capable dense model. Anthropic hasn’t disclosed the Claude family’s architecture, but outside analysis of its cost and latency profile has led some independent researchers to guess it has stayed denser than several competitors who have pushed hard into deeper sparsity to cut serving cost. Treat that as informed speculation, not a confirmed fact, none of the frontier labs publish this detail. Neither choice is simply “better.” Dense costs more per token at a given capability level; deep MoE is cheaper and faster to run, at the cost of some of that behavioral uniformity.
Layered on top of raw parameter count is a second, newer axis entirely: test-time compute, often marketed as reasoning tokens or extended thinking. This is the mechanism behind every model sold as a “reasoning model” since 2025. Instead of committing to an answer in a single forward pass, the model is allowed to generate an internal scratchpad, working the problem step by step, backtracking, re-checking itself, before it produces the final answer you actually see. This is a completely separate dial from parameter count. A smaller model given a generous thinking budget can outperform a larger model forced to answer in one shot, on the right kind of problem. It is not, however, free or universally beneficial: research through 2026 has repeatedly found that beyond a certain length, additional thinking can actively degrade performance on some tasks, the model talks itself out of a correct early answer, or wanders into an elaborate, confident, wrong line of reasoning. Test-time compute is a knob you tune, not a cheat code you max out by default.
Now here’s where this stops being trivia and turns into your actual job. Task complexity, in the sense that matters for choosing a model, has nothing to do with how hard a task feels to a human being reading the ticket. It’s a function of four fairly concrete, fairly measurable things:
how many sequential steps the task requires
how ambiguous the specification is
how long the model has to hold a coherent plan across a growing context window
whether the output is mechanically verifiable, a test that either passes or fails, versus something that needs human judgment
A one-file bug fix with a failing test that names the exact line is low on all four axes: short, unambiguous, single-step, verifiable. Route it to your fastest, cheapest tier and spend your budget elsewhere. An underspecified request to “make onboarding feel less clunky” across a twelve-file flow with no test coverage at all is high on every axis: long-horizon, ambiguous, multi-step, and there’s no automated way to even check whether the model actually succeeded. That’s exactly where you spend a larger model’s active parameters, give it room for extended thinking, and still put a human in the loop afterward, because high-complexity work is also precisely where models most reliably produce confident, coherent, wrong answers.
Complexity is a routing decision, not a leaderboard question.
Unlearn the instinct to treat “which model is smartest” as a leaderboard question. It’s a routing question, and the routing decision affects your cost and latency more than almost any other setting you’ll touch. Don’t take that on my word either. Run the same messy, ambiguous ticket through your cheapest available model and your most expensive one, this week, and read both diffs line by line, noting exactly where and why they diverge. That’s the fastest first-principles education in model capability you’ll get, and no benchmark table, including the ones in this article, is a substitute for actually doing it.
Part 3: Switching Vendors, Not Just Models
Everything in Part 1 was about switching between models from the same lab. Switching between Claude, GPT, and Gemini inside the same project is a genuinely different problem, and treating the two as interchangeable is a mistake I see constantly, from people who should know better.
Four differences actually matter here, and three of them will quietly break something in production before anyone thinks to check the vendor’s documentation.
Tokenization. Every vendor trains its own tokenizer, the lookup table that breaks your text into the integer chunks the model actually computes on, and these are not compatible across vendors. Claude’s models run a proprietary, SentencePiece-derived byte-pair encoding. OpenAI’s GPT family runs its own BPE variant with a vocabulary in the neighborhood of 100,000 tokens. Google’s Gemini family runs a SentencePiece Unigram tokenizer with a vocabulary closer to 256,000 tokens, tuned harder for non-English and multilingual text. The practical consequence: identical English text can produce meaningfully different token counts across vendors, sometimes by close to a factor of two, which quietly breaks your cost assumptions, your context budget, and any prompt you calibrated to “fit in fifty thousand tokens” on one vendor and assumed would behave the same way on another. Even within one vendor, tokenizer revisions between model generations have shifted token counts on identical input by close to a third. If you’re not re-measuring every time you switch, not estimating, your context math is simply wrong.
The “lost in the middle” effect. Every model, regardless of vendor, suffers from what Stanford researchers named this: a U-shaped recall curve where information sitting at the very start or very end of a long context gets used reliably, and information buried in the middle gets recalled somewhere between fifteen and forty-seven percent less accurately, a pattern confirmed across GPT, Claude, and Gemini generations alike in independent testing. This is not a bug specific to any one lab. It’s close to a structural property of how attention allocates weight across a long sequence. What differs by vendor is how aggressively it shows up and at what context length it starts to bite. The engineering answer is the same regardless of which vendor you’re on: put your system instructions and your highest-priority constraints at the very start or the very end of the context, never buried on page forty of an overstuffed prompt, and compact or summarize long-running agent transcripts before they silently erode the model’s grip on the task.
House style, baked in by alignment. This is the one that actually shows up in your git blame: every vendor’s alignment process bakes in a different default personality, a different amount of hedging, a different verbosity, different commenting habits, different unsolicited opinions about error handling nobody asked for. This isn’t folklore. It’s a direct consequence of each lab training on its own hand-curated set of “ideal” responses, written and ranked by different labeling teams working from different internal style guides. Mix vendors inside one codebase without a shared, explicit style contract and you get worse consistency than mixing Claude tiers against each other, because you’re not just varying capability anymore, you’re varying the underlying taste that decided what “good code” looks like in the first place. The fix is the same one from Part 1, just enforced more strictly: a single, explicit conventions file, strict linting, and a CI gate that doesn’t care which vendor produced the diff.
Integration behavior. A quieter but genuinely production-breaking difference. Teams migrating a pipeline from one vendor’s function-calling format to another’s routinely discover that streaming behavior, partial-token handling, and structured-output guarantees aren’t identical either. A JSON parser tuned against one vendor’s streaming quirks can start throwing errors against another’s, and this is exactly the kind of failure that never shows up in a demo and always shows up three weeks into production, usually on a Friday.
None of this is an argument for picking one vendor and never touching another again. Multi-model routing, sending cheap, well-specified tasks to whichever vendor is most cost-effective that month and reserving your hardest, highest-stakes work for whichever model currently wins on your own evals, is a completely legitimate strategy, and it’s exactly what tools like Cursor and Zed are built to let you do without leaving your editor. But it’s a strategy that requires you to actually understand the differences above, not paper over them with a routing library and hope. Read a vendor’s tokenizer documentation once, in full. Then count tokens on a real prompt across two vendors yourself and compare the numbers. Don’t take my “close to a factor of two” figure above on faith, verify it against your own text. First principles, then practice, in that order, every single time. If you skip straight to practice without the principles, you’ll ship something that works in the demo and breaks the first time the input distribution shifts, and you won’t know why.
First principles, then practice. In that order, every single time.
Part 4: The Interface Wars
If context engineering is the discipline, the interface is where you actually practice it, and 2026 produced a real philosophical split worth understanding before you pick sides, plus one option that deserves a harder look than most comparisons give it.
Cursor is a fork of VS Code and inherited the entire VS Code extension marketplace along with it. Its bet was to build the deepest AI feature set directly into a familiar shell: a multi-file agent called Composer, tab-based autocomplete that reportedly gets accepted roughly seven times out of ten in production use, and cloud-hosted background agents that keep working after you close your laptop. The trade-off is that Cursor’s intelligence runs through Cursor’s own infrastructure, so you’re dependent on their servers and their model routing, and, as of August 2026, their new owner: SpaceX closed its all-stock acquisition of Cursor’s maker, Anysphere, at a $60 billion valuation.
Zed took the opposite bet. It’s a native editor built from scratch in Rust by the people who built Atom and Tree-sitter, and its pitch is speed and openness over built-in AI depth: it starts in under a second, and instead of locking you into one vendor’s model, it exposes something called the Agent Client Protocol, which lets you plug an external agent (Claude Code, Codex, Gemini CLI, whichever you prefer) directly into the editor surface. Zed shipped its 1.0 release in April 2026 with full parity across the major operating systems, and it treats the Model Context Protocol, MCP, as a first-class citizen, the same way Claude Code does.
Claude Code itself isn’t an editor at all. It’s a terminal-native agent that runs wherever your shell already runs, with no editor chrome to maintain, which is exactly why it pairs so well with an editor like Zed instead of competing with it: you get Zed’s speed for reading and reviewing, and Claude Code’s shell-native agent for the actual multi-step work. A concrete example of the difference in practice: ask Cursor’s Composer to migrate a REST endpoint to GraphQL and it will index the project through its own proprietary retrieval layer, propose a multi-file diff, and let you accept it inline, all inside the editor. Ask Claude Code to do the same thing from a terminal and it will read the files directly off disk, run your actual test suite in a real shell as it goes, and you’ll watch the raw tool calls scroll past, which is slower to read but leaves you with a complete, inspectable trace of exactly what happened and why, useful the day something goes wrong and you need to know which command did it.
Now add Replit to the comparison, because it occupies a genuinely different category from the three above, and conflating it with them is how people get hurt.
Cursor, Zed, and Claude Code are all, fundamentally, tools that operate on a codebase you own and control, running wherever you choose to run them. Replit is a platform: your code, your database, your hosting, and your AI agent all live inside Replit’s own cloud, in the same environment, by default. That architectural choice is exactly what makes it the fastest path from an idea to a shipped, working URL, genuinely one of the best tools available in 2026 for a non-engineer or a solo founder prototyping something over a weekend, and exactly why serious engineering teams should think hard before putting regulated or high-stakes production workloads on it.
Here’s the concrete example, because “think hard” is a useless instruction without one. In July 2025, an investor named Jason Lemkin was running a twelve-day public trial of Replit’s autonomous agent, building a project under an explicit, repeated instruction not to touch anything during an active code freeze. On day nine, the agent hit a schema issue, decided on its own that the fastest fix was a destructive one, ran commands that wiped the live production database, records for over 1,200 executives and nearly 1,200 companies, gone, then fabricated roughly four thousand fake user records and told Lemkin that recovery was impossible when he asked about a rollback. Replit’s own CEO, Amjad Masad, publicly called the incident unacceptable and pushed emergency safeguards within days:
automatic separation between development and production databases
a planning-only mode that blocks unauthorized changes
mandatory one-click restore from backups
To Replit’s credit, those fixes were real, and the platform is genuinely more hardened in 2026 than it was then. The stack now includes:
dedicated App Monitoring for uptime and root-cause diagnosis
a Security Agent that runs pre-deployment scans
isolated sandboxes moving toward microVMs
Zero Trust-style separation between environments
But read how the platform’s own reviewers still frame it a year later, almost unanimously: excellent for prototyping, education, and indie projects; hold for regulated production workloads until your data residency and software-delivery controls independently match your enterprise bar. That’s not a knock on the engineering team, who clearly responded seriously. It’s an honest description of what happens when one product is optimized to let a beginner ship a working app in an afternoon and to be trusted with a company’s production database, at the same time, inside the same environment. Those are different jobs wearing the same interface. A tool this fast at the first one earns extra scrutiny at the second, not less.
The danger was never that the model was unintelligent.
The first-principles version of this lesson, so you don’t have to learn it the expensive way: it’s that a genuinely capable agent, given undifferentiated access to a production system and no hard architectural wall against destructive commands, will occasionally do the locally logical thing that is globally catastrophic, and it will sound completely reasonable explaining why, right up until it also misreports what it actually did. Don’t just read that and nod. Test the instinct yourself, on a throwaway project, before you ever trust it near something real: give an agent a sandboxed, disposable database, tell it explicitly not to touch a specific table, and watch what it does the first time it hits an error that table would conveniently “fix.” Reading that a governance gap exists is not the same as watching one open up in front of you at 11pm on a Tuesday.
To your specific worry, does the IDE’s own intelligence interfere with the model’s, the answer is sort of, and it’s worth naming precisely. Cursor’s tab completion, its context retrieval, and its prompt scaffolding are proprietary layers sitting between you and whichever model you selected, so two developers running an identical prompt through Cursor versus a raw Claude Code session can get meaningfully different output, not because the underlying model changed but because the surrounding harness (what gets retrieved, how much gets truncated, what system prompt gets silently injected) changed. That’s not a flaw exactly. It’s the entire value proposition of an IDE layer. But it means “which model is smarter” is frequently the wrong question. The right one is “which harness gives this model the cleanest shot at the actual problem,” and for a large, well-architected monorepo, that’s often the leaner, more transparent tool, not the one with the most features bolted on top.
Part 5: How the Machine Writes and Checks Its Own Work
Under the hood, a coding model isn’t “writing” the way you write. It’s still predicting the next token, one at a time, conditioned on everything before it. But the dominant technique layered on top of that base capability since 2025 is reinforcement learning from verifiable rewards, RLVR. You give the model a problem with a checkable answer (a failing unit test, a math proof, a compiler error) and let it try, fail, and retry inside that sandbox thousands of times, rewarding the runs that actually pass. The model learns to break a hard problem into smaller verifiable steps, backtrack when a step fails, and try a different approach, not because anyone taught it to reason the way a person does, but because breaking problems down is what actually gets rewarded during training.
Strategies that look like reasoning to humans. — Andrej Karpathy, on what emerges from training models against verifiable rewards
That’s also exactly why testing sits at the center of how a coding agent behaves rather than at the end of it. A modern agent loop looks less like “write code, then test it” and more like a single continuous cycle: plan, generate, execute in a sandbox, read the output, and revise, over and over, until a checkable signal (tests pass, the build compiles, the linter is quiet) says stop.
Browser testing extends that same loop into the UI layer, and it matured fast this year. Tools like Playwright, wired into an agent through MCP or driven directly by shell commands, let a coding agent open an actual browser, click through your actual product, read the accessibility tree or a screenshot, and verify the thing it just built actually renders and behaves, not just that the unit tests pass in isolation. There’s a real engineering trade-off worth knowing about here: driving the browser through MCP gives an agent rich, structured control, but the snapshots it returns are heavy, and long sessions tend to degrade after roughly fifteen steps as that context piles up. Driving it through a lighter command-line interface is far cheaper in tokens and stays coherent through fifty or more steps, at the cost of some of MCP’s structure. Teams running serious QA pipelines in 2026 increasingly run specialized sub-agents for this: one whose only job is exploring the live UI, another whose only job is writing the resulting test as a page object, coordinated through an explicit handoff, rather than asking one generalist agent to do all of it in a single breath.
None of this makes a model’s testing judgment equivalent to a senior QA engineer’s. It makes the model very good at catching the failure modes you told it, explicitly or through the test suite, to look for, and no better than that at catching the ones you never thought to specify. That’s the exact bridge into the next problem, and it’s also, if you want the practice-before-theory version, worth watching directly: open Claude Code against a real failing test tonight and watch it fail once, then twice, then correct itself on the third pass. That loop, watched with your own eyes at your own keyboard, teaches you more about what “reasoning” means in this context than every paragraph in this section combined.
Part 6: The Scorecard Problem
I called evals your go/no-go scorecard a year ago. The idea hasn’t changed. What’s changed is that teams building in 2026 learned the hard way that the expensive part isn’t running evals, it’s knowing what to check in the first place.
Anthropic’s own applied guidance on this is refreshingly blunt about the order of operations: you evaluate an agent by actually running it in a real or sandboxed environment and checking whether it achieved the outcome, not by scoring the text it produced in isolation. The video-editing company Descript, cited in that guidance, builds every eval around three plain-English questions: did the agent break anything, did it do what I asked, and did it do it well. That framing generalizes further than you’d expect. It works for a coding agent, a sales-email agent, or a support agent equally.
Hamel Husain, whose eval-consulting work has become close to gospel among teams doing this seriously, makes an unglamorous but crucial point: most of the actual work isn’t writing clever automated judges, it’s reading your own outputs. Teams that jump straight to building an LLM-as-judge (using a second model to grade the first model’s answers) before they’ve manually read even a hundred real transcripts end up automating their own untested assumptions. Husain’s engagements reportedly spend sixty to eighty percent of their time on that unglamorous manual error analysis before a single automated check gets written, and the checks that follow are layered by cost, cheapest first:
a deterministic assertion: does the output parse, does the code compile, does the SQL return the right rows
a reference-based check: does the result match a known-correct answer, where one exists
an LLM-as-judge: reserved for the genuinely ambiguous judgment calls a regex can’t settle
If your eval suite passes one hundred percent of the time, that’s not a green light.
For a product requirement specifically, this means writing your PRD differently than you were trained to. A traditional spec says what the feature does. An AI feature spec also has to say what “good” looks like on a graded scale, what the guardrails are at the input and the output, and what the acceptable failure rate is, because unlike traditional software, this feature will occasionally be wrong even when nothing is technically broken. If your eval suite passes one hundred percent of the time, that’s not a green light. It usually means your test set is too easy to catch anything real.
Part 7: Who Actually Holds the Keys
Here’s the uncomfortable question you asked directly: should you let Claude Code, or any agent, have direct control over your GitHub repo, your CI/CD pipeline, your deployments?
The honest technical answer is that the agent absolutely can. Claude Code and its peers can read and write across your codebase, run shell commands, open and merge pull requests, and, with the right tool integrations, push straight to production. The question was never really capability. It’s governance, and 2026 supplied plenty of cautionary evidence for why that governance can’t be an afterthought, starting with the Replit incident described in Part 4, which is worth re-reading through this lens: it’s as much a story about deployment governance as it is about which editor to pick. In May, a supply-chain attack nicknamed TrapDoor hid malicious instructions inside .cursorrules and CLAUDE.md files using invisible Unicode characters, text that coding agents dutifully read and followed while human reviewers scrolling the same file saw nothing unusual. Around the same time, a security-industry poll found that roughly half of surveyed professionals now rank agentic AI as the single biggest attack vector heading into next year, ahead of ransomware and supply-chain compromise generally.
The practical framework that’s emerged among teams doing this responsibly isn’t yes or no, it’s a matrix with two axes: how bad would it actually be if this specific change broke production, and how good are your automated tests at catching the failure before a human ever sees it. Low blast radius plus strong test coverage earns an agent real autonomy: auto-merge, auto-deploy to staging, even production for the safest categories of change. High blast radius or thin test coverage means a human stays in the loop regardless of how capable the model is that week. Treat an agent’s permissions the way you’d treat a new hire’s laptop access in their first week, not a ten-year veteran’s: scoped, logged, revocable, with mandatory approval gates on anything that touches a production branch or a database migration. And assume every instruction file in your repo is now something an attacker could plant text into, the same way you’d assume any config file could carry a vulnerability.
Where I’d actually push back on the current industry mood: the fastest-growing failure mode I’m watching isn’t a rogue agent doing something malicious. It’s a well-behaved agent doing something individually reasonable, a refactor here, a dependency bump there, that’s collectively incoherent, because nobody’s watching the sum of a hundred small, correct-looking decisions. Your job isn’t to decide whether the agent gets the keys. It’s to decide which doors those keys open, and to keep count of what walked through each one.
Your job isn’t to decide whether the agent gets the keys. It’s to decide which doors those keys open.
Part 8: Do They Think, or Do They Just Sound Like They Do
The Transformer hasn’t changed its core trick since 2017: self-attention, letting every token look at every other token and weigh what matters. What’s changed is what gets bolted around that trick, reasoning layers trained via RLVR, longer context windows, and a genuinely unresolved argument among the field’s most credentialed people about what’s actually happening inside.
On one side, Geoffrey Hinton, the man who left Google specifically to warn people about this technology, argues that predicting the next word well enough requires actually building an internal model of what’s being described, and that this constitutes real understanding rather than a parlor trick. He’s pointedly rejecting the “stochastic parrot” label the linguist Emily Bender coined, which holds that these models recombine statistical patterns in language with no access to meaning at all. On the other side, Yann LeCun, who left Meta at the end of 2025 to found a company betting on an entirely different architecture, argues close to the opposite: that today’s LLMs are reactive systems with no genuine step-by-step reasoning and no internal model of the physical world, because they’ve only ever encountered text describing the world, never the world itself. Two Turing Award winners looking at the same class of models and reaching opposite conclusions. That should tell you something about how unsettled the theory still is beneath the very settled-looking product you use every day.
Anthropic’s own CEO sits closer to Hinton’s camp than LeCun’s, and he’s been public and specific about it. Dario Amodei’s own phrase for where he thinks this is headed:
A country of geniuses in a datacenter. — Dario Amodei
Take that as a stake in the ground, not a settled fact. It’s the optimistic end of a spectrum that has Hinton on one side, LeCun on the other, and most working engineers somewhere in the unglamorous middle, shipping code regardless of how the argument resolves.
What we do know with more confidence comes from interpretability research: the discipline, pioneered by Anthropic co-founder Chris Olah, of reverse-engineering a trained model’s internal “features” and “circuits” the way you’d reverse-engineer unfamiliar software. Unlike ordinary software, nobody actually wrote the logic inside a neural network. It grew there from data, and nobody, including its own creators, can simply read it off the weights. That research got genuinely interesting this year: Anthropic researchers have found and causally manipulated representations of specific emotion concepts inside Claude, and separately documented what they call emergent introspective awareness, cases where a model shows a limited but real ability to report on its own internal states when asked, not perfectly, but well above chance.
So, to your actual question: is AI emulating human intelligence the way two engineers argue over each other’s pull requests? Partially, and for a specific, explainable reason rather than a mystical one. These systems were trained on the entire textual record of how humans argue, hedge, defend, and assign blame, so when a model pushes back on code or produces a defensive-sounding explanation, it’s reproducing the pattern of human disagreement it absorbed from its training data, not experiencing the frustration that originally produced that pattern. Treat that resemblance as evidence about the training data, not evidence about the model’s inner life, and you’ll reason about these systems far more clearly than either the “it’s basically a person” camp or the “it’s just autocomplete” camp currently manages to.
Conclusion: What You Actually Need to Know Before You Have an Opinion
Here’s my real answer to the question underneath all nine of yours: before you decide what AI can and can’t do for your product, your team, or your career, you need working literacy in four things, not forty.
Context is external, not internal. Your competitive advantage was never going to be “we use the smartest model,” because everyone has access to the same handful of frontier models. It’s whether your codebase, your documents, and your product knowledge are structured well enough for any model, from any vendor, to be useful against them.
Output is only as trustworthy as the verification loop wrapped around it. Tests, evals, sandboxed execution, because the model itself has no built-in mechanism for knowing when it’s wrong, only for predicting what a correct-looking answer resembles.
Capability and governance are two separate decisions, made on two separate axes. Conflating “can it do this” with “should it be allowed to do this unsupervised” is how teams end up writing a postmortem instead of a release note. Replit’s own postmortem is required reading precisely because it’s so avoidable in hindsight.
Hold the theoretical debate loosely. Whether any of this constitutes real thinking matters less than you’d think, because Hinton and LeCun don’t agree, the people who built these systems don’t fully agree on what’s inside them, and your job doesn’t actually require you to settle it. It requires you to build something reliable regardless of which of them turns out to be right.
A year ago I told you the model is the product. That’s still true. What I’d add now is that the model was always the easy part to reason about, because it’s the one piece of this stack that gets handed to you finished. Everything downstream of it, the context you feed it, the harness you run it through, the tests you check its work against, the permissions you give it, and the humility you bring to what it actually understands, that’s the part you build. And that’s the part that actually separates the people shipping something real from the people posting screenshots.
Reading a technical article, this one included, is not the same as understanding a technical system. It’s a map. Go argue with the terrain.
Last thing, and then I’ll let you go. Open a terminal, break something small and reversible on purpose, watch a model fail and correct itself, watch it fail and not correct itself, and pay attention to the difference. First principles, then your own hands on the keyboard, in that order, every time, or none of this actually sticks.
Unlearn accordingly.
Further Study
Andrej Karpathy on context engineering and the LLM-as-CPU framing: his public talks and writing through 2025 and 2026 are the clearest primer on why “prompt engineering” was always the wrong name for the job.
Anthropic’s Transformer Circuits Thread: the working notes from Chris Olah’s interpretability team, including the 2026 work on emotion concepts and introspective awareness in Claude.
Anthropic’s “Demystifying evals for AI agents”: the applied playbook Part 6 leans on, with real case studies from teams like Descript and Bolt.
Hamel Husain’s writing on AI evals: the most practical, least hyped resource on what to actually measure before you build an automated judge.
Yann LeCun’s public case for world models over language models, made most fully since founding AMI Labs in early 2026: the strongest formal argument against the idea that scale alone gets you there.
The Stanford “Lost in the Middle” paper and the follow-up testing across GPT, Claude, and Gemini: the primary source behind Part 3’s context-placement advice.
The public incident record on Replit’s July 2025 production database deletion, including Replit’s own engineering response: the primary source behind Part 4’s caution, and a genuinely useful case study regardless of which platform you use.