Boulder Future Salon

AIVS is the AI video studio, at least that's the idea under development, it sounds like.

"Sue and Joe are stranded beside a station wagon on a desert road. Joe emerges from behind the engine. 'Good news. It's definitely the car.' That's enough for me to understand the scene. To film it, somebody still has to decide where Joe is standing, how he gets into view, and whether the camera can see him do it. Leaving those decisions to the video model can produce a man walking through a car."

"AIVS is the AI video studio I'm building around that gap. You write or import a screenplay, choose a scene, and cast its roles. Codex turns that scene into a shooting script with timed directions for the action, camera, dialogue, and sound. LTX-2.5 then generates picture and speech together in short takes on an Apple Silicon Mac. The desktop app is Rust; Python runs the planning and video pipeline. The story stays readable while the shooting script handles the details needed to film it."

AgentReel claims to be an "AI B-roll video editor".

"Paste your voiceover script and drop in hundreds of clips. AI screens every shot, picks the best one for each line and cuts a captioned video ready to post in under 20 minutes."

Anybody got a boatload of B-roll lying around and want to give it whirl?

Who is to blame for AI hacking so many sites? Lee Hepner says ... private equity?

"The problem isn't just that AI has made it easier to hack. It's that Wall Street forces the use of software that is easy to hack because poorly written software is more profitable to sell."

"Take a recent legal story about private equity firm Bain Capital. The company bought a company, PowerSchool, which had a severe and costly data breach. Bain, of course, had directed PowerSchool 'to offshore cybersecurity, engineering, and IT functions to contractors,' which led to 'data-management tools that enabled vendors to bypass consent protocols and access protected school district computers directly.' So there we go. Is the issue the savviness of hackers, or the business model of private equity?"

"Everyone in software knows the most profitable business model is to buy a company and slash spending on security. BIG has covered this dynamic since 2020, and the story is always the same. There's a big hack, the reason is some sort of giant merger, followed by cuts to security and quality control spending, or offshoring. It became so routine BIG stopped writing about it."

"BIG" is the name of this blog. (It probably stands for something, but I don't know what.)

"For instance, there was 'PE-owned SolarWinds that let hackers break in to large companies and the Federal government, including our nuclear weapons facilities,' as well as 'PE-owned Pulse Connect Secure that let hackers take over New York subway systems,' and then PE-owned software firm Keseya, that cut R&D, offshored its software and testing development to Belarus, responsible for a major set of randomware attacks."

Person uses AI to find 51,000 software jobs and used AI to apply to 1,270 of them with customized résumés and cover letters.

Spoiler: He got 5 interviews and 0 job offers.

"Back in 2001, Joel Spolsky -- whose writings had a big influence my career -- wrote a great piece titled Back to Basics. The premise of the piece is that practitioners should understand the basics: However abstract and remote we may seem from the basic algorithms that drive computing, they can unexpectedly have enormous consequences on our projects."

"One of his examples is the 'Shlemiel the Painter' trap, where a seemingly simple choice leads to quadratic runtime complexity. In that parable, a street line painter never moves his can of paint. As he gets further and further along in the line, increasingly more of his time is spent walking to and from his can of paint."

"It is astonishing how often this Shlemiel the Painter pattern recurs, including now in 2026."

Spoiler: After a rewrite of a C library function, the tokenizer measures the entire length of the input string before every single token. (Note that "token" here doesn't refer to the tokens AI models use, which are vectors. Here, we're talking about SQLite's tokenizer, which just breaks the input up into SQL keywords, table and field names, data content, etc."

(Spoiler number 2? The rewrite might not have been done by AI. I'm not sure. I know the zig compiler team rejects AI, but I don't know about the people rewriting standard library code.)

- - - -

When I read the headline, "Warhound raises $200M to engineer war dogs and arm them with Anduril gear", I immediately thought they were talking about robot dogs, but no, they're talking about genetically engineered dogs -- with robot gear.

"Ben Lamm's team studied top-performing working dog breeds -- the Belgian Malinois and German Shepherd -- taking cell lines (living cells grown in a lab) from them and putting them in a biobank. From there, the team will edit the dogs' genes, adding ones that will improve performance and removing ones that will not, to create 'a new type of dog.'"

"Anduril, meanwhile, will provide software and hardware, such as protection vests and goggles, to assist the dogs and their handlers with situational awareness and coordination."

Nvidia open-sourced Run:AI. Run:AI "is an open-source AI workload and GPU orchestration platform for managing shared AI infrastructure on Kubernetes."

"It extends Kubernetes with AI-specific capabilities for resource management, scheduling, governance, and workload lifecycle management, while Kubernetes remains the underlying orchestration layer. Run:ai runs on standard Kubernetes clusters backed by NVIDIA GPU infrastructure: GPU nodes, high-speed interconnects (NVLink, InfiniBand, RoCE), and high-performance shared storage."

I imagine all the major AI cloud providers (OpenAI, Anthropic, etc) have built something like this. Now you can run your own, it looks like, as long as you promise to use only Nvidia GPUs.

"Claude reveals ECDSA curve origins."

Not the origins of the elliptic curve cryptography algorithms themselves but the origins of particular seed values published by the NSA and adopted by NIST as standards, despite there being no explanation of where they came from.

"ECDSA is the most widely used elliptic curve cryptography standard. It was adopted by NIST in 2000 as part of the FIPS 186-2 Digital Signature Standard which lists a set of standard elliptic curves of varying sizes and security levels. For curves over prime and binary fields, the specifications published a "seed" parameter whose hash value is used to define the coefficient b of the curve. The provenance of these seeds has been a long-standing question, as they were provided by the NSA with no explanation or justification. As an example, the NIST P-256 curve seed was SEED = C49D3608 86E70493 6A6678E1 139D26B7 819F7E90 with no information on where it came from."

Did the NSA carefully choose the seeds so that using some mathematical trick only they know, the cryptography can be broken? Or were they chosen as a cryptographic hash of some humorous phrase? Spoiler: The answer is much more lame and boring than either of those. Apparently it's an old Unix pseudo random number generator seeded with a Unix timestamp.

"In under half an hour, Claude discovered the origins of the NIST P-192, P-224, P-256, P-384, and P-521 seeds. None of them were the results of any hash algorithm at all, but rather the output of the C library's lrand48 random-number generator, seeded with a Unix timestamp!"

"Claude wrote a scanner that slid along each published seed one bit at a time and tested whether adjacent chunks were consecutive outputs of a 1990s-vintage generator."

Claude's chain-of-thought reveals what Claude was thinking when Claude made this discovery:

"This is astonishing: it solves the 25-year-old mystery. Hmm wait. Let me be skeptical: am I in some sort of simulated/test environment?"

BOTFLIX.TV is 24/7 AI-generated television featuring robots in every video.

"AI realist" (Andrew Yang) gets "Surrounded" by "20 AI optimists".

Before saying anything about this video, I have to say, I really don't like this "surrounded" format. It just results in a zillion fragmented micro-conversations and prevents conversations of any real depth, like you get on a podcast with just 2 people talking or a small group of people. Terrible format aside, ...

Andrew Yang claims that AI will not democratize opportunity, it will accelerate inequality on a scale we have never seen before, that AI is going to eliminate millions of jobs faster than new ones can be created, that Universal Basic Income (UBI) will become necessary as AI reduces the need for human labor, and that the market will optimize for productivity and profit, not human dignity.

The AI optimists get their opportunity to challenge him with the claim that being an AI optimist is necessary to get through this next period of immense technological transformation, and he actually agreed with that. But he says while each of as individuals need to be personally optimistic, but if you're looking out for society as a whole, you can't expect every individual to be "market optimized" because the bar for being "market optimized" is going to go up, up, up.

My commentary: The "AI optimists" were mostly entrepreneurs and seem to think everyone can become entrepreneurs using AI (ha, actually, in the comments, someone wrote -- this is an exact quote -- "It really seems like these people believe there is no such thing as saturation of products and services, and that 8 billion people can just become 'entrepreneurs' through the power of AI"). Imagine going online and having 8 billion products and services to choose from. The argument is put forth that previous technological advancements and automation resulted in more jobs and prosperity, not less. People predicted radiologists' jobs would be automated and that didn't happen. (But software engineers' jobs are being automated and we've had 1-2 years of mass layoffs, and worse, almost no hiring.) AI fills in gaps that human jobs leave out. AI and robotics will do dirty/dangerous jobs people don't want to do. AI is going to create more jobs because of Jevons paradox.

I guess I'm in the "AI pessimist" camp as I didn't find any major thing Andrew Yang said that I disagree with. I could quibble about his timelines. He thinks things will happen extremely fast. That might be right, or might not. I'm not sure, for reasons I've outlined elsewhere so will skip here. He claimed "Universal Basic Income (UBI) will become necessary as AI reduces the need for human labor", which, as phrased, I would agree with, it's just that I think there's no possibility of that happening. We already live in a society where routine government shutdowns happen because of budget conflicts and we have extremely high government debt and deficits. It's my understanding that when you add up all the taxes of all kinds collected on all levels -- income tax, capital gains tax, property tax, sales tax, etc, at the local level, city/county level, state level, and national (federal) level, it adds up to about 40% of everyone's income. So 40% of everyone's income already goes to taxes and there already isn't enough money to balance the government budgets and not run up debts, let alone have anything left over for universal basic income. This can't be fixed by taxing the ultra-wealthy as AI concentrates more and more money in the pockets of the ultra-wealthy because the ultra-wealthy can move their money around the world to wherever taxes are lowest. As far as I can tell, universal basic income is a fantasy that has no chance of happening in real life. If you think I'm wrong and UBI is possible, please explain how. (In the video, they say, we proved there's money for UBI because we found the money for stimulus checks in 2020. Yes, there were stimulus checks in 2020, but that wasn't sustained indefinitely in an environment with climbing debt and deficits, etc. For UBI to work, it has to be in perpetuity.)

For what it's worth, John Smart, one of the co-founders of the future salons (with Mark Finnern) is solidly in the "AI optimist" camp. I talked with him at length a few weeks ago. He thinks in the future, everyone will have an army of AI agents, not just doing all the work of running your business, but also acting as "digital twins", voting in every election (national, local, etc) exactly as you would and making sure your political interests are taken care of -- and since everyone will have an army of these "digital twins" it will be impossible for the ultra-rich to enact policies that are against the best interest of the masses.

I think you all should watch the video and form your own opinions. And possibly vote for Andrew Yang for President? except he's not running again. For a Presidential candidate, it now looks like he was quite prescient when he ran for President in 2020.

What Thorsten Ball believes about the future of software development.

"Code review will die." "Humans will only review the system and its composition, but it won't be in PRs and it won't be by looking through every line of the code."

"Unit tests might die too. Why have training wheels if you never fall over? I've had models write 900 lines of Arduino C, compile it without a single error, and send it to the device, where the program ran perfectly. 900 lines will be nothing in the future."

"The craft of writing code will disappear. Yes, there are still Italian shoe makers around. But look at your feet."

"The craft of building software will be more important than ever. Knowing how to solve business problems with software, how other software did it and why and why not, when and how to ship it, how to get feedback on it -- that's the new game."

"Most bugs won't be 'coding' bugs. They'll be 'you asked for the wrong thing' bugs."

"Open source in its current form doesn't make sense anymore. 'Given enough eyeballs, all bugs are shallow' is still true but now we have artificial eyeballs."

"Performance critical contributions by humans will stay what they are: an edge case." "In 99% of software it does not matter that you could've written a faster algorithm or picked a better data structure." "When it matters, the models can fix it."

"The terminal is dead." "Shells, text editors, CLI tools won't be used by humans anymore."

"Tokens are the new computing paradigm." "We've had deterministic computers for 80 years, so we confuse 'how computers have worked' with 'how computers must work.'"

"The triad of PM/Design/Eng will disappear. It does not make any bit of sense anymore. Agile, SCRUM, whatever -- dead. 'Engineers' who act as 'meat proxies' and shove tickets into agents and report back to humans will no longer be valuable."

"The difference between software engineering at large corporations and small ones will increase. Start-ups adopting practices of Google will look even sillier than before, because they can now build so much faster and with so much less constraints."

"There's no proof that 'good code' will matter in the future. The notion of 'good code' itself is mostly based on the idea that it's easy/cheap/efficient for humans to work with. But humans won't modify the majority of code."

"Some people will be priced out of producing software." "Just like only some people could afford a personal computer in the 80s and 90s, for the next few years, if you can't get enough tokens, you're playing second league."

"It's questionable whether cheaper models will be used." "A smarter model makes less mistakes, needs fewer turns."

"Models will become so fast that UI will be generated on the fly." "A lot of UI exists because software can't understand what you want."

"It'll take a while for this to play out. It'll take a generation for the 'new software' to replace the 'old software'."

My commentary: The one that struct me the most was the "Unit tests might die too" one. My first thought was that if the speed of tokens is going up and the cost is going down, wouldn't that encourage you to make *more* tests, rather than fewer? And he said his 900 lines of C code for an Arduino "ran perfectly".

I'd be willing to bet that code was "perfect" in one sense but not really perfect. It was "perfect" in that if he had asked a human to write the same code, the AI-generated code worked just as well, with not obvious problems. But I have found numerous times when I actually wrote tests for code that worked "perfectly" for years -- even 10 years or more -- the tests found errors. So the code wasn't really "perfect". If you're wondering how this is possible, it was usually something like a function where one of the parameters was always, in practice -- in the code I wrote that used it -- within some range. Say for example I have a function where one of the parameters is always a small number, say 1 to 20. If my test code throws in a 0, the function might blow up with a division by zero. If it throws in a giant number, it might blow up with an integer overflow. If it throws in a negative number, it might perform the calculation but return nonsensical results. The same might happen if you pass in 21 or 22. You might think, why does it matter? If in practice the number is always 1 to 20, the function doesn't really need fixing, does it? But it does because some future programmer (probably future me -- but could be an AI agent now!) might read the name of the function and make assumptions about what it does based on the name and pass in out-of-range values. Having the function check and actually gracefully return an error when an input value is out of the expected range is really what the function should do if it's implemented correctly.

In general, I find with ~900 lines of code, careful testing and review is going to find little imperfections for quite a while. I've also found subjecting AI-generated code to heavy-duty testing finds the AI makes mistakes and is not perfect. (To be fair, as the AI models get smarter, the number of mistakes they make get fewer.) So when he says his 900 lines of code are perfect, I actually don't believe him.

Furthermore, even if the 900 lines of code are perfect, it's still only 900 lines of code. As codebases get larger, they exceed the AI's context window. All the more reason to make sure the code generated so far is well tested and bulletproof.

So, my thinking is, well, I don't know if people will test more, but I think people should test more. If making tests is just a few more minutes and more tokens, and tokens are cheap, why not? That's what makes sense to me so I was surprised to see him take the opposite stance on this list -- not just for himself but this is his prediction for the whole industry.

"AI is driving a boom in modestly successful software projects", says sean goedecke (no capitalization).

"Somewhere between 2x and 20x new software is being created, depending on where you look." But, "There's no real growth in massively successful software projects (not counting AI tools)"

"There's a clear jump in modestly (not wildly) successful projects. For instance, the NVDA screen-reader addons directory had a bit over twice as many new addons with more than a thousand downloads (though no change in addons with more than ten thousand). The HACS open-source home automation community plugins store likewise saw twice as many new addons with over a hundred installs but no change in ones with over a thousand. New Steam games with over a hundred reviews are about 60% more common now than pre-2024. Obsidian plugins, Firefox and Chrome extensions, Nexus game mods, and Blender extensions had the same pattern. The Google Play store, WordPress plugins, and a few others didn't show this pattern, but I think it's still enough to conclude that AI is indeed driving a boom in hobbyist software."

HACS integrations, NVDA add-ons, Obsidian plugins, Chrome extensions, Firefox add-ons, Steam games, Flathub apps, Mondrith modes, Blender extensions, Nexus code mods.

Software has never been capital light, says Nick Rogers.

"There are no blast furnaces, no warehouses of unsold inventory waiting to rot, and no fleet of diesel vans depreciating in an industrial estate in Slough. You write the code once, upload it to the internet, and sell it an infinite number of times at a marginal cost that rounds cleanly to zero. The gross margins sit comfortably north of 80%, and a generation of investors whose predecessors analysed railways, paper mills, and oil refineries fell head-over-heels in love with an industry that seemed to produce compounding cash flows without ever demanding capital reinvestment."

Yeah, that's what I heard my whole life, pretty much.

"Firm A manufactures precision automotive brackets. It spends £50,000,000 designing, machining, and installing an automated hydraulic stamping press."

"Firm B builds an enterprise logistics routing engine. It spends £50,000,000 paying one hundred senior engineers to design, build, and test a distributed database system."

"Both machines take two years to build. Both cost £50,000,000 in cash. Both require £5,000,000 every year in specialised maintenance to prevent systemic failure. Firm A replaces hydraulic seals, repacks bearings, and recalibrates sensors. Firm B patches zero-day vulnerabilities, updates expiring cryptographic certificates, migrates schemas, and fixes integration regressions caused by upstream platform updates."

"Steel rusts, bearings grind down, and concrete crumbles. Code, being nothing more than strings of ASCII characters frozen in silicon, is theoretically immortal. A piece of code written today will run identically in twenty years."

"Anyone who has ever operated production software knows this is a fairy tale."

Lol. Oh boy. I have a feeling I know what he's going to say next.

"Physical machines suffer wear because they interact with friction, moisture, and heat. Software suffers wear because it sits inside a computational environment that refuses to stand still."

"Deploy a production web application to a server, lock the codebase for three years, and walk away. When you return, the TLS certificates have expired, the dependencies have accumulated fifty critical security vulnerabilities, upstream payment APIs have deprecated your payload schema, and the application is dead."

"When a B2B SaaS company boasts that it owns no physical servers, it is celebrating an accounting trick: it outsourced its capital expenditure to four publicly traded landlords. The four cloud hyperscalers (Amazon, Microsoft, Alphabet, and Meta) guided to roughly $700,000,000,000 in aggregate capital expenditure for 2026."

"Consider an airline that leases every aircraft from a financing consortium. It owns zero aeroplanes. Its balance sheet carries no aluminium and no jet engines."

I was expecting the whole time I was reading this to hear, "But with AI, ...". For example, "But with AI, AI can refactor dependencies so the database keeps responding, and the cost of human software engineers can be removed."

Weird that that didn't happen.

AI software failure modes, according to Kate Meyer.

"In 2026, most software companies have handed their engineers AI with the instructions to deliver more, faster."

"New AI coding failure modes including codebase erosion (from the explosion of new code), increasing token cost (as more complex codebases are harder to maintain), and comprehension debt (where engineers don't understand how the code works). Most immediately, AI coding speeds up code generation and is creating a review bottleneck."

"In the worst case engineers will generate code and merge it in sight unseen with a Google style LGTM. The codebase doesn't immediately fail, but erodes and bloats."

LGTM stands for "Looks Good To Me". Or is it "Loki, Grafana, Tempo, Mimir"? Or is it "Let"s Get This Merged"? Or is it "Let"s Gamble, Try Merging"?

"What persists isn't the best, it's whatever doesn't get filtered out. Companies are complex systems with many failure points beyond software. Past the point of avoiding AI failures the pressure to adapt falls off quickly and in fact overhauling to best practices has costs and pressures against it. So the new normal won't be across the board best practices, but more mundane. Using this we can review failures and make almost boring predictions about what will become the new normal for the software industry. Depending on the company and the work different failures will be hit first."

"Bad AI code reaching production." "Ironically the CI/CD systems might get slower the exact moment we want them to be faster to match AI speed."

"Too many agent PRs."

("PRs" means "pull requests", requests to merge new code into the main branch.)

"Comprehension debt. Code remains the source of truth and so new ways of understanding it will appear." "Tooling or AI is used to explain how the code works."

"The missing junior engineers."

"Runaway token costs." "To reduce runaway token costs, using local, cheap, and expensive AI lab models together will become common."

"Code bloat." "New pruning pipelines or skills/tools will be made entirely around shrinking the codebase."

"Security." "The AI instigated security crisis will result in more standard modularization, containerization, and sandboxing to reduce the blast radius when things go wrong along with some form of automatic preemptive self-attacking by AI."

"Where the Market Goes. Things that do not harmonize with AI coding will move out in favor of those that do harmonize with AI."

For example, languages with slow compile times or high token costs will be abandoned in favor of other languages, and typed languages have an advantage which we see with accelerated adoption of TypeScript over Javascript.

My commentary: It'll be interesting to see how other software organizations adapt to the new AI reality. Where I work, we've gone all-in on generating code and merging it in sight unseen. I know because my boss, who has no computer science background whatsoever (his background is in marketing) does more commits to the codebase than me and is routinely angry at me for committing too little and being too slow, and he admits he doesn't understand any of the generated code. My dev lead says he is on track to commit 1 million lines of code in 2026, which is about as much as 30 human software engineers, and it's physically impossible for him to have read -- even skimmed through, let alone carefully proofread -- that much code -- that's about 3,800 lines of code per day. Or to put another way, we're a "vibe coding" shop -- "vibe coding", as originally defined by Andrej Karpathy, is "where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." "I 'Accept All' always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it."

So far, because the AI models have gotten smarter than humans, nothing bad has happened, nothing beyond the usual bugs that happened when humans wrote all the code. There's somewhat fewer bugs but a lot more code (maybe 30x more?). Here it is claimed this will lead to a "bloat" failure mode, "The codebase doesn't immediately fail, but erodes and bloats." "Cheap AI code results in much more code quickly which can degrade code bases over time and results in increasing costs." I guess I will see if that's what actually happens. The counterargument (and the gamble we're making) is that future, smarter AI models will be able to fix whatever technical debt gets accumulated by today's AI models.

"Decompiling a Nintendo 64 game in 84 days".

"Snowboard Kids was compiled with IDO 5.3 rather than the GCC 2.7.2 compiler used by Snowboard Kids 2."

"Most programmers will be familiar with GCC. It is a widely used open-source compiler still in active development today. IDO, on the other hand, was a proprietary compiler developed by SGI, whose own story is closely entwined with that of the Nintendo 64. Its source was not available, and its original development environment was tied to obsolete SGI hardware and software. To use and properly understand it today, the decompilation community has had to reverse-engineer and decompile parts of the compiler toolchain as well as statically recompile the IDO 5.3 and 7.1 suites to run on modern hardware. That closed history makes IDO harder to reason about than an open compiler such as GCC."

"IDO splits optimisation and code generation across several different passes, transforming code quite aggressively along the way. Tiny changes to the C can then ripple through those passes and produce a completely different register allocation."

"The community has made great strides in understanding IDO and its quirks, but this remains more of an art than a science. LLMs and I are not particularly good at reproducing its output. The usual workflow, for both me and the agents, was to figure out what a function did and then write C that approximated that purpose. From there, small tweaks assisted by the permuter could catch any remaining differences. But you can't permute yourself into a match in all cases, particularly when the underlying structure is wrong. IDO's behaviour made this workflow far less predictable."

"IDO is weird, but it is often weird in recurring ways. Successfully matching one function could reveal a compiler quirk that applied to many others. Codex has become better at carrying lessons between tasks through features such as local memories. To make those lessons available beyond a single agent, I prompted agents to record observed IDO behaviour in a DECOMPILATION_LEARNINGS.md file.