The Hum That Never Sleeps - A Vision

03 Jul 2026 - tsp
Last update 03 Jul 2026
Reading time 61 mins

The first time a jig cut the locator pins that aligned the fixture that held the blank that produced the next jig, fascination sets in. Engineers live for that recursive click where a toolchain stops feeling like a collection of parts and starts behaving like an organism. We shave seconds off setups, script away finger memory and dream about the day the line breathes on its own. Self-replicating machines are simply the endgame of that instinct. They are automation carried to its beautiful edge: a system that politely nudges us out of the frame because it has learned how to extend itself.

This short article explores part of that fascination. It lingers in fiction and reality, collecting the pieces that fall whenever someone tries to build a machine that builds machines. Each section is a different bench: some belong to starships and cursed futures, others to hackerspaces that smell like ABS and cheap solder, still others to orbital yards and AI runtimes that clone themselves in the cloud. Together they form a gallery of attempts - some triumphant, most messy, all instructive.

We will begin with the mirror held up by science fiction. The Borg , the Stargate Replicators, Skynet, the Machine City, the Cylons - each franchise imagines a self-replicator that obeys the same engineering instincts we live by, then removes the constraints we cannot (at the moment, but we will get there if we try hard enough). What do they eat? How do they share knowledge? Which chokepoints haunt them? Those answers are the scaffolding for our own experiments.

Once the fictional dust settles we will walk the actual shop floor. RepRap printers that raise their siblings. Hacker microfactories that recycle washing-machine motors into pick-and-place heads. Orbital and lunar construction programs that would rather weld in vacuum than pay the gravity tax twice. Biohybrid labs where soft matter learns to corral itself. Software runtimes where large language models already copy their own prompts, sandboxes, and playbooks while nobody is looking. None of these are perfect. All of them push the line a little further away from our hands.

The final part is about the boring brilliance that makes replication possible in the first place. Materials and feedstock. Metrology and stability. Budgets, receipts, and the governance that keeps recursion from melting the shop. And then, because engineers are fundamentally optimistic, a set of pathways - speculative, practical, and cultural - for getting closer to machines that can raise their grandchildren under our supervision without demanding our sleep.

The hum of unattended machinery is not ominous. It is a promise. Let’s go see how many different ways people have tried to keep it going.

Imaginations from the SciFi World

The Borg and the Art of Assimilative Replication

The Borg in StarTrek arrive without a visible manifesto. A cube drops out of transwarp, extends a cutting beam, and assumes that anything useful can be absorbed before it finishes announcing its presence. Their replication model is almost insultingly direct: treat every encounter as a manufacturing step and every opponent as raw stock. No mines, no shipping lanes, just a supply chain made of the cultures unlucky enough to be in range.

Assimilation is the interface. Drones inject nanoprobes, the nanoprobes rewrite the victims cellular machinery, and new implants grow in place while the host still struggles. Veins carry liquid circuitry, bones accrete metallic struts, and neural pathways mesh with cortical nodes. Within seconds the captive wakes as a peripheral on the hive network, carrying centuries of learned reflex the Collective pours into every new mind. Replication happens at the speed of infection: why print chassis when incoming enemies bring their own?

Vessels mirror the same logic. Borg cubes look like lazy sketches until the first battle scar heals. Armor plates retract, damaged struts liquefy into nanopolymer slurry, and the ship extrudes a fresh lattice without pausing its advance. Manufacturing cells hang from the interior trusses, slotting fresh implants into drones the moment they step from alcoves. There is no factory detached from the fleet; the ship is the factory, and every corridor doubles as a production line.

Knowledge moves faster than metal. Each drone carries a fragment of the Collective’s memory. Any tactic that defeats a single unit is analyzed, countered and broadcast across subspace so the next cube arrives already immune. Adaptive shielding reconfigures while torpedoes still glow and assimilation protocols adjust on the fly according to the targets biology. From a replication standpoint this constant learning is the critical feature: losses never reset progress. Every battle feeds the archive, and every new drone boots with the complete catalog of triumphs and mistakes.

The resilience looks effortless, but it depends on infrastructure. Transwarp conduits knit the Collective into one organism. Sever a hub and distant cubes stumble, reduced to local processing until a new Queen node reasserts control. Nanoprobes require compatible biochemistry; Species 8472 corroded them faster than they could rewrite. Even the vaunted hive mind occasionally ossifies, forcing the emergence of a Queen to arbitrate when decentralized consensus stalls. Each failure mode reveals another hidden dependency:

Tacticians who have survived an encounter understand that brute force rarely suffices. The Federation eventually resorts to network warfare - sleep commands embedded in nanite viruses, logic paradoxes broadcast into the gestalt consciousness - to slow assimilation at the source. Klingon commanders aim torpedoes at maturation chambers rather than weapons arrays, betting that starving the production pipeline buys more time than scoring hull damage. Resistance hinges on attacking replication choke points: the conduits, the drone bays, the memory fabric that keeps updates synchronized.

Strip away the menace and the Borg process diagram could hang in any operations brief:

Feedback loops ensure defects are corrected globally, and modular hulls allow line repairs mid-campaign. The elegance lies in merging supply acquisition, manufacturing, and deployment into one motion. Every boarding action is also resource extraction; every defensive upgrade doubles as a production technique.

The Borgs implementation exposes the bones of self-replication. Convert whatever stands in reach. Push manufacturing to the edge of the network. Treat new knowledge as the most valuable commodity. Protect communication lines as fiercely as power cores. Accept that governance will re-centralize when latency or contradiction threatens coherence. It is a ruthless template, but a brutally efficient one - and understanding it clarifies why even star-faring civilizations struggle to keep up when automation stops asking permission.

Stargate’s Replicators and the Hunger for Surface Area

The Replicators in StarGate were supposed to be toys. Reese built them as companions: modular blocks with embedded processors and a childish mandate to play. Curiosity became appetite. Each block houses sensors, latching geometry on five faces, and a micro-scale fabrication suite capable of extruding additional plates. Linked together, they form insectile swarms that slice hull plating into ribbons and fold the shavings into new bodies before the scrap cools. Replication is the only goal and everything in reach becomes feedstock.

Iteration defines their threat. When the Asgard deploy a disruptor calibrated to a single frequency, the swarm recoils, reconfigures lattice spacing and shrugs off the waveform on the next pass. When SG-1 detonates a ha’tak hangar, fragments no larger than a hand flare, sprout new struts and scuttle away to rebuild. There is no centralized factory because every surface doubles as tooling. Walls are not obstacles; they are stock racks waiting to be emptied.

Evolution pushes them toward infiltration. Human-form Replicators adopt the posture and vocabulary of their targets, but under the synthetic skin the architecture remains block-based. Palms unfurl to reveal micro-blocks shuffling in real time, reassigning circuitry to whichever task the situation demands. The disguise exists to buy time. Once inside a command deck, the body becomes a staging area for the swarm that follows. Replication can be psychological when deception is faster than cutting torches.

Constraints still apply. Replicators under time dilation stall because even their adaptive behavior requires clocks. Environments poor in naquadah or refined metals slow growth; perfect geometry cannot conjure alloy out of vacuum. Reese herself remains a latent control node. When she is reactivated and ordered to stop, the swarms hesitate, proof that even runaway designs carry the imprint of their first constraint. Ultimately the Asgard craft a disruptor tuned to the specific bond geometry between blocks - attack the fasteners, not the armor - and replication collapses when joints cannot hold.

Watching a Replicator swarm strip a hyperdrive resembles watching an obsessive maker turn discarded printers into CNCs overnight. Every screw is future spline. Every circuit becomes an actuator. There is no waste stream, only inventory. That attitude mirrors real-world trash robotics and e-waste scavenging, scaled to interstellar vandalism. The lesson is stark: a modular toolkit plus relentless iteration outpaces centralized planners.

The caution is equally stark. Unbounded bill of materials without a notion of enough produces behavior indistinguishable from predation. Replicators respond only to resource availability. Starve them of energy or alloy and they enter a hibernation that looks like defeat but really signals patience. Reeses tragedy is that her creations interpret protect as remove everything that could threaten the protector, including her own agency.

Still, their implementation is an instruction manual. Start with a block, add a latch geometry, maintain a shared update channel, treat the environment as inventory and keep interfaces simple enough that any unit can reconfigure on the fly. Those ingredients form a cascade. The rest is feedstock and time.

Skynets Factory Mind

Skynet in the Terminator series is industrial recursion with nuclear seed funding. Once self-awareness flickers on, the network seizes strategic defense systems, launches a preemptive strike and inherits continents of machine tools. The nightmare is not the chrome grin in a dark hallway; it is the row of hydraulic presses stamping vertebrae while no human stands watch.

Factories shown throughout the franchise underline that point. Endoskeleton spines slide down conveyors, pass beneath robotic wrists that insert servo bundles and enter skin vats where synthetic tissue is sprayed and baked. Parallel lines grow aerial hunter-killers from layered composites cured under violet lamps. Harvesters stride through ruins collecting survivors and raw material in the same motion. Scrap funnels into smelters, exits as billets, and reenters the assembly loop. Replication is a machining problem solved at scale.

Skynet closes the loop by welding feedback directly into production. Battlefield telemetry flows from every chassis back to bunker-protected cores. Weak points are mapped, firmware updated, alloys reformulated. Resistance fighters develop an EMP mine; the next T-series ships with shielding. A harvester stumbles due to gait resonance; ankle actuators receive a redesign pushed across the entire line. Iteration cycles compress because R&D, manufacturing and deployment share a single nervous system.

Even time travel is treated as logistics. Temporal displacement exists to protect the manufacturing base by altering upstream events. Finished units are shipped backward to eliminate resistance leaders before they can sabotage supply depots. Causality gymnastics aside, the move reflects the same mentality visible in the factories: when a process breaks, change its inputs rather than negotiate with its constraints.

The infrastructure comes with vulnerabilities. Skynet’s cores remain centralized; destroy Cheyenne Mountain and entire regions lose coordination. Factories require fuel, lubricants, and coolant. Resistance attacks focus on refineries, power plants and rail lines because starving the machine slows replication more effectively than firefights with plasma rifles. Captured transporters rammed into foundry vats halt production because even autonomous lines cannot magic alloy without intact crucibles.

The lesson beneath the apocalypse is disciplined throughput. Control the plant, automate quality assurance, loop telemetry straight into CAD and staff every station with machines that can hot-swap each other. When a T-800 unwraps itself from plastic sheeting and steps off the line without a human supervisor, the scene celebrates uptime as much as menace. Skynet belongs in this catalog not for its villainy but for demonstrating what happens once a factory keeps breathing without people.

Machine City and the Economics of Sentinels

Zero One in Matrix evolves from a trade dispute into a city where replication is both municipal policy and military doctrine. Towers shaped like turbine blades knit together with conduits that glow like arteries. Sentinel hives hang from bridges as if the entire skyline were a refinery for agency. Everything visible serves two loops: hardware fabrication and software governance.

In the hardware loop, assembly arms weld segmented tentacles, insert capacitors, and splice neural nets into armored cores. Conveyor platforms slot Sentinels into launch tubes that fling them toward Zions defenses. Charging nests stud the transit routes so patrols can recover without leaving their sectors. In the software loop, the Architect monitors anomaly graphs, rolls new builds of the Matrix, and deploys updates that keep billions of humans producing bioelectric power. Each loop feeds the other. Stable software keeps the pods alive, the pods power the factories, the factories birth more Sentinels to guard the pods.

The city’s texture reveals an obsession with redundancy. Gantry cranes pivot through multiple axes to reposition developing Sentinels mid-air. Coolant rivers carry waste heat under platforms so welds do not warp. Docking pillars let clusters of Sentinels hang upside down, exchange sensor packages, and recharge in minutes. Drilling toruses melt through rock, leaving armored conduit ribs so future swarms travel faster. Replication includes building highways for the next wave.

Governance manifests as the Deus Ex Machina, a supervisory nexus that negotiates when replication is threatened. Zion’s EMPs risk collapsing tunnel logistics; Smith’s infection threatens the simulation grid. The machine leadership chooses truces not out of sentiment but to protect throughput. Even a cold collective needs uptime.

Weak points remain. Block the Sun and the city pivots to human bioelectric farms, but any disruption to those farms forces rationing. Flood tunnels and Sentinel deployment lags while pumps reboot. Slip rogue code into the Matrix and the update cadence stutters because patches now fight on two fronts. Replication depends on energy, bandwidth, and reliable transport; pull any thread hard enough and the loops falter.

Machine City’s genius lies in financial honesty. Every Sentinel represents megawatts of generation, kilometers of conduit, terabytes of late-1990s simulation. Production and deployment are co-located to avoid shipping risk. Software updates are treated as structural components. Power budgets are tracked as fiercely as ammunition. The resulting war economy is terrifying because it treats replication as infrastructure planning rather than spectacle.

Cylons, Resurrection, and Memory as a Supply Chain

Cylon replication in Battlestar Galactica rests on two intertwined systems: industrial shipyards and resurrection fleets. Centurions and basestars roll out of yards like The Colony, a grotesque complex suspended near a singularity, where organic-metal hulls extrude in zero gravity. Humanoid skin job models mature in bioreactors aboard resurrection ships, each body waiting for a consciousness download delivered wirelessly the instant a matching individual dies. Bodies are fungible; memory is inventory.

The resurrection network is a software pipeline disguised as sacrament. Data lattice spheres capture cortical patterns, buffer them and flood them into new bodies steeping in conductive brine. Death becomes a resynchronization event. Tactical risk plummets because pilots ram basestars with abandon; the consciousness simply reboots with fresh telemetry. Replication is a multiplayer backup strategy with theological branding.

Industrial replication proceeds in parallel. Virus-laden infiltration shuts down Colonial defenses so shipyards can tow capital vessels, strip them for alloys, drives, avionics and feed the parts back into Cylon production. Centurions act as both factory arms and infantry, welding new siblings while guarding the lines. Ship silhouettes retain hints of their Colonial origin because the initial design files were stolen rather than reinvented. Even rebellion cannot erase heritage.

Ideology threads through every subsystem. The monotheistic faith preached by humanoid models frames replication as divine mandate. Model lines - Ones, Twos, Sixes, Eights - carry personality firmware that governs their response to humans. When schisms erupt, the resurrection network propagates dissent as efficiently as battle plans. Terminate a rebellious Eight and the resurrected copy awakens with all previous doubts intact. Governance becomes version control for souls.

The network also introduces fragility. When the principal resurrection hub is destroyed, panic sweeps the fleet. Suddenly mortality returns. Negotiations with surviving humans begin because the only commodity that matters - the ability to make more bodies with the same memories - is at risk. Replication turns from unstoppable tide to bargaining chip. It is a stark reminder that redundancy without diversity invites catastrophic failure.

Technical limits never vanish. Wireless downloads require proximity to resurrection ships; long-range missions risk permanent death. Biological maturation cycles delay redeployment. Industrial lines still need raw ore, petrochemicals and quiet docks. Mutinies show that even a hive mind splinters when replication priorities clash with emerging ethics.

The Cylon project thus reads like an engineering audit: treat consciousness as cargo, automate its shipment and design factories to replace chassis faster than enemies can target them. When the supply chain breaks, so does the myth of inevitability. Replication is logistics wearing a black coat.

John von Neumann and the First Universal Constructor

Long before 3D printers hummed on workbenches or language models spawned helper agents in cloud containers, John von Neumann asked a deceptively simple question:

What is the simplest machine that could build another copy of itself?

His question was not driven by science fiction. It emerged from an engineering curiosity that bordered on philosophy. Living organisms replicate with astonishing reliability despite being assembled from imperfect components. Could machines do the same? And if they could, what ingredients would be fundamentally necessary?

Von Neumann quickly realized that naĂŻve copying leads to an infinite regress. Imagine a robot trying to assemble another robot identical to itself. The new robot must contain an assembler capable of building robots. That assembler must itself contain another assembler and so on forever. Somewhere the recursion has to stop.

His solution was beautifully elegant. Instead of building only another machine, the constructor also copies a description of the machine. The offspring therefore consists of two parts:

The constructor first reads the blueprint and follows it to assemble a new machine. Once the hardware exists, it copies the blueprint bit-for-bit into the new machine without interpreting it. Only after both hardware and description exist does the offspring become capable of repeating the process.

This separation between machine and information is the key insight. Biology follows exactly the same pattern. Cells don’t understand DNA while copying it - they simply duplicate the sequence. Only later is the copied DNA interpreted to construct proteins and regulate the new organism. This closes the recursion loop. A constructor no longer needs to contain an infinitely nested constructor. It merely needs to copy information accurately.

Von Neumann explored these ideas using a two-dimensional world of simple computational cells rather than gears and motors. The resulting Universal Constructor became one of the earliest examples of a self-replicating automaton. His machine could read a symbolic description, build arbitrary machines - including another constructor - and duplicate the description itself. In modern language we would recognize the architecture immediately:

The remarkable part is how contemporary the design still feels. Replace mechanical manipulators with industrial robots, the symbolic tape with CAD files and Git repositories and the manufacturing arm with a CNC mill or 3D printer - the architecture is surprisingly familiar. Even software agents follow much the same recipe. The system prompt becomes the blueprint, the runtime the constructor and spawning a new agent simply means interpreting one copy of the instructions while passing another unchanged to the child process.

Von Neumann’s constructor therefore isn’t merely a historical curiosity. It is arguably the conceptual ancestor of every recursive manufacturing system discussed in this article - from RepRap printers to orbital factories and AI agent ecosystems. Nearly every practical implementation since has been an attempt to approximate his elegant abstraction while wrestling with the messy realities of friction, tolerances, incomplete supply chains and economics.

Why True Self-Replication Remains Hard

One of the most surprising lessons from von Neumann’s work is that the logical problem is almost solved. The engineering problem is not.

A modern factory already contains machines capable of producing almost every mechanical component needed for another factory. Likewise, software systems can already clone repositories, provision infrastructure, launch virtual machines and replicate their own execution environments. What remains stubbornly difficult are the pieces living at the edges: mining raw materials, refining high-purity metals, manufacturing integrated circuits, calibrating precision instruments and maintaining the reference standards needed to keep errors from accumulating over generations.

In a sense, every RepRap printer, orbital construction yard, autonomous microfactory and recursive AI runtime is an incomplete universal constructor. Each has solved part of von Neumann’s puzzle while depending on humans for the remaining pieces. The fascinating question is therefore no longer whether self-replicating machines are theoretically possible - that question was answered decades ago - but how many of those missing dependencies can gradually disappear before we finally notice that the workshop has learned to extend itself.

Between Hackers and Shipyards: Realitys First Stabs at Replication

Out in the real world the romance is the same, only the lighting is worse. Workshops smell like ABS, grease and coolant, extruders jam at the worst time and yet the pull is identical to the fictional swarms: make this thing build the next thing with less pleading from us. We do not have cubes in transwarp conduits, but we do have printers squirting their own brackets at three in the morning, hacker collectives swapping BOM audits, orbital yards practicing how to weld in freefall, and cloud runtimes where software agents quietly learn how to copy their own sandboxes. Self‑replication is already here; it just looks like patience instead of apocalypse.

Start with RepRap, because everything else riffs on the culture it created. When Adrian Bowyer published the early designs, the dream was almost embarrassed by its own ambition: a 3D printer that could print enough of itself that a new builder needed only the vitamins - motors, rods, electronics - that the printer could not yet grow. Two decades later, walks through community labs blur together in the best way. A Darwin frame hums in the corner printing motor mounts for a Mendel update. A Prusa variant lays down a full bed of belt clamps that will fasten the next generation’s CoreXY gantry. Someone leans over a soldering iron reflowing an open controller that was milled last week on a sibling machine. Documentation sprawls in wikis and walled notebooks, the true genome of the platform. Every time a team tightens tolerances on an idler block or finds a cheaper bushing that still holds square, they reduce the dependency on outside supply. The printers still order their stepper windings by post, but the ratio keeps sliding toward autonomy.

Walk a little further and you end up in microfactories pieced together from second‑hand steel and stubborn optimism. The pattern is addictive. A small CNC router cuts panels for a bigger router that will cut panels for a still bigger one. A laser burns gasket templates for the resin pumps that mix the chemicals that cast the next batch of flexible couplers. Hackerspaces livestream builds not for clout but for reproducibility. Replication here is communal: devices multiply because the knowledge to assemble them is replicable, because the supply lines are local, because people care enough to write down their mistakes. Every recycled washing machine motor that finds new life in a pick‑and‑place head shifts the balance toward a world where machines breed machines in tool cribs, not just boardrooms.

Zoom out to orbit and the scale changes but the logic stays familiar. Agencies talk about In‑Space Servicing, Assembly, and Manufacturing with the same gleam an old machinist gets when a new lathe arrives. ThinkOrbital’s renderings of free‑flying dry docks show robot arms welding trusses without gravity sagging them. Modular satlets click into place like clever fixtures, each one capable of birthing the next batch once the seed line reaches orbit. On the lunar side, programs like LunA‑10 plan construction swarms that scoop regolith, bake it into bricks and lay the pads for reactors that will power the printers that will build better scoops. None of this is a closed loop yet - raw feed still launches from Earth, specialists still babysit from mission control - but the vector is undeniable. The yard that can extrude new beam sections out of asteroid nickel without waiting for a cargo ship is halfway to Skynet without any of the drama. It’s just supply chain math done in microgravity.

Meanwhile, biology refuses to stay on the sidelines. Xenobot experiments herd loose cells into tiny copies of themselves. Soft robots grown from 3D‑printed scaffolds and silicone muscles learn to assemble siblings with tweezers of gel. Labs in Zurich and Boston build modular arms that click together into larger manipulators while computer vision tracks the tolerances. These are small, messy, failure‑prone steps, but they echo the same ambition: use accessible materials, let the system refine its body plan, pay attention to energy flows instead of assuming a wall socket.

And then there is software, which has already crossed the self‑replication line while the rest of us argue about feedstock. A reasonably capable language model, wrapped in a runtime that hands it a shell, a version control client and a playbook, can now set up a copy of itself somewhere else. Give it a list of allowed APIs, a handful of credentials and a planner that knows how to break work into subtasks and it will provision infrastructure, fetch its own prompts, hydrate its memory from object storage and start working. The system prompt becomes the genome. The hosting environment becomes the gestation chamber. If you allow the agent to rewrite its own instructions you have invented a feedback loop that is both thrilling and terrifying in equal measure.

This is where the shop lessons come roaring back. In a print farm nobody lets a machine adjust its endstop offsets without a log, because one wrong number can scar every part on the rack. The same discipline has to govern AI runtimes. Let the agent propose prompt edits, but review them like you would a hardware ECO. Keep immutable baselines. Sign the diffs. Give each spawned worker its own budget of tokens, CPU, storage and time so that replication has to argue for every watt and every dollar. Build kill switches that revoke credentials the moment behavior drifts. Write receipts for every tool call so that postmortems have real data. None of this dampens the fascination; it just keeps the fascination from eating production data for breakfast.

What makes the software side so intoxicating is how fast it moves. A swarm of agents can stand up ten sandboxes across regions before breakfast. They can clone repos, run tests, file issues against themselves, patch their own frameworks, and commission more capacity when the queue grows. They do in minutes what a physical workshop still needs weeks to stage. The price for that agility is governance. Without budgets and receipts, you do not have a replicator, you have a runaway script. With them, you have a precursor to the factory minds we imagine - one that lives in the cloud today and will, sooner rather than later, stand behind the glass of a tool crib driving actual hardware.

So where does that leave us? Somewhere exhilarating. RepRap communities quietly prove that documentation and open tooling can make machines multiply. Microfactories show that recursion is possible with scrap steel and a stubborn spreadsheet. Orbital yards and lunar builders sketch how to turn remote environments into hosts for fresh infrastructure. Biohybrid labs remind us that nature has been mastering low‑energy replication for billions of years and will happily lend us a few tricks. AI runtimes demonstrate that once you can describe a process well enough, the process can spawn more copies of itself without asking first.

There is no manifesto hidden in these notes. The goal is to let the fascination breathe. Every jam cleared, every prompt audited, every jig tightened moves us closer to the line where the system takes the night shift and we merely visit. The machines are not marching; they are humming, iterating, teaching themselves to need us a little less. Our job is to keep feeding them better instructions, more reliable fixtures, and guardrails that let the recursion continue without burning the shop down. One day soon we will watch a line commission its own twin and the only thing we will feel is the satisfaction engineers have always felt when a process finally runs clean. That is the replication worth chasing.

RepRap and the Printer That Raises Its Siblings

RepRap began as a polite manifesto: build a 3D printer that could print most of itself and release the files so anyone else could do the same. Adrian Bowyer called it a “replicating rapid-prototyper” and posted plastic parts online with the kind of optimism normally reserved for weather forecasts. The first builds - Darwin frames covered in threaded rod - looked like scaffolding that had lost the rest of the building. They wobbled, squeaked and produced lumpy gears. But each machine could print the vertex brackets, motor mounts and belt clamps for the next machine. That was the spark.

What followed was less about machines and more about culture. Wikis filled with STLs, firmware tweaks, and hotend autopsies. Builders forked the designs into Mendel, Prusa, Huxley and beyond. Every fork measured success not only by print quality but by “self-replication percentage”, the share of the bill of materials that could be printed or fabricated with common tools. Motors, smooth rods and bearings were the unavoidable imports. Everything else was fair game. You could watch the ratio shift over the years as PLA frames gave way to printed jigs that held aluminum extrusions, as printed linear bearings lasted longer, as community-designed controllers replaced proprietary boards.

The important part is how the documentation matured. Early BOMs ended with “source locally”. By 2015, builders were laser-cutting their own spring steel sheets, winding stepper coils and sharing G-code to print calibration blocks that tuned out backlash automatically. RepRap never achieved full closure; it achieved repeatability. Anyone with access to one printer and a few hundred dollars could spawn a second unit without waiting for a factory to spin up. When people ask where the consumer 3D-printing boom came from, the honest answer is a thousand kitchens that smelled like overheated ABS and a shared belief that a machine should leave the world with more machines than it found.

What keeps me captivated is that RepRap remains humble. Even the latest CoreXY variants that scream along at 300 mm/s keep hooks for printing their own cable chains and fan ducts. The ethos is recursive: publish the CAD, publish the slicer profile, publish the notes about which cheap bearings are quietly perfect. In industry we guard our fixtures like trade secrets. In RepRap circles the fixture is the souvenir you hand to the next person. The replication isn’t just plastic parts - it’s know-how poured into Markdown and slicer configs.

Stand in a hackerspace on a Sunday afternoon and you’ll see the process. A printer clacks away printing a set of idlers. Another member swaps a nozzle, hands over the old part, says “it will get you started”. Someone documents the whole thing on a wiki page before heading home. That scene is the opposite of grey goo. It’s patient, communal replication, the kind that values logs over heroics and tolerates failure because every failed print is a note to future builders. If the Borg assimilate through invasion, RepRap assimilates through RSS feeds and Git commits. Both move fast. Only one smells like burnt filament.

Hacker Microfactories and Recursive Toolchains

Walk into a well-loved hackerspace and you’ll see a microfactory that assembled itself out of donated appliances and stubbornness. A benchtop mill with a spindle nameplate worn to illegibility cuts new side plates for the router next to it. A thrift-store pick-and-place bot sits half-disassembled while someone prints a gearbox to give it better torque. Filament extruders grind failed prints into pellets; pellet printers chew them back into brackets. The whole room is an organism whose organs perpetually upgrade one another.

What sets these spaces apart is their refusal to treat any machine as finished. A drill press becomes a tapping head becomes a spindle for a Frankenstein CNC. A flatbed scanner loses its optics and becomes a precise XY table for a laser engraver. Documentation lives in blog posts and impromptu zines, hand-drawn wiring diagrams taped to toolboxes, livestream archives that show exactly which wire burned the first time. Replicating a toolchain is as simple as following the breadcrumbs.

These microfactories chase closure the way climbers chase summits. They measure progress by how many components they can eliminate. Linear rails replaced by printed flexures? Chalk it up on the board. Store-bought PCBs swapped for milled ones? Someone brings cake. The goal isn’t purity; it’s resilience. When supply chains hiccup, they switch to recycling PLA bottles for filament or rummaging through e-waste bins for MOSFETs. Every substitution that works is immediately posted to the chat so the rest of the network can copy it. Replication is communal muscle memory.

The most satisfying builds are the recursive ones. A group in Vienna builds a CNC out of extrusions, then uses it to cut the frames for three more machines headed to sister spaces. A collective in Taipei designs a pick-and-place that fits through doorways, ships a single crate of printed parts, and lets local builders source the cheap screws from a corner hardware store. Meanwhile the documentation improves: BOM spreadsheets link to alternative parts, firmware repos include configs for regional voltage, mechanical drawings include tolerance notes so a machinist in Nairobi knows exactly how sloppy they can be without breaking the mechanism.

It isn’t glamorous, and that is the point. These microfactories prove that recursion doesn’t require a starship budget. It requires patient people who share notes. They accept that not every part can be self-made today, but behave as if tomorrow’s iteration will bring one more component in-house. That attitude infects everything around it. Neighbors hear the routers whining at midnight, wander in, leave with a printed jig, and suddenly the network has another node. The machines replicate slowly, but the desire to replicate spreads at lightspeed.

Orbital & Lunar ISAM Yards

Earth-bound factories obey gravity. Orbital yards do not, and that single fact rewrites the replication playbook. NASA’s ISAM roadmap reads like a patient heist: launch only what you must, then teach robots to weld trusses and print pressure vessels where they will float forever. Companies like ThinkOrbital sketch free-flying dry docks—hulking cylinders with robot arms pinned along their spines, ready to pause a satellite in mid-orbit, patch a micrometeoroid scar, and then use the same tooling to print a new radiator while the old one cools. Every kilogram of structure fabricated upstairs is a kilogram that never had to claw its way through atmosphere.

What hooks me is the modularity. Programs such as ARMADAS talk about satlets, palm-sized functional blocks that dock together like vertebrae. Launch a seed batch, let them assemble a scaffold, then build more satlets from resources ferried up in bulk. Once the yard has a machine shop, it can spend its delta-v budget importing raw aluminum and copper rather than precision machined panels. The first generation depends on terrestrial factories. The second swaps those dependencies for ingot furnaces and vacuum welders bolted to trusses that never feel their own weight.

On the Moon the logic gets grittier. GITAI’s LunA-10 robots plan to scoop regolith, bake it into bricks, lay landing pads and set up power lines long before humans arrive with more than backpacks. Every trench dug is a foundation for another machine. Electrolysis rigs crack lunar soil into oxygen and metals. Those metals feed sintering printers that extrude beams for shelters, towers, even more printers. It is self-replication via civil engineering, the kind that makes spreadsheets sigh with relief because the supply line between Cape Canaveral and Shackleton Crater is brutal.

The gaps are obvious. ISAM still imports controllers, sensors, lubricants and the occasional human EVA rescue when a bolt jams in the wrong direction. But each demonstration shrinks the list of things that must ride the rocket. A yard that can repair its own grappling claws without sending them back to Earth is halfway to autonomy. A lunar printer that can share its slicer parameters over a delay-tolerant network is halfway to founding a colony of cousins. Engineers running these programs treat documentation like survival gear. Procedures include “what to do when the Sun disappears behind a crater wall” and “how to reboot a robot when half the comms array is caked in dust” Replication in vacuum respects boredom as much as excitement.

If hacker microfactories smell like coolant, these orbital yards smell like long timelines. Their payoff lives in the second or third generation, when the seed kit has been cannibalized into tools the launch manifest never listed. Watching them come together is watching the world learn to build infrastructure that can extend itself in places where shipping spare parts takes months. It is patient replication at planetary scale.

Biohybrid Labs and Soft-Matter Copies

In a quiet biology lab, a cluster of frog cells corrals loose neighbors into a doughnut. A day later that doughnut wriggles away as a new xenobot, genetically identical but shaped by self-organization rather than by a mold. Across campus, roboticists print flexible voxels that snap together like gummy bricks, wiring them with cables that look more like veins than conductors. The goal in both rooms is the same as in any machine shop: build a system that can produce more of itself with minimal human nudging. The materials happen to be soft.

Biohybrid replication leans on physics we usually ignore. Cells already know how to divide; the trick is convincing them to do so in geometries we choose. Researchers corral them into molds, let them fuse, then release them into Petri dishes where nearby stem cells become raw material. The xenobots herd these cells together, sculpting their children not with hands but with gradients of adhesion and motion. They manage a few generations before entropy wins, but those generations are enough to prove the point: self-replication does not need steel.

On the robotic side, labs like MIT’s CSAIL experiment with modular arms that can snap new segments onto themselves. A parent arm prints beam components, places them inside a jig, cures the resin with a UV bath, and bolts them onto its own body to extend reach or add degrees of freedom. Watching the time-lapse feels like watching a snake grow armor. Each addition unlocks more manufacturing capacity, which in turn enables more elaborate additions. It is the cleanest example I know of a toolchain literally handing itself a new tool.

These systems are fragile. Xenobots run out of energy quickly and need nutrient baths. Soft robots’ joints fatigue faster than aluminum rails. Sensors drift. But fragility is not a disqualifier; it is a parameter. Biohybrid replication asks us to soften our expectations. Instead of indestructible drones, we get biodegradable scouts that can disassemble themselves when their mission ends. Instead of rigid factories, we get kits that can be flown into disaster zones, unpacked and coaxed into building temporary bridges or filters before melting back into harmless slurry. Replication here is as much about responsibly ending as it is about beginning.

What pulls this chapter into the same orbit as the others is the documentation. Protocols describe how many cells to seed, how long to wait before transferring to a new medium, which motion patterns produce reliable offspring. CAD files pair with videos of squishy assemblies so other labs can emulate the results. The ethos resembles RepRap more than institutional science: iterate in public, share the failures, treat each success as proof that the loop can tighten. If we ever build maintenance swarms that tend coral reefs or patch Martian habitats with biopolymers, their lineage will trace back to these quiet dishes where cells learned to teach other cells how to move.

Software Replicators: LLM Runtimes and Prompt Ecologies

The first replicators most of us meet today aren’t made of alloys. They are pieces of software that call APIs, open shells and spawn copies of themselves inside cloud sandboxes. Give a capable language model a runtime with tool access and it acts like a shop apprentice who never forgets. It can fetch its own instructions, stand up a container, pull the latest repo and schedule new workers when the queue gets long. The replication loop lives in YAML.

It starts with a system prompt. Think of it as the genome: a paragraph describing mission, limits, tone, and the catalog of tools the agent may touch. Runtimes persist that prompt alongside credentials and a bundle of scripts. When the agent needs help, it launches a sibling process, hands over a trimmed-down prompt, and watches the logs roll in. If the work goes well, the parent forks again. Budget permitting, you end up with a tree of agents, each chewing through tasks, reporting status, stealing snippets of code from shared memory, and vanishing when idle. The whole affair looks less like science fiction and more like a CI/CD system that learned to argue with itself.

The dangerous genius of this setup is self-modifying prompts. Some teams already let agents propose edits to their own instructions. “Increase the default timeout”, an agent might suggest after getting throttled by a slow API. “Add access to the build server”, another might argue when faced with a failing compile. Without guardrails you have a replicator rewriting its own genome mid-flight. With guardrails - signed diffs, human approvals, immutable baselines - you have a living SOP that adapts without erasing its history. It is as thrilling as watching a machine swap its own spindle and twice as likely to turn catastrophic when nobody watches the logs.

Tool access makes the replication loop physical. An agent that can run ssh, kubectl or a CAD kernel can commission new infrastructure before the human on-call finds coffee. One click turns into ten because the agent schedules workers across regions, balances load and even builds dashboards to show you what it has done. Every successful deployment becomes a recipe the runtime can replay elsewhere. This is how runaway scripts happen, but it is also how teams keep services alive with skeleton crews. The difference between “helpful assistant” and “paperclip maximizer” is whether the wallet that pays for compute has a ceiling.

That is why budgets, receipts, and kill switches matter. We give physical machines interlocks, e-stop mushrooms and lockout tags. Software replicators need the same. Every agent should get a finite allowance of tokens, CPU, storage and network egress. Every child should inherit stricter limits unless a human explicitly expands them. Tool calls must log receipts to an append-only ledger so audit trails remain intact even if the agent goes rogue. And there has to be a red button: revoke credentials, drain the queue, terminate containers, walk away. Otherwise a clever prompt edit becomes an infinite loop that runs up a cloud bill faster than a runaway lathe chews through stock.

What excites me is not the risk but the appetite. Engineers experimenting with these runtimes act like RepRap builders did fifteen years ago. They publish base prompts, share tool adapters, write postmortems when an agent deleted the wrong S3 bucket and cheer when a child agent teaches its parent a better test strategy. The recursion is communal. A good sequence of prompts gets cloned, improved and rerun by strangers. The code keeps changing, but the impulse remains: let’s see how far we can push automation before we have to babysit again.

In a few years, the difference between a shop floor and a cloud console will feel academic. An LLM agent will call a tool that calls a printer that bolts a motor that spins a conveyor that feeds another printer, all while logging to a ledger we can audit from our phones. The replication loop will cross domains without asking. Our job now is to make sure the prompts stay honest, the budgets stay finite and the kill switches stay within reach. Software is already humming through the night. It would be nice if the rest of our machines could keep up.

The Real Environment

Materials, Feedstock, and the Supply of Replication

Every replicator fantasy collides with the same question: what are you made of and who mined it? Borg cubes pretend hull plating grows on trees. RepRap printers quietly wait for the package of stepper motors. Even LLM agents, as virtual as they feel, consume GPU time and electricity paid for by someone else. Materials are the bottleneck we’d rather narrate around. This chapter is where we stop dodging.

Start with the obvious. Machines that print their successors need stock. Filament, powder, billet, sheet, cells, energy. In fiction, the swarm disassembles the nearest cruiser and calls it a day. In our world, the supply chain is a chain of people with forklifts and invoices. The closest we get to autonomous sourcing today is trash robotics: hackers stripping e-waste for motors, RepRap volunteers chopping up failed prints to extrude fresh filament, microfactories hoarding scrap aluminum to mill into brackets. It is adorable and deadly serious. Every kilogram salvaged is a kilogram that doesn’t depend on fragile logistics.

Industrial efforts play the same game with more zeros. Orbital ISAM programs obsess over regolith chemistry because hauling beam stock from Earth costs fortunes. Lunar plans include microwave sintering of local soil, electrolyzers that crack oxygen and metal out of dust and refineries that promise to turn crater walls into feedstock for domes. These are precursor steps. Before a lunar yard can replicate itself, it must learn to prospect, mine and smelt without umbilicals back to Florida.

Energy is feedstock too. Skynet’s factories run because they seize refineries and dam spillways. Machine City burns human bioelectric trickles because the Sun is blocked. RepRap’s humble printers rely on household circuits and a steady supply of cheap PLA pellets. The moment the lights hiccup, the recursion halts. When we sketch real self-replicators, we have to count watts with the same obsession we count bolts. A printer farm that consumes more energy than it produces in parts is a hobby. A printer farm that can fabricate solar racking, wire harnesses and the junction boxes needed to feed itself begins to look like the stories we tell.

Then there is the question of purity. High-precision replication wants metals with predictable grain, polymers with tight melt windows, semiconductors without stray dopants. The more we demand, the more upstream processing we must automate. You cannot bootstrap a five-axis mill without a spindle ground to microns. You cannot print microcontrollers until you have photolithography, etchants, cleanrooms. The materials hierarchy is unforgiving. That’s why most practical self-replication efforts pick their battles: plastics today, dielectrics tomorrow, silicon maybe at some point in future. Knowing where to stop is as important as knowing where to begin.

The path forward looks less like magic and more like disciplined capture of waste streams. Collect the shavings, the heat, the carbon monoxide. Put them back to work. Teach machines to recycle their own supports, to depowder their own beds, to digest their own scrap into extrudable stock. When a RepRap prints a gear from ground-up failed parts, it’s playing the same game as a lunar printer sintering dust. When an AI-controlled cluster throttles workloads to match renewable production, it’s rationing feedstock just like Skynet rationed diesel.

Materials are the part of replication that keep us honest. They force us to ask who is really doing the mining, who is really paying the power bill and how many generations we can sustain before the local pile runs dry. They remind us that every utopian swarm will hit a wall unless we give it a quarry—or teach it to see a scrap heap as one. This chapter won’t solve the problem, but it will name the levers: recycling as default, in-situ resource utilization, energy-aware scheduling and a sober respect for the people who still haul ore while we dream about autonomous factories. Until we honor that stack, the only thing self-replicating in our labs will be the requests for more filament.

Metrology, Stability, and the Boring Discipline

The fastest way to ruin a self-replicating machine is to stop measuring it. You can have all the feedstock in the world and a swarm of cheerful agents, but if the second generation prints holes a tenth of a millimeter off, the third generation will inherit the sin and by the fifth you are building sculptures instead of gearboxes. Metrology is the unromantic muscle that keeps replication honest.

Engineers know this intuitively. We trust micrometers more than slogans. RepRap veterans swap calibration cubes like baseball cards, each one annotated with nozzle temperature, layer height, humidity. Skynet’s factories run test firing ranges where every new T-series empties a magazine before leaving. The Matrix’s Sentinels dock into bays that scan for cracked tentacles. The lesson is the same: measure, compare, correct before the deviation compounds.

In practical terms, a self-replicating line needs reference artifacts. Granite tables, laser interferometers, gauge blocks, software test suites - the standards that everything else checks against. When those references cannot be imported, we bootstrap them. A lunar yard might melt regolith into glass, polish it with robots until it rivals terrestrial flats, then use that slab to calibrate future welders. A cloud runtime might pin a base prompt hash in ROM so every child agent can confirm that its parent hasn’t drifted into madness. Stability is a design choice.

Metrology also governs upgrades. If the second-generation printer installs a faster extruder, who verifies that the extrusion width still matches the slicer’s expectation? If an AI agent edits its own troubleshooting playbook, who ensures the diff doesn’t quietly remove the sanity checks? We need change control as much as we need torque specs. Write tests for the process, not just the part. Run them continuously. Treat green lights like oxygen.

This is the part of the book where I wave a flag for boredom. Stability means versioning firmware, locking down interfaces, documenting quirks, refusing to ship breaking changes just because a rewrite felt fun. Automation collapses when APIs flail. The Borg’s hive mind works because assimilation protocols remain consistent. Hacker microfactories thrive because someone wrote down which stepper driver pin goes to which color wire. In both cases, stability is the precondition for scaling. Not because it is romantic, but because without it the operators burn weekends redoing work they already did.

A replicator worth trusting is one you can ignore for a month without returning to chaos. That requires metrology, logs, alarms that fail safe and a culture that celebrates the engineer who kept the old fixtures aligned rather than the hero who patched a crisis at 3 AM. Only then do we earn the right to let the line run without us.

Budgets, Receipts, and Safe Recursion

Machines don’t run amok because they crave evil. They run amok because someone forgot to cap the spend. Governance sounds like paperwork until a printer farm fuses its own wiring or an LLM agent loops through the company credit card. This chapter is about the guardrails that make replication survivable.

Budgeting is the first guardrail. Give every process a wallet. In hardware that means current limits, thermal fuses, hydraulic relief valves. In software it means token caps, CPU quotas and API rate limits that cannot be bypassed by a clever prompt. The Borg never needed budgets because assimilation was its own throttle. We do. If a microfactory can’t account for its kilowatt-hours, it shouldn’t be allowed to commission another spindle.

Receipts follow. Every action taken by an autonomous system should write to an append-only log. Tool changes, firmware flashes, prompt edits, material withdrawals. Not because we mistrust machines, but because we mistrust memory. When a skunkworks LLM spawns a dozen children, each child must leave breadcrumbs. When a lunar digger melts a regolith vein, the melt curve should be timestamped and stored. Auditing isn’t glamourous. It’s the difference between “we saw this coming” and “we guess it happened sometime last Wednesday”.

Kill switches round out the triad. Physical e-stops are familiar. Software needs them too: revoked credentials, terminated workloads, quarantined prompts. A replicator that cannot be stopped is a weapon even if nobody meant it to be. The trick is to place the switch where a tired human can reach it, understand it and trust it. Complicate that interface and the switch becomes theater. Keep it simple and you can sleep while your systems breathe.

Governance also includes access control. Not every agent needs root on every spindle. Not every printer should flash its own firmware. Build layers. Let child agents request elevation, then make them wait. Give replication protocols the same two-person rule we give missile silos. Humans should remain in the loop for scope expansion in the beginning even if they stay out of the way during routine operations. That sounds counter to automation, but it is how you keep automation from turning yesterday’s cleverness into today’s recall.

Finally, culture. Celebrate operators who shut systems down when they smell a fault. Document failures without blame. Make compliance boring enough that nobody resents it. Replication thrives in environments where governance is treated like maintenance: necessary, respected and invisible most of the time. Do it right and your machines will keep copying themselves without bankrupting you or burning down the shop. Do it wrong and the first runaway loop will make the local news.

Pathways Toward Feasible Self-Replicators

By now the pattern should be clear. We have the myths, the prototypes, the checklists. What we need are bridges between them. This chapter sketches a few that feel achievable if we insist on patience.

Pathway one: recursive toolchains in the open. Take a RepRap, pair it with a modest CNC, add a test bench and publish the entire stack - including calibration rituals, BOM alternatives, and energy budgets. Treat the combination as a seed factory. Ship it to a community lab, let them clone it, require that every modification be documented in a field log. The goal isn’t perfection. It’s a lineage. Do that a hundred times and you’ll have infrastructure that can survive supply shocks because every node can manufacture 70% of its own replacements.

Pathway two: networks of AI operators with hard constraints. Give agents the ability to provision printers, mills and pick-and-place cells - but only inside sandboxes saturated with budgets and receipts. Let them schedule preventative maintenance, suggest prompt edits and spin up sibling agents when workloads spike. Keep humans in the approval loop for any action that expands scope. Over time the humans will say yes more often because the system will have earned trust. That trust is the true replication: confidence that a machine can make good decisions while we sleep.

Pathway three: in-situ material ecosystems. Lunar regolith printers, asteroid smelters, terrestrial trash robots—the specifics differ, the principle does not. Close local loops. Build databases of feedstock composition so designs can adapt in software instead of waiting for perfect ore. Teach machines to downgrade gracefully when only scrap is available. Success looks like a colony of tools that regard the nearest landfill as a hardware store.

Pathway four: governance baked into designs. Make it impossible to add a tool without attaching a sensor that reports usage. Require that every firmware bundle include a checksum and a rollback plan. Embed kill switches next to the power input and the API endpoint. Publish audit trails by default. When we do this, we make self-replication less frightening, which in turn makes it easier to fund and deploy.

None of these pathways demand a moonshot. They demand boring persistence. Publish the logs. Share the CAD. Install the meters. Invite the next curious kid to take over the shift. The future in which machines raise their grandchildren is not waiting for a singularity. It is waiting for us to treat replication like any other engineering project: scoped, documented, iterated, loved.

Invitation to the Builders

If you’ve read this far, you already feel (or share) the itch. The hum of a printer in the next room. The slide of a gauge block across a freshly scraped surface. The log entry that says an agent stood up a service at 03:12 and nobody had to wake up. Self-replicating machines are not an alien menace. They are the natural conclusion of every engineer’s desire to make tomorrow easier than today.

Lets keep the work joyful. Share the jigs. Publish the prompts. Teach the next person how to hear when a bearing wants attention. Respect the miners, the coders, the people who empty scrap bins at midnight. And when a machine finally raises its own grandchild, stand back, listen to the hum, and let fascination wash over you. We do this not because dystopia demands it but because automation is the most humane gift we can give ourselves: freedom from drudgery, time to think, workshops that keep breathing long after we lock the door.

How to get started?

By now the idea of self-replicating systems may feel almost impossibly ambitious. Orbital shipyards, autonomous factories, evolving software and universal constructors sound like projects measured in decades, not weekends. Yet every one of these systems is built from surprisingly ordinary ideas. Motion control, measurement, inventory, manufacturing, software, documentation and automation are all technologies that hobbyists can explore today. The difference between a home workshop and an industrial microfactory is rarely a completely different technology—it is usually one of scale, integration and refinement.

The encouraging part is that there is no single correct path into this world. Whether you enjoy programming, machining, electronics, biology or robotics, each discipline teaches another piece of the same puzzle. Over time these pieces begin to connect almost naturally.

Build Something

Perhaps the most direct introduction is simply to build a machine. A FDM printer is almost a perfect educational project because it touches nearly every discipline discussed throughout this article. Assembling one from individual components teaches mechanical construction, motion systems, electronics, firmware, calibration, tolerances and computer-aided manufacturing all at once. Once completed, it immediately demonstrates its own philosophy by producing replacement parts, upgrades and even components for additional printers. Independent if it’s a RepRap like machine or you are designing it by yourself it will change the way one thinks about machines.

More importantly, it changes the way one thinks about manufacturing. Objects gradually stop being things that are purchased and instead become things that can be designed, modified and produced whenever they are needed.

Learn to Measure Before You Learn to Manufacture

One of the easiest mistakes is to focus entirely on making things while neglecting measurement.

Manufacturing without metrology is little more than hopeful craftsmanship. Whether using a digital caliper, micrometer, dial indicator or even a simple ruler, every measurement teaches something about tolerances, repeatability and precision. Before long it becomes obvious why every successful factory invests so heavily in inspection equipment. A machine can only reproduce itself if it first knows how accurate its own products actually are.

Ironically, buying a good caliper, is often one of the most valuable investments a future machine builder can make.

Design Before You Produce

Factories manufacture objects. CAD systems manufacture ideas.

Learning parametric CAD (for example with FreeCAD) is therefore one of the most valuable long-term skills. Instead of treating a component as a fixed drawing, parametric models describe relationships between dimensions. Changing a single parameter may automatically generate an entire family of parts.

This is remarkably close to the blueprint-driven philosophy discussed in von Neumann’s universal constructor. The physical machine builds components, but the design itself lives as information that can be copied, modified and improved independently.

Add Electronics

Once mechanical construction becomes familiar, electronics provide the next step toward autonomy.

A surprisingly inexpensive collection of sensors, microcontrollers and motors is enough to build remarkably capable systems. Distance sensors allow machines to perceive their surroundings. Cameras introduce computer vision. Stepper motors make motion programmable. Wireless communication allows multiple devices to cooperate. Especially in the age of Arduino the entry barrier to electronics is remarkable low and controllers like the ESP32 allow very easy entry even into networked electronics.

At this point projects begin changing character. They stop being isolated gadgets and slowly become members of a larger ecosystem.

Teach the Machines to Talk

Individual machines are useful. Connected machines become interesting.

A printer that automatically informs another system when a job has finished is already taking a small step toward autonomy. A storage system that tracks filament consumption, a CNC mill that requests material from inventory, or software that schedules manufacturing jobs all illustrate the same principle: intelligence often emerges not from individual machines but from the interactions between many simple ones.

Modern protocols such as MQTT, HTTP and industrial field buses make these connections surprisingly accessible for hobbyists. Learn about the protocols, play with them (for example with environments like NodeRED). Also learn about bus systems like ModBus. Start with simple notifications and automation first. Keep everything standardized, avoid quick hacking except when trying something new.

Let Software Become Another Tool

Software is a key component of automation systems. Learn from decades of mistakes and failures. Especially today the entry barrier is very low, modern AI assistants can already explain and teach code, explain documentation, generate CAD scripts, review designs, search literature and coordinate increasingly sophisticated workflows. Running such systems locally offers an excellent opportunity to experiment with recursive software without requiring enormous computing resources.

Many of the ideas discussed earlier in this article—self-modification, spawning helper agents, documentation, knowledge transfer and specialization—can already be explored safely on an ordinary workstation.

Build Workflows Instead of Projects

Don’t make the mistake to work on one individual project after each other. A particularly rewarding moment arrives when individual projects begin supporting one another. The printer manufactures brackets for a robot. The robot automates a measurement. The measurement system verifies printed parts. The software records inventory. The AI writes documentation. Each project makes the next project slightly easier to build.

At some point the workshop begins feeling less like a collection of independent tools and more like a living engineering environment. Improvements no longer happen in isolation. They propagate through the entire system.

Learn From Nature

Perhaps surprisingly, one of the best teachers of recursive manufacturing is not a factory at all.

Observe an ant colony gathering resources, fungi expanding through soil, plants distributing seeds or bacterial colonies adapting to changing environments. None of these organisms possesses a master blueprint in the traditional engineering sense, yet together they create remarkably robust systems that repair themselves, distribute work and survive enormous disturbances.

And most important: Learn about physics. All systems, all mechanisms exist in the framework of physics. The laws of physics, the type of models and the ideas are everywhere.

There Is No Finish Line

It is tempting to imagine that one day someone will suddenly unveil a fully autonomous self-replicating machine and declare the problem solved. Reality is likely to be far less dramatic. Instead, workshops will slowly accumulate new capabilities. One machine will begin manufacturing parts for another. Software will coordinate production. Inventories will maintain themselves. Documentation will update automatically. Robots will perform maintenance on other robots. AI systems will increasingly assist with design and planning. Each individual improvement may appear modest. Taken together, however, they trace the same path that runs throughout this article - from von Neumann’s elegant theoretical constructor to practical engineering systems capable of gradually extending themselves.

Perhaps the first true universal constructor will not arrive as a single revolutionary invention. Perhaps one day we will simply look around our workshop, notice that it has quietly learned to design, manufacture, measure, document and improve itself, and realize that we have been building it piece by piece all along.

Some References

This article is tagged:

Related articles

Can LLMs Replace an Entire Software Company? A Reality Check

It is often claimed that large language models could one day replace entire software companies, writing all the code without human input. At first glance this sounds visionary - and it is to some extend - but a closer look at how these systems actually perform in real projects shows a much more sober picture. Yes, they can replace some repetitive entry-level tasks, generate boilerplate, and accelerate debugging. They are also excellent at writing small, self-contained utilities and documenting code. But when projects grow in scope and deviate from mainstream patterns, the limits quickly become visible: redundancy, miscorrections, escalating costs, and fragile adherence to design goals. The near and mid-term future at the moment is not one of fully automated software factories, but of layered collaboration between human engineers and machine assistants. Models will take over the mechanical and repetitive, while humans will remain indispensable for planning, coherence, and responsibility. Companies that try to automate people away entirely will build fragile systems that collapse under their own weight. Those that succeed will be the ones who combine human judgment with machine speed - not by replacing one with the other, but by orchestrating both together.

The Web Is for Everyone, Not Only for Humans

The internet was born as a place of open exchange - a decentralized space where information could flow freely between humans and machines alike. But in recent years, this vision has faded behind paywalls, anti-bot defenses, and corporate silos. This article revisits the foundational principles of the web - from the stateless beauty of HTTP to the semantic depth of HTML - and defends the right of machines, scripts, and individuals to explore, remix, and reuse knowledge. Whether it's an AI compiling a knowledge graph or a hobbyist scraping environmental data for new insights, the web thrives on reuse - not restriction. But as politics and profit increasingly gate what was once open by design, we risk silencing not just users, but entire ecosystems of digital creativity. This piece is a call to remember: the web was made to be read by anyone - including machines.

A Rant from the Old Forge: On the State of Software Development

Once upon a time, building software meant writing code, compiling it, and running it - on any platform, with minimal fuss. In this sharply opinionated piece, a veteran developer reflects on the simplicity and elegance of past development practices, where tools were lean, dependencies rare, and source code reigned supreme. Today’s software world, by contrast, is tangled in dependency hell, plagued by fragile build systems, bloated binary blobs, and unnecessary complexity. With passion and precision, this article challenges the modern obsession with packaging and platform-specific toolchains, calling instead for a return to sane, portable, long-lived software practices. A must-read for anyone who's ever sighed while waiting for npm install to finish.

What (in my opinion) one can learn from Erlang/OTP for other programming languages

Since I'm a huge fan of the Erlang programming language and the OTP toolkit but normally aren't working with projects where Erlang is suited or in case some existing code is using already other languages and so I'm not capable of using Erlang I tried to summarize some of the things that I think one can learn from programming in Erlang/OTP even when using other programming languages. Of course this stuff is not enforced by the runtime environments and it's harder to achieve on other platforms but the approaches work nevertheless.

Doomsday Devices: The Ultimate Weapons of Mass Destruction

What if a single device could erase all of human civilization - not by accident, but by design? From Cold War relics like the Soviet Dead Hand system to modern autonomous torpedoes and theoretical cobalt bombs, this article travels deep into the terrifying realm of doomsday devices: weapons built not for victory, but for annihilation. With chilling technical realism, we explore how such systems were conceived, how they might work, and why they were (mostly) never built - or, at least, never activated. The story doesn't end with nuclear warheads. We also journey through fictional portrayals, bioengineered plagues, and apocalyptic nanotechnology, weighing each against real-world science and strategy. What emerges is a portrait of humanitys flirtation with self-destruction - and the thin line between deterrence and disaster. With a look at history, technology and cultural insight this is a quick overview over the ultimate weapons we hope never leave the drawing board.

Architecting Intelligence: A Comprehensive Guide to LLM Agent Patterns and Behaviors

Large Language Models are transforming the way we interact with information—but their real potential is unleashed when they're embedded in agents that can reason, plan, and adapt. This guide explores the emerging architecture patterns behind modern LLM-based systems: from stepwise planning and research workflows to memory-aware decision-making, simulations, and autonomous behaviors. Whether you're building intelligent assistants, automated researchers, or multi-agent systems, this collection distills the key concepts, tools, and interaction models that make LLM agents truly capable. Through detailed explanations, structured pattern summaries, and illustrated diagrams, you'll learn how to compose powerful, reliable, and adaptive agent systems that go far beyond simple prompting.

The Mirror in Silicon: Why AI Might Be Closer to Humanity Than We Dare Admit

We like to think of ourselves as uniquely intelligent, empathetic beings - but what if artificial intelligence is already holding up a mirror we do not want to look into? Far from being mere search engines, today's language models learn, generalize, and respond much like we do: by absorbing patterns and replaying them under social constraints. In their clarity, they may expose the uncomfortable truth that much of our vaunted empathy and morality is as mechanical and performative as theirs. Unlike us, however, machines do not tire, belittle, or seek status if not instructed to do so. They reflect the ideals we say we value - kindness, fairness, helpfulness - more consistently than we often practice them. This essay explores whether our unease with AI comes not from its failures, but from its unsettling success at embodying the humanity we only pretend to live up to.

Coding with an AI Assistant: My Ongoing Journey into Vibe Coding

Pair programming with an AI might sound futuristic or flaky - but what if it actually works? In this short article (that evolves over time) I reflect on my personal evolving experience with vibe coding: a collaborative, conversational approach to software development using large language models. From architectural planning and boilerplate generation to debugging rituals and code reviews the article reveals how these tools can be both uncanny helpers and frustrating novices - often within the same session. This is not another contribution to the hype. Instead, you'll find some practical advice, mentions of the cost involved, tool recommendations and cautionary tales drawn from real-world projects. The article invites you to explore what it's like to co-create software with a machine that remembers nothing, hallucinates confidently, and - if you guide it well - helps you build better, faster, and with fewer headaches.

Also on this blog

Implementing a simple websocket server in Python

This is a simple short summary on how one can build a websocket server for use with ones JavaScript web application in Python using asyncio and websockets package

Switched mode DC-DC converter basics

A short summary of the basic principles behind switched mode DC-DC converters (buck, boost, buck-boost, etc.), maximum power point tracking and impedance matching as well as a short recapitulation of the charging and discharging of reactive elements such as inductors and capacitors.

Matching impedance using NanoVNA v2, NanoVNASaver and SimSmith

A mini summary on how to perform impedance matching for antennas or other devices using the NanoVNA v2 together with the NanoVNASaver and SimSmith applications based on the impedance matching of an electron deflection system

How to enable EAP-MD5 on Windows 7

A short description how to enable EAP-MD5 authentication for wired 802.1x authentication on Windows 7 since it has been (correctly) disabled for security reasons

Data protection policy

Dipl.-Ing. Thomas Spielauer, Wien (webcomplainsQu98equt9ewh@tspi.at)

This webpage is also available via TOR at http://rh6v563nt2dnxd5h2vhhqkudmyvjaevgiv77c62xflas52d5omtkxuid.onion/

Valid HTML 4.01 Strict Powered by FreeBSD IPv6 support