Full Episode Transcript

Hello and welcome to Turing's Torch. It's Friday. Sunny in London, if you're inclined to notice such things. This week, we find ourselves once again wading through the usual torrent of pronouncements regarding artificial intelligence. It's a familiar field, isn't it? Amidst the clamour, it's worth recalling Alan Turing's rather elegant observation. "A computer would deserve to be called intelligent if it could deceive a human into believing that it was human." That, in essence, is the challenge we face today, isn't it? Separating the genuine signal from the pervasive noise. We'll be looking at some of the claims that have emerged over the past seven days. And considering whether they hold up under a modicum of scrutiny. This is Turing's Torch: Artificial Intelligence Weekly — the bits that matter, minus the hype.

Anthropic spent two days in London running a developer showcase called Code with Claude. At the same time another big tech company held its usual glitzy developer show out in California. What we saw in London was not a product release so much as a rehearsal for a different idea about how code gets written. Models were cast as partners that can draft multi‑file changes, sketch tests, and, in demos, author entire pull requests. Someone on stage asked a question and left it hanging: who shipped a pull request last week that was entirely written by one of these systems? The silence said everything. There was obvious excitement about speed and scale, and immediately alongside it a pile of unease about trust and ownership. When vendors describe a model as a developer partner they mean more than the old line‑level autocomplete. They mean a system that synthesises architecture changes, stitches together patches, and proposes tests that could plausibly be merged. That is a useful leap. It replaces drudge work and pattern repetition. It also moves the risk from typing errors to design choices. A function that "looks reasonable" may still be wrong. It might compile and pass a local test suite and nevertheless embed a subtle race condition. It might misuse a cryptographic primitive. It might reproduce code whose licence forbids the reuse you just accepted. Demos show potential, not the procedures you need to keep that potential safe in production. The uncomfortable question is not whether a model can draft a pull request. The question is whether that pull request survives the full life of a software project. Software is written once and then fiddled with forever. Features are maintained, rebased, debugged and handed between teams. Production readiness demands reproducibility, clear provenance, test coverage that survives refactors, and audit trails that explain why a line was introduced. If a model authors a change and a bug appears three months later, who is accountable? Who validates licence claims or checks for cryptographic misuse? If those checks are manual, any time saved on the first pass evaporates in later review and remediation. There are practical failure modes that rarely make it past a polished stage demo. Models hallucinate unfamiliar APIs. They invent parameters that never existed. They suggest dependencies that live three levels down an ecosystem's dependency tree, which can look neat on paper. And collapse into operational debt when those transient packages break. They bake in inefficiencies and anti‑patterns that teams must later unlearn. They are often better at scaffolding than at making trade‑offs about observability, testability, or corporate‑standard error handling. For organisations with strict CI and security scans, an artificial intelligence‑generated change needs to pass those systems without adding brittle or untested behaviour. Watch not whether models can produce pull requests, but whether those pull requests survive the full pipeline week after week. There is another dimension at play. Vendors are not only trying to sell a tool. They are trying to shape what engineering managers expect from their teams. If Claude or another assistant becomes positioned as central to the workflow, the vendor nudges integration and hiring decisions in its favour. Companies that convince managers model‑assisted development is safe will capture telemetry, dictate workflows, and influence recruiting criteria. That matters for money and control. Firms will invest in platforms that promise faster delivery or headcount reduction. Those platforms will aggregate data and set defaults. If liability for subtle faults is unclear, firms will either over‑insure, slow projects with extra review, or accept fragility in the hope of speed. None of those outcomes is ideal if the technology has not proved itself at scale. What we have seen repeatedly across the industry is demo confidence trumping operational evidence. A flashy display of a model solving a task makes headlines. The hard questions are about integration. How will a model fit into continuous integration pipelines? How will generated changes be traced back to a training provenance and licence record? How do defect rates compare, over months, between model‑assisted code and human‑only code? Those operational answers will determine whether these systems are productivity multipliers or expensive sources of hidden technical debt. If you want the blunt summary: declare the death of debugging at your peril. Debugging has a stubborn habit of surviving each prediction of obsolescence. The sensible checklist is unglamorous. Look for reproducible reductions in bug churn over multiple releases. Demand transparent provenance for any generated code. Require integration with existing test and security tooling. Make liability explicit in contracts and clarify licence provenance. Vendors can provide impressive demos. Organisations should treat those demos as previews of a workflow, not as handbooks. The real experiment is whether teams can maintain accountability when machines start drafting commits. While developers were being tempted into new workflows, a very different kind of theatre played out in court. The Musk‑versus‑Altman trial ended its run with lawyers less focused on patents and roadmaps and more on credibility. Rather than arguing in technical detail, both sides tried to convince a jury which principal was telling the truth. Sam Altman found himself defending business ties and emails. Elon Musk was portrayed as a figure driven by power. The trial became a contest of character, not architecture diagrams. That shift matters because courts and juries work on human things: motive, opportunity, consistent behaviour, corroborating evidence. Email trails, witness demeanour and contemporaneous texts matter more there than benchmark scores. You can have the best technical explanation in the world, and still lose a courtroom battle if the human narrative does not hold up. For a sector like artificial intelligence, where large companies sit at the intersection of markets, media and public safety, those findings have real consequences. A ruling that a founder abused their position or misrepresented ties could ripple across boardrooms and investor desks. It could reshuffle who decides which projects scale, which safety mechanisms are prioritised, and which commercial partners are trusted. The legal fallout is practical. Juries can order damages or injunctive relief that rewrites corporate relationships. Boards may be forced to change governance structures. Investors and customers will notice and adjust exposures. For employees, the result may mean a change of leadership and strategy mid‑project. For regulators, a high‑profile courtroom showdown becomes a data point in favour of clearer rules about conflicts of interest and disclosure. But a jury is not a technical arbiter. It cannot certify that a company has effective safety culture, or prescribe audit standards the sector needs. That is a mismatch between the tools of law and the requirements of technical governance. There is also a broader pattern here. Personalised conflict often displaces structural debate. We watched a courtroom theatre in which reputations were litigated instead of foundational questions about oversight, verification, or industry standards. Personal accountability matters, very much. Yet determining who misled whom in a particular negotiation will not on its own build the institutions necessary to audit powerful systems. Boards, regulators and standard‑setting bodies must do the work the trial cannot. A public trial can feel like a catharsis. It can also be a distraction. It tells us who a jury believed. It does not, however, settle how models should be audited, how companies should document provenance, or how risk should be shared across ecosystems. Expect fallout in boardrooms and perhaps in committee rooms. Expect headlines. Do not expect a neat transfer of technical authority or a comprehensive governance fix. The same tension between capability and governance surfaced in a recent session where clinicians and researchers considered what happens when language models enter hospitals. The models in question can generate clinical text: notes, suggested diagnoses, discharge letters, explanations for patients, even triage prompts. In the lab you can measure accuracy against curated test sets. You can tune prompts and celebrate incremental improvement. In clinical practice those measurements do not capture the elements that make medicine lawful and safe. Hallucination in clinical models is not merely an academic complaint. A confident but false assertion in a novel might be amusing. In medicine it can be lethal. But hallucination is a symptom, not the underlying disease. It points to governance gaps. It highlights missing audit trails, ambiguous consent, and opaque reasoning that clinicians cannot meaningfully inspect. You cannot paper over those gaps with scale alone or a larger model. That raises immediate questions of responsibility. If an artificial intelligence system used for triage misses early sepsis signs, who answers for the harm? If a portal assistant omits a drug allergy in discharge instructions, who pays for the resulting costs? These are financial and reputational liabilities. They also cut to patients' trust. Health care sits inside regulation, insurance markets, professional standards and ethical duties. Deployments that ignore those realities will create more problems than they solve. There are distributional effects too. Models trained on datasets that under‑represent certain populations will provide worse suggestions for those groups. A system prioritised for commercial reasons will optimise for profitability, not equitable outcomes. The people who typically bridge this gap are clinicians already stretched thin. Asking a doctor to sign off on a recommendation from a system they cannot inspect is to saddle them with legal. And moral responsibility without equipping them for the task. What will make a difference is not bigger models but boring, administrative work. Operational benchmarks must reflect clinical reality rather than curated test sets. Independent audits should probe training provenance and deployment logs. Legal frameworks should allocate responsibility clearly so hospitals, vendors and clinicians understand liabilities. Security matters too. Patient records are attractive targets. A rush to deploy without the infrastructure to protect data invites breaches. Hospitals are not laboratories. They are legal entities with budgets, unions, regulators and patients who expect recourse when things go wrong. The sensible response is to insist that any model deployed in clinical care comes with uneventful infrastructure. Outcome‑linked benchmarks, transparent funding and ownership, auditable provenance, and contracts that make responsibility explicit. The models are useful and tempting. Usefulness must not become an excuse to outsource oversight or accelerate harm. A related set of questions appears in the privacy corner of machine learning. Organisations are experimenting with federated unlearning. The phrase promises a tidy idea: a user asks to be forgotten and the shared model is adjusted without centralising raw data. On the surface it is appealing. It sounds like deletion without disaster. In practice it is mechanically delicate and strategically risky. Federated learning trains models across many devices so individual data never leaves its origin. Federated unlearning seeks to reverse a specific contribution without retraining on the entire corpus. Engineers aim to surgically nudge model parameters to remove a client's influence. To do that, you must attribute which parameters were affected by which client updates. You must alter those parameters without breaking useful

Well, another week, another deluge of pronouncements. It's in these moments of considerable… noise, that a clear head becomes rather more valuable than usual. For those who prefer their artificial intelligence news delivered with a degree of measured consideration. And perhaps a touch less hyperbole, you can find our daily briefing at jonathan-harris dot online. One email, no embellishment. And before we conclude, a brief word about my own small contribution to the wider conversation. My book, "The Future of Government: Leveraging artificial intelligence to Enhance Services and Safeguard Information," is available 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.