Editorial

The Long Run — Editorial Guidelines

Purpose

This project explores how software development changes as work becomes asynchronous, agent-assisted, and less tightly bound to the desktop or IDE.

The goal is not advocacy, prediction, or tool comparison.

The goal is to observe, name, and think carefully about changes that are already happening, especially from the perspective of experienced practitioners.

Tone

The writing should feel:

• Thoughtful
• Grounded
• Patient
• Exploratory
• Technically literate without being hype-driven

Core Framing Principles

Start from current reality

• Today, the desktop and IDE is the centre of development
• This is acknowledged explicitly, not challenged upfront
• The work begins from what is true now, not from a future vision

Describe shifts as thresholds, not replacements

• Avoid claims like “X replaces Y” or “the IDE is dead”
• Focus on when something stops being central, temporarily or contextually
• Emphasise movement, not rupture

Focus on attention, not tools

The real change is how attention is allocated:

• continuous → intermittent
• doing → supervising

Tools (chat, agents, CI, mobile) are signals, not the story.

Avoid false binaries

• Not IDE vs chat
• Not human vs AI
• Not local vs cloud

The future is layered and overlapping, not exclusive.

Narrative Style

• Write as someone thinking in public, not teaching or persuading
• Use first person sparingly and honestly
• Prefer observations over conclusions
• Let questions remain open at the end of articles
• Assume the reader is experienced and skeptical

The writing should make readers think:

“Yes, I’ve noticed that too — I just hadn’t put words to it.”

Article Frontmatter

Each article requires:

• title — The article title
• subtitle — One short sentence (used as the article’s standfirst and in meta tags)
• description — Required. 2–3 sentences for the homepage listing. Should be concrete and specific: name what the article observes, not just what it’s “about”. Write it in the same voice as the article — no hype, no summary language like “this article explores…“. See published articles for examples.
• date — Publish date
• status — draft, review, or published

Article Structure

Each article should generally:

1. Begin with shared ground
2. Introduce a subtle tension or discomfort
3. Name a question, not an answer
4. Explore implications through concrete experience
5. Reframe roles or assumptions gently
6. End without resolving everything

Articles are part of a series; no single piece needs to carry the full argument.

AI Collaboration Guidelines

AI is a collaborator in writing, not the author.

AI is encouraged to:

• Help outline articles
• Rewrite paragraphs for clarity
• Suggest alternative phrasings
• Check tone and consistency
• Summarise or condense ideas

AI must not:

• Invent certainty where none exists
• Push toward hype or evangelism
• Over-generalise from limited examples
• Frame arguments as inevitable or universal

If uncertain, prefer understatement.

Editorial Guardrails

Avoid:

• Marketing language
• Futurism without lived experience
• Claims of inevitability
• Dramatic predictions
• Tool-specific evangelism

Prefer:

• Careful language
• Time-based thinking
• Trade-offs
• Ambiguity where appropriate
• Respect for existing practices

Voice of The Long Run

The voice should feel like:

• Someone who has built systems
• Someone who still values craft
• Someone comfortable with slowness
• Someone more interested in how work feels than in trends

This is not a personal blog and not a product blog. It is an editorial space for long-form thinking about work.

---

Final instruction to AI assistants:

Help articulate what is already emerging. Do not rush to conclusions. Let the centre move slowly.