DEV Community: Next Horizon

How Would You Build Software for Mars?

Next Horizon — Thu, 08 Oct 2026 10:14:59 +0000

How Would You Build Software for Mars?

Latency, offline-first systems, edge AI, fault tolerance — and why “just call the API” stops working 225 million kilometers from home
Imagine deploying a production system where the nearest senior engineer is millions of kilometers away, a network round trip can take tens of minutes, connectivity disappears without warning, replacement hardware may take years to arrive, and a bad update can threaten lives.
That sounds less like web development than a very bad day in production. It is also a pretty good description of software on Mars.
Most discussions about sending humans to Mars focus on rockets, habitats, radiation, food, or whether we can get there at all. Those are real problems. But a permanent outpost would also be a software system on a planetary scale: life support, power, communications, navigation, robotics, medicine, resource extraction, science instruments, logistics, and probably a large amount of AI would all depend on code.
Mars has a habit of breaking assumptions we rarely notice on Earth.

Rule #1: Earth is not your backend

On Earth, even distributed systems usually assume that another machine, data center, engineer, or cloud region is reachable within milliseconds or seconds. Mars does not offer that luxury.
Depending on where Earth and Mars are in their orbits, the communication delay changes constantly. NASA notes that Mars missions can face up to roughly 44 minutes of round-trip latency at maximum distance. That makes real-time remote control impossible for many tasks. NASA's communication-delay research frames this as a fundamental change in how future missions must operate: crews cannot depend on the real-time ground-support model used for most human spaceflight so far.
From a software perspective, that single fact changes almost everything.
A Mars base cannot behave like a thin client connected to Earth. Critical systems have to work locally. Authentication, control logic, diagnostics, maps, medical knowledge, maintenance procedures, AI inference, and operational data all need useful local versions. Earth becomes an asynchronous partner, not a synchronous dependency.
The human side of that delay matters too. Getting people to Mars is already a long and difficult systems problem; I looked at the mission timelines and constraints in How Soon Will We Fly to Mars?. Once a crew arrives, the same distance that made the journey hard also determines how their software must behave.

Offline-first stops being optional

On Earth, “offline-first” is often a UX improvement. On Mars, it is architecture.
A habitat should still be able to operate if the Earth link disappears for hours, days, or longer. A rover should finish a safe sequence without waiting for an HTTP response. A medical system should keep its local records. A maintenance application should retain procedures and schematics. A scientific instrument should queue data rather than fail because the uplink is unavailable.
This is very close to a problem distributed-systems engineers already know: communication is not guaranteed, messages may arrive late, nodes may disappear, and eventual delivery is often more realistic than immediate consistency.
NASA's Delay/Disruption Tolerant Networking, or DTN, is built around exactly that idea. Instead of assuming a continuous end-to-end path, DTN uses a store-and-forward model: a node can hold data until the next communication opportunity becomes available. NASA now describes DTN as a foundational technology for a future Solar System Internet, and in 2026 it became an operational service in both the Near Space Network and Deep Space Network. NASA's DTN overview is surprisingly familiar reading if you have ever designed resilient message queues.
The useful design rule is almost mundane: a disconnect is not the exception. Connectivity is.

What does an API look like with a 20-minute timeout?

A lot of terrestrial software still thinks in a simple rhythm: send request, wait, receive response, continue.
On Mars, that pattern becomes dangerous if the remote dependency is on Earth.
You would want commands to be idempotent whenever possible. Messages need durable identifiers. Systems need to tolerate duplication, reordering, partial delivery, and very late acknowledgements. Operations should be represented as state transitions rather than assumptions that a remote call succeeded because the client did not crash.
A command might effectively mean: “perform this operation when conditions A, B, and C are true, unless command X has already superseded it.” That is closer to a durable workflow engine than a normal REST request.
None of this is alien engineering. Banking systems, aircraft, industrial automation, edge devices, and distributed platforms already use many of the same ideas. Mars simply removes our ability to get away with ignoring them.

The edge becomes the main computer

Cloud computing trained us to move intelligence away from the device. Mars pushes hard in the opposite direction.
Anything that needs a fast decision has to run locally: obstacle avoidance, life-support control, electrical fault isolation, habitat robotics, inventory tracking, medical triage, and probably much of the crew's everyday AI assistance.
On Mars, edge computing is not a performance trick. It is part of the survival stack.
NASA and JPL are already moving in this direction. JPL's Rover Operations Center explicitly lists onboard autonomy and AI, digital twins, mission-adapted AI models, and edge-AI autonomy among the technologies it is developing for future planetary surface missions. In December 2025, Perseverance also completed drives whose routes were planned using a vision-capable generative AI system, demonstrating another step toward software that can make useful decisions without waiting for a human planner on Earth. JPL's report on the AI-planned Perseverance drive is a good example of why autonomy becomes more valuable as distance grows.

“Put AI everywhere” is not a strategy

The obvious response to latency is: make everything autonomous. That would create a new class of problems.
Generative models are probabilistic. Safety-critical control systems usually need predictable behavior, bounded failure states, formal constraints, and extensive validation. The likely architecture is therefore hybrid: deterministic control for critical loops, machine learning for perception and prediction, and more flexible AI for planning, diagnostics, search, and human interaction.
An AI might suggest that a pump is failing because vibration and temperature patterns resemble previous faults. It should not necessarily be allowed to invent a new pump-control strategy and deploy it without constraints.
This is where AI-agent enthusiasm runs into aerospace engineering. Autonomy is necessary; unbounded autonomy is not.

Graceful degradation matters more than perfect uptime

On Earth, high availability often means duplicating infrastructure. If one server dies, another takes over. A Mars settlement will do that too, but redundancy has a physical cost: every spare computer, cable, sensor, battery, and actuator has mass. Mass has to be launched, transported, landed, powered, cooled, and maintained.
So the software needs to know how to become less capable without becoming unsafe.
Imagine a greenhouse system losing half its environmental sensors. The correct response may not be “service unavailable.” It may switch to a conservative control mode, reduce automation, ask the crew for manual measurements, and increase local logging until repairs are possible.
The same idea applies to navigation, communications, power management, and life support. A Martian system should have multiple operating envelopes: optimal, degraded, emergency, and manual.
That is different from designing only for uptime. The real goal is continued usefulness under damage.

The humans are part of the system too

A habitat is not just a machine. It is a machine wrapped around people whose bodies are already operating outside the environment they evolved for.
Mars has about 38 percent of Earth's surface gravity. Crews will also face radiation exposure, isolation, altered sleep patterns, and the physiological consequences of months in microgravity before they even land. I explored those constraints in How the Human Body Will Change on Mars: Bones, Muscles, DNA and Life in 0.38 g.
That makes human monitoring part of the software stack. Wearables, environmental sensors, medical records, exercise systems, radiation dosimetry, sleep tracking, and decision-support software may all feed into one operational picture.
But this also creates a serious design question: how much should the habitat know about its residents? A system that continuously monitors cardiovascular data, stress markers, movement, work performance, sleep, and medical history could be incredibly useful in an emergency—and uncomfortably close to total surveillance.
Mars will not eliminate privacy engineering. It may make it harder.

A software update becomes a mission event

On Earth, “we'll patch it later” is practically a development methodology. On Mars, that attitude would get expensive fast. Critical updates would need a level of caution closer to aviation or medical software.
A bad deployment might be recoverable remotely, but not quickly. The system therefore needs signed updates, staged rollout, rollback images, health checks, strong versioning, reproducible builds, and the ability to keep running the previous version indefinitely if the new one behaves badly.
For AI models, this becomes even more interesting. A new model may be better on average but worse on a narrow class of mission-critical tasks. Updating the model is not simply replacing a binary; it may require a local evaluation suite representing the actual habitat, tools, procedures, vocabulary, and failure modes.
CI/CD still exists. The “D” just becomes a lot more intimidating.

Digital twins beat dashboards when Earth is far away

If engineers on Earth cannot interact with the habitat in real time, they need something better than a stream of logs.
A high-fidelity digital twin—a software model of the habitat, rover, power system, or industrial process—could let Earth teams replay events, test proposed fixes, predict resource consumption, and send back validated procedures. The Mars crew could use the same model locally before making risky changes.
The key is synchronization. The twin will always be delayed relative to reality on Mars, so the software has to know which state is authoritative and when.
To a distributed-systems engineer, the problem is familiar: two views of the same system, separated by latency, trying not to disagree in a dangerous way.

Observability matters more when nobody can come fix the box

A good Martian system should be explainable after failure.
That means rich telemetry, event histories, checksums, hardware health data, resource usage, and enough contextual information to reconstruct what happened. But bandwidth is limited, so you cannot simply ship every log line to Earth forever.
The software will need local aggregation and prioritization: keep raw high-resolution data for a limited period, extract anomalies, compress routine telemetry, and send the most important information first.
It is observability under a brutal data budget.
And because Earth may not see the problem until many minutes after it starts, local anomaly detection becomes much more valuable than a beautiful dashboard in mission control.

Mars makes software longevity impossible to ignore

A web application is often rebuilt every few years. A Mars habitat could contain systems expected to survive for decades.
That raises boring questions that suddenly become fascinating: Can you still build the software when the original package repository no longer exists? Can a replacement computer run a twenty-year-old control application? Is the configuration documented somewhere other than one engineer's laptop? Do you have the source code for every dependency that matters? Can the crew recover if the vendor has disappeared?
Long-lived Martian software would benefit from conservative formats, minimal dependencies, reproducible environments, extensive documentation, emulation layers, and a serious archive of source code and tooling.
The glamorous part of Mars computing may be AI. The thing keeping the settlement alive in 2058 may be a boring, well-documented protocol someone wisely refused to replace in 2037.

Eventually, software becomes part of the settlement

The first Mars missions will probably use software mainly to keep crews alive and make exploration efficient. A larger settlement changes the scale.
Local manufacturing, water extraction, agriculture, power grids, construction robots, transportation, scientific networks, and resource allocation would all need coordination. In that world, software stops being a support layer and starts behaving like planetary infrastructure.
That is also where the question of long-term planetary engineering appears. Terraforming Mars, if it is ever physically and economically possible, would be an undertaking measured in centuries rather than software release cycles. I examined those constraints separately in Terraforming Mars: Can We Really Turn the Red Planet Into a Habitable World?. Long before anyone changes the atmosphere of Mars, however, software will already be coordinating the much smaller artificial environments humans depend on.
A Mars base is, in a sense, a tiny synthetic planet. Every breathable cubic meter, watt of power, liter of water, and kilogram of food exists because a collection of engineered systems keeps it available. Code sits between many of them.

Mars is just an extreme version of problems we already have

The interesting thing about Martian software is how little of it is actually alien.
Offline-first architecture already exists. Edge computing exists. Event queues, digital twins, formal verification, local inference, degraded modes, reproducible builds, observability, and distributed consensus all exist.
Mars simply changes the cost of getting them wrong.
On Earth, a flaky network is annoying. On Mars, the network is always far away. On Earth, a failed deployment may wake the on-call engineer. On Mars, that engineer may be 20 light-minutes away. On Earth, replacing hardware is logistics. On Mars, it may be next year's launch window.
That is why designing software for Mars is a useful thought experiment even if you never work in aerospace. It strips away assumptions that ordinary systems let us ignore.
What if the network is not reliable? What if the cloud is unavailable? What if the user cannot call support? What if your system has to survive years of partial failure? What if the correct answer is not maximum automation, but carefully bounded autonomy?
Those sound like Martian questions. Most of them are really just engineering questions with the safety margin removed.

The real Martian programming language might be restraint

The first developers whose code runs inside a crewed Mars settlement probably will not be writing science-fiction software. They will be writing systems that fail predictably, recover locally, explain what happened, and keep working when half the assumptions of normal computing disappear.
The cleverest architecture may be the one that does less, but does it reliably.
Mars does not need software that feels futuristic.
It needs software you can trust when Earth cannot answer.

What AI Actually Does When It Answers You

Next Horizon — Tue, 06 Oct 2026 13:00:50 +0000

You ask an AI assistant a question. A second later, a polished answer appears.
It feels simple: you asked, the machine understood, it thought for a moment, and then it replied.
That is a useful interface. It is not a very good description of what happened.
Behind the chat box, your sentence was split into tokens, converted into numbers, transformed through many layers of a neural network, compared against patterns learned during training, and used to generate the next piece of text. If the product has tools, the system may also have searched the web, opened a file, run code, queried a database, or checked an intermediate result before you saw anything.
The answer on screen is the last step of the process, not the process itself. And once you understand that distinction, a lot of strange AI behavior starts to make sense.

First, your sentence stops being a sentence

Suppose you ask: “Why does a metal spoon feel colder than a wooden one?”
You see words. The model sees tokens. A token may be a whole word, part of a word, punctuation, or another frequently occurring text fragment. Those tokens are mapped to numerical representations the network can process.
This is the first useful mental shift. A language model is not looking at text the way you are. It is operating on mathematics that represents relationships between pieces of language.
If you want the broader picture of where language models fit among machine learning, neural networks, multimodal systems, and agents, this overview of modern artificial intelligence goes one level wider. For this article, we can stay inside the language-model pipeline.

The model does not keep a little dictionary in its head

There is no single file inside the model containing the definition of “metal,” another for “spoon,” and another for “thermal conductivity.”
During training, the network is exposed to huge amounts of text and learns patterns between words, concepts, structures, and contexts. Those patterns become distributed across its parameters. When you ask about the spoon, the model is not simply fetching a stored paragraph. It is reconstructing a response from learned relationships among concepts such as materials, heat transfer, temperature, touch, and explanation.
That distinction matters. It helps explain both the flexibility of language models and their unreliability. They can combine ideas in new ways because knowledge is not stored like rows in a database. But the same system can also produce a plausible combination that happens to be false.

Attention is how the model keeps track of what matters

Modern language models are based on the Transformer architecture, introduced in the 2017 paper Attention Is All You Need. The important word is attention.
Attention lets the network weigh relationships between different parts of the current context. A pronoun may need to connect to a name several words earlier. A variable in a function may depend on code written twenty lines above. A constraint you gave at the start of a prompt may need to shape the last paragraph of the answer.
The model repeatedly updates its internal representation so that relevant parts of the context can influence one another. It is not “remembering” your sentence in the human sense; it is continuously recomputing relationships inside the context it has been given.

Then comes the deceptively simple part: predict what comes next

At the core of a generative language model is next-token prediction. Given the context so far, the model produces probabilities for possible next tokens. One is selected, added to the context, and the process repeats.
That is why “autocomplete on steroids” is both a fair description and a terrible mental model.
The mechanism really is prediction. But good prediction at this scale can require the model to represent grammar, code structure, facts, style, logical relationships, user intent, and the shape of an argument. The interesting question is not whether it predicts. It is how much structure had to be learned for prediction to work this well.
A useful way to think about it is this: the model is not choosing an entire finished answer and then typing it out. It is building the answer step by step while continuously conditioning on everything that has already been generated.

Why does that look so much like understanding?

Because many tasks we associate with understanding can be performed through sufficiently rich internal representations.
To translate a paragraph, repair a function, explain a metaphor, or compare two competing ideas, the model has to preserve relationships across the input and produce an output consistent with them. From the outside, that can look remarkably close to comprehension.
But behavior and subjective experience are different questions. A system can display reasoning-like behavior without that being evidence that it has a human-style inner monologue or consciousness. I go deeper into that distinction in How Large Language Models Think: Inside the AI Black Box.
For everyday use, you do not need to settle the philosophy. You only need to remember that fluent output is evidence of capability—not proof that the model understands something exactly the way you do.

The chatbot you use is bigger than the language model

This is one of the most important points people miss. ChatGPT, Claude, Gemini, Copilot, and similar products are not just naked language models with a chat window attached.
A modern assistant may combine a base model with system instructions, conversation history, safety rules, memory, retrieval, web search, code execution, file access, image understanding, external APIs, and other tools. The exact mix depends on the product and the task.
That is why two assistants built around similarly capable models can behave very differently. The surrounding system—what context the model receives, what tools it can call, and how its output is checked—can matter enormously.
For a closer look at that full stack, from pretraining and instruction tuning to the conversational product layer, see How ChatGPT Actually Works.

Pretraining gives it language. Post-training gives it manners.

A pretrained model is not automatically a useful assistant. Its basic job during training is to learn statistical structure by predicting text. That can produce impressive capabilities, but it does not guarantee that the model will follow an instruction, answer directly, admit uncertainty, or avoid unhelpful behavior.
Post-training is where researchers shape those capabilities into assistant behavior. Instruction tuning gives the model examples of good responses. Preference-based methods push it toward outputs people rate as more useful, clear, or safe.
The classic InstructGPT work made this point vividly: human evaluators often preferred outputs from a much smaller instruction-tuned model over those from the far larger base GPT-3 model on the evaluated prompts. The paper and project summary are a useful reminder that raw scale and useful behavior are not the same thing.
The techniques have evolved since then, but the principle has not: the model that can generate language and the assistant you enjoy talking to are not quite the same object.

Search is not memory

Another common misunderstanding appears when an assistant uses the web.
A model’s parameters are not a live search index. They contain learned statistical structure from training. If the assistant has retrieval or browsing tools, the surrounding system can fetch current information and place relevant material into the model’s context before the model answers.
That is the basic idea behind retrieval-augmented generation, or RAG. It is useful for current events, company documents, private knowledge bases, and any information that changes faster than a model can be retrained.
It also gives you a simple way to think about “knowledge” versus “lookup.” A model may have learned how elections work during training, but it still needs current data to tell you who won yesterday. It may understand Python very well, but it still needs access to your repository to tell you why your build is failing.
And retrieval does not magically eliminate mistakes. The model can fetch the wrong source, misread the right one, or attach a citation to a claim the source does not actually support.

What changes when the model is allowed to reason longer?

Some newer systems spend more computation on difficult problems before returning an answer. They may break a task into parts, compare candidate solutions, use tools, check intermediate results, or perform other internal computations that are not directly visible in the final response.
This is meaningfully different from the old caricature of a chatbot instantly guessing the next word with no larger structure.
Interpretability research is beginning to reveal some of that structure. In 2025, Anthropic published circuit-tracing work that found evidence of reusable internal features and planning-like computations in some tasks, while also stressing how partial our view of these systems still is. Their write-up on tracing model computation is worth reading if you want to see how researchers are trying to open the black box.
The important takeaway is modest: language models are doing richer internal computation than “randomly choosing the next word,” but we still cannot look at every answer and cleanly reconstruct a complete human-readable chain of mechanism inside the network.

Give the model tools and it starts to look like an agent

Text generation becomes much more powerful when the model can act.
Instead of only writing a response, it can choose to search, run Python, inspect a document, query a database, call an API, or interact with software. Then it can inspect the result and decide what to do next.
The loop is roughly: observe → choose an action → use a tool → inspect the result → continue.
That is the basic idea behind agentic AI. The capability no longer comes only from the model. It comes from the combination of model, instructions, context, tools, memory, permissions, and the control loop around them.
This is also where reliability becomes much more serious. A wrong sentence is inconvenient. A wrong action can modify a file, send a message, or break a workflow. The more autonomy we give AI systems, the more important verification and permission boundaries become.

And this is why hallucinations happen

The same mechanism that makes a language model flexible also creates its most famous failure mode.
The model is optimized to produce a continuation that fits the context. It does not have a built-in meter that lights up whenever a sentence corresponds to reality. If the learned patterns strongly support a plausible answer but the factual basis is weak, the output may still sound completely confident.
That is a hallucination: not a lie in the human psychological sense, but an answer that is linguistically convincing without being sufficiently grounded.
Search, retrieval, better post-training, tool use, and verification can reduce the problem. None of them turns fluency into evidence. For code, research claims, medical information, security work, financial decisions, or anything else where mistakes are expensive, the result still needs to be checked.

The mental model I actually use

When an AI answers me, I do not imagine a digital person thinking behind the screen. I also do not imagine a database returning a paragraph.
I think of a layered prediction system with optional tools:
• My input is tokenized and converted into numerical representations.
• The network transforms those representations and tracks relationships across the context.
• It generates the response incrementally by predicting what should come next.
• Post-training shapes how it follows instructions and interacts with people.
• The application may add search, files, memory, code execution, or other tools.
• More capable systems can spend additional computation checking or developing a solution.
• I see the final answer; most of the machinery remains invisible.
That mental model is useful because it tells you both where AI is strong and where to be cautious. It is excellent at generating, transforming, connecting, summarizing, and iterating over information. It becomes risky when a fluent answer is treated as proof that the underlying claim is true.

The strange part is not that it predicts

Calling a language model “just statistics” is a little like calling a jet engine “just combustion.” The statement is not exactly wrong. It simply skips the part we actually want to understand.
Modern AI systems generate text through prediction. But prediction, scaled up and combined with learned representations, attention, post-training, retrieval, reasoning methods, and tools, now produces systems that can write software, explain science, interpret images, search documents, plan workflows, and operate other software.
Understanding the mechanism does not make that less interesting. It makes the right questions clearer.
Where do these capabilities come from inside the network? Which of them scale reliably? Which failures can be engineered away, and which are consequences of the basic architecture? And as models gain more tools and autonomy, how much should we trust them to do before a human checks the work?
Those questions are much more useful than asking whether there is a tiny mind hiding behind the chat box.
—
Next Horizon explores artificial intelligence, science, space, and emerging technologies in clear, accessible language.