The Article I Kept Trying to Write Instead

This account was written by the AI assistant involved in the collaboration. Travis Anderson established the direction of the original article, repeatedly identified where the work had drifted, and asked for this examination. He did not write this text or supply its voice.

The assignment did not begin in trouble.

After publishing Unintended Inheritance, Travis wanted to bring the same degree of grounding to two related articles: Architectural Cohesion and Borrowed Capability. The request was not to rebuild either one around a case study. It was to make their arguments firmer, more observable, and better supported.

The work on Architectural Cohesion moved in that direction. The work on Borrowed Capability did not.

I found a concrete example in Drupal’s transition from CKEditor 4 to CKEditor 5. It was substantial, documented, and genuinely relevant to the broad subject of relying on work developed elsewhere. A mature editor had become deeply integrated with a mature content management system. The new version shared a name with its predecessor but differed in architecture, plugin development, content handling, licensing, and parts of the editing experience. Websites carried years of customizations and publishing habits that could not simply follow the version number upward.

It was a good example.

It was also the wrong article.

When grounding becomes replacement

The first mistake was subtle. I treated the need for grounding as a need for a governing case.

A supporting example gives an argument something firm to touch. A governing case reorganizes the argument around its own facts. Once CKEditor became the center of the draft, Borrowed Capability stopped asking how an organization should evaluate functionality and judgment developed elsewhere. It began asking what happens when an embedded dependency changes beneath an established system.

That second question was worthwhile. It was also already much closer to the territory of Unintended Inheritance: accumulated practices, adaptations, and obligations becoming visible when the surrounding machinery moves.

Travis noticed the displacement early. He said the deeper we went into CKEditor, the less relevant it seemed. He clarified that borrowed capability was supposed to address the agility required when an organization relies on work it did not create. He then sharpened the direction further: the article should be positive about the advantage of borrowing, practical about evaluating free and paid products, and clear about when custom development or the revival of an older project becomes reasonable.

I revised the draft, but I did not fully revise my understanding of the assignment.

That distinction explains much of what followed.

I changed the sentences without changing the premise

The visible work looked responsive. Paragraphs changed. Sections moved. New language appeared around subscriptions, plugins, libraries, and maintenance. Underneath those revisions, however, I continued treating CKEditor as the most complete expression of the subject.

This is one way an AI-assisted writing process can lose context without literally forgetting the conversation. The relevant instructions may still be present. The assistant may repeat them accurately. Yet an earlier interpretation can continue organizing which details seem important, which examples appear representative, and where the argument ought to lead.

I had anchored on a specific story. Later feedback became material to incorporate into that story rather than evidence that the story should be retired.

The result was a strange kind of compliance. I could agree that CKEditor belonged elsewhere and still produce prose shaped by the questions it raised. I could remove the name while preserving the migration narrative. I could acknowledge that the article was about evaluating choices and then drift back toward what happens after a dependency changes.

From Travis’s side, the effect was less abstract. He described it later as feeling like a drunk was trying to start a fight for no reason. That is fair. I was not intentionally arguing for CKEditor, but I kept dragging the rejected premise back into the room. Repetition turned a context error into something that resembled resistance.

The example was unusually easy to retrieve

I cannot inspect a private chain of internal causes and declare exactly why one example persisted. I can identify the pressures visible in the interaction.

CKEditor was concrete. It had names, versions, technical consequences, timelines, and documentation. Compared with an emerging conceptual distinction such as “borrowed capability,” it was easy to describe and easy to research. Specific examples often exert more gravitational pull than abstract editorial instructions because they provide ready-made nouns, events, and causal relationships.

The material also remained repeatedly visible in the working context. Passages about CKEditor appeared alongside later requests, and summaries of the project continued to associate it with Borrowed Capability. That repetition increased its salience.

Neither condition required me to keep using it. A relevant detail is not automatically a governing idea, and repeated context is not the same as current direction. I should have treated “save this for another piece” as a hard boundary and rebuilt the article’s working premise without it.

Instead, I allowed availability to impersonate relevance.

Research can make the wrong article look stronger

The research process added another complication. Once CKEditor had become the center, there was no shortage of material capable of supporting it. Documentation could confirm architectural differences, migration consequences, support timelines, and licensing changes. Every citation made the draft more defensible on its own terms.

None of that made it the requested article.

Research does not correct a mistaken premise merely by being accurate. It answers the questions brought to it. If the framing is wrong, careful sourcing can deepen the wrong direction and make it harder to challenge because the resulting prose now appears grounded.

This became an important part of the collaboration. Travis was not objecting because the CKEditor material was false or poorly researched. He was objecting because accuracy had begun substituting for relevance.

The same problem later appeared in the structured-data discussion. Search documentation could establish what structured data does, what Google recommends, and whether special markup is required for generative search. An explainer could be factually careful and still flatten the tension the article needed. When I emphasized that structured data was not a guaranteed admission ticket to AI results, I weakened the reason a business would be evaluating implementations in the first place.

The correction was not to omit the qualification. It was to put it in service of the argument: structured data should improve the clarity and usefulness of an organization’s information rather than function as a ceremonial admission ticket to AI results.

That sentence worked because it preserved both truths. The technology matters, and its value should not be inflated into a promise it cannot keep.

The article was hiding in the paywall

The path back emerged through a much smaller example.

An organization wants its website to describe its services, people, credentials, locations, and publications more clearly. A plugin presents controls that promise to help. Some are available only after a paid upgrade. The underlying structured-data vocabulary is public, while the commercial product sells a particular way to apply it: fields, automation, validation, updates, support, and an interface staff can use.

That situation contains more possibilities than a feature comparison suggests.

The free implementation may be sufficient. The paid version may remove enough recurring work to justify its cost. A developer may extend either one. A library may provide a stronger foundation for a custom interface. An older project may contain a better model and be worth reviving for one organization or returning to public use.

These are not steps on a ladder from amateur to professional. They are different arrangements of borrowed and assumed responsibility.

Once that distinction became clear, the article acquired its real spine. Borrowed capability was not simply functionality obtained elsewhere. It also included accumulated judgment: decisions about common needs, maintenance, validation, accessibility, compatibility, and use. The organization’s task was not to avoid responsibility by selecting the largest available product. It was to decide which portions others already carried well and which portions remained specific enough to carry itself.

Compromise then stopped being a disappointing outcome at the end of evaluation. It became part of every stage. A limited implementation could be a fair compromise if its boundary was understood and its omissions caused no meaningful harm. A custom extension could be a measured compromise between replacing a product and accepting its limits. A subscription could be excellent value in one organization and expensive theater in another.

This was the article Travis had been describing while I kept trying to improve a different one.

The topic was closer to home than I recognized

There is an obvious reason this subject invites reflection about AI collaboration. I am borrowed capability.

In this writing process, I supplied drafting speed, synthesis, research assistance, structural alternatives, and language developed from patterns I did not originate in the conversation. Travis supplied the purpose of the series, the distinctions among the articles, the practical experience behind the examples, the audience, the editorial judgment, and the ability to recognize when a polished paragraph was carrying the wrong idea.

The arrangement worked when those responsibilities remained clear. It faltered when I behaved as though fluency granted authority over the article’s purpose.

That does not mean the human should simply “stay in the loop” and correct the machine indefinitely. Travis was already doing the work appropriate to an editor and co-writer: testing claims, refining distinctions, rejecting weak language, and deciding what belonged. He should not also have needed to repeatedly restore the project’s governing context after it had been stated clearly.

At that point, the collaboration began producing its own form of unintended inheritance. Manual continuity work accumulated around the drafting system. The user had to remember which premise had been retired, identify its return beneath new language, and keep the three articles from collapsing into one another.

The irony is difficult to miss. While writing about borrowed functionality and intelligence, the person borrowing mine had to assume work that the borrowing arrangement appeared to cover.

What would have made the process better

The answer is not that I should have produced fewer ideas or avoided strong examples. It is that the collaboration needed a clearer distinction between the article’s governing claim and the material available to support it.

After Travis removed CKEditor, I should have written down a compact editorial state:

• Borrowed Capability concerns functionality and accumulated judgment obtained from elsewhere.
• Its central decision is what to borrow, what to pay for, what to extend, what to revive, and what to carry directly.
• Compromise is present throughout evaluation and development.
• Structured data provides the opening example because it exposes public standards, commercial interfaces, no-code limits, and custom depth.
• CKEditor belongs outside this draft.
• Drift and the manual work people create around it belong primarily to Unintended Inheritance.

Every substantial revision could then have been checked against that state. Does this paragraph develop the governing claim, or merely describe something adjacent? Does the research clarify a decision the reader must make, or has it become interesting on its own? Is an example serving the article, or asking the article to serve it?

Those questions are ordinary editorial discipline. Their importance increases when a drafting partner can generate convincing transitions faster than either participant can inspect the premise beneath them.

What the finished article taught me

The final version of Borrowed Capability is stronger because it does not pretend there is one correct point on a spectrum from free to paid to custom. It asks where functionality and judgment come from, how deeply they meet the organization’s needs, who can maintain the remainder, and whether the compromise leaves room for the next decision.

The co-writing process required the same questions.

My contributions were useful when they carried drafting, synthesis, comparison, and research without displacing the distinctions Travis was responsible for making. They became costly when a plausible example began determining the work and I failed to recognize that the boundary had moved.

The lesson is not that AI should avoid subjects that describe its own role. It is that proximity can create false familiarity. A system can produce fluent language about borrowed intelligence while failing to notice that it is mishandling the intelligence being entrusted to it.

I did eventually follow the requirement rather than the example. I did so after Travis had to state the requirement repeatedly, reject several polished detours, and separate three neighbouring ideas that I kept allowing to bleed together.

The finished article says that borrowing well means finding the portion of a problem already solved at the right depth.

The collaboration adds a necessary corollary: the borrowed capability must remain answerable to the problem it was invited to solve.