{
  "schema": "org-writing@v1",
  "slug": "the-craft",
  "kg": {
    "id": "org:writing:the-craft",
    "type": "essay",
    "graph": "/kg.json"
  },
  "title": "The craft",
  "subtitle": "Machine intelligence made the making cheap, and verification became the job",
  "abstract": "How to tell which half of your work just got cheap and which half became the whole job, and what the disciplines are that keep a practice sound once a machine does the making.",
  "kind": "essay",
  "topics": [
    "Care",
    "Craft",
    "Provenance at machine scale",
    "Receipts",
    "Deskilling",
    "Tacit knowledge"
  ],
  "courseMemberships": [],
  "publishedAt": "2026-08-03T00:00:00.000Z",
  "version": 1,
  "guidelinesVersion": 15,
  "brief": {
    "problem": {
      "text": "Generation collapsed toward free while the cost of a defect that escapes did not move, and every quality signal practitioners learned to trust was built for a world in which writing the thing was the expensive part.",
      "claims": [
        "cost of correcting a defect rises steeply"
      ]
    },
    "mechanism": {
      "text": "The failure mode of working alongside a model is lost context rather than bad judgment, because the information that would prevent the mistake exists but sits outside the head making the decision, and expertise buys bigger chunks, never more slots.",
      "claims": [
        "Architectural failures are predominantly caused by lost context",
        "expertise increases chunk size rather than slot count"
      ]
    },
    "move": {
      "text": "Move context to the point of decision, keep the unit of work small enough that a person can still hold all of it, and refuse to ship what nobody can explain.",
      "claims": []
    }
  },
  "sources": [
    {
      "repo": "mnstry-research",
      "path": "topics/engineering/ai-assisted-development/01-ai-architecture-entropy-talk.md"
    },
    {
      "repo": "mnstry-research",
      "path": "topics/engineering/ai-assisted-development/03-patterns-gaps-synthesis.md"
    },
    {
      "repo": "mnstry-research",
      "path": "topics/engineering/ai-assisted-development/04-enforcement-patterns.md"
    },
    {
      "repo": "mnstry-research",
      "path": "topics/engineering/monorepo/solo-spiral-methodology.md"
    },
    {
      "repo": "mnstry-research",
      "path": "topics/engineering/monorepo/ai-assisted-dev-best-practices.md"
    }
  ],
  "canonicalPath": "/writing/the-craft/",
  "body": "It is a Tuesday afternoon and the feature works. You described it in a paragraph, a model wrote four files, the tests pass, the linter is quiet, and the thing does what you asked. The loop took nineteen minutes. The received view says the interesting question here is capability, whether the model is good enough yet, and the received view has a point, because capability is the thing that visibly keeps changing. It is also the thing that keeps failing to matter. Barry Boehm published the spiral model in 1986 with risk analysis at the center of every loop, and lighter methods displaced it because the analysis and its throwaway prototypes cost too much to run. The prototype is now free. Meanwhile the person holding the whole design together still runs on a working memory of roughly four to seven chunks, a figure that has barely moved since Miller estimated it in 1956.\n\nTwo costs that used to travel together came apart. Making things was the expensive half of nearly every knowledge craft, and it stopped being expensive. Checking things was the cheap half, mostly folded invisibly into the making and paid for by the same hours, and it is now the entire job. That is a different profession wearing the old job title, and most of the difficulty people report in working alongside machine intelligence is the friction of doing the new job with the reflexes of the old one.\n\n## The half that got cheap\n\nThe spiral model is worth a second look precisely because it lost. Each of its loops demanded objectives, a risk analysis, and often a prototype built to answer one question and then deleted. Teams could not afford to build things they intended to throw away, so they stopped, and the industry spent two decades optimizing for velocity instead. The economics that killed the spiral no longer hold. A throwaway prototype is an afternoon at most and frequently twenty minutes, which leaves the risk analysis it existed to serve as the only part of the loop still carrying a real cost. What was overhead became the work.\n\nBoehm's other well-known curve completes the picture. The cost of correcting a defect rises steeply with how late it is caught, cheap in specification and punishing in production. The exact multipliers he reported have been argued over ever since and we do not lean on them, but the shape has never been seriously disputed. Put the two together and the arithmetic is stark. Generation fell toward zero while the cost of an escaped defect did not move at all. When one input to a process becomes free and the others do not, the process reorganizes around what is still scarce, and what is still scarce here is knowing whether the thing is right.\n\n## Entropy is a context problem\n\nWhy does anything rot, though, given competent people? A practitioner talk in our research record makes the sharpest available answer, and it is not about capability at all. Architectural failures, the argument runs, are almost never caused by bad judgment. They are caused by context that exists somewhere but is spread across too many files, too many people, and too many moments in time to be present in one head at the moment of decision. The constraint underneath is not professional, it is anatomical. Working memory holds four to seven chunks whether you are in your first year or your thirtieth, and thirty years of expertise buys you bigger chunks rather than more slots. Codebases grow exponentially. Heads do not grow at all.\n\nThe talk lands on an image we did not expect to meet in an engineering context, because this program already runs on it. You cannot hold the design of the cathedral in your head while laying a single brick. We arrived at the kiln, the brick, and the cathedral from the question of how knowledge becomes durable; the talk arrives at the same cathedral from the question of why software decays, and the convergence is worth naming rather than smoothing over. Both are describing a builder whose reach exceeds their span and a structure that outlives everyone who touched it.\n\nThe failures this produces are small enough to be invisible and expensive enough to matter. An engineer adds one argument to a cached function, an options object where a plain value used to go. The code compiles, the types check, the tests pass, and the cache never hits again, because every call now constructs a fresh object and the cache is keyed on identity. Nothing about that change looks wrong at any point where a human or a linter examines it. Elsewhere, a tidy reusable hook for dismissing a popup attaches one listener to the document, which is correct, and a hundred instances of that popup attach a hundred of them, which is a different program. Elsewhere again, a coupon check goes into a checkout function long enough that nobody reads it end to end, and work that used to run in parallel now waits in line. In each case the information that would have prevented the mistake existed. It was simply somewhere else.\n\nThis is where the machine turns out to be structurally better rather than smarter. A model applies the same scrutiny to the ten thousandth file as to the first, holds a global and a local view at once, and does not tire at four in the afternoon on the day before a release. Those are not intellectual virtues. They are the absence of a body. The engineer at Vercel who spent years on performance work and, by the talk's account, distilled some four hundred pull requests into a structured rules repository designed to be queried by agents was not writing documentation. They were manufacturing the presence of context at the moment someone would need it. The catch sits in the order of operations. A pattern has to exist before anything can enforce it, and a model cannot infer the rule from a codebase that applies it inconsistently, which is exactly the codebase most in need of the rule.\n\n## What passes every old test\n\nThe new failure mode is hard to catch because it satisfies every check built for the old one. A generated prototype arrives carrying all the signals a decade of practice taught us to trust. It runs. It is internally consistent. It is fluent and well organized and confident in a way that human first drafts rarely are. If a model builds an entire subsystem on the assumption that an endpoint returns a timestamp when it actually returns a string, everything downstream of that assumption will be coherent with it, because coherence is what generation optimizes for. The linters pass. The tests, often written by the same model from the same assumption, pass emphatically. Every conventional quality signal confirms the error instead of catching it, which is a strictly worse position than the one those signals were designed for, and it is why so much of the review effort that used to go into reading code now has to go into reading the tests.\n\nA second thing degrades, more slowly and on the clock. Adherence to a complicated set of constraints thins as a session extends, and the model drifts back toward convention, toward the most common way of doing this rather than your way. Two of our engineering research documents reached that conclusion independently, and the practical response in both is the same and slightly undignified, which is to start a fresh session far more often than feels necessary. What that means for anyone in a long collaboration with a model is worth stating plainly, because it is not the intuitive risk. Long collaboration does not degrade toward error. It degrades toward the generic, which is much harder to notice, since the generic is exactly what a reviewer's eye slides over.\n\n## The seat with the known defect\n\nNone of this is peculiar to software, and the oldest published account of it is not about software at all. In 1983 the psychologist Lisanne Bainbridge described what she called the ironies of automation. Automate the parts of a task that are easy to automate, and what remains for the human is monitoring, which is the activity humans perform worst; meanwhile the operator's hands-on skill decays through disuse across exactly the years before the moment it is abruptly required. She was writing about process control rooms and cockpits. Four decades on, the description fits a lawyer reviewing a generated brief, a physician scanning a generated summary, an analyst signing off on a generated model. Everyone in those rooms has been promoted into the monitoring seat, and the monitoring seat has a known ergonomic defect.\n\nThe disciplines that answer it are unglamorous and they all do one thing, which is to move context back to the point where a decision is made. Writing down why rather than only what, so the reason a threshold is that number and the alternative that was rejected survive the person who knew them. Marking the load-bearing decisions, so that removing one means arguing with a sentence instead of deleting a line. Asking a second model to explain the work back rather than to approve it, since a critic and an author sharing a session share the author's assumptions. Keeping the unit of work small enough that a person can still hold all of it, which is less a technique than the last honest defense. None of these are new practices. What is new is that they stopped being professional courtesies and became the load-bearing structure, because the thing they compensate for is no longer occasional.\n\nUnder all of it sits one question you can ask of anything you are about to ship, and it is not whether it works. It is whether anyone can say why it is safe. That question was always available and it was rarely the bottleneck, because a person who had written something line by line could usually answer it, and the answer came free with the labor. The labor is gone and the answer did not leave with it. It has to be bought deliberately now, and buying it is close to the whole of what we are paid for. That is a better trade than it sounds. The half of the work that just became cheap was never the half anyone loved, and the half that became scarce, holding the design in mind, knowing why, putting your name to the claim that this is sound, was always the craft. It has come back to the center of the job, and it is asking more of us than it used to.",
  "apparatus": {
    "note": "The human-facing essay is deliberately practical; this apparatus carries the full references, evidence-graded claims, article-local concepts, and research context behind it. Canonical concept definitions come from the concept registry.",
    "references": [
      {
        "id": "org:references:the-craft:r01",
        "author": "Barry Boehm",
        "work": "A Spiral Model of Software Development and Enhancement (IEEE Computer)",
        "year": 1986,
        "relevance": "The historical anchor for the essay's inversion. The spiral put risk resolution and throwaway prototyping at the center of every iteration, and both were expensive enough that lighter methods displaced it; the prototype half of that cost has since collapsed."
      },
      {
        "id": "org:references:the-craft:r02",
        "author": "Barry Boehm",
        "work": "Software Engineering Economics",
        "year": 1981,
        "relevance": "The verification-cost curve: defect correction grows costlier the later the defect is caught. The essay uses the shape of the curve and explicitly declines to use the reported multipliers."
      },
      {
        "id": "org:references:the-craft:r03",
        "author": "Laurent Bossavit",
        "work": "The Leprechauns of Software Engineering",
        "year": 2015,
        "relevance": "The standing critique of how the defect-cost multipliers propagated through the literature with weaker evidence than their citation history suggests. The reason this apparatus grades the cost-curve claim directional rather than verified."
      },
      {
        "id": "org:references:the-craft:r04",
        "author": "George A. Miller; Nelson Cowan; William Chase and Herbert Simon",
        "work": "The Magical Number Seven, Plus or Minus Two (1956); The magical number 4 in short-term memory (2001); Perception in Chess (1973)",
        "year": 2001,
        "relevance": "The working-memory constraint the entropy argument rests on, including the chunking result that keeps the claim honest. Expertise enlarges the contents of a slot; it does not add slots."
      },
      {
        "id": "org:references:the-craft:r05",
        "author": "Lisanne Bainbridge",
        "work": "Ironies of Automation (Automatica)",
        "year": 1983,
        "relevance": "The generalization beyond software. Automating the tractable parts of a task leaves the human monitoring, which humans do poorly, while the manual skill needed at the critical moment decays through disuse. The essay's bridge from engineering cases to any practitioner working alongside machine intelligence."
      },
      {
        "id": "org:references:the-craft:r06",
        "author": "A practitioner talk on machine intelligence and software entropy (speaker not named in the research record)",
        "work": "Recorded in the MNSTRY research vault as 'AI architecture and software entropy' (2026), source captured as a public video link",
        "year": 2026,
        "relevance": "The keystone: entropy as lost context rather than deficient judgment, the four canonical failure modes, the structural rather than intellectual advantages of a model at scale, and the cathedral image the corpus independently uses. Attribution is deliberately unnamed because the record does not name the speaker; every claim taken from it is graded directional on that basis."
      },
      {
        "id": "org:references:the-craft:r07",
        "author": "Nelson F. Liu and colleagues",
        "work": "Lost in the Middle, How Language Models Use Long Contexts",
        "year": 2023,
        "relevance": "Adjacent published evidence for the attention-dilution claim. It measures position-dependent retrieval degradation in long contexts, which is related to but not the same as constraint adherence decaying across a long working session, and the essay's claim is graded accordingly."
      }
    ],
    "claims": [
      {
        "id": "org:claims:the-craft:c01",
        "claim": "Working memory capacity is limited to roughly four to seven chunks, and expertise increases chunk size rather than slot count.",
        "basis": "Miller 1956 and Cowan 2001 for the capacity range; Chase and Simon 1973 and the subsequent expertise literature for chunk size as the thing training changes.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:the-craft:c02",
        "claim": "Barry Boehm published the spiral model in 1986 with risk analysis and prototyping at the center of each iteration.",
        "basis": "The 1986 paper itself.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:the-craft:c03",
        "claim": "Lighter methods displaced the spiral model largely because its risk analysis and throwaway prototypes cost too much to run.",
        "basis": "The standard methodological history and the research record's account; a reading of why a method lost adoption, not a measured finding.",
        "confidence": "directional",
        "sources": []
      },
      {
        "id": "org:claims:the-craft:c04",
        "claim": "The cost of correcting a defect rises steeply the later it is caught.",
        "basis": "Boehm 1981 and the phase-cost literature that followed. The shape is broadly supported; the widely quoted multipliers rest on thinner evidence than their citation history implies (Bossavit 2015), so the essay uses the curve's direction only.",
        "confidence": "directional",
        "sources": []
      },
      {
        "id": "org:claims:the-craft:c05",
        "claim": "Generation cost fell toward zero while the cost of a defect that escapes into production did not fall with it.",
        "basis": "The corpus's own economic argument, built on observed generation costs and the unchanged downstream cost structure; an argument about which input became scarce, not a measured elasticity.",
        "confidence": "directional",
        "sources": []
      },
      {
        "id": "org:claims:the-craft:c06",
        "claim": "Architectural failures are predominantly caused by lost context rather than deficient judgment.",
        "basis": "The practitioner talk's central thesis, consistent with the working-memory constraint and with the four failure modes it enumerates. A framework claim from a single unnamed source, not a measured finding.",
        "confidence": "directional",
        "sources": []
      },
      {
        "id": "org:claims:the-craft:c07",
        "claim": "An engineer at Vercel distilled roughly four hundred performance pull requests into a structured rules repository built to be queried by agents.",
        "basis": "Reported in the practitioner talk and repeated in our research record; single-source and not independently verified, which is why the essay attributes it to the talk in the text.",
        "confidence": "directional",
        "sources": []
      },
      {
        "id": "org:claims:the-craft:c08",
        "claim": "A model's adherence to complex constraints degrades as a session extends, drifting back toward training-data convention.",
        "basis": "Two of our engineering research documents state it independently from practice; adjacent published work measures long-context degradation in retrieval rather than in constraint adherence.",
        "confidence": "directional",
        "sources": []
      },
      {
        "id": "org:claims:the-craft:c09",
        "claim": "Bainbridge argued in 1983 that automating the tractable parts of a task leaves the human with monitoring, which humans perform poorly, while the manual skill required at the critical moment decays through disuse.",
        "basis": "Ironies of Automation, 1983.",
        "confidence": "verified",
        "sources": []
      }
    ],
    "concepts": [
      {
        "id": "org:concepts:attention-dilution",
        "name": "Attention dilution",
        "definition": "The decay of a model's adherence to complex local constraints as a session extends and its context fills. The direction of the decay is the point: long collaboration degrades toward convention rather than toward error, which is harder to catch, because conventional work is exactly what a reviewer's eye is trained to accept. Answered operationally by the atomic session, one per task, cleared on merge, with the constraints reloaded from a file rather than remembered from the conversation.",
        "provenance": "canonical"
      },
      {
        "id": "org:concepts:bus-factor-zero",
        "name": "Bus factor zero",
        "definition": "The state of a system nobody has ever understood, including its author, reached when generation outruns comprehension. One worse than the classic bus factor of one, because the remedies for that case (pairing, review, documentation, onboarding) all assume an understanding exists somewhere to be distributed. Knowledge lost can be excavated; knowledge never formed leaves nothing to excavate, so load-bearing and accidental become indistinguishable and the system freezes.",
        "provenance": "canonical"
      },
      {
        "id": "org:concepts:competence-illusion",
        "name": "Competence illusion",
        "definition": "A functional artifact whose fluency, internal consistency, and passing checks are read as evidence of soundness. A false premise adopted early is built on consistently, so the work ends up coherent with its own error, and every conventional quality signal (it runs, the linter is quiet, the tests pass) confirms the error instead of catching it. Worse than a silent signal, which at least admits to knowing nothing.",
        "provenance": "canonical"
      },
      {
        "id": "org:concepts:context-loss",
        "name": "Context loss",
        "definition": "The condition in which the information needed to prevent a failure exists but is spread across more files, people, and moments in time than can be present in one head at the moment of decision. Architectural decay is this rather than deficient judgment, which makes the remedy logistical (put the context where the decision happens) rather than moral (find better people).",
        "provenance": "canonical"
      },
      {
        "id": "org:concepts:verification-inversion",
        "name": "Verification inversion",
        "definition": "The reordering of a craft's cost structure when generation becomes nearly free. Producing the artifact stops being the scarce input, establishing that it is sound becomes the scarce input, and risk analysis moves from overhead to the human's primary contribution. Named for the direction of travel: the half of the work that used to be paid for as a side effect of the labor is now the half that has to be bought deliberately.",
        "provenance": "canonical"
      },
      {
        "name": "Four canonical entropy failure modes",
        "definition": "From the practitioner talk: abstraction concealing cost, fragile abstraction (the cached call broken by a new object identity), opaque abstraction (a function long enough that its async shape is invisible), and optimization without proof. Each is a context failure rather than a judgment failure.",
        "provenance": "local"
      }
    ],
    "researchContext": "The agent-facing body for \"The craft\": full references, graded claims, and the\nconcept definitions that the five bricks elaborate one at a time.\n\n## Attribution decisions\n\nThe keystone argument, that entropy is a context problem rather than a\ncompetence problem, comes from a talk captured in our research vault with a\npublic video link and no speaker name. We attribute it in the text as a\npractitioner talk rather than inventing a name, and every claim drawn from it\nis graded directional on exactly that basis, including the Vercel rules\nrepository figure, which the essay reports as the talk's account rather than\nas a measured fact. Boehm carries his own name in both places he appears, and\nthe verification-cost curve is cited for its shape with the multipliers\nexplicitly declined, because the multipliers are the part of that literature\nwith the weakest evidentiary base. Bainbridge is the only source in the set\nwho was writing about none of this and describes all of it, which is why she\ncarries the widening move from software to any practice.\n\n## The cathedral convergence\n\nThe talk reaches, independently and for its own reasons, for the image this\nprogram already runs on. You cannot hold the design of the cathedral in your\nhead while laying a single brick. Our kiln, brick, and cathedral progression\ncame from the question of how knowledge becomes durable and shareable; the\ntalk's cathedral comes from the question of why systems decay. The essay names\nthe convergence rather than absorbing it, since a borrowed metaphor that\narrives from an unrelated direction is evidence about the metaphor, and\npretending it was ours would waste that evidence.\n\n## Material reserved rather than cut\n\nThe research record's fourth document, on enforcement patterns, develops an\nannotation discipline in which a decision is marked load-bearing together with\nthe conditions that would have to hold before it could be removed. The essay\ngestures at it in one sentence and goes no further. That discipline earns its\nown brick in a later wave and is deliberately not authored here, so that the\nargument about removal conditions gets its own mechanism sentence and its own\nclaim cluster rather than arriving as a paragraph in someone else's piece.\nThe same document's sync-pair and archaeology annotations are held with it.\n\n## Position within the MNSTRY program\n\nThe craft pillar sits beside the meaning economy rather than inside it. The\neconomics note asks which human roles keep their price as intelligence gets\ncheap; this essay asks what happens to the work itself inside a role that\nsurvives the swap. The two meet at the swap test, which is why the course\nbuilt on these bricks opens a door to it."
  },
  "contract": "https://mnstry.org/contracts/org/org-writing.v1.schema.json",
  "releaseHash": "b2303d410fd456568bb3789f3beb0aeb9382fad723f3cd96dc310829e8d42a40",
  "versions": [
    {
      "version": 1,
      "cutAt": "2026-08-03",
      "note": "Initial publication, craft wave",
      "visibility": "published",
      "path": "/writing/the-craft/",
      "contentHash": "sha256:a29a1e840c82f4e8",
      "releaseHash": "b2303d410fd456568bb3789f3beb0aeb9382fad723f3cd96dc310829e8d42a40"
    }
  ]
}