Close to the Machine and the Intimacy of Code

The Book

WorldCat's catalog record identifies City Lights Books as the publisher of Close to the Machine in 1997. Macmillan's Picador page lists its 2012 paperback at 208 pages, with ISBN 9781250002488 and an introduction by Jaron Lanier. Macmillan also lists a twenty-fifth anniversary edition published in 2022, ISBN 9781250884121, with an introduction by Anna Wiener. These are distinct editions; the Amazon link on this page points to the 2012 paperback.

The genre matters. This is neither a programming manual nor a detached history of computing. It is a situated memoir by a working software engineer and consultant, organized around the felt and institutional conditions of software work: concentration, debugging, client translation, status, money, illness, desire, age, and the pleasure of a formal problem that appears solvable.

Ullman's perspective adds interiority to the histories examined in The Computer Boys Take Over and Coding Freedom. Those books explain how expertise and professional identity are built around software. Ullman asks what repeated proximity to executable systems does to attention, preference, and responsibility.

Current Context

A coding agent is no longer just autocomplete. Current GitHub documentation describes a cloud agent that can research a repository, plan, change files on a working branch, use an ephemeral development environment, and prepare a pull request. GitHub's default controls make one acceptance boundary visible: the agent cannot approve or merge its own pull request, and workflows normally wait for approval from a person with write access. But workflow execution can be configured to start automatically, security checks can be disabled, and GitHub says its network firewall does not cover every process and may be bypassed. A vendor default is a control input, not a transfer of responsibility from the repository owner.

Productivity evidence is heterogeneous because the tools, workers, tasks, and outcomes differ. A 2026 Management Science paper pooled randomized field experiments at three companies and estimated 26.08% more completed tasks among 4,867 developers given an AI code-completion assistant, while the individual experiments were noisier and less-experienced developers adopted the tool more and gained more. By contrast, METR's randomized study of 16 experienced open-source maintainers completing 246 tasks in familiar, mature repositories found that early-2025 tools increased completion time by 19% in that setting. Neither result measures the present autonomous-agent population.

METR's February 2026 follow-up is equally important. Its later experiment could not support a reliable current effect estimate because developers who valued AI were less willing to accept an AI-disallowed condition, participants withheld tasks for which they expected high AI benefit, and concurrent agents made time accounting difficult. Those are not side issues. Once a tool changes task selection, concurrency, and what workers count as effort, “time per submitted task” no longer captures the whole production system.

Maintenance evidence is also bounded. A preregistered two-phase study published in 2026 involved 151 participants, 92.2% of them professional developers. Its observational first phase associated AI use with a 30.7% shorter median completion time; its randomized downstream phase found no significant difference when later developers evolved the resulting code. The authors explicitly say the work was conducted in late 2024, before the current agent generation. A 2026 FixedBench study tested 200 human-verified reports where no production-code change was needed and found that tested agents still proposed undesirable code changes in 35% to 65% of cases. Together, the evidence supports a narrow conclusion: usefulness depends on task and setting, while abstention, independent review, and downstream ownership must be measured rather than presumed.

Programming as Intimacy

The book's enduring insight is that programming is not simply control over a computer. It is a feedback-rich relationship with a formal system: a programmer makes a claim, the system accepts or rejects some part of it, and repeated correction produces practical knowledge. Requirements, however, arrive from clients, organizations, markets, users, habits, and damaged institutions. A program can be correct relative to its encoded rules while those rules remain incomplete, exclusionary, or wrong for the situation. Formal correctness is therefore not social adequacy.

Technical intimacy has at least four dimensions:

• Behavioral: someone can reproduce and explain what the system does, including important failure modes.
• Historical: someone knows why its interfaces, workarounds, and constraints exist, or can recover that history from a durable record.
• Relational: someone can connect an abstraction to the users, operators, clients, and non-users who bear its effects.
• Custodial: someone is prepared to monitor, repair, replace, or roll back the system after the original change ships.

This definition does not romanticize manual typing. An engineer can personally write every line and still lack relational or historical understanding; a team can delegate implementation and retain intimacy through investigation, review, documentation, operations, and repair. The test is whether proximity yields accountable judgment, not whether a human hand produced each token.

The title's technophilia is not simply fondness for devices. It names an attachment to formal closure: the relief of entering a domain whose states can be represented, whose errors return signals, and whose next move appears tractable. That attachment can sustain patient debugging. It becomes dangerous when tractability becomes a moral preference—when the encodable need is treated as more real than the ambiguous need, the passing test as more real than the excluded user, or the valid record as more real than the person who cannot fit its schema. The “discontents” are the social facts the formal system had to leave out in order to close. This complements the view of software as a humanistic medium: categories, interfaces, tests, prompts, and permissions do not merely describe a world; they help make one executable.

A conversational agent can intensify the attraction because its fluent explanations feel like shared understanding. But a plausible account of a repository is still a claim. Technical intimacy requires checking that claim against source history, dependency behavior, tests, runtime evidence, and the people affected. It also requires recording where understanding ends.

The Coding-Agent Reading

Read in 2026, the book is a sharp companion to AI coding agents. An agent can inspect a repository, propose a plan, edit files, run commands and tests, call tools, and prepare a pull request. That changes the delegation chain:

reported need → interpreted task → agent actions → diff → verification → human acceptance → deployment → maintenance or incident.

Every arrow is a possible loss of context. A clean diff can conceal an ambiguous requirement; a passing test can encode the same mistaken assumption as the implementation; a polished session summary can omit a failed path that matters later. This is why a useful review separates three things: an agent's claim about what it did, the trace of files, commands, tools, and outputs, and verification from checks the proposed change did not control. A check is not independent if the same run could weaken its oracle or redefine success. Claim, trace, and verification answer different questions; none substitutes for the others.

Ullman's memoir corrects the idea that the central problem is translating English into syntax. The harder problem is translating institutions into systems without laundering institutional confusion into executable authority. Someone still has to determine what the software is for, who may be harmed, which requirement is missing, what authority the requester actually has, and what pressure is hiding inside a ticket.

Sometimes the right technical action is no production-code change. FixedBench's no-change tasks show why agents should reproduce a reported problem before patching and why abstention should count as success when the evidence warrants it. Reproduction is not sufficient by itself—the study also found that stronger reproduce-first instructions could miss partially fixed cases—but it interrupts the assumption that visible activity is the goal.

The decisive boundary is therefore the maintainer's acceptance of a change. Agent output should enter the project as an untrusted contribution whose scope, evidence, and future owner are reviewable. A human approval click is meaningful only if the approver has enough time, access, and competence to reject the work.

Labor and Authority

Close to the Machine is also a labor book. Ullman's programmer is powerful enough to shape systems and vulnerable enough to be hired, replaced, aged out, misunderstood, or turned into a translator for someone else's managerial dream. The book's San Francisco software world is not the same as today's cloud platforms, but the pattern is recognizable: technical authority grows where institutions cannot say exactly what they want, then shrinks when the product becomes routine enough to manage, outsource, or automate.

Coding agents intensify that bargain. They may reduce drudgery and help some workers complete some tasks, but cheap generation does not make review, security analysis, architectural memory, incident response, or long-term maintenance cheap. It can shift labor from the person who requests a change to the reviewer who must reconstruct it, the maintainer who inherits it, the on-call worker awakened by it, or the user who discovers an omitted case. Calling the first stage "productivity" while leaving those costs unmeasured is an accounting choice, not a neutral result.

A useful scorecard therefore separates task cycle time from review time, waiting and parallel-agent time, accepted versus discarded work, escaped defects, change failures and rollbacks, incident and recovery time, later modification effort, documentation and ownership gaps, and learning. The denominator matters: tasks offered to a study, agent runs started, pull requests opened, accepted changes, and user outcomes describe different systems. Lines generated, diffs opened, or pull requests merged are throughput measures; they are not by themselves measures of delivered value or sustainable work.

Authorship and authority also need different records. A commit can identify the agent that generated a change and the worker who requested it. That does not make either one the sole accountable author. The organization that accepts and deploys the change should name the reviewer, approver, and maintenance owner. Provenance tells investigators who or what participated; custody tells them who had the authority to accept risk and who must respond when the code no longer behaves as intended.

Apprenticeship deserves the same precision. The large field study found greater adoption and larger task gains among less-experienced developers, but it did not test whether skills were retained over years. It would be equally careless to infer inevitable deskilling or automatic education. Teams can preserve learning by requiring newer developers to trace unfamiliar code, design adversarial tests, explain a proposed change, participate in review, and join incident and rollback work—not merely prompt for an answer.

Finally, auditability must not become indiscriminate worker surveillance. Session logs may be justified for security, review, or incident reconstruction, but a project should define who can access them, how long they are retained, and which secrets or personal data must never enter them. Collecting evidence about a change is not a license to score every hesitation, prompt, or failed attempt as an employee-performance signal.

Governance and Safety

The practical control proposed here is a change-custody record: a compact record that follows an agent-assisted change from request to maintenance. Proportionate to risk, it should identify:

• the requested outcome, requester, authority, acceptance criteria, affected users, and explicit non-goals;
• the repository and revision, relevant context, agent and harness version, and the files, dependencies, commands, and tools touched;
• the permissions granted for reading, writing, execution, network access, secrets, external tools, and deployment;
• the agent's trace and claims, independent tests and security checks, known omissions, reviewer, approver, and named maintenance owner; and
• the rollout, monitoring, rollback trigger and procedure, incident route, and any date when the change or its exception must be reconsidered.

The record should use references or hashes rather than copying sensitive prompts, credentials, or personal data into a permanent log. Its purpose is to preserve decision evidence, not every private keystroke.

Permissions and review should rise with consequence. Documentation or a narrowly scoped local test may need ordinary review. Runtime logic, dependencies, schemas, or public APIs need a constrained environment and independent verification. Authentication, cryptography, secrets, data migrations, build and deployment systems, infrastructure, and safety-critical paths justify least privilege, specialist or two-person review, staged rollout, and a tested reversal path. Some environments should prohibit direct agent deployment altogether. GitHub's working-branch and human-merge controls illustrate one implementation, not a universal safety guarantee.

Two gates prevent velocity from outrunning responsibility. A comprehension gate asks whether a reviewer can explain the requirement, affected components and people, important failure modes, rollback path, and what the tests do not cover. A capacity gate limits incoming change to the review, security, operations, and maintenance capacity actually available. If no one can answer for the change, a passing test suite should not promote it.

Agent-produced code should still enter the same secure development lifecycle as other code. As of August 12, 2026, NIST SP 800-218 version 1.1 remains the final Secure Software Development Framework; version 1.2 is an initial public draft, not the operative final publication. The stable framework's practices—preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities—are a better baseline than inventing a separate, weaker lane for generated changes.

The approved SLSA 1.2 specification adds a complementary supply-chain frame. Its Build Track covers evidence about produced artifacts. In the Source Track, Level 2 requires continuous retained history and source provenance, Level 3 adds enforced organizational controls, and Level 4 requires review by two trusted people for protected changes. Those claims can make a process more verifiable; they cannot prove that a requirement was wise, a reviewer understood the change, or the program is correct. Provenance supports judgment rather than replacing it.

Security controls also have to cover the full agent execution boundary: repository content and issue text may contain hostile instructions; tools can expose additional authority; dependencies can introduce risk; network and secret access can turn a bad edit into exfiltration or deployment. Sandbox the work, allow only necessary tools and destinations, keep credentials short-lived and scoped, and test the incident path before relying on the agent at scale.

Limits

The book is not a comprehensive history of software, a sociology of all programmers, or a governance guide. It is personal and situated. It cannot by itself establish how contemporary tools affect productivity, code quality, security, or learning; those are empirical questions, and the studies reviewed above examine different tools and narrow slices of those outcomes.

Its intense portrait of individual expertise can also be misread as a defense of the indispensable lone programmer. Technical intimacy concentrated in one person is a succession risk and can become gatekeeping. Healthy closeness is distributed through review, pairing, source history, architectural decisions, tests, runbooks, rotation, and incident practice. Abstraction and specialization remain necessary; no one can understand every layer of a modern system.

AI-era readers should also resist turning the memoir into a simple warning against automation. Agents can help people explore an unfamiliar codebase, reduce repetitive work, or express an idea they could not otherwise implement. None of that establishes inevitable empowerment, and the understanding-gap argument does not establish inevitable deskilling. The defensible claim is narrower: every programming interface redistributes attention, so organizations must measure which forms of judgment, learning, and maintenance survive.

What This Changes

Close to the Machine changes three recurring questions across this site. First, authority follows acceptance, not fluency: a persuasive agent explanation cannot approve its own consequences. Second, organizational memory must live outside the model in issues, source control, architectural decisions, tests, runbooks, custody records, and incident reports. Third, safe speed is bounded by the capacity to review, operate, repair, and reverse what is shipped.

On a public archive or knowledge site, that rule reaches beyond runtime code. An edit can pass HTML checks while weakening a citation, changing a publication date, dropping an affiliate disclosure, exposing restricted material, or making a legal status sound broader than its source. A responsible editorial change therefore preserves claim boundaries, source-review dates, internal-link integrity, privacy rules, build evidence, and a live readback after deployment. That is the connection between research integrity and software custody: syntax is only one acceptance criterion.

The practical lesson is demanding but testable: do not confuse generated code with settled understanding. Keep changes small enough for meaningful review; make requirements and non-goals visible; verify claims against independent evidence; name the maintainer before merge; exercise rollback and incident routes; and preserve room to say that no change is the correct result.

Technical intimacy is not being close enough to admire a machine. It is being close enough to answer for it.

Source Discipline

Bibliographic claims use official publisher records and WorldCat's catalog record; the purchase link is cited only for its own product page. The analysis paraphrases the book and reproduces no passage from it. GitHub documentation supports claims about one current product and its default controls, not all coding agents or every configuration.

The empirical studies are reported separately because they measure different systems, workers, repositories, tasks, and outcomes. The maintainability study's initial productivity comparison was observational; its downstream phase was randomized. METR's later update reports design and selection problems rather than a clean replacement estimate. Percentages from these studies should not be averaged or treated as forecasts.

The governance recommendations are inferences from the book, bounded empirical evidence, operational risk, and the cited standards; they are not experimental findings. NIST SP 800-218 version 1.1 is final, while version 1.2 remains an initial public draft. SLSA 1.2 is an approved specification, but conformity to a process level is not proof that a particular change is secure, maintainable, lawful, or understood. Source status and current-context claims were checked August 12, 2026.

Related Pages

• The Computer Boys Take Over and Technical Expertise and The Software Arts and the Humanities of the Machine place programming expertise and executable categories in historical context.
• Coding Agent, Human Maintainer and The Governance Substrate for Agentic Code develop the acceptance boundary and the infrastructure required for review.
• The Execution-Security Map for Coding Agents and the Agent Tool Permission Protocol turn permissions, tools, network access, and credentials into explicit controls.
• The Code-Line Authorship Receipt and SLSA Provenance distinguish attribution and supply-chain evidence from responsibility for accepting a change.
• The Glass Cage and Delegated Judgment connects automation to skill retention, while Agent Audit and Incident Review specifies the record needed after a run fails.
• Research and Editorial Integrity and Privacy and Data apply change custody to public claims, sensitive records, AI-tool use, retention, and correction.

Sources

• WorldCat, Close to the Machine: Technophilia and Its Discontents, City Lights 1997 edition catalog record, reviewed August 12, 2026.
• Macmillan Publishers, Close to the Machine, 2012 Picador edition publication date, page count, ISBN, and introduction, reviewed August 12, 2026.
• Macmillan Publishers, Close to the Machine, 2022 twenty-fifth anniversary edition publication date, ISBN, and introduction, reviewed August 12, 2026.
• GitHub Docs, Concepts for GitHub Copilot cloud agent, Risks and mitigations, and Customizing or disabling the firewall, product capabilities, configurable approval boundaries, security checks, audit controls, and firewall limitations, reviewed August 12, 2026.
• Kevin Zheyuan Cui et al., The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers, Management Science, published online February 27, 2026, reviewed August 12, 2026.
• Joel Becker et al., Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, randomized study and limitations, reviewed August 12, 2026.
• Joel Becker et al., METR, We are Changing our Developer Productivity Experiment Design, later-study selection, task-submission, concurrency, and time-measurement limits, February 24, 2026, reviewed August 12, 2026.
• Markus Borg et al., Echoes of AI: Investigating the Downstream Effects of AI Assistants on Software Maintainability, Empirical Software Engineering, two-phase design, participant sample, observational initial comparison, randomized downstream phase, and limitations, published June 9, 2026, reviewed August 12, 2026.
• Thibaud Gloaguen et al., Coding Agents Don't Know When to Act, FixedBench design, results, and limitations, reviewed August 12, 2026.
• National Institute of Standards and Technology, SP 800-218, Secure Software Development Framework version 1.1, final; and SP 800-218 revision 1, version 1.2, initial public draft; publication status reviewed August 12, 2026.
• Supply-chain Levels for Software Artifacts, SLSA specification version 1.2, including Provenance and Source Track requirements for retained history, provenance, enforced controls, and two-party review, approved specification reviewed August 12, 2026.
• Amazon, Close to the Machine: Technophilia and Its Discontents by Ellen Ullman, 2012 paperback product page, reviewed August 12, 2026.

Book links are paid affiliate links. As an Amazon Associate I earn from qualifying purchases.

• Amazon, Close to the Machine by Ellen Ullman, reviewed August 12, 2026.

Return to Blog · Return to Books