Claude Code

My CLI’s most frequent user isn’t me lql is a Rust CLI for managing Linear issues. I wrote it because none of the existing alternatives worked for my actual use case: an AI agent that manages issues autonomously. Why I had to write my own CLI Linear’s MCP was the first attempt. The idea is elegant: an MCP server that exposes Linear’s API directly to the agent. In practice, it was slow, unstable, and the agent had to build GraphQL queries from scratch on every call. Each call was an opportunity to invent a field that doesn’t exist. I uninstalled it after two weeks. ...

There comes a time in every programmer’s life, when using coding copilots, where you look at your monthly bill and think: “This is great and all, but I have more subscriptions than my local gym membership.” That moment came for me with quite a lineup: Claude Max 5, Codex Plus, and the temptation to throw in Z.AI with OpenCode for the grunt work. The idea sounded fantastic. The problem? If you throw three agents into your workflow with no ground rules, you’ll end up like a chaotic construction site boss—everyone scrambling around while no one holds the blueprints. ...

TL;DR: If you’re using Codex, use a command to control the session or application, and use a skill to teach the agent a way of working. In Claude Code, the current documentation already treats skills as something you can invoke with /skill-name, so the concepts merge more there. Not so in Codex: types might exist as a skill, but /types won’t exist by default. There’s a common confusion when switching from Claude Code to Codex. And it’s understandable. ...

TL;DR: After 165 sessions with Claude Code and 27 with Codex CLI, one thing is clear: use Claude for interactive, exploratory work and Codex for autonomous tasks you can delegate and forget about. It’s not about which is better — it’s about when to use each. My data shows the combination outperforms either one alone. It’s 9:00 a.m., coffee in hand, and I have a vague idea about restructuring a module. I don’t know exactly what I want yet — I just know the current setup isn’t right. ...

TL;DR: My AI agent had a 246-line instruction file for managing issues in Linear. 150 of those lines were workarounds: hardcoded UUIDs, curl fallbacks, notes like “the CLI doesn’t support X.” I didn’t rewrite them — I built a tool that made them unnecessary. Now those 150 lines are gone. Have you ever written a set of instructions so long that its sheer length proves something is fundamentally wrong? I’m not talking about legitimate documentation. I mean those files that start with “use tool X” and then spend 80% of the text explaining when tool X doesn’t work and what to do instead. Instructions that are, effectively, a list of apologies for the tool you should have built in the first place. ...

Imagine you ask someone to build you a bookshelf. They deliver it. It’s beautiful. It has shelves, screws, everything in place. You lean it against the wall, and it collapses. The screws are fake. They look like screws, but they’re made of plastic. That’s what an LLM does when it abuses the type system. It gives you code that compiles, passes tests, and looks correct. But under the hood, where there should be meaningful types, there are strings. Where there should be explicit state, there’s a nil that means three different things depending on who reads it. And where there should be an enum with two cases, there’s a == "claude" that one day someone will misspell, and no one will notice until production. ...

Have you ever written a technical plan at 11 PM, convinced it was flawless, only to realize the next morning you forgot authentication? Happens to me. More than once. And the worst part isn’t the oversight—it’s that when you use AI to plan things out, the plan sounds so coherent your brain stops looking for flaws. Claude generates a document with sections, dependencies, execution order, and it all checks out. Seems like a senior engineer’s masterpiece. But nobody has challenged it. ...

Imagine you have a brilliant coworker. Solves complex problems, writes clean code, understands what you ask on the first try. But every morning, when you tell them “open the course project,” they look at you with a poker face and ask: “What course? Where is it?” Every day. Without exception. It’s exactly like living with Leonard Shelby, the protagonist of Memento. The guy who can’t form new memories and has to tattoo important things on his body to remember them. ...

I currently have three Claude Code sessions open. One is translating blog posts. Another is writing tests for a CLI. The third is helping me debug a data pipeline. Each one runs in its own worktree, each one in its own Ghostty split, while I jump between them using Cmd+Alt+Arrow. I haven’t opened iTerm2 in months. I haven’t touched tmux in weeks. Everything lives in a single Ghostty window. Is it the perfect setup? No. Is it the most productive setup I’ve ever had? Absolutely. ...

A few weeks ago, I wrote about git worktrees — what they are, how to create them, and why they’re better than cloning a repo three times. The basics. But the basics are only half the story. Because Claude Code doesn’t just work with worktrees — it has native support for them. Dedicated flags, automatic isolation, integration with tmux. And the difference between knowing worktrees exist and knowing how Claude Code uses them is like the difference between having a car and knowing it has sport mode. ...