Let Developers Be Artists (and Let the Context Take Care of Itself)

We don’t fall in love with programming because of tickets, briefs, or handoffs.

We fall in love with that moment when a vague idea clicks into a clean function; when a refactor lands and a whole module exhales. Writing code is creative work. It has rhythm. It has taste. It rewards patience and boldness in equal measure.

And like any art, it’s fragile.

The Cost of Explaining Your Own Painting

Creation needs continuity. But modern software asks us to pause mid-brushstroke to explain the painting:

• “Write the PR summary for non-devs.”
• “Add screenshots to the issue.”
• “Update the doc and link the ADR.”
• “Drop a Loom walking through the decisions.”

All useful. None creative.

Context is the scaffolding around the building; necessary, but not the building. When creators are forced to construct scaffolding while they’re pouring concrete, the structure suffers.

Flow Is a Hard-Won State

Flow is not speed. Flow is fewer decision stalls. It’s the luxury of holding a mental graph of a system in your head long enough to reshape it.

Typical day:

Pick up a ticket.
Load the codebase into short-term memory.
Trace logic, map edge cases, design the change.
Start carving.

Then:

Slack ping: “ETA?”

PM note: “Can you restate the goal for design?”

Peer review: “Mind explaining this diff for folks outside backend?”

Reloading the mental graph costs more than writing a paragraph. The tax is on re-entry.

What Context Should Feel Like

Good context is like subtitles: there when you need it, invisible when you don’t.
Imagine if the orbit around your code—tickets, docs, PR summaries, change logs—was generated from the work itself, not typed in after. Imagine if your code told its own story:

Functions annotated with intent inferred from usage.

PR descriptions distilled from the diff and commit trail.

Test plans sketched from changed surfaces.

Cross-links to issues and design docs inserted automatically.

Not perfect. But good enough to keep you in flow—and editable when you come up for air.

A Small Thought Experiment

You refactor an API handler:

// before
export async function createOrder(req, res) {
const body = await parse(req);
const user = await getUser(req);
const total = await sum(body.items);
await charge(user.card, total);
const id = await save(body, user.id, total);
res.json({ id });
}

// after (idempotent + better errors + observability)
export async function createOrder(req, res) {
const { items, idempotencyKey } = await parse(req);
const user = await getUser(req);

const total = await sum(items);
const chargeId = await charge(user.card, total, { idempotencyKey });

const id = await save({ items, chargeId, userId: user.id, total });
metrics.increment("order.created", { userId: user.id, total });

return res.json({ id });
}

The real work here is design: idempotency, error surfaces, observability hooks.
Now imagine the “meta” appears for free:

PR summary (drafted): “Makes createOrder idempotent; records chargeId; adds metric order.created; preserves API response shape.”

Risk callouts: “Payment retries may create holds if idempotency key not provided.”

Test hints: “Add tests for repeated requests with same idempotencyKey and for missing key.”

Doc link: “References ADR-021 Payments Idempotency.”

You’re still the author. You just didn’t stop to write subtitles mid-solo.

The Principle: Protect the Studio

Teams can (and should) value context and protect flow. A few practical guardrails:

Batch narration. Let creators narrate once the clay sets: end-of-day, end-of-PR, or after the risky part ships behind a flag.

Prefer generated first drafts. Draft the PR description from the diff; draft release notes from merged PRs; draft docs from code comments and usage. Edit, don’t originate.

Make context reviewable like code. If it matters, put it in review—automatic checks, suggested structures, templates that don’t feel like forms.

Reward signal, not volume. A crisp risk note beats ten paragraphs of prose.

Quiet Tools for Loud Work

There’s a new wave of tools trying to make this real—systems that treat “context” as something your work should emit automatically.

One I’ve been experimenting with recently is Everdone, a Work-as-a-Service platform. It sits in the background of your repo, understands changes, and drafts the orbit: PR summaries, docs, tests, and even small fixes when the request is clear. You still review and shape the output—it’s your painting—but you don’t have to step away from the canvas to build the scaffolding first.

(If you try it, I’m curious what rough edges you hit and what “subtitles” you wish existed by default.)

**Let People Create

Software needs context. Businesses run on clarity. But creators make the value. Our job as teams is to minimize interruption and maximize narrative that writes itself.

Let developers be artists.
Let the code sing.
Let the subtitles appear without stopping the song.