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, pull up a chair, I'm your boy Tony DeLuca and this is Barely Possible, the show where we chew through the AI news so you don't have to swallow it whole. Fresh menu today, and I gotta tell you, there's a story buried in here that I think most people are gonna scroll right past because it doesn't have a flashy funding number attached to it. But it's the kind of thing that, if you build software for a living, should make you sit up straight. We're gonna get there. Buckle up, let's have at it.
Let me start with the one that got my attention, because it's small and it's quiet and it tells you something big about where we are. Google froze its open source bug bounty program. Not killed it — paused it. As of October 1st, with a promise to come back with an update in the first quarter of 2027. This is current, this came out October 4th, reported by Anthony Ha at TechCrunch.
Now, if you don't know what a bug bounty program is, here's the plain version. A big company like Google has a ton of open source software out in the world. They want people to find the security holes in it before the bad guys do. So they pay you. You find a real vulnerability, you report it, they verify it, they cut you a check. It's one of the better ideas in security — turn the whole internet into your part-time quality control department and pay for results. The specific one here is called the Open Source Software Vulnerability Rewards Program. Researchers get rewarded for finding holes in Google's open source code.
And Google just hit the brakes. Why? In their own words, and I'm quoting here: "This pause is due to a significant rise in automated submissions, the vast majority of which are not valid." According to Tom's Hardware, the engineers and the open source maintainers were getting buried under reports that were either invalid or flat-out hallucinated. In other words, somebody — a lot of somebodies — pointed an AI at Google's codebase, told it to find bugs, and then fired off whatever it coughed up. And the whole thing came in so fast and so junky that the humans on the other end couldn't keep up.
Now here's why I care about this more than the dollar amount on any Series C today. This is what people have started calling AI slop meeting the real world and actually breaking something useful. And TechCrunch points out they saw this coming — last year they reported that cybersecurity experts were warning that AI slop posed a serious risk to bug bounty programs. The warning was on the record. And now the warning came true, and one of the biggest, best-resourced companies on the planet had to shut down a good program because the signal-to-noise ratio collapsed.
Let me sit on that for a second, because I think the lesson generalizes way past bug bounties. Any system you've built that relies on people submitting things, and humans on your side reviewing those things — job applications, support tickets, vendor pitches, content moderation queues, academic peer review, grant proposals, pull requests from strangers — every single one of those systems was quietly built on an assumption. The assumption was: it costs the submitter real effort to submit. That effort was the filter. It wasn't written down anywhere, nobody designed it on purpose, but the friction of a human having to actually do the work is what kept the garbage manageable.
That assumption is gone. The cost of producing a plausible-looking, confident, completely wrong submission just went to basically zero. And when the cost of producing something goes to zero, the volume goes to infinity, and your human reviewers drown. Google didn't get hacked here. Google got flooded. And they had to close the door because they couldn't tell the real knocks from the noise fast enough.
If you're a founder, here's the direct takeaway, and I want you to actually write this down. Go find every place in your product and your operation where the whole thing works because a human on the other end reads submissions one at a time. Those are your flood zones. That's where you're exposed in the next twelve months, maybe the next six. The answer is probably not "hire more reviewers," because you can't out-hire infinity. The answer is probably some combination of staking — make the submitter put something real on the line, reputation or money or a verified identity — and using machines to triage machines, so a human only ever sees the stuff that already cleared a bar. And notice, Google's interim move was basically "please go use our other programs," which is a polite way of saying "we don't have the triage layer yet and we need to go build it." That's the honest position a lot of you are in right now, you just haven't had your flood yet.
Alright, that belief about cheap submission being filtered by effort — hold onto it, because it's a thread that runs through a couple more things today. Let's talk about who's actually paying attention to all this now.
Andrej Karpathy put up a short post on the 4th that I thought was worth repeating because it reframes the whole conversation. His mental model, his words: "99%-plus of people who are now paying attention have been onboarded to anything related to AI in less than one year." And then he throws a little dry elbow — this is very confusing, he says, to the AI dinosaurs, meaning anybody who's been in AI since before 2026, or, quote, "gasp, pre-2012."
Now why does that matter to you as a builder? Because it tells you who your user actually is. If 99 out of 100 people paying attention right now walked in the door in the last twelve months, then almost nobody using your product has the mental scar tissue that the old-timers have. They don't remember the failures. They don't have a gut feel for what these models get wrong. They don't instinctively double-check the output because they've never been burned yet. Which connects straight back to the bug bounty mess — a huge chunk of the people firing AI-generated vulnerability reports at Google probably genuinely think they found something, because they don't yet have the instinct that tells them "the machine is very confident and very wrong a lot of the time."
So you've got this enormous population of brand-new, trusting, un-burned users. That's an opportunity and it's a responsibility. The opportunity is obvious — enormous greenfield, people who are open and curious and don't have entrenched habits. The responsibility is that you are, whether you want to be or not, teaching a whole generation what AI is and what to expect from it. If your product ships confident garbage, you're not just hurting your retention, you're training a million people to trust confident garbage. And then they go point that trained-up confidence at somebody else's bug bounty program. It all connects.
Now let me shift us over to a story that is nominally about cars but is really about accountability, and it's one we touched the edges of before so I want to be careful here.
TechCrunch Mobility, Kirsten Korosec's newsletter, ran a piece on reining in robotaxis. California signed Senate Bill 1246 into law — Governor Newsom signed it. And the law sets new rules for autonomous vehicles around what happens when they break down or get in the way of emergency responders. Now I want to be straight with you on the timing, because the details here are a little tangled. The newsletter itself is a recent piece. The law is signed. But the thing actually goes into effect down the road — the piece points to July of 2028 — so this is a rule that's on the books now but doesn't bite for a while. Treat it that way. Don't let anybody tell you robotaxis changed overnight this week, because they didn't.
Here's what the law actually does, and this is the part builders should pay attention to even if you've never touched a vehicle. Companies like Tesla, Waymo, and Zoox will have to give first responders local, on-the-ground support when their robotaxis cause problems. They could face penalties if one of their cars blocks police or firefighters for more than thirty minutes. And here's the one I found genuinely interesting — remote drivers. If you're going to employ a remote driver to take over one of these vehicles, that person has to be based in the United States and hold a U.S. driver's license. Plus the companies have to notify cities and local jurisdictions about where their vehicles are and what state they're in during system-wide failures, and they have to provide what the law calls "local incident technicians" to help with accidents and obstructions.
Now step back from the cars for a second. What is this law really? It's the government looking at an autonomous system and saying: fine, you can automate the operation, but you cannot automate away the accountability. There has to be a human, in this country, with a real license, who can be reached, and there has to be a flesh-and-blood technician who shows up when your robot is sitting in the middle of an intersection with a fire truck stuck behind it. The whole structure of the law is about making sure that when the automated thing fails, there's a named, reachable, accountable human on the hook.
And I want you to hear the echo there, because this is the same shape as the Google story and the Karpathy story, just pointed at a different industry. Google's problem was automated submissions with no human cost behind them. California's answer to automated vehicles is to legally require human cost — human presence, human accountability — behind the automation. One industry got flooded because the human was taken out of the loop. The other industry is being told by law to keep the human in the loop or pay the penalty. If you're building autonomous anything — agents that take actions, systems that touch the physical world or people's money — the regulatory direction is getting very clear. Automate the work all you want. You will not be allowed to automate away the question of who's responsible when it goes wrong. Build your product assuming there has to be a named human on the hook, because increasingly, there's gonna have to be.
And look, the honest bit at the end of that newsletter is worth repeating. The question isn't really whether this one California law keeps robotaxis out of the way of ambulances — it probably won't, perfectly. The real question is whether other states follow California's lead or wait for the federal government to weigh in. If you're building in the AV space, that fragmentation is your actual headache. Fifty different versions of "who's accountable" is a compliance nightmare, and it's coming.
Alright, let me shift gears completely, from accountability to something with no connection other than it's a good story and it's about humans doing hard things. Let's talk about Milt Windler, and let me be clear up front — this is us marking a passing and reaching back into history, not breaking news about 1970.
Milt Windler, one of the four flight directors who in 1970 ran the round-the-clock effort to bring the Apollo 13 crew home alive, died at the age of 94. This is reported by Robert Pearlman at Ars Technica, and Windler died on a Thursday, surrounded by his family. He was "Maroon Flight" — each flight director picked a team name, and his was Maroon.
Now I'm a sucker for these stories, and I'll tell you why this one belongs on an AI show. Because Windler's whole career was about managing systems under failure when there was no do-over and no reset button. He was named a flight director in 1968. He ran a shift for Apollo 8 — the first time humans ever went around the moon. There's this detail I loved: on Apollo 8, Windler and his wife Betty and the other controllers' spouses secretly made these little red and blue flannel banners, each with a white number one on it, to wave at the trans-lunar injection burn as a little message to the Soviets — we got there first. And then somebody up the chain said, you know what, that's inappropriate, the mission's only half over. So they put the flags away. And Windler later wrote that this turned out to be a lesson — you do not celebrate until the crew is standing on the recovery ship.
And then Apollo 13 happened. He was lead flight director. Instead of overseeing the third moon landing, an explosion tore through the service module, and Windler, along with Gold Flight Gerry Griffin, had to poll the room and develop options — when, where, how long to fire the lunar module's engine to swing that crippled ship back around to Earth. That's the job. A system is failing in real time, lives are on the line, and you organize a room full of smart people to not panic and to find the answer.
Here's the quote from Windler that I can't shake, from a 2006 oral history. He said: "Apollo was such a rapid pace that I don't think people had the chance to think about it very much. It has only become more clear to me later on that we were making history." And then, asked what he'd do differently: "If I did it again, I'd probably try to do something more about trying to pay more attention... You couldn't enjoy, really, in a way you couldn't savor it."
I bring that into this show on purpose, because we are all right now in a bang-bang-bang moment. Karpathy's talking about 99% of people onboarding in under a year. The pace is insane. And a guy who ran Mission Control during the single most famous "failure is not an option" moment in American history looked back and his one regret was that he didn't slow down enough to notice he was living through something that mattered. I think that's worth carrying with you this week. We're making history too, in our own smaller way, and most of us are too buried in the next deploy to feel it. Rest easy, Maroon Flight.
Now let me connect that — the "failure is not an option" idea — to something concrete in the builder world, because it's a nice clean bridge. When failure really isn't an option, how do you actually build? Let's get practical.
OpenAI put out a recent piece — a model guide for the GPT-6 family. Now I'll be straight with you, the version I've got is thin on the body text, it's essentially the overview. But the overview itself tells you where the whole industry's head is at. The guide is pitched at startups, and it's about how to choose among the GPT-6 models, how to tune reasoning effort, how to improve prompts and skills, how to coordinate tools, and how to get your workflows ready for production.
And I want to zero in on one phrase in there — "tune reasoning effort." Because that's a dial now. You, the builder, get to decide how hard the model thinks about a given problem, and that's a cost-and-latency tradeoff you're managing on purpose. That is a very different world than "pick a model, send it a prompt, pray." The job has shifted. You're not a prompt-whisperer anymore so much as you're a systems operator — choosing the right model for the right task, dialing effort up for the hard stuff and down for the cheap stuff, wiring up the tools, and hardening it for production where failure actually costs you. It's starting to look a lot more like the Mission Control job than the coding-bootcamp job. Which model do I put on which shift, how much effort does this task warrant, and what's my fallback when it goes sideways. I'd read the full guide if you're shipping on these models — it'll be in the show notes — but the headline for me is just that "reasoning effort" is now a thing you budget, like compute or like money.
Alright, let's move from the model layer to the money layer, because there was a piece previewing a Disrupt conversation that I think has a genuinely useful idea in it even if the piece itself is an event promo.
It's a preview of a talk by Jas Khaira, global head of Blackstone N1, on building the next generation of AI giants. And look, I'll call it what it is — it's a sell-the-tickets piece. But the underlying question is a real one for anybody raising money right now, and it's this: what separates the AI companies built to last from the ones that are just growing fast?
Here's the tension the piece lays out, and it's correct. AI startups can grow at a speed that would've been unimaginable a generation ago. But — and this is the part that bites — you have to make enormous financing decisions long before you know whether that early momentum is a real business or just a sugar high. And the capital requirements aren't like the old software playbook. Compute, data centers, infrastructure — the piece notes Blackstone and co-investors agreed to put up to $600 million in primary equity into an Indian AI infrastructure company called Neysa, which was planning another $600 million in debt on top of that. That's the scale we're talking about. A billion-two for infrastructure for one company.
So here's the line I want you to take from this, and the piece says it plainly: raising more money isn't the same thing as building a stronger company. Fast growth attracts customers, employees, and investors — but the question the grown-ups are asking is whether the advantages driving today's growth can actually hold up over time. In a market where everybody's raising giant rounds at giant valuations, the discipline is in asking whether your moat is real or whether you're just well-funded. Well-funded and defensible are two different things. Plenty of companies have confused the two, right before the music stopped. If you're approaching the point where your next stage of growth requires a lot more capital — and if you're in AI, you probably are — that's the question to sit with. Not "can I raise it," but "does spending it build something that lasts."
Let me take you overseas now, because there's a story here about open source software and government power that every builder should have on their radar.
Jack Dorsey's Bitchat disappeared from the app stores in India after a government order. Now, framing — the underlying events here stretch back over months, July and onward, so this is a developing situation being reported on, not something that detonated this morning. But the mechanics are what matter. Bitchat is a decentralized messaging app. The whole point of it is that it works without an internet connection — it uses Bluetooth mesh networking so nearby phones can pass encrypted messages to each other directly. No cell network, no internet, no central server. You can see immediately why that's useful, and you can see immediately why a government might not love it.
So here's what happened. Dorsey said the Indian government ordered Apple to pull Bitchat from the App Store in the country, citing Section 69A of India's Information Technology Act — that's their main legal provision for government-ordered blocking. Apple said the app stays available outside India, and that the TestFlight beta version would be blocked in the country too. It also vanished from Google Play in India, and the website was unreachable across various Indian internet providers. And going back to July, Dorsey had already revealed that Indian authorities ordered GitHub to take down the repositories for the app. The government's argument, back then, was that Bitchat's architecture makes it hard for law enforcement to intercept communications or trace users, and they pointed specifically to its ability to keep working during internet shutdowns.
And that last part is the crux. The Internet Freedom Foundation, a digital rights group in New Delhi, called the order unconstitutional — their argument being that the law lets the government block unlawful information, not block a messaging app simply because of what it's capable of doing. They also pointed out that neither the blocking order nor the supposedly illegal content behind it had been made public. And the timing is not subtle: all of this is happening during a fresh wave of youth-led protests over the voter rolls, with police detaining people and authorities suspending internet service around a protest site for twelve hours. During earlier protests, people turned to Bitchat exactly because it works when the internet's been cut — the app's downloads in India went from about 1% of its global total to about 85% in a single week in July, per Sensor Tower.
Here's the builder lesson, and it's a hard one. If you build genuinely decentralized, censorship-resistant software, you are building a tool whose entire value proposition is that it resists control — and governments will come for the chokepoints you don't control. You can make the protocol decentralized, but the app stores aren't. GitHub isn't. The ISPs aren't. So the pressure gets applied at Apple, at Google, at the pipe. Decentralization at the protocol layer doesn't save you if your distribution runs through two companies that can be served a legal order. That's the structural reality, and if you're building anything in the privacy or crypto or decentralized space, you should be designing for it from day one, not discovering it when the notice arrives.
Okay, let me bring the energy down and take you somewhere physical and kind of wonderful. Let's talk about exoskeletons — and again, flagging the timing, this is a roundup piece pulling together developments from earlier in the year, March and before, not a fresh breakthrough that dropped today. But it's a good state-of-the-field read and I want to give it a minute.
This was in Ars Technica, written by Ildar Farkhatdinov, republished from The Conversation. And the picture it paints is that exoskeletons — these powered frames you strap onto your body to make you stronger, faster, or just less tired — have quietly crossed over from science fiction into real work. Members of Seattle Mountain Rescue have been hiking into the wilderness wearing powered assist devices on their hips and legs, testing whether it helps them move faster and last longer when they're searching for stranded people. IKEA has used exoskeletons from a company called SuitX for years to help warehouse workers handle heavy stuff. Ford, Boeing, and Mazda Toyota have put them on assembly lines. And the piece notes that earlier in 2026, Ukraine's military said its soldiers had been using Hypershell exoskeletons at the front to carry artillery shells — with a colonel quoted saying soldiers wearing them "become less fatigued, work faster, and maintain combat effectiveness for longer."
The market's small but real — estimated around $500 million now, with predictions it could double or triple by the mid-2030s. And the reason it's taking off is the same reason a lot of things are taking off: the motors, the sensors, the control systems got cheap and good. Same cost curve that's powering everything else.
But here's the part I want builders to notice, because there's a loop in this story that's genuinely clever. The piece points out that research into walking exoskeletons back in the 1960s and 70s helped create the first humanoid bipedal robots. And now it's come full circle — all the current interest and money pouring into humanoid robotics is accelerating the development of better actuators and better batteries, and those improvements flow right back into the wearable exoskeletons. So the robot boom is funding a components boom, and the components boom lifts a dozen adjacent industries that need the same parts. If you're building hardware of any kind right now, that's worth internalizing. The humanoid robot hype may or may not pan out exactly as promised, but the actuator, sensor, and battery supply chain it's building is real, and it's going to make a lot of other physical products possible that had nothing to do with robots. When a gold rush is on, sometimes the smart play is selling the shovels, or in this case, building the thing that uses the same shovels for a completely different job.
Let me close out the health-and-body thread with one more, because it's a current story and it's got a founder angle. The Spotify billionaire's body scan startup has come to America.
Neko Health — co-founded by Spotify's David Ek and Hjalmar Nilsonne — just landed in New York. It's a body scanning company. You go in, you get a one-hour scan that screens your blood, your skin, your metabolism, and they use computer vision as part of it. The company started in Sweden, has raised nearly a billion dollars total, and says it's already got a global waitlist topping 300,000 people. TechCrunch talked to Farooq Abbasi of Preface Ventures, who invested, and he's a believer — he's been scanned twice, says the first-generation scan was a blood test with 15 biomarkers and this latest one was 55.
The pitch is preventative medicine. The scan runs $500, it's not covered by insurance, though it might qualify as a health savings account expense. And Abbasi makes the case that preventative care in America is underused precisely because people are scared of what it costs. His line: "I think preventative care and healthcare should be cheap and accessible."
Now here's where I put my skeptic hat on, because that's the job. There's a tension sitting right in the middle of that pitch and I'd be doing you a disservice not to name it. The vision is "cheap and accessible, Neko clinics everywhere." The reality today is a $500 out-of-pocket scan with a 300,000-person waitlist, not covered by insurance. That's not cheap and accessible yet — that's a premium wellness product for people who can drop five hundred bucks on peace of mind. Which is a fine business. But if you're a founder watching this space, the lesson is the gap between the mission statement and the current price point. A lot of health startups live or die in exactly that gap — the ambition to democratize something, running headfirst into a cost structure that, for now, only serves the well-off. Neko might close that gap with scale. A lot of companies promised to and never did. The thing to watch is whether that $500 number comes down and whether they ever crack insurance coverage, because without that, "everywhere" stays "everywhere the affluent live."
Alright, two quick ones to round out the menu, and then I'll let you go.
First, Pope Leo XIV. And I'll flag the timing — the Pope's more detailed statement on this goes back to an encyclical letter in May, so this is resurfaced, not breaking. But he put up a post laying out what he sees as the difference between human art and machine-generated art. His words: "In this era of artificial intelligence, it is becoming urgent to distinguish human art from what machines produce. There is an ontological difference, even before an aesthetic one, between art and what a machine can generate through statistical calculation based on millions of images created by others. Algorithms lack the spark of humanity." Strong stuff. And here's the detail that made me laugh and also made me think — according to a New York Times report cited in the piece, Anthropic has actively lobbied the Vatican to reconsider its position on non-human consciousness, apparently without much success. Sit with that one. An AI company sending lobbyists to the Pope to argue about whether machines can be conscious. We are living in a very strange timeline, and I say that with affection.
And the last one, a small tool for all of you drowning in tabs. There's a new app called Laytr — this is a resurfaced writeup, the underlying trigger was Mozilla's Pocket shutting down back in August — built by an indie developer in Ontario named Mostafa Talaat. It lets you save anything from the web for later. Not just articles — recipes, screenshots, videos, PDFs, bookmarks, whole tabs. And the thing that makes it interesting, and the reason I'm mentioning it on a builder show, is the architecture choice. There's no server. No account. Everything stays on your own device and syncs through your own iCloud. The developer literally can't see what you save. His quote: "What you save says a lot about you, and I didn't want to be holding it." And because of that privacy choice, it deliberately doesn't do some of the fashionable stuff — no AI summarizing, no auto-tagging, no personalized feed.
I point this out because it's a counter-current. In a week where we talked about Google drowning in AI slop and a hundred billion-dollar infrastructure rounds, here's a solo developer whose entire pitch is "I built it so I'm not holding your data and I'm not running AI on it." There's a real and growing market for that — for the thing that deliberately doesn't phone home. Don't assume every product has to be AI-maximalist. Sometimes "we don't do that, on purpose" is the differentiator.
So let me tie the whole menu together before I sign off, because there's a spine running through today. Google had to shut a program because automation flooded a system that assumed human effort was the filter. California passed a law that refuses to let automation remove human accountability. A flight director who ran the most famous human-in-the-loop crisis in history passed away, reminding us that managing failure is a human craft. And a solo developer built a tool whose whole value is that no machine is watching. The question underneath all of it, the one I'd leave you with: as you automate your product, where are you keeping the human — and is it on purpose, or is it just there until your flood arrives?
Go find your flood zones this week. That's your homework.
That's the show. I'm Tony DeLuca, this has been Barely Possible, and I appreciate you spending a little of your precious time with me. Pay a little more attention out there — Milt Windler would tell you to. Catch you next one.