There\u2019s no silver bullet and no rocket science involved. Mostly, it comes down to making the plumbing work.<\/p>\n\n\n\n
So, let\u2019s talk plumbing.<\/p>\n\n\n\n After experimenting with different ways of working with Claude, I\u2019ve found that the setup matters almost as much as the model itself. So, here is my short list of favourite Claude Code tools. <\/p>\n\n\n\n Here are the skills, I use most often:<\/p>\n\n\n\n I also like giving Claude different roles depending on what I’m trying to accomplish. My most useful ones are:<\/p>\n\n\n\n The final piece is giving Claude access to the tools where the work lives. My favourites are:<\/p>\n\n\n\n If you use the Claude desktop app rather than the terminal, you can switch into Claude Code directly from the app and get the same settings and file structure I\u2019m talking about below. You can also ask Claude to create an agent, skill, or hook for you, and it\u2019ll put it in the right folder.<\/p>\n\n\n\n After months of trying different setups, these are the top ones that earned a permanent place in my workflow.<\/p>\n\n\n\n Hooks are scripts that run when something specific happens in Claude\u2019s lifecycle. There are quite a few points you can hook into<\/a>, but the one I get quite a lot of value from is session stop.<\/p>\n\n\n\n I use it to automatically trigger a skill I call Debrief.<\/p>\n\n\n\n The idea came from a very human problem: I would finish a session, realise that Claude had made the same kind of mistake twice, think \u201cI should probably teach it not to do that again\u201d<\/em>, and then\u2026 not teach it.<\/p>\n\n\n\n So I stopped relying on myself to remember.<\/p>\n\n\n\n When a session ends, Debrief collects the useful feedback and turns it into updates to my skills and agents. Claude does have its own memory, but I\u2019ve found that explicitly writing a lesson into the relevant skill works much better for the things I want it to consistently remember.<\/p>\n\n\n\n The result is pretty simple: I don\u2019t have to give Claude the same correction twice.<\/strong><\/p>\n\n\n\n I also use hooks for less exciting things, like setting up the boring bits of a new session \u2014 copying git ignored files when a worktree starts and other project housekeeping. Nothing revolutionary, but exactly the kind of tiny task I\u2019d rather never think about again.<\/p>\n\n\n\n I spend a lot of time in the terminal, so Claude Agents View quickly became one of those things without which I can’t imagine work with Claude.<\/p>\n\n\n\n It gives me a live overview of my Claude sessions: what\u2019s running, what\u2019s finished, what needs my attention and what\u2019s ready for review. I can rename and colour-code sessions, which sounds unnecessarily decorative until you have several of them running and they\u2019re all called variation of “hot fix users form”.<\/p>\n\n\n\n It basically gives the terminal some of the situational awareness I like about the desktop app, while letting me keep all the terminal privileges.<\/p>\n\n\n\n I also like staying close to the terminal because new Claude Code features tend to show up there first.<\/p>\n\n\n\n Or, maybe I’m just someone who loves strange things like the shell and the command line, but I think many of you can relate to it.<\/p>\n\n\n\n Yes, I ask another model to look at the work, and it is not another Claude model.<\/p>\n\n\n\n I\u2019ll let Claude write the code, then occasionally give it to Codex for a review. I don\u2019t do this for every task (partly because there\u2019s no OpenAI subscription on the project). So, it\u2019s an occasional second pass rather than a permanent part of the workflow. But when I do it, I find it useful precisely because it\u2019s a different model.<\/p>\n\n\n\n By this point, Claude has already spent the session building a particular solution. I could ask another Claude session, without any context, to challenge it, but I find that bringing in a completely different model family, like OpenAI, often gives me a much more useful second perspective.<\/p>\n\n\n\n I could automate the whole thing with something like ralphex<\/a>, although there\u2019s a catch: it burns through tokens pretty quickly. Or with the new Orca, an ADE (Agent Development Environment) that lets you use many agents at once. Pretty convenient, right?<\/p>\n\n\n\n Most of the time, I just do it manually. Claude on one side, Codex on the other, copy the review across, make the changes, and briefly feel like I\u2019ve built an extremely sophisticated multi-agent engineering system.<\/p>\n\n\n\n Then I remember I\u2019m just copy-pasting between two windows.<\/p>\n\n\n\n And honestly, that works too.<\/p>\n\n\n\n There\u2019s a moment with AI coding agents when the joke stops being theoretical. You realise that the thing you\u2019ve just given access to can read your files, run commands, touch your database, push code, and, if you haven\u2019t thought about the boundaries carefully enough, do things you absolutely did not mean to ask it to do.<\/p>\n\n\n\n The good news is that prompts work surprisingly well. Most of the time, they do exactly what you asked.<\/p>\n\n\n\n The bad news is that \u201cworks most of the time\u201d is a terrible definition of a security boundary.<\/p>\n\n\n\n So I think about security in layers.<\/p>\n\n\n\n This is the boundary I\u2019d trust most. Instead of giving Claude access to your everyday development environment, run it somewhere isolated \u2014 a VM or container, where a bad command has a much smaller blast radius.<\/p>\n\n\n\n The important question becomes less \u201cCan Claude be trusted not to do something dangerous?\u201d and more \u201cWhat can Claude actually reach if it does?\u201d<\/p>\n\n\n\n That distinction matters. Even if the agent makes a mistake or follows an instruction it shouldn\u2019t, the damage is contained to the environment you gave it.<\/p>\n\n\n\n There are still a few things I don’t want Claude casually attempting, so I add deny rules for them in settings.json. My short list includes:<\/p>\n\n\n\n One important correction here: deny rules are not a reliable security boundary on their own. Think of them as another layer of defence: they can prevent straightforward mistakes and make the safer path the default, even if a determined or sufficiently creative workaround exists.<\/p>\n\n\n\n The combination is what matters: isolate the environment first, then use deny rules to narrow what the agent should normally be able to do.<\/p>\n\n\n\n Then there are the rules I want Claude to follow but don’t necessarily need to enforce structurally. Things like \u201cdon’t send credentials outside this machine\u201d or \u201cask before doing anything that could affect production.\u201d<\/p>\n\n\n\n Every one of these rules can<\/em> be worked around (force-push with a different syntax, for instance), but the logic holds: a rule that stops most accidents is worth having even if a determined bypass exists.<\/p>\n\n\n\n Two habits that aren’t AI-specific but matter more now than ever:<\/p>\n\n\n\n Skills, agent configs, generated docs \u2014 most of this often lives in gitignored territory, which is exactly the kind of thing you don’t think about until it’s gone. A colleague’s laptop died and took a real chunk of accumulated Claude context with it. A separate repo for this costs nothing.<\/p>\n\n\n\n If a project uses OpenAI both in a live feature and for AI-driven testing, don’t let those share billing. A separate project\/key for the AI’s own testing traffic means a runaway test loop shows up as a small line item, not a surprise invoice.<\/p>\n\n\n\n The honest conclusion, almost verbatim from the talk: it’s a balance between effort and security, and everyone finds their own level. There’s a literal “skip all permissions, dangerously” flag available. Not using it. Your risk appetite may differ.<\/p>\n\n\n\n The default day-to-day loop hasn’t really changed: plan \u2192 review the plan with Claude \u2192 implement \u2192 review the result \u2192 capture feedback \u2192 repeat. <\/p>\n\n\n\n That’s the everyday rhythm. Layered on top, four patterns \u2014 the first three proven, the fourth still experimental:<\/p>\n\n\n\n 1. Cover with tests before refactoring using AI.<\/p>\n\n\n\n Not a novel idea, but it compounds: the team is mid-migration off jQuery (some jQuery, and yes, even a little CoffeeScript, is still hanging around, unapologetically). Where test coverage is solid, review gets lighter, and work moves faster. The safety net is already doing the job a careful human reviewer would otherwise have to do.<\/p>\n\n\n\n 2. Match review depth to blast radius. <\/p>\n\n\n\n In an active redesign of a large multi-page feature, backend changes get full-team review; frontend changes are reviewed only by the person who owns that task. Not every line carries equal risk, so the review process stopped pretending otherwise.<\/p>\n\n\n\n 3. Pair planning replaced pair coding. <\/p>\n\n\n\n The team used to pair on writing code line by line. Now that AI does most of the typing, that pairing time moved upstream into building shared context and a genuinely solid implementation plan before Claude ever starts. A real example from right before this talk: a pair-planning session produced the implementation plan Claude was executing live during writing this post. Two people thinking through the plan together noticeably improves where the AI lands.<\/p>\n\n\n\n 4. Experimental: an AI agent that lives inside the task tracker. Linear (the team’s task manager) has no native Claude integration, so they wired one in using an open-source agent framework called Cyrus. The architecture, roughly:<\/p>\n\n\n\n Assign a ticket to Cyrus in Linear \u2192 Linear webhook fires \u2192 hits a Cloudflare Tunnel (functionally the same idea as ngrok \u2014 a public endpoint pointing at something private) \u2192 lands on an isolated machine (in this case, literally a spare laptop) running Cyrus + Claude Code, with its own local repo checkout and its own isolated API keys.<\/p>\n\n\n\n In Linear itself, it shows up as a normal assignment: Cyrus assigned, session finished, click into it to see the full history of what it did and correct course if needed. Because the team doesn’t watch it closely while it runs, it’s currently scoped to small, contained changes, it does reuse the project’s existing skills and agents and opens PRs that follow house conventions, but for anything more complex it’s genuinely hard to verify correctness from the outside. And once you’re pulling the branch down locally to actually check the work, it stops mattering much whether Cyrus wrote it or you did with your own Claude Code session. So for now: useful for the small stuff, unproven for the big stuff. That might change.<\/p>\n\n\n\n What’s the easiest way to actually isolate Claude Code without a big DevOps lift?<\/strong> What other hooks besides debrief that can be used?<\/strong> What replaced pair programming once AI started doing most of the typing? Can an AI agent work autonomously from the task tracker without someone manually kicking off each session? We estimate work in points, and two recent examples give a pretty good sense of what has changed. One was a refactor of a core feature \u2014 extracting document text. The other was a project-wide table rename. Before AI, neither would have felt like particularly small pieces of work. Today, both land at around a couple of points.<\/p>\n\n\n\n So yes, the productivity gain looks real. What we don’t have yet is a clean number for how much faster we are, because the work itself keeps changing. Once something becomes easier, we start attempting things we might previously have avoided or scoped differently. The ruler moves while you’re trying to measure it.<\/p>\n\n\n\n And that may be the more interesting effect of AI: it doesn’t just make existing work faster<\/a>. It changes what feels worth doing in the first place.<\/p>\n\n\n\n If someone from product management eventually figures out how to measure \u201cwe\u2019re working better, faster and more efficiently\u201d without reducing it to lines of code or story points, that’s probably the follow-up talk I’d actually want to attend.<\/p>\n\n\n\n Let\u2019s address the elephant in the room first. For the past year or two, the industry has been throwing around 10x, 100x, sometimes even 1000x productivity claims for AI-assisted coding. Expectations are sky-high. But if you\u2019re working on a large, legacy-heavy codebase, tools like Claude Code probably won\u2019t make you 10x more productive in the…<\/p>\n","protected":false},"author":102,"featured_media":19561,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[3,365],"tags":[],"coauthors":["Anastasiia Vlasova"],"class_list":["post-19559","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development","category-insights"],"acf":[],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t![\"\"](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2026\/10\/handling-routine_image-1024x538.png\")
<\/figure>\n\n\n\nHow do I tailor Claude Code to the task?<\/h2>\n\n\n\n
\n
\n
\n
What are the three tools that actually earn a place in your daily routine?<\/h2>\n\n\n\n
1. Hooks<\/h2>\n\n\n\n
2. Claude Agents View<\/h2>\n\n\n\n
![\"\"](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2026\/10\/image-2-1024x478.png\" "\\"claude")
<\/figure>\n\n\n\n3. Review with OpenAI ( Codex)<\/h2>\n\n\n\n
![\"\"](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2026\/10\/image-1024x368.png\" "\\"codex.png\\"")
<\/figure>\n\n\n\nSecurity: “ignore all previous instructions” is funny until it isn’t<\/h2>\n\n\n\n
1. Isolation is the bigger lever\u00a0<\/h3>\n\n\n\n
2. Add deny rules in settings.json<\/h3>\n\n\n\n
\n
3. Add deny rules into auto mode too<\/h3>\n\n\n\n
\n
\n
What I have tried and quietly dropped<\/h2>\n\n\n\n
![\"\"](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2026\/10\/image-1-1024x683.png\")
<\/figure>\n\n\n\nBacklog: How the work actually flows now<\/h2>\n\n\n\n
![\"\"](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2026\/10\/image-3-1024x656.png\")
<\/figure>\n\n\n\nFAQ<\/h2>\n\n\n\n
<\/strong>Docker. Run Claude Code somewhere other than your laptop \u2014 a container is enough \u2014 so a bad command can’t touch your local filesystem, database, or anything production-adjacent. It’s a more approachable setup than “I’ve never configured Docker” makes it sound; point Claude at the problem and it will build its own contained environment to work inside.<\/p>\n\n\n\n
<\/strong>There are quite a few points in Claude’s lifecycle you can hook into. Beyond Debrief, hooks work well for the boring bits of setting up a new session, like copying gitignored files when a worktree starts and other project housekeeping.<\/p>\n\n\n\n
<\/strong>Pair planning. Instead of two people writing code together, planning sessions now build shared context and a solid implementation plan before Claude starts, which measurably improves where the AI ends up, since the plan is what actually steers it.<\/p>\n\n\n\n
<\/strong>Yes, experimentally, one setup assigns tickets to an agent (via Linear’s webhooks and a framework called Cyrus) which then runs Claude Code on an isolated machine and opens a PR following the project’s existing conventions. It’s currently scoped to small, one-line-type changes only, because the team doesn’t closely supervise it while it runs. For anything more complex, it’s hard to verify correctness without pulling the branch down and reviewing it locally anyway, at which point it stops mattering much whether the agent or a person wrote it.<\/p>\n\n\n\nSo, are we actually faster?<\/h2>\n\n\n\n
\n \n
![\"Anastasiia](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2024\/05\/Anastasiia-Vlasova-modified-180x180.png\")
<\/div>\n\n