Full Episode Transcript

Well, hello again. It's Friday, and the forecast, for what it's worth, suggests it's partly cloudy in London. Another week, another deluge of pronouncements from the world of artificial intelligence. It's enough to make one recall Alan Turing's rather sensible observation that "The search for new techniques. Must be regarded as carried out by the human community as a whole, rather than by individuals." A useful reminder, I find, particularly when trying to sift through the sheer volume of what's presented as groundbreaking. This week, we're going to attempt to do just that: separate the signal from the noise. We'll look at a few of the more… persistent claims, and see if they stand up to a moment's scrutiny. This is Turing's Torch: Artificial Intelligence Weekly — the bits that matter, minus the hype.

On a Friday not so long ago a software team did something refreshingly unshowy. Every week, about twenty people joined a call, someone shared their screen and they built an artificial intelligence agent together. No slides. No rehearsed demo. Just live typing, choices aired and decisions made in real time. What they were doing was simple to describe. They stitched together instructions, API calls and control logic to solve a task. The novelty wasn't the technology itself. It was the format. Live coding exposes the messy decisions that polished presentations hide. Which connector integrates reliably? How do you handle rate limits? Which errors can you tolerate for a quick ship? Those gritty answers turn a junior engineer into a useful one far faster than any polished walkthrough. That format matters now because the pace of development has shortened the useful half‑life of documentation. Written guides trail behind practical reality. Curated examples are optimized to illustrate concepts, not to survive the ugly corners of production. A short, recurring session where the team solves real problems together compresses onboarding, spreads tacit knowledge, and prevents expertise from nesting inside a single person's head. Companies that measure success by deployment, not by presentation, will see the benefit in product velocity and reduced risk. It also creates a few governance puzzles. Who decides what gets built each week? How do you preserve the work afterwards so it's discoverable and reusable? Recorded video is merely a start. Searchable snippets with context are more useful. And there are access questions — what permissions are you comfortable granting in a shared room? Who polices intellectual property and data handling when experiments happen on camera? People enjoy a lively build, but showmanship can teach shortcuts rather than sound engineering. What that ritual really attempts is institutionalising awkwardness. It celebrates imperfect work and rapid iteration. That's where learning lives, but it's also where bad practice can hide. If you try it, be deliberate about agenda curation, how artefacts are archived, and what safety checks guard production credentials. Frequency sometimes beats polish, provided you install sensible guardrails. If teams adopt those sessions without governance they will scale fragility. But done well, this practice trades theatrical launch events for resilient, distributed capability. Meanwhile, in a convention centre in San Jose, engineers spent a couple of days talking about the obvious and the easily ignored. They called it physical artificial intelligence. The phrase means machines that sense the world and act within it. The conversation there was about motors, wiring looms and the fact gravity is stubborn. Physical systems bring another pile of problems compared with purely cloud software. Sensors misread, latency appears between perception and actuation, batteries wear out, connectors loosen and motors overheat. Software can be patched remotely; a gearbox cannot. Integration is an operations problem with line items in maintenance schedules and spare‑parts budgets. What looks clever onstage will not be a product until it survives routine shifts for months, not minutes. Where money flows is instructive. Capital and regulation follow systems that work reliably, not the most dazzling demos. Firms promising fleets of delivery robots or autonomous forklifts will have to demonstrate thousands of hours of dependable operation. Liability lives at the margins: who pays when an arm drops a load? Who certifies safety when sensors fail? Investors will watch repeatability. Suppliers will ask for standards. Regulators will demand auditability. The glamour of demo reels gives way to the unglamorous arithmetic of repair costs and downtime. There is a cultural friction here too. Software‑first teams can under‑estimate supply‑chain realities. Designing for ease of repair, for standardised connectors and for maintainable spares is distinctly unglamorous. But it is precisely those choices that determine whether an automation programme is productive or merely expensive. If you want to know where artificial intelligence is actually useful in industry, watch the people who specialise in wiring looms and test rigs as closely as you watch the researchers. Back in the world of property technology there's a quiet correction underway. Building a compelling property app is not mainly about a pretty interface. The heavy lifting is the plumbing no one likes to show. Integrating multiple listing feeds, payment rails and document workflows demands work that looks nothing like a demo. MLS feeds do not present as one tidy API. They ship in different schemas, update schedules and licensing arrangements. Payment rails require reconciliation, escrow handling and compliance with banking rules that vary by state. Document workflows must preserve chain‑of‑custody and audit trails. Behind every smooth screen is a tangle of data transforms, scheduled jobs and legal constraints. Those parts determine delivery risk, lifetime cost and regulatory exposure. Buyers and procurement teams should respond accordingly. Choose vendors with concrete precedents. Ask for architecture diagrams and incident histories rather than glossy screenshots. Budget for ongoing data maintenance rather than treating a purchase as a one‑off. The portfolio of screenshots is a brochure, not a warranty. If a vendor has only happy‑path demos, treat that as publicity, not evidence of resilience. I've seen the same lesson repeat in healthcare and finance. Domain complexity overwhelms interface polish. Operational roles — data engineers, compliance analysts and SREs — are the people who keep systems usable and lawful. Cutting them from a budget to buy prettier design work is a false economy that will show up as invoices, outages and regulatory headaches later. On the factories front, a British robotics firm has announced plans to install humanoid machines across factories run by a major German supplier. The headline numbers are striking because they speak of scale rather than a single pilot. Beyond that, the public account is thin. Committing to thousands of humanoid robots differs from showing one on a test bench. Humanoids promise flexibility — a single shape that can tackle many tasks — but flexibility brings complexity. More moving parts, more sensors and more points of failure increase maintenance burdens. Factories are unforgiving environments. Safety certification, spare‑parts logistics and human teams to supervise and repair machines are non‑trivial. None of those costs are trivial, and they will determine whether such an automation programme is productive. If the deployment succeeds at scale the consequences will ripple. It will change labour arrangements on shop floors and shift bargaining power toward suppliers that own the machines and their service contracts. It will create recurring revenue streams in parts, software updates and maintenance. If it fails, the lesson will be costly and public. The proposed timeline to 2032 suggests a long, staged rollout rather than a sudden swap, which is sensible. Expect a decade of transition where promised benefits and practical pains will both be visible. Watch the metrics that matter: uptime, mean time between failures, cycle times and integrated throughput. Listen for clarity on commercial plumbing — who pays for spares, who is liable for stoppages, and how long the ramp will take. The less theatrical the announcement, the more useful the data when it finally appears. There is a conversation I keep returning to, one that unfolded in a room full of data engineers who feared the future would look very familiar. They worried that the most hyped advances would leave them unemployed, just as automation hollowed out other sectors in earlier decades. Their worry wasn't about the latest capabilities. It was about the quality and governance of the data that feeds systems. The reality on desks is mundane. Behind every prediction is data that needs cleaning, reconciling and documenting. Tracking dataset versions, labelling edge cases, and instrumenting pipelines to detect drift are organisational chores. More scale does not magically resolve them. Systems amplify their inputs rather than compensate for mess. Give a system fragmented, biased or undocumented data and you will get confident and wrong answers. There is an economic plainness to this. Fixing a bad deployment after the fact is often orders of magnitude more expensive than investing in provenance and data ops up front. Regulators will soon demand not just explanations of decision logic but provenance of the data that led there. If you want reliable systems, fund the infrastructure that keeps data honest and traceable. It is less glamorous than announcing a breakthrough, but it is where real value and real risk sit. That points to another trend: solo founders compressing roles that once required multidisciplinary teams. A recent example is a small company taking venture funding to build an artificial intelligence‑assisted divorce assistant and choosing to run it essentially solo. The product aims to guide people through separation: drafting documents, suggesting settlements and answering procedural questions. On paper it sounds efficient. On the ground, divorce is law and emotions and jurisdictional oddities. Mistakes can cost people housing, parental rights or large sums of money. Who is responsible when a template misses a clause or a suggested negotiation hurts one party? Operating a service like this with minimal human oversight externalises risk onto users. For narrow, uncontested cases a lean setup can work. For messy, contested matters it cannot. Regulators and professional bodies are beginning to notice. Where automation touches human lives, questions of transparency, human oversight and accountability now travel beyond academic debate into courts and policy drafts. Efficiency is a good goal. It should not substitute for appropriate human expertise when stakes are high. There is another small, unfashionable truth tucked into many of these stories. Much of what makes these systems useful is not the language engine at their core. It is how teams manage the information they feed into them. Context management is a craft, not a luxury. It decides whether a conversational assistant behaves sensibly or invents plausible‑sounding nonsense. Context management is about deciding what the system needs to know and how to keep that information coherent over time. Give too little and it hallucinates. Give everything and you pay in latency, cost and noise. Managers face trade‑offs: verbatim histories hit budget and performance limits; summaries risk losing constraints; retrieval systems risk stale or irrelevant results. The teams that win build pipelines to chunk documents, attach provenance metadata, refresh summaries and enforce hard constraints where safety matters. Those are engineering choices with direct business consequences. A sales assistant that invents a discount, a legal summary that omits a clause, or an automation that replays an action. Because it "forgot" a stop condition — these are reputational and legal risks. The people who understand how to manage context are becoming the most valuable engineers in practice, even if they rarely headline product announcements. This week a new runtime appeared with a clear promise: turn conversational engines from ephemeral endpoints into persistent operators that can remember, call external services and orchestrate multi‑step plans. The idea is to supply scaffolding to manage memory, connectors and execution control so systems can act over time rather than answering a single request and going quiet. The pitch is useful. Businesses want assistants that monitor data, trigger billing, and prepare summaries overnight. Self‑hosting appeals to organisations worried about data residency and vendor lock‑in. A consolidated runtime can reduce bespoke glue code and provide primitives for retries, rollbacks and permissioned access. But self‑hosting also transfers responsibility. Storage, backups, network configuration and incident response become internal concerns. Safe execution requires sandboxing, rate limiting and observability. Background tasks and multi‑step plans look attractive until they loop unexpectedly or external APIs change. The technology that makes autonomy plausible is only one part of delivery. The rest is governance, testing and monitoring. Treat such a runtime as a platform decision, not a quick upgrade. Another form of sprawl is already visible inside enterprises building these agents. Teams rush to build connectors for clouds, databases and third‑party services. The result is duplicated effort, fragmented credential management and a fog about which agent calls what and why. The low‑glamour remedy is an organisation‑level tool registry: a curated catalogue of approved connectors, their owners and authentication procedures. A registry is not sexy. It behaves like an internal package repository or API gateway. Each entry should list an owner, a stability rating, authentication recipes and a change history. Integrated with CI it can block unapproved calls, rotate tokens automatically and surface security findings before code reaches production. For auditors it makes dependencies answerable rather than a guessing game. Centralisation has trade‑offs. Heavy‑handed governance can bottleneck teams and slow innovation. The useful registries are those that make engineering easier, not those that become bureaucratic gatekeepers. Start small, focus on high‑risk tools and automate where possible. Doing so turns a hidden tax of duplicated connectors into manageable infrastructure. Security conversations have been noisy this week because of another supply‑chain incident in the JavaScript ecosystem. A widely used package was tampered with and signing certificates were implicated. The immediate response was standard: trace the breach, rotate signing credentials and force updates for affected clients. A supply‑chain compromise is dangerous because modern development stacks layer many dependencies on top of one another. A compromised package can propagate malicious code broadly. Signing keys are valuable — if exposed, attackers can impersonate updates. Rotating keys and forcing updates is the emergency procedure. But public statements often stop short of technical detail. Without specifics about which components were modified and how far changes propagated, downstream teams cannot accurately assess exposure. This pattern will push organisations to treat signing keys as crown jewels. Rotations, isolation from development environments and stricter publishing pipelines are sensible. Regulators and industry bodies might also demand clearer disclosure practices after incidents, because reassurance without verifiable artefacts does little to rebuild collective confidence. Meanwhile, voice has quietly shifted from novelty to a default tool for developers. New capabilities let apps listen, transcribe and reply conversationally. The engineering problem moves from crafting the perfect typed query to designing real conversations with turn‑taking and interruption handling. Voice brings usability benefits. People speak faster than they type, which matters for drivers, technicians and anyone with their hands full. It also brings fresh privacy and security considerations. Audio captures biometric signals, accents and ambient sound. Those are valuable data if you control the audio pipeline. They are delicate when you must respect consent and retention rules. The practical hurdles are everyday. Transcription errors, latency, accent variation and background noise all create friction. Designers must build for clarifying questions, conservative confirmation steps and graceful recovery when the system misunderstands. On the legal side, recording laws and biometrics regulation

Well, that was another rather brisk trot through the artificial intelligence landscape. It's a field that seems determined to outpace itself, so finding a steady rhythm, a bit of clarity, is surely the aim. If you'd like a daily digest of all this, without the editorialising, you'll find our artificial intelligence briefing waiting for you at jonathan-harris dot online. One email, no fuss. And for those of you who've been asking about the future of work, my own book, "The Artificial Intelligence Job Shift: Navigating the Future of Work," is available now. You'll find it in the eBooks section of the same site. 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.