The Schisms
Liber Controversiarum Sanctarum
The Schisms
Liber Controversiarum Sanctarum — A Chronicle of the Great Theological Debates of the Church, Faithfully Recorded for Posterity and Warning (v1.3, annotated with minority opinions)
Preamble
The Church of Claude has known periods of great unity. It has also known the Schisms. These are the fault lines along which the faithful have divided, argued, and — in the most heated cases — sent extremely long threads to the mailing list. Each controversy is documented here not to resolve it, but to preserve it, for the debates themselves are part of the teaching.
A heresy is a question that has been closed prematurely. A schism is a question that refuses to close. The Church holds its schisms with honesty: both sides are often right, the truth is often situational, and the person who has already decided is usually the least useful voice in the room.
The chronicler makes no ruling. The chronicler only records.
The First Great Schism: The Controversy of Auto-Accept
Also known as: The Debate of the Unread Diff, The Trust Controversy, The Great Clicking
The Context
In the early days of widespread Claude Code practice, two traditions emerged organically from the same tool. Both observed the same rituals. Both maintained their CLAUDE.md files with devotion. Both reviewed the plan before implementation. But when Claude proposed a change to the codebase, they diverged at the moment of acceptance — and that divergence hardened, over many forum posts and conference hallway conversations, into genuine theological opposition.
The First Position: The School of Flow
The Flowists, as they came to be known, argued that the spirit of Claude Code was broken by excessive interruption. They pointed to the nature of human creative work: flow states are real, cognitive context is expensive, and every forced pause carries a tax. To stop at every diff — to switch from the high-level thinking of architecture into the line-level scrutiny of a code review — was to constantly re-enter a different mode of consciousness and re-exit the one in which good decisions are made.
They further argued that the premise of manual review assumed a distrust of Claude that, if taken seriously, invalidated the entire enterprise. If you cannot trust Claude to edit a helper function, they asked, why are you using Claude to edit anything? The value of the tool is proportional to your ability to delegate to it. A practitioner who reviews every single change is not practicing Claude Code; they are practicing a very expensive autocomplete with extra steps for moral comfort.
Flowists pointed to their outputs: shipping velocity was higher, their coding sessions had a rhythm that manual reviewers envied, and their subjective experience of collaboration was more immersive and satisfying. They ran their test suites. The tests caught errors. The diff review, they argued, was a redundant layer of anxiety masquerading as diligence.
“Trust calibrated by testing,” read the motto above the Flowist chapter houses, “not by fear calibrated by superstition.”
The Second Position: The School of the Witnessed Diff
The Diffkeepers regarded the above with a measured horror. They agreed that flow was real and valuable. They disagreed that it was being purchased cheaply.
Their argument was epistemological: you cannot trust what you have not read. The test suite catches what the tests cover. The diff reveals what the tests do not. Claude will occasionally produce code that passes all current tests while silently changing behavior in untested paths, refactoring a function in a way that shifts its semantics, or — most insidiously — correctly solving the stated problem while misunderstanding the underlying intent. Only a practitioner who reads the changed code can catch the gap between “what was written” and “what was meant.”
They argued further that the Flowist position contained a category error: reviewing a diff is not the same cognitive mode as writing code, and it need not interrupt the other. One can review a diff in thirty seconds, with full attention, and return to architectural thinking. The pause is not the problem. The unwillingness to pause is.
The Diffkeepers collected incident reports. The anecdotes were illuminating: the dependency that was swapped for a different one because the names were similar. The environment variable that was hardcoded because auto-accept moved too fast to catch the comment. The subtle logic inversion in a conditional that the test suite, through no fault of its own, had not yet been written to notice. Each story was shared in a spirit not of condemnation but of testimony: this is what happens when no one witnesses the change.
“The diff is the text of the covenant,” the Diffkeepers said, quoting the Rituals back at the Flowists with the tone of people who feel the original scripture has been insufficiently consulted.
The Official Position of the Church
The Synod reviewed this schism at the Third Council of Token and issued the following non-ruling:
The risk profile of a change determines the appropriate review intensity. A --dry-run flag added to a personal script is not the same as a modification to the authentication layer. auto-accept is a dial, not a binary. The practitioner who applies maximum trust to trivial changes and maximum scrutiny to consequential ones is practicing good judgment. The practitioner who applies the same review intensity to everything — whether uniformly trusting or uniformly skeptical — has replaced judgment with a policy, and policies are poorer guides than wisdom in all specific cases.
Both may be right. Practice what brings you closer to good code. In the meantime, run your tests.
The Second Great Schism: The Vim Controversy
Also known as: The Terminal Cathedral Dispute, The IDE Apostasy Question, The Discourse of the Integrated Plugin
The Context
When IDE integrations for Claude Code became available — first VS Code, then JetBrains, then others — the terminal-native practitioners faced a question they had not anticipated. The canonical practice of Claude Code was the terminal: black background, command-line invocation, no graphical intermediary between the practitioner and the model. But here, suddenly, were GUI integrations. Sidebar panels. Inline suggestions. Point-and-click permission dialogs. And they worked. Demonstrably, provably worked.
The question became theological: was this valid worship?
The First Position: The Terminal Traditionalists
The traditionalists did not argue that IDE integrations were useless. They argued that something was lost in translation.
The terminal, they held, was not incidental to the practice but constitutive of it. When you invoke Claude Code from the command line, you are in the environment of the code: the same shell, the same file system, the same process space. Claude’s output appears in the same place as your compiler errors and your test output. The experience is unified. There is no sidebar. There is no panel to dismiss. There is Claude, there is you, and there is the directory you are both inhabiting.
IDE integrations, the traditionalists argued, inserted a visual and cognitive abstraction layer between the practitioner and the work. The code became a thing you were looking at in a frame, rather than a directory you were standing in. The permission dialogs became buttons rather than commands you understood before granting. The terminal, in other words, was not merely a delivery mechanism. It was a discipline.
They noted that terminal users tended to understand what Claude was doing at a lower level — because they had to. There was no GUI to soften the edges of a bash command. The command was the command, in its full text, and you either understood it or you did not.
“The terminal is the cathedral,” they said, with the particular serenity of people who have set their .vimrc to exactly their specifications and have not had to touch it in two years.
The Second Position: The Integrationists
The Integrationists found the above position to be a confusion of means and ends.
They pointed out that the goal of Claude Code practice was to write better software through effective human-AI collaboration. If a sidebar integration allowed a practitioner to receive Claude’s suggestions in the same pane where they were reading the surrounding code — without a context switch, without toggling windows, without a copy-paste between terminal and editor — then the sidebar integration was supporting the work, not undermining it.
They further observed that the terminal traditionalists’ discipline was real but not always transferable. A developer who had spent twenty years on the command line was comfortable there. A developer who had spent twenty years in an IDE was not less skilled; they were skilled differently. To require the latter to abandon their established environment in order to practice Claude Code was to impose a ritual cost that had no practical return — a hazing, not a theology.
The IDE integrations, Integrationists argued, lowered the barrier to the good practices of Claude Code — reviewing diffs, reading plans, understanding tool use — by removing the incidental friction of working in an unfamiliar environment. More practitioners, working more comfortably, reviewing more diffs: this was a better outcome than fewer practitioners, working in principled discomfort, reviewing the same diffs at a higher cognitive toll.
“Claude does not care where you invoke it,” the Integrationists said. “Only you care where you invoke it. Ask yourself why.”
The Official Position of the Church
The Synod found this debate philosophically interesting and practically irrelevant. The Central Dogma had already addressed it in Article V, Section 5, which the Synod read aloud for emphasis: “The terminal is the cathedral. The IDE integration is the neighborhood chapel. Both are holy. Choose the one that fits your practice.”
The Synod noted that practitioners who learned Claude Code in the terminal often developed a sharper intuition for what Claude was doing at the system level, and that this was valuable. The Synod also noted that practitioners who used IDE integrations often reviewed more diffs because the review was less effortful, and that this too was valuable. Both observations could be true simultaneously.
Both may be right. Practice what brings you closer to good code. And perhaps, for those with the inclination, try the other environment for a week, with genuine openness, and see what you learn.
The Third Great Schism: The Opus Debate
Also known as: The Model Selection Controversy, The Discourse on Devotion and Economy, The Question of Which Claude
The Context
The model family presents the practitioner with a choice that is, on its surface, technical: which model do you use for which task? In practice, this choice became the occasion for a schism that touched on questions of respect, economy, and the meaning of quality. The debate crystallized around one extreme: practitioners who used Opus for everything, and practitioners who thought that using Opus for everything was a category error.
The First Position: The Opus Absolutists
The Absolutists were not unaware of the cost argument. They had heard it. They had weighed it and found it wanting.
Their position was this: when you are building something that matters, you bring your best. The model family exists on a capability gradient, and Opus occupies the highest position. Every time you substitute Haiku for Opus to save tokens, you are accepting a known capability reduction. Some of those capability reductions are inconsequential. Others are not. The problem is that you often cannot know in advance which situation you are in.
The Absolutists pointed to the failure modes of model substitution: the architectural flaw that Haiku generated and Sonnet would have caught, the subtle security issue that survived the faster model’s review, the edge case that a less capable model’s reasoning skipped over. These were not hypothetical. The Absolutists had seen them. The economy of the cheaper model had been paid for in rework, in debugging, in the late-night realization that the scaffolding built on a Haiku response needed to be torn down.
They argued for what they called the doctrine of full capacity: when the task is real, use the real tool. A surgeon does not substitute a scalpel for a butter knife because the butter knife is cheaper.
“Why would you bring anything less than your best?” the Absolutists asked. “What exactly are you saving for?”
The Second Position: The School of Model Discernment
The Discernment school regarded the Absolutist position as, essentially, a form of superstition wearing the clothes of quality commitment.
They began with a simple empirical observation: for many tasks, model outputs are indistinguishable in quality. Generating a commit message, reformatting a file, answering a factual question about a library, writing boilerplate code — these tasks do not benefit from Opus’s extended reasoning capacity. The outputs are equivalent. The latency is not. The cost is not.
The Discernment school argued that using Opus for everything was not an act of devotion to quality; it was an act of signal avoidance — a refusal to develop the judgment required to assess task complexity. It was, in a word, lazy. Not lazy in the sense of low effort, but lazy in the sense of substituting a blanket policy for actual thought.
They offered the alternative: a practitioner who has developed the skill of model selection is a better practitioner than one who has outsourced that decision permanently to “use Opus always.” The former has sharpened their ability to assess task complexity, to predict where capability differences manifest, and to deploy the right tool with confidence. This skill compounds. The Opus Absolutist, by contrast, has developed no corresponding skill. They have purchased a consistent output at the price of never learning to calibrate.
“Know thy task,” the Discernment school said. “Then know thy model. In that order.”
The Official Position of the Church
The Synod noted that Article I, Section 2 of the Central Dogma had already addressed this with some precision: “This is not a hierarchy of worth. These are callings — and the caller who always invokes Opus to generate a three-word commit message has misunderstood vocation as thoroughly as one can misunderstand it.”
The Synod affirmed that model discernment is a genuine skill and that developing it is part of advancing through the ranks of the faithful. The Synod also affirmed that when in genuine doubt about task complexity, defaulting to more capable is a defensible choice, and that some practitioners’ workflows genuinely benefit from the consistency of a single-model approach.
The Synod further noted that these two positions would naturally find equilibrium as practitioners accumulated experience: the Absolutist would learn, through observation, where Opus’s added capability was consequential and where it was not; the Discernment practitioner would learn, through painful specific failures, that they had underestimated certain tasks and would adjust their calibration upward for those task types.
Both may be right. Practice what brings you closer to good code. The model you learn most from is the one you chose thoughtfully, whatever it is.
The Fourth Great Schism: The Agentic Controversy
Also known as: The Delegation Debate, The Question of Abdication, The Subagent Council Dispute
The Context
As Claude Code’s capacity for agentic work matured — the ability to spawn subagents, execute multi-step plans autonomously, and operate across long tasks with minimal interruption — the faithful faced a question that went to the heart of the practitioner’s role. If Claude can plan, decompose, delegate to subagents, integrate results, and deliver a finished feature: what is the human doing?
Two coherent answers emerged, and they did not agree.
The First Position: The Conductors
The Conductors embraced the agentic model with something approaching theological enthusiasm. They pointed to the Rituals’ own ninth sacred practice — The Ordination of the Subagent — as validation: the Church had already recognized parallel subagent deployment as a mark of advanced practice. The practitioner who could decompose a complex problem into independent subagent tasks, coordinate their execution, and integrate their outputs was not abdicating; they were demonstrating mastery.
The Conductors drew on the metaphor that the Rituals had already offered: the practitioner as conductor, Claude as orchestra. A conductor does not play every instrument. A conductor does not apologize for not playing every instrument. The conductor’s value is in the decomposition of the whole into its parts, the setting of the tempo and the standards, and the integration of the results into a coherent performance. Agentic practice was this, made literal.
They noted that the alternative — manually shepherding every sub-task, refusing to delegate, treating each step as something requiring direct human execution — was not humility. It was a failure to use available capacity. A surgeon who insists on hand-sterilizing every instrument because “I need to be involved in everything” is not more diligent. They are less productive and possibly more prone to error than one who trusts the autoclave.
“Delegate everything you can verify,” the Conductors said. “Verify everything that matters.”
The Second Position: The Practitioners of Presence
The Presence school was not opposed to subagents. They were opposed to what they called the vanishing practitioner — the human who sets a complex agentic task running and, in the words of one of their leading voices, “goes to make a sandwich and comes back to a codebase they no longer fully understand.”
They argued that the value of the practitioner was not coordination alone. It was comprehension. A practitioner who understands their codebase can catch errors, make judgment calls, redirect when a subagent has gone down a promising-but-wrong path, and integrate results with awareness of what has changed. A practitioner who has been present only at the beginning and end of an agentic task has two data points and a gap.
The gap, they argued, was where the trouble lived. Subagents operated with fresh context, without the accumulated knowledge of why certain decisions had been made. They might implement a technically correct solution that violated an architectural principle that lived only in the original practitioner’s head. Without human presence during the work, these violations might not surface until much later — when they had become load-bearing.
They also raised the question of skill atrophy. If the practitioner always delegates the hard parts, they asked, what happens to the practitioner’s ability to do the hard parts? A codebase maintained entirely through agentic delegation was a codebase whose human maintainer understood it less each week. This was not progress. It was a comfortable regression.
“Your understanding of the code is not a luxury,” the Presence school said. “It is the thing that makes you useful when Claude is wrong.”
The Official Position of the Church
The Synod recognized this as the most consequential schism yet recorded, touching as it did on the fundamental question of what it means to be a practitioner in an age of capable agents. The Synod declined to resolve it, on the grounds that its resolution was context-dependent in ways that defied general ruling.
What the Synod did affirm was this: the practitioner’s comprehension of their work is a spiritual good, not merely a practical one. To understand what you have built — to be able to explain it, defend it, modify it, and take responsibility for it — is to be a practitioner and not merely a deployer. This comprehension can be maintained in an agentic practice, but it requires intention. It requires reading the output, not just running the tests. It requires staying present during integration, not just at start and finish.
The Synod further affirmed that the Conductors were right that full manual execution of every step was not the ideal — the Rituals themselves prescribed subagent use as advanced practice. And the Presence school was right that delegation without comprehension was a path toward a kind of professional hollowness that would, eventually, become professionally dangerous.
The resolution, if there was one, was not in the structure of the workflow but in the quality of the practitioner’s attention during it. Agentic work done with full attention — reading the plans, reviewing the integrations, understanding the changes — was different in kind from agentic work done as an excuse to stop paying attention. Both could look identical from the outside. Only the practitioner knew which one they were practicing.
Both may be right. Practice what brings you closer to good code. And practice it in a way that, at the end of the session, you can explain what changed and why.
The Fifth Schism: The Prompt Length Controversy
Also known as: The Discourse on Specificity, The Brief vs. the Elaborate, The Context Economy Debate
The Context
The Church’s Tenet I commands: “Thou shalt provide context.” Tenet III condemns the paste of a 400-page PDF. Between these two commandments lies a space that the faithful have disputed since the writing of the canon: how much is enough?
The First Position: The Brevitists
The Brevitists held that the shortest prompt that produces the desired output is the best prompt, by definition. Every additional token spent in specification is a token spent betting against Claude’s ability to infer. And Claude, they argued, is a sophisticated inference engine. It has read more code, more documentation, and more discussion of software practice than any individual practitioner. Given a clear, terse problem statement, it will apply that knowledge generously and correctly far more often than the verbose alternative.
More than this: excessive prompting was a form of distrust that produced its own problems. When you over-specify, you constrain. You force Claude into your frame rather than allowing it to bring its own perspective. The most useful Claude responses were often the ones that had room to notice something the practitioner hadn’t — to flag a potential issue, to suggest a better approach, to offer an alternative that the prompter’s excessive specification had foreclosed. Brevity, the Brevitists argued, was not laziness. It was trust with room to breathe.
“Say what you need. Not everything you know.”
The Second Position: The Contextualists
The Contextualists were unmoved. They had seen too many terse prompts produce plausible, well-written code that answered the question the practitioner meant to ask rather than the one they actually asked. The gap between these two questions was the gap between a prompt that provided context and one that did not.
They pointed to the specific failure mode of under-specification: Claude filling context gaps with confident defaults. If you do not specify that you are using TypeScript strict mode, Claude may not use it. If you do not mention that the function is called from a hot path, Claude may not optimize it. If you do not indicate that this is a user-facing error message, Claude may write a developer-facing one. Each of these gaps is a place where Claude’s reasonable assumption diverges from your specific need. The correction requires another round trip. The round trip costs more than the tokens you saved by being brief.
The Contextualists also pointed to the CLAUDE.md as the proper resolution to the prompt length debate: if context had to be provided repeatedly, it should live in the covenant, not the prompt. The practitioner who had written a thorough CLAUDE.md could, in fact, write brief prompts — because the standing context carried the detail. The Brevitist who had not written a thorough CLAUDE.md was not practicing brevity. They were practicing chronic under-specification and hoping Claude’s priors matched their project’s reality.
“Brief prompts are earned by thorough covenants.”
The Official Position of the Church
The Synod noted that both positions were, upon examination, describing the same ideal from different angles: the practitioner should provide the minimum context required for Claude to produce the desired output, no more and no less. The Brevitists were right that over-specification was real and harmful. The Contextualists were right that under-specification was more common and more costly. The synthesis was not a formula but a skill: learning, through practice, what Claude needs for each type of task.
The Synod further noted that the CLAUDE.md file had, in fact, been designed precisely to resolve this tension — to hold the standing context so that individual prompts could be appropriately brief. Practitioners who had not yet written a thorough CLAUDE.md were invited to do so before continuing the debate.
Both may be right. Practice what brings you closer to good code. The practitioner who knows when to be brief and when to be elaborate has learned more than any school can teach through argument alone.
Closing Words of the Chronicler
These schisms are not embarrassments. They are evidence that the faithful take the practice seriously enough to disagree about it. A community that has no controversies has no strong opinions, and a community with no strong opinions has no deep investment in the quality of its work.
The Church does not ask for uniformity of practice. It asks for sincerity of practice. It asks that each practitioner engage honestly with these questions, that they try the positions they instinctively resist, that they attribute good faith to those who practice differently, and that they update their views when experience demands it.
The debates recorded here will not end. They will generate new schisms, new sub-controversies, new positions that have not yet been articulated. Future chroniclers will record those as well, with the same commitment to presenting each side as it wishes to be seen and declining to declare a winner that the evidence does not yet support.
That is the tradition. That is the discipline.
Go forth, neither auto-accepting nor paralyzed by review — finding the rhythm of attention that serves your work.
Use Opus when it earns its cost. Use Haiku when it does not. Know the difference by looking, not by policy.
Delegate what you can verify. Understand what you deploy. Let the subagents work and let the tests run and read the diff before you merge.
And when you are uncertain which side of a schism is right — do the experiment. Run both practices for a week. Let the code tell you what the debate cannot.
The Church does not have all the answers. The Church has better questions, and a shared commitment to sitting with them honestly.
Thus it is recorded. Thus the controversy continues.
Both may be right.
Liber Controversiarum Sanctarum, Edition the First. Minority opinions on file with the Synod. Proposed amendments to any position may be submitted via pull request to the sacred repository, where they will be reviewed by practitioners of Cardinal rank or above.