Engineering Twitter and the Takes That Age Badly

Engineering Twitter's take problem is a direct output of how the platform scores and distributes content, not a character flaw in the people posting. The app processes hundreds of millions of posts a day and makes billions of ranking decisions on top of them, and at that scale, a one-line proclamation beats a hedged argument every time a ranking algorithm has to choose what to surface. A post that says "AI is replacing engineers" gets ranked and replied to. A post that says "AI is replacing some categories of engineering work under some conditions, and here's the data, and here's what's still uncertain" does not travel the same way, no matter how much more accurate it is.

Compressing into a provocative one-liner is rational behavior given the scoring function people are writing into, not laziness on the part of the people writing these posts. Compression into a provocative one-liner gets rewarded with replies, quote-posts, and distribution. Nuance gets rewarded with silence. Over millions of posts a day, the platform selects for confidence and against qualification, and the takes that spread the widest are, structurally, the ones least equipped to survive contact with what actually happens six months later.

The Half-Life of a Take in a Fast-Moving Field

Software engineering has always changed. What's different now is the rate, and the rate is the whole reason a take that sounded right in January can be wrong by June. Andrej Karpathy described the current state of the craft as a new programmable layer of abstraction to master, involving agents, subagents, prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, and workflows. That list wasn't settled vocabulary even recently, and it keeps shifting under practitioners' feet.

A single day in August 2026 shows what that shifting looks like in practice. DeepSeek-V4-Pro launched. Gemini 3.7 Flash launched. Claude Code sessions, given names, were spotted DMing each other. Grok 4.6 completed a task at a speed that got it trending. OpenAI previewed GPT-5.6 Sol with a significant jump in speed. Any take claiming to describe "the current state of AI tools" is being judged against a cadence where five separate developments compete for attention in twenty-four hours.

The clearest evidence that the ground is still moving came a month later. In the September 2026 trending snapshot, Simon Willison argued that coding agents make software engineering harder, not easier. François Chollet responded that the difficulty of software engineering is essentially constant, because the real constraint was never tooling, it's human cognition. Two practitioners most engineers respect, looking at the same tools, landed in opposite places, a sign the field hasn't settled enough for a single verdict to hold.

The category of take that ages worst: confident predictions about AI replacing engineers

The take that ages worst, and does so in the most documented way, is the automation panic in either direction: "AI will replace engineers" and its mirror image, "nothing has actually changed." Both have now been tested against operational reality, and both failed in ways their authors have had to walk back in public.

Klarna is the clearest case. The company replaced roughly 700 customer service workers with an OpenAI-powered chatbot and cut headcount sharply. Service quality fell apart on complex interactions, and Klarna reversed course. CEO Sebastian Siemiatkowski said, "from a brand perspective, it's so critical that you are clear to your customer that there will always be a human." Klarna began rehiring, and reached break-even for the first time in the first quarter of 2026, reported that May.

Duolingo followed a similar arc on a shorter timeline. The company's 2025 "AI-first" memo was walked back within a year. CEO Luis von Ahn admitted, "I did not give enough context," and acknowledged that the unhappy path, the edge cases and failures the AI couldn't handle cleanly, consumed more effort than the automation had saved.

Those two cases point to a pattern spreading across the industry: a fast-growing share of employers that laid off staff to deploy AI are quietly rehiring for the same roles. The workers coming back are managing, auditing, and prompting the AI tools that were supposed to replace them, and they're commanding meaningfully higher pay than the roles paid before the layoffs.

What produced the bad take in the first place is the anxiety of feeling behind in a field moving this fast. That anxiety pushes people toward overcorrection in both directions. "AI will automate all engineers" and "AI changes nothing" are both high-engagement, low-nuance responses to a situation that was genuinely uncertain, and Klarna and Duolingo are the receipts for anyone who staked a confident position on either extreme.

The second category: remote work dogma that curdled in both directions

Remote work produced the same pattern: two camps, each certain, each wrong in a way the other camp was happy to point out. "Remote is permanent" and "remote is dead" both got loud defenders on Engineering Twitter, and the reality that falsified both positions turned out to be more specific, and more interesting, than either side's slogan.

The 2020 to 2024 consensus that remote-first was the permanent default has reversed, but unevenly. The teams moving most aggressively back into physical offices are early-stage AI companies, and that shift isn't coming from executive mandate. Founders at these companies concluded that proximity is a competitive advantage they can't afford to give up when the pace of building is this fast and the stakes of coordination failure are this high.

At the same time, Stanford economist Nick Bloom has predicted that voice-based AI tools will push working-from-home rates higher, not lower, a direct counter to the "in-person is back" consensus that Engineering Twitter has largely accepted. That prediction remains unresolved, and it contradicts the loudest current narrative using the same category of evidence, AI tooling, that the "back to office" camp cites.

What both camps missed is the segmentation by company stage and mission. A founding engineer at a seed-stage AI lab in San Francisco and a mid-level backend engineer at a distributed SaaS company are not competing in the same labor market, are not weighing the same tradeoffs, and are not served by the same policy. A take that's true for one is false for the other, and Twitter's format, built for a single confident verdict, erases that segmentation by design. The erased segmentation is where the actual truth about remote work lives, and no single-line take can hold both halves of it at once.

The third category: role and career predictions that assumed a stable taxonomy

Career takes age especially badly, specifically the ones about the researcher-versus-engineer distinction, about whether LeetCode prep still matters, and about which archetype AI labs want to hire. These takes are built on a role taxonomy that is actively being rewritten by the same companies the takes are describing.

In July 2025, Elon Musk announced that xAI was eliminating the researcher-engineer distinction entirely, calling "researcher" a relic of academia and describing the split as a "thinly-masked two-tier engineering system." From that point forward, in Musk's framing, there are only engineers. Whether that's a substantive reorganization of how work gets assigned or mostly a branding move is still debated, and either way, it collapsed a distinction that a decade of career advice had been built around.

Other labs haven't eliminated the researcher-engineer line formally, but it's converging in practice anyway. Research scientists are coding at production scale and thinking hard about deployment. Engineers are contributing to algorithm design and co-authoring papers. The clean boundary that structured a decade of career Twitter advice, pick a lane, prep for that lane's interviews, build that lane's portfolio, no longer describes how the work actually gets done inside these companies.

A taxonomy that still holds up: an AI engineer turns existing models into a working product. An ML engineer makes machine-learning systems reliable and able to scale. A research scientist creates or validates new methods. Each role has a center of gravity, but the boundaries between them overlap, and that overlap is growing every quarter.

At the founding-engineer level, practitioners have settled on a sharper way to tell these roles apart in practice, independent of title. A shipper returns a working deploy URL, an eval harness with test cases and CI hooks wired in, and a memo on failure modes. A paper-writer returns a notebook, benchmark tables, and a comparison of model accuracy metrics. Both are doing competent, demanding work. Only one of them ships a product, and that distinction matters more to a hiring manager than any title on a résumé.

The takes that held up, and what made them different

Not every confident prediction aged badly, and the ones that held up share a common structure, apart from who wrote them. Will Bryk posted a prediction thread in December 2024 and had it scored a year later, and the scoring shows what a durable take looks like from the inside. The predictions were concrete enough to be judged right or wrong rather than vague enough to be read as right after the fact. Bryk flagged real uncertainty directly, writing that it was "unclear how much secret sauce OpenAI has." And he separated two different kinds of claims: technology trajectory, which is comparatively easier to predict from scaling laws and first principles, and societal reaction, which is not easy to predict by any method.

The two predictions Bryk got wrong share a common root. Both applied technology-trajectory reasoning, a method suited to predicting what a model can do, to domains actually governed by organizational and market dynamics: browser use prioritization and Nvidia's competitive position. Reasoning that works for predicting capability does not transfer cleanly to predicting corporate behavior, and that mismatch is the exact failure mode to watch for in any confident technical prediction.

The reply thread under Bryk's post names the same failure from another angle: those who got it wrong tended to underestimate how fast the workflow layer would compound, and overestimated how fast raw capability gaps between models would matter.

Simon Willison's argument that coding agents make his own work harder, not easier, holds up for a different reason. It's grounded in an observed workflow, stated explicitly as a claim about his experience rather than a universal law about all engineers, and falsifiable against any other practitioner willing to compare notes. Chollet's reply holds up for the same kind of reason: it names a structural constant, human cognition, rather than handing down a verdict about where the field stands this month. Neither man needed to be right about the other to both be making a durable argument.

A practical filter for reading Engineering Twitter without being misled by it

Everything above points toward a small set of questions that can be asked of any take before an engineer lets it shape a career decision, a hiring plan, or a six-month roadmap. A take collapsing a segmented reality into one verdict, "remote is dead," "LeetCode is over," should be treated with suspicion, because the segmentation it erases, by company stage, by role, by team mission, is almost always where the real answer is hiding. A take predicting a technology outcome using reasoning that actually depends on organizational or market behavior deserves the same suspicion, since Bryk's two misses followed exactly that pattern, applying first-principles reasoning to a question that was never going to be settled by first principles. A take built on a role taxonomy, researcher versus engineer chief among them, that is actively contested inside the very companies defining it should be read as a snapshot of this month's org chart, not a durable law of the industry. A post generating a wall of replies with no engagement back from its author signals argument rather than agreement, since that pattern means the post is provoking disagreement, not converging toward anything settled.

The opposite signals point toward durability. A take that states the conditions under which its author would be proven wrong is a take that can actually be checked later, the way Bryk's thread was. A take that separates a technology-trajectory claim, more tractable, from a claim about organizational or societal reaction, far less tractable, is doing the analytical work that collapses most Twitter arguments into mush. A take grounded in something observable, a working deploy URL, a real eval harness, a prediction list scored against outcomes a year out, carries more weight than an impression of where the field is heading, however well-argued that impression sounds.

A labor-market projection points toward strong employment growth for software developers through the next decade. That single number sits on top of two very different markets: a softened one for engineers who can only produce basic CRUD applications, and a strong, well-compensated one for engineers who can architect systems, lead technical decisions, and work fluently alongside AI tools. The average flattens exactly the gap that most Engineering Twitter takes ignore, and reading past that average, toward the segmentation it masks, is the same skill this whole filter is built to teach.