Last December, Sundar Pichai announced that Google had decided to put data centers in space. Project Suncatcher was the moonshot — Pichai’s word — and the framing was that the sun puts out “100 trillion times more energy than what we produce on all of Earth today,” and Google would like access to that. Two pilot satellites with Planet Labs are scheduled for early 2027. “A more normal way to build data centers” is how Pichai described it, with a horizon of about a decade.

Then a former NASA engineer with a PhD in space electronics, who happened to have spent a decade at Google’s YouTube and Cloud-AI infrastructure, sat down at a blog called taranis.ie, opened with “For clarity: I am a former NASA engineer/scientist with a PhD in space electronics. I also worked at Google for 10 years,” and proceeded to walk through why none of this works. The post — credited to a single byline, Taranis — went to the front page of Hacker News and ran 361 comments deep, then to Lobsters, and game-engineering veteran Christer Ericson endorsed it on X with “data centers in space is a fantasy.”

Here is the math I cannot stop thinking about. The largest solar array ever deployed in space is on the International Space Station. It produces about 200 kilowatts at peak, covers about 2,500 square meters — half a football field — and required several Shuttle missions to install. An NVIDIA H200 draws 700 watts at maximum thermal design power, and Taranis’s rule of thumb of about one kilowatt per GPU once support hardware is counted is conservative. So an ISS-sized solar array, the largest humans have ever flown, can power approximately two hundred GPUs. NVIDIA’s standard 72-GPU rack ships in a DGX configuration that already exists. One ISS in orbit, powered to its peak, runs three of them.

Stargate Norway — OpenAI’s first European AI gigafactory, announced in summer 2025 — targets 100,000 GPUs by the end of 2026. To match that in orbit you would need five hundred ISS-sized solar arrays. The ISS itself took thirteen years and forty-some launches to build.

This is the kind of piece where the rest of the article is the unpacking.

Power

The intuition behind a space data center is that the sun is up there and it is enormous, and so power is, in some loose sense, free. The intuition is wrong in a specific way. Solar panels in orbit are essentially the same panels that cover the roof of any rooftop installation, with the same conversion efficiency, slightly more sunlight (the atmosphere absorbs a few percent), and no night. The advantages are real but they are a couple of multipliers, not a step change. The disadvantage is that the panels have to be deployed in vacuum, which is hard, and held there, which is harder. The four primary ISS solar wings were each delivered on a separate Shuttle mission — STS-97, STS-115, STS-117, STS-119 — between December 2000 and March 2009. That’s nine years to get four solar wings in orbit. The deployment is the easy part of operating them.

The other power option is nuclear, and in orbit that means radioisotope thermoelectric generators, which are the small plutonium-powered heat engines that drove the Voyager and Cassini probes. They produce 50 to 150 watts apiece. As Taranis observes, that is not enough to power one H200, even before you have asked anyone for a sub-critical lump of plutonium-238 and explained what you plan to do with it. The reactors NASA actually flies in orbit aren’t reactors at all. The reactors that would be reactors aren’t ready, and the agencies that would have to license them are unenthusiastic.

So the math is solar, and the math is two hundred GPUs per ISS-sized array, and the marketing slide where the sun is “100 trillion times the energy” of all human civilization is operating on a scale where the energy that matters is not the energy in the sun but the energy you can collect on a panel, beam to a chip, and not boil the chip with.

Thermal regulation

This is the section that broke me on first reading and is, in the long run, the structural argument against the whole project.

There is no air in space, which means there is no convection. On Earth, the way a data center stays alive is that hot air rises off a chip, gets entrained in a heatsink fan, gets dumped into a cold aisle, gets pumped through liquid loops or chilled-water exchangers, and ultimately gets convected into the atmosphere. The atmosphere has been doing the heavy lifting for the entire computing industry for sixty years. The atmosphere is the actual cooling system; everything else is a connector to it.

In orbit there is no atmosphere. There is no medium for the heat to leave through except radiation, which is the same mechanism that makes a hot piece of metal glow. The Stefan-Boltzmann law puts a cap on how much heat per square meter a radiator panel can dump, and the cap is unforgiving.

The ISS has the largest active thermal-control system humans have ever flown, the Active Thermal Control System (ATCS). It uses an ammonia coolant loop and a series of large radiator panels that face away from the sun. The system’s dissipation cap is 16 kilowatts. Sixteen kilowatts is the peak heat budget of the ISS thermal system. That is the equivalent of approximately sixteen H200 GPUs, or roughly one-quarter of an NVIDIA DGX rack. The radiator panels themselves are 13.6 m × 3.12 m, about 42.5 m². To dissipate the full 200 kW from a notional ISS-sized solar array, the same scaling on radiator area lands around 531 square metres of additional radiator panel, on top of the 2,500 m² solar array that’s already there. The satellite is now substantially larger than the ISS, and it is dissipating the heat of three server racks.

There is no engineering shortcut here. Stefan-Boltzmann is a temperature-to-the-fourth-power relationship and the radiator surface temperature is bounded by the temperature at which the chips you’re cooling stay alive. You can play tricks at the margin — heat pipes, two-phase loops, anti-sun-side radiators — but the margins are tens of percent. The marketing pitch “space is cold, so cooling is easy” is the inverse of the truth: space is insulating, and the only way to lose heat is to radiate it, and your radiator is what bounds the size of the satellite.

Radiation

The third reason this doesn’t work is that the chips you would put in orbit don’t survive in orbit.

GPUs and TPUs and the high-bandwidth memory they depend on are the worst-case silicon for radiation tolerance. The transistors are small, which means a single charged particle passing through one is a larger fraction of the gate’s relevant area, which means a single hit is more likely to flip a bit (a single-event upset) or, worse, to cause a single-event latch-up where a transistor turns itself on, draws current it shouldn’t, and burns the chip out. The die area is also enormous, which means more hits per second per chip. And the cumulative dose effect over months — transistors switching slower, drawing more power, eventually crossing into nonfunctional — is exactly the failure mode you don’t want at scale, because you can’t service it.

Chips actually designed for space use a different gate topology and much larger geometry — typically the BAE RAD750, based on a PowerPC architecture from the late 1990s, or its successors. Per Taranis’s framing, the typical processor on an actually-flying spacecraft has compute roughly equivalent to a 2005-era PowerPC. The relationship is not negotiable: radiation hardness comes from larger transistor geometry; performance comes from smaller. Pick one.

You could ship the H200s anyway — Taranis calls this the “YOLO approach” — and that’s how cubesats often work, which is also why cubesats often fail within weeks. Shielding helps a little, except past a thin layer it makes the problem worse: a cosmic ray hitting a sufficient mass of shielding produces a shower of secondary particles, and now you have many hits where you used to have one. Mass is always at a premium on a satellite. The result is that for a long-duration orbital data center — which it has to be, because at $5,000 per kilogram of launch mass, it isn’t economic for anything short — you can’t ship the GPUs you actually want, and the chips you can ship aren’t the ones the customer is paying for.

Google’s own Project Suncatcher paper acknowledges this and reports that Google ran TPUs in a particle accelerator and they survived for a simulated five years. This is a real result and it is not the same thing as the chips being the chips you would ship to a customer. The accelerator simulates dose; it doesn’t simulate every failure mode at sufficient fidelity, and the chip you put in space still has to be one that exists, which means it’s a TPU one or two generations old by the time it flies, and it’s competing in the AI-compute market against a TPU running on the ground that is being upgraded twice a year.

Communication

The smaller of the four problems, but worth saying. A typical orbital satellite communicates with the ground at single-digit gigabits per second on radio. Optical inter-satellite links are improving but they require atmospheric clarity to reach the ground, and a single rack of GPUs in a terrestrial data center can saturate hundred-gigabit interconnect to its neighbors as a floor. The space data center, until somebody builds the orbital optical mesh that doesn’t exist, has the I/O of a rack from 2010 with the compute of three.

The marketing-physics gap

Project Suncatcher’s own paper gets to the punchline by halfway through. “Launch costs could drop below $200 per kilogram by the mid-2030s.” SpaceX’s Falcon 9 is currently around $2,720 per kilogram to LEO; Starship’s projected mature cost — if Starship works at full reusable cadence, which it currently does not — is in the $200–500 range. Google’s paper is asking the reader to assume that Starship works, at scale, with the cost curve fully realized, in eight to ten years, and then the math becomes plausible.

The math also doesn’t actually become plausible. At $200/kg, the launch costs of a 200 kW solar array (a large structure of conservative-but-substantial mass) plus the corresponding 531 m² radiator plus the rad-hard or non-rad-hard compute payload plus the maneuvering and station-keeping plus the redundancy still produces three racks of orbital compute for tens of millions of dollars in launch costs alone, before the spacecraft bus or the deployment operations. You can build the equivalent terrestrial data center, including the grid hookup and the power-purchase agreement and the cooling tower, for less than that.

The honest version of the case for space data centers is that the grid is the binding constraint, not the silicon, and the AI industry has lost so much social license over the past two years on water consumption, farmland conversion, and electricity-rate impacts that putting the next 100,000 GPUs into someone else’s atmosphere is starting to look like the path of least resistance. That’s not engineering. That’s the marketing department’s response to the political problem the engineers gave them.

Why the marketing keeps coming back

The reason a fundamentally non-functional idea keeps showing up at scale is that the AI industry, in 2026, has a supply story it cannot tell honestly. Demand for AI compute is growing faster than grid hookups can be brought online. Hyperscaler PR, investor decks, and ESG reports all need a future answer to the question of how this gets built; “we’ll figure out the grid eventually” doesn’t fit on a slide. “Datacenters in space” does. The fact that the slide is in the deck is itself doing work — it absorbs the question for the duration of the meeting and lets the actual capacity expansion plan, which involves a lot of natural-gas peaker plants and disputed grid interconnects, proceed unexamined.

The other thing the slide does is launder. The single hardest political problem the AI industry has right now is that its capacity expansion is locally visible: the gas plants are in someone’s town, the data center is drinking someone’s aquifer, the rate hike is on someone’s bill. A satellite is in nobody’s town. A satellite, in the marketing imagination, runs on solar and harms no one. The fact that the satellite would have to be the size of the ISS, and would deliver three racks of compute, and would do so at a unit cost incompatible with the AI industry’s actual capex curve, is information that doesn’t survive the trip from the engineering team to the keynote.

There is one argument I find honestly worth taking seriously: the orbital infrastructure has to start somewhere, Project Suncatcher’s two pilot satellites are an order of magnitude cheaper than nothing, and the long-run learning curve on rad-hard compute and orbital deployment might justify the spend even if the short-run economics don’t close. This is a real argument and it is the one Google’s paper actually makes when you read past the marketing layer. It is also a different argument from “this is how we’ll meet AI compute demand,” and the gap between the two is the gap that Pichai’s keynote invites the audience not to notice.

What stays on the ground

Engineering arguments dressed in physics don’t shift with political winds. Stefan-Boltzmann doesn’t care that 2026 is a hard year for hyperscaler PR. The radiator-size problem will be the same in 2030 as it is now. The radiation-tolerance problem will be the same. The launch-cost problem might come down to within an order of magnitude of viable, and the bet on Starship reaching its target cost by the mid-2030s is the same kind of bet all the other 2010s reusable-rocket projections were — except this one lives in the appendix of a Google research paper instead of the keynote.

Three racks of orbital compute, on a structure the size of the ISS, riding on a launch cost that is almost certainly twice what the marketing assumes, in a chip generation that is one or two cycles behind the ground, with a thermal envelope that constrains everything else — that is the thing the slide is about. The slide is about the slide. The slide is in the deck because the deck needed something. The slide will be in the next deck for the same reason.

Meanwhile the next 100,000 GPUs that OpenAI is bringing online for the next training cycle are getting installed in northern Norway by its joint venture with Nscale and Aker, drawing 230 megawatts of renewable power, and cooled by a closed-loop direct-to-chip liquid loop. The data center stays on the ground because it has to. The space data center stays in the slide because it can.

The lie of the 80%: why software progress charts don’t work

Picture the ideal burndown chart. A clean diagonal line, descending steadily from “all the points” down to zero by the end of the sprint. Beautiful. Reassuring. Shareable in a stakeholder meeting.

Now picture an actual sprint you’ve lived through. Did the line ever look like that?

I’m going to guess: no. And not because your team was bad. Not because you’re undisciplined. Not because the estimates were off. The reason no real burndown ever matches the ideal one is more fundamental: software isn’t built like that.

Charts of progress assume a model of how software gets made that doesn’t reflect reality. And once you see it, you can’t unsee it.

Software isn’t a brick wall

The mental model behind every progress chart — burndown, burnup, Gantt, percent-complete, you name it — is the same: development is a stack of bricks. You add one brick at a time. The wall gets taller. Eventually, it reaches the height you wanted, and you’re done.

This metaphor is comforting and almost entirely wrong.

Real software development looks more like this: you build half a wall. You realize the foundation is in the wrong place. You tear the wall down. You build a different wall. You realize the room is in the wrong place. You spend three days reading and thinking and not laying any bricks at all. Then on day four, you build the entire wall in six hours because you finally understood the problem.

This isn’t a failure mode. This is what software development is. Exploration, dead ends, tear-downs, breakthroughs. The progress is non-linear because the work is non-linear. Any chart that assumes a smooth descent from “not done” to “done” is lying about the shape of the work itself.

The 80% lie

Here’s the most universally-told lie in software:

“It’s basically done. Just need to finish that last 20%.”

Every developer has said this. Every developer has heard this. And every developer has been on the receiving end of that 20% turning out to be 80% of the actual work.

It’s not that we’re all liars. It’s that the way development actually unfolds — exploration phase, implementation phase, polish phase — doesn’t map cleanly onto percentages. When you say “I’m 80% done”, what you usually mean is “I’ve done a lot, and I have a vague sense that the remaining stuff is smaller than the stuff I did”. That’s not a measurement. That’s a feeling.

The “remaining 20%” often contains:

• The integration with the system you haven’t talked to yet
• The edge case that surfaces only when you wire it up end-to-end
• The performance problem that shows up only at production scale
• The thing the PM forgot to mention until you demoed

None of these are visible from where you stand at the supposed 80% mark. They’re not in the chart. They can’t be in the chart. They haven’t been discovered yet.

Every metric is biased by who produces it

Here’s a quieter problem with progress charts: the person reporting the metric always has a stake in what the metric says.

If you want to look productive, you inflate. If you want to avoid getting more work assigned to you, you deflate. If you’re protecting a teammate, you smooth. If you’re frustrated with management, you let the truth show through harder than it should.

This isn’t dishonesty. It’s people responding rationally to incentives. The metric isn’t a mirror — it’s a message. Once you understand that progress charts are a form of communication, not measurement, you stop expecting them to reflect reality. They reflect the politics of the team’s relationship with whoever’s reading the chart.

The fix isn’t “be more honest”. The fix is recognizing that any metric whose value depends on the reporter’s interpretation will be shaped by the reporter’s incentives. Always. Every time.

The fallacy of uniform effort

Charts also assume that everyone on the team is contributing in roughly the same way at roughly the same time. Sprint velocity. Points completed per developer. Burndown lines that smoothly descend.

Real teams don’t work like that. Real teams have weeks where the frontend dev ships forty CMS templates because the work happened to be parallelizable, while the backend dev appears to be drinking mate and playing ping pong for two weeks. And then the next sprint flips: the backend ships a complex migration that took weeks to design, while the frontend dev waits, tests, and unblocks.

That’s not dysfunction. That’s how interdependent work looks.

If your chart shows uneven contribution and your interpretation is “the backend dev didn’t pull their weight”, your chart has lied to you. Maybe the backend dev was the reason the frontend could ship forty templates without blockers. Maybe they were doing the design work that makes next sprint possible. Maybe they were unblocking three other teams off-camera.

Charts can’t see any of that. They show throughput per person and call it productivity. It isn’t.

So who do these charts actually serve?

Once you’ve internalized all of the above, the question becomes hard to avoid: if these charts don’t reflect the work, don’t predict the future, and don’t measure productivity — why do we still draw them?

The honest answer: because somebody with money needs to see them.

Stakeholders need a deliverable. Steering committees need slides. Procurement needs evidence the contract is being honored. Investors want a sense that the burn is producing output. None of these audiences are going to read the codebase. None of them are going to sit in your standup. They need a representation, and the chart is what we hand them.

That’s fine. That’s the corporate game, and pretending it can be opted out of is naive. But let’s stop pretending the chart is a tool for the team. It isn’t. It’s a tool for the people the team has to report to. Calling it “project management” obscures what it actually is: status theater, dressed in the language of measurement.

The team doesn’t need the chart to know how the project is going. The team knows. They’re the ones doing it.

What actually works

If charts are theater, what’s the alternative? Three things, in this order:

1. Demos over charts. The only honest measurement of progress is working software. Last week the product looked like this. This week it looks like this. Did it move? Did it move in the right direction? That’s the question, and no chart in the world answers it as well as a five-minute demo. If you can’t show anything that works, you’re not progressing — no matter what the burndown says.

2. Narrative over numbers. Replace “we’re 73% done” with “we explored approach A, it didn’t pan out, we’re now on approach B and we expect to know if it works by Thursday”. This is harder than producing a chart, because it requires the reporter to actually understand the work. That’s a feature, not a bug. The narrative forces honest engagement; the chart allows comfortable distance.

3. Output metrics as complement, not substitute. What did the user actually receive? Deploys to production. Features released. Bugs closed in the wild. These can be counted because they’re real events with real artifacts. The user doesn’t lie. The git log doesn’t lie. Process metrics — story points completed, sprint percentage, velocity trends — measure the appearance of work. Output metrics measure work that left the building.

And if a stakeholder genuinely needs a number — sometimes they do, and that’s fair — give them one. Just be honest about what it is. “Let’s invent a number over a beer” is a more accurate framing than “based on our velocity-weighted forecast of remaining story points”. They’re often the same number. The first one tells the truth about its origins.

The elephant: but the stakeholders want the chart

I’m not naive. I know that in many companies, you can’t just stop producing burndowns. The contract requires it. The PMO requires it. The CFO has a slide template with that chart shape on it and changing the slide is harder than changing the moon.

So produce the chart. Hand it over. Smile at the meeting.

But internally, don’t let the team start believing the chart. That’s where the real damage happens — when developers start optimizing for the line on the screen instead of for the product. When the chart becomes the goal, the chart will start telling you the team is doing great while the codebase is rotting in ways no chart can show.

The worst version of this is the team building its own charts. When developers start producing the very theater that’s being used to manage them, the gap between “what we say is happening” and “what is happening” stops being a stakeholder problem and starts being an internal one. That’s how you end up with teams that look productive on paper and ship nothing of value for two quarters.

The bottom line

A chart never built a product.

The people who build great software don’t do it by staring at burndowns. They do it by talking to their teammates, watching the product grow, adjusting direction when something isn’t working, and being honest with each other about what they don’t yet understand. The chart is, at best, a translation layer between that work and the people who fund it.

Translation layers aren’t bad. But they aren’t the work, and they aren’t where the work happens.

If you’re a manager: the chart is for your audience, not your team. Don’t manage by it.

If you’re a developer: the chart is theater. Produce it if you have to, but don’t let it shape how you actually think about the project.

And if you’re at a company where the chart is the project — where decisions are made off the line on the screen and the actual code is invisible to everyone above the team lead — that’s not a measurement problem. That’s a much deeper one, and no better chart will fix it.

If your team genuinely needs a burndown chart to know how the project is going, the problem isn’t the chart. It’s that nobody is actually talking about the project.

What does your team use to track progress? Charts you trust, charts you tolerate, or something else entirely? I’d love to hear it in the comments.

İddialara göre Çin, yakında Ay’a insanlı iniş görevini tüm detaylarıyla açıklamayı planlıyor.

ABD’deki Apple ve Samsung müşterilerinin hangi markadan daha memnun olduğunu gösteren bir araştırma yapıldı.

Sahibinden, Nisan 2026’ya dair otomobil satış verilerini paylaştı.

Ford Avrupa Başkanı, verdiği bir röportajda Ford Fiesta’nın geri dönüşüne yeşil ışık yaktı.

CapCut, Gemini ile yeteneklerini birleştirecek iş birliğini duyurdu.

Togg, Trumore ve Trugo uygulamaları üzerinden kullanıcılarına özel bayram hediyesi şarj bakiyesi tanımlayacağını açıkladı.