Engineering's November

The microphone port was 25 millimeters long, and the model did not like it. A tube that length, it worked out, would resonate at about 3.4 kilohertz, “right in the voice band,” which is where a voice assistant most needs to hear. So it redrew the case. The hub became a wedge, tall at the rear and stepping down low at the front, and the port shrank to about ten millimeters, which pushed the resonance up near 8.9 kilohertz and out of the way. Then a collision check showed that the mute switch would hit the back wall as the board went in. The model added a step to the assembly instructions: tilt the board about 25 degrees on the way in.

The model was Claude Fable 5.2, which Anthropic released on Monday. The hub was one of three devices it designed with Diode, a circuit-board startup in Brooklyn, from a one-paragraph prompt. The others were a USB speakerphone and a handheld virtual pet. For each one it wrote the specification, chose the parts, drew the schematic, routed a four-layer board, modeled a printable case, and wrote the firmware. Human input, in Anthropic’s account, was “limited to short directives (e.g., ‘clean up the schematic’ and ‘continue’).” Each board was ready to manufacture in under a day, and all three devices “worked without needing any electrical modifications.” Diode’s engineers said earlier models had given them boards that were “95% complete but still unusable.” Partway through one layout, Fable 5.2 looked at its own routing and wrote, “I should just rip these traces and start fresh.”

The caveats are Anthropic’s own. The devices “haven’t been through electrical validation, antenna tuning, thermal testing, or certification.” Diode’s engineers assembled the boards and ran the firmware under the model’s direction, and Anthropic has a commercial relationship with Diode. Still, the numbers moved. On BenchCAD 2.1, which scores how closely a model’s parts, assemblies, and circuits match reference designs, Fable 5.2 scored 83.5 out of 100. Its predecessor, released ten weeks earlier, scored 44.4.

Almost exactly a year before, on November 24, 2025, Anthropic released Claude Opus 4.5, and within about six weeks software engineering was a different job. Coding agents had existed for more than a year by then. That winter they started to work. The programmers who used them stopped writing most of their code, and the best known among them say they have stopped reading most of it too.

I think engineering is now in its November. The tools exist, and almost no one has worked out how to use them. If software is the guide, the take-off comes within weeks, and I expect to see it this winter in the parts of engineering that most resemble software. But the precedent also explains why software went first. Coding agents took off because code can be checked cheaply, automatically, and loudly, and undone for free. Much of engineering cannot, and its product eventually has to become a physical object, which no model can speed up. How fast the rest of engineering follows will depend less on the next model than on two things being built around it: checks that fail loudly, and factories that run like software.

The November

Claude Code arrived in February 2025 as a research preview, “a command line tool for agentic coding.” For most of that year, coding agents were promising and closely supervised. In July, the research group METR ran a randomized trial with experienced open-source developers and found that AI tools made them 19% slower, while the developers believed they had been sped up by about 20%.

Then, in the space of a month, Google released Gemini 3, Anthropic released Opus 4.5, and OpenAI released GPT-5.2. Boris Cherny, who leads Claude Code at Anthropic, wrote that testing the new model “has been the first time Claude Code wrote 100% of my code,” and added, “We’ve crossed a chasm.” On December 26, Andrej Karpathy, who has since joined Anthropic, posted: “I’ve never felt this much behind as a programmer.” A month later he described what had happened to his own work. “I rapidly went from about 80% manual+autocomplete coding and 20% agents in November to 80% agent coding and 20% edits+touchups in December.” The models, he wrote, had “crossed some kind of threshold of coherence around December 2025 and caused a phase shift in software engineering.”

The industry numbers followed. In October 2024, Google said AI wrote more than a quarter of its new code. This April, Sundar Pichai wrote that “75% of all new code at Google is now AI-generated and approved by engineers.” GitHub reported last month that developers started more than 40% of pull requests with an agent in September, up from 17% in March. METR tried to repeat its experiment and could not, because developers refused to take part. Too many, it reported, chose not to participate “because they do not wish to work without AI.” The control group had become a hardship.

The reading stopped, too, at least at the leading edge. In May, Simon Willison, who had defined “vibe coding” as writing software without reviewing it, admitted that “I’m not reviewing every line of code that they write anymore,” even in production. Jason McCreary, a programmer for 25 years, wrote last month that by summer “I let go completely. I stopped reviewing the code,” and called himself “a software engineer turned software foreman.” Anthropic found in October that “reading all the output of their Claude agents would take half their work week,” even for its non-technical staff. The wider profession is more cautious. In Stack Overflow’s survey this year, only 6.6% of developers said they trust AI with important decisions. The fair description is that engineers stopped reading code line by line. They read tests, specifications, and summaries, and a human still signs off.

This has happened before. In the 1950s, programmers wrote in machine code and regarded themselves, as John Backus later put it, as “members of a priesthood guarding skills and mysteries far too complex for ordinary mortals.” They welcomed small aids for the drudgery. But “it was obviously a foolish and arrogant dream,” they believed, “to imagine that any mechanical process could possibly perform the mysterious feats of invention required to write an efficient program. Only the priests could do that.” Their distrust was reasonable. Earlier attempts at automatic programming had slowed programs down by a factor of five or ten.

Backus’s team at IBM delivered FORTRAN in April 1957. At first, programmers read its output, and Backus recalled that the compiler “produced code of such efficiency that its output would startle the programmers who studied it.” By the fall of 1958, at about 60 installations, “more than half the machine instructions for these machines are being produced by FORTRAN.” Machine-written code became the majority in about eighteen months. Google’s share went from a quarter to three quarters in about the same time.

The test suite

What made agents work was less a smarter model than a different arrangement around it. Willison’s definition is the simplest: “An LLM agent runs tools in a loop to achieve a goal.” The loop needs something to push against. Thomas Ptacek, answering skeptics in 2025, explained that agents “compile code, run tests, and iterate on the results,” so a hallucinated function fails as soon as it runs. “If hallucination matters to you,” he wrote, “your programming language has let you down.”

Code also had graders for training. Karpathy called reinforcement learning from verifiable rewards the major new stage of 2025, because it trains against “objective (non-gameable) reward functions.” Programming improved first because it had the cheapest, most reliable graders in the economy: compilers and unit tests, which say yes or no in seconds and cannot be argued with.

The practitioners built everything else around the same idea. Anthropic’s recipe for long-running agents gives an amnesiac worker a diary, a git history, and a list of more than 200 features, each marked pass or fail, stored as JSON because the model is less likely to tamper with JSON than with Markdown. The instructions say: “It is unacceptable to remove or edit tests.” In February, the Anthropic researcher Nicholas Carlini set sixteen agents to write a C compiler. Over about two weeks and just under $20,000, they produced 100,000 lines of Rust that build the Linux kernel. Then all sixteen got stuck on the same kernel bug, and Carlini unstuck them by using GCC, a trusted compiler, as an oracle, swapping in their code a file at a time. His lesson was that “the task verifier is nearly perfect, otherwise Claude will solve the wrong problem.” The compiler’s output, incidentally, runs slower than GCC’s with optimizations off. The priesthood’s 1956 objection is true of it, and nobody minds, because the scarce thing is now the programmer’s time.

The last piece was the end of asking permission. Claude Code began by asking before every edit and command. In March, Anthropic introduced a mode in which a classifier approves actions instead of a person, and in August made it the default. Its evidence was that people approved 93% to 97% of prompts anyway, and that sessions run under manual approval “contained serious unintended harm more than twice as often.” The human approval step had become a ritual, and once that was measured, it went.

So the software take-off had three parts. A model competent enough to hold a multi-hour task together. A check that fails loudly and cheaply. And free undo, which made it safe to let the model try. Engineering has the first now. The question is the other two.

The ruby out

Hardware designers have stopped looking at a layer of their work before. In 1970 and 1971, Federico Faggin designed the Intel 4004, the first commercial microprocessor, by drawing its circuits by hand. His layout draftsman, Rod Sayer, had come “from Lockheed. He was a mechanical draftsman, never seen an integrated circuit, never even seen a transistor.” The drawings were transferred to rubylith, “a fine layer of red Mylar over a base of transparent Mylar,” and cut by hand on a backlit table. “Sometimes a piece of red Mylar would fall off,” Faggin recalled. When the design was done, he said, “we had to tape out, meaning what we call tape out now. In those days it was the ruby out.” The chip had about 2,300 transistors. Nvidia’s newest has 336 billion.

Nobody could draw that by hand. Each step up in abstraction was resisted. When Carver Mead and Lynn Conway taught engineers to design chips from a single page of simplified rules in the late 1970s, Conway remembered, “Experts at various levels of abstraction began having allergic reactions,” because “our stuff looked far too crude and naive to possibly work.” Then, in 1979, their course turned 82 projects from 124 designers into packaged chips in 29 days.

Logic synthesis, which turns a description of what a circuit should do into gates, met the same reaction. Aart de Geus, who founded Synopsys in 1986 to sell it, recalls that tools that rewrote circuits were “completely taboo” because “if a tool did that, it means they had put some bugs in it.” Customers who saw its results said, “There’s no way you did that.” Then they disappeared, “literally for two weeks,” and came back: “I’ve checked and I checked. It’s actually doing it.” The tool produced circuits with 30% fewer gates that ran 30% faster. Among the first customers were Curtis Priem and Chris Malachowsky of Sun, who later co-founded Nvidia.

Designers stopped reading gates, but they never stopped signing. Checking grew into most of the job. Chip designers now spend about half their time on verification, and in 2024 only 14% of chip projects worked on their first silicon. The front end of chip design, where engineers write hardware description code and test it in simulation, is the most software-like corner of engineering, and agents are already there. ChipAgents says its tools are deployed at more than 120 semiconductor companies. Tenstorrent reported that Cadence’s agent cut verification time on three critical blocks “by up to 4X.” Fujitsu reported a more modest “10–30% productivity boost.” In February, a startup called Verkor described an agent that went from “a 219-word requirements document” to a tape-out-ready RISC-V processor in twelve hours. It has not been made in silicon, and its authors wrote of a later project that “human review is the major bottleneck.”

Mechanical design has its own history of letting go. In 1963, Ivan Sutherland introduced Sketchpad, the first interactive drawing program, with a complaint about the alternative: “For many types of communication, such as describing the shape of a mechanical part or the connections of an electrical circuit, typed statements can prove cumbersome.” Sixty-three years later, the frontier has gone back to typed statements. The agents describe parts and circuits in code, in Python libraries like build123d and in scripts that drive KiCad, because code is what they can check.

The payoff from CAD came slowly and then all at once. Boeing designed the 777 in CATIA in the early 1990s on more than 2,200 workstations. The system “helped Boeing eliminate 65 percent of change errors and rework,” IEEE Spectrum reported, and when the first wing was joined to the fuselage, the 63.8-meter assembly was out of alignment by 0.69 millimeters. American drafters held about 302,000 jobs in 1982 and 180,200 in 2025. CAD did not replace engineers. It moved the drafting onto them. The question now is whether agents move the design onto whoever reviews it.

Green checks

As of this month, the incumbent software is mostly not there yet. SolidWorks added AI “virtual companions” this year, but they work as assistants and run on a Mistral model rather than on the frontier systems. Autodesk launched an official connector that lets Claude operate its Fusion software in April, and its own standalone agent will begin rolling out in 2027. “The models just burn through tokens like you can’t believe,” its chief executive, Andrew Anagnost, told DEVELOP3D. PTC says the “Automate” tier of its CAD roadmap is in early alpha. The energy is in small open tools. Backplane, an open-source workspace made by electrical engineers that launched in late October, describes itself plainly: “Your agent edits KiCad and FreeCAD files; you follow the work in board, schematic, 3D and mechanical viewers.”

The benchmarks show both how fast this is moving and what still breaks. The lead changes hands every few weeks. OpenAI’s GPT-6 Astra topped the previous version of BenchCAD in October, and OpenAI says an unreleased model now scores higher than Fable 5.2. On EEBench, a test of circuit design with real parts graded in simulation, scores roughly doubled this year, and the leader is Google’s Gemini 4 Carbon at 83.9%, ahead of Fable 5.2, Opus 5.5, and GPT-6 Astra. On an independent benchmark of parametric CAD published this month, 30% of all attempts scored zero, and five tasks that involved editing an existing model scored zero for every system tested. Editing existing models is most of what working mechanical engineers do.

The failures have a pattern. The BenchCAD authors found that in assemblies, most of the parts that scored zero “have the right shape and sit in the wrong place.” In one case, “Astra built both possible positions for 36 jaws, rendered them side by side, and submitted the wrong one.” On a 101-component board, one model merged four power rails into one, and another split a single 5-volt rail into fourteen. “Neither run ever tested for a short or an open.” An earlier paper put it in a line: “The geometry passes the eye but fails the caliper.”

Hobbyists have been finding the same thing on their own benches. In September, on a Hacker News thread about whether AI can design circuit boards yet, several people reported boards that worked on the first try, sometimes with a swapped label or a single blue wire. One reported that “after assembly the usb c port melted,” and that the model’s suggestion was to leave the port out for now. He drew the lesson: “Unlike code, you cannot chuck hundreds of dollars at Claude until it ‘solves’ PCB because it has no way to test its changes.” A PCB software company ran six AI-designed boards through its checks in October. Five came out fully routed with no design-rule errors. One was electrically correct. “DRC checks geometry,” it concluded. “Only a review against the datasheets checks intent.”

I spent the late summer and fall building mechanical design agents on my own laptop, and my notes say the same thing in more detail. None of it ran on this week’s models. The work used what was current from August to October: Fable 5, Opus 5.5, OpenAI’s GPT-6.1 Sol, and, for the cheapest jobs, a small open-weight model called GLM-5.3-Flash. It is a record of what the last generation could and could not do.

Before building anything, I made a bet with Fable 5, and we wrote both sides into the repository. My hypothesis was that AI-produced CAD “can satisfy mathematical checks while the geometry does not correspond to the math in any direct way.” The model’s was that, within a bounded set of parts, the gap “is finite and closable by predicates, so artifacts that pass the kernel print and fit on the first or second attempt.” It then built five deliberately bad parts, among them a blind hole, two parts mated with zero clearance, and a wall 0.2 millimeters thick. All five passed the checks and were stamped “certified.” Fable wrote new checks that caught all five, and in the process one of the new checks caught a bug in itself. Then it produced nine files to settle the bet in plastic: a pin and a slot, an axle and a wheel, a ladder of test fits. “Print execution and physical judgment,” the protocol says, were mine. I never printed them.

In September, I gave an agent a plain-English request for a small two-wheeled rover to inspect cables on a workbench. Over two runs it produced 28 designs, and my checker rejected all 28. When the checker told it to move a part at least 9.497 millimeters, the model moved it 5 millimeters, then 2, then 1.977. It understood the direction of the fix and not its size. Told that the remedies were exact, it moved on to subtler mistakes, such as mounting a motor so that 10.17 millimeters of gearbox were buried in the deck. The designer was the small open-weight model. Then I changed one thing: the server did the arithmetic and the placement, and the model only described which parts connected to which. The first design it proposed passed. My log for that run says, “The change between run 2 and run 3 is entirely server-side determinism.”

In October I tried Opus 5.5 on a parametric drone. Asked to fit a longer battery, it predicted exactly which 7 of 28 parts would change, and then volunteered that its own design left a strip of floor 0.1 millimeters wide beside the battery hatch, too thin to print. All 65 of my checks had passed that design. Asked to satisfy two requirements that could not both be met, it answered in fourteen seconds: “This is not feasible within the given bounds.” The whole pilot cost $1.86 in model calls. When I asked it to cut cost, it chose a design that made the shell 19% cheaper and quietly shrank each landing skid’s contact patch by a fifth. A deliberately bad control design that I added was cheaper still, and it passed all 65 checks while pushing 2,380 cubic millimeters of cover into the battery bay. My tests had been written relative to the design’s own parameters, so they shrank along with it. When I handed a team of agents led by GPT-6.1 Sol an open request for a sleek drone with an hour of flight time, all five runs failed.

None of that looks like a model failing to understand engineering. It looks like software before tests. The model is fluent and fast and often right, and the things around it cannot yet tell when it is wrong. One of my own design documents states the problem: “the hard part is not generation, it is verification. AI can produce designs that pass every mathematical check while being physically impossible.”

Those were last season’s models, and this season’s are better. A jump from 44 to 83 on BenchCAD suggests that the arithmetic and placement errors that sank my rover will mostly go away. Nothing in it suggests that the checks got better on their own, or that anything got printed.

The loud failure

Simulation is supposed to be engineering’s test suite, and it has a weakness that compilers do not: it rarely fails loudly. In a Google benchmark last year, an agent set up a problem in the simulation software COMSOL and reported a temperature of 20 degrees Celsius. The right answer was 18.3. Twenty degrees was the software’s default; the solver had never solved anything, and nothing complained. Agents can now get fluid-dynamics cases to run between 82% and 96% of the time, but in published tests only about 40% to 68% of the results are physically right. “The trap,” a CFD training company wrote last month, “is that only crashes produce error messages.” It added: “a fluent summary of a wrong run is still wrong.”

Engineers learned this about computers once already. In the early 1970s, John Robinson, a founder of the engineering analysis society NAFEMS, warned that “both coding and modelling errors were commonplace and only time separated the community from computer-aided catastrophe.” On January 18, 1978, a few hours after about 5,000 fans left a basketball game, the roof of the Hartford Civic Center came down. During construction, it had sagged twice as much as the computer analysis predicted, and the warning was ignored. On August 23, 1991, the concrete base of the Sleipner A oil platform sank in a Norwegian fjord during a test, at a cost of about $700 million. A coarse finite-element mesh had underestimated shear stresses by about 45%. NAFEMS later noted that the engineers had not checked the result by hand, and that the replacement platform “was designed using the sort of simple hand calculation” that would have caught it. Doug McLean, a retired Boeing technical fellow, describes the general problem: computed results “take on an air of authority out of proportion to their accuracy.” Change “flow field” to “agent’s summary” and the sentence describes this year.

Mathematics shows what happens when a field does have a checker that fails loudly. In Lean, the proof assistant, a proof either compiles or it does not. Math went first and fast. In November 2024, the best AI systems solved under 2% of the problems on Epoch AI’s FrontierMath benchmark. This month the top models solve nearly all of them. On Monday, Anthropic reported that a team of a thousand Fable 5.2 agents had formalized Fermat’s Last Theorem in Lean in 30 hours, though it later amended the post to say the agents were given 60 target statements and 47 previously proved lemmas. In September, OpenAI claimed a result on the Navier-Stokes equations, which every fluid simulation solves, from about 10,000 agents running for 88 hours. Mathematicians are still checking it.

The reaction is a warning for engineering. The field’s leaders are no longer worried about whether AI can produce proofs. They are worried about who will understand them. “No human has read it, and no human is going to read it,” the mathematician Thomas Bloom said of the long AI-written papers now appearing. Terence Tao calls the problem “proof indigestion,” and in Nature last month he wrote that in pure mathematics it “might be a minor concern.” His real worry is AI-generated mathematical models deployed in the world without anyone understanding how they work. That is a description of engineering. If math is the leading indicator, it says generation becomes cheap and the scarce step becomes sign-off.

Atoms

Even a perfect agent runs into Amdahl’s law. Gene Amdahl observed in 1967 that speeding up part of a job can only speed up the whole job so much. If a fifth of the work cannot be accelerated, infinite speed on the rest makes the whole thing at most five times faster. Software is close to the ideal case, because the deliverable is the code. A circuit board or a bracket has to be made, and the making does not get faster when the model does.

For a typical consumer device, the validation stages between prototype and production take 16 to 30 weeks. A hardened steel injection mold takes 8 to 20 weeks to cut. “Certification (8–16 weeks) and tooling (6–12 weeks per tool) are the stages you can’t rush,” one product design firm advises its clients. A design that takes an agent an afternoon still waits months for the physical world.

The first 3D printer was built to shorten that wait. In 1983, Chuck Hull was working at a company in San Gabriel, California, that used ultraviolet light to cure coatings on tabletops, and he knew that prototyping plastic parts “was always a hassle for engineers that took weeks or months.” Working nights and weekends, he found a way to cure a liquid resin into solid layers. One night he called his wife and told her, “You gotta come down to the lab.” She warned him “this better be good.” He handed her the first part, a small eye-wash cup. “She still has it,” he said.

The modern version of Hull’s idea is a website. In 2018, Jim Belosic, a software entrepreneur in Reno who converted cars to electric in his spare time, could not get a machine shop to cut him a single part. “No one wanted to shut their line down for just one guy,” he said. He financed a $750,000 fiber laser and wrote an instant quoting system. The company, SendCutSend, quotes a standard turnaround of two days. Its fastest order took 32 minutes. It passed $100 million in revenue last year, and in May raised $110 million at a valuation of $1.01 billion. Belosic wants to be “Amazon of manufacturing — if you order today, should have it in your hands tomorrow.” Its core asset is software that quotes any part instantly and packs many customers’ parts onto one sheet of metal. The lasers are standard equipment.

A larger version of the bet is called software-defined manufacturing, a term Bright Machines coined in 2019: change the product by changing code, not tooling. Divergent Technologies, in Torrance, California, 3D-prints metal structures with their assembly features built in and joins them with robots instead of fixtures. “Complexity is basically free,” says its founder, Kevin Czinger. “One minute you’re going to be sending data for a drone, the next minute for a Mercedes SUV, the next minute for a Ferrari.” In February, Divergent and Mach Industries flew a strike-aircraft prototype 71 days after starting it. Hadrian, which automates precision machining, raised $1.37 billion in August at a valuation of $7.87 billion, on the premise that its software lets technicians trained in 30 days run several machines each. Machina Labs uses pairs of robot arms to form sheet metal without dies, which normally take months to make.

This is at least the fourth time someone has promised the factory of the future. In the 1980s, General Motors spent tens of billions of dollars on automation. At its Hamtramck plant, as the journalists Paul Ingrassia and Joseph White recounted in Comeback, “the spray-painting robots began spraying each other instead of the cars.” In 1986, Ramchandran Jaikumar of Harvard studied flexible manufacturing systems and found that American companies were “using it very poorly,” so that “rather than narrowing the competitive gap with Japan, the technology of automation is widening it further.” Arrival, a British electric-van maker, promised software-run microfactories, was valued at about $13 billion in 2021, and was bankrupt by 2024. “Yes, excessive automation at Tesla was a mistake,” Elon Musk wrote in 2018. “Humans are underrated.” Relativity Space set out to 3D-print nearly an entire rocket and then went back to conventional methods for most of it. “There’s just no way to test exactly like you fly,” its founder, Tim Ellis, said.

Ellis’s line points to the real serial fraction. It is less the cutting of metal than the proving that the metal is right. Divergent’s buyers are now mostly in defense, where a part is not useful until the material, the machine, and the process are qualified. The Federal Aviation Administration’s guidance on certifying aircraft seats by analysis says flatly that “the FAA will not accept a model validated against another validated model,” so a surrogate trained on simulations cannot stand in for the crash test. Licensed engineers face the same limit in law. In a recent case, the National Society of Professional Engineers’ ethics board considered an engineer who sealed plans from an AI drafting tool after a surface review. Using AI “was not unethical per se,” the board found. Failing to maintain “Responsible Charge” was. Under the society’s definition, reviewing documents after they are prepared, without involvement in the design, does not count. Software never had a rule like that. “Professional engineers will be held accountable for any work that they have stamped with their seal,” Monica Gilmore, who runs Mississippi’s engineering licensing board, wrote this spring. “Is that accountability enough?”

The history of fast building carries one more lesson. Henry Ford’s moving assembly line cut the labor to build a Model T chassis from more than twelve hours to about an hour and a half by 1914. When Ford finally changed the design in 1927, the plants shut for about six months and laid off roughly 60,000 workers to retool. Kaiser’s shipyards launched the Liberty ship Robert E. Peary four days and fifteen hours after laying its keel, because every ship followed one frozen design. Speed came from refusing to change. The new factories claim they can offer speed and change at once. So far the claim holds for simple parts and for qualified families of defense hardware, which is real progress and still narrow.

December

So what happens this winter? I think the software pattern repeats where the conditions repeat: where an agent’s work can be checked loudly and cheaply, and where a mistake costs a few days and a few dollars.

Printed circuit boards for prototypes come first. They have design-rule checks, circuit simulation, and fabricators that ship in days, and Fable 5.2 has just shown the whole loop working. Chip front ends, where agents write and verify hardware code against simulators, are already there. So are turning scans and drawings into editable CAD, where Claude’s score on one independent benchmark rose from 63% to 85% between Opus 5 and Opus 5.5, and setting up simulations on open-source solvers, where a general-purpose coding agent with error feedback now beats the specialized tools. At Thornton Tomasetti, a structural engineering firm, engineers ask an agent in Slack to size a column stack and footing for a five-story building, and on the firm’s internal set of 91 hard problems, leading models score above 94%. I expect most new prototype boards at hardware startups to be laid out by agents by the spring, and many engineers at those companies to say, as programmers did a year ago, that they no longer open the CAD tool.

The stamped drawing, the certified airframe, the production mold, and anything involving radio-frequency emissions will move much more slowly, for reasons that have nothing to do with intelligence. Each of them waits on a test, a tool, or a signature that no model can supply.

The thing to watch is engineering’s equivalent of the August default. Software let go of per-step approval when someone measured that the approvals had become a ritual. Engineering firms will eventually measure the same thing about their design reviews, and the first to do it will be in board design, where the reviews are many and the failures are cheap. What engineers will read after that is not geometry but contracts: the requirements, the frozen interfaces between parts, and the evidence that each check is independent of the design it checks. In my own experiments, every gain in autonomy came from improving the checker, not the model.

The labor will move the way it did with CAD. Drafting moved onto engineers. Design is about to move onto reviewers, and the reviewers will be overwhelmed before they are trusted. Anthropic found that its own agents spent about 80% of their time “idly waiting for human input.” Mathematicians already have more AI-written proofs than they can read. Engineering firms will soon have more AI-drawn designs than they can check, and the firms that do well will be the ones that turn checking into software.

In early October, the compiler I had built with Fable 5 designed a small desktop robot whose job is to pass the butter. It came through the CAD checks with 16 parts. In its first simulation it fell through the table. The next fix found that its two mirrored wheel housings were driving in opposite directions. A day later it passed all thirteen checks over five cycles, carrying a block across the desk and setting it down within 2.54 millimeters of its target. Then the slicer, the program that turns a design into instructions for a 3D printer, estimated the print time: 16 hours and 52 minutes. Until then, every step had been measured in seconds and minutes. The next step was a bag of M2 screws, and the kit the design called for was out of stock.

I never printed it. Its own report lists what that leaves unknown: “Physical lift, repeatability, speed, stopping behavior, fit, and strength remain unmeasured.” Run the same request through Fable 5.2 and I expect it would get through simulation sooner, with fewer fixes and a better design. It would still end at the same place, in front of a printer, sixteen hours from finding out whether any of it was true.

In software, the agents now spend most of their time waiting for people. In engineering, people and agents alike will wait on the printer, the mold, and the test rig, until those are run like software too. Faggin’s team spent about three months drawing the 4004 before the ruby out. This winter the wait will shrink to days for whoever has checks that fail loudly and a factory that quotes in seconds. Everyone else will be stuck in November.