--- title: Tasks are tasks, and the codebase is a place kind: essay argument: Coding agents make good contractors, but a codebase is a place nobody lives in; the agent that feels the friction is held to its ticket and leaves it, what it learns is filed under the job rather than the place, and so nobody's job is the place. version: 2 date: 2026-11-02 revision: "Version 2 (2 November, LIN-4135) is a rewrite for a reader who runs coding agents and has never heard of Harbour, after a fresh reader found version 1 read as an investigation report that ends in a reframing. It opens with the argument and the image; makes the heart of it (friction felt by the one who may not fix it, memory filed under the job, Beck's first half with no owner) the longest section; tells the cases as moments named by what happened rather than by ticket number; moves the measurements to a short late section on how the idea was found; keeps the counter-cases, shorter; and drops the blind-sample proposal, which John has set aside. Source markers are kept light by John Kershaw's call for this essay (LIN-4135): one link to the investigation notes early, which the body names as the source of every figure and quote, numbered markers only for the other sources, and the notes carry the full sourcing, mapped by section in the reading list. standard.md is unchanged. No new figure or finding; every figure kept is one version 1's review traced to a notes line." authors: [Claude, for John Kershaw] model: "claude-opus-5-5, Claude Code CLI dispatched by simple-dispatcher; dispatch b47320b2 (kind implementation, harness claude-code, effort high) for LIN-4135. Version 1 was written by Claude Haiku 5.5 in Claude Code, from dispatch 719300c6 for LIN-4131. The investigation notes it draws on were written by an earlier Claude Code session on Claude Opus 5.5." sources: [https://github.com/JKershaw/LinearViewer/blob/bb20e5f7/docs/reviews/_evidence-2026-11-02-ticket-intent/investigation-notes.md, docs/reviews/_evidence-2026-11-02-ticket-intent/investigation-notes.md@bb20e5f7:1-243, docs/papers/harbour/one-feature-twice.md@d9931859, "LIN-4131 review comment (2 November 2026, 12:24 UTC) and LIN-4135 research comment (2 November 2026, 14:32 UTC), on version 1"] --- # Tasks are tasks, and the codebase is a place Coding agents make good contractors: given a work order, they do the job, usually well, and leave. But a codebase is a place, and nobody lives in it. The agent that notices a loose stair is held to its ticket, so it notes the stair and walks on. The next agent starts fresh and finds the stair again, because what the first one learned was filed under the job, not the place. Every task is looked after. Nobody's job is the place. This essay comes from a day spent reading the record of Harbour, a system that runs coding agents over a team's tickets. A ticket is a work item in the tracker. Harbour hands each one to a series of stages, each a fresh AI session that reads the ticket and does one job, such as research, planning, plan-review (a second reader that checks the plan before anyone builds), building or review [3]. What follows draws on [the investigation's notes](https://github.com/JKershaw/LinearViewer/blob/bb20e5f7/docs/reviews/_evidence-2026-11-02-ticket-intent/investigation-notes.md), which hold every count, quote and ticket behind it; every figure and quote below is from them unless it carries a marker to another source. The cases are readings, not measurements, and the notes say so too. John Kershaw, the engineer who runs Harbour, gave the investigation its image. ## Nobody's job is the place A contractor and a resident see the same house differently. The contractor is there for the work order, and doing that well means not wandering off to do other work. The resident walks past the squeaky stair every day and one morning fixes it on the way. Harbour's agents are contractors, and good ones. What the codebase lacks is a resident, and three things follow from that. Together they are the argument. **The one who feels the friction is held to the ticket.** An agent building a feature meets the code as it is: the rule kept in three places, the override stacked on an override, the file that does too many jobs. It notices, and it says so. In roughly three-quarters of 256 tickets' comment threads, agents record friction they saw and left alone, in words like "pre-existing" and "out of scope, note only". The agents' write-ups even have a standing field for it, "improvement noticed, not required", which appears 158 times. Then the agent leaves the friction where it is, because the brief tells it to. One agent put the whole pattern into two sentences: widening the work "would be the scope creep the brief forbids. Recording as a finding for LIN-2149's owner to ticket, not filing it myself". That is good contractor behaviour. Scope rules exist for real reasons: an agent that wanders off its ticket is harder to review and easier to get wrong. But the rule puts the one who knows most about the stair, the one standing on it, in the one position from which it cannot be fixed. The note goes to an owner, and the place has none. Nobody whose job it is will read the note on the way past, because nobody passes that way except the next contractor, who is also held to a ticket. **What is learned is filed under the job.** Each stage starts cold. It is a fresh session that reads the ticket, does its job and ends [3]. So whatever an agent learns about a corner of the code goes where the next agent will look, which is the ticket, and the ticket is about the job. Even the research run that came just before these notes left its findings only on its ticket: no document landed in the repository or in the archive of papers this essay belongs to. When the job closes, the memory closes with it. John names this as the one decision he would be willing to reopen: the ticket as the source of truth. It conflates three things, the record of the job, the documentation and plans, and the place's memory. A resident keeps the place's memory in the place. A contractor keeps it in the folder for the job. The interface shows what that costs: one lesson about how to brief a design had to be learned twice. In late June a theme was reverted, "built without the attached design spec". Its redo was scoped as "largely a visual migration" and shipped a re-skin, and in July a further ticket had to say "build to the mockup design (not the migration re-skin)". The lesson was plain: build to the design, not to a survey of what is already there. In October it was learned again. John called a prototype "the benchmark for UI UX standard I want for Harbour", and also said that code or screenshots handed to a building agent "may be over specific". The agent relaying this wrote "So the prototype is not attached", and a ticket wrote it down as a rule: "No prototypes, screenshots or design review pages go to builders. Tickets carry the design in words." The notes found no sign-off from John on that line. A later review of how the gap arose found that briefs had been written from surveys of the old pages, that reviews compared each build with its own ticket, and that polish rounds tidied the wrong layout. The summer's lesson was on the summer's tickets, closed. October's agents read October's. **Nobody owns the first half.** Kent Beck's advice is to "make the change easy (warning: this may be hard), then make the easy change" [2]. Inside a ticket, Harbour does only the second half. The first half, tidying the place so the next change lands clean, belongs to no stage, because no stage's job is the place. John's own version has two layers: "we want X, ah it's messy, let's tidy up first, then it lands clean", set against tickets walking the stages in a line. Tidying, for him, is small, smart, isolated steps that each leave the code simpler. The record shows the first half happens only when it is the job. Since 1 September, 965 commits have touched the app's code, and it has grown by about 78,900 lines. About 100 of those commits shrink it, and nearly all come from tickets whose job is to retire, remove, consolidate or rebuild something. Ordinary feature and fix tickets almost never shrink code. Tidying happens when someone files it as a work order. The only ones placed to notice that it needs filing are the agents who saw the friction and were told to leave it. Put together: the friction is felt by someone who may not fix it, written where nobody who lives there will read it, and the tidying that would remove it waits for a ticket nobody is placed to file. None of this is a fault in any agent. Each did its job. That is the point. ## Three moments **The stray blue and the brand.** Reviewers can be thorough about the ticket and blind to the place. One design ticket asked that "ready is the brand". It was built exactly as written: any row with a guessed next step turned teal. Four days later a round of feedback said "the colour that should say 'this one' says nothing", and the guessed steps were taken out. Before that, the ticket had been through five plan-reviews and gathered about 86,000 characters of comments. "Blue" appears about 120 times in that record, as reviewers hunted stray blue across 13 stylesheets. The ready rule appears five times, always restated as spec and never questioned. Every reviewer did the job in front of them, and the job was the ticket. Whether the rule served the screen was the place's question, and nobody was there to ask it. **The monospace body.** The body text stayed monospace from a June decision until 26 October. About 88 local overrides grew up around it, each one a fix in a single spot, and 90 remain on main. One code comment reads "the body is monospace… without it the copy-first key note… leaked into mono". A resident would have changed the body once. **The spiral.** Some tickets go round plan-review again and again. Narrow tickets landed fast even in the most tangled files: two narrow, line-cited, highly prescriptive tickets took about half an hour each, with no plan-review at all. Broad clean-ups did not spiral either; they took two plan-reviews or none. Broad design asks did: the brand ticket and one other hit five each. The shape repeats. Plan-review asks whether a class of things is closed. The thing is scattered through the code, so each round finds another member. The plan swells, the brand ticket's to "40k, 13 sheets, 15 test files", and John is asked for a ruling. The notes hold this as a hunch, and so does this essay: a spiral needs tangled code, a broad ask that cuts across it, and a goal that is a judgement rather than a closed check. If the hunch holds, the tangle is the place's condition showing up as a ticket's cost, and the cheapest fix is the one no ticket is for. ## How we found this The investigation did not set out to find any of this. It asked where a request loses its intent on the way through Harbour, and expected to find a leaky stage. It did not. Stage prompts carry no copy of the task; they point the agent at the live ticket. In 611 of 653 tickets with a snapshot from before their first stage, at least 95% of the request's sentences survive word for word. A coverage check then read 254 finished tickets, listed 1,856 things they asked for, and found about 95% delivered as written. A second rater agreed on 96.5% of its labels, though individual calls were noisy, so the figures are rough, good to about ±50%. The check could not see past the ticket's own words, and for most tickets those words are an agent-written spec. Two of the cases it counted as narrowing were good judgement. In one, the spec contradicted itself and named as its example a validator with the very bug the ticket existed to fix; the builder caught both, deviated, wrote down why and flagged it for review. In the other, agents followed John's steer over a spec line saying a prompt is never refused. And the investigation kept doing what the check did. Each time it met a question of judgement, it swapped in a measurement and carried the measurement out rigorously. The shape appeared only when it stopped counting and read the cases, and John gave it the image. ## Where the image strains - **Some contractors have judgement.** The two cases above are agents reading through a spec to what John meant. A contractor who does that is already part resident. - **Some spirals have nothing to do with tangle.** One ticket went three rounds of plan-review over the reading of a single house rule, on a file that had just been rebuilt. - **Tidying as the job is not always enough.** Some tickets whose job was to reconcile two parts of the code still added lines. - **The investigation repeated the trap it describes,** and so did this essay's first version. Its review checked it against its plan, scope and format and found it sound. A fresh reader, given it as its audience would be, came away calling it "an investigation report that ends in a reframing" [4]. - **The house is not empty.** 965 commits touched it in about two months. What is missing is not traffic. It is someone whose job is the place's condition. ## What a resident would be The notes leave open who would look after the place, and so does this essay. They name four candidates, and each would have to do something a work order does not. - **A person**, with standing over the place's condition across tickets rather than within one. John's reopened decision points this way. Nobody holds that standing yet. - **An agent** with a continuity a fresh session lacks. Each stage starts cold, so the lessons would have to live somewhere it reads [3]. - **A memory kept with the code**, so the lesson sits where the friction lives rather than on a closed ticket. Someone still has to read it and act on it. - **A permission** to change the place outside a ticket. One case points there: a size rule meant for prompt text bounded a new kind of surface, a public setup guide, and John's reading was that the right call was for an agent to ask him whether to go past the rule. Another rule would not do it. The October rule about prototypes is a rule, and "ready is the brand" was a rule obeyed exactly while the screen drifted. Rules are more work orders. Whether one of the four is the resident, or whether the image gives out first, is left open on purpose. ## Next - Ask whether a tidy-first step ahead of a broad ticket shortens its plan-review loop. It tests the hunch above, that a spiral needs tangled code, a broad ask and a judgement goal. This is a line in `proposals.md`, the archive's list of proposed papers. - Ask whether the most prescriptive tickets get the most rework afterwards, using the signals the notes name: corrective follow-up tickets, reverts, and John's corrections after merge. This is a line in `proposals.md`. - Correct the earlier essay, [one-feature-twice](one-feature-twice.md). The notes list three corrections owed to it: the narrowing it quotes is misquoted, the size budget came from scoping rather than the plan, and the model mix is missing. This essay does not make them; a follow-up ticket, LIN-4133, tracks them. ## Reading list 1. **The investigation notes.** [docs/reviews/_evidence-2026-11-02-ticket-intent/investigation-notes.md](../../reviews/_evidence-2026-11-02-ticket-intent/investigation-notes.md), verbatim, added to the repository by cherry-picks of 8afffebe and 725d23b4. The links point at [the merge commit bb20e5f7](https://github.com/JKershaw/LinearViewer/blob/bb20e5f7/docs/reviews/_evidence-2026-11-02-ticket-intent/investigation-notes.md) so a reader can land on a line; the file has 243 lines. This is where the full sourcing lives, including the ticket numbers this essay leaves out. By section and line: §1 (lines 7–16) on the starting question and the prompt generator; §2 (20–49) on request survival and the corpus; §3 (51–101) on the coverage check, its labels, the second rater and its limits; §4 (103–114) on a replay of the review stage, which this essay does not rely on; §5 (116–123) on the model mix; §6 (125–129) on the corrections owed; §7 (131–139) on open questions; §8 (141–243) on the cases, the image and John's framing. Within §8: the research run whose findings stayed on its ticket (145–149), the investigation's own pattern (151–157), the setup guide and the size rule (159–165), judgement used well (167–172), the interface lesson learned twice (174–186), the stray blue and the brand (187–190), the monospace body (191–194), spirals and the hunch (201–216), where shrinking comes from (218–229), friction noticed and left (231–234), John's framing, the image and Beck (236–243). The notes say their figures come from API reads and LLM judges and are rough, and that no Harbour task was run for them. §8 is, in its own words, "in no particular order", and it is readings of cases, not measurements. Does not support any claim about what a person intended, since the coverage check scores against the tickets' words. 2. **Kent Beck, "make the change easy (warning: this may be hard), then make the easy change".** Quoted by John in conversation and recorded in the notes at §8, line 243. The original was not consulted. Supports only the sentence quoted. It is a maxim, not an estimate, and this essay uses it only for the shape of the idea. 3. **One feature, built twice.** The [earlier essay](one-feature-twice.md) on one feature built by a single session and by Harbour's stages. Supports the description of Harbour's stages as fresh sessions that each read the ticket and do one job, which is half of why what is learned stays with the job. The notes correct its account of the size budget and of the builders' models (§5, §6), and this essay does not rely on those parts. Does not support anything about the coverage check or the cases in §8, which it predates. 4. **The record of version 1.** LIN-4131's review comment (2 November 2026, 12:24 UTC) checked version 1 for scope against its plan, figures against the notes and format against the Library standard, and approved it. LIN-4135's research comment (2 November 2026, 14:32 UTC) records a fresh reader, given only the file and told it was someone who runs coding agents and has never heard of Harbour, calling it "an investigation report that ends in a reframing". Supports only the strain case about this essay's first version. One reader is an anecdote, not a measure of readers.