DEV Community: Can Ceylan

Automation Was Always Possible. AI Just Made It Everyone's Problem to Ignore

Can Ceylan — Wed, 15 Jul 2026 06:29:58 +0000

This article answers:

What is actually the difference between automation and agentic AI?
Is agentic AI really that expensive, and when does cost become a problem?
Can you automate business operations without building full AI agents?
How do you reduce API costs when using LLM-based workflows?

Every second LinkedIn post right now is about AI agents. Agents that book your meetings, write your emails, manage your calendar, run your customer support. The pitch is always the same: the future of work is autonomous, and if you are not building agents, you are already behind.

I find this a little funny, because we were building automation at Foodora back in 2018 using Zapier. No agents. No LLMs. Just a trigger, an action, and a team of young professionals with the tools of a highly funded start-up.

Why this matters

The conflation of automation and agentic AI is not just a semantic problem. It leads people to over-engineer solutions, overspend on API calls, and completely miss the fact that a large portion of what they want to automate does not require an agent at all.

At the same time, the people who do understand the difference are quietly getting a compounding advantage. Because what AI actually changed is not whether automation is possible. It changed who can do it, and how fast.

That is worth sitting with for a moment.

What is the difference between automation and agentic AI?

Automation, in the classic sense, is rule-based. If this happens, do that. It is deterministic. You define every step, every branch, every output format. Tools like Zapier made this accessible to non-developers in the early 2010s, though Zapier in 2018 was still quite technical to use properly and definitely assumed you had a certain level of digital literacy. Tools like Make (formerly Integromat) and n8n pushed this further, allowing more complex multi-step flows, direct API integrations, and significantly more flexibility without requiring you to write code from scratch. That space has matured a lot.

Agentic AI is something different. An agent does not just follow a fixed decision tree. It reasons. It takes a goal, breaks it into steps, decides how to proceed at each step, uses tools (APIs, browsers, files, code execution), and adapts when something unexpected happens. The defining quality of an agent is autonomous decision-making across a sequence of actions, not just task execution.

Here is the honest version: most of what businesses want to automate right now is not agentic. It is deterministic workflows that happen to involve a language model at one or two steps. Writing a summary, classifying an email, generating a draft response. That is not an agent. That is automation with an LLM node inside it.

Calling that an agent is a bit like calling a calculator an AI because it computes things faster than a human.

Is agentic AI actually expensive?

It depends entirely on what you are asking the agent to do, and how often.

Text-based tasks are cheap. A well-structured prompt to GPT-4o or Claude for summarising a document, extracting structured data, or generating a short output costs fractions of a cent. At scale that adds up, but it is manageable if you are thoughtful about it.

The cost climbs when you introduce:

Long context windows with lots of history passed on every call
Audio or video transcription as part of the workflow
Multi-step agent loops where the model calls itself repeatedly to reason through a problem
Vision tasks where images need to be analysed at each step

So the question is not "is agentic AI expensive" in the abstract. The question is whether you have designed your workflow with cost in mind from the start.

A few things that actually help: build a memory layer so you are not re-passing the same context on every API call. Ask yourself whether a written summary of a meeting is sufficient, or whether you genuinely need to transcribe and analyse the full audio. Minimise API outreach by caching results where possible. Text is cheaper than audio, audio is cheaper than video. Work with that hierarchy.

This is operational efficiency, and it applies to AI workflows exactly the same way it applies to logistics or product operations. You design for throughput and cost at the same time, not as an afterthought.

What most people get wrong

The dominant narrative positions agents as a democratisation of intelligence. And that is partly true. But the real democratisation that happened is in automation itself.

Before LLMs, setting up a non-trivial automation required either a developer, a very patient non-technical person who was willing to spend weeks figuring out webhooks and API authentication, or a significant SaaS budget. Most small businesses and solo operators skipped it entirely because the barrier was too high.

What changed with AI is not that agents replaced automation. What changed is that a domain expert, someone who deeply understands their own customer journey and internal processes, can now describe what they want in plain language, get a working draft of the logic, and implement it themselves. The technical ceiling dropped dramatically.

But here is the catch: you still need to understand your own processes. The LLM cannot do that part for you. If you do not know what happens between a customer placing an order and that order being fulfilled, no agent in the world will automate it well. The map has to exist in your head first.

Automation was never the hard part. Understanding your own processes well enough to automate them was.

I have seen this at both ends. In logistics operations, the processes that got automated well were the ones someone had already documented and lived with for years. The ones that failed were handed off to a developer with a vague brief and a tight deadline.

AI lowers the technical barrier. It does not lower the thinking requirement.

What to actually do

Audit before you automate. Map out one complete internal or customer-facing workflow end to end before touching any tool. Every handoff, every decision point, every place where a human currently applies judgement. That map is the thing you are automating, not the tool.
Start with classic automation, not agents. If your workflow is deterministic, use n8n, Make, or even a simple script. Bring an LLM in only at the steps where language understanding or generation is genuinely needed. This keeps costs down and makes debugging much easier.
Build a memory layer early. If your agent or workflow needs context about a user, a project, or a product, store that context in a database and retrieve it selectively. Do not dump everything into the prompt every time. Your API bill will thank you.
Text first, always. Before deciding to transcribe audio, extract from video, or analyse images, ask whether a written alternative exists or could be created upstream. The cost difference is not trivial at volume.
Understand where agents actually earn their complexity. Agents make sense when the task requires real-time decision making across multiple unknown steps, when exceptions are common and unpredictable, or when the workflow cannot be fully specified in advance. That is a narrower set of use cases than the current hype suggests.
If you are early and cost-sensitive, start with free tiers and open-source models. n8n self-hosted is free. Local models via Ollama cost nothing per call. You can build and validate a lot of logic before spending meaningful money on frontier model APIs.

I write more about working with AI tools practically and the product thinking behind them in the Tech & AI section. And if you are thinking about where automation connects to building a business around your own expertise, that thread runs through a lot of what I think about with Fleamio.

Agents are not magic. They are just automation that can think a little. The thinking part is impressive. But the automation part was always there, waiting for someone who understood their own work well enough to use it.

AI Tools Worth Knowing in 2026: What I Picked Up at a Workshop in Vienna

Can Ceylan — Tue, 14 Jul 2026 07:21:55 +0000

This article answers

What are the best AI tools for entrepreneurs and builders right now?
How do you run a local LLM to keep your data private?
Which AI tools actually lead in video, image, voice, and music generation?
What is the European shift away from US AI providers really about?

I spent a day at a KI Workshop at the UGP in Vienna this week. A room with practitioners, founders, and curious generalists, all arguing about the same thing: which tools are actually useful, and which ones just look good in a demo.

I took notes. Here is what stayed with me.

Why this matters

The AI conversation has split into two very different rooms. One room is still debating whether AI is overhyped. The other room is quietly rebuilding workflows, cutting costs, and shipping faster. The gap between those rooms is growing every quarter.

What struck me at this workshop was not the tools themselves. It was the attitude in the room. Less FOMO, more selectivity. People are starting to ask better questions: not "have you tried this?" but "does this actually solve anything?"

That is a sign of a maturing space. And it means the tools that survive will be the ones that solve a real, repeatable problem, not just the ones with the best product hunt launch.

Which LLM should you actually use?

The honest answer: it depends, and the people in this room were split.

For general use, the debate was spread across Gemini, Claude, and OpenAI. No single winner. Each has a different personality and different strengths. Claude tends to write better. Gemini integrates tightly with Google's ecosystem. OpenAI has the widest tool surface.

What was more interesting to me was the names that came up as alternatives: Hermes, Mistral, and, perhaps most surprisingly for a European room, Qwen, a Chinese provider from Alibaba. The fact that Qwen was being discussed seriously, without the reflexive suspicion that would have greeted it a year ago, says something about how the geopolitical mood is shifting.

There is a growing sentiment in Austria, and I would guess across the EU broadly, that US Big Tech is no longer a neutral choice. The combination of the AI Act tensions, concerns about the US Cloud Act giving American authorities access to data stored on US-operated infrastructure regardless of physical location, and a general political discomfort with the direction of some major tech players, is pushing people to look elsewhere. This is not fringe thinking anymore. It came up naturally, without anyone making a speech about it.

How to run a local LLM for privacy and cost control

This one matters practically, so let me be direct about what the workshop covered and what the facts actually support.

The argument for running a local LLM has two legs: data privacy and long-term cost. Both are real, but they come with trade-offs worth understanding.

On privacy: if you run a model locally, your prompts and outputs never leave your machine. For anyone handling client data, internal documents, or anything that falls under GDPR scrutiny, this is not a paranoid preference, it is a compliance consideration. The Cloud Act concern is legitimate: US-based cloud providers can be compelled to hand over data stored on their infrastructure under US law, even if that data belongs to an EU user. Running locally sidesteps that entirely.

On cost: the upfront compute investment can be real, especially for heavier models. But for high-volume users, the marginal cost of API calls adds up. Local models eliminate that recurring cost once you have the hardware.

The dominant tools mentioned for desktop use were Ollama and LM Studio. Both let you pull and run open-source models locally without needing to write code. Ollama is more developer-friendly and runs cleanly from the terminal. LM Studio offers a graphical interface that makes it accessible to non-technical users. For mobile, Pocket Pal was the name that came up, an app that runs smaller models directly on your phone.

The honest caveat: local models are still behind the frontier models on raw capability. You are making a trade-off between privacy and performance. For sensitive internal work, that trade-off is often worth it. For complex reasoning tasks, you may still reach for the cloud.

What are the best AI tools by category right now?

Here is the practical breakdown from the workshop, with my own read layered in.

Video transcription and summarisation: Google Gemini's NotebookLM came up as the clear leader for turning long content into structured summaries. Whisper (the open-source transcription model from OpenAI) handles audio-to-text well and can be run locally. CapCut got a mention for lighter video editing workflows with AI-assisted captioning.

Voice cloning and imitation: ElevenLabs was the perceived leader. It was not contested much. If you are building any kind of audio content workflow, it is the first stop.

Logo creation: Ideogram was recommended, especially for entrepreneurs in early stages. I want to be straight about something here though. A live test at the workshop showed the same limitation that plagues most image generators: the first draft can be surprisingly good, but adjustability is limited. And critically, outputs are not served as vector files. A logo that lives only as a raster image is a logo that will cause you problems the moment you need to resize it for a pitch deck, a banner, or a print run.

My take: until someone builds a one-stop solution that goes from prompt to editable vector, logo generation tools are still a starting point, not a finish line. You will end up in Adobe Illustrator anyway. If anyone pitches you a logo service, ask one question before anything else: do you deliver an editable vector file? If the answer is no, save your time.

Presentations and pitch decks: Still unsettled. Canva and Gamma were discussed but the room was not convinced. This feels like a gap that has not been filled cleanly yet.

Website and product UI drafting: I found Google Stitch genuinely useful for first-draft website layouts in a product development context. It is not a builder, it is a thinking tool. For getting a rough structure out of your head and onto a screen quickly, it holds up.

Image and video generation: Higgsfield was cited as the best starting point for AI video generation. For creating a digital avatar of yourself with your own voice, HeyGen and Synthesia were the two names mentioned.

Music and sound: Suno is the perceived leader for AI-generated music. The one that genuinely caught my attention was Magenta-RT, which generates an infinite AI radio station from a text prompt. I have not tested it yet, but the concept is immediately interesting, especially for fitness instructors, content creators, or anyone who needs background audio without licensing headaches. I will report back.

What most people get wrong about AI adoption

The biggest mistake I see is treating AI adoption as a one-time decision. People either go all-in on one provider and ignore the rest, or they try everything and master nothing.

The better frame: think in layers. One general-purpose LLM you use daily and know deeply. One privacy-respecting local option for sensitive work. One or two specialist tools for the specific workflows that matter in your business.

The other thing worth saying out loud: we are still early. Most of the people in that room, smart, engaged, genuinely curious practitioners, are still mostly using basic LLMs. No category has a dominant winner yet. Most workflows are still being figured out. That is not a reason to panic. That is actually a reason to breathe.

The window where showing up and learning is enough is still open. It will not be forever.

Most people are still using AI like a slightly smarter search engine. The gap between that and what is actually possible is where the next five years will be decided.

What to actually do

Pick one LLM and go deep. Use it for 30 days across real work. Do not switch. The compounding comes from fluency, not from sampling every new release.
If you handle client or company data, set up Ollama or LM Studio now. Even if you only use it occasionally, having a local option removes a category of risk entirely.
Audit your logo and brand assets. If you have used an AI tool and do not have editable vector files, fix that before you need to scale anything. The problem always shows up at the worst moment.
Follow people who filter for you. Matthew Berman, Matt Wolfe, Andreas Horn, and Sasha Pallenberg were all mentioned as reliable signal in a noisy space. Let them do the scanning, you focus on applying.
Test Magenta-RT if you create audio-heavy content. I have not yet, but an infinite prompt-driven radio station sounds worth an hour of exploration.
Watch the Will Smith eating spaghetti compilation from 2023 to today. It is the most honest visual timeline of how far AI video generation has come. Better than any trend report.

The European alternatives to US AI providers are still catching up on usability. But the direction is clear and the funding is following. If you are building in that space, the tailwind is real, and an EU-first positioning is already a differentiator even before the product is competitive on pure capability.

Stay curious. Stay selective. And if someone tries to sell you urgency about any single tool right now, they are probably selling the tool.

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.