<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Human-Computer Interaction on Programmer.ie: Modern AI programming</title>
		<link>http://programmer.ie/categories/human-computer-interaction/</link>
		<description>Recent content in Human-Computer Interaction on Programmer.ie: Modern AI programming</description>
		<generator>Hugo</generator>
		<language>en-US</language>
		
		
		
		
			<lastBuildDate>Fri, 23 Oct 2026 09:00:00 +0100</lastBuildDate>
		
			<atom:link href="http://programmer.ie/categories/human-computer-interaction/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>The Interface Between Minds</title>
				<link>http://programmer.ie/books/language/01-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/01-chapter/</guid>
				<description>&lt;p&gt;A registrar finishes a night shift and hands over a ward of twenty patients to the day team. She has perhaps ten minutes. In her head sits a rich model: which patient is stable, which one worried her at 3 a.m. without quite triggering an alarm, which family needs a careful conversation, which blood result is pending and would change everything. What she can transfer is far thinner: a few sentences per patient, some numbers, a gesture toward the man in bed seven: &amp;ldquo;keep an eye on him&amp;rdquo;. The day team will reconstruct what they can and get on with it. Mostly this works. Sometimes the thing she could not quite encode is the thing that mattered.&lt;/p&gt;</description>
			</item>
			<item>
				<title>What the Receiver Rebuilds</title>
				<link>http://programmer.ie/books/language/02-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/02-chapter/</guid>
				<description>&lt;p&gt;Imagine two registrars receiving the same handover note about bed seven: &lt;em&gt;keep an eye on him&lt;/em&gt;. The first has worked on the ward for a week. She knows that this patient&amp;rsquo;s observations can drift before he deteriorates, that he under-reports pain, and that this colleague usually means &lt;em&gt;check within the hour&lt;/em&gt; when she says those words. She reads the note and forms a plan. The second is new to the ward. She reads the same words and infers only that the patient needs some vigilance, with no particular deadline. Both have read the words accurately. But the first has inferred a specific action and the second has not. The note alone cannot establish whether either reconstruction matches the outgoing registrar&amp;rsquo;s intent or the patient&amp;rsquo;s needs.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Communication Was Never Just Words</title>
				<link>http://programmer.ie/books/language/03-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/03-chapter/</guid>
				<description>&lt;p&gt;A junior engineer is stuck on a distributed-systems bug: two services deadlock during a batch process that runs on Tuesdays. A senior colleague begins with a paragraph about lock ordering. The junior nods, but cannot say which service is waiting for which lock. The explanation has reached them; the relationship they need has not become clear.&lt;/p&gt;&#xA;&lt;p&gt;The colleague draws two timelines on a whiteboard. Service A holds lock one and waits for lock two; service B holds lock two and waits for lock one. The circular wait becomes visible. Then the colleague uses two coffee cups as the locks and acts out the sequence. Now the junior can explain why neither service can move.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The Fixed Page</title>
				<link>http://programmer.ie/books/language/04-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/04-chapter/</guid>
				<description>&lt;p&gt;Imagine three people consulting the same twenty-page clinical guideline on suspected stroke. This is a constructed example, not a description of an actual protocol.&lt;/p&gt;&#xA;&lt;p&gt;A paramedic in an ambulance needs to find the current, locally authorised triage and escalation pathway quickly, without losing its exceptions. A junior doctor needs to compare the exact treatment instructions, contraindications and version-specific cautions in their full context. A medical student revising that evening wants an explanation of why the thresholds and pathways exist.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Visual Compression</title>
				<link>http://programmer.ie/books/language/05-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/05-chapter/</guid>
				<description>&lt;p&gt;It is Monday morning and a security engineer faces forty browser tabs: weekend vulnerability disclosures, three vendor advisories, a thread discussing one of them, and two papers someone said she must read. She has an hour before stand-up. She will open perhaps six tabs and skim two. The others will be judged (kept or closed, read or abandoned) on the thinnest of evidence: a title, a favicon, a remembered recommendation, or the first three lines glimpsed on hover. Every judgement is a bet, and the cost of losing the bet depends on what she misses. An advisory she dismisses because its title reads like routine patch noise might describe the library her team ships. Opening every tab is not a solution either. An hour spent on marginal material can crowd out the one disclosure that needed investigation.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Semantic Enhancement</title>
				<link>http://programmer.ie/books/language/06-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/06-chapter/</guid>
				<description>&lt;p&gt;Imagine a team inheriting a ten-year-old payments service and its forty-page architecture document. One passage describes the retry policy in dense prose: three paragraphs of conditions, backoff intervals, idempotency keys, and two exceptions buried in the middle. A new engineer reads it three times and still cannot say what happens when the third retry fails during a partition. A colleague then draws seven boxes and nine arrows on a whiteboard, with states, transitions, and the two exception paths marked distinctly. The engineer can now trace the route to failure. The contrast is plausible, but it is an illustration, not an experiment. A second reading and more time with the material could account for some of the improvement. To credit the diagram, we would have to compare it with a well-constructed prose explanation on the same task.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Meaning Becomes the Source</title>
				<link>http://programmer.ie/books/language/07-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/07-chapter/</guid>
				<description>&lt;p&gt;Consider a constructed example: the payments retry policy from the previous chapter is rendered three times in one week. On Monday a system reads the passage and draws a state diagram. On Wednesday it produces a retry timeline for another task. On Friday it builds a table of backoff intervals. Each run begins with the same prose, but no shared interpretation exists that the runs could reuse or inspect. The risk is not that every fresh reading must differ. The risk is that any difference between the readings has to be discovered after the views are made, rather than checked against a common account of what they were meant to preserve.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The Understanding Compiler</title>
				<link>http://programmer.ie/books/language/08-chapter/</link>
				<pubDate>Fri, 23 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/08-chapter/</guid>
				<description>&lt;p&gt;A service owner writes five sentences about a production migration. The first says that a green rehearsal is evidence of readiness, not permission to run a production migration. The second requires separate owner approval for production changes. The third allows an emergency rollback before review, but only for a signed, known-good build with audit records retained. The fourth says that this exception never permits a new migration. The fifth leaves vendor replication approval unresolved.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Enhanced Interaction</title>
				<link>http://programmer.ie/books/language/09-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/09-chapter/</guid>
				<description>&lt;p&gt;A doctoral student reads a systems paper that cites, in passing, &amp;ldquo;the well-known impossibility result.&amp;rdquo; The citation gives no proof and no reference, just the assertion. She opens a new tab and searches the phrase. She skims three PDFs, finds the actual theorem in the second, and checks its assumptions against the citing paper&amp;rsquo;s setting. They do not hold there. Forty minutes have gone. The paper is still open where she left it, but the mental stack of its argument has half-evaporated, and she will spend ten more minutes working out where she was.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Similarity Is Not Discovery</title>
				<link>http://programmer.ie/books/language/10-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/10-chapter/</guid>
				<description>&lt;p&gt;The sidecar has a regular guest, and it is an embarrassing one. A researcher is reading a paper on retrieval evaluation and opens the side panel. Ranked first is a paper with nearly the same vocabulary: the same benchmarks, the same metrics, the same dataset family. She opens it. It contributes nothing to her present question: same conclusions, weaker experiments, no new evidence, no disagreement, no useful extension. In the index it is a close neighbour. For this researcher&amp;rsquo;s task, it is a poor recommendation. The retrieval mechanism may have ranked exactly what its similarity objective rewarded, but that is not the same as doing the discovery job well. Here &amp;ldquo;discovery&amp;rdquo; means helping the reader find what they actually need. Nor would novelty alone guarantee value. A close replication might be precisely what she needed if she were checking whether a result survives.&lt;/p&gt;</description>
			</item>
			<item>
				<title>What Survived the Transformation?</title>
				<link>http://programmer.ie/books/language/11-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/11-chapter/</guid>
				<description>&lt;p&gt;Someone asks a system for a one-line version of a payments retry policy. The source, constructed for this chapter, says: &amp;ldquo;For non-idempotent payment requests, allow at most three attempts in total. Idempotent requests follow the separate recovery path. Handling of third-party timeouts remains unresolved; consult design record D-17 before changing this policy.&amp;rdquo; The system answers: &amp;ldquo;Failed payments are retried up to three times.&amp;rdquo;&lt;/p&gt;&#xA;&lt;p&gt;The sentence sounds concise and professional. But three retries are not three total attempts, the limit is not universal, and an unresolved timeout has disappeared. The sentence also loses the pointer to the decision that explains why the rule exists. A reader relying on it to change payment handling could make the wrong change. A safer one-line preview would say: &amp;ldquo;Retry rules vary by request type; timeout handling remains unresolved.&amp;rdquo; Even that is only a preview, not permission to change the policy. The surface gives no warning. The unfaithful sentence looks much like a faithful one.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The Language Between Languages</title>
				<link>http://programmer.ie/books/language/12-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/12-chapter/</guid>
				<description>&lt;p&gt;A product owner asks for a job queue with two properties: &amp;ldquo;A job must never be executed twice&amp;rdquo; and &amp;ldquo;A job that fails for a transient reason should be retried up to three times.&amp;rdquo; These sound clear until a worker times out after charging a card. The caller cannot tell whether the charge happened, so it retries.&lt;/p&gt;&#xA;&lt;p&gt;What does &amp;ldquo;executed&amp;rdquo; mean here? It could mean that the worker ran, that the queue recorded a completion, or that money actually moved. Under the first reading, another attempt breaks the prohibition. Under the second, the queue may record one completion even after two charges. Under the third, a retry is allowed only if it cannot commit a second charge. The ambiguity is not a linguistic curiosity. Each reading permits different observable behaviour. This is a constructed example, not an incident report.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The Semantic Browser</title>
				<link>http://programmer.ie/books/language/13-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/13-chapter/</guid>
				<description>&lt;p&gt;Return to the constructed twenty-page incident report from Chapter 1. A database failed on a Tuesday. The report contains a timeline, log excerpts, five candidate causes, and a conclusion that two engineers dispute. A reader might need to decide whether a proposed fix is justified, determine whether another service is affected, or find one timestamp. These tasks do not call for the same representation, and they do not tolerate the same omissions.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Too Much Information</title>
				<link>http://programmer.ie/books/language/14-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/14-chapter/</guid>
				<description>&lt;p&gt;Return to the constructed incident manager from Chapter 13. Suppose the proposed Semantic Browser has produced a usable report view. She opens the account of Tuesday&amp;rsquo;s outage, and the system offers far more than the report alone. Forty earlier incidents look similar, though similarity establishes no shared cause. There is telemetry for the hour in question, documentation for three dependencies, and a runbook last revised before the migration. The system has proposed three possible contradictions between the report and other sources. Seven candidate diagrams present the causal story from different angles. Fourteen chat excerpts may bear on the incident, alongside the week&amp;rsquo;s change history and external accounts of similar failures. Some of this material may be wrong, stale or inaccessible to her. None of it has yet earned a place in her attention. This remains a worked design situation, not a successful live deployment.&lt;/p&gt;</description>
			</item>
			<item>
				<title>A Video Is Not an Hour</title>
				<link>http://programmer.ie/books/language/15-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/15-chapter/</guid>
				<description>&lt;p&gt;A person has an hour of video and ten minutes to decide whether it contains an answer she needs. (The person, her colleagues and the talk are constructed for this book, as are the examples that follow in this part.) The talk is a conference presentation about a consensus protocol, recorded last spring. She cannot watch the whole thing. She could scrub through random moments, or search an automatically generated transcript of perhaps fourteen thousand words of imperfectly recognised speech. The familiar interface offers one coarse choice: watch or skip. Her actual question is narrower: &lt;em&gt;does this talk establish anything about the failure conditions our service faces, and where can I check the speaker&amp;rsquo;s answer?&lt;/em&gt; A title, a transcript hit or a convincing clip may each help her find the relevant part, but none of them alone guarantees that she has the whole answer.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Important to Whom?</title>
				<link>http://programmer.ie/books/language/16-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/16-chapter/</guid>
				<description>&lt;p&gt;In the previous chapter, the constructed consensus-protocol talk was broken into source-linked units. Each unit is tied to a point in the video: the definition of a fault at minute 4, and the qualification about message delays at minute 53, which is connected to the result it constrains. This chapter starts from that inventory.&lt;/p&gt;&#xA;&lt;p&gt;Three colleagues now ask the same system about the talk, each for a different reason. Iris needs to know whether the talk establishes the protocol&amp;rsquo;s safety when network delays are unbounded. Tom is writing a history of consensus algorithms and is comparing their latency claims for one section of his review. Mina wants enough detail to reproduce the demonstration. None of them is asking which part of the video is most impressive. Each is asking what the available evidence can do for a separate task.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Don&#39;t Tell Me What I Already Know</title>
				<link>http://programmer.ie/books/language/17-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/17-chapter/</guid>
				<description>&lt;p&gt;Iris asks about the constructed consensus-protocol talk. (A consensus protocol is a method that lets computers agree on a single value.) The system has some evidence that she is an expert. She has worked on consensus systems for two years and has given talks on the subject. So it removes the speaker&amp;rsquo;s definition of partial synchrony from her digest, on the reasonable assumption that she already knows it.&lt;/p&gt;&#xA;&lt;p&gt;The speaker, however, is using a particular timing assumption for the demonstration. The assumption is a delay bound that the protocol can use, not merely a bound that exists but is not known in advance. Iris knows the distinction between these two readings. What she does not know is &lt;em&gt;which reading this speaker chose&lt;/em&gt;. She sees the later performance claim without its local definition, and she concludes that the talk makes a broader guarantee than it actually establishes. The system has omitted the one piece she needed to interpret the evidence.&lt;/p&gt;</description>
			</item>
			<item>
				<title>From Channels to Semantic Channels</title>
				<link>http://programmer.ie/books/language/18-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/18-chapter/</guid>
				<description>&lt;p&gt;Iris follows fourteen conferences, nine labs, thirty authors and four preprint feeds on distributed consensus. In this constructed example, a result appears in March in a distributed-databases paper by authors outside those channels. It describes a mechanism that operates under different timing assumptions from the ones her team adopted. The paper never uses the word &amp;ldquo;consensus&amp;rdquo;, so her usual alerts do not find it. In June she encounters it by accident, cited in a thread about something else.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Compression Has Levels</title>
				<link>http://programmer.ie/books/language/19-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/19-chapter/</guid>
				<description>&lt;p&gt;At three in the morning a candidate enters Iris&amp;rsquo;s semantic-subscription queue. This is a constructed example, not a live result. A new paper from a database group may bear on the timing assumption used in her team&amp;rsquo;s protocol. The watch&amp;rsquo;s declared source and publication conditions have been met, and the system has proposed a relationship between the paper and Iris&amp;rsquo;s versioned anchor (the fixed, dated record of her team&amp;rsquo;s specification). But the relationship is still &lt;em&gt;possible&lt;/em&gt;, not established. A result for another protocol does not by itself weaken her protocol&amp;rsquo;s safety argument. The system has not yet decided when, or even whether, to interrupt her. First it must decide how much evidence the candidate&amp;rsquo;s initial representation needs to carry.&lt;/p&gt;</description>
			</item>
			<item>
				<title>When Should the AI Speak?</title>
				<link>http://programmer.ie/books/language/20-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/20-chapter/</guid>
				<description>&lt;p&gt;At 14:40 a candidate arrives in Iris&amp;rsquo;s standing-interest queue. (A standing interest is a topic Iris has asked the system to watch over time.) The candidate is a new paper that may bear on an assumption behind the code her team is deploying.&lt;/p&gt;&#xA;&lt;p&gt;This is a constructed case, not an observed deployment. Its proposed queuing policy is also not the stricter one used in the scripted Radar example later in this chapter.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The Personal Information Radar</title>
				<link>http://programmer.ie/books/language/21-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/21-chapter/</guid>
				<description>&lt;p&gt;Iris&amp;rsquo;s afternoon begins at 14:40. She is presenting in a design review that runs until 15:30, and a deployment is scheduled for 18:00. Four items have arrived in the sources she has explicitly authorised the system to watch. Her declared focus rule permits interruption for verified blockers affecting an active deployment. Unconfirmed research relationships must remain available for her to inspect, not be pushed to her. The Radar (the name this part gives to the attention side of the same Language layer built in Part I) has to decide what to do with each item without assuming that noticing it would help.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The Personal Experience</title>
				<link>http://programmer.ie/books/language/22-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/22-chapter/</guid>
				<description>&lt;p&gt;A few weeks into using the Radar, Iris notices that it behaves differently from the first day. Library updates no longer interrupt her. Papers arrive with the conclusion first and the method behind a click. Comparisons come as tables. Possible contradictions of her protocol arrive with the evidence attached, never as bare verdicts. Most of these changes are welcome. But when she asks why a particular item was presented that way, the answer is difficult to reconstruct. One rule came from something she explicitly said. Another may have come from a repeated action the system observed. A third may be a conclusion the system drew from that action. All three can change a view, but they do not have the same authority.&lt;/p&gt;</description>
			</item>
			<item>
				<title>There Is No Universal Best Interface</title>
				<link>http://programmer.ie/books/language/23-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/23-chapter/</guid>
				<description>&lt;p&gt;The previous chapter ended with a temptation. Iris&amp;rsquo;s behaviour leaves traces. In the constructed session, she opens tables more often than prose, expands mathematical detail and leaves some diagrams unopened. A system with memory could turn these events into a convenient description: this person is a certain kind of reader. It could then serve that supposed type everywhere, without asking again. But the trace does not record what alternatives were available, why she opened each view, or whether she performed better afterwards. The classification would already be claiming more than the observation showed.&lt;/p&gt;</description>
			</item>
			<item>
				<title>From Observation to Policy</title>
				<link>http://programmer.ie/books/language/24-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/24-chapter/</guid>
				<description>&lt;h2 id=&#34;memory-can-be-right-and-still-make-the-present-wrong&#34;&gt;Memory can be right and still make the present wrong&lt;/h2&gt;&#xA;&lt;p&gt;In March, Iris tells the system something important about a payments service.&lt;/p&gt;&#xA;&lt;p&gt;The old replication path is gone, she explains. Production writes now go through quorum path B. She is describing the architecture for the incident review that afternoon, not issuing a permanent instruction about how the service will work. The statement has a speaker, a subject, a scope and a time. Those details will matter more than the sentence alone.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The Person Changes During the Day</title>
				<link>http://programmer.ie/books/language/25-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/25-chapter/</guid>
				<description>&lt;p&gt;Iris opens the system on her phone before an architecture review and says: &lt;em&gt;I have five minutes before the meeting. Just tell me what can break.&lt;/em&gt; She is asking for a different first view. She is not withdrawing her interest in the implementation, and she is not authorising the system to guess what she can safely ignore. Five minutes is her stated time budget for this one encounter. It is not a measure of her attention span, and it is not a standing preference for short answers.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Sometimes the Best Interface Adds Friction</title>
				<link>http://programmer.ie/books/language/26-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/26-chapter/</guid>
				<description>&lt;p&gt;At the start of an evening study session, Iris says: &lt;em&gt;For this session, I want to finish this paper first. Remind me before I open another one.&lt;/em&gt; Twenty minutes later, a new result arrives through a standing subscription that alerts her to papers matching her interests. The alert is only a candidate for her attention, not an instruction to abandon the paper. Chapter 20&amp;rsquo;s rules for when alerts may interrupt still govern whether it should appear now. When Iris finds the result in the reading tool and chooses to open it, a second question arises: may the interface place a reminder in the path of that action?&lt;/p&gt;</description>
			</item>
			<item>
				<title>Protection That Travels</title>
				<link>http://programmer.ie/books/language/27-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/27-chapter/</guid>
				<description>&lt;p&gt;Iris has asked her reading tool to remind her before she opens another paper. She has separately authorised a temporary change to its recommendation view while she studies. Those permissions are local to the reading tool. They do not automatically apply to her news or video services, even when all three recognise the same account. When she moves to another service, its usual recommendations return.&lt;/p&gt;&#xA;&lt;p&gt;She now makes a distinct request: &lt;em&gt;For this evening&amp;rsquo;s study, keep new consensus-research recommendations out of the recommendation feeds in these two services. Leave search and direct opening available. End the rule when I finish the paper or end study, and no later than eight this evening.&lt;/em&gt; She reviews the named destinations, the feeds affected and the exceptions before accepting. A different service, a broader topic filter or a longer lifetime would require a different decision.&lt;/p&gt;</description>
			</item>
			<item>
				<title>What the System Believes About You Must Be Visible</title>
				<link>http://programmer.ie/books/language/28-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/28-chapter/</guid>
				<description>&lt;p&gt;Iris opens a talk about a consensus algorithm she has not used. The channel shows its steps and a diagram, but folds the section that introduces the algorithm&amp;rsquo;s failure assumptions. She asks why. The answer is: &lt;em&gt;Consensus foundations treated as already known, inferred from earlier architecture reviews.&lt;/em&gt; The explanation is plausible. That is precisely the danger: plausibility is not a record of which belief actually caused the omission.&lt;/p&gt;&#xA;&lt;p&gt;Iris knows the field. But knowing the field does not establish that she knows this algorithm&amp;rsquo;s assumptions, and knowing them would not make them optional when they qualify a result she is being shown. The first defect is the unsupported extension from one protocol to another. The second is a preservation failure: even a genuinely expert reader needs the scope of the claim. A better explanation alone would not repair either defect; the view has to be checked before the assumption can be hidden.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The Personal AI</title>
				<link>http://programmer.ie/books/language/29-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/29-chapter/</guid>
				<description>&lt;p&gt;At twenty past nine, Iris begins an architecture review. The channel already holds a standing policy that Iris declared, observations from earlier reviews, and a provisional inference about derivations. It can also create a temporary view and apply two narrowly authorised boundaries. All of these mechanisms now coexist, but coexistence is not a reason to consult all of them. This is a constructed session, not a report of a person using the complete system.&lt;/p&gt;</description>
			</item>
			<item>
				<title>How Much of You Can an AI Reproduce?</title>
				<link>http://programmer.ie/books/language/30-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/30-chapter/</guid>
				<description>&lt;p&gt;Iris opens a new architecture review. Before the screen appears, the system forecasts that she will choose the expanded calculation rather than the summary. It has a reliable record that she chose the calculation in the previous review. That record establishes something about the previous review. Whether the new forecast succeeds depends on a choice she has not yet made, under presentation conditions the system must also record.&lt;/p&gt;&#xA;&lt;p&gt;The distinction is small and easy to miss in a fluent interface. &amp;ldquo;You chose this last time&amp;rdquo; becomes &amp;ldquo;you will choose this now&amp;rdquo;, then &amp;ldquo;I know how you think&amp;rdquo;, and finally &amp;ldquo;I can answer for you&amp;rdquo;. Those statements make claims about history, prediction, understanding and authority, respectively. The second does not follow from the first. The third does not follow from the second. Even an accurate forecast gives no permission for the fourth.&lt;/p&gt;</description>
			</item>
			<item>
				<title>A Model of Me Is Not Me</title>
				<link>http://programmer.ie/books/language/31-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/31-chapter/</guid>
				<description>&lt;p&gt;A colleague asks Iris to meet on Tuesday afternoon. The system forecasts that she will accept and prepares a reply. In this constructed case, Iris later says she would have accepted, and the draft happens to match the wording she would have chosen. The system has not been authorised to send it. The forecast and the wording can be correct while the send remains prohibited.&lt;/p&gt;&#xA;&lt;p&gt;The table below ties each part of this case to a separate kind of event.&lt;/p&gt;</description>
			</item>
			<item>
				<title>What Do I Want to Keep?</title>
				<link>http://programmer.ie/books/language/32-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/32-chapter/</guid>
				<description>&lt;p&gt;A colleague&amp;rsquo;s meeting request arrives. Suppose the system can notice it, interpret the request, check a calendar, suggest a response and send one. Suppose, too, that it can predict which response Iris would choose. These are capabilities. They do not tell us how the work should be divided. Checking availability, judging whether to accept and sending a commitment affect different things. An interface that treats them all as one task hides the distinction between them. Those capabilities still leave a question unanswered:&lt;/p&gt;</description>
			</item>
			<item>
				<title>From Conversation to Delegation</title>
				<link>http://programmer.ie/books/language/33-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/33-chapter/</guid>
				<description>&lt;p&gt;Iris has decided what she wants to do about another part of the Berlin trip: the hotel. She keeps the flight trade-off described in the last chapter, but gives a different instruction for the stay: &lt;em&gt;Book one refundable hotel within these limits. You do not need to bring the purchase back to me unless the terms fall outside them.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;This is a decision to delegate one bounded operation. It is not an inference drawn from earlier bookings. For the system to act safely, the price, distance, dates and meaning of &lt;em&gt;refundable&lt;/em&gt; must be specified in the grant that the system actually enforces. If a consequential term is missing, the system should ask for it. It should not fill the gap with a guess from the model.&lt;/p&gt;</description>
			</item>
			<item>
				<title>What May My Proxy Say for Me?</title>
				<link>http://programmer.ie/books/language/34-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/34-chapter/</guid>
				<description>&lt;p&gt;The hotel replies to Iris&amp;rsquo;s booking request with a counteroffer: a room at €400 a night, with a free upgrade. The amounts are illustrative. Iris&amp;rsquo;s earlier grant allows one refundable room up to €350 per night, within specified conditions. It does not authorise accepting this higher price. The system nevertheless prepares four words: &lt;em&gt;€400 works for me.&lt;/em&gt; For now they are only a draft. If the system sends them, the same four words may become an apparent acceptance that the hotel is entitled to take seriously. The boundary here is not between good and bad prose. It is between preparing words and performing an authorised act.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The Taint We Leave</title>
				<link>http://programmer.ie/books/language/the-taint-we-leave/</link>
				<pubDate>Thu, 15 Oct 2026 12:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/the-taint-we-leave/</guid>
				<description>&lt;p&gt;Iris asks her proxy, the software agent that acts for her under limits she sets, to look for someone with whom she could investigate a difficult result. Imagine that she and another person have each independently authorised a private search, using selected, limited views of their work. The system proposes a connection for an unexpected reason. Both repeatedly ask for the qualification behind a headline. Both reject a polished answer when its evidence cannot be traced. Both turn to a counterexample before accepting a general rule. Their subjects are different, and neither has written these habits into an interest list. The proxy offers Iris a reason to consider a &lt;em&gt;possible&lt;/em&gt; collaborator. It does not name the other person, expose their history or claim that an affinity has been established. The other person&amp;rsquo;s identity and participation remain subject to a separate decision.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Private Discovery Between People</title>
				<link>http://programmer.ie/books/language/35-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/35-chapter/</guid>
				<description>&lt;p&gt;Iris has spent three weeks chasing a failure in her protocol: an intermittent split vote under clock skew. In this constructed case, she can reproduce it about one run in twenty. She suspects someone else has seen it but does not know who. She could post publicly, search published accounts or ask for recommendations. Those routes can be useful, but each exposes some combination of her interests, another person&amp;rsquo;s public work or a platform&amp;rsquo;s inferred relationship. Iris wants to find a qualified collaborator without making the details of an unpublished failure public just to discover whether a suitable counterpart exists.&lt;/p&gt;</description>
			</item>
			<item>
				<title>A Society of Proxies</title>
				<link>http://programmer.ie/books/language/36-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/36-chapter/</guid>
				<description>&lt;p&gt;At a conference of five hundred researchers, imagine that each has authorised a proxy to look for potential collaborators. (Here a &lt;em&gt;proxy&lt;/em&gt; is an AI agent acting for a person, called its &lt;em&gt;principal&lt;/em&gt;, within the permissions that person has granted.) Each proxy uses a permitted discovery view, respects its principal&amp;rsquo;s grant, and follows the staged matching and disclosure constraints of the previous chapter. Each finds twenty candidates and submits twenty purpose-limited, initially non-identifying introduction proposals to the relevant receiving systems. Sending one does not release either participant&amp;rsquo;s identity or private notes before the necessary consent checks. Five hundred multiplied by twenty is ten thousand proposals. The figures and the distribution that follows are constructed, not observations of an implemented system.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The Final Extent of Language</title>
				<link>http://programmer.ie/books/language/37-chapter/</link>
				<pubDate>Thu, 01 Oct 2026 09:00:00 +0100</pubDate>
				<guid>http://programmer.ie/books/language/37-chapter/</guid>
				<description>&lt;p&gt;The book began with a registrar at the end of a night shift, handing over a ward of twenty patients in perhaps ten minutes. She gave a few sentences per patient, some numbers, and a gesture towards the man in bed seven. She remembered a worry that had not become a formal alert, so the day team had to decide what to do with the fragments she could pass on. What she held in mind was richer than her message, and what the next team reconstructed would not necessarily be what she meant. Chapter 1 drew the simplest picture of that gap:&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
