Disclaimer: This content reflects my personal opinions, not those of any organizations I am or have been affiliated with. Code samples are provided for illustration purposes only, use with caution and test thoroughly before deployment.
Almost every day, I see someone on LinkedIn publicly calling out a “terrible” recruiter. The complaints follow familiar patterns: a recruiter mixed up the technology and pitched a role that had nothing to do with the person’s actual skills; they demanded ten years of experience in a framework that’s barely been around for two; they proposed a position several levels below where the person is in their career, and the candidate took it as a personal insult; or the job description itself was fantasy — a full-stack, AI-data-scientist-superhuman with an entry-level salary attached. The frustration is real. But the response — the public callout, the viral screenshot, the snark — is usually a mistake.
Early in my career, every recruiter message on LinkedIn felt like a small victory. Someone had noticed me. Someone had looked at my profile and decided I was worth reaching out to. I’d read each message carefully, even the templated ones, because it meant my skills and contributions were being recognized.
Then came the messages that stung. “Hi, we have an exciting Java opportunity…” — except I’m a web browser engineer who builds JavaScript engines using Rust. Getting lumped in with generic “Java developer” outreach felt like someone had glanced at a keyword on my profile and stopped there. I remember the mix of annoyance and embarrassment, like being called by the wrong name at a party. It felt insulting, even dismissive.
If you use GitHub Copilot custom agents, you probably know you can define them per-repository in .github/agents/. That works well for project-specific agents, but it means every new repo starts from scratch. There is a way to share agents across all your repos without copying files everywhere — and it works for personal accounts too, even though the documentation only mentions organizations.
I wanted a quick way to scan paper documents with my phone, but I kept getting harsh shadows on the page. The scanner app could detect edges, but the image quality was inconsistent because my hand, phone, and room light all affected the result.
So I made a simple document scanner box from cardboard. It is cheap, simple, and works surprisingly well.
A few weeks ago, I was vibe coding a personal CRM with an AI assistant. Nothing fancy — just something to log my communication with people at work: who I talked to, what we discussed, when to follow up. The AI cheerfully scaffolded the whole thing: a Python backend, a SQLite database, tables for contacts and interactions, a schema with migration scripts.
I stared at the output for a moment. A contacts table with foreign keys. For notes I could have kept in a text file.
There’s nothing wrong with what the AI generated — it’s following established software engineering instincts. But those instincts were built for a different kind of software. For SaaS apps with millions of users and thousands of concurrent writes, yes, you need a database. For a personal CRM on one machine used by one person? I’m not so sure.
My thesis: plaintext files are the right default storage format for AI-generated personal software, and we should be nudging AI assistants toward that default more deliberately.
I’ve been experimenting with the GitHub Copilot Cloud Agent (also called the Copilot coding agent) as part of my remote vibe coding setup. The idea is simple: assign a GitHub issue to Copilot, let it implement the code on cloud compute, and have it open a pull request — all without needing a machine running locally. If you haven’t read that post, the short version is that this kind of setup is great when you only have a few minutes at a time and want meaningful progress to happen in the background.
The catch is that in some environments you can’t just use GitHub-hosted runners. Maybe you need compute that stays inside a specific AWS VPC, or your setup already lives on AWS and you’d rather keep everything there. In October 2025, GitHub announced support for self-hosted runners for the Cloud Agent, which opens the door to running the whole agent pipeline on AWS CodeBuild. Getting it working end-to-end took some trial and error. This post walks through the setup and, more importantly, the pitfalls I hit along the way.