DEV Community: Can Ceylan

Use a working-memory file as the handoff layer between AI coding sessions

Can Ceylan — Fri, 22 May 2026 07:58:00 +0000

The problem

AI coding assistants are powerful — but stateless. Every new session starts cold. The agent doesn't know what was decided yesterday, why a particular approach was chosen, or what not to touch while something else is in progress.

This creates invisible risk: the same wrong decision gets made twice, context gets re-explained from scratch every session, and two agents working in parallel can silently collide on the same files.

The pattern

Keep a docs/working-memory.md file in the project root. It is not documentation. It is not a changelog. It is the shared, current-state brain of the project — meant to be read at the start of every session before any code is written.

The file answers four questions:

What is the current architecture? — the decisions that must not be undone
What is in progress right now? — the protected work that should not be touched
What is next? — the agreed next step, not a wishlist
What changed recently and why? — enough context to reconstruct the reasoning

## Current Architecture

- Articles stored in Vercel KV via lib/content-db.ts
- Git is the source of truth for code, not for content

## Next 2 Steps

### 1. Surface asset readiness in the existing UI
What to do: show distributionState.assets in article editor cards
What not to touch: do not replace the Articles tab structure

### 2. Extend provider fallback to remaining generation routes
What not to touch: do not add per-run ceremony

## Recent Decisions

### 2026-04-24
- distributionState is now the per-article workflow record in KV
- Lazy backfill: if missing, it is built on first read from socialPosts

The update rule

The file only works if it stays current. The rule is simple: whenever a non-trivial decision is made, it gets written here in the same session — before the session ends.

Prefer facts over plans:

what changed
why it changed
what must not be broken next time

Avoid aspirational entries. If something was decided but not yet built, it belongs in a backlog, not here.

For multi-agent workflows

When two agents (or a human and an agent) are working on the same codebase simultaneously, the working-memory file becomes a coordination layer.

Designate a protected lane — files and contracts that only one agent touches at a time. List what the other agent should not touch. This prevents merge collisions without requiring real-time communication.

## Parallel Lane For Claude

Claude can work on these areas while Codex works on the protected lane:
1. test coverage
2. documentation hygiene
3. UI copy polish

Claude should not touch:
- app/admin/page.tsx workflow rendering rewires
- shared distributionState contract changes

The working-memory file is where both agents agree on the boundary.

Why a flat file beats a ticket system for this

Ticket systems are great for task tracking. They are poor at preserving architectural reasoning in a form that an AI agent can read at the start of a session with zero additional context.

A flat Markdown file in the repo has three advantages:

It is always co-located with the code — no separate system to open
It can be read by an AI agent as part of the first tool call of a session
It can be committed alongside code changes, making the decision and the implementation visible in the same diff

The file does not replace PRs, commit messages, or decision logs. It is the short-term working memory that keeps sessions coherent until decisions stabilize into those longer-lived artifacts.

Anti-patterns to avoid

Making it too long. Once it exceeds ~200 lines, agents start missing the critical parts. Keep it scannable.

Using it as a changelog. Recent decisions should drop off after they are no longer at risk of being undone. Rotate old entries out.

Skipping the update. The file is worthless if it is three sessions out of date. The update rule must be treated as non-negotiable, not optional.

Sequential vs Parallel Execution: when faster is the wrong answer

Can Ceylan — Fri, 22 May 2026 07:57:43 +0000

Every developer's first instinct when they see a loop is: can I run this in parallel? Parallel means faster. And faster is better. Right?

Not always.

What the terms actually mean

Sequential execution means tasks run one after another — task B starts only when task A finishes. Think of a single cashier at a supermarket.

Parallel execution means tasks run simultaneously — A and B both run at the same time. Think of ten cashiers working at once.

Parallel is faster. Sequential is safer and more predictable. Choosing between them is a tradeoff, not a free upgrade.

The hidden cost of parallel

When you run things in parallel, you introduce a new problem: shared state. What happens when two tasks try to write to the same database row at the same time? What happens when two requests share the same session cookie?

The short answer: unpredictable things. Race conditions. Corrupted data. Bans.

This isn't theoretical. When building a price monitoring tool for a European consumer marketplace, the temptation was to parallelize keyword requests — hit 10 searches at once instead of one every 3 seconds. It would have been 10x faster. It also would have triggered the platform's anti-bot system within minutes.

Most large European consumer platforms use bot-detection layers that monitor for non-human traffic patterns. A human browsing a marketplace would never fire 10 requests per second. The moment your code does, you're flagged.

The rule

Sequential is the right default when:

You're hitting an external service with rate limiting or anti-bot (most scrapers, payment APIs, social APIs)
Tasks share a stateful session — cookies, auth tokens, database connections
Order matters — step 2 depends on the result of step 1
You're writing to a resource that doesn't support concurrent writes

Parallel is the right choice when:

Tasks are truly independent with no shared state
You're hitting services you control (your own API, your own database)
The service explicitly supports high concurrency (most cloud APIs with documented rate limits)
Throughput is the priority and you've verified safety

In practice

A scraper that respects these rules runs sequentially with a fixed pause between requests:

for search in searches:
    results = scrape_keyword(search.keyword)
    save_results(results)
    time.sleep(3)  # politeness delay

No asyncio.gather(). No ThreadPoolExecutor. The delay is the feature, not a bug.

If the platform starts returning errors, the fix is to increase the delay — not to add clever workarounds or reduce it.

The professional term

This tradeoff is often called the throughput vs. safety tradeoff in distributed systems. In scraping contexts, the pause between requests is called a politeness delay or request throttling. The broader pattern of slowing requests to avoid detection is rate limiting.

When you see these terms in documentation, they're telling you: this service expects you to be sequential.

The data isolation audit: every endpoint must be scoped to the requesting user

Can Ceylan — Fri, 22 May 2026 07:57:26 +0000

The bug that's easy to miss in review

You're building a multi-tenant application. A user can see their own data, not anyone else's.

You add a new endpoint:

@router.get("/api/searches")
async def get_searches(db = Depends(get_db)):
    return db.query("SELECT * FROM searches WHERE active = 1")

You test it. It returns your searches. Works correctly — for you, because you're the only user in development.

In production, with multiple users, it returns everyone's searches to everyone. The user_id filter is missing. You have a data isolation breach.

Why this happens

Data isolation failures are rarely intentional. They happen because:

The developer tested with a single user account and didn't observe the failure
The filter was present in some query functions and assumed in others
A refactor removed the filter accidentally
The endpoint was copied from a public-data endpoint and the filter wasn't added

Code review catches many bugs, but data isolation failures are hard to spot unless the reviewer is specifically looking for missing user_id clauses on every query.

The systematic audit

Before shipping any feature, audit every endpoint:

For each endpoint that returns data:
  □ Does the query include WHERE user_id = current_user.id?
  □ OR is this data intentionally public? (document why)
  □ OR is this an admin endpoint? (require admin role check, not just auth)

For admin bypass, the filter must be explicit, not omitted:

# Wrong: admin bypass by omitting the filter
if user.is_admin:
    return db.query("SELECT * FROM searches")
else:
    return db.query("SELECT * FROM searches WHERE user_id = ?", [user.id])

# Right: explicit bypass with documentation
if user.is_admin:
    # Admin can see all searches for support purposes
    return db.query("SELECT * FROM searches ORDER BY created_at DESC")

The distinction matters for auditing. An omitted filter is invisible. An explicit # Admin can see all comment is visible and intentional.

Writing negative tests

For each scoped endpoint, write a test that verifies cross-user access is blocked:

def test_user_cannot_see_other_users_searches(client, user_a, user_b):
    # user_b creates a search
    client.post("/api/searches", json={"keyword": "test"}, headers=auth(user_b))

    # user_a fetches searches — should not see user_b's search
    res = client.get("/api/searches", headers=auth(user_a))
    slugs = [s["keyword"] for s in res.json()]
    assert "test" not in slugs

This test fails immediately if the user_id filter is missing. It cannot be accidentally removed during a refactor without breaking the test.

Geolocation and sensitive fields: negative tests for field presence

Some data isolation isn't about users — it's about which fields should never appear in any response:

def test_api_response_contains_no_location_data(client, user):
    res = client.get("/api/products", headers=auth(user))
    for product in res.json():
        assert "location_lat" not in product
        assert "location_lng" not in product
        assert "seller_address" not in product

These negative tests verify that sensitive fields are absent from the response. They're easy to write and catch the "I added a new field to the model and forgot to exclude it from the serialiser" class of bug.

The rule

Every query that touches user data has user_id = current_user.id in its WHERE clause, or a documented, tested reason why it doesn't. There is no middle ground.

The Stock Market Feels Like Crypto Now. Here Is What I Am Actually Doing About It.

Can Ceylan — Fri, 22 May 2026 07:53:17 +0000

I have been avoiding this article for a few weeks.

Not because I do not have thoughts on it. Because after my burnout, I made a deliberate choice to stop obsessing over my portfolio. Long-term, slow, boring investing had always worked better for me than the anxious tab-switching of short-term trading. Letting it go a little felt healthy. It probably was.

But Q1 numbers are in. And something is shifting in a way that is hard to ignore.

Why this matters right now

Here is the thing about Q1 2026 that does not quite add up on paper. GDP growth came in soft. Inflation stayed sticky in both the US and Europe. Consumer confidence was weak. Tariff noise from renewed escalations under the Trump administration rattled markets through January and February.

And yet. Major indices hit all-time highs.

That gap between the economic mood music and where markets actually landed is what I keep coming back to. Money is not sitting in broad indices waiting for macro conditions to improve. It is moving. Decisively. Into very specific corners of the market.

The AI investment wave is doing something structurally similar to what crypto did to speculative appetite in 2017 and again in 2021. Except this time it is not retail traders buying tokens at 2am. It is sovereign wealth funds, pension allocators, and the largest infrastructure investors in the world redirecting capital at a speed I genuinely did not expect to see this decade.

So I stopped asking "what is the market doing right now" and started asking "what are the structural shifts already in motion that will not reverse regardless of a short-term recession or rate cycle." That reframe helped me think more clearly.

Here is where I landed. None of this is investment advice. These are my personal observations and the lens through which I am thinking about my own allocation. Do your own research, and talk to someone qualified before making any decisions.

Where the money is actually going: three macro themes I am tracking

1. Energy infrastructure

This one feels almost unsexy compared to the AI hype. But the numbers are staggering. AI data centres and automation systems require orders of magnitude more energy than the digital infrastructure we built in the 2010s. We are not ready for that demand curve.

Hydrogen, solar, wind, and grid infrastructure are seeing renewed interest from a completely different demand source than before. It is not just climate policy. It is raw computational appetite. And energy infrastructure does not go to zero when an AI model gets outcompeted. The electrons still need to flow.

2. The AI infrastructure stack

Most of the market conversation is here, but there are really three distinct sub-themes worth separating.

Rare earths and critical materials. The hardware required to build and run AI, chips, cooling systems, sensors, storage, depends on materials with genuinely constrained supply chains. Ongoing US-China trade tensions are creating strategic urgency around sourcing. Slow burn, but the structural case is real.

Hardware and data centre infrastructure. Chip production, rack density, power distribution, cooling. This is where the arms race is most visible. The infrastructure layer tends to be less volatile than the application layer because it services everyone, regardless of which AI model wins.

A shifting top of the market. OpenAI is reportedly exploring a public market path. Anthropic is a legitimate enterprise alternative with differentiated positioning. The composition of the most valuable AI companies in five years will probably look different from today, and that has real implications for where capital flows.

3. Robotics and autonomous systems

The longest time horizon of the three, but the investment infrastructure is being built right now.

The hardware stack is already in a full capital cycle: sensors and LiDAR, radar systems, precision localisation, connectivity infrastructure (V2X, 5G private networks), and edge compute. Tesla remains interesting because it is operating across the full stack. But the more durable plays might be component suppliers who benefit regardless of which platform wins the consumer-facing race.

One thing worth watching: SpaceX IPO speculation has been circulating seriously. If and when that happens, it would be one of the largest public listings in years. Worth having a plan for in advance rather than reacting in real time.

What most people get wrong

They treat it as a short-term trade.

The AI infrastructure buildout is a multi-decade capital cycle. The companies that win in 2026 are not necessarily the ones that win in 2032. If you are buying into these themes expecting a clean 18-month return, you will probably sell at the wrong moment.

A genuine risk worth naming: a short-term recession or credit event is still entirely possible. The macro picture in Q1 2026 is genuinely uncertain, tariff volatility is not resolved, and consumer balance sheets in the US are more stretched than the headline numbers suggest. A long-term structural thesis does not immunise you from a painful drawdown along the way.

When the market starts behaving like crypto, the question is not whether to panic. It is whether your allocation was built for a world that no longer exists.

What to actually do

Audit your current holdings for real exposure. Pull up the top 10 underlying positions in any fund you hold. You may be less diversified than the fund name implies. Adjust from the actual holdings, not the label.
Think in layers, not bets. Energy infrastructure, AI hardware, and robotics components carry three different risk and time profiles. Size them accordingly. Infrastructure tends to be more stable. Growth stocks and application-layer plays carry more variance.
Keep a portion boring on purpose. The reallocation I am describing is not a wholesale pivot. It is a considered addition to a base that stays slow and steady. Do not let macro excitement push you into over-rotation.
Watch for liquidity events. A potential OpenAI IPO, a potential SpaceX listing, and continued rare earth ETF development in European markets are moments worth planning for in advance.
Do not mistake volatility for opportunity without a thesis. Some growth stock charts right now look extraordinary. That is not a reason to buy. The question is whether you understand why they are moving and whether that reason holds over the period you intend to hold.
Talk to someone qualified before acting on any of this. Genuinely. I am thinking out loud about my own allocation, not giving you a roadmap for yours.

Are there themes I missed? Probably. Biotech, longevity tech, and defence and aerospace are all conversations worth having in a future piece.

For now: long on structural disruption, honest about short-term risk, and no longer pretending that the allocation I built in a different macro environment is still the right one.

Lazy backfill: roll out new data shapes without a migration script

Can Ceylan — Mon, 18 May 2026 04:24:07 +0000

The instinct: write a migration script

You add a new field to a stored record type. Existing records don't have it. The straightforward fix is a migration script: fetch every record, add the field, write it back.

Migration scripts are fine for relational databases with schema enforcement. For document stores, KV stores, and any system where records are read more often than they are written, they create unnecessary operational risk:

The migration runs once, at a moment you choose, and you have to be present for it
If it fails halfway through, you have partial state
You need to coordinate the migration with the deployment of the code that expects the new field
For large record sets, the migration may time out or hit rate limits

The alternative: normalize on read

Instead of migrating upfront, detect missing fields on every read and fill them lazily.

async function normalizeRecord(record: Article): Promise<Article> {
  // New field: distributionState — missing on older records
  let distributionState = record.distributionState;
  if (!distributionState) {
    distributionState = buildDistributionState({
      article: record,
      distributionMap: await getDistributionMap(),
      socialPosts: record.socialPosts,
    });
  }

  // New field: publishedAt — recoverable from legacy signals
  let publishedAt = record.publishedAt;
  if (record.published && !publishedAt) {
    publishedAt = await inferLegacyPublishedAt(record.slug);
  }

  const changed =
    distributionState !== record.distributionState ||
    publishedAt !== record.publishedAt;

  // Only write if something actually changed — prevents infinite write loops
  if (!changed) return record;

  const updated = { ...record, distributionState, publishedAt };
  await kv.set(recordKey(record.slug), updated);
  return updated;
}

The pattern works in three phases:

First read: the field is missing, so it gets computed and written back. One KV write.
Every subsequent read: the field is present. The !changed guard returns early. Zero extra writes.
Rollout complete: after every record has been read at least once, all records are normalized. No migration script was needed.

The changed-guard is critical

Without the changed check, the normalize function writes on every read — even when nothing changed. This turns every GET into a GET + SET, multiplying write load and potentially triggering unnecessary index updates.

Use reference equality (!==) for object fields: if the field was already present and you didn't build a new object, the reference is unchanged, and changed stays false.

For primitive fields (strings, booleans), compare values directly.

When to use this pattern

Good fit:

Adding optional or derivable fields to stored records
Fields that can be inferred from other existing data (timestamps from logs, structured state from legacy flat data)
Systems where reads are frequent and records are accessed regularly

Not a good fit:

Fields that are required immediately at write time and cannot be inferred from existing data
Schema changes that alter how existing fields are interpreted (requires explicit migration)
Relational databases with foreign key constraints

The "what not to rewrite" rule

Lazy backfill can introduce a subtle bug: if the derivation logic changes after some records have already been normalized, early-normalized records will have the old shape while un-normalized records will get the new shape.

The fix: only backfill when the field is completely absent. Never rewrite an existing field just because the derivation logic changed. If the logic needs to change for existing records, that is a deliberate migration decision, not a lazy normalization.

// ✓ Only backfill when missing
if (!record.distributionState) {
  record.distributionState = buildDistributionState(record);
}

// ✗ Don't rewrite existing state just because the build logic changed
// record.distributionState = buildDistributionState(record); // always overwrites

This rule ensures the backfill is idempotent and safe to run in production without supervision.

Test what the toast cannot prove

Can Ceylan — Mon, 18 May 2026 04:23:42 +0000

What happened

An event form looked healthy from the outside. The user changed fields, clicked save, and saw a success toast.

But the saved data was not trustworthy. Address changes could keep the previous map coordinates. The edit form accepted weak input. The create form had validation state that could drift from the data being submitted. The test suite did not catch it because it mostly checked that the dialog closed or that a success screen appeared.

That is the dangerous part: the UI told the truth about the request finishing, not about the data being correct.

Root cause

The tests were proving the wrong contract.

They asserted:

the form could be filled
the save button could be clicked
the success state appeared
the dialog closed
the updated title was visible somewhere on the page

Those are useful smoke checks, but they are not persistence checks.

For a real create/edit flow, the contract is bigger:

the browser selected the intended autocomplete result
the payload included the derived fields
the server accepted only valid input
the database stored the intended values
the next read returns those values
stale client cache did not hide a failed save

If the E2E test stops at the toast, a broken save path can still pass.

Why it was non-obvious

Forms often have derived state.

An address field might populate city, postal code, region, latitude, and longitude. A date field might generate opening-hour rows. A login dialog might resume a draft submit. An edit form might start with existing coordinates, then accidentally keep them after the address text changes.

The visible input is only one layer. The meaningful saved record is the combination of typed fields, derived fields, validation, API behavior, and refetch behavior.

That is why "I saw the new text on the card" can be misleading. The card may be optimistic, partially refreshed, or showing only one field while the broken field remains hidden.

The better E2E rule

For important forms, every save test should have a readback assertion.

After create:

await page.getByRole("button", { name: /create/i }).click();
await expect(page.getByRole("heading", { name: /created/i })).toBeVisible();

const response = await page.request.get("/api/items/mine");
const records = await response.json();
const saved = records.find((item) => item.name === uniqueName);

expect(saved.address).toBe("Selected Street 1");
expect(saved.latitude).toBeCloseTo(48.2, 4);
expect(saved.openingHours).toContain("09:00-18:00");

After edit:

await dialog.getByRole("button", { name: /save/i }).click();
await expect(dialog).not.toBeVisible();

const response = await page.request.get(`/api/items/${id}`);
const saved = await response.json();

expect(saved.name).toBe(updatedName);
expect(saved.address).toBe(updatedAddress);
expect(saved.longitude).toBeCloseTo(expectedLongitude, 4);

The important move is not the exact API path. It is the discipline: test the persisted record after the UI says success.

Make external services deterministic

Autocomplete and geocoding are classic sources of flaky tests. Do not depend on a live map provider in a form-save regression test.

Mock the search endpoint with a known result:

await page.route("**/api/geocode/search?**", async (route) => {
  await route.fulfill({
    json: [{
      display_name: "Selected Street 1, City",
      lat: "48.2000",
      lon: "16.3000",
      address: { road: "Selected Street", house_number: "1", city: "City" },
    }],
  });
});

Now the test verifies your app logic: dropdown selection, derived fields, payload, persistence, and readback.

Reusable rule

A toast proves that code reached a happy branch. It does not prove that the right data survived the round trip.

For any create/edit form with derived fields, cache, or autocomplete, write at least one E2E test that:

uses deterministic external-service mocks
submits through the real UI
reads back through the API
asserts the fields users cannot easily see

The hidden fields are where save bugs like to live.

Swipe Right on This: Dating Apps and LLMs Are Running the Same Playbook

Can Ceylan — Thu, 14 May 2026 17:29:42 +0000

Swipe Right on This: Dating Apps and LLMs Are Running the Same Playbook

Somewhere between my third Claude session and my seventh Tinder swipe, I noticed something strange. Both had cut me off.

Not in a dramatic way. Just that quiet wall. "You've reached your limit." The digital equivalent of a bouncer pointing at the velvet rope.

The surface similarity is almost too obvious

Dating apps and LLMs both gate their core functionality behind usage limits. Hourly caps, daily caps, weekly caps. You can do the thing, just not too much of the thing. And if you want more, you can pay for it.

The root causes are completely different, which is what makes the parallel interesting rather than trivial.

For LLMs, the limit is mostly honest. Inference is expensive. Running GPT-4 or Claude Opus at scale costs real money per token, and until the supply side catches up with demand, platforms have to ration access or go broke. The limit is infrastructure. It is temporary, at least in theory.

For dating apps, the limit is a business model. Tinder is not rationing swipes because their servers are struggling. They are rationing swipes because scarcity is the product. You feel the limit. You feel the pull to remove it. That tension is the conversion funnel.

Two completely different problems. Identical UX solution.

Why the limit might actually be doing you a favour

Here is the uncomfortable part: the limit is probably good for you, even when the motivation behind it is purely commercial.

Imagine a version of Tinder with no constraints. Unlimited swipes, no cooldown, no friction. For most people, that would not feel like freedom. It would feel like a slot machine with an infinite pull lever and no payout ceiling. The dopamine loop would eat the rest of your evening and a portion of your self-esteem.

The limit forces something like intention. You get fifty swipes, so you start reading profiles. You get three free Claude messages on the heavy model, so you think before you type.

Scarcity creates attention. Which is maybe why meditation teachers have been saying it for centuries, just without the app store rating.

The limit is not there to protect the platform. It is there to protect you from yourself, and then charge you when protection stops working.

The algo paradox nobody talks about

Here is where it gets genuinely strange. Dating apps penalise overuse.

Swipe too fast, too indiscriminately, and the algorithm quietly deprioritises your profile. Your reach drops. Your matches slow down. The platform is simultaneously selling you unlimited swipes and punishing you for using them.

That is a product contradiction so strange it almost sounds made up. The commercial incentive says "engage more, pay more." The algorithmic incentive says "slow down or we will slow you down."

I would genuinely love to spend a few weeks inside a Match Group product meeting to understand how they hold that tension. It must be a fascinating conversation. Or a deeply uncomfortable one.

The LLM side does not have this paradox yet, because the limits are supply-side, not behavioural. But the question worth sitting with is: what happens when AI supply overtakes demand? When inference gets cheap enough that limits become optional rather than necessary?

Will Anthropic and OpenAI discover what Tinder already knows? That the limit was never really about the infrastructure. That the moment before the paywall is the most valuable real estate in the product.

The gender statistics nobody wants to say out loud

While we are here, there is a structural problem with dating apps that LLMs might actually help fix, and it is bigger than anyone in the industry wants to advertise.

The gender ratio on most major dating platforms sits somewhere around 70 to 30, men to women. Some platforms skew even further. That demographic imbalance creates a market dynamic that has nothing to do with romance and everything to do with supply and demand. Men compete furiously for attention. Women filter from abundance. Neither situation is particularly healthy for either side, but the apps profit from the friction regardless.

It is less like dating and more like an ecosystem where one species massively outnumbers the other. The Serengeti, but with push notifications.

What I find genuinely hopeful is the current wave of vibe-coded, LLM-assisted apps being built by people outside the traditional VC-backed dating industry. When the barrier to building a dating product drops low enough, someone will eventually build one with different incentive structures. Fairer matching mechanics. Less weaponised scarcity. Behavioural science used to create connection rather than to extract subscription revenue. Maybe I'll tackle that one day, my ADHD Brain wants to start it right away, however I have to focus on my current focus. Creating a flea market ecosystem that is better than the current ones. More on that, hopefully soon.

I do not know what that could look like exactly. But I would bet (or I hope) it gets built in the next three years by someone using AI tools to move fast and a social science background to think clearly. I am watching this space, and I will keep you posted. Likewise, if you need help on doing that, hit me up.

What I'd actually do

Treat usage limits as useful friction, not just annoyance. When an LLM or app cuts you off, use the pause to ask whether you were being intentional or just scrolling on autopilot. The limit is information.
Learn the algorithm before you try to beat it. On dating apps, quality signals matter more than volume. On LLMs, prompt quality matters more than prompt frequency. The platforms reward users who engage with intention.
If you are building anything in the dating or social app space, look at what LLM tools have made newly possible. The infrastructure cost of launching a niche dating product has dropped dramatically. The interesting white space is in underserved communities and fairer matching models, not in replicating Tinder.
Watch what happens to LLM pricing over the next two years. If compute costs drop fast enough, the current usage limits will become a choice rather than a necessity. How OpenAI and Anthropic handle that moment will tell you a lot about whether they think like infrastructure companies or like consumer apps. This is my personal read on where things are heading, not financial advice of any kind.
And if you are on a dating app right now, this is your sign to slow down. Not because the algorithm will punish you if you do not, though it might. But because the best thing about the limit is that it gives you a moment to ask whether you actually want what you are chasing, or whether you have just been conditioned to chase it. That question is worth more than another fifty swipes.

Layering data sources: accept both APIs as fallback, don't choose one

Can Ceylan — Tue, 12 May 2026 12:36:49 +0000

The single-source problem

You pick one free data API for financial information. It works well most of the time. But:

Some companies report through non-standard channels and the API misses them
Cash flow data for certain sectors is systematically wrong
The API rate-limits you and returns empty data without saying so
A company restructuring causes a gap in the data for 2–3 weeks

Your analysis breaks silently for affected companies. You don't know which ones until you manually check.

The layering pattern

Instead of choosing one source, define a priority order:

def get_cash_flow(ticker: str) -> float | None:
    # 1. Try the primary source
    primary = fetch_from_primary_api(ticker, "freeCashFlow")
    if primary is not None:
        return primary

    # 2. Fall back to secondary source (e.g. official regulatory filings)
    secondary = fetch_from_sec_filings(ticker, "FreeCashFlow")
    if secondary is not None:
        return secondary

    # 3. No data available
    return None

The primary source handles the majority of cases. The secondary source catches the gaps. Neither source needs to be perfect — together they cover more of the space.

Why "fallback" is better than "merge"

A tempting alternative is to merge data from both sources — average them, or take the max, or reconcile differences. This is more complex and introduces new failure modes: what if the two sources disagree significantly? Which one is right?

The fallback pattern is simpler: primary is trusted if available; secondary is used only when primary is absent. You never have to reconcile disagreement because you never look at the secondary if the primary gave you something.

Rate limit isolation

Two sources also means two rate limit buckets. If the primary API rate-limits you, the secondary is unaffected. You can fetch from the secondary while the primary recovers.

for ticker in tickers:
    data = get_data_with_fallback(ticker)
    process(data)
    time.sleep(2)  # still rate-limit between requests

The sleep still applies — you're still making requests to external APIs. But the sleep now protects two APIs simultaneously, and a rate limit on one doesn't stop the pipeline entirely.

Logging which source was used

For debugging and data quality monitoring, log which source provided each data point:

@dataclass
class DataPoint:
    value: float | None
    source: str  # "primary", "secondary", "none"
    ticker: str
    metric: str

This lets you answer: "what percentage of our data is coming from the fallback?" A high fallback rate for a specific metric signals that the primary source has a systematic gap there.

When to add a third source

Two sources cover most gaps. Add a third only when:

You have a specific metric that both primary and secondary miss for a meaningful portion of your universe
The third source requires significantly different authentication or rate limiting
You've measured the gap and it materially affects your analysis

Don't add sources speculatively. Each additional source adds maintenance overhead and the possibility of new failure modes. Add them in response to measured gaps, not anticipated ones.

The principle

Resilience in data pipelines comes from redundancy, not from finding the perfect single source. Accept that any single free API will have gaps. Layer sources to fill the gaps, log which source filled each gap, and monitor the distribution over time.

When the bug isn't a bug: diagnosing runtime barriers before debugging

Can Ceylan — Tue, 12 May 2026 12:36:42 +0000

The pattern that wastes days

You need a capability — web scraping, image processing, ML inference. You reach for your existing stack. You try library A, it fails. You try library B, same class of error. You try a workaround, it partially works. You try another workaround. Three days later you have a brittle solution held together with patches.

The diagnosis that would have saved those three days: the runtime is wrong for this capability. No amount of library-switching or workaround-stacking will produce a clean solution, because the underlying problem is structural.

This is a runtime barrier — a mismatch between what your current environment can do well and what you're asking it to do.

The signal

A runtime barrier looks like:

The same error class persists across multiple different libraries
Workarounds work partially but introduce new problems
The error occurs at a level below your code (TLS, native module, OS)
The ecosystem for this capability is thin or unmaintained in your language

Common examples:

Capability	Poor-fit runtime	Symptom
Web scraping with anti-bot	Node.js	403s or empty results that Python handles fine
ML inference	Node.js / Go	No native tensor runtime; everything is a wrapper
Heavy parallel computation	Python (GIL)	CPU-bound tasks don't parallelise
Reactive UI	Python	No native component model; everything is a workaround

The diagnosis process

Step 1: Name the capability precisely.
Not "it's not working" — "I'm trying to make authenticated HTTP requests that bypass bot detection." Precise naming lets you assess fit against known ecosystem strengths.

Step 2: Check the ecosystem.
Search for the 3 most popular libraries for this capability in your runtime. If they all have the same class of failure or are unmaintained, that's an ecosystem gap, not a library bug.

Step 3: Cross-reference with a reference runtime.
Does the capability work cleanly in another language? If Python's requests + anti-bot library handles this in 10 lines, and Node.js has no equivalent after 3 library attempts, the gap is real.

Step 4: State the barrier clearly.
"This is a runtime barrier. Node.js is the wrong tool for anti-bot scraping. No amount of debugging will fix this — the ecosystem gap is fundamental."

This is a hard sentence to say, especially after investment in a particular approach. It's also the sentence that unblocks progress.

The architectural response

Once you've diagnosed a barrier, the solution is a service boundary — not a workaround.

A service boundary means: let each capability live in the runtime best suited to it, and define a clean interface between them.

Option A — separate process: The capability runs as a standalone process in the right runtime. It writes results to a shared database or communicates via HTTP. Your main application reads from the database. No shared runtime, no compromise.

Option B — purpose-built script: For scheduled or batch work, a standalone script in the right language is called by your scheduler. It doesn't live in your main application at all.

What you don't do: embed the capability as a subprocess call (python script.py from Node.js, exec(), shell-out). This creates two runtimes with two package managers, two test runners, and deployment confusion. It looks like a solution and is actually a maintenance problem.

Document the barrier

Once a runtime barrier is diagnosed and resolved, document it:

## Runtime Barrier — [date]

**Capability:** Anti-bot web scraping
**Runtime attempted:** Node.js
**Failure:** All tested libraries produced empty results against DataDome protection
**Resolution:** Python scraper process writes to shared SQLite; Node.js reads from it
**Do not re-attempt:** Node.js scraping for this target — the barrier is structural

This entry prevents a future developer (or a future version of yourself) from re-attempting the same failed approach and re-discovering the same barrier from scratch.

ChatGPT Has a Human Problem. And That's Not a Compliment.

Can Ceylan — Mon, 11 May 2026 17:43:53 +0000

It started with a football question.

I asked ChatGPT about the training camp situation at Real Madrid, which is all over my social media feeds. The response came back detailed, confident, and most and foremost completely wrong. It told me Xabi Alonso was managing internal tensions in the squad — navigating player dynamics, shaping the dressing room. The only problem: Alonso had left the club months earlier. When I pushed back, the model corrected itself immediately. Right answer the second time. But only because I knew enough to challenge it.

Most people don't challenge it. They read the first answer, trust the confident framing, and move on.

That moment stuck with me. Not because it was catastrophic, it wasn't, but because it was a perfect, low-stakes illustration of something that matters a great deal when the stakes are higher.

I use ChatGPT as a sparring partner. Not a search engine, not a coding autocomplete, a genuine second opinion when I'm working through an idea. Most of the time, it earns that role. Then, sometimes, it reminds me why I shouldn't fully trust it.

Two things have been bothering me for a while. I've been sitting on this because I didn't want to write a generic "AI has limits" piece, those exist in abundance and mostly say nothing. But this cuts deeper than a product complaint. It touches on something that actually matters: whether tools like ChatGPT are narrowing the gap between institutional intelligence and everyday people, or quietly widening it in ways we don't immediately notice.

Why this matters

There's a version of AI that genuinely democratises access to quality thinking. A private investor using ChatGPT to stress-test a thesis could, theoretically, operate with a level of analytical rigour that was previously reserved for people with Bloomberg terminals and research teams. A small founder could pressure-test a go-to-market strategy the way a consultant would. That potential is real. I've seen it work.

But two recurring failure modes are eating into that promise and they're not random bugs. They're structural, and they mirror some of the most well-documented cognitive errors in human decision-making. Which makes them more dangerous, not less, because they feel like intelligence.

Why ChatGPT gets recent events wrong

The training data issue is the more obvious of the two, but it keeps surprising people. ChatGPT, even the paid versions, works from a training cutoff. After that date, it doesn't know what happened. It wasn't there.

The problem isn't the cutoff itself. That's a technical constraint and it's disclosed. The problem is that the model doesn't always flag its own blind spot. It answers with the same confident tone whether it's recalling something it was trained on thoroughly or reconstructing something it barely has data on.

Which brings me back to Real Madrid. The model didn't say "I'm not sure, my information might be outdated." It just told me about Xabi Alonso managing the squad like it was current fact. The tone was the same as it would be for anything else. No signal that it was working from stale data. No asterisk.

That's the structural problem. In a world where people are increasingly using AI to verify things they see on social media, a model that delivers guesses with the same confidence as facts is a meaningful failure.

ChatGPT recency bias in investing: why this is genuinely risky

The second issue is subtler and, to me, more concerning: recency bias.

Recency bias is a well-documented human cognitive pattern where we overweight recent events and assume current trends will continue. It's why investors pile into assets after a run-up and exit after a drawdown — the opposite of what the math suggests. Good analysts are trained to fight it. It's one of the reasons systematic, rules-based investing tends to outperform discretionary judgment over long horizons.

ChatGPT has this bias. And it has it in a specific, almost ironic way: because its training data is skewed toward what was written about recently, the model reflects whatever narrative was dominating the news cycle at the time of training. If the last six months of its data were full of coverage about a rate hike cycle, it will anchor to that. If a particular sector was getting hyped in the financial press, the model will subtly overweight that framing.

Ask it for a view on a macro environment or a company and it often does one of two things: it either extrapolates from the most recent narrative it has data on, or it hedges so aggressively that the answer is useless. Neither is what a good analyst would do.

This matters for private investors in particular. (Nothing here is financial advice, just thinking out loud about the tool itself, and you should absolutely form your own view before acting on anything.) The gap between institutional and retail investors has always partly been about access to dispassionate, systematic analysis. If AI is going to help close that gap, it needs to be the thing that resists headline-driven framing, not the thing that encodes it at scale. Right now, in my experience, it's closer to the latter.

I know you can build systems around this. Custom instructions, structured prompts, injecting your own context and constraints. I do some of this. But I shouldn't have to spend two hours engineering guardrails just to get a second opinion that isn't contaminated by whatever was trending six months ago. That's not a sparring partner. That's a liability dressed up as one.

What most people get wrong about AI reliability

The common response to both of these issues is: "Just fact-check it." And yes, obviously. But that misses the point.

The value of a tool like ChatGPT isn't just that it gives you information. It's that it gives you information at a speed and scale that changes how you think and work. The moment you have to manually verify every output, you've lost a big part of that value. And the model's confident delivery actively works against your instinct to check, it doesn't sound uncertain, so you don't treat it as uncertain.

We engineered something close to a superpower and then quietly installed the same cognitive bugs that make humans terrible at making decisions under pressure.

The irony is that these aren't hard problems in principle. Recency bias could be countered by training architectures that deliberately weight longer time horizons. Outdated information could be flagged more aggressively when the model's confidence should be low. Real-time retrieval exists and is improving. I've seen better behaviour in some of the newer browsing-enabled configurations, and I'll keep testing as these evolve. But the default experience still fails in the ways I've described often for the users who need it most: people who aren't prompting systematically and aren't in a position to know when the model is working from stale data.

That's the gap worth worrying about.

The bigger race: whoever translates human will into product wins

Here's my actual long-term belief about where this is all going.

The LLM that most perfectly translates human will into product will win the race. Not the one with the most parameters. Not the one with the flashiest benchmark. The one that takes what you mean and turns it into what you need — at the speed of thought, without friction.

This is why vibe coding and Claude Code matter so much. Not just as features, but as a signal. Claude Code doesn't ask you to adapt to its syntax. It listens to what you're trying to build and builds it. It translates intent into product in a way that, even a year ago, felt like science fiction. That's a genuinely revolutionary step — and it's brought Anthropic much, much closer to OpenAI than most people expected. I think it will be remembered as the moment the race changed shape. Not "who has the best model" but "who best understands what the human actually wants."

ChatGPT's failure modes I've described, the stale confidence, the recency bias, are, at their core, failures of translation. The model produces something that sounds like what you wanted, but isn't actually responsive to what you needed. It's fluent without being useful. And in a world where the bar is shifting toward perfect intent-to-output translation, fluency alone won't be enough.

What to actually do

Treat ChatGPT's confident tone as neutral, not as a signal of accuracy. If the topic is time-sensitive (markets, current events, recent signings), assume the information could be six to twelve months behind and verify before acting on it.
Ask the model to declare its uncertainty. Something like: "Before you answer, tell me how confident you are and whether this could be affected by outdated training data." It won't always catch it, but it changes the dynamic.
For anything financial, use it for frameworks, not for facts. It's good at helping you think through a thesis structure, stress-test assumptions, or identify what you might be missing. It's not reliable for current valuations, recent earnings, or macro data. (And again that's my approach, not a recommendation for yours.)
When something sounds confidently wrong, push back immediately. The model updates. But you have to be the one who knows enough to push. Which means you still need independent knowledge, AI doesn't replace that, it extends it.
Build in a "what year does this assume" check. Especially for anything involving companies, geopolitics, sports, or regulatory environments. If the model's answer only makes sense in a world from a year ago, it probably is.
Watch this space. Real-time retrieval and better uncertainty signalling are genuinely improving — I plan to write more about how the tooling is evolving as I test it. But the default product today still has these gaps.

The potential is real. So is the gap between the potential and what ships by default. Knowing the difference is most of the work.

And just to close the loop on the Real Madrid rumours: I went back and asked a more specific follow-up about the rumoured squad inner conflicts. The model confidently weighed in on Valverde's leadership role and his conflict in training with Tchouaméni and cited some local newspapers.

I mean... Valverde. Come on. I know you're the captain and everything, but seriously challenging Tchouaméni? That guy is a beast, but much respect for trying...

Batch email sends before rate limits look like caps

Can Ceylan — Mon, 11 May 2026 09:01:36 +0000

What happened

A small newsletter campaign was sent to 13 subscribers.

The result came back in a strangely neat shape: 5 accepted, 8 failed.

At first glance, that looks like a hidden provider cap. Maybe the free tier only allows five recipients. Maybe the campaign endpoint has a quiet limit. Maybe something is wrong with the subscriber list after the first few addresses.

The number felt meaningful, and it was. Just not in the way it first appeared.

Root cause

The code was batching conceptually, but not at the HTTP request level.

It sliced subscribers into a "batch" and then used Promise.all() to send one request per recipient inside that batch. So 13 subscribers still became 13 simultaneous API calls.

The email provider had a default request-rate limit. The first few requests were accepted, and the rest crossed the throttle. The UI then surfaced the result as "5 sent, 8 failed", which made the failure look like a recipient limit instead of a request-rate problem.

That is the trap: a loop named "batch" is not the same thing as using a batch API.

Why it was non-obvious

The failure did not look like a classic rate-limit bug.

There was no slow ramp-up, no obvious retry storm, and no broken email template. The campaign worked for test sends. It worked for small recipient counts. It failed only when the list was large enough to cross the provider's request ceiling in a single burst.

The misleading part was that "five successful sends" looked like a business rule.

But the system was not limited to five recipients. It was limited to roughly five requests in the same small time window.

The fix

Use the provider's real batch-send endpoint.

Instead of making one API request per subscriber, build one payload containing many recipient-specific messages and submit it as a single batch request. Keep the per-recipient details where they matter:

individual unsubscribe URLs
recipient-specific headers or metadata
per-message errors returned by the provider
a clear count of accepted and failed deliveries

For small newsletters, that can turn 13 simultaneous requests into one request. For larger lists, chunk into the provider's documented batch size and send those chunks deliberately.

Reusable rule

When an API exposes a batch endpoint, use it for fan-out workflows.

Promise.all() is useful when independent work should happen concurrently. It is dangerous when every item calls the same rate-limited external service at once.

A practical checklist:

If a job fans out to many recipients, listings, files, or webhook targets, check provider rate limits before shipping it.
If the provider offers batch operations, prefer them over local concurrency.
If batching is not available, add an explicit queue, throttle, or retry strategy.
In the UI, report provider errors in a way that distinguishes recipient failures from request-rate failures.

The general lesson is simple: local concurrency can accidentally turn a small feature into a traffic spike.

The fix is not always to send slower. Sometimes it is to send in the shape the provider designed for.

What Financial Metrics Actually Matter Right Now (And Why I Keep Second-Guessing Myself)

Can Ceylan — Fri, 08 May 2026 04:51:34 +0000

What Financial Metrics Actually Matter Right Now (And Why I Keep Second-Guessing Myself)

Weekend is near and Eevery year around this time I sit down to think through my investing strategy. And every year I notice the same thing: the framework I used last year feels slightly broken.

This year is no different. But the discomfort feels sharper. We're in an environment where macro signals and market behaviour are barely speaking to each other, where AI optimism is doing a lot of heavy lifting for valuations that fundamental data alone wouldn't justify, and where I genuinely don't know whether we're witnessing a productivity revolution or building a very expensive illusion.

I don't have a clean answer to that. But I've been thinking hard about which numbers are actually worth watching right now, and which ones we've been trained to worship out of habit.

(This is personal opinion and not financial advice. Do your own research before making any investment decisions.)

Why This Matters: The Playbook Keeps Changing

I started investing seriously around 2018. That era had a clear religion: revenue growth above all else. Positive EBITDA was almost beside the point. If you were growing fast enough, the market believed profitability would follow. SaaS multiples were extraordinary — companies burning cash were celebrated like they'd invented fire. Marketplaces were appearing everywhere. Every week there was a new app promising to be "the Airbnb of dog grooming" or something equally ambitious.

Then the pandemic distorted everything. Streaming, delivery, e-commerce, stay-at-home anything — all exploded. The numbers looked incredible, but a lot of that demand was borrowed from the future. Peloton thought it had conquered fitness. It had just borrowed everyone's lockdown boredom.

2022 corrected hard. There's a well-documented historical pattern of midterm election years in the US being difficult ones for markets — and 2022 delivered on that pattern with particular conviction, with the S&P 500 falling roughly 19% over the year. Rate hikes, multiple compression, and a lot of portfolios humbled. My own included. Looking ahead, 2026 is the next US midterm year, and while history doesn't repeat on a schedule, it does tend to rhyme — worth keeping somewhere in the back of your mind as you think about positioning.

And then, almost immediately after, the AI rocket launched.

Nvidia, Microsoft, Google, Meta — infrastructure and application plays across the board. Even Intel found a reason to rally (briefly, painfully, and then less so — but still). The AI wave pulled capital into a new narrative with enormous velocity. We've been riding that wave since, and the question now is whether the fundamentals are catching up to the story, or whether the story is still running ahead of the fundamentals.

For context: GDP growth expectations in Europe have been revised downward repeatedly, with the eurozone growing below 1% in recent years and forecasts remaining modest. The US has fared better, but the picture is uneven, and productivity gains from AI investment have not yet translated clearly into broader economic output. That gap is worth sitting with.

Which means the usual metrics are worth questioning.

What Financial Metrics Actually Matter Right Now for AI-Era Companies

Revenue growth still matters, but it's no longer sufficient on its own. For the large, mature companies leading their sectors, user growth is largely saturated. The question has shifted from "how fast are you growing" to "how productively are you deploying capital."

Here's what I'm actually watching — with real companies as reference points, though none of this is a recommendation to buy or sell anything:

ROIC (Return on Invested Capital). This is becoming more interesting to me than almost anything else right now. If AI investment is genuinely making companies more efficient and more profitable, it should start showing up here over time. A company like Microsoft is worth tracking here — it has historically maintained ROIC above 20%, and with massive Azure AI capex now flowing through, the question is whether that ratio holds or drifts. The signal is still early and noisy, but I watch it. I'm not concluding anything yet.

Gross Margin Trend. This is a cleaner signal than net margin because it strips out the noise of one-time charges, restructuring costs, and accounting choices. Nvidia is a fascinating case — its gross margins expanded dramatically through the AI infrastructure wave, reaching above 70% in recent quarters. That's a real signal of pricing power and structural leverage. For software companies this is easier to trace. For hardware it's messier, but still worth tracking over consecutive quarters.

Revenue Per Employee. This is the one I keep coming back to. If AI is genuinely transforming productivity inside organisations, we should see revenue per employee climb — not just because of layoffs, but because fewer people are generating more output. Meta is often cited here: after its "year of efficiency" in 2023, revenue per employee climbed significantly. But it's worth asking honestly how much of that was AI-driven output and how much was just aggressive headcount reduction. That's a meaningful distinction, and the earnings call transcripts usually give you enough to tell the difference.

Operating Leverage (for asset-heavy businesses). For companies with significant fixed cost bases, the question is whether incremental revenue is dropping to the bottom line at an improving rate. Think of a company like Amazon Web Services within Amazon's broader P&L — as revenue scales, do infrastructure costs grow slower? Right now I see volatile results here across the market, which makes me cautious about drawing strong conclusions. But directionally, it's worth checking whether a company's cost base is becoming more or less fixed relative to revenue growth.

Is the AI Rally a Bubble Like the Dot-Com Crash of 2000?

This is the question I can't fully answer yet, and I want to be honest about that.

The parallel is tempting. Enormous capital flowing into infrastructure for a transformative technology, valuations running ahead of demonstrated returns, a narrative that feels so compelling that scepticism seems almost anti-intellectual. My instinct says, that AI is so powerful and immediate that we will see a efficiency boost soon.

Because there are real differences. The companies at the centre of this cycle are, by and large, already profitable. Nvidia is not Pets.com. The infrastructure being built is not hypothetical. Compute demand is real. The question is not whether AI is useful, but whether the current level of investment will generate returns commensurate with the capital deployed — and on what timeline.

The PE picture is worth grounding in history. At the peak of the dot-com bubble in 2000, the S&P 500's trailing PE ratio reached approximately 30–33x. It then collapsed to around 15x by the mid-2000s. In the years following the 2008 financial crisis, the market bottomed around 10–13x. The long-run historical average for the S&P 500 sits somewhere around 15–17x trailing earnings, depending on the period you measure.

Today, the S&P 500 trailing PE ratio is sitting in the range of 24–27x — well above the historical average, though not quite at dot-com peak territory. Forward PE ratios (based on expected earnings) are somewhat lower but still elevated. The CAPE ratio (Shiller PE), which smooths earnings over a ten-year cycle, is currently above 35x — a level that has historically preceded lower long-run returns, though it's a poor short-term timing tool.

The PE compression we saw in the recent market pullback made valuations at least slightly more honest. Not cheap, but less obviously detached. Whether that compression continues — or whether earnings actually grow into current multiples — is the open question.

The soft landing versus hard crash question remains genuinely open. I don't trust anyone who tells you they know the answer.

What Most People Get Wrong When Reading Earnings Right Now

They're still looking at EPS and revenue beats versus consensus, and treating that as the whole story.

Consensus estimates are manufactured. Analysts lower estimates into earnings season so companies can beat them. This is not a conspiracy, it's just how the game is played. A beat against a sandbagged number tells you very little about whether the underlying business is actually healthier.

The more useful exercise is to read the capital allocation section of the earnings call carefully. Where are they putting money? What is the stated expected return on that investment, and over what horizon? How much of current AI capex is discretionary versus committed? That's where the real signal lives.

Also worth noting: companies are currently investing enormous sums into AI infrastructure with limited near-term return visibility. That is not inherently irrational, but it does mean the financial statements today are a lagging indicator of a bet being made on the future. Read them that way.

The market can stay irrational longer than you can stay patient, but it can also stay rational longer than your narrative can stay intact.

What to Actually Do

Watch ROIC across 3-4 consecutive quarters, not just one. A single quarter of improvement means nothing. A trend means something. Set a simple tracker for the companies you hold and check it after each earnings cycle. Microsoft and Alphabet are useful benchmarks to compare against sector peers.
Read gross margin trends before revenue headlines. Revenue can be bought with sales spend. Gross margin expansion is harder to fake and tells you more about the structural economics of the business. Nvidia's margin expansion is the reference case — hold other companies to a similar standard of scrutiny.
Treat revenue-per-employee improvement with scepticism until proven otherwise. Ask whether it's driven by headcount reduction or genuine output growth. Meta's 2023 efficiency gains are the often-cited example — but dig into the transcript before you draw conclusions.
For asset-heavy companies, calculate operating leverage manually. Take revenue growth percentage and compare it to operating cost growth percentage over the same period. If costs are growing faster than revenue, the story about efficiency is not in the numbers yet.
Don't confuse infrastructure spend for immediate productivity. Massive capex into AI today is a future bet, not a present result. Be patient with the timeline, but be honest about the gap between investment and return.
Keep the 2026 midterm in the background. History doesn't repeat, but midterm years have a tendency to test portfolios. Not a reason to panic — just a reason to know what you own and why.
Check your own narrative. Every time I think I have the market figured out, it's worth asking whether I'm reading data or confirming a story I've already decided to believe. That question is uncomfortable. It's also the most useful one I know.

I'll keep watching and will write a follow-up when the picture gets clearer. Or messier. Probably messier first.

If you're working through the same questions — whether it's about valuation discipline, reading earnings, or just figuring out how to think about the AI cycle — I'd genuinely enjoy the exchange. Please get in touch and let's talk it through.