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 and new tools. We still have work to do, right?
So, as a full-stack engineer myself, I wanted to share a short list of things I’ve found genuinely useful when working with AI in engineering. I’ll focus my examples on Claude Code, but most of this applies just as well to Codex or any other AI coding tooling you choose to work with.
Tip №1: Well-written project configuration file, skills and agents
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):
- Main project configuration file
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.
- Skills
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.
It does take time, but don’t 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.
- Agents
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.
Examples of agents: backend developer, frontend developer, QA, reviewer.
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.
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.
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.
Tip №2: Use MCP and CLI
I am more than sure you’ve already bumped into MCPs and CLI. But if needed, here is what these are:
What is MCP (Model Context Protocol)?
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.
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.
What is CLI (Command-Line Interface)?
A CLI is a way to control a program by typing commands in your terminal instead of clicking around a graphical interface (GUI).
How to choose between MCP and CLI?
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.
What are the examples of flows you can do using MCP / CLI?
- Give Claude access to Figma instead of sending screenshots
You get much more precise HTML/CSS output
- Give read-only access to production logs
Ask it to investigate what caused an issue instead of pasting 2000 lines into chat
- Connect GitHub
Let it address review comments directly.
(but make sure that Claude won’t post the comments on your behalf in response – “Great catch” on the syntax correction from your colleague, it can make you feel uneasy:))
Tip №3: Choose Docker environment… or switch to auto mode
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’ve explicitly allowed a bunch of “safe” commands, it will still occasionally invent a new one.
From my experience, if you see too many prompts, you eventually start allowing everything blindly — and that’s where things get tricky.
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.
And so, your blind acceptance of every change doesn’t differ that much in practice.
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.
I would recommend starting with auto mode, which Claude released a month ago. It’s better than allowing everything, it doesn’t ask so many questions, and, God help us, let’s hope Claude engineers made it safe enough not to allow deleting important stuff.
That said, I still prefer the Docker setup. It’s not actually that heavy if you just let Claude build its own cage for you.
Tip №4: Review the changes (yes, all of them)
Sorry for the inconvenience, but this part is non-negotiable.
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’s fun… until it isn’t.
It can make you cry a couple of months later when you look at something you no longer understand and, therefore, can’t fix.
And that’s the trap. It doesn’t break everything immediately. It just slowly turns your codebase into something you can’t fully explain anymore. That’s why it’s important to keep changes small and reviewable. Ask it to avoid large, multi-step transformations in one go. Otherwise, you don’t get productivity, you get a review hell.
After all, responsibility for the code is still on you. And you need to understand what you are doing.
Even if “you” is Claude Code:)
AI changes the pace, not the craft
The way I see it, AI tools don’t really change what good engineering is. They change how fast you can get there, for better and for worse.
So it’s worth setting aside both hype and scepticism for a moment. The fundamentals don’t go away. You still need structure. You still want tight feedback loops. You still keep changes small. And yes, you still review everything.
AI just makes it easier to skip over those steps if you’re not careful.
A bit of a spoiler: I’ll share more in the next article about how I actually use AI in engineering work, and not only. But for now —
Thanks for reading and happy coding!
Example of Claude.md as promised
CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
## Architecture
...
### Key Integrations
- …
## Skills
When writing tests or performing specific tasks, always check `.claude/skills/` for relevant skill guides and follow them:
- …
## Documentation
Product and engineering documentation is available at .... Consult it when you need context about features, product requirements, or engineering decisions.
## Conventions
### Frontend work
Any work under `frontend/` must go through the `frontend-developer` subagent — see `.claude/agents/frontend-developer.md` for the full conventions.
### Backend work
Any work outside `frontend/` must go through the `backend-developer` subagent — see `.claude/agents/backend-developer.md` for the full conventions.
### Simplicity First
Minimum code that solves the problem. Nothing speculative.
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
### Surgical Changes
Touch only what you must. Clean up only your own mess.
When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it — don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that **your** changes made unused.
- Don't remove pre-existing dead code unless asked.
The test: every changed line should trace directly to the user's request.
## Bash Commands
Avoid 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.
## Task workflow
When given a task (URL or ID), follow these steps in order:
1. **Understand the task** — Fetch the issue. Read the description and any linked documents. Explore the codebase to understand what needs to change.
2. **Plan** — 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:
```
1. [Step] → verify: [check]
2. [Step] → verify: [check]
```
3. **Think before coding — state assumptions, surface tradeoffs** — Don't assume. Don't hide confusion.
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them — don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
4. **Define success criteria** — Transform the task into a verifiable goal before implementing:
- "Add validation" → "Write tests for invalid inputs, then make them pass."
- "Fix the bug" → "Write a test that reproduces it, then make it pass."
- "Refactor X" → "Ensure tests pass before and after."
Strong success criteria let you loop independently; weak criteria ("make it work") require constant clarification.
5. **Implement** — Write the code. Follow the conventions and quality checks below.
6. **Commit and create PR** — Commit with a descriptive message, then use the `/create-pr` skill.
## Git workflow
Prefer 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.
## Learning and knowledge persistence
- 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 — technical conventions belong in skills/agents where they'll be applied.
## Self-review before PR
- After finishing the implementation, review your own changes (`git diff`) before creating a PR.
- After self-review, present a summary of the changes to the user and ask them to review before proceeding with the PR.
## Quality checks
- Always write corresponding tests and run them to check that the changes you applied are working
- Always check for the warnings from lint tools in the files you edited and fix them if they exist
- For Ruby files, run `bundle exec rubocop <file>` to check for offenses and fix them. Do not disable offenses with `rubocop:disable` comments — fix the underlying issue instead
- DO NOT run or fix eslint for files you didn't touch
