Behind the Architecture: How We Built This Essay in Real Time

The project began with an arithmetic problem.

I wanted one long-form essay about applying SOLID, DRY, and YAGNI to technical writing. SOLID supplied five design principles: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. DRY, or Don’t Repeat Yourself, addressed duplicated knowledge. YAGNI, or You Aren’t Gonna Need It, addressed speculative work. I also thought the essay could produce about nine individual posts. There were only seven named principles.

The first useful contribution from my AI collaborator was not a paragraph. It was an architectural correction. Add an introduction that establishes writing as designed structure, give each of the seven principles its own chapter, and end with a synthesis that turns the ideas into a refactoring workflow. Seven principles became nine chapters without inventing two more principles to satisfy the number.

That exchange established the process we followed for the rest of the work. I supplied the premise, audience, experience, and judgment. Codex helped research, organize, draft, compare, and inspect. Neither role was sufficient alone.

The Architecture of Nonfiction eventually became a substantial essay, a dedicated section of this site, a set of companion essays, and two reusable skills: a writing-architecture audit and a cold-start audit. Its structure is simple: an introduction establishes the model, seven chapters apply the named principles, and a final chapter turns them into a revision workflow. A companion essay such as this one develops one related question, links back to the parent, and remains understandable on its own.

You do not need to read the parent to use this case study. The premise required here is that a document has components, dependencies, boundaries, and handoffs that can be designed and revised deliberately.

None of the resulting artifacts were designed in one pass. They emerged through a sequence of decisions that made the work easier to examine.

This is the case study of that sequence.

The Premise Came Before the Framework

The target audience was specific from the beginning: technical practitioners who write for other technical consumers across blogs, LinkedIn, Substack, Medium, white papers, and similar channels. The central premise followed quickly:

You already know how to manage complexity. Apply the same training to your writing.

That premise constrained the project. The essay could not become a survey of composition theory with software vocabulary pasted over it. It had to give practitioners diagnostic lenses they could use during revision. Familiarity with responsibilities, interfaces, dependencies, duplication, speculative work, code review, and refactoring reduced the learning cost for the parent’s technical audience. This case study explains the process without requiring that background.

The premise also created a risk. SOLID was developed for software design. A paragraph is not a class, a reader is not a runtime, and evidence must be allowed to overturn a conclusion. A weak analogy would make the essay feel like an attempt to be clever while delivering a weak lesson.

We wrote the boundary into the design: use software principles as diagnostic lenses, not laws of nature. The essay would say where a comparison helped, where it broke, and what writing already understood under different names.

Research Before Writing

I learned to write essays by assembling sources and informational notes before trying to produce finished pages. We followed the same sequence here.

The initial research question was not “Can we find someone who agrees?” It was “What prior work already connects composition, modularity, reader context, revision, and software design?” Robert C. Martin mattered because he assembled and popularized the principles. Michael Feathers later gave the group its SOLID acronym. Martin also explained that the principles apply beyond conventional object-oriented classes to coupled groupings of functions and data. Barbara Minto supplied hierarchy and governing-point logic. Clark and Haviland described how given information creates the context for new information. Nancy Sommers distinguished surface correction from revision that reconsiders meaning and structure.

Other sources established narrower parts of the model. Hunt and Thomas connected writing practice to code. Adam Strantz discussed modular technical communication. Research on long-form AI generation and context-aware revision supplied evidence for the gap between fluent passages and coherent wholes.

The result was a source dossier rather than a pile of links. Each entry recorded four things:

Field	Responsibility
Source contribution	What the source actually established
Use in the essay	Which point or inference it could support
Boundary	What we must not infer from it
Open question	What still required judgment or more research

The boundary and open-question fields kept our interpretation separate from each source’s findings. One paper on paragraph-level AI revision evaluated models that received the full document and explicit revision criteria. It supported the value of wider context and clear guidance. It did not evaluate our use of an author-specific style guide, a maintained set of editorial preferences and rules, to supply that guidance across projects. The style guide remained our design decision rather than the paper’s conclusion.

The sources did not manufacture the thesis. They refined it. They showed that good writing already contained many of the ideas we planned to borrow from software: hierarchy, cohesion, reader contracts, context management, modularity, and structural revision. Our contribution became very clear. We were not importing engineering discipline into a field that lacked it. We were naming parallels in terms technical practitioners already knew.

The Outline Became an Architecture

We did not treat the outline as a list of future headings. Each chapter received a responsibility, required inputs, intended outcome, key sources, examples, analogy boundary, and handoff to the next chapter.

That made the outline executable.

For example, the Single Responsibility chapter could assume that Chapter 1 had already established sentences, paragraphs, sections, and chapters as components. Its job was to replace the slogan “do one thing” with Martin’s more precise “one reason to change.” Its outcome was a reader who could diagnose mixed rhetorical purposes. Its final question, whether an essay’s structure could accept new evidence without being rebuilt, handed the reader to Open/Closed.

The architecture also prevented thematic aggregation: nine chapters could discuss the same subject without building on one another, leaving the reader with a collection of points instead of a coherent whole. We avoided it by giving each chapter an outcome the next chapter could use. Single Responsibility ended by asking whether a cohesive argument could accept new material without being rebuilt. Open/Closed answered that question, then asked what a replacement must preserve. Liskov Substitution began with that contract. Each chapter’s conclusion became a precondition for the next instead of letting the essay restart nine times.

The outline changed under review. We removed target lengths because the editorial process should determine the necessary length. We stopped describing every chapter as a future standalone post because each chapter’s current responsibility was to the essay. We reserved related ideas, such as the unit-test parallel, for later companions when expanding them would interrupt the main path.

The essay began applying its own principles before meaningful prose existed.

Serial Drafting Created Better Feedback

We drafted one chapter at a time.

That decision traded speed for a tighter feedback loop. I reviewed Chapter 1 before Codex drafted Chapter 2. The accepted edits, rejected phrases, and clarified boundaries became context for the next implementation. By Chapter 3, the first draft already sounded more natural because the collaboration had accumulated specific editorial evidence.

Several recurring rules emerged from ordinary line edits:

Draft language	Editorial response	Durable lesson
“Those instincts transfer”	Engineers have training, guidelines, and experience, not unexplained instincts.	Name the mechanism instead of romanticizing expertise.
“Clarity is often a local request”	“Local request” sounds neat but means nothing in prose.	Prefer semantic specificity over tidy abstraction.
The reader must “carry” context	The metaphor felt habitual and unnatural.	State what the reader must remember, infer, or retrieve.
“Epigraph” in conversational explanation	Technically correct, but unnecessarily grand.	Use the ordinary word when it carries the full meaning.
Repeated use of “claim”	The word had become a default where contention, assertion, statement, or conclusion was more precise.	Reserve technical vocabulary for the cases that need it.

These were not cosmetic preferences. Each edit reduced the amount of interpretation required from the reader. Together, they became part of an author-specific style guide that later drafts could load as working context. Those rules improved later chapters only when they arrived with the relevant chapter-specific context. Before Codex began the next chapter, we assembled a compact handoff instead of relying on conversation history:

Chapter contract:
- responsibility, prerequisites, outcome, and handoff

Evidence:
- assigned sources, supported statements, and inference boundaries

Editorial learning:
- accepted edits and the rule each one established
- rejected edits and why they failed

Current standards:
- relevant voice, terminology, citation, and formatting rules

Next task:
- implement this chapter without revising settled upstream decisions

When those inputs conflicted, facts, evidence, safety, legal requirements, and publication rules came first. The current chapter contract and task came next. The author’s style guidance shaped valid implementations, and generic model preferences came last. If sources at the same level conflicted, a required input was missing, or the rules did not resolve the choice, Codex surfaced the conflict, preserved settled decisions, and waited for my judgment instead of inventing support or choosing silently.

The process also corrected conceptual mistakes. I initially compared an experienced reviewer with a copy editor. Editors Canada’s professional standards made the distinction clear: the work we meant was structural or developmental editing. Automated tools functioned more like linters, while an experienced editor asked why a section existed, whether its evidence supported its conclusion, and whether the intended reader had enough context.

That correction strengthened both the essay and the collaboration. Codex was often my editor, but naming the role accurately clarified what kind of review I expected.

The Author Was Not a Prompt Source

It would be easy to describe the project as a good prompt followed by iterative generation. That would be false.

My contributions were not limited to approving or rejecting text. I supplied the core premise, corrected interpretations, contributed lived examples, drew connections among sources, set the limits of the analogies, and decided what the work was ultimately for. Many of the essay’s strongest turns began as objections during review.

The SRP chapter is one example. “Do one thing” was too restrictive for writing because a great sentence can deliver information, create emotion, raise a question, and prepare the next rhetorical move at the same time. “One reason to change” was the better principle. It preserved multifunctional language while asking whether all those effects served one rhetorical purpose.

The Dependency Inversion chapter needed a different correction. A thesis cannot outrank contrary evidence merely because high-level policy should not depend on low-level implementation detail. The useful parallel was organizational: the argument defines what role support must perform, while evidence retains the authority to qualify or overturn the argument. Without that boundary, a software analogy could rationalize bad scholarship.

Codex contributed different leverage. It found and compared sources, maintained the outline and process artifacts, generated candidate phrasings, applied approved changes consistently, checked terminology across a large manuscript, verified links, and ran structured reviews. Together, Codex and the maintained artifacts kept the project’s sources, decisions, and dependencies available during drafting instead of requiring me to reconstruct them from memory or sift through multiple pages.

The collaboration worked because authority remained explicit. AI could identify a pattern. It could not decide that the pattern represented my voice. AI could find a source. It could not decide what I was justified in concluding from it. AI could propose a clean sentence. It could not decide that the sentence deserved space in the essay.

Scope Decisions Became Part of the Evidence

The essay produced more useful material than it could responsibly contain. That was not a surprise. It was a live application of YAGNI.

The Hamlet quotation became the cleanest example. We identified “brevity is the soul of wit” as a possible chapter opener, rejected it when the isolated line appeared to reduce YAGNI to brevity but preserved the idea, and later restored it after the chapter’s reader-value framing gave the scene a real role in framing the concept. YAGNI meant not yet, not never.

Other material required promotion. The relationship between natural language and AI-generated software, paragraph state transitions, multifunctional sentences, author-specific style guides, editorial roles, scope control, and unit tests for prose all deserved more treatment than the parent could provide. Each became a companion only after it had a clear question to answer on its own.

The OODA loop work showed the same process outside this project. I began researching a connection for one blog idea and discovered several distinct theses. The Loop Is the Easy Part and A Fighter Pilot Is Hiding in Your Engineering Practices share research, but they do not share a responsibility. The first explains orientation in agent loops. The second traces the concept across fields and engineering practices.

AI made research and preservation cheaper. It did not make reader attention cheaper. Keeping notes outside the draft let us cut aggressively without treating every removal as permanent loss.

Review Worked from the Outside In

Once all nine chapters existed, line editing was not enough. We needed to inspect the essay as a composed system.

The review sequence moved from the largest contract to the smallest:

Review	Primary question	Output	Ready to advance when
Developmental	Does the essay support its premise, maintain a coherent line of reasoning, and respect the analogy limits?	Structural findings and accepted revision decisions	No unresolved issue changes the governing premise, sequence, or scope.
Architecture	Do components have clear responsibilities, stable handoffs, sufficient interfaces, controlled dependencies, consistent knowledge, and present reader value?	Findings organized by principle, contract, and severity	Every structural failure is repaired or explicitly accepted by the author.
Cold start	Can the intended reader proceed without the conversation, dossier, outline, or private assumptions?	Missing-context inventory with the smallest useful fixes	Every required prerequisite is supplied locally or declared honestly.
Terminology	Do recurring words identify deliberate levels and operations?	A usage inventory and localized corrections	Each reserved term has one defensible meaning in context.
Copy editing and links	Are statements mechanically sound, citations reachable, names correct, and style rules satisfied?	Corrected copy and verification results	The release checks pass without reopening the structure.

The author owned every advance decision. A specialist editor or isolated reviewer could diagnose a failure, and an automated check could enforce a declared rule, but none silently changed the essay’s reasoning or waived an unresolved issue.

The developmental review found a problem created by our process. The essay repeatedly referred to its source dossier, supplemental queue, derived posts, and final skill. Those artifacts were useful to us, but the reader could not inspect them. The backstage had become a hidden dependency.

We removed or reframed those passages. The parent essay now explains that additional material can become a separate document when it has an independent purpose. It does not require the reader to understand our tracking system. This case study can discuss the tracking system because the process is its subject.

The same review found five competing endings in the final chapter. Release criteria, emotional closure, AI review, the future skill, and a slogan all tried to conclude the essay. We kept the ending that completed the reader’s path and moved future artifacts out of its way.

The cold-start review addressed a problem that recurred throughout this essay. A draft could appear complete to us because we still had the conversation, notes, source dossier, and earlier versions in view. Each fresh review began outside that accumulated context and worked inward from the reader’s entry point: What does this artifact expect the reader to know? Which prerequisites does it supply, which does it declare, and which are simply missing? That outside-in review exposed context dependencies the author and collaborator could no longer see.

The Website Followed the Work

For this project, publication meant a website. The essay did not fit naturally into a blog feed. It was a durable reference with a different scale, navigation need, and relationship to future material. We created a separate Long Form section, then added a table of contents because a reader needed to navigate nine chapters without scrolling through the whole piece.

Companion essays created another infrastructure decision. They needed stable identifiers, their own routes, and visible links to the parent, but they also needed to stand alone. The site now treats them as a collection beneath the canonical essay rather than as hidden appendices.

The broader Writing landing page changed too. A navigation label that led only to the blog concealed the scale of the existing work. The page now gives readers three distinct entry points: Dispatches for shorter blog articles, Long Form for canonical essays, and Companion Essays for focused extensions.

Those changes were not content strategy invented in advance. They were interfaces extracted from real reader needs. The work exposed the structure the site needed.

Another publishing channel would require different implementation work. A book might need parts, a table of contents, and cross-references. A newsletter might need a sequence and archive page. The transferable rule is to make the work’s scale and relationship to related pieces visible through the interfaces the channel provides.

The Skills Came Last

From the early conversations, we knew the framework could become a skill that inspected other writing. We deliberately did not build it first.

Before the essay existed, the writing-architecture skill would have encoded an attractive theory. After the essay had survived source review, serial drafting, author correction, developmental editing, terminology audits, and publication, the skill could encode a practiced method. Its diagnostic questions came from real failures rather than imagined completeness.

The same pattern produced a second skill. Repeated reviews showed that an artifact could be coherent to its creators while depending on context unavailable to a new reader. Once the problem recurred across several pieces, the cold-start audit had earned a stable procedure of its own.

This is DRY applied to knowledge rather than sentences. The essay remains the maintained explanation. The writing-architecture skill operationalizes its structural diagnostics, while the cold-start skill inspects missing reader context. Neither rebuilds the theory. Individual companion essays extend one question without forcing the parent to absorb every implementation detail.

The artifacts have distinct responsibilities and interfaces:

Artifact	Minimum contents	Create or update	Handoff
Source dossier	Source contribution, intended use, inference boundary, and open question	Begin before drafting; update when evidence changes a conclusion	Supplies verified support and limits to the outline and draft.
Outline	Governing premise, intended reader outcome, component contracts, dependencies, examples, and handoffs	Create after initial research; revise when architecture changes	Supplies the implementation plan for each draft.
Draft	The reader-facing implementation and receipts	Write serially; revise after every accepted finding	Supplies text to each review stage.
Process log	Consequential decision, reason, affected artifact, and rejected alternatives worth preserving	Update after a material scope, evidence, terminology, or workflow decision	Supplies selected cases to retrospectives without becoming reader-facing prose.
Style guide	Durable rule, rationale, examples, boundary, and authority	Promote a rule after repeated or consequential editorial evidence	Supplies relevant author guidance to later drafts and revisions.
Audit	Consumer contract, finding, evidence location, consequence, smallest fix, and resolution	Run after the complete draft exists and rerun after repairs	Supplies accepted repairs or explicit risk decisions to release review.
Companion candidate	Independent reader, governing question, evidence need, and disposition	Record when useful material exceeds the current scope	Becomes notes, a rejected idea, or a standalone essay contract.
Skill	Trigger, required inputs, ordered procedure, output contract, and boundaries	Extract only after the method succeeds repeatedly	Supplies a reusable procedure without replacing author judgment.

No artifact substitutes for another. A process log is not reader-facing prose. A source dossier is not a finished analysis. An audit is not an author. Keeping those responsibilities separate made the system easier to revise.

A Reusable Workflow

The project did not follow a perfectly linear process. Research changed the outline. Drafting exposed missing research. Review created new companion ideas. Publication revealed navigation needs. The sequence was recursive, but it was not shapeless.

Looking back, the reusable path is the process I was taught for writing papers in school. Define the premise. Research the subject. Plan the points into a structure. Write the draft. Read it critically and edit it yourself. Ask someone else to review it and offer critiques. Revise it again. Conduct a final review. Submit the paper.

AI changed the speed, scale, and visibility of that work. It did not replace the underlying discipline. Our version looked like this:

1. Define the reader, premise, and outcome. Know who should choose the piece, which foundational proposition it will establish, and what should become possible for the reader.
2. Research before drafting. Record each source’s contribution, intended use, and inference boundary, not just its link.
3. Plan the points into a structure. Give every component a responsibility, prerequisites, outcome, and handoff.
4. Write the draft. Work serially so accepted editorial decisions can improve the next chapter.
5. Read critically and self-edit. Inspect the reasoning, control the scope, and preserve repeated editorial judgments in the style guide.
6. Invite outside critique. Use developmental, architecture, and cold-start reviews to expose failures the author and collaborator can no longer see.
7. Revise again. Apply accepted critiques in small changes, then inspect the affected relationships.
8. Conduct the final review. Check evidence, links, mechanics, terminology, rendering, and navigation.
9. Publish the work. Release it when it fulfills its purpose, knowing that later evidence or better examples may justify another edition.

Only after the process had worked repeatedly did we add a step my school assignments never required: extract the proven procedures into templates, audits, and skills that other work could reuse.

The most important lesson is not that AI can help write a long essay. That is already obvious.

The lesson is that AI collaboration improves when the work has visible architecture and explicit authority. Sources need assigned roles. Chapters need contracts. Editorial objections need to become durable guidance. Rejected material needs somewhere to go. Reviews need to inspect the whole as well as the sentence.

The finished essay argues that technical practitioners should write their articles with the same discipline they bring to software. The project became convincing only when its own construction followed that advice.

Receipts

• The finished parent essay. The Architecture of Nonfiction is the reader-facing result of the process described here.
• SOLID principles and acronym. Robert C. Martin’s “SOLID Relevance” presents the five principles, while a publisher-hosted history of SOLID supports the attribution that Martin assembled and popularized them and Michael Feathers gave the group its acronym.
• SOLID beyond classes. Part III of Martin’s Clean Architecture explains that the principles apply to coupled groupings of functions and data rather than only to conventional object-oriented classes.
• Writing practice and code. Andy Hunt and Dave Thomas’s The Pragmatic Programmer tips extend programming discipline to English and documentation.
• Argument hierarchy. Barbara Minto’s Pyramid Principle organizes supporting ideas beneath a governing point.
• Reader context. Herbert Clark and Susan Haviland’s “Comprehension and the Given-New Contract” explains how readers integrate new information with shared context.
• Modular technical communication. Adam Strantz’s “Modularity” describes content modules through dependencies, reuse, independent updating, and composition.
• Revision as structural work. Nancy Sommers’s “Revision Strategies of Student Writers and Experienced Adult Writers” distinguishes word-level correction from revision that reconsiders meaning and structure.
• Professional editing roles. Editors Canada’s Professional Editorial Standards distinguishes structural editing, stylistic editing, copy editing, and proofreading responsibilities.
• Long-form AI planning. PLANET addresses the gap between fluent passages and coherent long-form generation through planning.
• Context-aware revision. XtraGPT evaluates document-context use during paragraph-level revision. It does not evaluate the author-specific style-guide implementation described in this project.
• Applied engineering practice. The Disciplined Codebase and Boundaries Preserve Optionality supply first-party examples of the engineering discipline and boundary decisions carried into the writing process.