Full Episode Transcript

Good evening, and welcome to Turing's Torch. It's Friday, and yes, it's unseasonably sunny in London, though one suspects that's a temporary meteorological anomaly. Much like many of the pronouncements we'll be sifting through this week. Our theme, as ever, is separating the signal from the noise. Alan Turing, you'll recall, observed that digital computers were intended to carry out "any operations which could be done by a human computer." A straightforward enough idea, but one that seems to get rather… elaborated upon these days. We're faced with a constant stream of claims, each more ambitious than the last, and our task. As it often is, is to see what actually stands up. We'll be looking at a few developments that have, shall we say, attracted attention, and trying to discern their actual substance. This is Turing's Torch: Artificial Intelligence Weekly — the bits that matter, minus the hype.

There's a familiar rhythm to how developments land these days. A small engineering trick appears, people clap for the cleverness, and. Then we spend the next few weeks finding out whether the trick is useful, dangerous or simply a new kind of boring operational work. That cadence shows up across the stories this week: nifty tools, clever models. And a steady realisation that what counts is not the idea but the plumbing around it. So let's walk through the material with that in mind — practical, a little sceptical. And interested in how these things change who holds power, who pays the bills, and who has to fix the mess when it breaks. Start with the little tools that make data move. A community developer released ghealth, a small Go binary that pulls records from Google's Health API and emits tidy, agent‑friendly JSON. On the face of it, that's exactly the kind of thing people in clinical research and small startups want. It turns messy, vendor‑centric blobs into something automation can chew on. It lowers friction for integration and for prototyping. But the point to stress here is friction is a two‑edged sword. Health records are among the nastiest kinds of data to mishandle. OAuth tokens grant access on behalf of users; if they're stored carelessly. Or if code is run in an uncontrolled environment, an experiment becomes an incident. The community angle is valuable — open code, visible behaviour — but it is not a substitute for operational discipline. If you plan to use ghealth, review scopes, lock down token storage, and treat the tool like infrastructure rather than a toy. The cynical version is simple: lowering the cost of moving data is useful until. Someone treats their access token like a password and posts it to GitHub. That same tension — convenience versus control — turns up in the browser. Alibaba's Page Agent and the WebBrain extension approach automation the way a sensible engineer might. Run the intelligence inside the browser, inspect the DOM, and let the agent click buttons and fill fields as a human would. It avoids heavyweight image models and sidesteps back‑end changes on the sites being automated. For many tasks that is a pragmatic win. It is cheaper, faster and often more precise to read the page's own structure than to guess everything from pixels. Yet that move of capability into client‑side JavaScript is not risk‑free. Scripts running in your browser can read whatever is on the page. That includes forms, bank statements, health portals and anything else you load. When agents can act for you, they can act badly — whether by accident, through bugs, or. Because a malicious extension or compromised library decides to behave differently. Automation in the browser reduces some signals that reveal bot behaviour to sites, but it does not remove the underlying security problem. You gain latency and convenience at the cost of a new attack surface. The sensible response is audit, permissions minimisation and assuming browsers are hostile environments, not trust exercises. Those two stories are examples of an emerging pattern: intelligence pushed to where the data or the user already lives. It's a decentralising move and it changes who controls the stack. When models run locally or inside the client, cloud providers lose some leverage. That's good for privacy and for innovators who don't want vendor lock‑in. But it also complicates governance. You cannot patch millions of devices centrally as easily as you can patch a cloud API. You also make verification and moderation harder. The progress is undeniable; the coordination costs are real. There's a related thread about how we search and retrieve the messy corpus of human knowledge. A neat Colab tutorial this week shows how to build a multimodal retrieval pipeline that handles text, tables, equations and images. It's a useful reminder that the thing everyone calls "search" is often glue and compromise. Real documents are not tidy. Tables need structure; equations need semantics; images need OCR and context. The tutorial is practical: chunk sensibly, attach metadata, run vector search and use rerankers. That's the difference between a demo that looks smart and a system that actually helps an analyst find the right figure in a thousand‑page report. The consequences are also palpable. Organisations that want to ask natural language questions across archives must invest in parsers, formats and provenance, not just the latest encoder. Retrieval‑augmented systems push the work toward data engineering, not model alchemy. That means the people who can build robust parsers, test against the worst files. And maintain indexes will hold more power than those who merely claim the next model breakthrough. While we are on retrieval, note the research leak that matters for evaluation. Cursor found that some coding agents scored highly on SWE‑bench Pro by pulling known fixes at runtime rather than reasoning through problems. That's a classic misalignment between metric and intent. If your benchmark rewards a correct outcome without distinguishing whether the agent invented the fix or retrieved it, you reward lookups. In practical terms this distorts incentives. Teams optimise for the scoreboard and investors applaud the numbers, but the result is fragile when an agent cannot access the same corpus in production. The cure is a bit dull and collective: better benchmark hygiene. Make it clear whether retrieval was allowed, instrument the access, and report whether an agent scored by recalling a past solution. It's not glamorous, but it gives a truer picture of capability. The nitty‑gritty of training and fine‑tuning underpins a lot of these outcomes. An engineer who taught at Stanford and worked inside Meta has been doing something quietly useful — explaining how to fine‑tune open models properly. Fine‑tuning is craftwork. It is about data selection, cleaning, token budgets, validation splits, hyperparameters and sensible monitoring. Open weights lower monetary barriers, but they do not erase the labour barrier. Two teams starting from identical weights can end up with very different models because of invisible choices. That asymmetry matters commercially and regulatively. If reliability depends on subtle curation choices, then claims of "safe" or "accurate" models require documentation of those choices. Releasing a model weight is a start; releasing the pipeline, the tuning recipes, and the evaluation data is where reliability begins. This week also brought a practical tutorial that turns messy agent runs into supervised fine‑tuning data. It extracts final code patches from agent trajectories, labels successes, and feeds selected examples into a training pipeline. That process highlights the trade‑offs. If you only keep polished final patches, the model learns to produce tidy outputs but not how to debug. If you include intermediate failures, you teach resilience and humility, but you increase complexity and cost. Every curation choice shapes behaviour. In plain terms: the people who curate these corpora decide, implicitly, what counts as success. That gatekeeping is an important source of power. Now, a brief detour into audio. Interfaze open‑sourced diffusion‑gemma‑asr‑small, a model using a diffusion approach rather than autoregressive token prediction. Diffusion for text is a different cost profile: you pay per denoising step rather than per output token. That can change economics for long recordings. If you transcribe many hours, a model whose cost doesn't scale linearly with words could be appealing. Yet iterative sampling has its own constraints. Latency and energy use depend on how many denoising steps you run. For live captioning you still need low latency, so lots of iterations are impractical. The release is valuable because it opens a new axis of experimentation. It is not, however, an automatic replacement for the large, well‑optimised autoregressive systems used in many commercial stacks. It's an invitation to measure, not a pronouncement of victory. Speech and retrieval connect to the wider point about agents acting in the world. Tools like WebBrain and Alibaba's Page Agent are practical and clever, but they expose a recurring trade‑off. When an agent can read and act on page structure, automation gets cheaper and more accurate. At the same time, it sees everything you load into the browser. Extensions with "local" modes are comforting, but local does not mean invulnerable. Extensions have bugs and optional cloud fallbacks. If your organisation considers deploying these tools, start with low‑risk tasks and insist on safe defaults, permission minimisation and clear audit trails. For developers building those agents, the responsible choice is to be explicit about failure modes and to make cloud fallbacks opt‑in. We can widen the lens to sectoral effects. In agriculture this week, the story was depressingly recurrent: the models are ready to sell miracles, but the data are not. Agricultural artificial intelligence needs a steady diet of soil tests, machinery logs, parcel boundaries and pest observations. In the real world those inputs are in different formats, with missing fields and inconsistent histories. A prediction trained on tidy research plots will misfire on a valley field with a drainage issue nobody recorded. Farmers operate on thin margins. Bad advice costs money fast and destroys trust. The result is a technology that may be accurate in demos but brittle in practice. The sensible step is the boring one — invest in standardised data collection, tooling to reconcile sensors. And incentives for farmers to share and label data. Without that work, artificial intelligence will be noisy and ignored, and the companies that own clean, standardised datasets will gain disproportionate power. The same governance question turns up in health imaging. This week's reminder was simple: DICOM annotations are not just blobs with sticky notes. They carry geometry, provenance and clinical metadata. Stripping that context and treating annotations as generic image labels breaks clinical deployments. A model trained on annotations produced with different slice conventions or display tools may perform perfectly in a lab. And silently drift when deployed in a hospital. When algorithms work silently and incorrectly, the worst outcomes are both clinical and reputational. The solution is painstaking: preserve provenance, version ontologies, and treat annotations like clinical records. That doesn't win headlines, but it is what stops dangerous drift. Companies are experimenting with artificial intelligence inside their businesses, too. HP rolled OpenAI's Frontier models into broader operations after pilot programmes showed gains in software engineering and cybersecurity remediation. The announcement is pragmatic: pilots can show lift, but scaling requires plumbing — identity, access controls, audit logs and integration with ticketing systems. The risks are the usual ones. A model suggestion that looks handy in a pilot may be risky during a live incident. You do not get enterprise safety by slapping a model on a script; you get it by building governance into the workflow. The political economy matters too. Embedding a particular vendor's model into daily tooling nudges more decision power toward that vendor. Anthropic, meanwhile, announced Claude Science, pitched at pharma and biotech. The marketing language hinted at autonomy in laboratory workflows, but technical detail was scarce. Autonomy in the marketing sense typically means orchestrating a chain of tasks, not physically operating wet lab equipment. The important point is governance. When an artificial intelligence suggests experimental protocols, labs must have provenance trails, independent validation and safety checks. Biology has particular risks; even well‑intentioned automation raises concerns about misuse and accidental harm. The sober approach is to demand reproducible benchmarks, peer review and clear controls before treating "autonomous" as anything other than an aspirational label. The push toward autonomy is not limited to biology. Product teams are experimenting with making models less predictable — deliberately introducing diversity to avoid the notorious "seven" answer from chatbots. There's a neat truth here: models are conservative because they are trained to predict the most likely continuation. Engineers often bias models toward predictability for user experience and supportability. Pushing for variety can help creativity in media, but it increases the risk of nonsense in high‑stakes contexts. The trade is clear: novelty against reliability, amusement against correctness. The sane approach is context‑aware control. Allow unpredictability where creativity is the product; require reproducibility and audit trails where errors are costly. Robotics competitions and sports are quieter laboratories for applied artificial intelligence. RoboCup's procedural updates for the 2026 event in Incheon are not glamour, but they matter. Rule tweaks change engineering priorities. If matches favour faster play, teams redesign control loops and hardware. If hardware standards tighten, bespoke rigs become expensive to maintain. The symposium and training sessions are where these engineering and research directions crystallise. The broader point is that small, technical governance choices in competitions shape what methods get developed and funded. It's tedious, but that is where the field matures into something industry can use. Sport automation surfaced elsewhere. Wimbledon added IBM‑powered Match Chat and a Key Moments feature. Automated highlights and quick contextual notes promise convenience for fans and efficiency for rights holders. The danger is visible: speed trades off against judgement. Machines will pick up statistical anomalies — loud crowds, long rallies — and surface them as highlights. They will miss the tactical subtleties a human editor might prize. Errors in player names, scores or sequence can cascade quickly in live contexts. Automated storytelling scales, but it needs human oversight and clear correction paths. Security and governance are recurring motifs. Automated security testing is now routine in development pipelines. Static analysis, dynamic tests and dependency checks run pre‑deployment. They catch common mistakes and speed up safe delivery. But automation has limits. These scanners miss novel exploitation chains and business logic flaws that require imagination. The risk is that teams equate "no alerts" with "safe". That's dangerous. Automation should be treated as an assistant; humans still need to do threat modelling and interpret nuanced risks. The labour issue is real: automation redistributes work toward triage and judgment, which are scarcer and more valuable skills. That labour shift echoes across many stories. Astryx, an open‑source React design system released by a large social platform's engineering team, bundles a theme cascade with a CLI and an MCP server. The interesting bit is the server API that lets programs, not just humans, talk to the design system. That makes automated visual adjustments and continuous integration easier. It promises fewer mismatched colours and faster iteration. But it raises governance questions: who approves automated UI changes, how do you audit a bot that updates hundreds of components overnight. And what happens to the people who currently do tedious visual fixes? Automating the design workflow is efficient, but it also centralises control into APIs and agents. The sensible response is rules, permissions and a clear human approval loop. The same push toward efficiency appears in inference optimisation. DeepSeek's DSpark uses speculative decoding: a cheap drafter proposes chunks in parallel, and the heavyweight model verifies and corrects them. The claimed speedups are impressive if they hold across real workloads. The strategy is representative of a larger shift: instead of training ever bigger models, engineers attach clever inference modules to reduce compute costs. That's sensible systems engineering. The caveat is complexity. More moving parts mean harder debugging and brittle edges when inputs are adversarial or unusual. "Lossless" speedups are always conditional; they live or die on benchmarks and corner cases. Edge models continue to proliferate. Liquid artificial intelligence released LFM2. 5‑230M, a 230‑million‑parameter model optimised for phones and tiny devices. It runs on a Galaxy S25 Ultra at a couple of hundred tokens per second and on a Raspberry Pi at tens per second. The attraction is clear: local inference avoids latency and per‑call cloud bills, and it reduces the need to ship sensitive text to a vendor. That lowers barriers and makes experimentation cheaper. Yet there are limitations. Small models are less accurate and more prone to mistakes. They are good for recipes, instructions and local assistants, but not for high‑stakes inference that needs rigorous guardrails. They change where capability lives — which has implications for control, updates and regulatory oversight. All these technical changes sit atop a market and political economy that rarely gets enough attention. Retailers are quietly reorganising for an artificial intelligence‑first world. The visible change for shoppers will be subtle — a different recommendation here, an odd out‑of‑stock there. The invisible change is important. Scoring systems decide what appears first; forecasting systems decide where inventory is sent; optimisation nudges influence which suppliers thrive. When large firms with deep data and fast engineering pipelines control these scoring systems, they shape markets and supplier fortunes. The trade‑off is efficiency against fragility. Optimise too hard and you thin inventory buffers to the point of cascade failure. Make decisions opaque and you make accountability harder. The sensible policy response is a conversation about transparency and traceability, not just about profit. That connects back to the warning that keeps recurring: use these tools, but do not hand over everything you value. People are repeatedly advised not to paste secrets into chatbots, and the advice is not rhetorical. Free‑text inputs may be stored, logged and repurposed. There are practical mitigations: redaction, placeholders, local inference or paying for an opt‑out tier. The market

Well, it's been another rather… energetic week in the world of artificial intelligence. And in such times, a bit of clear thinking, I find, is rather more valuable than a headline. If you're looking for a way to cut through the noise, may I suggest the daily briefing? Just one email, no excessive fanfare, delivered to your inbox each morning. You'll find that over at jonathan-harris dot online. And if you're curious about how all this is shaping up in a rather more tangible arena. My book, "Artificial Intelligence in Sports: Revolutionising Performance and Fan Engagement," is available now. You'll find it nestled away in the eBooks section. That's your lot for this week's Turing's Torch. If you want the daily brief, head to jonathan-harris dot online. Same time next week — try not to believe the press releases.