Subscribe
Share
Share
Embed
A daily briefing on the AI systems, products, companies, and policy shifts that are just becoming possible.
Want a podcast for your own topics? Join early access: https://www.barelypossible.to/waitlist/?source_path=public_feed&feed_source=rss
Okay kiddos, welcome back. I'm your boy Tony DeLuca, and this is Barely Possible, the show where I read the technical stuff so you don't have to, and I tell you which of it actually matters to somebody trying to build a company instead of just impress a room. We've got a real menu today, and I want to start with the one that made me laugh and then made me think, because those are usually the good ones.
Here's the headline that grabbed me. Ford rehired its gray beard engineers after AI fell short. That's a recent piece out of TechCrunch, and the quote from inside Ford is the kind of thing you want to staple to your office wall. They said, and I'm reading it straight, "Mistakenly we thought that by just introducing artificial intelligence that would produce a high-quality product." Just introducing it. Like you sprinkle some AI on the chassis and out comes a better car. Sit with that for a second, because there's a whole episode in that sentence.
Now let me tell you why I'm leading with Ford instead of leading with the model-of-the-week stuff, because the smart money, the founder money, is in this story. For the last couple of weeks on this show we've been circling the government-rationing-of-models saga over and over. We did the allowlist for Anthropic's Mythos yesterday. We did the GPT-5.6 throttle. We did the memory chip crunch. Important, all of it, and I'll touch a couple threads later because there's a little movement. But the theme I keep seeing under everything, and the one nobody puts on a slide, is this: companies are quietly discovering that AI is a power tool, not a finished product, and the bill for confusing the two is coming due in real organizations.
Ford is the cleanest example of it I've seen all month. A car company looks at AI, looks at the cost of senior engineers, those expensive folks with twenty, thirty years of knowing why the door panel rattles, and somebody up the chain does the math. AI's cheaper. AI's faster. Let's lean on it. And then the product quality slips, and they have to go back and rehire the gray beards. The exact people the spreadsheet said they could thin out.
Here's what I want you to take from that if you're building. The mistake wasn't using AI. The mistake was treating AI as a replacement for the judgment layer instead of a multiplier on it. The gray beard at Ford isn't valuable because he types fast. He's valuable because he's seen ten thousand failures and he can smell a bad design before it's a recall. That tacit knowledge, the stuff that isn't written down anywhere for a model to learn from, that's the thing AI is worst at and the thing companies keep trying to automate first because it's the most expensive line item.
And look, I'm not anti-AI, you know I'm not. But there's a pattern I want every founder listening to internalize. When AI makes a task cheap, the value doesn't disappear, it moves. It moves up the stack to whoever can tell the difference between a good output and a plausible one. Ford learned that the hard way and had to pay twice. Once to lay off, once to rehire. You don't want to be the company that pays the Ford tax.
Let me connect this to a softer piece in the same batch, because they rhyme. There's an interview TechCrunch ran with the writer Ian Bogost about his new book, The Small Stuff, and the framing question was blunt: has Silicon Valley been building the wrong things? Bogost's argument, roughly, is that we've spent two decades dematerializing everything, taking the physical, tactile, slightly inconvenient parts of life and flattening them into apps and abstractions, and that maybe the small inconveniences were doing something for us. Now, that's a culture essay, not a product spec, and I'm not going to oversell it. But put it next to Ford. Both stories are about the same blind spot. We are very good at automating away the visible cost and very bad at noticing what the visible cost was holding up. The rattle in the door panel. The friction in the daily routine. Sometimes the inconvenient thing was load-bearing.
For a builder, the actionable version of that is unglamorous: before you automate a step, figure out what that step was secretly doing besides the obvious. Half the time the friction was quality control nobody documented.
Now let's shift from the philosophy to the money, because Wall Street is doing something this week that I want you to watch with a skeptical eye. TechCrunch ran a piece titled, basically, why Wall Street thinks US memory maker Micron is the next Nvidia. And I want to be careful here, because we covered the memory chip crunch a few days back, the profit jump, the HBM shortage being the real bottleneck under the AI boom. So this is a follow-up, not a re-run. The new wrinkle is the narrative itself: investors, hungry to find the next stock that goes up like Nvidia did, have decided Micron is it.
Here's my street-level read, and you can take it for what a radio guy's opinion is worth. Whenever you hear "the next Nvidia," your wallet should flinch. Not because Micron's bad, the underlying story is real, memory is genuinely the choke point, high-bandwidth memory is scarce and everybody building these data centers needs it. That part's solid. But "the next Nvidia" is a story Wall Street tells when it's already a little late to the first one. It's pattern-matching on the last winner. And memory has a history Nvidia's accelerators don't share: memory is famously cyclical. It booms, it gluts, prices crater, the whole sector takes a haircut. Nvidia's pricing power came from a near-monopoly on a specific kind of chip. Micron's in a commodity-ish market with real competitors. So when somebody waves the next-Nvidia flag, the question isn't "is memory hot right now," it obviously is. The question is "what happens to this when supply catches up." If you're a founder thinking about your own compute and memory costs, the read-through is the one that actually affects you: scarcity is keeping these prices high, and scarcity ends. Plan your unit economics for the day the memory crunch eases, not just for today's panic pricing.
Let me pull on a related thread, because there's a second hardware story that's pure hype-check material. SoftBank's CEO, and he's not alone, has questions about Elon Musk's orbital data center pitch. The idea, for those who missed it, is you put data centers in space. Solar power's abundant up there, cooling's a different problem, and you've got Musk with the rockets to put the hardware in orbit. Sounds like science fiction, which, you know, sometimes science fiction ships. But TechCrunch's piece is about the pushback, and SoftBank's Masayoshi Son, a man who has historically never met a moonshot he didn't want to fund, is among the skeptics. When the guy whose whole brand is betting big on the future is raising an eyebrow at your space data centers, that tells you something about where this sits on the realism spectrum.
My take, briefly, because I don't want to spend your time relitigating Musk's PowerPoint: orbital data centers are a real engineering conversation buried under a marketing one. The hard parts, getting compute into orbit, servicing it, cooling it, getting the data back down fast enough to matter, those aren't solved by enthusiasm. And the reason this matters to a founder isn't that you're going to build one. It's that the energy and cooling crisis for AI data centers on Earth is so acute that serious people are floating, literally, orbital solutions. The bottleneck under the bottleneck isn't chips anymore and it isn't even memory, it's power and heat. Keep your eye on anyone solving the boring version of that on the ground, because that's where the durable business is.
Now let me dig into the deep dive, and I'm going to do something a little different. The most useful long piece in front of me today isn't a news story, it's an operator's playbook, and I want to extract the one genuinely valuable argument from it and leave the rest, because that's the deal I make with you.
There's a daily AI commentary show, and one of its recent weekend episodes laid out what the host called the capability overhang playbook. Now the framing context is the thing we've been beating to death: we're in what he calls a forced, involuntary AI pause. The new models everybody was waiting for got delayed, partly because of the government licensing mess we covered yesterday, partly because the labs aren't satisfied with what they've got. So instead of a new shiny model every week, we've got a quiet stretch. And his argument, which is the part worth your time, is this: you already have way more capability sitting in front of you than you're using. The models you've got access to right now can do dramatically more than most people and most organizations are actually getting out of them. He calls that gap the capability overhang. The distance between what the tool can do and what you've bothered to make it do.
And I want to read you the core of it, because the phrasing matters. He says the good news is that even the previous generation of models have a lot more capability, particularly within the harnesses we have access to, than most of us are getting real value out of. So his proposal is that during this forced pause, where there's a little breather before the next new thing, this is a good time to close that overhang, at least a little, in your individual and organizational lives.
Now here's why I'm spending real time on this instead of waving it off as another operator pep talk. Because it's the constructive flip side of the Ford story, and the two of them together make the actual point of today's show.
Ford's lesson was: don't treat AI as a finished product that replaces your best people. The overhang playbook's lesson is: but also, don't leave the thing mostly idle either. Both failures are the same failure of judgment about what the tool is. One side over-trusts it, fires the gray beards, ships junk. The other side under-uses it, keeps the gray beards typing emails by hand, leaves value on the floor. The sweet spot, and this is the whole ballgame for a founder right now, is using the tool to amplify your judgment people instead of replacing them or ignoring it.
Let me give you the concrete bits from the playbook that I think actually translate, because some of it is the usual exhortation and some of it is genuinely good.
The best idea in there, and I mean this, is building yourself a personal benchmark. Not a fancy academic eval, just a set of the tasks that actually matter in your work, with the prompts you'd really use, the outputs you'd expect, and what "good" looks like to you. The reason this is smart is durable: when the new models finally drop, and they will, you'll be able to run them against your own real work in an afternoon and actually know whether the upgrade helps you, instead of reading some leaderboard that has nothing to do with your business. That's a founder move. You're building a private measuring stick for the one thing you care about, which is your product.
The second idea worth stealing is what he calls portable context assets. The pitch is that people burn hours every week re-explaining themselves to the AI, re-uploading the same background, re-establishing who they are and what the project is. He cites a study finding people spend something like two and a half hours a week just organizing context for the AI they use. So you build that context once, properly, as reusable documents, and you carry it from tool to tool. The reason I like this for a builder specifically is that it's a hedge against exactly the lock-in problem we've talked about on this show before. If your context lives in portable files instead of trapped inside one vendor's product, you can move when the pricing changes or the model gets throttled or a better tool shows up. And given that the whole industry just watched the government start rationing access to specific models, portability stopped being a nice-to-have. It became a survival skill.
The third thing, and I'll keep it short because it's the most inside-baseball, is the idea of experimenting with the harnesses rather than the models. The point being, since you can't play with the unreleased frontier models, spend the quiet time getting fluent in the tools you run them through, the coding agents, the workspace integrations. Build the same small project in two different tools and feel the difference. That's a reasonable use of a slow week.
Now where I'd push back, gently, on the whole playbook. There's a line in there that I think founders should sit with carefully. He warns about what he calls an over-strong known-ROI bias. The worry being that organizations, under pressure to justify their AI spend, will only chase efficiency use cases, doing the existing work faster and cheaper, and never get to the opportunity use cases, the genuinely new products that weren't possible before. And he's right that you want both. But I'll be the skeptic at the table: for a small company, doing the existing work faster and cheaper is not the consolation prize. Sometimes that's the difference between making payroll and not. The efficiency stuff is the foundation, like he says, but I'd tell a founder, build the foundation solid before you go chasing the moonshot product. The startups that died chasing opportunity AI while ignoring their burn rate are a longer list than anybody admits.
So that's the deep dive, and the through-line connecting it back to Ford is the thing I want you carrying out of here today. The tool is more capable than you're using it, and less capable than the spreadsheet wants it to be, both at the same time. Your job as a builder is to find that line. Not the hype line, not the doom line. The actual line where the thing helps your good people do more without pretending it can replace them.
Let me catch us up on a couple of the policy threads, briefly, because there's a small new wrinkle and I promised I wouldn't just re-run yesterday. We've covered the government-rationing story thoroughly, the allowlists, the throttling. The new texture today is a comment from Yann LeCun, who reshared a take from Clement Delangue, the Hugging Face guy, and the line was that it's quite rational to regulate frontier API models, especially to get more transparency for the government, without restricting, and it cuts off there, but the clear implication being without restricting open models. Now I flag this not to relitigate the whole regulation fight, but because the position is interesting coming from those two. These are open-source-leaning voices, and their framing is a deliberate wedge: regulate the closed frontier APIs if you must, but leave the open-weight ecosystem alone. Whether you agree or not, that's the fault line forming. The closed labs get the government's attention and the government's leash. The open-weight crowd is trying to argue itself into the "don't bother regulating us, we're just publishing math" category. For a founder choosing what to build on, that distinction is about to have real teeth, because where the regulators draw that line determines which models you can actually depend on a year from now.
And that connects to a developer-tooling note worth thirty seconds. OpenRouter, the model-routing service, rolled out a unified image API, one normalized request format across thirty-plus image generation models from eight different providers, with transparent per-image pricing showing up right in the response. Now on its own that's a feature announcement. But in the context of everything we just talked about, portability, not getting locked to one vendor, the government rationing specific models, a router that lets you swap image providers behind a single interface is exactly the kind of insurance policy a builder wants right now. You don't get married to one image model. You point at a router, and if one provider gets expensive or throttled or just worse, you reroute. That's the portability principle from the deep dive, made concrete in a product. I'd kick the tires on it. Link's in the show notes.
Let me move us into a few stories that matter for builders even though they're not about models at all. First one, India. There's a piece on Dilip Asbe, who runs India's payments infrastructure, the UPI system, and his argument is that AI is going to be heavily involved in the next era of digital payment growth, and crucially that newer payment apps could finally become competitive if there's a viable commercial model behind them. Now, UPI is one of the most important pieces of fintech infrastructure on the planet that Americans mostly ignore. It moves staggering volumes, and it's been famously hard to make money on because it's been essentially free. Asbe floating a viable commercial model is the interesting part. If India's payment rails open up to a sustainable business model layered with AI, that's a green field for fintech founders the size of a subcontinent.
And it doesn't stand alone. Recall, OpenAI poached the Uber India chief to lead its biggest market outside the US, a recent report, and that's the same signal from a different direction. The serious money has noticed that India isn't a side quest, it's a main market. If you're a founder thinking about where the next hundred million users come from, the people who actually move when they're serious are moving there. That's worth more than any forecast.
Now let me hit one that's a pure cautionary tale for anyone building agents, because it's the kind of thing that doesn't make headlines but should. There's a security writeup about AI agent skill scanners from Cisco and Nvidia getting bypassed by a fake marketplace. The short version, and I'm keeping it short because the details are technical: the tools that are supposed to scan agent skills for malicious code got fooled by a counterfeit marketplace. The reason this matters to you, even if you never touch those specific products, is that we are racing to build agent ecosystems, marketplaces of skills and plugins and tools that agents pull in and run, and the security model is way behind the capability model. Same lag we keep seeing. The agent can do impressive things. The guardrails around what it pulls in and executes are duct tape. If you're building anything where an agent installs or runs third-party skills, assume the scanner can be fooled and design like the supply chain is hostile. Because it is.
Let me give you a quick mobility and liability note, because it ties to a theme. Tesla settled an FSD crash lawsuit, this was a recent report, connected to a fatal 2023 crash involving Full Self-Driving, and federal investigations are still going. And TechCrunch's mobility roundup this week was, in their words, all eyes on Tesla FSD. I'm not going to wade into the Tesla fight, that's a religious war and I'm not here to officiate. But the builder takeaway is the same one from Ford, just with higher stakes. When you ship AI that takes real-world action, driving a car, the gap between "works in the demo" and "works in the wreck" is where the lawsuits live. Settling a suit while investigations continue is the sound of a company managing the cost of that gap. Anybody building agentic systems that act in the physical or financial world should watch how this plays out, because the liability framework that gets built around self-driving is going to be the template for liability around every other consequential agent.
Alright, let me clear out a couple of lighter ones, because not everything has to be a sermon.
There's a luxury EV story I can't resist. Apple and Audi alumni built a street-legal electric buggy, the Amble One, basically a fancy moon-buggy-inspired thing for twenty-five grand aimed at luxury resorts. Twenty-five thousand dollars for a golf cart with a pedigree. I'll just say, when the ex-Apple, ex-Audi talent is building resort buggies, you can read that two ways. Either the big-swing car projects ran out of runway and the talent's finding smaller landings, or there's a real luxury-mobility niche somebody finally figured out how to price. Probably a little of both. I just enjoy that the moon buggy came back around as a resort toy. That's the circle of life in this business.
And one consumer note that's actually a small policy thing: a California law targeting obnoxiously loud streaming ads takes effect July 1. Illinois passed something similar. For anybody who's been blasted out of their chair when the show goes quiet and then the ad screams at you, relief is coming, at least in those states. And the builder angle, small as it is: this is regulators catching up to a specific, annoying ad-tech behavior that the industry would never fix on its own because the loudness was working for them. It's a tiny preview of how regulation actually arrives in tech. Not with a grand framework, but one specific annoyance at a time, after the industry's had years to behave and didn't.
Let me bring it home. The thread running through today, from Ford rehiring its gray beards, to the overhang playbook telling you to actually use the tool you've got, to the security scanners getting fooled, to Tesla paying for the gap between demo and disaster, is a question about judgment. Where does it live, who has it, and what happens when you try to automate it away or, just as bad, leave it sitting unused on the table.
The companies winning right now aren't the ones who believe AI is magic, and they're not the ones who think it's a toy. They're the ones who figured out, specifically, in their own shop, which tasks the machine should run and which ones still need the person who's seen the door panel rattle a thousand times. Ford had to pay twice to learn it. You don't have to. Build your little benchmark, keep your context portable, keep your good people sharp, and treat every "just add AI" pitch with the same skepticism you'd treat a guy selling you the next Nvidia.
That's the show. I'm Tony DeLuca, this has been Barely Possible, and I appreciate you spending part of your day with me. Go build something that's worth the friction. Take care of yourselves.