Cockroaches everywhere: starlink revenue won't be enough to fund constellation sustainment. Refurbishment costs for Falcon 9 make the reusability economics dubious. And xAI is just a disaster. So is Twitter.
9000 satellites that last less than five years, and no path from EBITDA to a GAAP profit. Never mind the crazy space data centers, even the supposedly profitable part won't be.
They'll try. But they are between two forces squeezing the TAM:
The anvil: satellites can't serve most people in a densely populated area, whereas terrestrial wireless can be engineered and deployed to serve any population density, even tens of thousands of people in a stadium.
The hammer: electronics get cheaper faster when they don't have to be space grade, and electronics get cheaper faster than rockets. As they get cheaper, terrestrial wireless will be deployed in more areas that are uneconomical right now.
> The anvil: satellites can't serve most people in a densely populated area, whereas terrestrial wireless can be engineered and deployed to serve any population density, even tens of thousands of people in a stadium.
That's if everyone is trying to connect to the satellite. Would it be possible to have regional hubs that connect and distribute the connection via a local wireless link like 5G?
You don't need to be close to having everyone connect to cause congestion on a satellite network. That congestion is caused by the amount of data used, not by the number of connections.
Every kind of network has the potential for congestion, it's just easier and much cheaper to engineer a terrestrial network to avoid congestion. There are congestion scenarios for satellite networks that are not solvable.
You can use satellite backhaul for a 5G tower. And I'm sure there are many towers with satellite backhaul.
But, once you start having multiple towers near by, you are going to link those up terrestrially (wireless or not) and pretty soon you'll end up with terrestrial backhaul.
Satellite backhaul really only happens in mobile disaster recovery truck-mounted cell sites, and the fairly rare occasions where a rural site can't use terrestrial wireless backhaul.
This is what actually happened. Methanol was put into industrial ethanol to prevent people making drinkable booze out of it. It was required. It was the prohibition era version of spraying Agent Orange on a cannabis crop.
You can't mix really strong robots with humans without barriers separating them. That's one reason humanoid robots won't sell. They're dangerous. Real robots in real factories that make real stuff can juggle car engines. And they can tear you limb from limb. So they work behind barriers and intrusion detection systems.
This is the much more likely future of home robotics. Yes it will be a box, because it would be dangerous to let you stick your fingers inside that mechanism. It won't walk around.
It's probably too much inside baseball to merit a study, but I'm curious if the results would change for part-time coders. When I'm not coding, I'm writing patents, doing technical competitive analysis, team building, etc.
My theory is that if you're not full-time coding, it's hard harder to remember the boiler plate and obligatory code entailed by different SDKs for different modules. That's where the documentation reading time goes, and what slows down debugging. That's where agent assisted coding helps me the most.
SDKs and Binary format descriptors are where I see agents failing the most, they are typically acceptable for the happy path but fail at the edge cases.
As an example I have been fighting with agents re-writing or removing guard clauses and structs when dealing with Mach-o fat archives this week, I finally had to break the parsing out into an external module and completely remove the ability for them to see anything inside that code.
I get the convenience for prototyping and throwaway code, but the problem is when you don’t have enough experience with the quirks to know something is wrong.
It will be code debt if one doesn’t understand the core domain. That is the problem with the confidence and surface level competence of these models that we need to develop methods for controlling.
Writing code is rarely the problem with programming in general, correctness and domain needs are the hard parts.
I hope we find a balance between gaining value from these tools while not just producing a pile of fragile abandonware
One aspect of a product I'm working on is a family communications tool meant to bridge generations. My side project is an alternative client for Bluesky that runs as an installable app on many platforms, and cleans up some of the legacy UI complexity in the default client app. I'm looking for application areas like enterprise group communication. If you are working in related areas, especially in product management and strategy, I want to hear from you. Find me at my name .com
After years of writing native code for mobile apps I'm using Flutter, and finding that, if you do things step-wise, and check in intermediate results so you can easily roll back failed experiments, agent-assisted coding can accelerate your front end coding substantially, and you can deliver more polished results instead of obviously demo grade visual results that need refinement. And that makes it easier to communicate with your non-coder colleagues.
reply