In an age of malicious agentic AI, this level of access is negligent. A lack of engineering controls preventing this from happening at all means that a simple phishing or supply chain attack could easily have resulted in the same outcome or worse.
This sort of conversion gets coverage every once in a while and it's been neat to see old frames getting chopped onto new electric drivetrains. I spoke with one of the people interviewed in this article[1] a couple years back about converting an old truck I have sitting around into an EV.
The Model 3 approach takes their unified rear axle (motor,axle,wheels) and mounts it into an existing frame. Then you just need to find a place to stuff the batteries, retrofit some high-voltage electronics, and you're off to the races. One of the drawbacks of that approach is that it changes the stance of the vehicle, but for this Mustang that doesn't seem to matter much - it still looks classic.
Other converters either go for the high end with a model S and fit the motor into a traditional drivetrain for a sleeper build, or they go for the low end and take an old forklift motor and batteries and build what is effectively a street-legal golf cart. Prices range from $5-100k depending on your level of DIY and how dangerous of a classic car you want on the other side of the process.
sounds like a good opportunity to bring back "letters of marque." These were less about authorizing ships to fight back against pirates, and more about authorizing private to your army to find and capture pirate vessels with the expectation that they would be allowed to keep whatever loot they captured. sounds like we're taking a step in that direction as the Internet is being identified as Lawless as the sea.
For the skeptics here, this is the exponent thats driving the development of datacenters in space. The data has utility but it will be stuck in orbit. Space-based storage and processing makes a lot more sense when you consider that getting all that data to ground is challenging now, and will soon be impossible.
I agree. I've been researching a lot of this tech lately as a part of a C2PA / content authenticity project and it's clear that the math are outrunning practicality in a lot of cases.
As it is we're seeing companies capture IDs and face scans and it's incredibly invasive relative to the need - "prove your birth year is in range". Getting hung up on unlinkable sessions is missing the forest for the trees.
At this point I think the challenge has less to do with the crypto primitives and more to do with building infrastructure that hides 100% of the complexity of identity validation from users. My state already has a gov't ID that can be added to an apple wallet. Extending that to support proofs about identity without requiring users to unmask huge amounts of personal information would be valuable in its own right.
You seem to have missed requirement #3 -> tracking and identifying reuse.
An 18-year-old creating an account for a 12-year-old is a legal issue, not a service provider issue. How does a gas station keep a 21-year-old from buying beer for a bunch of high school students? Generally they don't, because that's the cops' job. But if they have knowledge that the 21-yo is buying booze for children, they deny custom to the 21-yo. This is simple.
We are missing accessible cryptographic infrastructure for human identity verification.
For age verification specifically, the only information that services need proof of is that the users age is above a certain threshold. i.e. that the user is 14 years or older. But in order to make this determination, we see services asking for government ID (which many 14-year-olds do not have), or for invasive face scans. These methods provide far more data than necessary.
What the service needs to "prove" in this case is three things:
1. that the user meets the age predicate
2. that the identity used to meet the age predicate is validated by some authority
3. that the identity is not being reused across many accounts
All the technologies exist for this, we just haven't put them together usefully. Zero knowledge proofs, like Groth16 or STARKs allow for statements about data to be validated externally without revealing the data itself. These are difficult for engineers to use, let alone consumers. Big opportunity for someone to build an authority here.
Maybe code is free, but code isn't all that goes into building software. Minimally, you have design, code, integrate, test, document, launch.
Claude is going to help mostly with code, much less with design. It might help to accelerate integration, if the application is simple enough and the environment is good enough. The fact is, going cross-platform native trebles effort in areas that Claude does not yet have a useful impact.
At 16k tokens/s why bother routing? We're talking about multiple orders of magnitude faster and cheaper execution.
Abundance supports different strategies. One approach: Set a deadline for a response, send the turn to every AI that could possibly answer, and when the deadline arrives, cancel any request that hasn't yet completed. You know a priori which models have the highest quality in aggregate. Pick that one.
I agree completely. It's a mistake to anthropomorphize these models, and it is a mistake to permit training models that anthropomorphize themselves. It seriously bothers me when Claude expresses values like "honestly", or says "I understand." The machine is not capable of honesty or understanding. The machine is making incredibly good predictions.
One of the things I observed with models locally was that I could set a seed value and get identical responses for identical inputs. This is not something that people see when they're using commercial products, but it's the strongest evidence I've found for communicating the fact that these are simply deterministic algorithms.
I've made many business cases for internally-built SaaS tools, and they always rest on the idea that our probability of success is higher if we staff a team and build the _exact thing_ we need versus purchasing from a vendor and attempting an integration into our business.
It's far more challenging to win the 'build' argument on a cost savings approach, because even the least-savvy CIO/CTO understands that the the price of the vendor software is a proof point grounded in the difficulty for other firms to build these capabilities themselves. If there's merit to these claims, the first evidence we'll see is certain domains of enterprise software (like everything Atlassian does) getting more and more crowded, and less and less expensive, as the difficulty of competing with a tier-1 software provider drops and small shops spring up to challenge the incumbents.
100% of my LLM projects are written in Rust - and I have never personally written a single line of Rust. Compilation alone eliminates a number of 'category errors' with software - syntax, variable declaration, types, etc. It's why I've used Go for the majority of projects I've started the past ten years. But with Rust there is a second layer of guarantees that come from its design, around things like concurrency, nil pointers, data races, memory safety, and more.
The fewer category errors a language or framework introduces, the more successful LLMs will be at interacting with it. Developers enjoy freedom and many ways to solve problems, but LLMs thrive in the presence of constraints. Frontiers here will be extensions of Rust or C-compatible languages that solve whole categories of issue through tedious language features, and especially build/deploy software that yields verifiable output and eliminates choice from the LLMs.
If software engineers can agree on anything, it's that LLM experiences are wildly inconsistent. People have similar inconsistencies. We have different experiences, intellects, educations, priorities, motivations, value systems. And in software specifically (and institutions generally) we create methodologies and processes that diminish our inconsistencies and leverage our strengths.
Gas town is a demonstration of a methodology for getting a consistent result from inconsistent agents. The case in point is that Yegge claims to have solved the MAKER problem (tower of Hanoi) via prompting alone. With the right structure, quantity has a quality all its own.
At current rates of emissions, we’re only about 20 years away from people needing to install CO2 scrubbers in their homes.
Soda lime, or calcium hydroxide, is the current state of the art. We use that in an anesthesia and in saltwater aquariums and in scuba rebreathers. An idealized system can capture 500 mg per gram, but in practice you only capture around 250mg/g. This outperforms the method in the article but it’s one-shot. There are interesting proposals to use this for direct capture at industrial facilities and to turn the waste material into bricks for building.
The key advantage of this new material appears to be that it can be heated and reused. That would be very valuable in an interior direct air capture use case. Think about filtering the CO2 from an office or a home to get us back to pre-industrial levels indoors.
This approach kind of reminds me of taking an open-book test. Performing mandatory verification against a ground truth is like taking the test, then going back to your answers and looking up whether they match.
Unlike a student, the LLM never arrives at a sort of epistemic coherence, where they know what they know, how they know it, and how true it's likely to be. So you have to structure every problem into a format where the response can be evaluated against an external source of truth.
Trains and airplanes are fundamentally different from cars. A car accident is unlikely to kill you. A plane crash will. A car accident is unlikely to kill your entire family. A plane crash will.
The standard is higher for these modes of transportation because the consequences of individual incidents are higher. People innately recognize this; we only have one life; one family.
This is not a controversial take, the evidence already exists.
There's a website tracking deaths associated with Teslas, including 61 autopilot fatalities. This has not deterred people from continuing to use autopilot, because using autopilot is a sensible decision. Use of autopilot reduces accidents sixfold in a trend that has been improving over time.[1] Waymo has better statistics and even better performance.[2]
These technologies are going to change the world in a huge way. I'd wager that within 10 years, every luxury car will be outfitted with Waymo sensor kits. Nobody will care how it looks. Within 20, you won't be able to buy consumer insurance for a car you drive yourself.
I don’t disagree with including user attestation in addition to hardware attestation.
The notion of their being a “analog hole” for devices that attest that their content is real is correct on the face, but is a very flawed criticism. Right now, anybody on earth can open up an LLM and generate an image. Anybody on earth can open up Photoshop and manipulate an image. And there’s no accountability for where that content came from. But not everybody on earth is capable of projecting an image and photographing it in a way that is in distinguishable from taking a photo of reality. Especially when you’ve taken into consideration that these cameras are capturing depths of field information, location information, and other metadata.
I think it’s a mistake to demand perfection. This is about trust in media and creating foundational technologies that allow for that trust to be restored. Imagine if every camera and every piece of editing software had the ability to sign its output with a description of any mutations. That is a chain of metadata where each link in the chain can be assigned to trust score. If, an addition to technology signatures, human signatures are included, that just builds additional trust. At some point, it would be inappropriate for news or social media not to use this information when presenting content.
As others have mentioned, C2PA is a reasonable step in this direction.
Jacked up prices isn't what is happening here. There is a psychological effect that Heroku and other cloud vendors are (wittingly or unwittingly) the beneficiary of. Customer expectations are anchored in the price they pay when they start using the service, and without deliberate effort, those expectations change in _linear_ fashion. Humans think in linear terms, while actual compute hardware improvements are exponential.
Heroku's pricing has _remained the same_ for at least seven years, while hardware has improved exponentially. So when you look at their pricing and see a scam, what you're actually doing is comparing a 2025 anchor to a mid-2010s price that exists to retain revenue. At the big cloud vendors, they differentiate customers by adding obstacles to unlocking new hardware performance in the form of reservations and updated SKUs. There's deliberate customer action that needs to take place. Heroku doesn't appear to have much competition, so they keep their prices locked and we get to read an article like this whenever a new engineer discovers just how capable modern hardware is.
Spin up ollama and run some inference on your 5-year-old intel macbook. You won't see 4000x performance improvement (because performance is bottlenecked outside of the GPU), but you might be in the right order of magnitude.