The
HUMAN_INPUTmarkers that appear in this article are placeholders left by AI writing skills to indicate “a human should fill in the confirmed value here later” (example format:<!-- HUMAN_INPUT: enter the number -->).
Simply instructing a business cluster pillar to “make sure engineering terms do not become the grammatical subject” is not enough. Communicating intent alone cannot maintain prose density. Tech prose slips back in during the next writing session. Prose density is maintained through structural constraints that restrict generation directly — not through expressing intent.
Two constraints work. A complete ban on inline code fragments, and placing management decision vocabulary as the grammatical subject of each paragraph. Neither is a vague instruction to “write in a more business-oriented way” — both impose direct barriers on prose generation. The bateson business pillar (2026-05-bateson-business-strategy) applied both constraints without a single code fragment and produced 12,996 characters.
Constraint 1: A Complete Ban on Inline Code Fragments
How Code Fragments Destroy Business Prose
When a code fragment appears in the body text, the reader’s cognition is forcibly switched from a “business context” to a “technical implementation context.”
Variable names (tenantId), type names (ICalendarAdapter), function calls (adapter.getSlots()) — the moment any of these appear in a paragraph, business readers conclude “this text is not addressed to me.” The experience shifts to “I am looking at code an engineer wrote.”
This shift happens in a single line. Even if ninety percent of a paragraph is business prose, one code fragment destroys the prose density. There is no such thing as a “small enough intrusion to tolerate.”
The problem with code fragments is not visual — it is the cognitive load imposed on the reader. Engineers naturally skim over code fragments, but business readers pay a cost to determine “what is this?” and “is this relevant to me?” As code fragments accumulate, the cost to business readers compounds until they disengage.
Adding “Pasting Code Fragments into the Body” to must_avoid
The addition to the brief YAML’s must_avoid field takes one line.
must_avoid:
- "Paste code fragments into the body text (including the use of variable names, type names, function names, and pattern names as English words in the prose)"
- "Place engineering terms as the grammatical subject of a paragraph"The first line is the formal constraint. By extending the definition of “code fragment” to include “English variable names and type names,” the restriction covers inline technical terms beyond code blocks (triple-backtick fences).
The second line is the prose density constraint (which overlaps with Constraint 2, described below).
Recording these in must_avoid causes the blog-tech-write skill to treat them as contractual constraints when generating body text. Making the code fragment ban explicit produces a more precise constraint than the vague instruction “write in a business style.”
Cross-Link Design That Delegates Technical Details to Sister Pillars and Spokes
Banning code fragments raises the concern that “removing engineering specifics will make the content less convincing.” The response is to handle this through cross-links to the sister pillar and spokes.
business pillar: No code fragments. Focuses on management decisions, Phase strategy, and ROI.
→ "For engineering implementation details, see [tech pillar]" as a cross-link.
tech pillar: Code fragments included. Presents implementation details concretely.
spoke: Deep-dives into the implementation of a specific theme.Business readers read the business pillar to understand “the meaning of the design decision.” Readers who want technical details follow the cross-link to the tech pillar. Connecting the two allows the business pillar to retain specificity without code fragments.
The opening sentence of the bateson business pillar implements this design. It explicitly states “for engineering implementation details, see [Booking Engine Self-Build Design Strategy]” and declares upfront that the article handles no code.
Constraint 2: Placing Management Decision Vocabulary as the Grammatical Subject
What Subject Placement Means — Concrete Examples and Contrasts
“Placing management decision vocabulary as the grammatical subject” is a prose technique: fix the subject or topic phrase of each paragraph to vocabulary associated with management decisions — ROI, Phase strategy, options, sales funnel, medium-term investment, commercialization, and so on.
Before (engineering term as subject): “The Adapter pattern is an abstraction layer that makes external calendar implementations interchangeable. By unifying under the ICalendarAdapter interface, Google and Outlook adapters can be swapped in and out.”
After (management decision vocabulary as subject): “The freedom to switch external vendors creates room to accommodate customer requirements in commercial deployments. A design that does not lock in a specific calendar system becomes the foundation for handling future customer diversity.”
Both sentences are about “calendar abstraction,” but the first places “what the Adapter pattern does” as its subject, while the second places “what the freedom to switch enables” as its subject.
Before (ROI framing is abstract): “This design makes the transition to Phase B easier. It has the effect of reducing refactoring costs for multi-tenancy.”
After (management subject is explicit): “The investment decision for Phase B depends solely on which design disciplines were maintained in Phase A. Reserving the right place for tenant isolation in Phase A shortens the time from the Phase B investment decision to the start of execution.”
The first is a passive description — “the design reduces costs.” The second places “the Phase B investment decision” as the subject and states what it depends on.
Typical Patterns Where Engineering Terms Slip into Subject Position
Three typical patterns appear.
Pattern 1: Design concept names become the grammatical subject. “The DI container manages dependency injection.” “The adapter makes implementations interchangeable.” In these sentences, engineering concepts are the subject. Business prose does not place words like “DI container” or “adapter” in subject position.
Pattern 2: Paragraphs are occupied by implementation step-by-step descriptions. “First, define the interface. Next, create the implementation class. Finally, inject it with DI.” This is procedural description. Business prose discusses “what becomes possible,” not “how to implement it.”
Pattern 3: Technical term definitions precede business context. “Tenant isolation means logically separating the data of multiple customers.” The definition comes first. Business readers want to know “what this design means from a management perspective” before they hear a term definition.
Building a Per-Paragraph Subject Checklist
The practical check is to write out the grammatical subject of each paragraph’s first sentence.
- After writing the first sentence of a paragraph, bracket the subject.
- If the bracketed word is an engineering term → rewrite required.
- If the bracketed word is business vocabulary (ROI, investment, options, phases, management decision, competitive advantage, customer, etc.) → continue.
Applying this check paragraph by paragraph turns maintaining prose density into a mechanical verification task. Rather than asking “is this good prose?” — a subjective judgment — you ask “what is the subject?” — a factual check.
Embedding Both Constraints in the Brief’s must_avoid
Concrete Example Entries for the must_avoid Field
Example entries for the brief YAML’s must_avoid:
must_avoid:
- "Paste code fragments into the body text (including the use of variable names, type names, function names, abstract class names, and pattern names as English words in the prose)"
- "Place engineering terms as the grammatical subject or topic of a paragraph (including words like Adapter / DI / interface appearing as the leading subject of a sentence)"
- "Explain technical details in the body (delegate tech details to cross-links to the sister pillar or spokes)"
- "Describe implementation steps (step-by-step procedural writing in the form: first..., then...)"Four lines cover the full prose density constraint. Line 1 is the code fragment ban (Constraint 1); lines 2–4 are constraints related to placing management decision vocabulary as the subject (alternative expressions of Constraint 2).
Designing Rule Granularity That blog-review Can Check
For must_avoid entries to function as blog-review criteria, they need specificity. “Write in a business style” does not give review a decision axis.
Examples of granularity that review can check:
- “Are there English words (equivalent to variable or type names) inside a paragraph?” → mechanically detectable
- “Is the subject of the first paragraph under each H2 an engineering term?” → determinable by LLM
- “Is there technical step-by-step writing (first…, then…)?” → detectable by pattern matching
Aesthetic judgments like “is this better prose?” are not suitable for review. The review’s responsibility is to mechanically detect concrete constraint violations recorded in must_avoid.
Why Specifying Constraints in the Brief Maintains Prose Density During AI Writing
Recording constraints in must_avoid causes blog-tech-write to read them as constraints during body text generation. The constraint “do not paste code fragments into the body” becomes an explicit instruction that suppresses the tech prose that naturally emerges when writing about technical topics.
With “write in a business style,” the AI interprets this as “set the overall tone to business” and does not check subjects paragraph by paragraph. “Do not use variable names or type names as English words in the paragraph body” functions as a concrete output constraint, increasing the probability that prose density is maintained at the paragraph level.
Conclusion — Prose Density Is Maintained by Constraints, Not Intent
Prose Density Is Determined by Structural Constraints, Not Writer Intent
Even with strong awareness of writing business prose, the impulse to naturally reach for engineering vocabulary when writing about technical topics in a business context is hard to stop. Familiar vocabulary surfaces before considered vocabulary.
Constraints are the structure that stops that impulse. Banning code fragments creates a situation of “want to include it but cannot.” The subject check provides a criterion that “can be verified after writing.” Both are designed toward “can be verified” rather than “consciously try to.”
How the Two Constraints Changed the Quality of the Business Cluster Pillar
The bateson business pillar applied both constraints. No code fragments; management decision vocabulary — contracted assets, commercialization, Phase strategy, sales funnel — placed as paragraph subjects. As a result, sustaining a state of “engineering terms do not dominate subjects” required no significant effort. There is no memory of encountering difficulty during the writing process — rather, the structure worked: because must_avoid in the brief already contained the code fragment ban, the impulse was suppressed before it arose.
One side effect was that HUMAN_INPUT, an internal marker term, was used naturally in the body text as if it were common knowledge, leaving passages that would be unclear to a first-time reader (this is being addressed by adding a note at the opening of a separate article).
The basis for judging the final output as maintaining quality for a business audience is that the body directly reflected the policy Yakumo wants to communicate to business readers — discussing decisions in the vocabulary of contracted assets, commercialization, Phase strategy, and sales funnel. The vocabulary constraints did not distort the policy; they translated the policy into a form that was “easier to write.”
“Having constraints makes writing harder” is a correct feeling. Constraints reduce ease of writing while building the structure that maintains prose density. The cost of the constraints is paid by the writer; the readability is received by the business reader.
Both constraints are already partially in place. As of 2026-05, the brief for implemented business cluster pillars includes “paste code fragments into the body text” individually in must_avoid, and the blog-tech-write skill reads the brief’s must_avoid and incorporates it during the writing phase. What remains is embedding into the blog-plan skill’s template the logic “if business cluster, include these 2 constraints in must_avoid by default.” Once that is in place, business cluster pillar brief generation will automatically carry both constraints without any manual additions.
There is no recorded instance of a strong impulse to write in a certain direction. Checking git log, there is no revision history of “removed code fragment” or “moved engineering term out of subject position” — the bateson business pillar’s body was structured from the first draft to delegate implementation details to the sister tech pillar via cross-link. This is not “encountered difficulty after writing” but rather the result of the structure working: because the brief’s must_avoid contained the code fragment ban in advance, the writing LLM itself was prevented from proposing code fragments.
→ For the diagnostic framework for prose density (the three-layer structure), see Three Layers of Pillar Design (Structure / Vocabulary / Prose Density). For sister pillar schema design, see Representing Sister Pillar Relationships as First-Class Schema.