DEV Community: Can Ceylan

AI Is the Most Equalising Force Tech Has Ever Seen, Especially for Women

Can Ceylan — Thu, 04 Jun 2026 14:48:54 +0000

AI Is the Most Equalising Force Tech Has Ever Seen, Especially for Women

I spent a day at an AI coding conference. Not as a speaker. Just as someone building something, paying attention, and occasionally wondering whether I was the least technical person in the room. The conversations were sharp. Some were uncomfortable. But one thread kept pulling at me, and it was not the one everyone expected.

Nobody had clean answers. And that was actually useful.

Why this matters

Let me be honest about what most AI-in-tech conversations look like from the outside. Confident takes. Either the robots are coming for everything, or nothing is really changing and you should relax. The conference was not like that. It was full of people actively building things, actively unsure, and actively debating. That felt closer to reality.

What I took away is not a prediction. It is more of a reframe. The question is not whether AI will change the job market. It obviously will. The more interesting question is who it changes things for, and in which direction.

The answer that kept coming back to me: the people who have historically been locked out. And at the top of that list, women.

Will AI replace software developers?

Short answer: not the ones paying attention.

The longer version is genuinely complicated. The role of Junior developers got some airtime at this conference, and not in a reassuring way. Some argue that entry-level roles will shrink because AI can now handle the scaffolding work that used to train those people. Others argue the opposite: that juniors who embrace AI tooling are actually more valuable right now, because they arrive without years of habits to unlearn and with a genuine appetite for the new workflow.

Both arguments are probably true in different contexts. What seems less debatable is that the shape of the job is changing faster than job descriptions are. About 80% of enterprise AI projects reportedly fail, and the most cited reason is not the technology. It is people inside organisations who are not willing to leave their comfort zone, including, maybe especially, in leadership positions. The bottleneck is human, not algorithmic.

So the developer who learns to work with AI is not being replaced. They are being promoted past everyone who refused to adjust.

Can you build real things with AI if you are not a developer?

This is the one that kept me up a little.

Vibe coding, the practice of building working software through natural language prompts without writing traditional code, is not a gimmick anymore. It is clumsy in places, and I would not hand it a critical infrastructure project tomorrow. But the distance between an idea and a working prototype has collapsed. Significantly.

What surprised me at the conference was who was least threatened by this. The coding bootcamps, the certification platforms, the learn-to-code institutions. You might expect them to be nervous. Most were not. Their argument: understanding the fundamentals still matters, because when the AI gets it wrong, you need to know what wrong looks like. The tool accelerates. It does not replace the need for judgment.

I am not fully convinced, but I am not dismissing it either. I'll keep watching that space and report back.

What most people get wrong

Everyone is framing this as a loss. Job cuts. Skill obsolescence. Industry disruption. That framing is real, but it is not the whole picture, and it is suspiciously centred on people who already had the advantage.

The conversation that landed hardest for me was about women in tech. The argument, and I think it is a strong one, is that AI is one of the most significant equalising forces the industry has ever seen. Women have historically been underrepresented in tech roles, partly because of gatekeeping, partly because of credentials culture, partly because of how networking and sponsorship work in deeply homogenous industries. AI disrupts all three simultaneously.

When the barrier to building something is no longer five years of computer science, but curiosity and the ability to ask the right questions, the landscape changes. The same logic applies to migrants, to people without elite degrees, to people in regions that were never close to a Silicon Valley pipeline.

Globally, women hold around 26% of tech jobs, a number that has barely moved in a decade. The gender pay gap in tech sits somewhere between 16 and 28% depending on the market. Those are stubborn numbers. But when the tools change, the gatekeepers lose some of their leverage.

This is worth sitting with. The technical debt that kept most people on the outside of the digital economy, the years of learning, the access to the right networks, the cost of entry, is being vaporised. Not completely. Not overnight. But faster than any previous shift in computing.

And here is the asymmetry that nobody talks about enough: individuals can adapt faster than organisations. A person can learn a new tool this weekend. A corporation with legacy infrastructure, internal politics, and a middle management layer that is quietly terrified has to navigate all of that before it can even run a proper pilot. That is a structural advantage that currently sits with small teams, independent builders, and people who have nothing to unlearn.

Every structural advantage that kept people out of tech is slowly becoming a software problem, and AI just shipped the patch.

A note on Fleamio

One thing I can speak to directly is what this shift looks like in practice for a small team. At Fleamio, we are a lean operation. We are not a legacy enterprise. We do not have layers of internal politics slowing down every experiment. When a new AI tool lands, we can pick it up, test it against a real problem, and decide within days whether it belongs in the workflow. That agility is not incidental. It is one of the few genuine structural advantages a small team holds over a funded competitor right now. The window where moving fast actually matters is open. We are using it.

What to actually do

If you are early in your career: do not wait for clarity. The people debating whether to learn AI tooling are already behind the people using it. Pick one tool, build one real thing with it, understand where it breaks.
If you have been out of tech or never felt like it was for you: this is the most genuinely open window in a generation. The qualification inflation that kept the door closed for years is losing its grip. The entry cost has never been lower.
If you are inside a large organisation: the 80% failure rate on AI projects is almost certainly downstream of culture, not capability. The question to push internally is not "what tools are we buying" but "what are we actually willing to change about how decisions get made."
If you are building something independently: your advantage over incumbents is real right now, but it is time-limited. Organisations are slow, but they are not asleep. The window where a small team can move 10x faster than a funded competitor is open. Act accordingly.
On the pay gap question: if you are a woman, a migrant, or anyone who has been told the cost of entry into tech was too high, it is worth genuinely reassessing that right now. The tools changed. The old map is not reliable anymore.

Do not build masks from translucent polygons

Can Ceylan — Sat, 30 May 2026 04:51:37 +0000

What happened

A map needed a fog-of-war effect: areas with data should feel visible, and areas without data should stay dark.

The first implementation used circular buffer polygons around every data point. Each buffer had soft transition rings with different opacities. In isolation, one buffer looked reasonable.

But once multiple data points were close together, the map turned into a mess of dark circular bands. The visual effect looked like stacked shadows instead of explored territory.

Root cause

The mistake was using many translucent polygons for a masking problem.

Map renderers blend every semi-transparent shape independently. If three rings overlap, their opacity stacks. If ten rings overlap, the area becomes much darker than intended.

The system was technically doing the right thing. The model was wrong.

A fog effect should answer one question:

How visible should this pixel be?

The polygon approach answered a different question:

How many semi-transparent shapes happen to cover this pixel?

Those are not equivalent.

Why it was non-obvious

The bug hides because the first few test cases look fine.

One circle creates a nice transition. Two circles still seem acceptable. Then real data arrives, nearby buffers overlap, and the renderer starts accumulating darkness in unpredictable-looking bands.

This is especially easy to miss in AI-assisted UI work because the proposed solution sounds geospatially correct: "create buffer zones around covered areas." But the desired output was not a geographic fact. It was a visual effect.

The fix

Use a single composited mask.

The corrected implementation used a canvas layer above the map:

Draw one dark rectangle over the whole viewport.
For each covered area, subtract a soft radial gradient from that dark layer.
Redraw the canvas when the map moves, zooms, resizes, or receives new data.

Now overlaps reveal more of the map instead of adding more darkness.

The important change was not canvas itself. It was changing the mental model:

One mask, many cutouts.

Not:

Many transparent overlays.

Reusable rule

Use map polygons for geographic facts.

Use canvas, WebGL, or another compositing layer for visual masks.

Good uses for polygons:

boundaries
regions
hex cells
selected areas
measured buffers that represent real spatial meaning

Bad use for overlapping translucent polygons:

fog-of-war
spotlight effects
progressive reveal
darkness/lightness masks
any effect where opacity should not depend on shape count

If the overlay is supposed to behave like a mask, build a mask. Do not approximate it with many semi-transparent geometries.

Practical test

Before shipping a visual map overlay, test it with clustered data.

Sparse points can hide blending bugs. Dense points reveal whether the effect is truly composited or just stacked.

If adding more data makes the overlay darker, louder, or ring-shaped, the rendering model is wrong.

Claude Is Overhyped. Codex Is Underrated. Here Is What Actually Happened When I Built Real Products With Both.

Can Ceylan — Fri, 29 May 2026 20:55:46 +0000

The picture looks different now

A few months ago I wrote about hiring two AI developers and the surprisingly human feeling of having to manage them. At the time I was still figuring out the dynamic. Now I have actually shipped products with both of them running in parallel, and the picture looks different. Not worse. Just sharper.

This is not a Claude takedown. I want to be clear about that from the start. Claude is the reason I broke through a years-long wall of having ideas with no real way to implement them. That matters to me personally. But after running both agents through real production cycles, I have some honest things to say about where each one earns its money and where the hype does not hold up.

Why this matters if you are building as a solo founder or small team

Most AI coding conversations are still about single-agent setups. Someone opens Cursor or Claude, asks it to build something, and judges the tool by what comes out. That is a fine place to start. But once you are building products with actual users, real infrastructure, and moving parts that interact with each other, the single-agent model starts to show its limits.

The moment I started treating these two tools as roles rather than alternatives, everything got faster and more stable. The question is not "which AI is better." The question is: better at what, and at which stage?

How does Claude perform for building real products?

Still exceptional for the right tasks. Claude is my frontend developer and UX partner, full stop. Its design instincts are genuinely younger and fresher than anything Codex produces. When I give it a layout brief or a component to build, what comes back tends to feel modern, clean, and considered. It does not need much direction on visual hierarchy.

For heavy implementation work, especially in the middle phases of building an MVP, Claude handles multitasking well. You can hand it several things at once and it manages them with decent coherence. Speed is real. If I need a working prototype that looks like a product rather than a proof of concept, Claude gets me there faster than anything else I have used.

But here is the honest limitation. Claude is not great at knowing what it does not know. When something breaks at the deployment layer or the server behaves unexpectedly, Claude reasons from the code rather than from observed behaviour. It guesses intelligently, but it is still guessing. For debugging live environments, that gap becomes expensive quickly.

What does Codex actually do better than Claude?

More than people give it credit for, particularly at the stages most developers skip or rush.

I now start every project with Codex, not Claude. The planning and architecture phase is where it genuinely surprises me. It thinks like a product manager and a solutions architect at the same time, identifies edge cases before they exist, maps dependencies, and produces infrastructure decisions that hold up later. The plans need very little correction mid-build. That saves an enormous amount of back-and-forth downstream.

The second place Codex outperforms is testing and deployment. This is the capability that I think is most underrated in public discussion. Codex can actually observe what is happening on a live server. It takes screenshots. It checks whether the implementation works in production, not just whether the code looks correct. That is a fundamentally different kind of intelligence for debugging. Claude tells you what the code says. Codex tells you what the product is actually doing.

Codex also thinks more carefully about legal and compliance dimensions of code. Not perfectly, but noticeably. For anyone building in regulated contexts or even just thinking about data handling, it flags things that Claude would sail past without comment.

What most people get wrong about dual AI workflows

They treat it as a competition. They pick a side, defend it, and miss the point entirely.

The workflow that is actually working for me looks like this: Codex plans and architects, Claude builds the frontend and implements the core product, both review each other's work (yes, I run cross-reviews deliberately, the 360-degree perspective catches things neither would catch alone), and then Codex takes the lead again for testing, deployment, and server-side debugging.

The uncomfortable truth is that neither agent is dominant across the full stack. Claude is not the rocket I called it in the original article, it is more like a brilliant junior frontend architect. Codex is not just the wiring-checker, it is closer to a senior engineer who works more slowly but breaks fewer things in production.

The hype around Claude specifically tends to come from people who are building prototypes and demos. Which is valid. Claude is exceptional at that. But once you are building something real, the production reliability of Codex starts to matter in ways that demo culture does not reward.

The best AI workflow is not about picking a winner. It is about knowing which problem each agent was actually built to solve.

I am still testing things here, including some newer capabilities I have heard about but not fully explored yet, particularly around how Codex handles longer-context architectural reasoning across large codebases. That is next on my list and I will keep people posted as the stack evolves.

I also write about the product thinking side of building with AI tools. If you are interested in how the solo builder mindset connects to product strategy, that territory overlaps with what I cover in my notes on AI and product development.

What to actually do

Start every build with Codex, not Claude. Use it to define your architecture, plan your data model, and map your infrastructure before a single line of code is written. The time you spend here is recovered threefold later.
Hand the frontend and MVP implementation to Claude. Give it the vision that Codex defined and let it build fast. Do not micromanage the design decisions, it has better instincts there than you expect.
Run cross-reviews deliberately. Let Claude review Codex's plans. Let Codex review Claude's implementation. The friction between the two agents surfaces things you would not find alone.
Return to Codex at deployment. Do not try to debug live server behaviour with Claude. It is not built for that. Codex can observe the running product, not just the codebase, and that distinction matters when something is wrong in production.
Resist the urge to pick one tool. The efficiency gain from a dual setup is not marginal. It is structural. The two agents cover genuinely different parts of the software development lifecycle.
Treat the workflow as a living thing. Both tools are updating regularly. What is true about their relative strengths at the time of writing this may shift. Build the habit of re-evaluating, not just defending the setup that worked last month.

The solo builder era is real. But it works best when you stop thinking about AI tools as replacements for a dev team and start thinking about them as a dev team with distinct roles that you actually have to manage.

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.