The Man Who Built ChatGPT Just Said He Was Wrong About Your Job

Last Tuesday I was reading the morning headlines and almost spilled my coffee.

Sam Altman, the CEO of OpenAI, the person who spent the last three years telling the world that AI would eliminate entire categories of white-collar work, stood in front of an audience at a banking conference in Sydney and said something nobody expected: he was wrong.

Not slightly wrong. Not nuanced-wrong with caveats and footnotes. Wrong enough to go on record saying, "I'm delighted to be wrong about this." Wrong enough to publicly admit that his predictions on the social and economic impact of AI were "pretty wrong," even while his predictions on the technology itself were "roughly right."

I run jsgurujobs.com, a JavaScript job board. I talk to developers every week. I read their messages, their frustration, their fears. And the fear I hear most consistently over the past 18 months is some version of: "Am I learning a dying skill? Is this whole career going to evaporate?" I've watched developers second-guess whether to invest in TypeScript, whether to go deep on system design, whether to even bother applying for senior roles because surely a model will do it in a year.

This article is the one I've been waiting to write. Not because the news is uniformly good, it is not. But because the reality of spring 2026 is dramatically different from the panic of 2023 and 2024, and most of the people writing about it are still stuck in the old narrative.

The bubble did not fully pop. But it cracked, loudly, in ways that matter for you specifically as a JavaScript developer. And understanding exactly where the cracks appeared tells you more about where to invest your energy than any "future of coding" think-piece ever will.

What Altman Actually Said and Why the Timing Matters

The speech happened on May 26, 2026, at a Commonwealth Bank of Australia technology conference. Altman appeared virtually, which somehow makes the moment more striking. The man whose company is preparing to confidentially file for a U.S. IPO targeting a valuation near one trillion dollars went on a video call and said his predictions about entry-level white-collar job losses were off.

His explanation for why the displacement has not happened at the speed he predicted centered on what he called "the human part" of work. He said he underestimated how much professional roles depend on things AI cannot replicate at scale: relationship context, judgment under ambiguity, the ability to be accountable when something goes wrong.

Goldman Sachs CEO David Solomon called the apocalyptic job loss fears "overblown" in the same period. Yale Budget Lab published a May 2026 study concluding that AI was likely not the reason for weakness in the labor market and that there has been no meaningful change in unemployment through March 2026 for workers in roles with high AI exposure.

I want to be honest with you: this is not a clean "everything is fine" story. Altman acknowledged that HSBC, Amazon, and others have made AI-driven cuts. Challenger, Gray and Christmas tallied nearly 50,000 AI-linked job cuts announced by U.S. companies so far in 2026. Goldman's research found that AI reduced monthly U.S. payroll growth by about 16,000 jobs over the past year, which nudged unemployment up by 0.1 percentage points. The effect showed up not through mass layoffs but through weaker hiring, particularly for junior roles.

But the narrative of mass replacement, the one that had developers questioning whether to even stay in the field, has been publicly walked back by the person most responsible for promoting it.

Starbucks Tried to Replace Baristas With AI. The AI Could Not Count Milk.

Here is a story that will stick with you.

In September 2025, Starbucks rolled out an AI-powered inventory system called NomadGo across all 11,000-plus of its North American stores. The technology used LiDAR sensors and tablet cameras to automatically recognize and count items on shelves: milk jugs, syrups, beverage ingredients. The chief technology officer said at launch that it would count inventory "up to eight times faster than manual methods, with 99% accuracy." That press release has since been deleted from the Starbucks website.

By February 2026, Reuters was reporting that employees across multiple locations described the system "frequently miscounting and mislabeling items," confusing similar milk types, missing items entirely, and in one case failing to recognize a peppermint syrup bottle in a promotional video Starbucks itself had uploaded to showcase the tool. That video was also removed.

In May 2026, nine months after launch, Starbucks sent a company-wide memo. It read: "Starting today, Automated Counting will be retired. Beverage components and milk will now be counted the same way you count other inventory categories in your coffeehouse."

In other words: do it by hand.

The PR statement from Starbucks framed this as "a decision to standardize" inventory counting. NomadGo said it is "continuously learning from customer and user feedback." Neither acknowledged the accuracy failures. The system that promised to revolutionize supply chain operations across one of the most data-rich consumer companies on earth could not reliably tell oat milk from 2%.

If AI cannot do a single, isolated, controlled task like counting items on a well-lit shelf in a temperature-controlled room, you can probably imagine what happens when you ask it to understand the full context of a production JavaScript codebase with eight years of technical debt, an inconsistent API layer, three different state management approaches used by three different teams, and a business requirement that lives in someone's email from 2021.

The Uber Story Is Actually More Relevant to You as a Developer

The Starbucks story is dramatic. The Uber story is the one that should make you think.

Uber deployed Claude Code to around 5,000 of its engineers. Usage exploded. The internal leaderboard they built around AI coding tool adoption showed usage rates between 84 and 95 percent. By most engagement metrics, this was a success.

The problem was the bill.

Token costs ran between $500 and $2,000 per engineer per month. The entire AI coding budget for 2026 was consumed in roughly four months. The COO and CEO began publicly questioning whether the ROI justified the spend, even while acknowledging productivity gains. Uber is now trying to figure out how to cap usage and reduce costs without destroying the productivity improvements they actually did see.

What this tells you is not that AI coding tools are useless. What it tells you is that they are expensive, they require human supervision, and the business case is not automatic. Companies are not going to hand five thousand engineers unlimited AI tooling and walk away. They need engineers who understand when the AI output is good, when it is subtly wrong, and when it is catastrophically wrong in a way that will not surface until production.

That judgment cannot be automated. It requires experience with the codebase, with the domain, with the failure modes of the specific stack. It requires exactly the skills you build by going deep on JavaScript rather than assuming the tool will handle it.

From the job board I run, I can tell you something about what I see in postings right now: companies are not hiring fewer senior JavaScript developers because of AI. They are hiring senior developers specifically to manage and validate AI-generated output, to maintain the architecture the tools cannot reason about, and to take ownership of systems that AI cannot be held accountable for.

The Illusion of the AI Developer and the Reality of Messy Codebases

Here is the thing about AI coding tools that most of the hype cycle glosses over: they work remarkably well in isolation.

You can prompt a model to write a React hook that fetches data, handles loading states, and manages errors. The result is often solid. You can ask it to generate TypeScript interfaces from a JSON schema, write unit tests for a utility function, or convert a REST call to use async/await properly. These are real productivity gains.

What the tools cannot do is understand your codebase as a whole. They cannot know that the authentication flow in your app was written by a contractor who left in 2022, that it has a race condition that only appears under specific network conditions, that your team has an unwritten rule to never touch that file without checking with the original architect first, or that the API route you are about to refactor is consumed by a mobile app that has not been updated in eighteen months.

Context is the thing. LLMs are stateless in the way that matters for professional work. They do not know the history. They do not feel the weight of a decision. They do not understand why something was built the way it was, which is almost always more important than what was built.

A developer at a company I have been following wrote me recently and said something that stayed with me. He said: "The AI writes code faster than I do. It also introduces bugs faster than I do. The question is whether I'm fast enough at catching them." That is the actual dynamic in most engineering teams right now. Speed up, but keep the human in the loop. The human is still the one responsible when things break at 3 AM.

This is not a temporary situation. It is structural. The value of JavaScript developers is not being eliminated by models that can autocomplete functions. It is shifting toward the people who can see the whole system, make architectural decisions under uncertainty, and take ownership of what gets shipped.

Why I Think the Skills Panic Is the Wrong Response to a Real Signal

I want to push back on something here, because I think a lot of career advice going around right now gets this wrong.

The panic response to AI has been to chase whatever the newest tool or framework is. Learn LangChain. Build agents. Pivot to prompt engineering. Do something that feels like "AI work" so you do not get left behind.

I think this is mostly wrong for most JavaScript developers.

The people who are going to be most valuable over the next three to five years are not the ones who learned the most about AI. They are the ones who got exceptionally good at software engineering and also learned to use AI tools efficiently. The conjunction matters. The order matters.

I have seen developers on my job board get hired at strong salaries not because they had "AI" on their resume, but because they had deep TypeScript knowledge, could discuss trade-offs in system design, understood performance at the browser level, and could articulate why they made specific architectural decisions. Employers are asking for that. They have always asked for that. The companies that thought they could replace that judgment with a language model are the ones quietly shutting down their pilots.

The companies cutting senior developers and replacing them with AI-generated code are, in a lot of cases, building themselves a problem they will need to hire someone to fix in twelve to eighteen months. I have seen this pattern before in the offshoring wave. The work that looks automatable from the outside looks very different when you are inside the system trying to maintain it.

Lean into the fundamentals. Get better at reading large codebases. Understand the event loop well enough to teach it. Know when to reach for a different data structure. Build something real that people use and maintain it through the messy parts. That is still the actual job, and no language model has taken it yet.

What the Job Market Looks Like From Inside a JavaScript Job Board

I want to give you something concrete here rather than general encouragement.

I have been running jsgurujobs.com for over a year now, and here is what I actually see in the listings, not what analysts predict, not what LinkedIn thought leaders claim, but what companies put in writing when they need to hire someone.

TypeScript is no longer a nice-to-have. I wrote about this when TypeScript crossed 69% adoption, and the shift has continued. I see postings where "JavaScript" is in the title and TypeScript is listed as required in the body. If you are still writing pure JavaScript and avoiding the type system, that gap is costing you interviews.

System design questions are showing up in job descriptions for mid-level roles. Not just senior. Companies want to know that you can think about scale, that you understand why you would choose one approach over another, that you are not just someone who knows syntax. I wrote about this specifically in the context of what interviewers actually test, and the pattern has only gotten more pronounced.

Remote work restrictions have tightened but have not disappeared. Companies are being more selective about timezones and overlap hours, but fully remote roles still exist in volume. From what I see on the board, developers who can demonstrate strong async communication and documentation practices are getting remote offers at rates that surprised me.

The demand for Node.js backend knowledge alongside frontend React skills has gone up, not down. Full-stack capability is being listed more often as a requirement rather than a preference. Companies that used to have the budget to hire separate frontend and backend specialists are working with leaner teams and want people who can cover more ground.

None of this sounds like an industry abandoning human engineers. It sounds like an industry that got overexcited about automation, spent a lot of money on it, discovered that messy real-world problems are harder than demos, and is now hiring the people who can actually solve them.

The Builders Are Still Here and They Are Not Being Replaced

Here is my honest read of where we are in the spring of 2026.

The AI hype cycle hit its peak somewhere in 2024. We are now in the phase that always follows hype: reckoning. Starbucks scrapped a nine-month AI deployment because it could not count milk. Uber burned its AI budget in four months and is trying to figure out what to do. Dozens of enterprise pilots have been quietly retired. Sam Altman went on camera and said the thing he spent years predicting did not happen.

This is not cause for celebration exactly. It is cause for clarity. The technology is real. The productivity gains are real in specific, well-defined contexts. The threat to certain categories of repetitive work is real. But the "developers will be obsolete" narrative was always more useful for fundraising decks and conference keynotes than it was as a description of how software actually gets built.

Software gets built by people who understand the problem, the system, the constraints, and the consequences of getting it wrong. Models are very good at producing code that looks right. They are much less good at knowing whether it is right, why it matters, and what to do when it breaks.

The gap between "looks right" and "is right in production" is exactly where your career lives.

That gap is not closing. If anything, as companies ship more AI-generated code without understanding what they are shipping, the people who can audit it, fix it, and take ownership of it are going to be more valuable, not less.

If you are a JavaScript developer and you have been wondering whether to keep going, keep going. Learn TypeScript seriously. Go deep on the parts of the stack that AI handles worst: architecture decisions, performance under load, security, accessibility, the strange edges of the event loop. Sharpen your ability to read code you did not write and explain what it does and why.

FAQ

Is AI actually replacing JavaScript developers in 2026? Not at the rate predicted. Sam Altman publicly stated on May 26, 2026 that he was "pretty wrong" about entry-level white-collar job losses from AI. Enterprise AI pilots are failing at high rates, and most companies are discovering that human judgment, system context, and accountability cannot be automated out of software engineering.

What skills matter most for JavaScript developers right now? TypeScript proficiency has moved from optional to expected in most hiring decisions. System design knowledge is appearing in mid-level job requirements. Full-stack capability covering both React and Node.js is increasingly listed as a requirement rather than a preference. Fundamentals like understanding the event loop, debugging complex systems, and reading large codebases are what separate candidates in competitive processes.

Should JavaScript developers learn AI tools or focus on core skills? Both, in the right order. Core software engineering skills remain the foundation. AI tools like GitHub Copilot or Cursor improve productivity for well-defined tasks but require experienced developers to validate their output, catch subtle bugs, and maintain architectural integrity. Getting exceptionally good at JavaScript engineering and learning to use AI tools efficiently is a stronger position than chasing AI tooling without the underlying engineering depth.