![\"\"](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2026\/06\/fibonacci_image-1024x536.png\")
<\/figure>\n\n\n\nTip \u21161: Well-written project configuration file, skills and agents<\/h2>\n\n\n\n
Couldn’t really start the list anywhere else. Yes, the prompt still matters. It matters most, actually. There are three main ways I shape it (my examples are in Claude Code, but map them onto whatever workflow you’ve got):<\/p>\n\n\n\n
- \n
- Main project configuration file<\/li>\n<\/ul>\n\n\n\n
In Claude Code, this is your CLAUDE.md file. This file contains the core facts, conventions, and rules about your project. Not be noisy about explanations, I’ll share our actual CLAUDE.md for a Rails + React monolith at the end of this article because the devil is in the details.<\/p>\n\n\n\n
- \n
- Skills<\/li>\n<\/ul>\n\n\n\n
If there is a need to explain, skills are specialised instructions for recurring tasks. Examples of skills: writing frontend tests, backend tests, end-to-end tests (yes, AI now writes most kinds of tests faster than you can argue about whether to write them), refactoring, opening a PR, fixing a red CI. <\/p>\n\n\n\n
It does take time, but don\u2019t regret the hours you spent creating good skills. You’ll earn that time back quickly. And of course, don’t write them by hand. I’ve heard that’s forbidden in 2026:) Ask AI to draft them, then review and improve them.<\/p>\n\n\n\n
- \n
- Agents<\/li>\n<\/ul>\n\n\n\n
Agents are like team members. Fast ones, yet not always very smart. They need clear and very specific instructions, otherwise they will improvise in ways nobody asked for.<\/p>\n\n\n\n
Examples of agents: backend developer, frontend developer, QA, reviewer.<\/p>\n\n\n\n
Sometimes, agents can have intersections with the skills. It is okay, do not worry. In fact, repetition helps. And try to use a subscription instead of API where you pay by tokens.<\/p>\n\n\n\n
The part that matters most across all three is the feedback loop. Keep one skill whose entire job is to debrief each session, so Claude updates its own skills, agents and stops making the same mistake. <\/p>\n\n\n\n
That’s also why we end up with so many md files. They’re big, and loading all of them at once is pointless. Instead, just trust your tool. Claude Code just picks what it needs for the moment, mixes it together, and adds the right details into the prompt.<\/p>\n\n\n\n
Tip \u21162: Use MCP and CLI<\/h2>\n\n\n\n
I am more than sure you’ve already bumped into MCPs and CLI. But if needed, here is what these are:<\/p>\n\n\n\n
\n note<\/span>\n \nWhat is MCP (Model Context Protocol)?<\/p>\n
<\/p>\n
MCP is an open standard, introduced by Anthropic, that lets AI tools like Claude Code connect to external services such as your database, GitHub, Slack, a browser, or your file system through one shared interface.<\/p>\n <\/div>\n <\/section>\n\n\n
The usual analogy is a USB-C port for AI: one standard plug instead of a drawer full of incompatible cables. Before MCP, every integration was a handcrafted snowflake. Now a tool speaks MCP once and can talk to anything that also speaks it. In practice, this is what turns Claude Code from a clever chatbot into something with actual hands. It can reach your real tools instead of just describing, in beautiful prose, what it would do if only it could.<\/p>\n\n\n\n
\n note<\/span>\n \n<\/p>\n
What is CLI (Command-Line Interface)?<\/p>\n
<\/p>\n
A CLI is a way to control a program by typing commands in your terminal instead of clicking around a graphical interface (GUI).<\/p>\n <\/div>\n <\/section>\n\n\n
How to choose between MCP and CLI?<\/h3>\n\n\n\n
If the tool you’re connecting to provides a CLI, use the CLI. It burns fewer tokens and runs faster. When there’s no CLI available or when the integration needs to be more interactive, use MCPs. That’s really it. <\/p>\n\n\n\n
What are the examples of flows you can do using MCP \/ CLI?<\/h3>\n\n\n\n
- \n
- Give Claude access to Figma instead of sending screenshots<\/li>\n<\/ul>\n\n\n\n
You get much more precise HTML\/CSS output<\/p>\n\n\n\n
- \n
- Give read-only access to production logs<\/li>\n<\/ul>\n\n\n\n
Ask it to investigate what caused an issue instead of pasting 2000 lines into chat<\/p>\n\n\n\n
- \n
- Connect GitHub<\/li>\n<\/ul>\n\n\n\n
Let it address review comments directly.<\/p>\n\n\n\n
(but make sure that Claude won\u2019t post the comments on your behalf in response – \u201cGreat catch\u201d on the syntax correction from your colleague, it can make you feel uneasy:))<\/p>\n\n\n\n
Tip \u21163: Choose Docker environment\u2026 or switch to auto mode<\/h2>\n\n\n\n
Claude Code, like any other AI tooling, can be a bit annoying when it comes to permissions. Even if you have a fairly detailed settings file where you\u2019ve explicitly allowed a bunch of \u201csafe\u201d commands, it will still occasionally invent a new one.<\/p>\n\n\n\n
From my experience, if you see too many prompts, you eventually start allowing everything blindly \u2014 and that\u2019s where things get tricky.<\/p>\n\n\n\n
You probably know about the dangerously-skip-permissions mode and that you should absolutely never-ever use it on your laptop. Backed up by scary stories told in Reddit or X by people who deleted production databases, disappearing servers, and collapsed projects.<\/p>\n\n\n\n
And so, your blind acceptance of every change doesn\u2019t differ that much in practice.<\/p>\n\n\n\n
Ideally, you need a Docker environment running in your project folder, with restricted network access and read-only CLI keys. But it requires some time to set up and quite a lot of time to maintain.<\/p>\n\n\n\n
I would recommend starting with auto mode, which Claude released a month ago. It\u2019s better than allowing everything, it doesn\u2019t ask so many questions, and, God help us, let\u2019s hope Claude engineers made it safe enough not to allow deleting important stuff.<\/p>\n\n\n\n
That said, I still prefer the Docker setup. It\u2019s not actually that heavy if you just let Claude build its own cage for you.<\/p>\n\n\n\n
Tip \u21164: Review the changes (yes, all of them)<\/h2>\n\n\n\n
Sorry for the inconvenience, but this part is non-negotiable.<\/p>\n\n\n\n
Claude Code (and tools like it) will absolutely make you faster. You stop fighting with repetitive stuff, and you move at a pace that feels slightly illegal at first. It\u2019s fun\u2026 until it isn\u2019t.<\/p>\n\n\n\n
It can make you cry a couple of months later when you look at something you no longer understand and, therefore, can\u2019t fix.<\/p>\n\n\n\n
And that\u2019s the trap. It doesn\u2019t break everything immediately. It just slowly turns your codebase into something you can\u2019t fully explain anymore. That\u2019s why it\u2019s important to keep changes small and reviewable. Ask it to avoid large, multi-step transformations in one go. Otherwise, you don\u2019t get productivity, you get a review hell.<\/p>\n\n\n\n
After all, responsibility for the code is still on you. And you need to understand what you are doing.<\/p>\n\n\n\n
Even if \u201cyou\u201d is Claude Code:)<\/p>\n\n\n\n
AI changes the pace, not the craft<\/h2>\n\n\n\n
The way I see it, AI tools don\u2019t really change what good engineering is. They change how fast you can get there, for better and for worse.<\/p>\n\n\n\n
So it\u2019s worth setting aside both hype and scepticism for a moment. The fundamentals don\u2019t go away. You still need structure. You still want tight feedback loops. You still keep changes small. And yes, you still review everything. <\/p>\n\n\n\n
AI just makes it easier to skip over those steps if you\u2019re not careful.<\/p>\n\n\n\n
A bit of a spoiler: I\u2019ll share more in the next article about how I actually use AI in engineering work, and not only. But for now \u2014<\/p>\n\n\n\n
Thanks for reading and happy coding!<\/p>\n\n\n\n
Example of Claude.md as promised<\/h2>\n\n\n\nCLAUDE.md\n\n\nThis file provides guidance to Claude Code (claude.ai\/code) when working with code in this repository.\n\n\n## Architecture\n\n\n...\n\n\n### Key Integrations\n- \u2026\n\n\n## Skills\n\n\nWhen writing tests or performing specific tasks, always check `.claude\/skills\/` for relevant skill guides and follow them:\n- \u2026 \n\n\n## Documentation\n\n\nProduct and engineering documentation is available at .... Consult it when you need context about features, product requirements, or engineering decisions.\n\n\n## Conventions\n\n\n### Frontend work\n\n\nAny work under `frontend\/` must go through the `frontend-developer` subagent \u2014 see `.claude\/agents\/frontend-developer.md` for the full conventions.\n\n\n### Backend work\n\n\nAny work outside `frontend\/` must go through the `backend-developer` subagent \u2014 see `.claude\/agents\/backend-developer.md` for the full conventions.\n\n\n### Simplicity First\n\n\nMinimum code that solves the problem. Nothing speculative.\n\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No "flexibility" or "configurability" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\n\nAsk yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.\n\n\n### Surgical Changes\n\n\nTouch only what you must. Clean up only your own mess.\n\n\nWhen editing existing code:\n- Don't "improve" adjacent code, comments, or formatting.\n- Don't refactor things that aren't broken.\n- Match existing style, even if you'd do it differently.\n- If you notice unrelated dead code, mention it \u2014 don't delete it.\n\n\nWhen your changes create orphans:\n- Remove imports\/variables\/functions that **your** changes made unused.\n- Don't remove pre-existing dead code unless asked.\n\n\nThe test: every changed line should trace directly to the user's request.\n\n\n## Bash Commands\n\n\nAvoid compound Bash commands chained with `&&`, `||`, or `;` (e.g. `source ~\/.nvm\/nvm.sh && nvm use 24 && git commit`). Compound commands require additional user approval since the permission rules match each command individually. Run commands separately instead.\n\n\n## Task workflow\n\n\nWhen given a task (URL or ID), follow these steps in order:\n\n\n1. **Understand the task** \u2014 Fetch the issue. Read the description and any linked documents. Explore the codebase to understand what needs to change.\n2. **Plan** \u2014 Use plan mode to design the implementation. Identify all files to modify, patterns to follow, and edge cases. For multi-step tasks, state a brief plan with verification steps:\n ```\n 1. [Step] \u2192 verify: [check]\n 2. [Step] \u2192 verify: [check]\n ```\n3. **Think before coding \u2014 state assumptions, surface tradeoffs** \u2014 Don't assume. Don't hide confusion.\n - State your assumptions explicitly. If uncertain, ask.\n - If multiple interpretations exist, present them \u2014 don't pick silently.\n - If a simpler approach exists, say so. Push back when warranted.\n - If something is unclear, stop. Name what's confusing. Ask.\n4. **Define success criteria** \u2014 Transform the task into a verifiable goal before implementing:\n - "Add validation" \u2192 "Write tests for invalid inputs, then make them pass."\n - "Fix the bug" \u2192 "Write a test that reproduces it, then make it pass."\n - "Refactor X" \u2192 "Ensure tests pass before and after."\n Strong success criteria let you loop independently; weak criteria ("make it work") require constant clarification.\n5. **Implement** \u2014 Write the code. Follow the conventions and quality checks below.\n6. **Commit and create PR** \u2014 Commit with a descriptive message, then use the `\/create-pr` skill.\n\n\n## Git workflow\n\n\nPrefer adding new commits over amending or rebasing existing ones. This avoids force pushes, which require extra user approval. Only rebase or amend when explicitly asked.\n\n\n## Learning and knowledge persistence\n\n\n- When you learn a new convention or pattern about the project, save it to the relevant skill file (`.claude\/skills\/`) or subagent file (`.claude\/agents\/`), not to memory. Memory is for user preferences and project context \u2014 technical conventions belong in skills\/agents where they'll be applied.\n\n\n## Self-review before PR\n\n\n- After finishing the implementation, review your own changes (`git diff`) before creating a PR.\n- After self-review, present a summary of the changes to the user and ask them to review before proceeding with the PR.\n\n\n## Quality checks\n\n\n- Always write corresponding tests and run them to check that the changes you applied are working\n- Always check for the warnings from lint tools in the files you edited and fix them if they exist\n- For Ruby files, run `bundle exec rubocop <file>` to check for offenses and fix them. Do not disable offenses with `rubocop:disable` comments \u2014 fix the underlying issue instead\n- DO NOT run or fix eslint for files you didn't touch<\/code><\/pre>\n\n\n\n\n \n![\"Anastasiia](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2024\/05\/Anastasiia-Vlasova-modified-180x180.png\")
<\/div>\n\n \n Article by<\/span>\n \n Anastasiia Vlasova <\/span>\n\n Anastasiia is a full-stack developer rooted in Ruby on Rails, with React on the frontend and 13+ years of shipping real products. From greenfield builds to untangling legacy code, she’s comfortable across the stack, including search, databases, and third-party integrations. Here, she shares practical insights on building applications that work and keep working.\r\n\r\nLinkedin<\/a> <\/div>\n \n <\/div>\n<\/section>","protected":false},"excerpt":{"rendered":"Programming has always moved fast. Yet when AI showed up, it rewrote this “fast”. It made many of us feel like we spent our whole careers on horseback, only to wake up on a high-speed train and realize we’re already running late. And it’s hard not to get overwhelmed by the constant stream of updates…<\/p>\n","protected":false},"author":102,"featured_media":19156,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[3],"tags":[],"coauthors":["Anastasiia Vlasova"],"class_list":["post-19117","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development"],"acf":[],"aioseo_notices":[],"categories_data":[{"name":"Engineering","link":"https:\/\/railsware.com\/blog?category=development"}],"post_thumbnails":"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2026\/06\/fibonacci_icon.svg","article_background":"#f1f5fd","amp_enabled":true,"_links":{"self":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/19117","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/users\/102"}],"replies":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/comments?post=19117"}],"version-history":[{"count":15,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/19117\/revisions"}],"predecessor-version":[{"id":19151,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/19117\/revisions\/19151"}],"wp:attachment":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media?parent=19117"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/categories?post=19117"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/tags?post=19117"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/coauthors?post=19117"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Connect GitHub<\/li>\n<\/ul>\n\n\n\n
- Give read-only access to production logs<\/li>\n<\/ul>\n\n\n\n
- Give Claude access to Figma instead of sending screenshots<\/li>\n<\/ul>\n\n\n\n
- Agents<\/li>\n<\/ul>\n\n\n\n
- Skills<\/li>\n<\/ul>\n\n\n\n