Voyager Wasn't in a Hurry (and That's Why It Still Works)

There's an image making the rounds that almost everyone in tech has seen by now. On one side, Voyager 1: launched in 1977, now in interstellar space, running on about 69 KB of memory. On the other, a task manager screenshot: two LinkedIn tabs using more than 2.4 GB of RAM.

It's a meme, and like every meme it oversimplifies. But it didn't go viral because it's funny. It went viral because we all know there's some truth to it.

Around the same time, another LinkedIn post went viral arguing the opposite. A Meta hardware engineer says every generation of engineers writes sloppier code than the last, "and I think that's great." He tells how, on a device with 4 GB of RAM, teams were told they only had 2 GB, to force them to fit. How they shipped the product in eight months with AI agents generating code at full speed. And he closes with: "Voyager had years and one launch attempt; we have months and a market that won't wait. Write sloppy when speed matters; set the limit before the hardware sets it for you."

It's a good line. It has the rhythm of a quote you'd frame in the office. The problem is what it leaves out.

The time-to-market mirage

Going from 18 months to 8 is news any board will applaud, and rightly so: getting to market sooner is worth money, sometimes all of it. We won't pretend speed doesn't matter. At Núcleo we work with companies that lose sales every week their system doesn't exist; for them, waiting a year for the perfect version isn't engineering either, it's just another way to fail.

But that celebration blends two different things: shipping fast and shipping sloppy. They're presented as the same thing, and they aren't.

Shipping fast means cutting scope, postponing what isn't essential, and accepting a modest first version. Shipping sloppy is something else: accepting code nobody fully understands, dependencies nobody consciously chose, and resource usage nobody measured, because "the hardware can take it." The first is a product decision. The second is a mortgage signed without reading it.

And that mortgage doesn't show up in the eight-month presentation. It shows up later: in the time it takes a new engineer to understand why something works, in the bug nobody can reproduce, in the refactor that's always "next quarter." Fast-generated code isn't free; it just gets billed in installments, to a different team.

The paradox in Meta's example

The story of the hidden 2 GB is, ironically, the best argument against the post's thesis.

The team proved the product fit in 2 GB. The constraint worked: it forced people to think, to measure, to choose. That isn't sloppiness; it's exactly the discipline the post says we no longer need.

Which raises the obvious question: if the software fits in 2 GB, why does the chip have 4?

There may be good reasons. Headroom for the operating system, for future updates, or simply that memory modules come in standard sizes and 4 GB cost about the same. We don't know the details and we won't make them up. But the principle deserves to be said out loud: when the answer to inefficient code is "add more hardware," that hardware actually gets manufactured. In a consumer product it isn't made once; it's made millions of times. Every gigabyte of headroom that exists to absorb sloppiness is silicon, manufacturing energy, and, in the case of DRAM, continuous power to keep the data refreshed while the device is on.

Multiplied by millions of units, it stops being an engineering detail and becomes an industrial decision.

Software's physical bill

For two decades the industry has run on a comfortable assumption: compute is infinite and cheap. If the code is slow, buy a bigger server. If it uses too much memory, the next phone will have more. And now, with AI, a second assumption joins it: writing code is free too.

Neither is true. The cost just moves to where we can't see it.

Software doesn't live in "the cloud" in some ethereal sense. It lives in data centers that draw power around the clock, that need cooling systems (many of them water-based), and that fill up with equipment someone had to build. That manufacturing has its own cost, what green computing calls embodied carbon: the energy and materials already spent before the hardware processes its first request. For many consumer devices, that manufacturing cost weighs as much as, or more than, all the energy they'll use over their lifetime.

This isn't a moral stance. It's basic thermodynamics: every instruction a processor executes dissipates energy, and every byte a memory holds needs a physical circuit someone built. Inefficient code isn't an aesthetic problem. It's unnecessary physical work, repeated billions of times.

And the uncomfortable part: much of that extra work produces nothing the user notices. A social network today does, in essence, what it did fifteen years ago: show text, images and comments. The experience improved in some ways, no doubt. But not in proportion to the resources it now consumes. The gap between what software does and what it spends keeps growing.

The counterpoint: where the bill hurts, efficiency comes back

It would be unfair to paint the whole industry with the same brush. While sloppy code is being celebrated, there's a movement in the opposite direction, and it comes precisely from the places where inefficiency is paid for in earnest.

The clearest example is in the JavaScript ecosystem itself. For years, the tools to compile, bundle and lint JavaScript were written in JavaScript. That worked, until projects grew large enough that every build took minutes. The answer was to rewrite those tools in compiled languages: esbuild in Go; SWC, Turbopack, Rspack, Biome and Rolldown (Vite's new bundler) in Rust. Python went the same way with Ruff and uv, also in Rust.

The most symbolic case is TypeScript's. In 2025, Microsoft announced it is porting the TypeScript compiler, for a language that exists to make JavaScript better, to Go, and reported builds around ten times faster on large projects. A telling detail: they chose Go not because it's the fastest language possible, but because its structure let them carry the existing code over almost line by line. It wasn't a rewrite for fashion's sake; it was an engineering decision with the lowest possible risk.

In infrastructure the pattern repeats. Discord documented how it moved a critical service from Go to Rust because garbage-collector pauses caused latency spikes that, at their scale, were noticeable. AWS built Firecracker, the micro-VM technology Lambda runs on, in Rust, precisely because every megabyte of memory and every millisecond of startup gets multiplied by millions of executions.

The lesson isn't "rewrite everything in Rust." It's a less comfortable one: efficiency matters again the exact moment someone has to pay the bill. When the provider absorbs the cost (on its servers, in its builds, in its cloud), it optimizes without a second thought. When the cost is spread across millions of users (their battery, their RAM, their next phone), it becomes invisible and sloppiness gets celebrated.

The same engineers who write tools in Rust to save seconds of build time ship apps that consume gigabytes on the user's device. It isn't a lack of knowledge. It's that inefficiency only gets fixed when it hurts whoever makes the decision.

One nuance is worth making here. It's tempting to read all of this as a story of passion versus profit: craftspeople rewriting in Rust for love of the craft against corporations that only chase earnings. It isn't that simple. Many of these tools really were born from the craft of one person or a small team (esbuild started as a single engineer's project), and that care shows. But almost all of them survived and grew because there was an economic incentive behind them. And Meta itself, when the cost lands in its own data centers, optimizes with enormous rigor: it built HHVM to make its PHP servers cheaper to run, Hermes so React Native runs on low-memory phones, and the Zstandard compressor. The difference isn't who loves code more. It's who gets the bill: when it reaches whoever makes the decision, craft becomes good business; when it's spread across millions of users, sloppiness is free for whoever produces it.

Pragmatism isn't the same as laziness

It's worth being fair to Voyager. Its software isn't admirable because its engineers were more virtuous than today's, but because they had no choice. Memory was extremely expensive, the processor was slow, and there was no way to send a technician 20 billion kilometers away. The constraint was physical and absolute.

And still, that constraint produced something worth looking at. In 2024, nearly half a century after launch, a chip in Voyager 1's computer failed and the spacecraft started sending unreadable data. The NASA team had no spare part and no way to touch the hardware. What they did was understand the code well enough to relocate it, piece by piece, to other areas of memory and recover the spacecraft. That's only possible when someone, decades earlier, wrote a system that could be understood.

That's the difference that matters. It isn't about writing everything in assembly or optimizing every cycle. It's about someone, at some point, knowing what the system does and why.

There's nothing wrong with using AI to generate code. We use it every day: for drafts, for tests, for the repetitive work that doesn't need judgment. The tool isn't the problem. The problem starts when the tool becomes an excuse to stop reviewing, measuring and deciding. An agent can generate a thousand lines in a minute; what it can't do is answer for them when they fail on a Friday night.

Pragmatism says: this part doesn't matter that much, let's solve it fast and move on. Laziness says: nothing matters that much, the hardware can take it. The first is judgment. The second is giving it up.

Less fat, more engineering

The Meta post has one half we fully agree with: set the limit before the hardware sets it for you. It's a good principle. Only the right conclusion isn't "write sloppy." It's the opposite: limits exist to make you think, not for you to find ways around them.

At Núcleo we build systems for companies that don't have Meta's budget, and maybe that's why we see it more clearly. For a mid-sized business, every wasted resource shows: a bigger server, one more license, a system nobody dares to touch because nobody understands how it works. There's nobody to pass the bill to. Efficiency isn't an abstract virtue: it's money that stays in the company instead of going to the cloud. That's why, in our case, craft and business point in the same direction.

We believe sober software, the kind that does what it has to, uses what it needs and can be explained, isn't nostalgia for another era. It's economic and product responsibility:

• Measure before you scale. If something is slow, first understand why; then, if needed, buy more hardware.
• Ship fast by cutting scope, not judgment. A small, solid first version is worth more than a big one nobody can maintain.
• Choose the tool for the bottleneck, not the trend. Not everything needs Rust; but when part of a system runs millions of times, that part deserves the right language and design.
• Use AI to accelerate, not to stop thinking. Every piece of code that reaches production has someone who understands it and answers for it.
• Design to last. The system you build today will be maintained by someone five years from now, maybe you, and they should be able to read it.

Voyager has been running for nearly fifty years on less memory than a desktop icon uses today. Not because its engineers had more time, but because they had something that's scarce today: the obligation to know exactly what they were building.

The hardware no longer imposes that obligation on us. Today we have to choose it.

Has your system grown on patches until nobody really knows how it works? Let's talk on WhatsApp →