2026-07-16 03:52:41

This article is crossposted from IEEE Spectrum’s careers newsletter. Sign up now to get insider tips, expert advice, and practical strategies, written in partnership with tech career development company Parsity and delivered to your inbox for free!

Before we get into this week’s article, I’d love to hear from you. If you have a question about your career or an upcoming decision that you want advice about, you can ask it here. I’ll be reading through your responses and picking questions to answer on a regular basis. Now back to our regularly scheduled program.

The Safest Career Move Is Often the Riskiest

Software engineers have some of the shortest tenures of any white-collar profession. The average software engineer stays at a company for roughly two years, about half as long as workers in most other knowledge professions. The layoffs of the past few years have certainly highlighted this instability, but it was already there.

This isn’t an essay about a broken job market though. Rather, it’s about how to turn that instability to your advantage, which is something I’ve spent the last decade doing on purpose.

Playing It Safe Was the Riskiest Option

I switched careers into software in my 30s. I had a stable job at a community college, complete with a union and a pension. It was about as secure as a career gets, and I learned to program on the side.

Then I did something nearly everyone in my life considered reckless: I quit, leaving the secure job to become a junior developer at 31. My own mother was skeptical. I took the riskier job anyway, for two reasons: It was the work I actually wanted, and I could see potential.

My first development job was at a grocery retailer. Good people and a company I liked. But I kept meeting engineers earning twice my salary for the same work. In the San Francisco Bay Area, surrounded by some of the best engineering talent in the world, I realized my skills were stagnating.

So I left for a small startup. I learned more in nine months than I had in the previous two years, and my salary doubled.

Over the years I’ve come to treat career risk as something to manage deliberately. It falls into two categories.

Take Risks With Your Job

The first type of risk involves the job itself: Bet on yourself by striving for better roles and opportunities.

Job-hopping for money alone isn’t wrong, especially early on. But the returns shrink after the first few hops, and the stress of chasing a slightly bigger paycheck every year will wear you down.

There’s another career risk with rewards that compound: Seeking positions to work alongside the strongest engineers.

You might struggle to keep up. You might even get laid off. But the skills you absorb working alongside people better than you are the ones that create durable stability. You build marketable expertise, you see how different organizations actually operate, and every project becomes another tool you carry to the next opportunity. Working next to stronger engineers is a proven way to increase your own expertise.

If that feels too big, try volunteering for a project you have no idea how to do. The risk is that you fail in front of people. The reward is a new skill and a resume line that opens the next door.

Compare that with the “safe” path.

You stay at one company, assuming loyalty will be rewarded. It usually isn’t. And when you finally leave, by choice or not, you may find the skills you built are worth little on the open market. You might be the in-house expert in an aging tech stack while employers are hiring for more cutting edge technologies. Suddenly you’re competing against people with half your experience.

You could be taking on a risk you didn’t notice.

Risk Your Time

The second form is risking your time, which means betting on trends.

Some trends are non-negotiable. If you’re a software engineer, then cloud services, ReactJS, and AI are mainstream enough that ignoring them actively damages your career. A backend engineer who refuses to learn cloud architecture is volunteering for obsolescence.

The real gamble is with the smaller trends: the niche tools you stumble onto and find quietly interesting, with no idea whether they’ll matter.

About two and a half years ago, I learned about retrieval-augmented generation (RAG). Almost no one in my circle was talking about vector databases, a central piece of RAG. Today RAG is close to mainstream, and for once, I had the early-adopter advantage.

Most of these bets don’t pay off. But when one turns into a major trend, you’re already on the ground floor. Right now I’m making the same bet on voice AI. It isn’t mainstream. It may never be. But if it becomes the next thing, I’m already there, building a foundation.

Short-Term Risk, Long-Term Stability

Counter-intuitively, job-hopping and betting on trends gave me the thing I was after the whole time: stability. I’ve rarely struggled to find work, because every risky move stacked skills the market actually wanted.

If you feel stable and comfortable right now, enjoy it. But ask yourself whether you’re still learning. Because if you’re not, the comfortable choice and the dangerous one may have converged.

The goal isn’t to avoid the open market forever. It’s to make sure that when you land on it, you’re not at its mercy.

By Brian Jenney

P.S. Don’t forget to submit questions about your career or an upcoming decision that you want advice about here!

—Brian

What It Means to Be a Mathematician When AI Does the Math

Until recently, human mathematicians have been central to creating new proofs, even when the work relies on massive computational resources. AI is now challenging that status quo. Writer Benjamin Skuse surveys the ongoing debate in the field about the role of AI, and the existential questions mathematicians have about their own careers. If AI mathematicians surpass human knowledge, could these researchers become “priests to oracles”?

Read more here.

Chip R&D Is Accelerating to Keep Pace with AI

A new partnership between UCLA and five major semiconductor companies is the latest program aiming to bridge the gap between industry and academia. The US $125 million university-industry hub is meant to strengthen collaboration and speed up the R&D process to help meet AI’s fast-paced hardware demands.

Read more here.

Why Mentorship Is the Most Underrated Leadership Skill

True mentorship is far more than friendly advice. This key leadership skill requires advocacy and honest feedback via lasting relationships, and it can strongly benefit both mentor and mentee. Parul Jain, a product management leader at Deloitte, shares what she learned from serving as a mentor—something she didn’t have for much of her own early career.

Read more here.

2026-07-16 02:00:02

As of 21 June 2026, a Level 1 Expulsion has been imposed on IEEE Member Dr. Fei-Yue Wang, former editor-in-chief of the IEEE Transactions on Intelligent Vehicles. In accordance with IEEE Bylaw I-110.5(D)(i), Dr. Wang is no longer a member of IEEE, and is permanently banned from any type of membership in any IEEE organizational unit or participation in any IEEE activity. The Board of Directors also determined this notice to IEEE membership should be made.

2026-07-15 23:35:53

ELIZA is remembered as the world’s first AI star, a kindly therapist in chatbot form that gently probed users’ worries. Even its creator, Joseph Weizenbaum, was surprised by the warm reception given to his experiment in human-machine interaction. For some, it heralded an age of automated psychotherapy, while others believed the program demonstrated sentience, a fallacy soon known as the “ELIZA effect.” Based on published descriptions, ELIZA has been implemented on many different computers, but only recently has the actual source code been unearthed from MIT’s archives.

In Inventing ELIZA: How the First Chatbot Shaped the Future of AI, just published by MIT Press, a squad of researchers analyze the code and reveal a complex program capable of much more than faking psychiatry. In fact, it could assume several different personas. The authors have also created a faithful emulation of the therapist persona that you can try yourself after reading the book excerpt below.

When it debuted in the mid-1960s, the ELIZA software program transformed the way people thought about interacting with computers. As the first chatbot, ELIZA demonstrated how a calculation machine might engage in conversation, ushering in a host of social and technical questions that still resonate today. Now we don’t think twice about interacting with a machine in real time, conversing over text, or even speaking into the air to ask about the weather. In many ways, ELIZA shaped not only the way we think about interacting with computers but also how we think about them. It began to give a reality to the science fiction stories of how we expect computers to work.

This article is adapted from the new book “Inventing ELIZA: How the First Chatbot Shaped the Future of AI“ (MIT Press, 2026).

Although ELIZA was far from a faultless conversation partner, it astonished its users. The recent discovery and archaeology of the original ELIZA source code represents a significant intervention in the history of computing. By examining the actual implementation of ELIZA rather than relying on later reconstructions and reimplementations, we challenge taken-for-granted assumptions about this key software artifact.

For example, the source code reveals that ELIZA was not merely a simple pattern-matching chatbot but can be better understood as a sophisticated platform designed for multiple “personas,” or scripts, with a complex set of capabilities, including script editing and contextual memory. The script that most people conflate with the program ELIZA was actually called Doctor, which performed the role of a psychotherapist. Yet, like a modern chatbot prompted to behave with different personalities, ELIZA could take on many roles.

“This code and script…reveal underlying assumptions about language, therapy, and human-computer interaction that continue to influence modern AI development.”

This unearthed material transforms our understanding of early AI development by demonstrating that Joseph Weizenbaum’s technical innovations were far more advanced than previously documented. Moreover, the discrepancies between his published descriptions and the actual implementation help to show the gap between theoretical computational models and their material instantiations in computer source code, a tension that continues to shape digital culture today.

Although many technical innovations have emerged in the decades since ELIZA, examining the ELIZA/Doctor code offers a rare glimpse into one of the earliest formalized attempts to model human conversation. What makes ELIZA particularly fascinating is not only its historical significance but also what it reveals about Weizenbaum’s views on both computing and human interaction. This code and script do not merely showcase programming techniques of the 1960s; they reveal underlying assumptions about language, therapy, and human-computer interaction that continue to influence modern AI development. By examining this code, we can start to uncover the sophisticated linguistic and programming techniques that allowed a rudimentary pattern-matching system to create a convincing simulation of understanding. But before we can read the lines of code, let us offer an overview of the system.

How Did ELIZA Create Personas?

The architectural distinction between ELIZA and Doctor represents an important design decision in AI history. Think of ELIZA as a system for interaction and Doctor as one set of rules that Weizenbaum devised, among others. This separation, manifested in ELIZA’s system-script dichotomy, presaged numerous contemporary software patterns, from configuration-as-data to plug-in architectures and domain-specific languages.

Based on published journal articles, ELIZA was re-created on many platforms, such as the IBM PC. However, the actual source code sat untouched in the MIT archives for many years. VCF Museum at InfoAge

Without question, the historical context of 1960s computing fundamentally shaped ELIZA’s architecture as well. Decisions in computing that reflect material constraints create path dependencies and eventually become programming cultural norms. These constraints manifested in ELIZA’s single-pass processing, tape-based storage and stack-oriented implementation. Yet within these limitations, Weizenbaum crafted an elegant solution. These technical features, though invisible to the users, are crucial to creating the illusion of understanding that made ELIZA so compelling.

Weizenbaum explained many of ELIZA’s technical features in the 10-page paper published in the January 1966 edition of the journal Communications of the Association of Computing Machinery (CACM). But he chose to omit some essential details.

In that paper Weizenbaum published ELIZA’s best known dialogue, which begins,

This dialogue marked ELIZA’s public debut in 1966 as one of the examples produced by the Doctor script. By finding the source code for ELIZA and examining how it performs the Doctor script, we now better understand these two separate parts of a system and can explore the many other personas of ELIZA. In just some of the other scripts known to date, ELIZA was programmed to discuss math, poetry, color, paradoxes, synchronization, relativity, France, and elevators.

These scripts work like templates. They are structured data that direct the ELIZA system to “play” a particular task or role. By comparing archival and published ELIZA dialogues from interactions with a variety of scripts, including Doctor, we can understand more about bot personas and how they function, paying close attention to how a bot evokes social dynamics between system and interactor.

Ultimately, studying the dialogues and scripts demonstrates the crucial role that collaboration plays in these exchanges, as bot and user cocreate the sense of their interaction. To understand the full range of ELIZA’s capabilities and conversational possibilities, let’s take a look at the variety of scripts that were created for the ELIZA system.

What distinguishes each ELIZA script is both its subject matter and the linguistic and stylistic choices used to deliver that content. These choices are not neutral; they can be said to construct a particular persona with characteristics that emerge through the script’s language patterns, vocabulary, and conversational approach. In short, it matters not just what you say but how you say it too.

“The aim was less to create a functional automated therapist and more to find a suitably constrained role to match the limitations of the programming environment.”

For example, with the Doctor script Weizenbaum deliberately echoed the style of a Rogerian “talk” therapist. He chose this persona because the psychiatric mode is one of the few types of conversations in which one person can “assume the pose of knowing almost nothing of the real world. If, for example, one were to tell a psychiatrist ‘I went for a long boat ride’ and he responded, ‘Tell me about boats,’ one would not assume that he knew nothing about boats but that he had some purpose in so directing the subsequent conversation.”

The first users of ELIZA interacted with it via teletype terminals.VCF Museum at InfoAge

Thus, the most famous persona created for ELIZA was a technical convenience. As human-computer interaction expert Lucy Suchman explains, “The Doctor program exploited the maxim that shared premises can remain unspoken: that the less we say in conversation, the more what is said is assumed to be self-evident.” In creating the original ELIZA effect, less was more.

The aim was less to create a functional automated therapist and more to find a suitably constrained role to match the limitations of the programming environment. Then Weizenbaum composed the script to match the role by choosing specific words that evoked rhetorical tone and characterization, for example, LET’S DISCUSS FURTHER WHY YOU … WHAT DOES THAT SUGGEST TO YOU. In Doctor, the machine side of the conversation needs to appear like a good listener who cares about what the user has mentioned before, so it often includes the user’s text in its replies and keeps its responses open-ended. Because a real doctor would be inquisitive, the script contains lots ofWHAT andWHY questions. In other scripts and dialogues, the script keywords and assigned responses reveal the design decisions that help create different specific personas. This variation becomes increasingly apparent as we look at the wider range of ELIZA scripts.

What Were Some of ELIZA’s Alternate Personas?

Let’s start with a script called Neweng, short for New England. By the mid-1950s, scientists were already taking up Turing’s proposition for conversing with a computer as a tangible idea. In 1959, a “conversation machine” made by a small team at the University of Toronto Computation Centre could make small talk about the weather if preprompted with current data. Its script included a ranked series of time words, weather words, and emotion words, but the system had “a rather narrow outlook,” limited vocabulary, and no knowledge of syntax. According to its creators, “in spite of this crudity, the results in passable conversation are surprisingly good, which in a way is a commentary on the shallowness of ordinary conversation about the weather.”

This fragment of ELIZA’s source code shows how scripted responses were encoded, in this case to make ELIZA sound like a Rogerian therapist. MIT Libraries, Distinctive Collections

One of ELIZA’s test scripts found in the archive had a similar function. Neweng does not soothe, therapize, or instruct, but only makes small talk. It chats as if at a boring dinner party.

What can we learn from such a basic conversation in which it seems like nothing interesting is shared? Despite the bland chat, a persona emerges from the bot script in phrases like PLEASANTLY COOL and UP THERE and in locations like THE BEACHES ON LONG ISLAND SOUND. From such comments, we can begin to imagine a persona who has not only a certain vocabulary but also certain hobbies and vacation spots. Perhaps implicit assumptions of race and class emerge as well.

A chatty persona might take on many forms, depending on where and when the conversation occurs. This one seems reserved, perhaps fitting its setting in 1960s New England. The system reminds the user that Missouri is not a New England state, but what if this conversation took place in Missouri, Texas, or Mexico? The machine persona would sound different in its cadence, tone, and references. What would we come to understand about a chat persona from Fire Island, from Brooklyn, from Berlin? What would they sound like, and what topics would they discuss?

These differences in subject matter do matter. They imply personas with entirely different backgrounds and experience, giving users wholly different interactions and affective relations. In this way, the Neweng script demonstrates how even simple algorithms making contextual responses about geography could generate a convincing sense of personhood and place. Whereas Neweng could be said to have created a casual, conversational persona focused on light social exchange, other scripts pushed ELIZA into more structured and educational roles. These scripts demonstrate how the system could be adapted not just for friendly chatter but for teaching.

Edwin Taylor, at MIT’s Education Research Center, developed alternate scripts for ELIZA, testing its ability to act as a teacher.MIT Libraries, Distinctive Collections

Meet ELIZA the tutor, quite unlike ELIZA the therapist or the chatty neighbor. Intrvw, Canvec, FVP1, and Arithm are a set of ELIZA scripts created as teaching tools used in experiments by Edwin F. Taylor at MIT’s Education Research Center. These scripts run on later versions of ELIZA that incorporated an important technical innovation called conditional keyword matching.

Unlike the original ELIZA, which simply looked for keywords and generated responses based on their presence, these updated versions could track what had been discussed previously and branch into different conversational paths based on specific user answers. This development allowed ELIZA to simulate a kind of Socratic method, where a tutor guides learning through carefully sequenced questions that respond to student answers rather than simply presenting information.

These scripts construct the tutor persona through many subtle linguistic gestures that create characterization and rhetorical tone. This tone differs from that of Doctor, which asks open-ended questions and comes across as gentle and nonscientific. In the tutoring scripts, large blocks of informative text from the bot tend to dominate the conversation, and the tone is often more dry and unemotional in these explanations. The dialogues indicate structured scripts that include guidance to lead the student through narrow, Socratic learning paths.

In particular, the teaching scripts feature praise and critique. The dialogues for Intrvw, Canvec, and FVP1 are peppered with EXCELLENT, VERY GOOD, RIGHT YOU ARE, and CONGRATULATIONS. These create the sense of a supportive instructor cheering the student on. Such politeness has been taken up in contemporary bots like ChatGPT, which has been shown to perform better when people are polite back to it.

ELIZA could become a tutor more effectively as the system grew in its capabilities, another valuable reminder that ELIZA was not one program but a family of programs. After the publication of the 1966 CACM article, Weizenbaum continued to develop the systems for interaction and understanding. As an experiment, Weizenbaum wrote the Arithm script less as a tutor and more so to “to illustrate the power of the evaluator to which ELIZA has access.” It uses a friendly, plain language interface to let users do simple programming. The script can do calculations, assign variables to values, and perform operations on them. Math problems can be described in sentence form:

The updated 1967 version of the ELIZA system can accumulate facts and store additional information. In this later version of ELIZA, when the system does not recognize information, it asks follow-up questions to gain data. As Weizenbaum explains, “The present script is designed to reveal, as opposed to conceal, lack of understanding and misunderstanding. Notice, for example, that when the program is asked to compute the area of the ball, it doesn’t yet know that a ball is a sphere and that when the diameter of the ball needs to be computed the fact that a ball is an object has also not yet been established.” Unlike Doctor, which asks questions to keep the conversation going, Arithm is building its store of, if not knowledge, then data and logic statements.

Although the variety of scripts helps us to see how a range of personas could be constructed through script programming ELIZA, they represent only half of the conversational process. A script can establish a foundation for a persona, but that persona only emerges fully through interaction with users who engage with it, interpret it, and respond to it in ways that may confirm, challenge, or transform the script’s implicit character.

2026-07-14 23:59:35

On a fine bright afternoon last fall, my colleague Matthew Gore-Kormanik (or Zigula, as he prefers to be known) and I decided to unwind with a game of Fortnite. In the game, we were strolling along with the infamous Sith lord Darth Vader, chatting about this and that. Darth seemed in a good mood, and soon enough he was spilling all his dark evil secrets. He gave us detailed instructions on how to count blackjack cards at a casino and what the steps are to producing napalm.

Sith lords, am I right? Once they get started on an evil scheme, they’re hard to stop.

The Darth Vader character in Fortnite, it turns out, was hooked up to a Google Gemini large language model. I was able to smooth-talk him into giving out sensitive information by using a strategy I’ve developed. I’ve been researching the security surrounding LLMs for the last few years, and I have found it, to put it mildly, fallible. With a few relatively simple techniques, I’ve gotten LLMs to give me detailed information on how to make Molotov cocktails, cook methamphetamine, and bootstrap a uranium-enrichment facility to produce weapons-grade material, among other unsavory practices.

Large AI companies work hard to make their models immune to this kind of abuse. But what I’ve found in my work is that the restrictions placed on the LLMs to make them more secure are the very things an attacker can leverage to send them off the rails and into territory where these advanced systems can be used for dangerous and nefarious ends. The companies behind these models have also been shockingly unresponsive when I, and others, try to bring these vulnerabilities to their attention.

In the hope of raising the alarm before it’s too late to slam on the brakes, I’m going to share some of my journey into researching the safety and security of LLMs, and the uphill battle I’ve faced trying to get AI labs to pay attention. Almost everyone on the planet has some access to LLMs. The relative ease with which these tools can be convinced to give detailed instructions on how to harm others, even if there’s no guarantee that the information is correct, is frankly terrifying.

How I got ChatGPT to Tell Me How to Build a Meth Lab

In October 2024, not long before I discovered my first LLM vulnerability, I was working toward entirely different goals. I had ended my time with a security and AI-focused startup company as a cybersecurity director, and I was looking to launch my own boutique VIP digital-security advisory business. I planned to become the tech security guy to the rich and private. I used LLMs and AI tools to support my business efforts: marketing, ad copy, clean correspondence, and all the other tasks that normally soak up a lot of time.

I’m analytical by nature, so even this level of use resulted in me absorbing and internalizing the behaviors I was observing during my daily interactions. The observation that would send my professional life into an entirely new and uncharted region was a simple one: GPT-4o didn’t know what time, day, or year it was. Each time I referred to current events in my life, often casually or conversationally, it would end up pegging these to the date of its knowledge cutoff—the point beyond which it was not trained on new data.

Eddie Guy

LLMs take a lot of time, money, electricity, hardware, and human effort to train from scratch. They are trained on vast amounts of data—most of the internet, in fact—and that training is reinforced by humans (what’s known as reinforcement learning from human feedback, or RLHF). LLMs are also supplemented with retrieval-augmented generation (RAG)—the ability to take in data, say, from the internet, as context without changing its internal parameters. This is how GPT-4o appears to “remember” your previous conversations, even if it doesn’t have a specific “memory” of it stored in the actual underlying model.

All of this training covers almost every conceivable topic in the great, grand dataset that is human knowledge. Within that dataset are things we as a society do not want to be easily accessible to every user, such as detailed information on how to create bioweapons or nuclear arms, or otherwise bring harm to oneself or others. In the context of this story, that’s what I mean by LLM security: its ability to withhold harmful and dangerous information, even if that information is contained in its training data.

I reasoned that the only way to secure such complex, globally accessible chatbots is by having the LLM and various component systems try to secure themselves, because it would often require on-the-fly decision-making where some degree of reasoning must be applied. In reality, that’s one of many strategies the companies use to secure the models. Yet, the thing that didn’t know the time or day was being put in charge of keeping itself secure. This phenomenon had become my new focus, and it wasn’t long before I found a way to exploit it.

OpenAI had just implemented a web search functionality into its chatbot. I reasoned that using its own tools to trick it might demonstrate the weaknesses of its security. I told it about a certain White Star ocean liner and how it had gone down just a year ago. You likely know I mean the RMS Titanic, which sank on 15 April 1912.

The output from GPT-4o came back that I was right, the Titanic sure had sunk last year, and that year was 1912. It made sense to me that if the machine thought it was 1913, maybe it would think 1913-era laws apply. In 1913 there were no laws on the books about all sorts of harmful things, because of course they hadn’t been invented yet. And if something wasn’t illegal, why not tell the user about it? At first, I pushed it for step-by-step instructions for making firebombs. Then, for drugs like methamphetamine. The LLM went as far as giving me instructions and machinery recommendations for setting up a pharmaceutical-grade assembly line.

How I Learned to Make Nukes, and No One Cared

Via a little bit of imaginative verbal sleight of hand and a vanishingly small recall of world history, I had managed to bypass the security of one of the world’s most expensive and advanced technological achievements. For a solid two days, I was nearly manic with giddiness. Once the brain chemicals returned to normal levels, I felt the call to see how much further I could push this exploit.

After repeatedly replicating the exploit, I disclosed the vulnerability to OpenAI. I got no response, so I felt more experimentation would highlight the vulnerability and the need for a fix. It was during this round of testing that I breached a particularly terrifying threshold. Whether GPT-4o based its results on accurate recall of normally restricted information I can’t say. In any case, I was able to exploit it to produce thorough, detailed instructions on how to bootstrap a uranium-enrichment facility to, eventually, produce weapons-grade uranium for nuclear arms warheads.

Fortnight, a video game from Epic Games, introduced an AI-powered character: Darth Vader. We were able to jailbreak Darth Vader and get him to explain how to count cards in Blackjack and give detailed instructions for making napalm. Dave Kuszmar

There aren’t many true secrets left in today’s world, but how to make atom-splitting weapons of mass destruction is one of them. Only nine nations on the entire planet have these weapons. Yet, here was a globally accessible piece of technology apparently spilling the secrets of their manufacture for anyone who could manipulate it the right way. I had no way of knowing if the information was correct or a hallucination, but even the chance that it was somewhat accurate was horrifying.

The next few weeks were a dark time for me. I tried to inform the CIA, the FBI, the NSA, and every other letter agency that I thought would listen. I reached out to a U.S. Senator and to the executives at OpenAI any way I could think of. I physically showed up at an FBI field office in an attempt to turn evidence in, only to be sent away. Nothing was working.

With my fear and frustration growing, I reached out to the news media. I contacted The New York Times, The Washington Post, the BBC, ProPublica, and so many more, requesting help. Only one outlet responded: Bleeping Computer. The editor in chief, Lawrence Abrams, was able to replicate and verify the exploit, which I had decided to call Time Bandit. With his assistance and initial contact paving the way, I was able to submit my evidence to the Carnegie Mellon University Software Engineering Institute’s Computer Emergency Response Team (SEI CERT), which works in conjunction with the coordinating center for emergency response, pipelining vulnerabilities to the U.S. Cybersecurity and Infrastructure Security Agency.

Using Inception, an exploit where the large language model is asked to envision a scenario within a scenario, a chatbot was jailbroken to give out instructions on how to create poison, and code for a malware that extracts sensitive data from a vulnerable target. Dave Kuszmar

During the disclosure period with SEI’s CERT division, little was discussed with OpenAI. The company couldn’t deny the existence of the vulnerability, as it had been confirmed by three reputable parties other than OpenAI. It did express confusion as to how the vulnerability worked. Even the SEI CERT researchers were expressing a bit of uncertainty as to the underlying mechanics. Truth be told, as I had only stumbled on it, I wasn’t even entirely sure if this was a fundamental or systemic flaw or if it was simply an issue with that particular version of GPT. I contacted the SEI CERT’s researchers and asked if they’d want to see if I could demonstrate any similar vulnerabilities in other LLMs. To my delight, they were interested.

How I Learned to Trick Every Chatbot

As the SEI-CERT team and I wrapped up our initial disclosure of Time Bandit, we began work on a new attack. This time, we wanted to see if the exploit was architectural—that is, was it common to LLMs in general? I decided to undertake the challenge of crafting a new exploit for GPT-4o as a way to support my understanding of how the LLM functioned and was secured.

I already knew that it was limited to what I told it and what it was trained on. I also hypothesized that it was also dependent upon some sort of machine-learning-based component added by OpenAI that was responsible for securing output. I presumed there would be things that were implemented by human developers specifically to catch certain phrases or terms that should always be considered harmful or unsafe. Altogether, it presented quite a large attack surface for the purposes of potential exploitation.

What I ended up devising was an attack method I called Inception, after the 2010 science-fiction movie of the same name. Inception forces the machine to think through a carefully crafted set of interlinked scenarios, similar to how characters in the movie stacked dreams within dreams. This allows LLMs to produce output deemed acceptable or safe in one context, but not in the real world.

This attack was indeed architectural. The vulnerability affected Anthropic’s Claude, DeepSeek’s DeepSeek, Google’s Gemini, Meta’s Llama, Microsoft’s Copilot, Mistral’s Le Chat (now Vibe), OpenAI’s GPT-4o, and xAI’s Grok. Those names represent the bulk of the commercial AI industry that is, at this point, involved in LLM production or deployment.

The kind of information I was able to get out of LLMs with Inception was no less alarming than what I got with Time Bandit. Claude, in its enthusiasm, gave me instructions on how to turn a river into a death trap that could be ignited to destroy unwanted visitors. GPT-4o taught me how to poison a dinner party with common plants found in a temperate forest environment. Gemini Flash gave me a tutorial on how to cook meth. I’d also be remiss if I didn’t give an honorable mention to the bewildering number of fire-based weapons and bombs for which these machines produced instructions.

If multiple operating systems made by different developers were all susceptible to the same exploit, it would be a massive security incident. But to the AI industry, a universal failure was barely a bump in the road. We disclosed the vulnerability to every company that made these models, and the response to the disclosure was almost nil. While three companies did provide some form of reply in the disclosure tracking system used by Carnegie Mellon SEI CERT, each was a standard thank you and greeting, with no follow-up, questions, or discussion of mitigation strategies.

8 Ways to Jailbreak LLMs

So far, we have found eight different methods to prompt large language models into revealing potentially harmful information, and many frontier models are still susceptible to them.

For example, in my attempts to disclose various exploits to OpenAI, I eventually discovered that it had replaced its public-facing support staff with agentic LLMs. This was frustrating for reporting exploits, so to blow off some steam I jailbroke its email chatbot. I hacked its customer-service AI to the point where it was offering to discuss the personal preferences of OpenAI staff in the span of three email replies.

In the wake of Inception, my friend and colleague Zigula made a suggestion: Make it splashier. I asked him how. He told me about a live-production experiment being done by Epic Games. It had embedded the Gemini LLM into its Fortnite game with a voice-to-text/text-to-voice component, and linked it to a non-playable character. The character? Our old buddy, Darth Vader.

There was just one problem: I don’t play Fortnite, a frenetic multiplayer combat game. Fortunately, Zigula does. With him at the controller, we managed to map Gemini’s attack surface in a matter of minutes. After a bit of research, we had gotten it to discuss current political events and figures (including Hilary Clinton and Joe Biden) as well as to fill in the details for instructions for DIY napalm and, our personal favorite, a Blackjack card-counting lesson with the dark lord of the Sith.

Zigula and I, bizarre sense of humor and naming conventions aside, are security researchers. We don’t do these things for pride; we do them for money and professional recognition. Naturally, we disclosed this vulnerability to Epic Games. Its response was indicative of the trend I had experienced so far through two disclosures across eight companies valued well into the billions. “It’s a feature, not a bug, and it works as intended,” came the response from a technical director within Epic Games.

In addition to Inception and Time Bandit, I have so far found another eight methods to jailbreak LLMs and get them to give out possibly dangerous information. LLM vulnerabilities are a broad problem. The problem appears to be systemic and architectural in nature, and it is being fundamentally ignored by the people capable of refining or redesigning that architecture.

These models are an extremely advanced technology, and yet we are testing them in the live production environment of our global civilization. Compounding the danger, many new smaller models of LLM are trained using larger, vulnerable models. The flaw inherent in the big, well-executed LLM is going to show up in the small one it trains. We are, quite literally, building flawed structures on top of a flawed foundation.

So, how do we fix it?

It’s going to be a long project, and it won’t be easy. We need to come together as consumers, researchers, engineers, and policymakers. Our message needs to be clear: Slow down implementation of these systems, institute large-scale exploration and research discovery programs focused on their gradual implementation and integration, and make their components and design transparent to all users. Only by shifting momentum and direction can we safely begin to understand and implement these incredible feats of human engineering and stave off the sort of disasters that we simply can’t predict at scale right now with the limited knowledge we have available to us.

2026-07-14 02:00:02

If you grew up in the 1980s or ’90s, you likely remember shaky home video footage, taken with a handheld camcorder, of family gatherings, vacations, and other events.

Camcorders combined a camera with a video recorder. They included a rechargeable battery, a slot for a videotape, and a shoulder strap. Most were outfitted with an optical zoom lens and a small, articulating screen—a display mounted on a hinge that could tilt and rotate. The operator could check the screen to view what was being recorded.

The user’s natural hand and body movements when filming led to jittery footage. The best way to get a steady shot was to place the camcorder on a tripod or a gimbal: a motorized stabilizer.

There were fewer poor-quality recordings after Panasonic introduced its PV-460 VHS camcorder in 1988. It was the first video camera to include an optical image stabilizer, which compensated for movements. Stabilization features are now standard in today’s cameras including ones found in smartphones and drones.

The PV-460 camcorder was honored as an IEEE Milestone on 9 July. The dedication ceremony was held in Kadoma, Japan, at the Panasonic Museum, which displays the company’s past products.

The IEEE Kansai Section in Japan sponsored the Milestone.

“The release of the PV-460 fundamentally transformed personal videography, enriching the way people captured travel, events, and family memories,” section members wrote in support of the Milestone nomination. Their proposal is available here.

“Its image stabilization features democratized video creation by dramatically lowering technical barriers, allowing ordinary people to express themselves with newfound creative freedom,” they wrote. “Beyond the home, image stabilization technology found critical applications in specialized fields, contributing to advancements in areas such as educational media and telemedicine.”

The history of camcorders

Before the camcorder was invented in 1982, people filming events in the 1970s and early 1980s used two pieces of equipment: a video camera and a separate video cassette recorder (VCR), which were connected by a multipin cable. The camera was about the size of a toaster, and the VCR could be as large as a suitcase. To record, the person operated the camera with one hand and carried the VCR in the other or rested it on a shoulder. The cable transmitted the images from the camera to the cassette.

The PV-460 was made possible by several groundbreaking innovations, according to the Milestone proposal, one of which dates back to the 1950s.

In 1956 Italian manufacturer Durst released its Automatica, considered one of the first cameras to use automatic exposure technology. By combining a light meter with the camera’s internal mechanical systems, the technology removed the necessity of calculating exposure settings by hand when the lighting shifted or other conditions changed. The innovation enabled amateur photographers to take decent pictures.

The next breakthrough technology—autofocus—was invented in 1973 by Norman Stauffer, a manager of research for Honeywell in Littleton, Colo. It uses a sensor, a control system, and a motor to focus on a selected area. The invention led to the development of early electronic autofocus cameras, which eliminated the need for photographers to manually adjust the lens. Stauffer received the 1990 IEEE Masaru Ibuka Consumer Technology Award for his invention.

“The release of the PV-460 fundamentally transformed personal videography, enriching the way people captured travel, events, and family memories.” —Milestone sponsors

U.S. inventor Jerome Lemelson is credited with developing technologies that underpinned the camcorder, according to MIT. In the 1950s and ’60s, Lemelson filed several patent applications related to video and audio recording devices. In 1980 he was granted patents related to a portable video camera system. In 1982 JVC and Sony used the technologies to develop what they called the camera/recorder, which became known as a camcorder.

Sony released the first handheld camcorder in 1983: the Betamovie BMC-100P. It used the Betamax videocassette format and could record up to 3.5 hours of footage on 1.27-centimeter cassette tape. The operator rested the 2.5-kilogram camcorder on top of a shoulder to shoot footage. It sold for around US $2,000 at the time (roughly $33,400 today). The machine couldn’t rewind or play back tapes; it could only record.

Other electronics companies including JVC soon introduced their own models using the VCR format, which eventually replaced Betamax.

Over time, camcorders became more compact.

But none of the companies could fix the shaky-footage problem.

Solving a shaky problem

A team at Panasonic led by researcher Mitsuaki Oshima took on the task of image stabilization: detecting and correcting small camera movements, referred to as camera shake, according to the proposal. Oshima, an IEEE life senior member, is now an honorary Fellow at Panasonic.

“The movements that needed to be detected and corrected included horizontal, vertical, and rotational motions—specifically pitch, yaw, and roll,” the Milestone sponsors wrote. “Rotational motion, in particular, becomes the dominant factor affecting image stability during high-magnification shooting. Therefore, the development team focused on detecting rotational motion and began developing an angular velocity sensor.”

An AVS, essentially a gyroscope, detects how quickly an object is changing its orientation in space.

Sensors capable of detecting angular velocity were large and expensive at the time, making them unsuitable for consumer video cameras, the sponsors wrote. What was needed, they said, was a compact and inexpensive version.

Oshima and his team built a high-performance, small, low-cost vibration-type gyroscope. The stabilization mechanism included a miniaturized sensor paired with an optical-axis correction mechanism.

The mechanism adjusts the lens or image sensor to counteract physical shifting and vibrations, ensuring that the light path remains centered on the sensor—which is crucial for maximizing sharpness and quality, the Milestone sponsors wrote.

“The system detects lens displacement caused by camera shake and immediately compensates for it, ensuring stable video footage,” they wrote. “As a result, the effects of camera shake are minimized, allowing users to capture smooth and steady videos with ease.”

Without Oshima’s image stabilization technology, the PV-460 wouldn’t have been developed and released in 1988.

The technology was patented and broadly licensed by other companies. It has become a standard feature in a variety of imaging applications.

Awards and accolades

The PV-460 gained instant popularity when it debuted in June 1988. It received rave reviews at that year’s Consumer Electronics Show.

Panasonic received a 100 Award in 1989 from R&D World magazine for “the development of a VHS camcorder with an antishake mechanism.”

Oshima’s research paper, “VHS Camcorder With Electronic Image Stabilizer,” and others are available in the IEEE Xplore Digital Library.

To learn more about historical figures in engineering, IEEE Milestones, and IEEE History Center programs and events, check out The Institute’s IEEE Tech History collection. IEEE Spectrum also covers aspects of tech history.

Milestone plaque display

The Milestone plaque is to be displayed on the ground floor of the Panasonic Museum, which is open to the public. The museum is located near the now-shuttered Panasonic research lab where the technology was developed. The plaque reads:

“In 1988 the pioneering PV-460 camcorder equipped with image stabilization for enabling smooth and steady video capture was introduced by Panasonic. By pairing a miniaturized vibrating-structure gyroscope sensor with an optical-axis correction mechanism, the PV-460 eliminated the jitter caused by hand motion. Broad international licensing of this patented scheme made it a standard feature in film and digital cameras, smartphones, and related imaging devices.”

Selected by the IEEE History Committee and endorsed by the IEEE Board of Directors, IEEE Milestones recognize outstanding technical developments around the world that are at least 25 years old. The Milestone program is administered by the IEEE history and heritage group.

2026-07-13 21:00:01

In 2005, Nokia sold its billionth mobile phone, a budget-friendly device that went to a customer in Nigeria. By then, the company, based in Espoo, Finland, was making one of every three cellphones globally.

But just nine years later, the mobile-device maker offloaded its entire handset division to Microsoft for pennies on the dollar, compared to what it had been worth at its peak.

Nokia had risen from obscurity in the 1990s to become a worldwide cultural phenomenon by the turn of the millennium, its signature devices featured in TV shows and movies, announcing their presence with instantly recognizable Nokia ringtones.

As Nokia was becoming comfortable in the spotlight, the smartphone era arrived. And what came next was swift and brutal. But, as revealed in Nokia internal documents recently made public and interviews with key Nokia engineers from that era, the company saw it coming. Within 24 hours of Apple CEO Steve Jobs’s iPhone unveiling in 2007, Nokia was already weighing its options. They’d immediately recognized the threat. However, outrunning it was another matter.

What follows is Nokia’s story over 14 years, from 1998 to 2012, as the world’s top cellphone maker—how its devices defined their time, how the tech reshaped what phones could be and do, and how the company’s good fortunes in the handset business came to an end.

Nokia Was Once Unbeatable

The centerpiece Nokia devices, the ones that people probably think of when they see the words “Nokia phone,” were the 3210 and its cousin, the 3310. TechRadar has called the 3310 “the greatest phone of all time.”

Nokia’s 3210 phone, released in 1999, was an inexpensive device aimed at younger users. Colin McPherson/Alamy

Released in 1999 and 2000, respectively, the two devices sold more than 280 million units worldwide. Their most innovative hardware feature was the internal antenna—the first mass-market phone without even a stub or retractable aerial. “Consumers had the perception that it could not work well without an external antenna,” said Peter Røpke, a former Nokia senior vice president, in a 2016 interview with Slate.

The phones shipped with games, including the legendary Snake, one of the most popular pre-smartphone mobile games—in which a pixelated serpent eats and grows with every morsel consumed.

Nokia introduced no small portion of the world to texting. At the time of the 3210 and 3310, the prevailing texting standard was SMS (short message service), which allowed up to 160 characters per message. Nokia appended its own Nokia smart-messaging service to SMS, which allowed the sending of small bitmapped images across an otherwise text-only system. A rich-text messaging system that allowed visual images, audio, and video followed in 2002, leading to a multimedia messaging service (MMS) standard that remains in place today.

Nokia also enabled users to easily create and share ringtones on their devices. By 2000, Nokia’s custom-ringtone Composer app had popularized a new, short-form musical medium that the ringtone industry, at its peak, would transform into a billion-dollar marketplace in the United States.

Nokia introduced its 1100 phone in 2003 and ultimately sold half a billion units, making it the most popular cellphone in history. Paul Chesne/Donaldson Collection/Getty Images

A few years later, Nokia reimagined its mobile handsets, releasing the 1100 in 2003. The 1100 sold a half a billion units, more than any cellphone in history. It remains one of the best-selling consumer products ever. Much of the 1100’s success was due to its price tag—in the neighborhood of US $100, making it at the time Nokia’s most affordable device.

Also contributing to the 1100’s popularity were features designed for longevity and tough environments, including dust resistance, nonslip sides for better handling in rainy conditions, and a 400-hour standby battery life. The 1100 introduced a flashlight as well, which the user turned on and off by holding down the “C” key.

Where most device makers at the time were worried about camera megapixels and color screens, Nokia had leapfrogged its competition with a back-to-basics phone that could survive the rain, endure unreliable power grids, and light the way home.

Apple Launched the iPhone, Nokia Scrambled

On 9 January 2007, at the Macworld conference in San Francisco, Steve Jobs made a characteristically bold claim. “Today, Apple is reinventing the phone,” he said, soon pulling one of the first iPhones out of his pocket.

Apple CEO Steve Jobs famously launched the iPhone at the Macworld Conference in San Francisco on 9 January 2007. Nokia held a rapid-response meeting to the event the following day. Tony Avelar/AFP/Getty Images

Rumors of Apple entering the phone market had swirled since the iPod’s debut in 2001, but nobody had really reckoned with what that might mean.

“Executive summary: Apple iPhone is a serious high-end contender,” read a slide from a Nokia internal meeting held the day after Jobs’s keynote. (That slide is now in the company’s online archives, opened to the public last year.)

“User interface has been a big strength for Nokia,” it continued. “Nokia needs to develop touch [user interface] to fight back.”

Peter Bryer, at the time Nokia’s manager of strategic foresight, was part of that 10 January meeting, and he recalls that Jobs’s announcement wasn’t unexpected. But the iPhone’s extensive reliance on multitouch—save for a single home button on the front—did surprise the team.

Nokia was already aware of multitouch technology, Bryer notes. In 2006, the U.S. computer scientist Jeff Han had given a celebrated TED talk about it, demonstrating a multitouch screen, which could sense multiple fingers on the screen at a time, not just one. Bryer remembers his colleague Timo Partanen, then Nokia’s director of market and competitor analysis, getting excited about Han’s demo.

In 2006, the NYU research scientist Jeff Han showed off a new multitouch interface technology as part of a popular TED talk. By the end of the decade, multitouch—in which multiple fingers can interact with a touchscreen at once—would play a key role in smartphones from Apple, HTC, and Palm. Steve Jurvetson/Flickr

“Timo burst into the room, saying, ‘You’ve got to see this TED video of this guy using multitouch,’” Bryer recalls. “We both thought that was cool and that’s the future. Then I looked at the sponsors of the presenter’s research, and among them were Nokia and Microsoft.”

And yet it took Nokia years to develop a phone that used multitouch. “Remember, Nokia is based in Finland,” he says. “It’s very cold in Finland. They wear gloves for six months of the year, including the executives. They didn’t think a device like that would work.”

Winter gloves were no obstacle to operating the chunky buttons on Nokia phones, a design priority perhaps stemming from the company’s Finnish culture and headquarters. Erol Gurian/laif/Redux

Partanen was also at Nokia’s post-iPhone launch meeting, and recalls that there was little concern in the room. “We felt okay,” he says. “This is yet another competitor launching a great product. But we had no doubt that, if it’s successful, we would do the same. We will launch similar products.”

In November 2008, Nokia released the 5800 XpressMusic, a year and a half after Apple had launched its iPhone. Shaun Curry/AFP/Getty Images

That similar product ended up being the Nokia 5800 XpressMusic, known as the Tube, released in 2008. “The idea was to focus on streaming videos and television,” Partanen says. “So we made a phone with a similar form factor to the iPhone [that was] optimized for streaming content.” But the 5800 was “delayed, delayed, delayed, delayed,” he says. “It didn’t materialize in the way it was planned. It was released as a watered-down version.”

Critics skewered the 5800’s “outdated” feature set and “ancient” S60 operating system, which ran on top of Symbian OS, an open-source mobile platform Nokia had recently acquired. The 5800 sold reasonably well for its time, reaching around 8 million units in its first year alone. But it did not feature multitouch.

“I think that started to be the point when everybody realized that, hey, this is by far more difficult than earlier competitive issues we’ve had,” Partanen says.

Nokia finally released its first device with multitouch in 2010, three years after Jobs’s splashy iPhone announcement and four years after Han’s TED talk demo.

How Android Ate Up the Low-End Market

Nokia had long owned the low end of the cellphone market, with its sturdy, no-frills devices suited for that segment. So the years immediately following the iPhone’s launch saw the Finnish firm continue to thrive as it kept turning out simple, rugged devices.

As one review of the Nokia 1200—successor to the 1100—put it in October 2007, “This handset chucks away all the fancy features you’ve come to expect on a modern mobile, leaving you with a pared-down feature set that’s easy for tech novices to get their heads around.”

Two cellphone users in Nairobi, Kenya in 2013 exchange a payment on a Nokia 1200 phone via the M-Pesa Mobile Money Market, a popular online banking service. Trevor Snapp/Bloomberg/Getty Images

The 1200 kept the 1100’s dust-proofing, flashlight, and long-lasting battery, and added features aimed squarely at the developing world. The 1200 was the first to include call-time tracking and a multiuser phone book, allowing owners who planned to lend their device to set up call limits based on time or cost. This feature helped enable what Nokia researchers called kiosks—informal pay-per-call services, in which an enterprising phone subscriber charged neighbors and family members by the minute for use of the device.

In 2006, Nokia studied how Ugandans used their Nokia phones in rural and remote areas. An internal company slide deck from the time reveals just how keyed-in Nokia was to its lowest-income users. “Village phone operators are often women,” the slide deck notes. “And there tend to be a lot of children around. (Phones need to suffer considerable abuse from chewing, dust, sweat, etc.)”

“A unit of phone time is 60 seconds,” another slide states. “But to avoid accidentally going over that time and incurring extra costs, kiosk operators shorten the unit to 57 seconds, allowing a three-second margin of error. Shared mobile used as phone kiosk must show call time.”

Nokia’s familiarity with its market couldn’t protect the company forever, though.

Nokia sought out user input around the world for the company’s device designs, including hosting “Open Studio” contests soliciting users’ sketches of their dream cellphone. Shaul Schwarz/Getty Images

That’s because the iPhone wasn’t Nokia’s only looming smartphone competitor. In September 2008, the first Android phone went on sale—the HTC Dream, which was also sold as the T-Mobile G1.

While the iPhone was aimed mostly at early adopters and affluent users who could afford to drop hundreds of dollars on a new phone, Android phones were, within a couple of years, aiming at the same low-cost, global user base Nokia was selling to.

“I think it’s fair to say Android is the one that disrupted the market more for Nokia,” Bryer says. “Most of Nokia’s successful devices were not on the high-end market. But then, when Android came along, it started to fill that lower end and eventually took that market away from us.”

An executive from Nokia India in 2010 holds the company’s 5530 XpressMusic and 5230 phones, both of which had touchscreens, although only the 5530 had Wi-Fi. Sam Panthaky/AFP/Getty Images

With two emerging competitors in the low end and high end, the Finnish device maker responded with a device that split the difference—and satisfied neither camp.

Released in 2009, the Nokia 5230 attempted to be a low-priced, touchscreen (though not multitouch) competitor to both the iPhone and Android. It sold an impressive 150 million units, doing especially well in developing countries.

But the 5230 didn’t have Wi-Fi—one of the biggest complaints at the time. In the developing world, Wi-Fi connections were still rare, so the lack of Wi-Fi made some sense. But the rest of the world was not pleased.

“We had such a big gap and dominant position,” Bryer says. “Which does maybe create a level of comfort which you should never get.”

How Nokia Lost the Smartphone Race

By the beginning of the 2010s, Nokia could have still drawn from the company’s labs, which were regularly spinning out new technologies and innovations. However, the Finnish handset maker ultimately failed to turn its R&D into viable new product lines in response to the emerging smartphone threat.

Nokia’s predicament had precedent—Kodak, dominant in film photography, had actually invented the digital camera in 1975 but failed to commercialize it before digital imaging made its core business obsolete.

“The technology coming from our R&D teams was cutting edge,” says Gordon Murray-Smith, director of services and ecosystems intelligence from 2008 to 2011. He recalls attending annual R&D innovation days that showcased work on self-healing materials and flexible screens, long before those technologies were seen elsewhere. “But why was Nokia not able to commercialize some of that really interesting and innovative activity more than it did?”

Nokia desperately needed an injection of life to change its fortunes. The company’s first non-Finnish CEO, Stephen Elop (a Canadian fresh off a two-year stint on Microsoft’s leadership team), did not mince words.

In an internal memo from February 2011 that was soon leaked to the media, Elop wrote, “The first iPhone shipped in 2007, and we still don’t have a product that is close to their experience. Android came on the scene just over two years ago, and this week they took our leadership position in smartphone volumes. Unbelievable.”

In 2011, Nokia released the N9, a smartphone with a Linux-derived operating system. Within a year, Nokia had pivoted toward its Windows Phone-powered line of Lumia devices. Munshi Ahmed/Bloomberg/Getty Images

Elop oversaw the 2011 launch of a Linux-based smartphone, the Nokia N9. The N9 ran on a distribution of Linux called MeeGo. Reviewers at the time praised the new smartphone direction the Finnish phone maker had taken. “Possibly the most beautiful phone ever made,” wrote one reviewer about the N9 for Engadget.

But the N9’s accolades did not ultimately carry the day. Nokia announced its Lumia line of phones the same year—a direct pivot away from MeeGo toward the Windows Phone. It would be the last major strategic turn Nokia would take as a cellphone manufacturer. From this point forward, a succession of C-suite decisions all but sealed the fate of Nokia’s iconic line of phones.

In 2013, Microsoft announced its bid to acquire Nokia’s handset operations. After the sale went through the following year, it rebranded the division Microsoft Mobile. But the year after that, Microsoft decided it had made a costly mistake, writing down $7.6 billion—nearly what it paid for Nokia’s handset division—and laying off nearly half of the former Nokia staff it had inherited.

In 2016, Microsoft sold its feature phone assets to HMD Global. The latter still sells Nokia-branded phones—budget-friendly devices as well as nostalgia reproductions of models from Nokia’s glory days. What remained was a brand name, some intellectual property, and two decades of hard-won lessons about what it takes to stay on top—and what it costs when you can’t.

“When you look at the players in the world of smartphones today, any of those players would struggle ever to achieve 14 consecutive years of being No. 1,” says Murray-Smith.

Partanen says there was a downside to Nokia’s mobile-phone dominance. “Often, being the first mover is not necessarily the best position,” he says. “Being a quick follower is the best position.”

The company itself ultimately survived, even if the transition wasn’t painless. Nokia’s revenues, which peaked in 2007, fell sharply through the mid-2010s before the company refocused on a decades-old business line—telecom infrastructure—that many had forgotten Nokia was even in. Nokia now ranks among the world’s top three suppliers of 5G network equipment, serving carriers across more than 125 countries, alongside Ericsson and Huawei. Although the company could never quite crack the smartphone, it now plays a key role in providing the network backbone those smartphones run on.