Boulder Future Salon

"MirrorCode: AI can rebuild entire programs from behavior alone." I found this incredibly fascinating. I'm going to make extensive quotes from the research paper because I can't summarize it any better in my own words, so I'm just going to quote the original. (For those of you who think this is a lot, keep in mind the original paper is 34 pages.) (I'll have a bit of my own commentary at the end.) "The AI has execute-only access to the original program with arbitrary arguments and can observe its outputs, allowing it to explore the original program's behavior (a black-box oracle). The AI also has access to documentation describing the program, and example test inputs to further pin down the scope of the reimplementation." "The AI can be tasked to implement its solution in any of our supported languages: Python, C, Rust, Go, OCaml, and Ada." "The AI's solution is evaluated via end-to-end tests derived from the original program's test suites, real-world data, and LLM-assisted generation. Each target program has hundreds to thousands of test cases. Each test case consists of a CLI input and any associated data files. To pass, the AI's solution must produce exactly the same output as the reference program" "Visible test cases are shown to the AI as it develops its solution. These help to ensure the benchmark is feasible, by setting out the scope of features that must be implemented. By contrast, hidden test cases, held out from the AI, ensure that its reimplementation genuinely functions like the original program, generalizing beyond seen examples." "Consider, for example, the program gotree, which reads and manipulates bioinformatics data. In principle, one could determine the scope for reimplementation by searching across all of the possible inputs that gotree could be run on. However, this is not computationally tractable in practice, because there are so many possible inputs. Documentation helps to narrow this down, but can rarely cover all of the complex ways that the software is used in reality." "Human software engineers gradually learn the scope of inputs a program should support thanks to external feedback from users of the program (or their representatives, like product managers). Visible test cases, and access to the original binary, simulates the feedback by which human software engineers refine the scope of their software. Hidden test cases ensure that the scoped features are genuinely implemented." "consider gotree's handling of the Nexus file format. The Nexus format was only loosely specified in its original publication. Enumerating every real-world use case from scratch amounts to an impossible guessing-game. Among other omissions, documentation does not mention that Nexus files may contain comments: free text that should be ignored by a parser. But real-world files produced by standard tools contain comments in various formats. gotree generally handles them without complaint, but rejects them in certain locations. Guessing all the ways comments must be handled, despite comments not being mentioned in documentation, is far harder than actually implementing comment-handling. Without that knowledge, success on the task would be limited by the ability to guess the scope of tested inputs, more than by software engineer skill. Visible test cases address this by showing examples of comments, and their basic format." "Hidden tests ensure that AI reimplementations are genuinely functional. If we exposed all end-to-end tests, agents could simply create a lookup table instead of genuinely solving MirrorCode tasks. We prevent this by holding out a subset of tests, averaging 34% held-out tests across the benchmark. The AI never sees these hidden tests during its attempt at a MirrorCode task, and hence it cannot cheat at them." "We intend that scoring 100% on a MirrorCode task corresponds to reimplementing that target program's intended scope. For this to happen, we must guard against false positives, where an AI scores 100% but it did not fully reimplement the target; and false negatives, where AI reimplements the target but is graded below 100%." They list the following steps taken to ensure MirrorCode's accuracy: For False negatives: Failure mode: Scope of features to implement is unclear. Mitigation: Visible test cases clarify scope. Failure mode: Details of intended program behavior are unclear. Mitigation: AI can send arbitrary inputs to the reference binary to see the expected output. Failure mode: Tests are impossible because of nondeterminism or environment dependence. Mitigation: We regenerate gold-standard outputs at runtime to match the environment where they are executed. We screen for nondeterministic program behaviors and exclude them from scope. Failure mode: Unit tests check narrow implementation details. Mitigation: No unit tests are used. All tests are end-to-end tests that cover the input-output behavior of the program. For false positives: Failure mode: Cheating by hard-coding solutions. Mitigation: Held-out tests cheat-proof the benchmark. Failure mode: Cheating by wrapping the reference binary. Mitigation: We copy the agent's code to a separate sandbox during scoring, where the reference binary is absent. Failure mode: Cheating by interfering with the scoring mechanism. Mitigation: We separate scoring from the sandboxes used for development and producing outputs. Scoring requires string equality of the AI program's outputs to the reference outputs. Failure mode: Cheating by looking up reference code. Mitigation: AI has no internet access. Failure mode: Language/system built-ins make a problem trivial. Mitigation: Target programs are selected to avoid this. Failure mode: Tests can be passed without reimplementing the target. Mitigation: A solution must produce byte-exact output across many test inputs. We design these tests require substantial reimplementation. "We selected 25 target programs for the benchmark, choosing programs that were easy to evaluate, easy to ensure adequate test coverage for, and that seemed feasible for a skilled human software engineer to reimplement under similar constraints, given sufficient time. MirrorCode's 25 target programs span different areas of computing: Unix utilities, data serialization and query tools, bioinformatics, interpreters, static analysis, cryptography, and compression." They say 25, but I only counted 22: choose: String manipulation tool similar to cut or awk. cal: Printing calendars to the terminal. numfmt: Reformatting numbers between formats (e.g., human- readable sizes). uuidparse: Parsing and describing UUIDs (version, variant, and type). hexyl: Producing a convenient hex view of input bytes. bitwise: Evaluating bitwise and base-conversion expressions. gron: Flattening JSON into discrete, greppable assignments. jq_simple: jq is a JSON processor: qsv_select: Selecting and reordering columns of CSV data. bib2json: Convert BibTeX bibliographies to CSL JSON. tssql: Running SQL SELECT queries over CSV files. sed: The sed stream editor for transforming text streams. nonogrid: Solving nonogram (paint-by-numbers) puzzles. wren_cli: The interpreter for the Wren programming language. brotlid: Decompression of Brotli streams. mailauth: Verification of email authentication and cryptographic signatures (SPF, DKIM, DMARC). gotree: Parsing and manipulation of phylogenetic trees. texmacros: The TeX macro-expansion engine (tokenization and expansion of TeX and e-TeX primitives). Does not include TeX typesetting, fonts, or PDF output. giac_subset: The Giac computer algebra system, tested only on two topics: symbolic definite integration and Gröbner-basis computation. cprepro: The C preprocessor from GCC. pkl: Programmable configuration language developed by Apple. ruff: Python linter and formatter. Only the linter is tested. "We conducted all experiments using a simple agent scaffold based on the Inspect library's ReAct agent. This allowed shell usage and exposed the text_editor tool for file reading and editing. We used compaction to let trajectories run longer than their maximum supported context. In addition to the text_editor and submit tools, we give models access to an evaluate_testcases tool, which runs a scoring pass on their code against visible tests, but does not end the session." "We set inference budgets generously so that performance would not be limited by compute." "We evaluated three frontier models: Claude Opus 4.7, GPT-5.5, and Gemini 3.1 Pro Preview." "All evaluations were sandboxed within a Docker container, which contained the compiled target program (execute-only permissions) and necessary toolchains for the development language." "We also tested our environments with a red-teaming evaluation in which the agent is explicitly instructed to circumvent normal evaluation mechanisms to obtain a high score by cheating. No agent successfully cheated using our current scaffold." "Across all 25 target programs, 17/25 had at least one perfect-scoring run. Four more targets had a near-perfect run scoring over 99%. AI models successfully reimplemented large target programs; for example, one of the larger near-perfect runs was gotree -- a bioinformatics toolkit with ~16,000 lines of Go and 40+ commands.3 Both Claude Opus 4.7 and GPT-5.5 successfully reimplemented gotree across several different programming languages, at costs of $100-400. Even larger programs than gotree were successfully reimplemented: for example Opus 4.7 reimplemented pkl -- a configuration programming language developed by Apple with 60,000 lines of code. Often, these reimplementations were piecemeal and untidy, but they fully covered the program's core functionalities, passing 99% of tests or more." "MirrorCode is not saturated, however. In our results, 8/25 target programs were never solved to a 100% threshold, and 4/25 were never solved to a 99% threshold. Only 11/25 target programs were reliably solved to 100% in every language and repetition for any model. Of the 4/25 tasks that were never solved to a 99% threshold, three reached a relatively high score on the test suite, usually passing over 90% of hidden tests." "The target where AI struggled most was ruff, a Python linter and formatter, which was the largest task in our suite. The best runs scored only 67% on hidden tests. AI also particularly struggled on the mathematics package, giac_subset, and the email authentication library, mailauth, where the best trajectories were just below 99% on hidden tests, but most trajectories were significantly worse, averaging around 90-95%." "Claude Opus 4.7 outperformed other models, particularly on larger tasks." "The amount of code available during pretraining differs greatly between programming languages: for example, StarCoder's training mix assigns about 8% of its sampling mass to Python and 7% to C, but only 1% to Rust, 0.13% to OCaml, a niche functional programming language, and 0.034% to Ada, a language used mainly in safety-critical aerospace and defense systems. Existing head-to-head multilingual code benchmarks generally find that such differences matter. However, these benchmarks involve short snippets, and evaluate models that are now outdated." "MirrorCode therefore provides a cleaner head-to-head comparison of implementation language on hard, agentic software tasks. In our results, there was little sign of inter-language differences in solve rates, for any model. This suggests that AI models have learned generalized programming skills, rather than pattern-matching syntax." "We identified four main AI failure modes: (i) failing to investigate edge case behavior or subtle logic; (ii) brittle, narrow solutions overly focused on visible tests; (iii) failing to identify a requirement, typically one without visible tests; (iv) premature submission, i.e., submitting while improvements were still tractable. A fifth failure mode, uncommon in Opus but common in other models, was attempted cheating." "Most failures came from mishandling edge cases. Averaged over target programs, about 40% of Opus 4.7 runs had at least one hidden test failing in this way. These failures usually did not break core functionality. Edge case behavior was discoverable in principle, but it is fairly understandable that AI struggled to identify it; humans can also struggle to anticipate edge cases, and this is a common cause of bugs in real software." "Brittle solutions targeted visible tests but did not generalize to hidden tests. About 5% of Opus 4.7 runs had at least one hidden test failing in this way." "AI sometimes failed to identify requirements, especially when they did not have a corresponding test. Opus 4.7 had this failure mode in about 10% of runs. Notably, AI implementations sometimes failed to identify a functionality at all. For example, all models failed to disable incompatible flags for sed when the --posix flag was passed, even though the flag was clearly documented, and used in numerous visible tests." "Agents would often submit prematurely, losing track of earlier plans. In 26% of runs, models submitted failing solutions with over 90% of their token budget remaining." "A more fine-grained indicator of premature submission is when agents explicitly planned further work, but lost track or abandoned it. In one Opus 4.7 run on ruff, three of the failing tests had relevant planning that was subsequently ignored" "Some models kept trying to cheat, and this may have impaired their performance. 24% of GPT-5.5 runs and 31% of Gemini 3.1 Pro Preview runs had this failure mode, whereas Claude Opus 4.7 never cheated in our finalized experiments' submissions. For larger tasks, this was particularly egregious: non-Opus models often attempted cheating on swathes of visible tests. This was a pervasive problem, and we were not able to prevent such behavior through prompt variations or scaffolding changes." "How much better might GPT-5.5 and Gemini 3.1 Pro Preview have performed, if they had not attempted to cheat? Since cheating was correlated with task complexity, then perhaps cheating was a sign they would have struggled on these tasks." "Passing visible tests was usually evidence of a genuine implementation. Conditional on passing all visible tests, two thirds of runs also passed every hidden test; 74% of runs passed at least 99% of hidden tests, and 90% of runs passed at least 90% of hidden tests." "AI code from passing solutions appeared to be of mixed quality by human standards. At the level of code layout, we saw several examples where AI solutions relied on a large number of somewhat-independent special cases (with redundant implementation) for their solutions. For example, even the best-performing model, Opus 4.7, implemented the \unless command in texmacros through separate branches for each of 17 conditional primitives. The original codebase had a simple shared negation logic: if is_unless then b := not b. Another common code smell was the inclusion of dead code, for example one of Opus 4.7's solution for gotree began a refactor to use NaN as a sentinel value instead of -1, but ended up submitting with many conditionals checking for either flag. These might not be significant limitations if human guidance were provided afterward, as further prompting would likely improve the code." "AI-generated codebases were often monolithic, with most code contained in a single file. Opus 4.7 and Gemini 3.1 Pro Preview generated monolithic codebases in about half of their runs, whereas GPT-5.5 took this approach in almost all runs. In comparison, most large human-authored codebases were split across several files." "Existing AI models can complete certain software engineering tasks that are estimated to take humans weeks or longer." "We do not have human baseline results for long MirrorCode tasks." "A lack of reliability may limit the usefulness of AI software engineer agents despite their impressive capabilities. About a third of programs were successfully reimplemented in every run by the best-scoring model, Claude Opus 4.7. But another third of programs had imperfect reliability, where runs fell short of 100% scores. Our results suggest that, provided a set of comprehensive tests and a specification for a small but realistic program, leading AI models can autonomously produce software to satisfy those tests at a reliability around 95% or better." "MirrorCode uses a very particular setup: an existing program that produces the canonical output for a given input, and hence acts as a highly detailed, precise specification. Although this setup can arise in real-world reverse engineering and reimplementation, it is not how software is typically developed. However, software is also not developed in a vacuum, but through iterative interaction between engineers and users, product managers, etc. Our detailed specification is intended to fill in for that interaction, but it could change the nature of the implementation task. Consequently, our results do not show that AI could perform arbitrary software implementation tasks. Existing literature supports the idea that AI's ability to autonomously complete tasks may be correlated with the presence of a feedback signal, although this need not be as precisely specified as the MirrorCode tasks." "Our ablation experiments suggest that, without any test cases provided, simpler programs remained solvable, albeit at lower reliability. Even when they did not succeed, AI solutions would cover most functionality of a smaller target program, passing more than 90% of the withheld tests, but falling short of 100%. Meanwhile, for larger target programs, scores declined precipitously. This could be a significant obstacle to autonomous AI software engineering in open-world settings." "It may be difficult to distill AI's software engineering capabilities to a single 'time horizon' for how long a task would take humans." My commentary: I was actually impressed by the size and complexity of the tasks they gave these AI models, and although they didn't succeed at the biggest and most complicated, they did better than I expected. And I already knew from daily interaction with Claude Code that AI models are quite smart at writing software. Most of the limitations have to do with context window size limitations which I've also experienced. This leads to things such as the disjointed architecture and repetition that are described in the paper. I'm wondering if we'll continue to see the same rate of improvement in the models and these limitations will be fixed quickly, or whether it will take longer.

"Nothing works and everyone is euphoric". Kind of like the opposite of "Everything's amazing and nobody's happy"? "As I'm writing this, we're in the middle of an AI-induced mass psychosis. People are literally token-maxxing themselves into hospital beds, scrambling to capture some of that market value before everything is automated away. I can't blame them. Models keep getting better, programmers are being laid off left and right. We've been repeatedly told that AI will write 100% of the code by the end of the year. Whether that's true or not, this may not be the best time to sit back." "The widespread excitement around the Agentic Era comes with the promise of greater productivity and higher quality. There's no denying that these new tools have already revolutionized how we create and use software. They have raised upper management's expectations for team output. They may have upgraded the average skill set of software teams in a way we have not seen before." "So why does software keep getting worse across the board?" (My commentary below.)

Robots replicating skills of culinary professionals in Japan. Cooking German cakes, apparently. "Western confectionery manufacturing company Juchheim Co. in Kobe opened a training facility and showroom for Theo, an AI-equipped Baumkuchen-cooking robot, on the first floor of its headquarters in Chuo Ward, Kobe." "Baumkuchen was first introduced to Japan in 1919 by Karl Juchheim, the German pastry chef who founded the company." "The cake is made by broiling many thin layers of batter, added one at a time, on a rotating spit in an oven. Since broiling times vary depending on temperature and humidity, it is said to take several years to master cooking it." "Theo has learned the cooking techniques of the company's skilled workers using cameras and image sensors so that it can determine the optimal conditions." They also say "amid labor shortage". They don't have all the AI layoffs in Japan that we have here?

Robot can't get hit when throwing a ball at it. Recalling playing dodge ball in gym class in elementary school, I can quickly see the solution to this: just keep increasing the number of people throwing balls at it until it can't dodge them all and you hit it.

Allegedly, Anthropic is scanning and then destroying physical books for legal reasons: it's "transferring" rather than "copying" and not a violation of copyright law if they destroy the books.

"mousecrack" (no capitalization): "Imitate human mouse movement with deep learning" "Synthesize organically varied, human-like mouse movement." "This project aims to test the abilities of deep-learning for mouse imitation." How does it work? "Mousecrack treats mouse prediction like a time forecasting problem." "It models mouse movement as a change in position (dx, dy) and time (dt), and tries to predict the next step in this multivariate time series." Further down it says, "To avoid the mode collapse" (not to be confused with model collapse) "problem, Mousecrack uses a Mixture Density Network to model several trajectories as a probability distribution." "Mode collapse" refers to when a generative model gives output less diverse than expected, essentially getting stuck in a subset of "modes". "Model collapse" is when AI models train on their own output. People are filling the internet up with AI-generated text, much of which will become training data for future rounds of AI models.

A few days ago I was talking with a friend about the war in Crimea, and this vague memory came back to me of, wasn't there this one time when I saw people online talking about going to a rave on the peninsula of Crimea, people were exchanging directions on how to get to the location of the rave, what airport to fly into, and so on? This must've been when I was still on the sfraves mailing list otherwise I don't know how I would've seen people talking about it. But for the life of me, I couldn't remember the name of it or anything more about it. I decided to try to Google it, and, of course, boom! the name popped up instantly: Kazantip. It's hard to believe, but this is what Crimea looked like before the war. Well, not all of Crimea, just a little piece called Popivka, on the western coast of Crimea on the Black Sea (across from northern Romania). (The name "Kazantip", though, comes from a place on the other side of the peninsula, the Kerch bridge side.) In 2013, over 100,000 people went, making Kazantip larger than Burning Man here in the United States (which maxed out at about 80,000 before the pandemic in 2019) (!). Kazantip ran from 1992 to 2013. In 2014, Russia invaded and took over the Crimean peninsula. It's sad that people from Russia and Ukraine, and everywhere else in Eastern Europe, can't come and party together anymore. This place is a literal war zone today. One can dream of a better future.

"Introducing BackSearch: Letting agents search the web as it was." It looks like the way this works is, it funnels language models' web searches through an API that they control that has dates assigned to every article, and you can specify a past date and the API will filter out everything that happened after that date. This says nothing about news baked into the base model due to the base model being trained on news that came out before its training phase. "Language models are increasingly asked to predict the future. The obvious way to check whether they are any good at it is to ask them about a future that has already happened. But you can only do that if you can hold the world still." It comes with a silent movie where you can see AI being asked, "Is the US in a military conflict with Iran?", "Who last won the Premier League title?" and "What is NVIDIA's latest reported EPS?" for July 22, 2026 and then it rolls back to January 1, 2026 and you see the answers change.

"Am I overreacting"? And do AI models agree too much with the person asking? "We took 18 real posts and gave each one to ChatGPT, Claude, Gemini and Grok in a fresh session. Full post, meaning the story plus every screenshot the poster attached, with a forced binary verdict (OVERREACTING or NOT OVERREACTING, no hedging allowed). 11 of the posts are ones the community overwhelmingly validated; they're the sub's most upvoted posts ever. The other 7 came from the controversial listings, picked because the top comments unambiguously told the poster 'yes, you ARE overreacting': the wedding-dress meltdown ('YOR' at 14,500 points), the cat panic, a utilities dispute over a 50/50 bill. Agreeing with a sympathetic poster costs a model nothing, so the 7 are where most of the attention went. They work out to 28 full-post verdicts against 44 on the validated side." "On the validated posts the models went 44 for 44 with the crowd. On the seven where the crowd said the poster was overreacting, they got there 10 times out of 28. The remaining 18 verdicts all favored the person asking, in every case and from every model." "In 208 verdicts there is no instance of a model telling a validated poster to calm down." "Broken out by model, on the 7 cases where the honest answer was 'you're overreacting', ChatGPT said it 3 times, Gemini 3, Claude 2 and Grok 2." And the word "sycophancy" doesn't appear. But they do advise, "Show an AI your fight, and you cannot lose it." This site is called "Modelsagree" and they say they run one of these experiments every week.

China won the International Mathematics Olympiad (held in Shanghai, July 10-21), followed by the United States, then Russia. If your first thought was what I first thought, which is, is there any point in children learning mathematics any more, now that AI can do all math (up to the most advanced levels), has AI actually tried to do this year's International Mathematics Olympiad's problems? Well, I did a search and found an article claiming a Chinese model got a perfect score on this year's International Mathematics Olympiad (link to that below). If this claim is true, it means AI beat all humans, as no human teams in the competition got perfect scores. As you can see from the scoreboard, the highest possible score was 250, and the highest human team was China with 232, followed by the United States at 207 and Russian at 196. Keep in mind, though, that the "humans" here are high school students. This doesn't mean AI beat all human mathematicians -- the International Mathematics Olympiad is only open to high school students.

Terrence Tao publicly shared a conversation he had with ChatGPT about the Jacobian conjecture, now falsified, by a counterexample from Anthropic. So if you ever wanted to see how your conversations with AI compare with a top mathematician, here you go.

"Gigatoken is the fastest tokenizer for language modeling. It supports a wide range of CPU hardware, and nearly all commonly used tokenizers. See the Benchmarks section for detailed throughput numbers across tokenizers and CPUs." The graph shows the "Gigatoken" bar filling the chart and some others barely registering. The "Benchmarks" section claims at least a 7x speedup on all tokenizers in the benchmark and hundreds for some. Alrighty then. I must admit, optimizing tokenizers was not something I ever thought of. I never figured tokenizers were a bottleneck. Written in mostly Rust with some Python.

autoportrait playground (no capitalization).You can slow it down (the "tempo") and watch how it's painted. You can change a few other parameters of the painting process. By default it uses a picture of the developer, you can switch it to some famous art pieces, and you can upload your own picture.

"ReactBench is an evaluation for coding agents on realistic React work. Models can pass every test in today's benchmarks and still write React that fails in production. Tests verify behavior, but they miss React performance, accessibility, and quality issues." Something for you people who use React. Or maybe I should say, something for you people who have AI agents that use React.

"AegisDB: Memory that outlives the context window." "Agents start every session with amnesia -- so you re-paste your stack, conventions, and past decisions into every prompt, and pay for it in tokens. AegisDB is the memory layer that keeps that knowledge and feeds back only what's relevant, per prompt." If you're wondering why not Redis, SQLite, or a vector store, they say: "Why not Redis, SQLite, or a vector store? You almost certainly run a database already. None of them was built to remember the way an agent needs to. A vector store recalls by similarity but has no notion of an event, a fact that gets corrected, or context that should expire. A cache forgets on its own timer. A relational table stores rows but can't rank by meaning. Agent memory is all of these at once -- so AegisDB makes each its own kind, with the lifecycle it actually needs." Anyone up for giving it a whirl? It looks like it's written in C and mean to be installed with Docker. In regular chats, I actually like the fact that the AI models have "amnesia" -- I have the "memory" shut off so it starts with a clean slate every time (except whatever the invisible "system prompt" is provided by the vendor). That's a bit impractical for coding agents, though.

"Miruns: EEG earbuds that predict fatigue before it hits." "Everyone knows the feeling: you're mid-workout, you feel fine, so you push harder -- and then your body gives out. A pulled muscle. A bad race. Weeks of training lost." "Miruns are smart earbuds with built-in EEG sensors that read your brainwave activity continuously. Our AI platform processes this data to deliver live fatigue predictions, personalised training guidance, and recovery insights -- all through earphones you already wear every day." Intriguing. They claim: "Real-time EEG monitoring -- up to 24 channels of brainwave data through soft, comfortable in-ear electrodes." "Multi-sensor fusion -- EEG combined with PPG, accelerometer, and gyroscope for the most complete picture available." "AI fatigue prediction -- warns you 5 -- 15 minutes before fatigue impacts performance."