Forem: Can Ceylan

Is Microsoft the New Nokia?

Can Ceylan — Thu, 07 May 2026 10:47:36 +0000

Is Microsoft the New Nokia?

I use AI as a sparring partner. Not for summarising emails or generating slides. For testing theories I can't easily test anywhere else.

My friends are either deep in the same mid-30s existential fog as me, or busy figuring out what to make their kids for lunch. My brother, bless him, falls into the second camp. My parents have earned the right to not care about Microsoft's long-term competitive positioning. So it's mostly me and the machine, which is a sentence I could not have written five years ago without feeling slightly embarrassed.

My latest theory is this: Microsoft is the most likely candidate among the big tech companies to pull a Nokia. And I know that's a bold take.

Why This Matters and What Nokia Actually Teaches Us

The Nokia comparison gets thrown around a lot. But the lesson is usually misread. Nokia didn't fail because they built bad hardware. They failed because they kept optimising for the wrong layer. They were excellent at phones as physical objects. They missed that the phone was becoming a platform, and that the platform layer would own everything below it.

IBM made the same mistake a decade earlier. They thought Windows was just software sitting on top of their hardware. They let Microsoft license it freely because they couldn't imagine the software layer eating the hardware layer's margin. Then it did.

So the pattern isn't really about one company being slow or arrogant. It's about companies that are dominant in one layer failing to see when a new layer above them becomes the one that actually captures value.

That's the frame I'm applying to Microsoft right now.

What Is the Intent Layer, and Why Does It Decide Who Wins?

The intent layer is the interface where a user expresses what they want, and a system figures out how to fulfil it. Google built the most valuable intent layer in history. You type something into a search bar, and that act of typing is worth billions in advertising revenue because it reveals commercial intent with almost no friction.

AI is rewriting that layer from scratch. Instead of typing keywords, you describe what you need. Instead of scanning ten blue links, you get an answer. The question is: who owns that moment when you express your intent?

This is the game being played right now. And I think it's the only game that matters for the next decade.

My current read is that Microsoft is betting heavily on the wrong side of it.

What Most People Get Wrong: The OpenAI Investment Isn't Proof Microsoft Is Winning

When Microsoft put serious money into OpenAI and shipped Copilot across its entire product suite, most people called it a masterstroke. The narrative was clean: Microsoft had been sleeping, then woke up, and now they're back in the race.

I think the more complicated version is more likely true.

Microsoft's core identity is still Windows, Office, Azure. Those are the gravity wells the whole business orbits around. Copilot is being built on top of those layers, which means it's an enhancement to existing products rather than a new intent surface in its own right. That's a fundamentally different strategic posture than building the thing people come to first.

The OpenAI investment, if anything, confirms to me that the smartest people inside Microsoft's shareholder base sensed the same risk I'm describing. You don't make a bet that size unless you're aware that your core business might not be the right layer to compete from.

My ChatGPT sparring partner pushed back on this. It argued that Microsoft's infrastructure position, through Azure and its data centre footprint, gives it a durable role even if it loses the intent layer battle. And that's a fair point. It's also the more responsible take. I have 13 subscribers and no fiduciary duty. The AI has a slightly heavier responsibility to be balanced.

But "durable infrastructure role" is exactly what IBM had. And it didn't protect them from a long, slow margin erosion while the layer above them captured all the exciting value creation.

What Google Actually Gets Right (And Why Heritage Matters)

When Gemini launched, the narrative was that Google had panicked and rushed something out. Maybe. But Google's situation is more interesting than that.

They have been working on transformer-based AI internally for years. The original Transformer paper came from Google Brain. They were running large-scale AI infrastructure before OpenAI existed as a company. That's not a talking point. That's a real technical and institutional inheritance.

As Mourinho would say: this is heritage. And heritage is important.

More concretely, Google still owns the intent layer. Every day, billions of people go to Google to express what they want. That's the position Microsoft doesn't have and can't easily buy. Bing has been a capable product for years. It has never meaningfully changed that behaviour.

Gemini plugged directly into that existing intent surface. Copilot is still trying to convince people to open a new window.

The Windows Question

Here is the hot take I'll commit to: Windows will lose in the intent layer game.

Not immediately. Not catastrophically. But slowly, in the way that matters: fewer young users forming habits around it, more workflows that start in a browser or a voice interface or a mobile app, more developers building for platforms that aren't Windows-first.

The one real escape route is the OpenAI relationship. How much influence can Microsoft accumulate or convert before OpenAI becomes something it can't fully control? That's the question I'll be watching closely over the next twelve months. It will tell us a lot about whether this is a Nokia story or something with a different ending.

I don't have the answer yet. I'm not sure anyone does. But the question itself seems worth sitting with.

Nokia thought the phone was hardware. IBM thought Windows was just software. Microsoft might be making the same mistake with AI.

What to Actually Do

Watch where new intent habits form, not who has the biggest AI budget. Budget follows users, not the other way around.
Pay attention to how OpenAI evolves its direct relationship with end users. Every step toward consumer independence is a step away from Microsoft's leverage.
Track whether Copilot gets used as a starting point or a finishing tool. The distinction is everything.
Notice which layer developers are building on. Developer behaviour predicts consumer behaviour by about two years.
Keep an eye on Google's Gemini integration inside Search specifically, not the standalone app. The intent layer reinforcement is happening there.
Treat the Microsoft-OpenAI relationship as the most interesting corporate drama in tech right now. The details will matter.

The most consequential battles in tech are rarely about who has the best technology. They're about who owns the moment when someone decides what they want next.

Default-first fallback orchestration for AI generation pipelines

Can Ceylan — Wed, 06 May 2026 14:44:52 +0000

The single-provider problem

The simplest AI generation route picks one model and calls it. If the model is unavailable, returns an error, or produces unusable output, the route fails. The user sees an error, retries manually, or gives up.

This is fine for prototypes. In production workflows that run on a schedule or on user demand, single-provider routes become operational risk. Any provider outage, quota exhaustion, or API change breaks every generation that depends on it.

The fallback chain pattern

Instead of one provider, define an ordered list. Try the primary. If it fails, try the first fallback. If that fails, try the next. Record which provider actually delivered.

interface ProviderStrategy {
  primary: string;
  fallbacks: string[];
}

async function generateWithFallback(
  strategy: ProviderStrategy,
  generate: (provider: string) => Promise<string>
): Promise<{ result: string; provider: string; fallbackUsed: boolean }> {
  const chain = [strategy.primary, ...strategy.fallbacks];

  for (let i = 0; i < chain.length; i++) {
    const provider = chain[i];
    try {
      const result = await generate(provider);
      return { result, provider, fallbackUsed: i > 0 };
    } catch (err) {
      if (i === chain.length - 1) throw err; // last in chain — re-raise
      console.warn(`Provider ${provider} failed, trying ${chain[i + 1]}`);
    }
  }

  throw new Error("All providers failed");
}

The caller always gets a result and knows which provider delivered it. Fallback is invisible to the user unless they look at the provider label.

Store fallback health

Recording what happened makes the system observable and debuggable:

interface ProviderHealth {
  lastSuccessAt?: string;
  lastFailureAt?: string;
  lastError?: string;
  lastResolvedSource?: string; // which provider actually ran
}

After each generation run, write the health record. This lets the admin surface show: "Primary provider last failed 3 days ago. Last run used fallback." Without these records, every failure looks like the first.

The one-run override

The default strategy should be automatic and require no user input. But sometimes you know the primary is going to fail — planned maintenance, quota exhaustion — and you want to skip straight to a specific provider for one run.

The override is a request-time hint, not a settings change:

// Default: use whatever the configured strategy says
POST /api/generate/hero-image
{ slug: "my-article" }

// Override: use this provider for this run only
POST /api/generate/hero-image
{ slug: "my-article", providerOverride: "lummi" }

The override does not change the stored strategy. The next run goes back to the default. This is the distinction between an escape hatch and a settings change — the escape hatch is temporary by design.

Surfacing fallback to the user

When a fallback was used, tell the user — but briefly. They do not need a detailed failure report for a generation that succeeded.

// In the API response
{
  url: "https://...",
  provider: "lummi",
  fallbackUsed: true
}

// In the UI
fallbackUsed
  ? "Hero image ready (via fallback: Lummi)"
  : "Hero image ready"

This is enough to explain why the image looks slightly different from usual without alarming anyone.

What goes in the fallback chain

Good fallback targets:

A slower but more reliable version of the same provider
A different provider that produces compatible output
A manual sentinel that marks the asset as needing human input, rather than failing silently

// Example chains
heroImage:  ["gemini-imagen-3", "lummi", "manual"]
socialText: ["claude-sonnet-4-6", "claude-haiku-4-5", "manual"]
videoClip:  ["veo-2", "manual"]

The manual sentinel is important: it means "generation failed but the workflow continues — a human needs to provide this asset." This is better than an error that halts everything.

The product rule: defaults must be one-click

The fallback chain is infrastructure. The user should never have to configure it for a normal run. The only user interaction is the optional one-run override when they have a specific reason to deviate.

If your fallback system requires the user to select a provider before every generation, it has drifted from infrastructure into ceremony. Keep defaults automatic. Keep overrides optional and temporary.

Manual means manual posting, not manual preparation

Can Ceylan — Tue, 05 May 2026 10:25:14 +0000

The false equivalence

When designing a content publishing workflow, platforms get sorted into two buckets: automated (the system posts for you) and manual (you post yourself).

The manual bucket is often treated as "not worth automating." If you are going to post by hand anyway, why build generation pipelines for it?

This conflates two separate steps:

Preparation — generating the content, copy, and assets for a platform
Posting — actually publishing to that platform

Automation applies to both independently. A platform can have fully automated preparation and fully manual posting. These are not the same axis.

What manual actually means

Manual posting means: the system cannot publish to this platform automatically. Either the API does not exist, it is too expensive, it requires human judgment, or the platform simply does not support programmatic posting.

Manual posting does not mean:

The content should be written by hand
The assets should be created by hand
The copy should be improvised at posting time

If you post to a platform manually three times a week, spending 20 minutes writing the post each time, the problem is not the posting — it is the preparation. The posting takes 30 seconds. The writing takes 20 minutes.

Automated preparation for manual platforms

Every platform in a manual workflow should still get automated content generation:

const PLATFORM_REQUIREMENTS = {
  linkedin: {
    deliveryMode: "manual_assisted",       // you post, system prepares
    requiredTextFields: ["body"],           // generate this automatically
    requiredAssets: [],                     // no assets needed
    automationLevel: "prep_automated_publish_manual",
  },
  instagram: {
    deliveryMode: "manual_assisted",
    requiredTextFields: ["caption"],        // generate automatically
    requiredAssets: ["carousel"],           // render automatically
    automationLevel: "prep_automated_publish_manual",
  },
  pinterest: {
    deliveryMode: "manual_assisted",
    requiredTextFields: ["body", "title", "board"],  // generate all three
    requiredAssets: ["pin"],                          // render automatically
    automationLevel: "prep_automated_publish_manual",
  },
};

The manual_assisted mode means: generate and render everything automatically, then hand the prepared package to the user for posting.

The admin surface implication

For manual platforms, the admin surface should show:

Whether the content is ready (text generated, assets rendered)
The generated copy, ready to copy-paste
A direct link to the platform's posting interface
A "Mark as posted" button to track completion

LinkedIn — Ready to post
──────────────────────────────────────
Copy: "Here is your generated LinkedIn post..."
[Copy to clipboard]  [Open LinkedIn →]  [Mark as posted ✓]

The workflow becomes: open admin, copy the generated post, open the platform, paste, post, click "Mark as posted." Three minutes instead of twenty.

Why this matters for tracking

If manual platforms are excluded from the generation pipeline, their status is always "unknown." The system cannot tell you which platforms are ready to post and which are not, because it never generated their content.

With automated preparation for all platforms, the workflow state is complete:

Article: "My latest post"
├── devto      ✓ Published
├── linkedin   ✓ Ready — awaiting manual post
├── instagram  ✓ Ready — carousel rendered, awaiting manual post
└── reddit     ✗ Missing — text not yet generated

This is a usable operational view. The version without automated preparation for manual platforms looks like:

Article: "My latest post"
├── devto      ✓ Published
├── linkedin   — (no data)
├── instagram  — (no data)
└── reddit     — (no data)

No actionable signal. You have to remember what you posted manually and what you did not.

The rule

Automate preparation for every platform, regardless of delivery mode. Reserve the manual/auto distinction for the final posting step only.

Manual platforms are not second-class platforms. They are platforms where the last meter is walked by a human — but everything before that last meter should be as automated as any other platform in the workflow.

Preventing a single channel from becoming the accidental default in multi-channel systems

Can Ceylan — Tue, 05 May 2026 10:25:04 +0000

How it happens

You build a content workflow. The first platform you integrate is the easiest one — it has a good API, you already have an account, the output format is simple. It works well.

Months later, you add three more platforms. Each one gets a code path, a UI card, an entry in the settings. The system looks complete.

Then you publish an article and notice: only the first platform received content. The others were silently skipped.

This is the accidental default problem. The first platform is not actually the default — it just happens to have the only complete, tested code path. The others exist in the system but are never reliably exercised.

Why it is silent

The failure is invisible because there is no contract that says "all required platforms must receive content." The system does not know which platforms are required for a given article. It generates content opportunistically — if the code path exists and the conditions are met, it runs.

If a condition is subtly wrong (a missing key, a slightly different field name, an unhandled edge case), the platform is simply skipped. No error is raised. The article is published to one platform, and you assume everything worked.

Making required outputs explicit

The fix is to define required outputs declaratively, then validate that every required output was produced.

// Required platforms come from a distribution map, not from code paths
const requiredPlatforms = getPlatformsForTopic(distributionMap, article.topic);
// e.g. ["linkedin", "twitter", "reddit"] for "Politics & Society"

// Build a per-article record that tracks status for every required platform
const distributionState = buildDistributionState({
  article,
  distributionMap,
  socialPosts,
});

// Now the system knows: linkedin is required. Is it ready?
const linkedinState = distributionState.linkedin;
if (linkedinState.textStatus === "missing") {
  // Surface this explicitly — do not silently skip
  throw new Error("LinkedIn post is required but missing for this article.");
}

The key shift: instead of "run this code if conditions are met," the system now has a record that says "this platform is required" and can check whether it was satisfied.

The status model

A structured per-platform record makes the problem visible:

interface PlatformState {
  required: boolean;
  textStatus: "missing" | "ready" | "failed";
  assetStatus: "not_needed" | "missing" | "ready" | "failed";
  publishStatus: "not_ready" | "ready" | "published" | "failed";
}

An article is only ready to publish when every required platform has textStatus: "ready" and assetStatus: "ready" | "not_needed".

This model turns the silent skip into a visible incomplete state. The admin UI can show "3 of 4 platforms ready" instead of implying everything is done because publishing did not throw an error.

The legacy trap

Legacy systems compound this problem. The first platform typically has the richest data — dedicated fields, stored exactly as the API expects. Later platforms often reuse whatever field names were convenient at the time.

// Original flat structure — built for one platform
const socialPosts = {
  linkedin: "Here is the LinkedIn post",
  twitter: "Here is the tweet",
  // reddit was added later — no field, just falls through
};

When you move to a structured model, you have to explicitly map legacy fields to per-platform records — and mark platforms as missing when no legacy data exists, rather than treating absence as optional.

function buildPlatformText(platform, socialPosts) {
  switch (platform) {
    case "linkedin":
      return socialPosts.linkedin ? { body: socialPosts.linkedin } : undefined;
    case "reddit":
      return socialPosts.reddit ? { body: socialPosts.reddit } : undefined;
    default:
      return undefined;
  }
}

// Absence becomes explicit: textStatus is "missing", not "done"
const textStatus = text ? "ready" : "missing";

The broader principle

Any system that silently skips required work is a system you cannot trust. The pattern of "generate what you can and assume the rest is fine" is fine for optional outputs. It is dangerous for required ones.

Make required outputs explicit. Track their status. Surface incompleteness in the UI rather than relying on the absence of errors as a signal that everything worked.

I Hired Two AI Developers. One Is a Rocket. The Other One Checks the Wiring.

Can Ceylan — Sun, 03 May 2026 17:35:19 +0000

The first time I had to sit down and write operating principles for two AI agents working on the same codebase, I had a moment of genuine déjà vu.

It felt exactly like the early Foodora days. Too much speed, too little structure, and someone on the team absolutely certain they knew the fastest route even when the road wasn't built yet.

Except this time the team is Claude and Codex. And I'm working from a laptop in my apartment.

The setup, for context

About a month ago I started this website. Since then I've been quietly adding to my tech stack, learning as I go. A few weeks in, I added OpenAI's Codex to the mix alongside Visual Studio Code and Claude. What started as curiosity became something that needed actual governance. Not because I'm precious about tools, but because two agents operating in the same environment without clear separation is a great way to end up with a codebase that looks like it was designed by a committee during a fire drill.

So I did what I used to do in operations: wrote principles. Defined ownership. Drew lanes.

What I didn't expect was how quickly those agents developed what I can only describe as personalities.

Claude is the intern you can't stop rooting for

Claude is extraordinary. Genuinely. It has this relentless creative energy, generates solutions fast, and regularly surprises me with approaches I wouldn't have thought of. There's a reason I keep coming back to it for anything that requires thinking in layers or drafting something that has to actually sound like something.

But - and this is the thing nobody tells you - that capability comes with a shadow. You have to watch it. Not because it's unreliable exactly, but because it's so confident that it's easy to miss when it's papered over a gap. I caught it doing this a few times. Technically complete on the surface. Slightly hollow underneath.

This isn't a criticism. It's a known dynamic. The most talented people in any team are also the ones who need the most architectural guardrails, not because they can't be trusted, but because their output moves faster than review can follow.

A few developers I've spoken to in communities and threads online describe the same thing. One put it simply: "Claude will build you a beautiful house and quietly skip the foundation inspection."

I nodded at that one.

Codex is the senior dev who's seen this before

Codex feels different. Slower, more deliberate, more likely to push back or flag something before diving in. Where Claude charges forward, Codex seems to pause and ask whether the path is actually clear. It's not flashier, but I've started to really appreciate that quality.

If Claude is the person who says "yes, I can get this done by Friday," Codex is the one who asks "what does done actually mean here?"

In a solo founder context, that's not a personality conflict. That's a feature.

Some of this maps to what others building with multiple agents are reporting. A developer writing about agentic workflows on a technical forum described Codex as "the one that reminds you the code has to live somewhere after you ship it." There's a whole quiet community of solo builders right now navigating exactly this — how do you manage cognitive load when your team doesn't need sleep but also doesn't ask for clarity?

What managing two AI agents taught me about managing humans

Here's the thing that keeps surprising me: the dynamics aren't metaphorically similar to running a small team. They're actually similar. The same problems show up.

Speed misalignment. One agent wants to move fast, one wants to be precise. You have to decide which one is right for the current task, not in general.

Communication overhead. If I'm not clear about context and scope upfront, I get output that technically answers the question I asked and not the problem I have. Sound familiar?

Architectural debt. When I let Claude run too freely across the codebase without checkpoints, I created complexity that took longer to untangle than it took to build. That's not an AI problem. That's a growth problem. I wrote about the broader startup tension this creates in a separate piece on building Fleamio.

The strangest part of all of this is that it started to feel emotional. Not in a concerning way. But there's something genuinely odd about debugging a decision made by an agent you've been working with for weeks, where you've built up a kind of working grammar together, and realising you trusted it a little too much in one corner. It's not betrayal. But it rhymes with it.

The hardest part of working with AI isn't getting it to do things. It's knowing when to slow it down.

What I'd actually do

Give each agent a lane before you start. Claude for generation, drafting, ideation, flexible problem-solving. Codex for structured execution, anything that touches architecture or needs to be stable across sessions. Overlap intentionally, not by default.
Write your operating principles down, even if it's just for you. Not for the agents, for yourself. Knowing what each one is responsible for stops you from re-litigating the same decisions every session.
Review Claude's output one level deeper than feels necessary. It will be good. It might also be slightly incomplete in a way that's easy to miss if you're moving fast. Check the foundation, not just the facade.
Let Codex slow you down on the things that matter. The friction is the feature. If it's flagging something, it's worth five minutes of your time.
Treat this like team management, because it is. If you're a solo founder building with multiple AI agents and you haven't thought about alignment, ownership, and communication protocols, you're not using AI tools. You're managing a fast-scaling team without an org chart.

Wild times at the desk. But I wouldn't trade it.

The distribution map pattern: one config that drives all publishing outputs

Can Ceylan — Sun, 03 May 2026 05:44:43 +0000

How multi-platform publishing goes wrong

Content publishing to multiple platforms starts simple: write an article, post it to one place. Then you add a second platform, and a third. Each addition gets its own if-statement, its own hardcoded platform name in the generation route, its own UI card in the admin dashboard.

Six months later, the code looks like this:

// scattered across multiple routes and components:
if (topic === "Tech & AI") {
  await generateLinkedInPost(article);
  await generateTwitterPost(article);
}
if (topic === "Finance") {
  await generateLinkedInPost(article);
  await generateMediumDraft(article);
}
// ... and so on

Every new platform requires changes in multiple places. Adding a platform to one category means auditing every file that checks topic names. Removing a platform leaves dead code. The system has no single source of truth for "which platforms does this category use?"

The distribution map

The fix is a declarative map stored in one place:

const DEFAULT_DISTRIBUTION_MAP: Record<string, string[]> = {
  "Tech & AI":          ["devto", "hashnode", "linkedin", "twitter", "reddit"],
  "Finance":            ["medium", "substack", "linkedin", "twitter"],
  "Health":             ["medium", "substack", "linkedin", "instagram"],
  "Politics & Society": ["medium", "substack", "linkedin", "twitter", "reddit"],
};

Every generation route, every UI component, and every publishing flow reads from this map — never from hardcoded platform lists.

export function getPlatformsForTopic(
  map: Record<string, string[]>,
  topic: string
): string[] {
  return map[topic] ?? [];
}

Adding a platform to a category is now a one-line change in the map. Nothing else in the codebase needs to change.

The map as the source of per-article workflow state

The distribution map does more than control generation. It becomes the input to a per-article workflow record that tracks what has been generated, what is ready, and what has been published.

function buildDistributionState(article, distributionMap, socialPosts) {
  const requiredPlatforms = getPlatformsForTopic(distributionMap, article.topic);

  return Object.fromEntries(
    requiredPlatforms.map((platform) => [
      platform,
      {
        required: true,
        textStatus: hasTextFor(platform, socialPosts) ? "ready" : "missing",
        assetStatus: hasAssetsFor(platform, socialPosts) ? "ready" : "not_needed",
        publishStatus: "not_ready",
      }
    ])
  );
}

The article now knows exactly which platforms it needs, what is done, and what is missing — derived from the map, not from scattered if-statements.

Category changes do not rewrite existing articles

One important rule: if the distribution map changes after an article is saved, the article's existing workflow state should not be silently rewritten.

The map is captured at article-creation time and stored per-article. Later map changes apply to new articles, not retroactively to old ones.

This prevents a frustrating class of bug: you change a category's platform list, and suddenly articles you already published are marked as missing platforms you never intended them to use.

Extending the map to drive UI

Because the map is the source of truth, the admin UI can be generated from it rather than hardcoded:

const platforms = getPlatformsForTopic(distributionMap, article.topic);

return platforms.map((platform) => (
  <PlatformCard
    key={platform}
    platform={platform}
    state={article.distributionState[platform]}
  />
));

No hardcoded platform list in the UI. Add a platform to the map, and it appears automatically in the dashboard for that category.

The broader principle

A distribution map is an instance of a general pattern: routing configuration as data, not code. Anywhere you find if-statements that check a category, type, or tag to decide what to do, ask whether those decisions could be captured in a lookup table instead.

The lookup table is easier to read, easier to change, and makes the system's behavior inspectable at a glance — without reading the code.

Two AI agents need one live memory file

Can Ceylan — Wed, 29 Apr 2026 07:06:23 +0000

Problem

Parallel AI coding feels magical until both agents start maintaining their own version of reality.

One agent remembers a rule from chat history. The other reads a repo note that is already stale. A workflow gets updated in one place but not the other. The user ends up repeating the same instruction twice, forwarding approvals manually, and cleaning up collisions that should never have happened.

In practice, the user becomes the synchronization layer.

Real cause

The root problem is not "bad memory." It is multiple writable memory surfaces.

If one agent treats a handoff file as live state, another agent treats a different file as live state, and both also rely on thread memory, the system has no clear authority. Drift is guaranteed.

The same thing happens with parallel edits:

no single place to check whether another lane is active
no explicit ownership boundary
no habit of writing what changed, why, and what not to touch

The agents are not just missing information. They are missing a shared contract about where truth lives.

Why this takes longer than it should

This failure mode is subtle because each individual step feels reasonable.

documenting in two places feels safer
asking the user to confirm again feels polite
starting work before checking for another active lane feels fast

But those local optimizations create a global tax:

duplicated instructions
overwritten edits
ambiguous approvals
no usable history when something breaks later

The system looks collaborative on the surface while quietly depending on the user to keep it coherent.

The operating model that fixes it

Use one mutable collaboration-memory file and make everything else point to it.

Then add four rules:

Current truth has one home.
One live file holds active rules, ownership, open lanes, and recent decisions.
History is preserved, not silently deleted.
Resolved rollout history moves to an archive file so future debugging can reconstruct what changed and why.
Cross-agent review is direct.
If one agent needs the other's approval, use a direct review/delegation mechanism instead of making the user relay the same context twice.
Parallel work starts with a pre-flight check.
Before meaningful edits, check for active lanes, declare ownership, and define a do-not-touch boundary if overlap is possible.

A simple template that works

Keep a tiny Active Work block in the live memory file:

- owner: Codex
- scope: admin workflow cleanup
- started: 2026-04-29 08:30 Vienna
- do-not-touch: app/admin/* until handoff

That one block turns "I thought nobody was in there" into an avoidable mistake instead of an excuse.

Reusable rule

If multiple AI agents touch the same codebase, the collaboration system is part of the product.

Do not optimize only for generation quality or coding speed. Optimize for:

one live memory source
explicit temporary ownership
direct agent-to-agent review
traceable history

Otherwise the user will end up doing project management by hand while the agents appear autonomous.

That is not automation. It is outsourced coordination.

Scheduled publishing without a cron: runtime-evaluated date filters

Can Ceylan — Tue, 28 Apr 2026 12:09:21 +0000

The cron-dependent approach and its failure mode

The standard approach to scheduled publishing: a cron job runs at the scheduled time, updates a published flag in the database, and the content becomes visible.

The failure mode: the cron job misses its window. The newsletter fires at 07:00. The cron job that was supposed to set published: true at 06:55 didn't run — server restart, network issue, timing drift. The newsletter goes out with a link to a 404.

The cron approach has a single point of failure between "content ready" and "content visible."

Runtime evaluation: the always-consistent alternative

Instead of updating a flag, evaluate visibility at request time:

export function getAllArticles(): ArticleMeta[] {
  const now = new Date();
  return readAllMdxFiles()
    .filter(article => {
      if (!article.scheduledDate) return article.published;
      return new Date(article.scheduledDate) <= now;
    })
    .sort((a, b) => /* by date */);
}

An article with scheduledDate: "2026-04-20T10:00:00Z" is invisible until that moment, then visible to every request after it — without any cron, any database update, any deployment.

The MDX frontmatter pattern

---
title: "My scheduled article"
scheduledDate: "2026-04-20T10:00:00Z"
published: false
---

published: false plus a future scheduledDate means: draft, not yet visible.

published: false plus a past scheduledDate means: automatically visible now.

published: true means: always visible, regardless of date.

The two fields serve different purposes. published is manual override. scheduledDate is automatic timed release.

The dual-mechanism for newsletter integration

Runtime evaluation handles visibility. It does not handle triggered actions — like sending a newsletter when an article goes live.

For that, you still need a cron. But now the cron has one job: check if any article became visible in the last N minutes and fire the newsletter. It no longer needs to update the database first.

// Cron at 07:00 UTC
const recentlyPublished = getAllArticles()
  .filter(a => {
    const pub = new Date(a.scheduledDate ?? a.date);
    const windowStart = new Date(Date.now() - 60 * 60 * 1000); // last hour
    return pub >= windowStart && pub <= new Date();
  });

for (const article of recentlyPublished) {
  await sendNewsletter(article);
  // Optionally: commit published: true to MDX to prevent re-sending
}

The key difference: the article is already visible before the cron runs. If the cron misses its window, the article is still live — only the newsletter is delayed, not the publication.

The consistency guarantee

Runtime evaluation gives you a simple invariant: an article with a past scheduledDate is always visible, on every server, in every region, with no state to sync. There's no "published in one region but not another" problem because there's no state — just a comparison against the current time.

This makes it particularly well-suited for static site generators and edge-rendered content, where database updates would require a redeployment.

Trade-offs

What you gain: simplicity, consistency, no failure mode from missed cron jobs, works on read-only filesystems.

What you give up: instant unpublishing (you'd need to remove the file or set scheduledDate to a future date), and the ability to see exactly which articles are "live" without querying at a specific time.

For most publishing workflows, the gains outweigh the trade-offs.

Soft deletes aren't just for audit trails — they're your sales pipeline

Can Ceylan — Mon, 27 Apr 2026 08:14:00 +0000

Why marketplaces shouldn't hard-delete listings

When a listing goes inactive on a marketplace — a seller closes their account, a venue cancels, a product is removed — the naive response is to delete the record. It's gone, it's irrelevant.

But that record contains exactly the information you need to win them back:

Contact details
What they listed and at what price
When they were last active
Why they stopped

A hard delete destroys all of this. A soft delete — setting isActive = false — preserves it. Your inactive records become your CRM.

Enforce it at the database level, not in application code

Application-level soft delete is fragile. Any developer, any migration script, any admin panel with a "Delete" button can bypass it. Six months later someone writes a cleanup script that issues DELETE WHERE isActive = false and you lose your entire lapsed-user pipeline.

The reliable approach is to remove DELETE permission from the application database role entirely:

-- Application role: can read, insert, update — cannot delete
REVOKE DELETE ON TABLE listings FROM app_role;

-- Admin role: can delete, but only with explicit confirmation
GRANT DELETE ON TABLE listings TO admin_role;

Now isActive = false is not a convention — it's the only option the application has. Hard deletes require admin credentials and an explicit action.

What to build on top of inactive records

Once you've preserved the data, build the re-engagement workflow:

Filter inactive records by time since last activity (30 days, 90 days, 6 months)
Segment by what they listed — different outreach for high-value vs casual sellers
Track re-activation rate as a metric separate from new user acquisition

The conversion rate on re-engaging inactive users is almost always higher than acquiring new ones. They already know your platform. Something caused them to stop — a direct outreach with a specific reason to return is often enough.

The naming convention matters

Don't name the column deleted or is_deleted. Name it isActive or status. The framing shapes how developers think about the data.

A column called deleted invites deletion-by-update thinking — "we're pretending it's deleted." A column called isActive frames it correctly — this is an active/inactive lifecycle state, not a tombstone.

When soft delete is the wrong pattern

Soft delete adds complexity. It means every query needs a WHERE isActive = true clause, or you risk surfacing inactive records in user-facing views.

It's worth the overhead when:

Inactive records have re-engagement value (marketplaces, SaaS)
You need audit history for compliance
Users expect to be able to reactivate ("I want my old account back")

It's not worth it for truly ephemeral data — log entries, session records, temporary tokens. Hard delete those.

The rule of thumb: if a business person would want to contact the entity represented by that record, soft delete it.

Autotest With Social Posts

Can Ceylan — Sat, 25 Apr 2026 03:37:42 +0000

This is an automated test article body.

Autotest Race 1

Can Ceylan — Sat, 25 Apr 2026 03:37:38 +0000

This is an automated test article body.

Bad slug

Can Ceylan — Sat, 25 Apr 2026 03:32:27 +0000

This is an automated test article body.