The last half of the year I went silent. Claude Code went mainstream and got so good that now it just works in many cases without the need of some tips and tricks. Initially, I felt good about being right about the tool but quite soon I got… depressed.

My monkey brain extrapolated where things were heading and I got into the infinite loop of doom and end of the world.

The narrative “AI won’t replace developers, developers with AI will replace developers without it” started appearing as a denial phase:

• LinkedIn got a burst of posts about people vibecoding full apps in a matter of a few evenings.

• Articles about ChatGPT solving math problems started popping up one after another in a matter of days.

• Linus Torvalds posted on GitHub that he vibecoded an audio visualizer.

• DeepMind Chief AGI Scientist tweets about incoming AGI in 2028 with 50% chance in the thread about hiring Senior Economist for post-AGI economics research.

From every corner you can hear that Software engineering is DONE, IT’S OVER, come work at McDonald’s!

And just like that you find yourself almost having a panic attack.

Well, as an undisputed world boxing champion once said: “Don’t push the horses!“!

The first thing I did to calm down was focusing on what I can control.

If AGI is here in 6 months/1 year/2 years, there are literally zero things I can do to prevent it. The amount of investments in AI in 2025 was 200 billion+, we had comparable investments only in the Dot-Com bubble, thanks to which we have amazing cheap internet nowadays. So if it’s possible at all to reach AGI based on LLM-architecture, humanity for sure will reach it and I cannot do anything about it.

Can I prepare for it? Not really. The richest companies are hiring the best minds of the world to do analysis and prepare for possible outcomes, odds are not in my favor. No point in spending time and energy here.

What if AGI won’t happen in the next 5 years?

In this case we have to deal with the fact that we got a new tool that can write code quite well based on provided human text. As any tool, it will get cheaper and better with time.

How does it impact the industry?

Any automation decreases the number of jobs in an industry. Thanks to LLM’s tendency towards hallucinations and sometimes very good plausible but completely wrong answers, you need an expert in the domain area to validate whatever it produces. If you dig deeper into articles about ChatGPT solving math problems you will discover that in many cases solutions existed before but were not properly published and ones that were really solved didn’t have novel approaches at all. Without human experts we would be giving Nobel Prize to AI every day for slop.

Ok, so we need to have an expert, who are the primary experts in Software development? PM + Technical lead. Now PM can do way more things, what required Tech lead in the past now can be done with LLM. It might not be obvious but the same applies to the Tech lead, now they can do a lot of PM’s job way easier as well as getting information about the domain and edge cases became trivial as well. So it’s highly likely we will see a merge of these roles into one. There is quite a strong case for devs being PM in a technical product, like development of a new database. A non-technical user is highly unlikely to have enough expertise to understand the problem and demand for a new solution in the first place. Such products are usually built with low-level programming languages like C++/Go/Rust, so instead of switching fully to being electricians it’s worth considering switching to these languages first.

What about other roles?

Using LLM as a code writing machine already made a good chunk of devs in fact QA specialists. Many companies have eng. policy “you wrote it - you own it”, which means infrastructure and maintenance on devs as well. Throw the ultimate teacher that can explain everything in the picture and it becomes quite obvious that we will see a transition of the role towards something more generic, like Automator/Integrator, where it would be expected to cover entire solution end-to-end.

Will we need fewer automators than software devs we currently have?

Instinctively, you want to say yes. However, there is a possibility that:

• Expectations from the software will increase. Now everyone can produce low-quality MVP in a matter of hours. There is already a surge of new apps to Apple App Store. There are rare success stories about making good money out of it because even if an app has a good idea, it’s easy to copy it. So, everyone is and will be looking to get an upper hand.

  Currently, I see people betting on distribution (marketing), which is a valid point, however I feel like reliability would be among top requests from users after we get fatigue from buggy software. The success path was always the easy part of software engineering. The last 10% of any project were always the most challenging and required the most effort. I bet not everyone enjoys choosing trade-offs and thinking about edge cases on a daily basis.

• The number of lazy people will just increase as more and more people will delegate thinking to AI. The truth is that all information was available to everyone for quite some time thanks to the internet but we still have travel agencies and consultants. Even if the research part becomes trivial you still need to use your brain to ask right questions, that’s where expertise comes in handy. And that’s what people will be paying for “think instead of me“.

• Several huge security incidents will happen due to LLM/AI agent flaws (e.g., prompt injection). LLM providers won’t have any liability and answer that it was a “skill issue“ of one using their product.

  To some extent it’s already happening. For instance, after the rollout of Claude Codex Boris Cherniy was flexing that all of it was written by Claude Code itself. But Codex had many issues, so users on Reddit were joking that “you can tell it was built by AI“, on top of that it had some serious security issues but Anthropic said it’s the responsibility of the LLM users.

  Obviously business owners don’t want to deal with this stuff and would hire someone to be responsible for this.

  

• Every company will build all software tooling in-house, as there is no point in paying for SaaS anymore right? They will learn about maintenance costs quite quickly, so they might just hire an automator to manage all of it. Turns out “we’ll just build it ourselves” hits different at 4am when prod is down and you got sued by thousands of angry customers.

In my opinion, these reasons won’t be enough and the number of automators would be lower until we have immense complication in software products. We just won’t have a sharp drop in numbers.

So the best thing to do is to become such an automator already. For that one needs to forget about roles split (backend/frontend/devops/ml/security/mobile), you just do whatever is needed by the business, if you don’t know something - you have the best teacher in the world as long as you ask right questions. Asking right questions is what most senior devs do anyway, so you should be good at it already. The hardest adjustment for me was to accept that now it’s acceptable to solve problems in a sub-optimal way as long as you don’t spend time on it and throw more compute at the problem. There is even a technique for this called Ralph Loop. Here is a great post about the approach from Ralph Wiggum, the creator of this masterpiece. If you don’t have time to read it, here is a secret formula:

while :; do cat PROMPT.md | claude-code ; done

Congratulations, now you are a senior Ralph dev!

Ok, that’s great but you still have anxiety that AI will take your job next month?

Look at LLM providers’ actions not their words

OpenAI rolls out ads. In 2025 Sam Altman said that adding ads would be a last resort for them. If AGI is around the corner, why bother?

Anthropic’s CEO says that we won’t need developers in 6 months every 6 months. Meanwhile the company keeps hiring devs.

Why bother if you fire them in 6 months?

Because of these contradictions I prefer to believe Yann LeCun (one of three “Godfathers of AI/Deep Learning”) in this matter:

TLDR

• Don’t stress over things you cannot control. If AGI is here, it’s a completely new world. You cannot prepare for a post-AGI world as no one knows what’s coming.

• Develop yourself towards being Automator/Integrator, don’t be attached to your current job title. Learn Rust and apply Ralph loop on all problems you see around you.

• Look at actions not words of LLM providers.

• Breathe out and remember that asking right questions and thinking is not what everyone loves to do, so there will always be demand for these until AGI-era arrives.

In my last post, I showed you how to get hooked on Claude Code. But here's what I didn't tell you: even with the perfect setup, your honeymoon will end. Mine lasted only several weeks.

It's unavoidable, as with every new technology you pass three stages:

• Week 1: I can do everything with it/ It’s x10 improvement in my workflow!

• Week 3: “It sucks!” - after learning limitations of the tool.

• Month 2: “It’s a nice tool in the right situation“ - after having decent experience with it.

Claude Code or any other coding agent is not an exception. However, the limitation is far from typical as developers are used to - its nondeterministic nature. So the first thing that a developer asks when Claude skips some instructions or produces slightly different interface than expected “how can I force it to do exactly what I said?!“. Well, you cannot.

Remember, you are not a developer anymore, you are a manager. Human managers have this dilemma all the time, especially with junior/middle folks:

You tell someone how to solve a problem, they start implementation, somewhere in the middle they find new information, sometimes it changes everything(starting with a case when you already have an existing component that does what you need and ending up when the whole approach is wrong because of hidden constraints) and at that moment it’s not clear for them what to do:

• To ask the manager? But the manager asked them to do exactly what they were told to do. You might think that it’s obvious that you should ask in such situations but often the new info doesn't matter because of context they don't have. And providing of all information would take way more time and one can easily forget details somewhere in the middle, so it’s simply not worth it.

• Ignore and follow instructions? but then your manager would tell you that new information changes everything and you should have told them earlier about it.

Quite a high chance of looking like a fool regardless of a choice, and we are dealing with a human who can actually think!

Obviously, Claude can't think. But it learned from code where developers made different choices having situations described above, so solution wasn’t deterministic even in the beginning. So no point of being mad about it, better just to accept it as a limitation of the tool. But here's the thing: acceptance doesn't mean helplessness. It means getting smarter about how we work with the chaos.

Embracing the Chaos

First, you need to understand where non-determinism is acceptable. Usually, these are implementation details. If you tell Claude Code literally every line to write you will achieve 100% determinism, but what’s the point, it would be faster to write the code yourself. So you need to focus on things that matter:

• Product requirements.

• Data flows.

• APIs contract between backend and frontend.

• System components, which will be changed during development of the task.

• Test cases.

These things you need to pay close attention to and even write yourself(WHAT?! It’s so 2024! ) an initial version.

Second, you need to learn to control the context of Claude code. Providing entire codebase and giving a ticket number only will work on small projects at best. If you have a legacy project, it will lead to hallucinations quite quickly.

Recently I was adding multi-currency support to several screens of an app. I nailed it with Claude for the first screen, so I naively thought that second one would be a piece of cake and wouldn’t take more than 30 mins of Claude’s time. Oh boy, how wrong was I! I’ve made four attempts starting from scratch with Claude, but I failed miserably. This page made Claude drunk instantly, I was swearing like I am the worst human-being on the planet. Nothing helped.

I felt not like an orchestrator but like a manager of a rock band, where a star singer got drunk and found his calling as a ballerina because he saw a tweet with ballet performance 5 minutes ago.

So I’ve decided to do unimaginable - do everything myself.

Turned out, that page was in the middle of transition to a new graphql client. Had one title but under the hood was using completely different models and several different APIs(new graphql one, old graphql API and REST API), and, ofcourse, all three had endpoints named after the page title, but none were actually relevant. Poor Claude. Instead of half an hour, I spent almost a week on it. (Every developer right now: haha, classic).

After several such occasions, I’ve started seeing patterns when my son comes home drunk Claude struggles with a given task. Eventually I came up with key pieces of the puzzle to avoid having such surprises:

• A proper structure of documentation with file maps.

• A prompt that asks claude to work only with specific directories and forbids even reading from not allowed directories.

• Giving up quickly. If I want to start swearing - time to give up and try again from scratch.

• Addressing technical debt in related area first, even Claude prefers clean architecture and code!

The Documentation System

Here's the structure that finally tamed the chaos (and yes, those feature names are real):

leprik-ai/
├── docs/
│   ├── product/
│   │   ├── awesomeness/
│   │   │   ├── feature.md          # Feature overview & entry point
│   │   │   ├── implementation.md   # Technical design
│   │   │   └── file-map.md         # Explicit file references
│   │   ├── pragmatic-insights/
│   │   │   ├── product-reqs.md     
│   │   │   ├── implementation.md   
│   │   │   └── file-map.md        
│   │   └── no-hype/
│   │       └── ...
│   ├── architecture/
│   │   └── system-overview.md
│   ├── dev/
│   │   └── qa-guidelines.md
│   │   └── be-guidelines.md
│   │   └── fe-guidelines.md
│   └── overview.md                   # Master documentation index
├── backend/
├── frontend/
├── infrastructure/
├── CLAUDE.md

When product gets bigger a product directory becomes : domain → features → sub features. Same structure + index files at every level, so Claude can quickly find only files related to the feature it’s working on.

file-map.md is a simple file with list of all related files to the feature.

Architecture directory can be extended with graphs(Mermaid diagrams would work perfectly), ADRs or C4 diagrams.

I like this structure the most because in the future, when you have insane amount of docs you can easily build MCP around your docs + RAG for fast retrieval of the data make search more efficient.

If you work only with, let’s say frontend repo, you can try a simpler setup when every component has README.md file, which explains what component does and what features it supports and what files it has.

If you are extremely lazy, you can use Repomix to convert a specific directory to md format and provide it to Claude as documentation (though proper documentation structure pays off in the long run)

My main workflow is:

• Having a ticket in linear with description of desired changes.

• Start claude with this prompt:

Create a plan for the implementation of ticket #ENG-4242, read product related documentation in @leprik-ai/docs/product/awesomeness/feature.md, follow dev guidelines during development defined in @leprik-ai/docs/dev/

You are allowed to work ONLY in these directories:
- /backend/src/awesomeness.
- /frontend/src/awesomeness/

Do not access any other directories or files outside this list.

• I ask it to store the plan as md file, so I can continue implementation if somewhere in the middle Claude run autocompact process. I don’t like autocompact because usually Claude gets amnesia and needs to read CLAUDE.md file several times before it can remember what commands to use. That’s why I prefer to use /compact myself and use the created file as a part of summary.

• After that I ask Claude to implement the task via several sub-agents providing information about allowed directories again.

I am lazy, so instead of typing such prompts every time I’ve created custom commands.

Automating the Workflow

Creation of own command is trivial:

mkdir -p .claude/commands # inside the project

touch .claude/commands/plan-issue.md

Here is example of the prompt(don’t forget to use Anthropic’s prompt generator to improve your prompts):

---
allowed-tools: ReadFile, Bash(ls:*), Bash(fd:*), Bash(rg:*)
description: Create implementation plan for a ticket with directory restrictions
---

You are tasked with creating a plan for the implementation of a ticket. Follow these instructions carefully:

1. Parse the input arguments:
Parse the {{ARGUMENTS}} string, which is in the format "TICKET_NUMBER | PRD_PATH | ALLOWED_DIRS". Extract the ticket number, path to product documentation, and allowed directories from this string. Stop execution if any of the required arguments are missing or invalid and notify the user.

2. Read product documentation:
Access and thoroughly read the product-related documentation located at the PRD_PATH you extracted from the arguments. This documentation contains crucial information about the product that will inform your implementation plan.

3. Follow development guidelines:
Adhere to the development guidelines defined in @leprik-ai/docs/dev throughout your planning process. These guidelines ensure consistency and best practices in development.

4. Observe directory restrictions:
You are only allowed to work within the directories specified in the ALLOWED_DIRS section of the parsed arguments. Do not include any files or directories outside of this list in your implementation plan.

5. Create the implementation plan:
Based on the information from the product documentation, development guidelines, and directory restrictions, create a detailed plan for implementing the ticket.

Remember to only include tasks and files within the allowed directories, and ensure all aspects of your plan adhere to the development guidelines you've read.

After the plan looks good to both of us (me and Claude's army of agents), I use command /implement-plan command, which has similar limitations regarding working directories as previous prompt. And the last command that I use is /update-docs, the prompt for this command is quite long and contains many bash commands, so it doesn’t look nice on Substack. So I'm only showing the beginning to demonstrate another feature - execution of bash commands and using their output in the prompt:

---
allowed-tools: ReadFile, Edit, Bash(git:*), Bash(fd:*), Bash(ls:*), Bash(test:*), Bash(echo:*), Bash(rg:*), Bash(head:*), Bash(sort:*)
description: Update feature documentation based on current changeset
---

# Update Feature Documentation

Update documentation for feature at path: $ARGUMENTS

## Initial Setup
Set feature directory path:
!`FEAT_DIR="$ARGUMENTS"; echo "Feature directory: $FEAT_DIR"`

Check Git repository status:
!`if git rev-parse --git-dir > /dev/null 2>&1; then echo "✓ Git repository detected"; else echo "⚠️ Not in a git repository - skipping git-based analysis"; fi`

Current branch (if in git):
!`git rev-parse --git-dir > /dev/null 2>&1 && git branch --show-current || echo "N/A"`

## Step 1: Validate Feature Directory
Check if the provided path exists:
!`test -d "$ARGUMENTS" && echo "✓ Directory exists: $ARGUMENTS" || echo "✗ Directory not found: $ARGUMENTS"`

List current documentation files:
!`find "$ARGUMENTS" -maxdepth 1 -name "*.md" -type f 2>/dev/null | sort || echo "No markdown files found"`

If directory doesn't exist or empty, notify the user about it and ask to provide correct path.
## Step 2: Check/Create implementation.md
!`test -f "$ARGUMENTS/implementation.md" && echo "✓ implementation.md exists" || echo "⚠️ implementation.md missing - will create"`

If implementation.md doesn't exist, create it with this template:
...
## Step 3 ...

Want the full version? Just ask (though Anthropic's generator works great too)

That’s it, next time when you need to make an addition to the feature you have entire relevant context defined in a proper docs directory, so you just need to ask Claude Code to use it and nothing else. In most of cases it works pretty well.

When does it not work? Obviously, when a skin sack(aka me), forgets to run a command for updating docs. Humans are great source of non-determinism as well. In a perfect world, we could have just updated the command /implement-plan to execute /update-docs in the end, but I noticed that it’s not efficient for complex tasks as it’s rarely a one-shot story and I had to ask Claude follow-up tweaks.

The best idea that I came up with was a pre-commit hook. However, I don’t want to annoy everyone in the team by forcing this command, so I've decided to try Claude Code hooks feature, which was released a few weeks ago.

Claude Code hooks

I’ve added such hook inside ./claude/settings.json file:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "./scripts/claude-hooks/update-features-docs-reminder.sh"
          }
        ]
      }
    ]
  }
}

Basically, Claude Code will execute our sh file before any bash command.

Here is the script itself:

#!/bin/bash
# update-features-docs-reminder.sh
# Detects /implement-plan commands in the session

# Read the JSON input
TOOL_INPUT=$(cat)

# Extract fields
TOOL_NAME=$(echo "$TOOL_INPUT" | jq -r '.tool_name // ""')
SESSION_ID=$(echo "$TOOL_INPUT" | jq -r '.session_id // ""')
TRANSCRIPT_PATH=$(echo "$TOOL_INPUT" | jq -r '.transcript_path // ""')

# Only process Bash commands
if [ "$TOOL_NAME" != "Bash" ]; then
    exit 0
fi

COMMAND=$(echo "$TOOL_INPUT" | jq -r '.tool_input.command // ""')

# Check if it's a git commit command
if ! echo "$COMMAND" | grep -Eq "(^|&&|;|\|)\s*git commit"; then
    exit 0
fi

# Check the transcript for actual /implement-plan commands in current session
if [ -f "$TRANSCRIPT_PATH" ] && [ -n "$SESSION_ID" ]; then
    # Check if /implement-plan was run in current session
    # Look for the exact pattern in user messages
    IMPLEMENT_PLAN_FOUND=$(grep "\"sessionId\":\"$SESSION_ID\"" "$TRANSCRIPT_PATH" | \
                          grep '"type":"user"' | \
                          grep -c '<command-name>/implement-plan</command-name>')

    if [ "$IMPLEMENT_PLAN_FOUND" -gt 0 ]; then
        # Check if update-docs was also run or if user said skip docs
        UPDATE_DOCS_FOUND=$(grep "\"sessionId\":\"$SESSION_ID\"" "$TRANSCRIPT_PATH" | \
                           grep -E '<command-name>/update-docs</command-name>|<command-name>/update-feature-docs</command-name>|skip docs|no docs needed' | \
                           wc -l)

        if [ "$UPDATE_DOCS_FOUND" -eq 0 ]; then
            echo "🔍 Found /implement-plan command without docs update" >&2

            cat <<EOF
{
    "decision": "block",
    "reason": "You ran /implement-plan in this session. Before committing:\n\n1. Please specify the documentation file path (e.g., 'docs/product/awesomeness')\n2. I'll run /update-feature-docs <path>\n3. Then proceed with the commit\n\nIf no documentation update is needed, just say 'skip docs' to proceed."
}
EOF
            exit 0
        else
            echo "✅ Docs already handled in current session" >&2
        fi
    else
        echo "✅ No /implement-plan command found in current session" >&2
    fi
fi

# Proceed with commit
echo "✅ Proceeding with git commit" >&2
exit 0

It will check if Claude tries to execute git commit command and if so it will check whether you used /implement-plan within this session and didn’t cover it with a documentation.

Even though this script works, it took significant efforts to debug it initially. If you run claude —debug it shows additional information about hooks invocation, useful but still not enough as majority of time you are testing and debugging bash scripts.

At this stage I would recommend to wait for another iteration over this feature from Claude’s team. And use it only for simple cases, like notifications.

In my previous post, we asked Claude in CLAUDE.md to notify us whenever he needs an input from us. Unfortunately, it doesn’t always work. Claude forgets to do it from time to time: usually after automatic compact(once again, you should avoid having those because Claude has complete amnesia in most of cases after this) or when sub-agents are involved, sometimes Claude just swallows messages from them.

Hooks are a perfect solution in this scenario. I’ve created a simple terminal-notifier.sh script:

#!/bin/bash

HOOK_INPUT=$(cat)
HOOK_EVENT=$(echo "$HOOK_INPUT" | jq -r '.hook_event_name // ""')

# Send notification with Claude app as sender
notify() {
    terminal-notifier \
        -title "Claude Code" \
        -message "$1" \
        -sound "$2" \
        -sender "com.anthropic.claudefordesktop"
}

# Handle events
case "$HOOK_EVENT" in
    "Notification")
        NOTIFICATION=$(echo "$HOOK_INPUT" | jq -r '.notification // ""')
        if echo "$NOTIFICATION" | grep -qi "permission\|confirm\|proceed\|Do you want"; then
            notify "Input needed" "Ping"
        else
            notify "$NOTIFICATION" "Pop"
        fi
        ;;
    "Stop")
        notify "Task completed" "Glass"
        ;;
esac

exit 0

and updated hooks settings

"Notification": [
  {
    "matcher": "",
    "hooks": [
      {
        "type": "command",
        "command": "./scripts/claude-hooks/terminal-notifier.sh"
      }
    ]
  }
],
"Stop": [
  {
    "matcher": "",
    "hooks": [
      {
        "type": "command",
        "command": "./scripts/claude-hooks/terminal-notifier.sh"
      }
    ]
  }
]

After this I can clean up notifcation part from my CLAUDE.md file and will start seeing this beauty:

TLDR

TLDR for Claude Code’s junkeys who will use Claude to summarize this article:

• Embrace non-determinism and pick your battles.

• Manage Claude’s context properly:

  • Avoid autocompact at any cost.

  • Share only relevant documentation for the current task.

  • Limit access to non-related folders/files so Claude doesn’t clutter its context, which decreases chances of hallucination.

  • Automate workflows to eliminate humans from equation.

  • When it doesn’t work try treating Claude as an imbecile and tell him about it without hesitations, if it doesn’t work - threaten to fire it. Surprisingly, it works really well (Does Claude have US work experience?).

• Know when to give up. If you caught yourself, swearing at Claude again and again, highly likely your code is unbelievable mess and you need to clean it up first or your task is so complex that you need to break it up for Claude yourself.

Happy shipping and don’t forget to subscribe!

Subscribe now

As an engineering leader I observe two almost non-overlapping worlds:

• In one of them, AI agents have won and we don’t need developers anymore (in fact, we don’t need anyone except influencers with their posts about another tool killing another one)

• and in another, ChatGPT (we have only one LLM, right?) is always drunk Frankenstein who suggests only dumb shit and only good at rewriting corporate emails.

Initially, I belonged to the second camp for quite a while even though I tried Cursor a year ago before it became mainstream. I moved close to the first camp only when I tried Claude Code for extensive amount of time.

Why Claude Code

Regardless of organization, the majority of developers are opinionated, they don't like to be told what to use especially when it’s related to their tooling. That’s the exact reason, why such a simple thing like “a limited set of supported tooling in the company” is not trivial and requires exceptional Developer Experience team in the organization.

Because of it, I always prefer CLI tools, they are easy to integrate in any existing workflow. So I got hooked to Claude Code almost immediately, the only reason which stopped me from promoting it in the company was price. I created a PR within an hour, the PR was a fix for a small issue, which required changes in multiple repositories. It cost me $3, which was quite expensive even though the experience was amazing. So I postponed this idea for a while and was trying to make Cursor work according to my needs, failing in it again and again. Until Claude made Claude Code part of the Pro plan, which allowed me to use it with fixed rate of 100$ per month.

Saying that I got hooked would be an understatement, I was waiting for limits to be reset several times per day, so it took me only one week to give up and upgrade to x20 Pro plan. Now I am a Claude junky.

Here is my setup if you want to accompany me.

Mindset shift

Before jumping into specifics, it’s important to understand shift in work - you are no longer an executor, you are an orchestrator and responsible for results while you work through others. In a nutshell, you are a manager but a manager of an agent(s), not humans.

This is a key to efficient work with AI. Yes, you can deliver complex feature faster than AI, yes, you can do it without hallucinations. That's what most managers were capable of when they just switched their path to management. It wasn’t scalable, so they had to learn how to work through other people with all accompanying imperfections. I guess you won’t argue that an entire department outperforms a single dev in most cases. So you are a single dev now and you need to learn how to run an entire department. That’s where you are if you still don’t use AI.

Now let’s consider a typical flow of any project:

Planning → Execution → Testing → Rollout → Bug fixes

If you apply your new mindset, you do not control execution at all but you are still responsible for results. How to be sure that you get what you wanted?

You need to have a detailed plan with clear acceptance criteria, so it’s objectively easy to determine if the target has been achieved. The validation should be a quick operation, ideally automatic.

• How can you say that the goal was achieved? A unit test, integration test or E2E test. Depends on the goal.

• How can you say that it was done properly? A properly configured linter should cover a big part of it. Everything else should be formulated as Code guidelines and put into repo as an md file.

• If needed write additional scripts that would run complex checks.

Claude Code configuration

To install:

npm install -g @anthropic-ai/claude-code

Claude Code uses a CLAUDE.md file for getting information about the project, you can create this file yourself in the root of the project or ask Claude to review the entire project and generate this file. To do this go to your directory and run in console:

claude

after that type

/init

and you will get a generated CLAUDE.md.

Add something like this to your CLAUDE.md file to be sure that whatever Claude does it will run linter and tests before it considers anything done:

# CLAUDE Development Guidelines

## Core Principles

### 1. Quality Assurance Protocol
**MANDATORY**: All code changes must pass the following checks before considering ANY task complete:

1. **Linter**: Code must pass all linting rules without warnings
2. **Tests**: All existing tests must pass + new tests for new functionality
3. **Type Checking**: If applicable (TypeScript, Python type hints, etc.)
4. **Code Review**: Self-review for best practices and potential issues

### 2. Pre-Completion Checklist
Before marking any development task as "done":

- [ ] **Linter passed** - Zero warnings/errors
- [ ] **All tests passing** - Existing + new test coverage
- [ ] **Code formatted** - Consistent with project style
- [ ] **Documentation updated** - If public APIs changed
- [ ] **Edge cases considered** - Error handling implemented
- [ ] **Performance validated** - No obvious bottlenecks introduced

### 3. Development Workflow

#### For Every Code Change:
```bash
# 1. Run linter first
npm run lint        # or equivalent for the project

# 2. Fix all linting issues before proceeding
npm run lint:fix    # if auto-fix available

# 3. Run tests
npm test           # or equivalent

# 4. Add new tests if needed
# Write tests for new functionality
# Ensure edge cases are covered

# 5. Verify everything passes
npm run ci         # if available (runs lint + test + build) 

Tip: Use https://console.anthropic.com/dashboard for prompt generations or edits to CLAUDE.md

With this setup you already decrease number of reviews needed from your end dramatically. However, your junior partner still needs a lot of information from you:

• details of the task

• design if your task involves frontend

you don’t want to describe it in details, especially colors of your design, so we need to provide tooling to our junior partner. This tooling is called MCP server. There are many of them available already. However, you need to be cautious, as it’s relatively new technology and it opens a new vector of attacks, so better to use only official MCP servers and only ones you actually use. Here is an awesome list of MCP servers.

I personally use only these:

• Linear MCP, so I explain what’s needed to be done only once.

• Figma MCP to provide links to the design, so Claude can get understanding of the design. It uses many tokens though, so better to turn it off and provide screens of the design if you are not on x20 Max plan.

  Tip: Use Ctrl+V(not cmd +v!) combination to insert a picture into claude code

• Serena MCP to give Claude ability to work with code as a code and not simple text. From a pragmatic standpoint it speeds up claude significantly as the time to read files drops.

• Context7 to use up to date technical documentation. Cannot say that it has a big impact as I work primarily with mature tech(who am I kidding, it’s legacy).

There are bunch of MCPs that give an access to browser to Claude, I am afraid to use them now as not enough time passed for them to mature. It wouldn’t speed up me tremendously, so it’s not worth the risk.

Here is my .mcp file that you need to put in the root of the project:

{
  "mcpServers": {
    "Figma Dev Mode MCP": {
      "type": "sse",
      "url": "http://127.0.0.1:3845/sse"
    },
    "linear": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.linear.app/sse"]
    },
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    },
    "serena": {
      "command": "/opt/homebrew/bin/uvx",
      "args": [
        "--from",
        "git+https://github.com/oraios/serena",
        "serena-mcp-server"
      ]
    }
  }
}

So now your junior partner has a bunch of tools at their disposal, it’s their first time at work so they will ask for your approval literally for everything, e.g running a linter.

You don’t want to be sitting in front of your laptop entire day and approving simple commands, so let’s provide them a list of allowed tools by default, to achieve that you need to open .claude/settings.local.json file within your project and update “allow“ property:

{
  "permissions": {
    "allow": [
      "Bash(fd:*)",
      "Bash(ls:*)",
      "Bash(rg:*)",
      "Bash(npm run legacy:test:*)",
      "Bash(npm run check-types:*)",
      "Bash(npm run:*)",
      "mcp__linear__get_issue",
      ...
}

I recommend to add all commands that you have in your scripts section of package.json file. You will have an option to update this list when Claude will ask you for permissions, so don’t stress out that you don’t fill in this list fully on a first attempt.

Even with a long list of approved tools, you will still need to provide input to Claude from time to time. To avoid missing it due to multi-tasking I advise installing terminal-notifier package:

brew install terminal-notifier

and add such prompt to CLAUDE.md

On macOS, show toast notification and play sound using:
```bash
terminal-notifier -title "Claude Code" -message "MESSAGE" -sound default
```

Use notifications when:
- Requesting user permissions or approval for tool use
- Completing a major task or set of tasks
- Encountering errors that require user attention
- Finishing execution of long-running commands

Tips and Tricks

100% brain capacity

If you have the max tier (x20 Max) force your junior partner to use its brain at 100% via switching the model to Opus4, you can achieve it via `/model` command.

Even though you got a better brain, it’s not enough you also need to tell Claude to use it fully via using “think harder“ or “think longer“ in your prompts, it forces Claude to use extended thinking. It’s not some prompt magic - just a feature of Claude Code.

Planning

The main trick is to spend most of your time on planning the execution. First of all, you need to use planning mode via clicking Shift+Tab twice, in this mode Claude won’t touch any of files:

Second, you need to provide all important documentation, you can refer to files by using`@`

Third, to speed up development you need to come up with a plan that can be split among several agents. I create a plan together with Claude, after that I ask it to create detailed tasks with clear dependencies between them, so it can be given to a dev team. After that I ask what would optimize size of people working on this feature in parallel and based on the answer, I ask it to implement the feature (don’t forget to quit planning mode) with n sub-agents in parallel. It’s crucial to mention that they have to work in parallel because Claude is lazy and would do it sequentially by default.

Low-hanging fruit

You will notice that Claude reads a lot of code and does many operations with files(Serena MCP helps but doesn’t solve it fully), so it’s worth to replace default command-line tools with more performant ones. So I recommend to install these 3

brew install fd rg sd

and add this prompt to CLAUDE.md

Always use modern Rust-based CLI tools:
- fd instead of find
- rg (ripgrep) instead of grep
- sd instead of sed

These tools are already installed on the system.

You will feel the difference only on big projects though.

Documentation

When feature is ready, I highly recommend to ask Claude to summarize the feature and create an md file in docs directory with several sections - product requirements, how the feature works end-to-end and what tradeoffs this solution has.

The context window of Claude is small, so it would be reset quite often. Having these docs helps to save time on parsing entire project when you need to do follow-up tickets. Btw, don't shy away from using Claude to create follow-up tickets in Linear, it does an amazing job with it.

Github

Claude Code knows how to work with `gh` tool out of the box, so you just need to install it on your system via:

brew install gh

I primarily use it for commit creation as I’m lazy to type proper commit messages (who isn’t?!) and to do an initial code review of PRs. You just need to use the /review command within Claude and specify PR id or simply explain what’s PR about, it will find it, review and provide comments for improvements. You can also specify a focus of the review via prompt, e.g., review as a Security engineer.

Welcome to the other side

After you use Claude Code for a while, you'll highly likely get a rough awakening. Like one of my senior engineers had this week:

Happy shipping!

Thanks for reading Leprik! Subscribe for free to receive new posts and support my work.

Subscribe now