While the article is oriented towards defense planning, many of these points apply to any sufficiently complex software engineering project.
Generating several "competing constructs" used to be a wanton misappropriation of resources, but now it's not only viable... it's cheap. Comparing these constructs, however, has not necessarily become easier.
Leaders need to avoid using the base appearance of competence to accept any given plan (as they will all appear internally coherent), and instead spend more effort determining which difficult questions have been left unasked. As we learned from HHGttG, the answer is the easy part.
Not OP, but having the exact VM spec your agent runs on is useful for testing. I want to make sure my code works perfectly on any ephemeral environments an agent uses for tasks, because otherwise the agent might invent some sort of degenerate build and then review against that. Seen it happen many times on Codex web.
I have a degree in EE (2016) and am doing mostly ML engineering with a considerable amount of SWE tasks in my day-to-day.
Of my graduating class, very few are designing hardware. Most are writing code in one form or another. There were very few jobs available in EE that didn't underpay and lock you into an antiquated skillset, whether in renewables/MRI/nuclear/control etc.
We had enough exposure to emerging growth areas (computer vision, reinforcement learning, GPUs) to learn useful skills, and those all had free and open source systems to study after graduation, unlike chip design.
The company sponsoring this article is a contributor to that status quo. The complete lack of grassroots support for custom chips in North America, including a dearth of open source design tools or a community around them, has made it a complete non-starter for upskilling. Nobody graduates from an EE undergrad with real capability in the chip design field, so unless you did graduate studies, you probably just ended up learning more and more software skills.
But the relentless off-shoring of hardware manufacturing is likely the ultimate cause. These days, most interesting EE roles I see require fluency in Mandarin.
The one thing I really disagree with is the notion that there will be millions of identical AI images.
The next big step is continual learning, which enables long-term adaptive planning and "re-training" during deployment. AI with continual learning will have a larger portion of their physical deployment devoted to the unique memories they developed via individual experiences. The line between history/input context/training corpus will be blurred and deployed agents will go down long paths of self-differentiation via choosing what to train themselves on; eventually we'll end up with a diaspora of uniquely adapted agents.
Right now inference consists of one massive set of weights and biases duplicated for every consumer and a tiny unique memory file that gets loaded in as context to "remind" the AI of the experiences it had (or did it?) with this one user / deployment. Clearly, this is cheap and useful to scale up initially but nobody wants to spend the rest of their life with an agent that is just a commodity image.
In the future, I think we'll realize that adding more encyclopedic knowledge is not a net benefit for most common agents (but we will provide access to niche knowledge behind "domain-specific" gates, like an MoE model but possibly via MCP call), and instead allocate a lot more physical capacity to storing and processing individualized knowledge. Agents will slow down on becoming more book smart, but will become more street smart. Whether or not this "street smart" knowledge ever gets relayed back to a central corpora is probably mostly dependent on the incentives for the agent.
Certainly my biggest challenge after a year of developing an industrial R&D project with AI assistance is that it needs way, way more than 400k tokens of context to understand the project properly. The emerging knowledge graph tools are a step in the right direction, certainly, but they're not nearly integrated enough. From my perspective, we're facing a fundamental limitation: as long as we're on the Transformers architecture with O(n^2) attention scaling, I will never get a sufficiently contextualized model response. Period.
You might notice this yourself if you ask Claude 4.5 (knowledge cutoff Jan 2025) to ramp up on geopolitical topics over the past year. It is just not physically possible in 400k tokens. Architectures like Mamba or HOPE or Sutton's OAK may eventually fix this, and we'll see a long-term future resembling Excession; where individual agents develop in enormously different ways, even if they came from the same base image.
Regardless of net efficiency, that still entails collecting CO2 at a central facility (where it could have been dealt with in other ways, such as injection underground) and sprinkling it through the air as you fly over delicate ecosystems. I'm sure bankers see both as net zero, but condors might have more issues with your simpler workaround.
> sprinkling it through the air as you fly over delicate ecosystems
I wouldn’t be so sure spraying water vapour is innocuous. As long as it’s atmospheric CO2, the environmental impact of synthetic fuels is much less than rebuilding the world’s air fleet and fuelling infrastructure to accommodate hydrogen.
The difference in volumetric energy density is not that big though, and hydrogen is not as flexible as jet fuel or even batteries when it comes to how you can store it in the vehicle.
To be fair, high gravimetric density is a fairly large advantage for an air plane. But the bad volumetric energy density does present some serious challenges.
Most internal combustion engine cars have a lead acid battery to start it up and run the spark plugs (or preheat the glow plugs if diesel). They don't get called "hybrid" or "battery powered" because the batteries aren't the propulsive power themselves.
This is akin to that: the batteries run the pumps, they're not the propulsive system itself.
Ion drives can be run off battery, but you can't launch with those.
Unlike a car battery though, these batteries provide a not-insignificant part of the energy that is generated by the engine. Each Rutherford engine generates around 37 mega-watts of power at sea-level (24900 N and 3.05 km/s exhaust velocity, Power = 1/2 * Thrust * v_e) and there are nine in the first stage. The first stage battery provides around one megawatt [1].
That's about 0.3% of all energy generated by the engines, which is significantly more than what a spark plug does in an ICE.
This is the closest we have to electric power directly powering the ascent of a rocket from Earth.
Something like a HyperCurie engine (which is also electric pump-fed), could probably lift off from a planetary body like the moon. When they used it in orbit, they actually had to wait for the batteries to charge up from solar panels between each engine burn.
It is about 1 megawatt (1341 HP) of the power pushing the rocket into the sky (directly translated into exhaust velocity and therefore thrust). That would be like a spark plug generating 1 HP in a 300 HP engine (Which would exhaust the typical car battery in about 1 second if it could even push that much power out).
Rough estimates I've seen say the starter motor is about that, though. (Not that I can tell real pages from GenAI ad content farms, I'm not a petrolhead).
I'd agree "it's all semantics", but yours are confusing me :P
(And for energy content, like for like is comparing the size of the fuel tank with the capacity of the battery, but cars aren't 90% fuel by weight).
Generating several "competing constructs" used to be a wanton misappropriation of resources, but now it's not only viable... it's cheap. Comparing these constructs, however, has not necessarily become easier.
Leaders need to avoid using the base appearance of competence to accept any given plan (as they will all appear internally coherent), and instead spend more effort determining which difficult questions have been left unasked. As we learned from HHGttG, the answer is the easy part.