--- title: "My take on using AI for coding" date: 2026-05-07 tags: [claude, ai, claude-code, spec-driven-development, ralph, opinion] summary: Where I land on AI-assisted coding in 2026. Claude Code and the rest are powerful, but prompt steering, guardrails, spec-driven dev and the RALPH loop are what separate "this works" from "I have no idea what I shipped". aliases: [ai-coding-take, using-ai-for-coding, my-take-on-ai-coding] --- ## What I actually use Mostly [Claude](https://claude.ai/). Claude Code in the terminal, Claude in the browser for one-off thinking. I've tried [Cursor](https://www.cursor.com/) and [GitHub Copilot](https://github.com/features/copilot) too, and [Codex](https://openai.com/codex/) is competitive on a lot of tasks. Honestly the gap between the top tools is small compared to the gap between "good prompt with guardrails" and "vibe-coded one-shot". The model matters less than I expected. The harness around it matters more. ## The bottleneck moved When I wrote everything by hand, the slow step was typing and remembering syntax. Now the slow step is reviewing what the model produced and making sure it actually does what I asked, on the inputs I care about, without quietly breaking something else. So the work shifted: - Less time writing boilerplate, glue code, first-pass implementations. - More time reading diffs, writing tests for the diffs, and asking "wait, why did it touch that file?" This isn't a complaint. Reading and reviewing is higher-leverage than typing. But anyone who claims AI coding is "10x faster" without mentioning that the review burden went up too is selling something. ## Prompt steering and guardrails do most of the work The biggest jump in output quality I've seen comes from constraining the model up front: - A `CLAUDE.md` (or equivalent) at the repo root that spells out conventions, commands, and the shape of the codebase. Claude Code reads it on every session. - Permissions, hooks, and explicit allow-lists so the agent can't run arbitrary destructive commands without asking. - Sub-agents and skills for repeatable workflows. The post you're reading was created by a private skill of mine that enforces "branch from origin/main, run /tagore, open a PR, never merge". It's not really a tool, just a workflow I trust wrapped in something Claude can invoke. Without those rails you end up with a very smart intern who occasionally `rm -rf`s something they shouldn't. With them you get a very smart intern who actually checks before doing anything load-bearing. ## "Hey Claude, design a full-blown fullstack knowledge base. Make no mistakes." That kind of prompt almost never produces what you actually want. It produces *something*, usually a plausible-looking scaffold, but: - The model picks defaults that don't match your stack, your hosting, or your constraints. - Trade-offs you'd have argued about (auth model, data store, deploy target) get resolved silently. - Six iterations later you've got a folder full of code you didn't choose, and when something breaks you have no map of what depends on what. I've watched this play out on side projects and on bigger work too. The further you let the AI run without you actually understanding the architecture, the more painful the eventual debugging session. Because at some point there *will* be a debugging session, and the only person who can drive it is someone who understands how the pieces fit. If that's not you, you're stuck. So the takeaway isn't "don't use AI for new projects". It's that understanding the architecture of your application matters more, not less, when AI writes most of the code. You don't need to type every line, but you do need to be able to redraw the box-and-arrow diagram from memory. ## What works better: specs and RALPH The pattern I keep coming back to is spec-driven development plus a tight loop. Spec-driven means: before the model writes code, write down (or have it write down, then edit) what the thing should do, what it should not do, what the inputs and outputs are, and where the edges are. Save that spec next to the code. Then prompt against the spec, not against vibes. The loop part is what [Geoffrey Huntley calls RALPH](https://awesomeclaude.ai/ralph-wiggum), short for Read, Analyse, Loop, Plan, Hone. The short version: don't ask for the whole feature in one shot. Ask the model to read the spec, look at the current state, plan the next small change, make it, then loop. Each pass is small enough to review honestly. Each pass updates the spec and the code together. [claude-mem](https://github.com/blader/claude-mem) bakes a similar workflow in directly. `/make-plan` produces a phased spec, `/do` executes it pass by pass with subagents, and observations from each session feed the next one. One caveat: `/make-plan` and `/do` are barely documented. You kind of have to read the skill source to understand what they actually do. But once you do, they work brilliantly in my experience. There are alternatives, [get-shit-done](https://github.com/gsd-build/get-shit-done) being one of the more visible ones, but most of them feel bloated to me. claude-mem stays small and gets out of the way, which is what I want. ## What I'd tell someone starting today 1. Pick one tool (Claude Code, Cursor, whichever) and learn its harness deeply. Switching constantly is a tax. 2. Always have a `CLAUDE.md` (or equivalent) at the repo root. Update it when conventions change. 3. Write the spec first. Even three bullet points beats nothing. 4. Loop in small increments. Review every diff. Don't merge what you can't explain. 5. When the model surprises you, good or bad, figure out *why* before continuing. The tools are good. They're not magic, and they don't replace the work of knowing what you're building. The people I see getting the most out of them treat the AI as a fast collaborator that needs a clear spec and tight feedback, not as an oracle. ## References - [Claude Code docs](https://docs.claude.com/en/docs/claude-code/overview) - [RALPH method on awesomeclaude.ai](https://awesomeclaude.ai/ralph-wiggum) - [claude-mem](https://github.com/blader/claude-mem) - [get-shit-done](https://github.com/gsd-build/get-shit-done) for comparison