content: line-edit machine-generated writing patterns from markdown#15
Merged
Conversation
Surgical pass over all markdown to remove machine-generated writing tells while preserving voice. 33 edits across 18 files; net shorter. Files with no listed defect were left untouched. Edits by category: - Dedup: index.md trade-off triplet stated twice; wrong-abstraction.md "DRY is about knowledge, not lines" x3; dns.md "map exposes the extension point" in two adjacent paragraphs. - Contrastive-negation tic: kept the single strongest "isn't X — it's Y" per file, flattened the rest to positive declaratives (philosophy essays, generics, testing, probe, middleware). - Comma-splice lists: change-you-can-see.md jammed lists -> em-dashes/"and". - Hedge repetition: mvc.md "usually" x3 in one paragraph. - Rule-of-three flourish: no-pattern.md "diligence, planning ahead, leaving room, avoiding corners" -> trimmed. - Performed transitions: shipping.md and structure.md throat-clearing cut. - Generic example: modular-monolith.md foo/internal/ -> billing/internal/. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR performs a light line-edit pass across site/course Markdown content to remove repeated “machine-generated” phrasing patterns (e.g., contrastive negations, throat-clearing transitions, repetitive hedges) while keeping edits minimal and preserving intended voice.
Changes:
- Flattens repeated “not X, but Y” constructions into more direct declarative sentences across philosophy/course modules.
- Deduplicates repeated points in a few essays and trims over-ornate rule-of-three flourishes.
- Tweaks examples/wording for consistency and readability in several pattern/course pages.
Reviewed changes
Copilot reviewed 18 out of 18 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| drafts/courses/build-a-cli/testing.md | Refines explanation of test seams to remove contrastive-negation phrasing. |
| drafts/courses/build-a-cli/structure.md | Removes a transition sentence to make the section more direct. |
| drafts/courses/build-a-cli/shipping.md | Cuts throat-clearing module-intro sentence before build instructions. |
| drafts/courses/build-a-cli/probe.md | Rephrases Strategy-pattern mention to a simpler declarative sentence. |
| drafts/courses/build-a-cli/middleware.md | Tightens the “shared code belongs in neither command” rule explanation. |
| drafts/courses/build-a-cli/dns.md | Removes a duplicated “extension point visibility” sentence (keeps discussion later). |
| drafts/blog/generics.md | Tightens generics guidance wording (“start from concrete code”). |
| content/philosophy/wrong-abstraction.md | Deduplicates DRY/knowledge emphasis and trims repeated phrasing. |
| content/philosophy/no-pattern.md | Trims rule-of-three flourish and tightens a few explanatory sentences. |
| content/philosophy/name-the-trade-off.md | Removes extra clause to reduce repeated contrast framing. |
| content/philosophy/listen-to-the-tests.md | Reduces repeated negation framing and simplifies a few sentences. |
| content/philosophy/index.md | Tightens intro copy by removing repeated “rulebook/checklist” framing. |
| content/philosophy/disagree-with-reason.md | Tightens the “permission” section and removes repeated thesis restatement. |
| content/philosophy/change-you-can-see.md | Fixes a mid-sentence list and trims a transition clause. |
| content/philosophy/architecture-is-a-philosophy.md | Removes repeated framing clauses for more direct statements. |
| content/patterns/architectural/mvc.md | Replaces repeated hedges (“usually”) with more direct phrasing. |
| content/patterns/architectural/modular-monolith.md | Updates a generic internal/ example path to match the page’s domain framing. |
| content/index.md | Deduplicates repeated “trade-off / earns it / over-engineering” triplet. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| Design for the change you can see. When the change you imagined finally shows up wearing real requirements, it almost never looks like what you guessed, and the scaffolding you built for the guess is now in the way. | ||
|
|
||
| This is an argument against *designing* ahead. Decisions that are genuinely hard to reverse like data formats, wire protocols, public APIs, all deserve real upfront thought, because changing them later is disproportionately expensive. Operational concerns such as scaling, sharding, distribution, retries, should be added in response to evidence, because you can only learn their real shape by running the system. | ||
| This is an argument against *designing* ahead. Decisions that are genuinely hard to reverse — data formats, wire protocols, public APIs — all deserve real upfront thought, because changing them later is disproportionately expensive. Operational concerns such as scaling, sharding, distribution, and retries should be added in response to evidence, because you can only learn their real shape by running the system. |
| A modular monolith is a single deployable application that is *internally* divided into well-bounded modules. It sits deliberately between the big-ball-of-mud monolith and full [Microservices](/patterns/architectural/microservices): one process, one database connection, one deploy — but inside, each module (billing, orders, catalog, notifications) owns its domain, exposes a small public contract, and hides its implementation. Modules talk to each other only through those published contracts, never by reaching into each other's internals. | ||
|
|
||
| Go is unusually well suited to this. The **package** is a real encapsulation boundary, and the `internal/` directory is enforced *by the compiler*: code under `foo/internal/` can only be imported by code rooted at `foo/`. That gives you architectural boundaries the build will defend, not just ones a code reviewer hopes everyone respects. The result keeps the operational simplicity of a monolith while staying genuinely decomposable — and any module you later need to extract into a service is already a clean seam. | ||
| Go is unusually well suited to this. The **package** is a real encapsulation boundary, and the `internal/` directory is enforced *by the compiler*: code under `billing/internal/` can only be imported by code rooted at `billing/`. That gives you architectural boundaries the build will defend, not just ones a code reviewer hopes everyone respects. The result keeps the operational simplicity of a monolith while staying genuinely decomposable — and any module you later need to extract into a service is already a clean seam. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A line-editing pass over the markdown content to strip machine-generated writing tells while changing as little as possible — repair, not rewrite. A continuation of the earlier
content/remove-generation-tellswork, at the sentence level.Approach
Triaged every
.mdfile with per-defect greps, then read and edited only where a listed defect actually appeared. Files with no defect were left untouched on purpose. The single strongest deliberate use of each pattern was preserved as voice — only repetition was treated as the defect.33 edits across 18 files; net −2 lines (nothing got longer).
What changed, by category
index.mdstated the "trade-off / situation that earns it / over-engineering" triplet twice;wrong-abstraction.mdsaid "DRY is about knowledge, not lines" three times;dns.mdmade the "map exposes the extension point" point in two adjacent paragraphs.listen-to-the-testskeeps the[!IMPORTANT]callout "the problem is the design, not the test";disagree-with-reasonkeeps "'I don't like it' is not a reason; it's the absence of one") and flattened the rest to positive declaratives.change-you-can-see.mdhad two lists jammed mid-sentence → em-dashes / "and".mvc.mdrepeated "usually" three times in one paragraph.no-pattern.md"diligence, planning ahead, leaving room, avoiding corners" → trimmed.shipping.mdandstructure.md.modular-monolith.mdfoo/internal/→billing/internal/, matching the page's own domain.Left untouched on purpose
The ~75 pattern reference pages and most course modules. Their "X, not Y" constructions are technical/definitional (
contract, not concrete type;has-a, notis-a), their hedges are genuine conditional caveats, and their triples are informative — none are the machine tic.Not addressed (out of scope — flagging for a separate fix)
drafts/blog/index.mdfrontmatter key isorer:, should beorder:(likely breaks that page's ordering).content/philosophy/change-you-can-see.mdhas two stray double-spaces ("This is an", "which is the").🤖 Generated with Claude Code