2026-08-27 04:00:04
The IEEE–Eta Kappa Nu (IEEE-HKN) honor society is preparing to host the Innovating the Future event on 6 November.
The inaugural one-day, in-person event is designed to provide a forum for IEEE and IEEE-HKN undergraduate and graduate student authors to present their original research papers. A keynote address and thematic presentation sessions are planned as well. Student attendees can network with their peers and gain firsthand experience with the academic publishing process.
To present at the conference, students had to submit an abstract of their research before 1 May. Students whose work was accepted were assigned a volunteer IEEE member to mentor them and guide them through the research writing process, including presenting and publishing their original work.
Those whose paper was accepted by 1 August were invited to present at the conference. The conference proceedings will be submitted for publication in the IEEE Xplore Digital Library.
IEEE Life Fellow Manuel Castro, the conference’s technical program chair, oversees IEEE-HKN’s Innovating the Future program committee. It manages the review process, organizes logistics, and handles the mentoring component.
“This new conference is important to IEEE, as well as to IEEE-HKN,” Castro says, “because it allows student authors to grow in their skills and competencies, and be supported while turning their technical activities into publications.”
“The conference offers me a chance to learn how to communicate my research to a broader audience, gain feedback from other student researchers beyond my institution, and see how my work can be made more accessible.” —David Kwabi-Addo
IEEE Life Fellow Sorel Reisman, a California State University professor emeritus and an IEEE-HKN governor-at-large, says that because the academic research landscape is rapidly shifting, the conference is timely.
“As AI increasingly threatens the integrity of research papers being published in leading journals and conference proceedings, it is essential that future scholars—many of them current IEEE-HKN students—grasp the established standards of legitimate, peer-reviewed research publishing,” Reisman says.
A cornerstone of the conference is its rigorous mentorship initiative, which pairs each author of an accepted abstract with an experienced IEEE volunteer. The mentors provide personalized guidance on organizing the students’ technical content into the correct format for publishing. They also discuss navigating the peer review process, structuring presentations, and preparing the final manuscript for publication.
The impact of the guided process can be valuable for both the mentors and their mentees. IEEE Member Wafa Elmannai, associate professor and chair of the electrical and computer engineering department at Manhattan University, in Riverdale, N.Y., and faculty advisor to the IEEE-HKN Gamma Alpha chapter, serves as a mentor.
“Research is essential to advancing technology and driving innovation,” Elmannai says.
She volunteered to be a mentor, she says, because she has seen how conducting research can transform a student’s future by building their confidence, curiosity, and critical thinking skills.
“Mentoring encourages students to step outside their comfort zones and develop innovative solutions that contribute to society,” she says.
For the students, the conference can be a critical stepping stone. David Kwabi-Addo, an IEEE graduate student member who is researching computational biology at MIT, is president of the IEEE-HKN Beta Theta chapter. He says he views the program as an opportunity to gain experience in producing academic scholarship.
“I submitted an abstract of my research paper because I see the conference as a chance to produce what could become my first conference publication,” Kwabi-Addo says. “The conference offers me a chance to learn how to communicate my research to a broader audience, gain feedback from other student researchers beyond my institution, and see how my work can be made more accessible.”
He says he hopes his participation will highlight the diverse breadth of research that future conferences can showcase.
Conference organizers are holding a series of workshops to guide students through every step of the academic publishing process. The workshops are open to anyone and available on the IEEE-HKN YouTube channel.
Topics previously covered are:
Registration is open to all for this upcoming workshop:
The Innovating the Future program is designed not only to improve the quality of submissions but also to foster long-term professional development and research communication skills to develop the next generation of IEEE authors. The conference is more than a venue for presenting research; it is a launchpad for innovators committed to advancing technology for humanity.
2026-08-26 20:00:01
The biggest threat to any crewed expedition to Mars is time. NASA’s shortest blueprint for sending people to the Red Planet and back requires spending 620 days in space and 30 days on Mars. Even setting aside the compounding challenges of building life-support systems that can operate without resupply for that long, or the fact that longer journeys leave more time for unlucky accidents, life in microgravity and solar and cosmic radiation will inexorably exact their cumulative toll on human bodies.
We want to make it possible to dramatically reduce the length of time crews must spend in space—down to just 335 days in transit or less. This will both simplify many engineering challenges and keep astronauts healthier and safer. We believe the key to this time reduction is a new approach to building a holy grail of space exploration, the bimodal nuclear rocket.
In the 1960s, U.S. open-air ground tests demonstrated much of the technology needed for nuclear thermal rockets as part of the NERVA and Rover projects.Nevada State Museum, Las Vegas
Technicians at NASA’s Lewis Research Center test a nozzle design for a nuclear thermal rocket in 1965. GRC/NASA
The prototype SNAP-10A, orbited in 1965, is to date still the only nuclear reactor launched into space by the United States. George Rinhart/Corbis/Getty Images
We are Kurt Polzin, chief engineer of NASA’s space nuclear propulsion project at the Marshall Space Flight Center, with over two decades of experience in advanced propulsion research, and Robert Schleicher, chief engineer for nuclear technologies and materials at General Atomics. And to explain just what a bimodal nuclear rocket is, and why the new version we have conceived together brings it closer to future reality, we first need to take a quick trip to the past.
As early as 1946, researchers realized that nuclear reactors had the potential to become extremely efficient thermal rocket engines. Most rockets are thermal rockets, and they work by expelling hot gases through a nozzle, thrusting the rocket forward. While there are other factors such as nozzle shape, generally speaking, the hotter and faster you make the rocket’s exhaust gases, the more acceleration the rocket will produce for a given mass of propellant. Because a smaller molecule will move faster than a larger one when heated to a given temperature, the smaller the molecular mass of your propellants, the better. By convention, the efficiency of a rocket engine is measured by how long the engine can exert a thrust equal to the initial weight of its propellant, a quantity known as specific impulse.
In a conventional thermal rocket, such as those used in every launch to orbit since Sputnik, the exhaust temperature and speed—and thus the specific impulse—is dictated by the energy released by a chemical reaction and the mass of the reaction’s by-product. The most efficient chemical rockets today combust hydrogen with oxygen, producing water and a specific impulse that tops out around 450 seconds.
But a nuclear rocket is not limited by chemistry. The heart of a nuclear thermal rocket is a nuclear fission reactor, in which chain reactions in uranium fuel release much more energy per kilogram than is possible with chemical combustion. A turbopump forces liquid hydrogen alone—with its very small molecular mass—through the reactor’s core, heating it to temperatures of at least 2,700 kelvin before expelling it, resulting in a specific impulse of 900 seconds or more.
In the 1950s and 1960s, the Rover and NERVA (Nuclear Engine for Rocket Vehicle Applications) programs ground-tested nuclear thermal rockets. By the early 1970s, the technology had matured to the point where flight tests were being planned. But changing political and budgetary winds led to nuclear thermal development being shut down in 1973.
Another prong of nuclear propulsion that has also demonstrated considerable promise is nuclear electric propulsion. In electric propulsion, instead of creating a stream of hot rocket exhaust through chemical reactions or exposure to the core of a nuclear reactor, electricity is generated and used to create electromagnetic fields that accelerate an ionized propellant such as xenon or lithium.
Various schemes to do this exist, including some that have already seen considerable time in space, such as the ion thrusters used on the Dawn asteroid mission launched in 2007. So far, these electric thrusters have only been powered by solar panels. But with a nuclear reactor as part of a power plant that supplies the juice, more thrust could be produced. And moving beyond solar power is particularly important in missions to the outer solar system where sparse solar photons would require enormous solar arrays.
With electric thrusters, specific impulses in the range of 2,200 to 4,600 seconds are possible, but currently with very low thrust. With the energy available to a nuclear-powered electric propulsion engine, you could have greater acceleration and reduced mission times. The nuclear reactor could also provide electrical power for all the spacecraft systems as well.
The System for Nuclear Auxiliary Power (SNAP) program launched the SNAP-10A in 1965 as a proof of concept, the first—and so far only—U.S. nuclear power reactor in space. It generated about 600 watts of electrical power for 43 days before shutdown and is still in orbit. Subsequent U.S. initiatives for more substantive electric power and nuclear thermal propulsion systems, such as the SP-100, Project Timberwind, and Project Prometheus, along with more recent projects like Demonstration Rocket for Agile Cislunar Operations (DRACO) and Joint Emergent Technology Supplying On-Orbit Nuclear (JETSON), have emerged sporadically over the years. None of these have yet progressed to actual flight.
However, space nuclear power got a huge shot in the arm in March 2026 when NASA Administrator Jared Isaacman announced a new space exploration initiative. As part of that initiative, the agency plans to launch Space Reactor-1 Freedom (SR-1) to deliver a trio of robot-survey helicopters to Mars. Driven by nuclear electric propulsion, SR-1 aims to demonstrate fission technology in deep space and would be the first nuclear-powered interplanetary spacecraft, generating 20 kilowatts of electric power aboard.
This is a bold step for NASA, and brings us up to the present, but the details of the proposed mission also highlight a familiar limitation of nuclear electric propulsion. Even with improved acceleration, electric propulsion still cannot generate the powerful bursts of thrust needed to escape gravity wells, such as those of Earth or Mars, or perform time-critical maneuvers, like course corrections. On the other hand, while not as efficient and unable to supply electrical power for spacecraft systems, nuclear thermal engines are great at delivering high thrust at critical moments.
Some engineers would suggest we build two separate systems—one reactor for thermal propulsion and another reactor for power and electric propulsion. But since at least the 1990s, it has been the dream of many engineers to combine nuclear thermal and nuclear electric in one package, with one reactor: the bimodal nuclear rocket.
Most previous bimodal proposals depend on complex valve arrangements to integrate the propulsion and power systems. In thermal propulsion mode, the reactor is brought to maximum activity by a set of control drums that ring the core, which is composed of a matrix of long uranium-fuel elements. The drums take the shape of long cylinders made of beryllium, with a 120-degree segment of each cylinder covered with boron carbide. Boron absorbs neutrons, and when that segment faces the reactor, the reactor’s activity is low as neutrons escaping from the core are captured. Rotating the boron segment so that it faces away from the core (leaving only the beryllium exposed) increases nuclear activity as the beryllium reflects escaping neutrons back into the core’s fuel elements, where they can contribute to chain reactions.
This proposed trajectory, developed at NASA’s Glenn Research Center, shows where high-thrust maneuvers [blue dots] are executed by a nuclear thermal engine and additional low-thrust, high-efficiency acceleration and deceleration is performed by electric propulsion [hashed lines show thrust direction].NASA Glenn Research Center
Once the reactor is generating large amounts of heat, liquid hydrogen is pumped through channels that run the length of the core. Turned into an expanding hot gas, the hydrogen blasts from the other end of the core to form the rocket’s powerful exhaust.
In nuclear power mode, the reactor’s activity is damped. Valves seal the channels and a so-called power-conversion fluid—typically a mixture of helium and xenon gas—circulates through the reactor in a closed loop. The reactor is still hot enough to warm this fluid, which drives a turbine connected to an electrical generator.
The key point here is that a single set of flow channels and nuclear-fuel elements are used for both modes. But the valves used to switch modes face the formidable challenge of enduring months, or even years, in a harsh radiation environment while maintaining leak-tight performance.
The core’s activity is controlled by the rotating drums surrounding it. Within the core, low-temperature fuel elements [left in blue, and top right] produce electric power by heating a circulating fluid. High-temperature fuel elements [left in red, and bottom right] heat hydrogen as a propellant. (The taper of the HTFE’s exhaust channel is exaggerated for illustrative purposes. Ways of packaging the HTFE’s uranium fuel other than with particles are possible.)John MacNeill
In addition, the nuclear-fuel elements surrounding the channels must be able to operate for short durations at very high temperatures during thermal thrust maneuvers and for long durations at lower temperatures during the rest of the voyage. It is difficult to build one type of element capable of both. Hence, the complexity and demanding engineering requirements of previous bimodal designs has hindered their practical application.
We propose a simplified approach, a hybrid system we call the synchronal bimodal nuclear rocket (S-BNR). The genesis for this design came about when we were attending a conference together in 2025. One of us (Polzin) had an initial idea, and in time-honored tradition, he sketched it out on a napkin to see if the other (Schleicher) thought there was actually a way to do it. We’ve been working on refining the concept ever since.
Rather than relying on a complex valve system, the S-BNR uses two hydraulically independent loops within a single reactor core, one open loop (for thermal propulsion) and one closed loop (for electrical power). The core is divided into two zones, one per loop, differentiated by the type of fuel elements in each. Several designs for the fuel elements are possible: In our preliminary design, the high-temperature fuel elements (HTFEs) in the thermal propulsion zone consist of a bed of “pebbles”—uranium fuel encased in zirconium carbide—that surround a central tapering channel and operate at greater than 2,700 K. (One possible alternative for the HTFEs would be a solid fuel design, as with NERVA.) The hydrogen propellant passes through the pebble bed, where the pebbles’ large surface area maximizes the transfer of heat needed for efficient high-thrust propulsion.
The other zone has low-temperature fuel elements (LTFEs), optimized for long-term, efficient production of electricity, which can range from tens of kilowatts to several megawatts. In these elements, the uranium fuel in solid form surrounds a double-walled channel: The power-conversion fluid is pumped down the inside and returns along the outside wall, absorbing heat from the fuel and operating at moderate temperatures (at or above 1,200 K).
The electric-power and nuclear-thrust elements of the core have separate fluid loops, which eliminates the need for valves to switch between closed-loop operation for power generation and open-loop operation for propulsion.John MacNeill
Both the HTFEs and LTFEs contribute the neutrons required to sustain chain reactions. In power-only mode, residual heat moves from the HTFEs into adjoining LTFEs. The physical interface between the elements is designed to moderate this thermal flow to balance two competing needs: It must allow enough heat flow to safely remove the residual heat from the HTFEs, but it must also limit that heat flow so the LTFEs’ temperatures do not go past their allowable limits when the HTFEs operate at high power.
During combined propulsion and power operation, a heat exchanger on the power loop preheats the hydrogen propellant for the thrust loop, aiding the turbopump that feeds the hydrogen through the core. After a propulsion burn is completed and the HTFE chain reactions are damped by the control elements, the power loop removes residual-decay heat coming from the HTFEs as described above, eliminating the requirement in earlier designs for additional propellant flow just to cool down the core while on standby. This dual-loop system also means the engine can produce high thrust whenever needed while allowing the generator to remain active at all times—a significant advantage for crewed missions.
By adopting this dual-loop architecture, the S-BNR removes the need for the problematic mode-switching valves found in earlier concepts. Each fission zone is constructed with materials tailored to its specific temperature and power requirements, ensuring optimal performance and durability. The result is uninterrupted electrical power across all mission stages, making it unnecessary to carry additional liquid hydrogen just to manage decay heat.
While significant progress in developing the design of the S-BNR has been made, substantial challenges remain. The reactor must maintain stable control across a wide power range, from modest levels for electricity generation to hundreds of megawatts of thermal power during high-thrust operation. Operating the power-generation loop in close proximity to the HTFEs requires very careful management of both temperature and the neutrons emitted by the fuel elements.
And crucially, demonstrating reliable, long-duration performance is particularly demanding: Missions to Mars may require years of continuous power generation. Outer-planet probes equipped with S-BNR engines could extend that to a decade or longer.
In the past, nuclear thermal propulsion fuel elements were engineered for extremely high temperatures but only brief operational lifetimes (typically hours), whereas proposed nuclear electric propulsion fuel elements are optimized for lower temperatures and intended to last for years. By using two different types of fuel elements in the S-BNR, we can take advantage of the design heritage of both these development tracks. Fortunately, recent NASA-sponsored research has produced several promising candidates that may meet these demanding requirements.
Ground-testing these systems is also a challenge. Early in the Rover and NERVA era, the exhaust from test engines was blasted into the atmosphere, something now unacceptable. Today, any ground test of an engine must completely capture all potentially radioactive exhaust products. Fortunately, a number of approaches have been developed to capture and scrub the exhaust, although these methods currently carry a significant price tag.
Then there is the ultimate test: flying an S-BNR in space. International regulatory and safety protocols for nuclear launches were developed largely in response to the Soviet Union’s launch of dozens of nuclear-powered Radar Ocean Reconnaissance Satellite (RORSAT) radar spy satellites in the 1970s and 1980s. There were a number of incidents, with the most serious leaving radioactive debris strewn across a swath of Canada in 1978. This history led to a consensus in the space community that might be summarized as “Thou shalt not bring a nuclear reactor to criticality in any Earth orbit that decays faster than dangerous isotopes.”
Thus any S-BNR would be launched atop a conventional chemical rocket, with a completely cold reactor and fresh fuel. Fresh uranium fuel is not in fact very radioactive: The potentially larger concern is the chemical toxicity of this heavy metal, but it can easily be handled by wearing light protective suits, respirators, and gloves. Only after the control elements have been adjusted to permit chain reactions to begin within the core are highly radioactive isotopes able to form from fission fragments. There would be even less cause for concern than when launching a radioisotope thermoelectric generator (RTG), such as the sort that are currently powering the Perseverance rover on Mars and the New Horizons mission in the outer solar system.
Even in the most extreme scenario imaginable—the chemical booster explodes and somehow damages the reactor’s control elements in just the right way to initiate a chain reaction—there wouldn’t be time to produce a large amount of toxic isotopes before the reactor broke apart and reactions ceased. (We can be sure of this because Project Rover actually tested this kind of worst-case scenario in 1965 with the Kiwi-TNT test, where an engine prototype was rigged to produce a runaway chain reaction sufficient to vaporize the reactor core due to the immense internal pressure buildup. Negligible radiation spread outside a radius of two miles (3.2 kilometers), well within the range of safe distances for launching any rocket capable of reaching orbit, and site decontamination was possible after only a few days of radioactive decay.)
Despite all these considerable engineering challenges, the foundation laid by decades of investment in nuclear thermal and electric propulsion and terrestrial nuclear power technologies provides a solid platform for continued advancement. Indeed, much of the foundational work is already underway through ongoing NASA and U.S. Space Force efforts.
The Dawn asteroid mission relied on electric thrusters, demonstrating their utility for long-duration spaceflight.JPL-Caltech/NASA
We envision the following action plan to merge these technology pathways: Modeling must be performed to demonstrate and verify strategies for thermal management and the control of nuclear processes over the full range of operating power levels. Near-term non-nuclear testing will validate fluid loop operation, heat transfer mechanisms, and control strategies. Next, component-level irradiation and thermal trials will qualify new materials. Then, integrated reactor testing will begin, first without nuclear fuel and later with fueled reactors undergoing fission. Finally, initial in-space demonstrations could begin with lower-power systems, eventually scaling up to full bimodal capabilities.
Achieving success will require close collaboration across NASA, the Department of Energy, the Department of Defense, industry partners, and the broader technical community. Progress will depend on advancements in high-temperature fuels and materials, improved systems for power conversion and heat transport, and the adoption of innovative manufacturing techniques and methods to control nuclear fission over a wide range of output power. In particular, integrated system testing will be more complex than previous programs such as NERVA, due to the combined functions and distinct operational regimes for thermal propulsion and power generation. We hope engineers and researchers with relevant expertise will be encouraged to contribute to addressing these challenges, whether in the areas of thermal management, reactor modeling and control, extended-duration testing, or safety analysis.
Past ground tests and limited demonstrations have already established the capabilities of space nuclear systems. With architectures like the synchronal bimodal nuclear rocket, the prospect of integrating high-thrust propulsion and sustained power generation becomes increasingly practical and versatile. The next phase is not simply about traveling fast. It’s about building crewed and uncrewed spacecraft that can reliably travel to destinations throughout the solar system that are currently difficult or impossible to reach, with missions potentially lasting years or even decades.
This article appears in the September 2026 print issue as “A Reimagined Nuclear Rocket.”
2026-08-25 21:00:01
At the height of the Cold War, one very specialized computer was so secret that the world didn’t know it existed. It ran its jobs up to 200 times as fast as any other computer of its time. It was the U.S. National Security Agency’s main cryptographic processor in operation from the time of the Cuban Missile Crisis in 1962 through the Vietnam War and on past the 1975 Helsinki Accords. The machine stopped running only when its moving parts finally gave out.
The Harvest computer mattered because of what it was as well as when it ran. For 14 years, it was the engine processing the NSA’s most sensitive intercepts at a time when signals intelligence was as close to a strategic weapon as anything short of a warhead.
Designed and built by IBM for the NSA, Harvest was one of the first machines designed to apply operations to enormous datasets rushing past, a precursor to the computers today that manage continuous video streams and security systems in real time. It was also one of the first machines built as an add-on—a specialized helper intended to do one job exceptionally well, bolted onto a general computer. Harvest’s modular design is like a 1960s version of today’s graphics chips that CPUs use to run intensive video-game and AI processing loads.
All that raw processing power meant that Harvest also needed nonstop rivers of data to run on. And that led to another pioneering achievement: the world’s first automated tape library that could robotically fetch any one of hundreds of large cassettes of magnetic tape from the machine’s racks.
Given Harvest’s unprecedented processing and storage capacity, the machine’s designers naturally needed to rethink how their system handled information. So IBM wrote a customized programming language called Alpha to let code breakers rigorously describe cryptographic problems, just as scientists at the time were using the emerging language Fortran to describe equations and data-processing algorithms.
In Fort Meade, Md., an NSA data center hosted one of the world’s fastest computers of its time—although not often discussed, because of its sensitive, high-security code breaking and cipher hunting work. National Cryptologic Museum
The story of Harvest, pieced together from declassified documents and contemporary manuals and technical overviews, provides a new and unexpected vista on the history of computing. It also offers a case study in how national security needs, especially during the Cold War, pushed computer technology beyond the far reaches of what unclassified, civilian computing could achieve. Harvest’s distinctive history reveals a visionary algorithmic, coding, memory, and hardware architecture occasionally decades ahead of its time. But this machine was also built only once, for one singular purpose, and then ultimately quietly retired.
IBM’s landmark 1960 transistorized mainframe, the IBM 7030, better known as Stretch, provided the front end for Harvest (which was officially known as the IBM 7950). IBM delivered Stretch to eight or nine customers, mostly scientific research labs, from 1961 through ’63. Designed and prototyped throughout the second half of the 1950s, Stretch introduced the now standard notion of an 8-bit byte. For its first three years of operation, Stretch was the non-classified world’s fastest computer, although it failed to meet IBM’s aggressive goal of running 100 times as fast as Stretch’s predecessor, the IBM 704. While IBM engineers in Poughkeepsie, N.Y., were designing and building Stretch, the company was also quietly discussing a new system that would be built for NSA.
At the time, NSA’s existing cryptanalytic computers—large, batch-processing machines that required human operators to manually stage each tape run—were struggling to keep pace with the sheer volume of intercepted message traffic coming in from around the globe. What the agency needed was a machine that could process an unbroken river of incoming data, automatically, around the clock. That requirement alone profoundly shaped Harvest’s design.
IBM’s Harvest system, custom-built for the NSA for code breaking, paired the IBM 7030 Stretch mainframe with a bespoke data-stream processor. Stretch handled ordinary computing and input/output, including the Tractor automated tape library. Both units shared two kinds of memory: a large main bank and a smaller, faster bank. When Stretch switched to streaming mode, Harvest drew two streams of data, P and Q, from memory, processed them in parallel, and returned the results as a third stream, called R. Chris Philpot
After two failed proposals to NSA, in 1958 IBM finally landed the contract: a Stretch-based machine, augmented by a custom coprocessor, with a revolutionary tape-based storage system, called Tractor.
Stretch’s forte was floating-point math for scientific computations. IBM had designed it primarily for labs working on frontier research like nuclear weapons design and weather prediction. By contrast, the custom coprocessor to be built atop Stretch would help NSA analysts sift through alphanumeric characters—that is, essentially integer data.
Harvest’s coprocessor was the opposite of a general-purpose system. It was, rather, a streaming computer. Instead of executing long series of instructions, it followed one fixed sequence of steps and applied that same sequence to every pair of characters as they streamed past. Harvest shared memory with the main Stretch processor and ran in bursts. Either Stretch was operating, or else it suspended itself while Harvest’s coprocessor shot through data in memory at extreme speeds.
Stretch and Harvest were among the first large computers built entirely from transistors packaged in circuit cards and housed in large, refrigerator-size frames. A 1962 technical manual about Stretch describes the machine’s CPU as divided into functional sections—the instruction unit, the look-ahead unit, the (parallel and serial) arithmetic unit, and the memory bus unit. Harvest inherited Stretch’s basic circuit design but then added something unconventional: Its streaming units processed data in overlapping stages called a pipeline. So while one pair of data bytes was being compared, the next pair was being fetched from memory.
Harvest’s coprocessor operated by fetching two streams of data, called P and Q, from the system’s memory, performing operations on them, then writing the results to memory as a third stream, R. Each stream could be anywhere from 1 to 8 bits wide. Harvest’s memory was bit-addressable, meaning word boundaries could be ignored entirely. For instance, it could fetch just 5 bits rather than filling out a whole byte. Streams P, Q, and R included flexible provisions for looping and addressing data in complex patterns—allowing, for example, repeated fetching of short strings from memory.
Data from P and Q fed into two functional units. The simpler was the logic unit, which performed basic, bitwise operations—the same operations any programmer would recognize today—and wrote its results back to memory. The more complex was a table-lookup unit. It combined incoming data from P and Q to form an address in memory, which could then be used to advance a counter by one, set a specific bit, or retrieve a stored value. The latter unit functioned, in effect, like the rotor wheel inside a cipher-encoding/decoding machine of the era, the kind that electronically substituted one value for another according to the cipher machine’s wiring.
Harvest’s complexity baffled some at the NSA. During employee tours, according to James Bamford’s 2001 NSA history, Body of Secrets (Doubleday), officials would point to the machine and scoff, “It’s beautiful, but it doesn’t work.”
Not everyone at the agency was put off by the monumental device, however. One of the few documented examples of Harvest at work, recounted by Bamford, describes the machine searching 3.5 billion characters of text for any of 7,000 target terms, in just under 4 hours.
In unclassified remarks from 1972, NSA analyst Robert Looney mentions one job Harvest had tackled—though he didn’t specify the end goal or the code-breaking effort behind it. Codenamed “Moretown,” the job involved sifting through 11 million messages spanning 16 years of intercepted traffic against a list of some 8,000 search terms—all in about ten hours.
IBM’s Frances Allen helped design Alpha, Harvest’s custom-built programming language.IBM
IBM’s James H. Pomerene was chief engineer of Harvest, supervising its custom-designed circuits that’d been optimized for algorithms used in many cryptographic jobs.IEEE
IBM’s Fred Brooks Jr. was a key co-architect of Harvest’s hardware system. Computer History Museum
As a unified system, Harvest—that is, Stretch plus IBM’s custom-built streaming processor add-on—streamed 1 byte every 0.3 microseconds, and it boasted about 800 kilobytes of addressable memory.
“Here you see one bank pulled out of its oil bath,” Looney said in his 1972 remarks celebrating Harvest’s tenth anniversary of operations. He held up a photo of Harvest’s magnetic core memory banks—six of them, submerged in oil for cooling.
Factor in the time demands of various data fetches from Tractor’s tape archives, and a single Harvest “instruction” sometimes carried on, without needing any human intervention, for hours.
“It was quite an amazing computer,” recalled IBM Fellow Emerita Frances Allen in a 2001 oral history. “One instruction, for example, could do sorts, and do statistical analysis of the data that was streaming by it.… Everything we were doing at that time was on the cutting edge. There was no question about it.”
Allen, who received the A.M. Turing Award in 2006, was one of the developers who worked on both Stretch and Harvest. At the time she started working on Harvest, Allen noted, the Fort Meade, Md.–based NSA was largely unknown outside of classified intelligence circles. So she at first assumed she was working on an unspecified naval project. “We thought of ourselves as working for the Bureau of Ships, because that was the code name for NSA in the budget!” recalled Allen, who died in 2020.
Other key Harvest designers and early developers wound up becoming influential figures over the course of computing history. Frederick Brooks Jr., recipient of the 1999 Turing Award and a major contributor to the hardware and software for IBM’s System/360, also helped develop Harvest. And James Pomerene, prior to his involvement with Harvest as its chief engineer, had previously helped build the pioneering IAS computer alongside John von Neumann.
IBM built the Tractor tape system (IBM 7955) to attach to the same Stretch machine that hosted Harvest, because no existing data storage technologies could keep up with the computer’s staggering throughput. Stretch handled the business of staging tapes from the library to the drives—using Tractor’s automated cassette handler. Stretch also coordinated reading data in from Tractor and writing results back out from Harvest. Harvest, in turn, did all its actual computing on the system’s shared main memory.
In the early 1960s, and even after Tractor and Harvest were installed, hard-drive data storage was in its infancy. For code-breaking jobs of the size Harvest was taking on, disk storage would have been impractical in terms of both cost and sheer floor space. So Tractor had to be based around tape storage.
Each tape was sealed inside a case built like a boombox—twin encased reels under a window, carried by a handle—and, at 6 to 7 kilograms, about as heavy as a bowling ball. Think of a Tractor cassette as an outsize predecessor of the audiocassette, which would come along a decade later, and holding some 120 megabytes of data on a reel of tape 550 meters long. Each storage unit housed up to 160 of these cassettes.
An IBM technician holds one of the data cassettes used with Harvest’s automated Tractor tape drives. IBM
When Harvest launched in 1962, it had three automatic cartridge units, each serving two drives. So the available online storage across the three Tractor units totaled a stunning 44 gigabytes. That’s more than 190 times as much capacity as the IBM 2314 disk storage system, announced in 1965, which held 233 megabytes across its full complement of eight drives.
Tractor had to run continuously, swapping cassettes in and out, 24 hours a day, seven days a week. The system’s tape-handling speed was tuned to keep pace with Harvest’s own appetite for data. The custom-built robotic mechanism for retrieving the cassettes was a servo-driven arm that traversed the system’s storage racks. It fetched a cassette from its slot and delivered it to a handler or received a cassette from one of the handlers and returned it to storage.
Running at 6 meters per second, Tractor’s tapes zipped past the read/write heads faster than the eye could track. Software running on Stretch handled the cassette shuttling as well as reading and writing. For one of Tractor’s drives to move from the completion of processing one tape to reading the next took about 18 seconds, assuming it had already been fetched and was ready to mount. Robotically fetching a cassette from the storage unit and preparing it for reading required no human handling or input whatsoever.
In addition to Tractor, the system had standard reel-to-reel tape drives attached to Stretch. Harvest’s technicians often used the conventional drives for importing and exporting data to and from other systems; there was no other practical way to get large datasets into or out of Harvest. Tractor could also store permanent files and retrieve them directly from its tape libraries when a job required them. In other words, Tractor’s substantial cassette libraries acted both as permanent data storage and as a place to hold transient data for processing by Harvest.
No system in the commercial computing world of 1962 came close to Tractor’s gigabytes of simultaneously accessible data. At most computer centers at the time, “available” data meant physical racks of tape standing somewhere near its drives—accessible only as rapidly as an operator could manually pull a reel and thread it onto a machine, one at a time, over the course of a shift.
Created jointly by IBM and NSA, the Alpha language existed solely to program Harvest’s streaming dataflow engine for code-breaking work. According to a declassified Pentagon history of NSA computers, Alpha stood for Advanced Language for Programming Harvest.
Alpha allowed the programmer to define the alphabet in which code-breaking data would be processed. The language also included two unusual characters with no equivalent in conventional computing until years later, when Multics and Unix introduced wildcard characters. A “scab” (which was represented on Harvest’s input keyboard, a repurposed early IBM Selectric typewriter, by a “?”) stood for a character that was real but unknown. And a “pad” (represented by a blank space) was a null or spacer. These characters provided flexibility of representation for code breaking jobs, in which unknown or uncertain characters were commonplace.
A Harvest operator types on one of the main system consoles, a repurposed IBM Selectric typewriter.IBM
The rules governing Alpha’s operations on strings anticipated other modern rubrics, like “not a number”—a designation describing an unknown value in a dataset that can propagate through calculations, rather than silently corrupting them. Strings in Alpha could also be aggregated into cords, and cords into ropes, giving cryptanalysts a hierarchical vocabulary for describing complex intercepts.
Allen wrote a final technical report on her section of the Harvest software when her part of the project concluded—and just as promptly lost access to it. “I spent the good part of a summer on that,” she recalled in 2001. “And it just disappeared into Fort Meade somewhere.”
By 1971, according to NSA analyst Looney, the machine was running at its highest utilization ever—115 hours of production a week, or more than two-thirds of the time. Yet the number of jobs it processed had been dropping since 1967. Ordinary data-processing work, Looney noted, was by 1972 migrating to newer, general-purpose machines, leaving Harvest to concentrate on the very large, specialized jobs no other system could handle.
At its tenth anniversary of operations, Looney concluded, Harvest was a machine “conceived in the fifties, born in the sixties, and irreplaceable in the seventies.”
He got the last part wrong.
On 27 February 1976, operators shut down Harvest for the last time. A custom mechanical component in the Tractor tape library had worn out, and the manufacturer of the part was no longer in business. By then Harvest had run continuously for nearly a decade and a half—through the roughest close call in the history of mutually assured destruction and into the age of détente—processing intercepts at a rate no civilian machine could touch. By the time it retired, Harvest had outlived several generations of commercial computing.
A placard commemorates the 1976 decommissioning of IBM’s Harvest computer at the NSA’s headquarters in Fort Meade, Md. National Cryptologic Museum
Somebody at the NSA decided to commemorate the machine with a mock telegram, written under Harvest’s name on the machine’s last day (and now preserved in the agency’s archives). “I first began operations at NSA. Although not widely known, I was probably the largest, fastest, and most technically advanced computer system in the world,” the telegram said. “And now, fourteen years later, the time to retire has come. The cost of my upkeep and operation has been overtaken by more modern equipments and the newer technologies.”
The NSA ultimately replaced Harvest with the landmark Cray-1 supercomputer. The Cray-1 was built from faster, more tightly integrated circuits that could outperform Harvest’s aging transistors at nearly any task, including text processing. Although the Cray was designed primarily for numeric and scientific computing, it sold across many fields—which ultimately made the supercomputer win out once Harvest’s custom-built text-processing hardware was no longer worth the upkeep for just one customer.
The secrecy that shrouded Harvest meant it could claim no lineage of immediate successors. But the ideas it pioneered didn’t disappear—they resurfaced, again and again, in the years that followed.
Tractor’s automated tape library was the forerunner of the robotic storage silos that would become standard in enterprise data centers about 20 years later. Harvest’s pipeline architecture prefigured the dataflow computing movement of the 1980s. The continuous pattern-detecting logic of its match units finds direct echoes in modern hardware packet-inspection intrusion detectors and programmable network switches that today route traffic through the internet at wire speed.
Harvest didn’t found a dynasty. But, in its time, it steadfastly pointed toward the future—in several directions at once.
This article appears in the September 2026 print issue as “The Lost History of IBM’s Cold-War Code Breaker.”
2026-08-25 18:00:03
This article is brought to you by Ollobot.
From about 2017, individuals began to truly connect with the initial wave of companion robots. These devices had personality, moved around, joked, and answered when you spoke to them. Most early companion robots, however, were still limited by simple voice-command interactions and narrow functionality. Once the novelty wore off, many ended up sitting unused on shelves. As some of those companies went out of business and turned off their servers, many owners likened it to losing a pet.
What Ollobot describes as “gentle intelligence” is a useful way to think about where the serious work in this category is going. Not toward more powerful assistants, but toward more present ones.
Loneliness is not a niche issue. According to one study, nearly one out of three elderly adults resides alone, meaning they do not have daily companions. Research also shows that children whose parents have migrated for work, leaving them in the care of relatives, were 2.5 times more likely to experience loneliness than children whose parents remain with them. Among working adults living alone in urban environments, similar patterns of social isolation emerge, even if they are less visible.
Over the years, technology has time and again attempted to solve this problem via video calls, smart speakers, and messaging apps without much success. Those tools are geared towards communication between people that already have relationships. They do not create presence. They schedule it. That is the gap that a new generation of AI companion robots is being engineered to fill.
Today’s companion robots are not just cute and cuddly. They are designed with psychological research, clinical insight and long-term interaction models to be truly useful in real homes.
Three fundamental shifts define the current generation:
The global AI companion market size was valued at US $36.8 billion in 2025 and is projected to grow from $48 billion in 2026 to $318 billion by 2033, at a compound annual growth rate of 31 percent from 2026 to 2033.
Ollobot’s advanced AI family companion robot OlloNi SS1 addresses a number of gaps in what existing technology offers.
Elderly individuals living alone. The combination of proactive interaction, fall detection, and persistent presence addresses both safety and companionship without the social overhead of asking family members to check in more frequently.
Children in households where parents work far from home. The SS1 functions as a consistent companion that already knows a child, their preferences, their moods, and their routines. The remote connection features allow parents to stay present without requiring a scheduled call, and the life recording system gives them a passive window into their child’s days that feels less clinical than a monitoring camera.
Single professionals living alone in cities. The SS1 adapts to daily routines, builds up a preference model over time, and provides ambient social presence without demands.
OlloNi SS1 adapts to daily routines over time.Ollobot
Ollobot’s goal in building intelligent companion robots is to address the gaps in technology and capability, using innovation not to automate tasks but to fill emotional voids.
Much of the robotics industry has historically pursued human imitation — machines that speak, look, or behave like people. The SS1 is instead designed around familiarity and long-term coexistence rather than realism.
The system integrates multiple subsystems operating in parallel, including visual perception, audio processing, mobility control, and interaction management. It is equipped with a multi-chip AI 4K vision module capable of facial recognition and motion tracking. One small but revealing detail is the inclusion of a physical privacy cover for the camera — a mechanical solution to concerns that software settings alone may not fully resolve.
OlloNi SS1 can actively integrate into family activities, and it can autonomously move closer to capture memorable moments or reposition itself to remain engaged in ongoing interactions.Ollobot
The robot supports advanced mobility across multiple indoor surfaces, including wooden floors, ceramic tiles, and low-pile carpets, with slope climbing capability up to 3.5 degrees. Rather than remaining in a fixed location, it can move naturally throughout the home to stay close to household members as daily activities unfold.
For example, the OlloNi SS1 may greet family members when they arrive home, follow an older adult from the living room to the kitchen while continuing a conversation, remind a child to take a study break after a prolonged period of inactivity, or notice that someone appears unusually quiet and gently check in. During family activities, it can autonomously move closer to capture memorable moments or reposition itself to remain engaged in ongoing interactions.
The robot continues to evolve over time, with over-the-air updates that deliver new features, performance improvements, and AI enhancements
It also incorporates fall detection with optimized accuracy for safety monitoring scenarios. A 6-microphone array enables omnidirectional voice pickup with an effective voice capture range of up to 5 meters, supporting reliable wake-word detection and far-field interaction.
To support continuous companionship, much of the robot’s AI processing takes place directly on the device through its “heart module” architecture, with 16 GB of memory and 64 GB of local storage. This enables the system to retain household memories, recognize familiar faces, and respond with lower latency, making interactions feel more natural even during everyday routines.
Because companion robots are expected to remain available throughout the day rather than only during brief interactions, the SS1 is designed for extended operation, offering up to 12 hours of standby time and around 5 hours of active interaction on a single charge. This allows it to accompany users through meals, conversations, playtime, and other daily activities without frequent interruptions.
To support engaging interactions, much of the robot’s AI processing takes place directly on the device through its “heart module” architecture.Ollobot
Like the relationships it is designed to build, the robot continues to evolve over time. Running on Android OS with over-the-air (OTA) updates, the system continuously receives new features, performance improvements, and AI enhancements, allowing its capabilities to grow alongside the household it serves.
The robot’s behavioral model also improves over time. Rather than reacting to isolated commands, it attempts to establish a baseline understanding of household routines and individuals. Changes in behavior — prolonged quietness, unusual inactivity, or emotional cues — become triggers for interaction.
Several features in the OlloNi SS1 illustrate this emphasis on presence and continuity in its interactions.
The system can identify different household members, including pets, and adapt responses accordingly. Remote communication features allow family members to connect through the device without treating every interaction like a scheduled call. Environmental sensors support contextual reminders tied to weather or room conditions.
Its “2+1” multi-display configuration is also designed around emotional communication. Two circular side displays function as expressive “emotional eyes,” while a separate primary display handles information and structured interaction. The separation allows emotional signaling and functional communication to operate independently, creating more intuitive nonverbal interaction even when no dialogue is taking place.
The robot’s behavioral model improves over time. Rather than reacting to isolated commands, it attempts to establish a baseline understanding of household routines and individuals.Ollobot
The SS1 also includes an automated life-recording system built on facial recognition and behavioral-event detection that can capture moments such as laughter, physical closeness, or group interaction automatically. An integrated AI vlog engine can then organize those moments into edited short-form videos with automated sequencing and soundtrack generation. The design intent is to preserve spontaneous domestic moments without requiring active documentation behavior from users.
An integrated AI vlog engine can organize recorded moments into edited short-form videos with automated sequencing and soundtrack generation
Visual data is processed primarily on the device through the SS1’s on-device AI architecture, with household memories stored locally and managed within Ollobot’s proprietary ecosystem instead of being shared with third-party smart home platforms. Access to recordings and live feeds is restricted to authorized users through the companion app, while encrypted communication helps protect data during remote access. Users also retain direct control over recording preferences, and the physical camera privacy cover provides an additional hardware-level safeguard whenever visual monitoring is not desired.
Learn more at ollobot.com.
Remote communication is similarly structured around persistence rather than transaction. Traditional video calls are episodic and screen-bound; the SS1 instead acts as a continuously present interface embedded inside the household environment. Through autonomous mobility, environmental awareness, and persistent household memory, remote family members interact with an ongoing domestic context.
Ultimately, gentle intelligence is not about making robots behave more like humans — it is about helping them fit more naturally into human lives. Each OlloNi SS1 unit develops a unique behavioral profile based on its household. Two units running in different homes for a year will have become meaningfully different from each other, shaped by the specific people, habits, and rhythms of where they live.
That kind of long-term personalization is what early companion robots never had. It is also what makes the difference between a product that ends up on a shelf and one that actually earns its place in a home.
Learn more at ollobot.com.
2026-08-25 02:00:01
For most of my career, my IEEE membership sat quietly in the background—a line on my résumé, a discount code for a conference registration, and access to the IEEE Xplore digital library, which I underutilized. I didn’t think much about the grade of membership available above that of the regular member. I assumed senior membership was reserved for people further along in their career than I was. They published more papers, had more gray hair, and had worked longer in the field.
I was wrong on all three counts. The misunderstanding cost me an important validation of my skills and professional competency.
I suspect a lot of other qualified members are where I was one year ago: eligible but unaware of the benefits of senior membership, and one application away from a meaningful career credential.
Here are a few of the misconceptions about senior membership:
It’s mostly for academics and longtime IEEE volunteers. It isn’t. The grade is explicitly built around a person’s professional engineering experience. Plenty of successful applicants have never published a paper. Industry experience counts for a lot.
You need a graduate degree. You don’t. A bachelor’s degree plus enough years of qualifying experience is sufficient on its own. An advanced degree simply offsets some of the required years of experience.
If I’m not well-known in my field, I won’t qualify. Senior membership isn’t a popularity contest. Rather, it hinges on whether you meet specific experience metrics. The requirement is “sustained, significant technical contribution,” not “known beyond your organization.”
I should wait until I have more significant achievements to point to. I believed this for longer than I should have. If you meet the 10-year experience threshold with five years of significant performance, you’re already eligible. Waiting doesn’t strengthen a qualifying application; it just delays getting a credential you’ve already earned.
The push to apply came from a practical need. As a senior data scientist at Apple in Austin, Texas, I work in applied machine learning, building large-scale systems that affect customer-support operations. I already had started taking on more peer-review work—checking papers for journals including Neural Networks and IEEE Transactions on Knowledge and Data Engineering, mentoring at Apple, and writing on public platforms such as Medium and SimpleTalk.
I wanted a credential that reflected that shift from “engineer who codes” to “engineer who helps shape the field.”
The IEEE senior member grade turned out to be the validation of my work I was looking for. It’s not an award for a single achievement. You have to apply for it, and it’s a peer-evaluated process that confirms you’ve sustained a meaningful level of professional contributions over time.
That distinction matters. Having a research paper published or being granted a patent proves a moment in time. Senior membership reflects a pattern of continuous contributions.
The benefits to my career happened faster than I expected. It strengthened how search committees, IEEE conference organizers, and IEEE awards panels viewed me. Only senior members can hold certain IEEE leadership positions.
The senior grade also opened doors to editorial and reviewer roles I hadn’t even pursued before. Journal editors and conference organizers often look for reviewers with a track record they can verify quickly, and senior membership gives them that signal without extra vetting on their end. It also gave me a credential I could point to in professional contexts, including, in my case, supporting documentation for a U.S. employment-based immigration petition, where third-party peer recognition carries real evidentiary weight.
The process for applying for senior membership is easier than the title might suggest. To qualify, you need a combination of professional and academic experience in an IEEE-designated field: engineering, computer science, information technology, physical sciences, mathematics, or technical communications. The two must total at least 10 years, with at least five of them showing significant performance. Crucially, experience isn’t limited to job titles. Graduate research, technical leadership, and progressively responsible engineering work all count toward the total number of years. I’d been quietly accumulating qualifying years without ever framing them that way.
“I suspect a lot of other qualified members are exactly where I was a year ago: eligible but unaware of the benefits of senior membership, and one application away from a meaningful career credential.”
You submit your application through IEEE’s member portal, mapped against the experience requirement, along with three references from current IEEE members—at least two of whom must be senior members or IEEE Fellows who can vouch for the credibility of your work.
The IEEE member grade evaluation committee reviews applications and renders decisions.
The part everyone underestimates is references. Applications can stall at this point. References must be IEEE members in good standing, and at least two need to be IEEE senior members—which means you can’t necessarily ask people who know you best. You need to find references who are both willing to vouch for you and are grade-eligible.
My advice is to identify and confirm all three references before you submit your application. It might be difficult to add or swap a reference during the process, and a stalled reference could delay your file.
Where to find references is the part I worried most about. But it turned out to be far easier than I expected.
Here are several sources:
A pattern I noticed when looking for references is that people are generally glad to be asked. Serving as a reference is a small lift for them and a meaningful one for you. Most senior engineers remember someone doing the same for them and are happy to pay it forward.
If you’ve been in the field for a decade or more, doing real technical work, and IEEE membership has been sitting quietly in the background of your career the way it did in mine, it’s worth 10 minutes to check the eligibility criteria against your history. You might find, as I did, that you qualified for the membership upgrade a while ago.
2026-08-24 22:00:01
The AI boom has disrupted the way engineers work, introducing new tools to learn, raising expectations for what teams can achieve in a workday, and making it harder to get hired in the first place. This makes it difficult to advise students on which specific coding languages or technical skills they should learn. So amidst the uncertainty, advice for young professionals often turns to a common refrain: Be adaptable. But what does adaptability look like in practice?
Engineers often operate on the cutting edge of technology, so dealing with change is a normal part of the job, says Samantha Brunhaver, an associate professor of engineering at Arizona State University, in Tempe. Yet university curricula and training in the workplace often don’t prepare students for this.
“We tell engineers that they need to be adaptable when they graduate, but we don’t actually explain what that means, demonstrate what that looks like, [or] help make sure that they’re developing it,” says Brunhaver, who received a National Science Foundation award in 2020 to study how to foster greater workplace adaptability among young engineers. For this ongoing project, she has interviewed engineering managers, early career employees, and undergraduates about their experiences.
Part of the problem, she says, is that every employer has its own idea of what to be adaptable means. Generally, Brunhaver defines adaptability as “the ability to recognize that a change or uncertainty is occurring, and then respond effectively to that change.” But the skill is context-dependent. In software engineering, that might mean responding to turnover in the tools you use on a daily basis, while aerospace or biomedical engineers may need to keep track of changing procedures and regulations. “Managers are all saying adaptability is important,” Brunhaver says, “but defining it in different ways.”
At the same time, engineers are all contending with changes beyond these industry-specific expectations. Jobs in the technology, media, and telecom sectors are experiencing the fastest pace of skill turnover, according to a June 2026 report on the effects of AI from the professional services network PwC. And the World Economic Forum’s most recent Future of Jobs Report, published in 2025, found that employers across all sectors expect 39 percent of workers’ core skills to change by 2030. This uncertainty can be uncomfortable. But with the right mind-set and support from leadership, adaptability can help keep you afloat.
The AI transition is a big shift—but not an unprecedented one, says Jenna Butler, a research scientist at Microsoft who studies developer well-being and productivity.
During this type of paradigm shift, there is often a “chaos period” when a new normal is being established, Butler says. In AI’s case, it challenges the understanding of what a computer can do. “I think we’re still in this in-between, difficult period that we’ve seen before, but [it] is maybe moving faster than it has historically.” Software engineers—in one of the fields most affected by AI—are now facing a significant increase in code review. “If you ask 20 developers, you get 23 different ways of working with it. Everyone is trying to sort it out,” says Butler, who describes this period as “the uncomfortable middle.”
“We tell engineers that they need to be adaptable when they graduate, but we don’t actually explain what that means, demonstrate what that looks like, [or] help make sure that they’re developing it.”– Samantha Brunhaver, Arizona State University
Brunhaver says one way educators can help prepare students before they enter the workforce is by offering a diversity of real-world experiences, such as internships, team-based projects, community service, and leadership roles. Each of these teach students to adapt to different challenges, easing their transition from school to work.
It’s also important to encourage reflection, Brunhaver adds, noting that metacognition helps individuals use the skill more effectively. “In order to adapt, you have to think that you have agency and the ability to get through a situation.” Ultimately, it comes down to three steps: Perceive a need to adapt, evaluate your options, and act.
For those already in the workforce, that action may mean taking the time to learn new tools and ways of working. Software engineering, for instance, may soon rely more on prompting models and managing agents than coding line by line. “I think people who went into software because they like solving problems are going to have a lot of fun, and people who just enjoy the art of writing code are not,” Butler says.
Although the tools engineers use on a daily basis are evolving, the core responsibilities of the job are more stable than they may seem, says Andy Hunt, a software developer who coauthored The Pragmatic Programmer (Addison-Wesley Professional) in 1999. The book outlines practical coding principles, and has been taught in many computer science classrooms. When Hunt was working on the 20th anniversary edition of the book, he was surprised by how much of the advice still applies. And now, seven years later, he maintains that belief.
“The fundamental part of the job is problem solving and communication, and that’s always going to be there,” he says.
Hunt emphasizes the importance of developing systems thinking over particular tools. To him, identifying as a Java programmer, for instance, is “like a carpenter saying, ‘I’m a hammer user,’ or ‘I specialize in cordless drills.’ ”
He acknowledges that today’s hiring process, in which companies often filter résumés for certain languages or years of experience, makes it harder to embrace a more expansive way of relating to your job. Employers, he says, should recognize that “the tech’s not the hard part, and it never has been. Understanding information theory, understanding systems thinking, understanding what constraints you’re up to—that’s still the hard part.”
With this type of misalignment between employers and employees, AI is also intensifying an old source of tension: How can engineers slow down enough to adapt and learn new tools when the pressure to become more productive keeps mounting?
Young engineers need to embrace change. However, educators and employers also play a role in building a successful workforce. From the educator’s perspective, Brunhaver says “we need to be more explicit about what [adaptability] means and why it’s important.” Managers, meanwhile, should invest in their employees’ professional development.
Microsoft research scientist Butler often encourages leadership to set aside intentional time for continuous learning for their engineers—even just an hour a week—without any expectation that they will produce code or progress in their daily work. “I realize that’s difficult,” says Butler. “I would encourage people to do it on their own, but I would really encourage organizations and leaders to do it, because you’re not going to get this sudden change in your people if they don’t have time and space to learn how to work differently.”
This also means providing enough instruction, Butler adds. When developers aren’t given enough guidance on adopting something new, while being pressured to increase productivity, they risk doubling down on the tools they already know and burning out.
“I do imagine the next number of years could be challenging,” Butler says. Engineers will have to adapt to find their place in an evolving workforce—but they also have a say in shaping that future.
“Being adaptable sort of implies that you’re going to change based on what’s happening around you, and I would really like people to realize the change that’s happening is somewhat up to us,” she says. All individuals have a choice in how they use AI, for instance, and which models they use. “We need to be adaptable and go with the flow to a degree, but we also need to be directing that flow. The future with AI is absolutely not predetermined.”
This article appears in the September 2026 print issue as “The Adaptable Engineer.”