I've been using Claude Code as my primary agent orchestration tool for a few weeks now. Running cron-style loops for browser automation through a remote Playwright instance. Haven't tried Codex at this depth yet, but from what I've seen it's more focused on code generation while Claude Code is more of a general-purpose agent runtime. The things that make Claude Code powerful for me are the persistent session with tool access, the ability to run background tasks on schedules, and the hook/skill system for customization. If Codex matches that plus adds better async execution (Claude Code's scheduled tasks die when the session ends), it could be compelling. But for now Claude Code handles my use case better than anything else I've tried.
Interesting approach. I've been running a similar setup using Slack as the control plane for browser automation agents. The main challenge with messaging apps as control planes is handling long-running tasks and state management. Telegram's bot API is actually nicer than Slack's for this since you get more granular message editing.
Backend Engineer at British Council, architecting Agentic AI systems for one of the world's largest cultural organizations. Building AI agent orchestration layers and LLM-powered backend services that automate complex examination workflows across 100+ countries. Previously built a FinTech SaaS from zero at Marquee Equity and solo-shipped an AI-powered interview prep platform (ProTechStack.com)
Senior Backend Engineer with 5+ years building scalable systems across FinTech, EdTech, and AI. Currently at British Council architecting exam platforms for millions of concurrent users. Solo-built a Go-based scraping engine that extracts structured data from 200M+ company records, and an AI interview prep platform with 100K+ users (ProTechStack.com). No over-engineered stacks — Go, PostgreSQL, Playwright, and headless Chrome. Looking for early-stage roles.
I agree that reading every dependency isn’t realistic. But “not reading the code” as a principle feels risky.
In my experience, abstractions hold until they don’t. The first time you hit a production incident and the docs stop helping, reading the source stops being academic and starts being survival.
We once had a performance issue caused by a library making assumptions about concurrency that weren’t obvious from the API. The fix only became clear after stepping through the source.
I think the real skill isn’t avoiding reading code, it’s knowing when to escalate from trust to understanding.
For glue code or low stakes utilities, sure. For auth, billing, or core infra, I’d argue reading at least the critical paths pays dividends.
So last week I tried Gemini pro 3, Opus 4.6, GLM 5, Kimi2.5 so far using Kimi2.5 yeilded the best results (in terms of cost/performance) for me in a mid size Go project. Curious to know what others think ?
Insights on this cat-and-mouse game are spot on. As AI evolves, watermarking might be a viable countermeasure. what detection methods/tools have you found most reliable in practice? I want to be able to detect and automatically block AI generated comments under my posts.
I just checked out Forgejo. I think i start with it, looks clean and lightweight. For my homelab I don’t have very large requirements. Might be a good starting point for me.
At this point, GitHub outages feel closer to cloud provider outages than a SaaS blip. Curious how many people here still run self-hosted Git (GitLab / Gitea) vs fully outsourcing version control.
Software engineer who scaled a startup from 10→500, seeking early-stage roles
Location: India
Remote: Yes
Willing to relocate: Open
Technologies: Backend-heavy systems nodejs & go, distributed systems, infra & tooling, scraping and browser automation, AI-based outreach & enrichment pipelines, full-stack (backend-first), production systems at scale
Experience: Joined a startup early (~10 people) and worked through growth to ~500 employees. Currently working in a large enterprise environment, gaining experience with scale, process, and long-lived systems. Prefer early-stage teams where ownership and speed matter more.
Looking for: Early-stage startups (seed–Series A), ideally working closely with founders and owning systems from zero to one.