I feel you on this. The market is rough right now, especially for remote roles in the UK/Europe. A few things that helped me and others I know:

1. The "hidden job market" is real - most roles never get posted publicly. LinkedIn connections and warm intros close more doors than cold applications.

2. Consider targeting specific niches where your Rails/Node/Go stack is highly valued. Fintech and healthtech companies often prefer experienced engineers who can ship reliable code over "move fast and break things" types.

3. Don't underestimate smaller companies (50-200 employees). They often pay competitively but get far fewer applications than FAANG-adjacent companies.

4. Your GitHub looks solid. One thing that sometimes helps is having a few short-form technical posts on your own site or blog - it helps establish expertise when hiring managers Google your name.

The market will turn. 10+ years of shipping real products is valuable, and companies that recognize execution skills will find you. Keep pushing.

Self-hosted workers are becoming critical infrastructure for AI agent workloads. When you're running agents that need to interact with external services - web scraping, API orchestration, browser automation - you hit Cloudflare's execution limits fast. The 30s CPU time on the free tier and even the 15min on paid plans don't work for long-running agent tasks.

The isolation model here is interesting. For agents that need to handle untrusted input (processing user URLs, parsing arbitrary documents), V8 isolates give you a security boundary that's much lighter than full container isolation. But you trade off the ability to do things like spawn subprocesses or access the filesystem.

Curious about the persistence story. Most agent workflows need some form of state between invocations - conversation history, task progress, cached auth tokens. Is there a built-in KV store or does this expect external storage?

Good use case. For state between invocations, we have KV (key-value with TTL), Storage (S3) and DB bindings (Postgres). Durable Objects not yet but it's on the roadmap.

Wall-clock timeout is configurable (default 30s), CPU limits too. We haven't prioritized long-running tasks or WebSockets yet, but shouldn't be hard to add.

nice, KV + Postgres covers most of our use cases. the TTL on KV is useful for caching auth tokens between invocations without worrying about cleanup.

for long-running tasks we've been using a queue pattern anyway - worker picks up task, does a chunk, writes state to KV, exits. next invocation picks up where it left off. works around timeout limits and handles retries gracefully. websockets would be nice for real-time feedback but polling works fine for now.

will keep an eye on the durable objects progress. that's the main thing missing for stateful agent workflows where you need guaranteed delivery.

The "code vs LLM" framing is a bit misleading - the real question is where to draw the boundary. We've been building agents that interact with web services and the pattern that works is: LLM for understanding intent and handling unexpected states, deterministic code for everything else.

The key insight from production: LLMs excel at the "what should I do next given this unexpected state" decisions, but they're terrible at the mechanical execution. An agent that encounters a CAPTCHA, an OAuth redirect, or an anti-bot challenge needs judgment to adapt. But once it knows what to do, you want deterministic execution.

The evals discussion is critical. We found that unit-test style evals don't capture the real failure modes - agents fail at composition, not individual steps. Testing "does it correctly identify a PR link" misses "does it correctly handle the 47th message in a channel where someone pasted a broken link in a code block". Trajectory-level evals against real edge cases matter more than step-level correctness.