I got tired of being the guy who knows where things are.

Every week, Robin, my co-founder at Moqa Studio pings me: "Where's the API spec?". It’s in Notion. “Did the client reply about the deadline?” Check Gmail. “What’s the status on that bug?” Linear. “Did you mention something about the auth flow?” Probably Slack, maybe two weeks ago.

I was the human search engine across five tools. And I hated it.

So I did what any developer would do, I over-engineered a solution. I built a Python MCP server that connects Claude directly to our entire knowledge base: Notion, Linear, GitHub, Slack, and Gmail. One interface. Ask a question, get an answer from wherever the information lives.

It took a weekend to get it running. It took three more weeks to make it actually work. Because the prototype was terrible, and I didn’t realize it until we started using it.

Here’s every mistake I made.

1: We wrapped every API endpoint as a tool

Our first instinct, expose every useful endpoint as its own MCP tool. Small, composable, RESTful. We’d been building APIs for years, this felt natural.

# ❌ Our first attempt — 23 tools
@server.tool()
async def notion_search_pages(query: str) -> str:
    """Search Notion pages."""
    ...

@server.tool()
async def notion_get_page(page_id: str) -> str:
    """Get a Notion page by ID."""
    ...

@server.tool()
async def linear_list_issues(team_id: str) -> str:
    """List Linear issues for a team."""
    ...

@server.tool()
async def slack_search_messages(query: str) -> str:
    """Search Slack messages."""
    ...

# ... 19 more tools like this

We had 23 tools. It was a disaster.

When a user asked “What’s the latest on this project?”, Claude had to read all 23 tool descriptions (~10,000 tokens just for the catalog), pick which to call, orchestrate multiple round-trips, and keep all intermediate results in memory.

What actually happened? Claude picked 2-3 tools, ignored the rest, and hallucinated the gaps. Every conversation was inconsistent.

The Fix

We collapsed 23 tools into 7 outcome-oriented ones.

# ✅ After: one tool replaces five API calls
@server.tool()
async def get_project_status(project_name: str) -> str:
    """Get a complete status overview of a project.
    Use when the user asks about progress, status, or updates.
    Returns: open tickets, recent commits, latest docs, 
    and recent discussions — all in one call.
    """
    return {
        "linear": await _get_project_tickets(project_name),
        "github": await _get_recent_commits(project_name),
        "notion": await _get_project_docs(project_name),
        "slack": await _get_recent_discussions(project_name),
    }

The orchestration happens in our code, not in the LLM’s context window. One call instead of five.

Rule: if the agent needs to chain 3+ tools to answer a common question, you need a higher-level tool.

2: Our Tool descriptions were written for engineers

We wrote descriptions the way we’d write code comments:

@server.tool()
async def search_knowledge_base(query: str) -> str:
    """Search the knowledge base."""
    ...

Claude kept ignoring this tool. A user asked “Find the API documentation for the payment module” and Claude answered from memory instead of searching. Confidently wrong.

The Fix

@server.tool()
async def search_knowledge_base(
    query: str,
    sources: list[str] = ["notion", "linear", "github", "slack", "gmail"],
    limit: int = 10
) -> str:
    """Search across the company knowledge base for any information 
    about projects, clients, technical decisions, or internal discussions.
    
    Use this as your FIRST tool when the user asks about any topic. 
    Searches Notion docs, Linear tickets, GitHub repos, 
    Slack conversations, and email threads simultaneously.
    
    Returns a ranked list with: source, title, snippet, date, 
    relevance score, and doc_id for fetching full content.
    
    Examples of when to use this:
    - "What did we decide about the authentication approach?"
    - "Find everything related to the latest project"
    - "Any emails from the client about the deadline?"
    """
    ...

Three things: when to use it (”FIRST tool when...”), domain-specific terms (projects, clients, Notion, Linear), what comes back (exact return shape).

Tool selection accuracy went from ~60% to ~95%.

Treat tool descriptions like product copy. You’re selling the tool to an LLM.

3: Raw API responses murdered the context window

Our tools returned whatever the API gave us. A Notion page? Full JSON with blocks, properties, metadata, permissions, audit history. A single page was returning 8,000+ tokens.

# ❌ Returning raw API response
@server.tool()
async def get_document(source: str, doc_id: str) -> str:
    if source == "notion":
        page = await notion.pages.retrieve(doc_id)
        blocks = await notion.blocks.children.list(doc_id)
        return json.dumps({"page": page, "blocks": blocks})  # 8,000+ tokens 💀

Three pages = 24,000 tokens of raw JSON. Claude would read the first document and hallucinate the rest. Research confirms this: when the context window saturates, the model doesn’t gracefully degrade, it selectively forgets earlier tokens.

The Fix

Extract only what Claude needs:

# ✅ Curated, token-efficient responses
@server.tool()
async def get_document(source: str, doc_id: str) -> str:
    if source == "notion":
        page = await notion.pages.retrieve(doc_id)
        blocks = await notion.blocks.children.list(doc_id)
        return json.dumps({
            "title": _extract_title(page),
            "last_edited": page["last_edited_time"],
            "content": _blocks_to_text(blocks),  # Plain text, no JSON nesting
            "tags": _extract_tags(page),
        })  # ~800 tokens ✅

Same for Linear — full API response was ~3,000 tokens. After curation: ~300 tokens. 90% reduction. Claude could now handle 10+ documents in a single conversation.

Never return raw API payloads. Curate the output like you’re designing a dashboard.

4: The agent made random tool calls without workflow instructions

Even with good tools and descriptions, Claude’s behavior was a coin flip. Sometimes it searched first, then fetched details. Other times it skipped search entirely and guessed a doc_id. No predictable pattern.

We assumed Claude would figure out the right workflow. It didn’t. LLMs don’t have a mental model of your system.

The Fix

Explicit workflow instructions, embedded directly in descriptions:

@server.tool()
async def get_document(source: str, doc_id: str) -> str:
    """Fetch the full content of a specific document, ticket, or thread.
    
    Use AFTER search_knowledge_base when you need complete content 
    of a specific result. The doc_id comes from search results.
    
    Do NOT call this tool without first searching — you need a valid doc_id.
    """

That last line, "Do NOT call this tool without first searching", reduced hallucinated doc_id calls by ~80%.

We also added a system-level workflow:

SYSTEM_INSTRUCTIONS = """
WORKFLOW for answering questions about the company:
1. ALWAYS start with search_knowledge_base
2. Use get_document to fetch full content of top 2-3 results
3. For project overviews, use get_project_status instead
4. NEVER guess or use training data for company-specific questions
"""

5: We almost shipped without auth on a multi-Client server

This one still makes me uncomfortable.

Our first deployment ran on a shared server. One MCP instance, connected to all our tools, accessible by anyone on the team. Anyone asking about a project could theoretically pull up confidential client emails or private Slack channels from any workspace.

We didn’t think about it because during development, everything was local. stdio transport, our own laptops, our own credentials. Worked perfectly.

The Fix

Three changes:

1. Per-user credentials. Each user connects with their own OAuth tokens. No shared service accounts.

2. Scoped access. Tools only return data from workspaces the user already has access to.

3. Read-only by default. No write operations. No creating tickets, no sending emails. If we add writes later, every one requires explicit user confirmation.

The moment you move from local to remote deployment, you need auth, scoping, and audit logging. Day one.

The Checklist

If I were starting over:

• Map the 5-7 most common questions your team asks across tools, design tools around those

• Start with 5 tools max. Add more only when you see a clear gap

• Write descriptions first (400+ chars, domain-specific), implement handlers second

• Return curated responses, never raw API payloads

• Embed workflow instructions in descriptions

• Per-user auth from day one, read-only by default

• Test by asking real questions, not by checking if API calls succeed

Our 7 tools now cover ~90% of the questions the team was asking. The remaining 10% can wait.

Final Thought

Building an MCP server isn’t an infrastructure project. It’s a product design project for a non-human user.

The protocol works fine. Your server probably doesn’t. Ours didn’t either, until we stopped thinking like API engineers and started thinking like designers building for a user that reads every word you write, but doesn’t understand any of it the way you do.

We've since deployed variations of this setup for client projects at Moqa Studio, same patterns, different tool stacks. The checklist holds up every time.

Whether you’re new to Claude Code or feel like you’ve been using it wrong, you’re in the right place.

Most developers approach it the same way:
→ “Build feature X”
→ Get messy output
→ Conclude the tool isn’t ready.
I was one of them until I fundamentally changed my approach.

Here’s the thing about being a developer: you’re constantly learning. New frameworks, new patterns, new tools. Most bring incremental improvements. But every once in a while, something fundamentally reshapes how you work.

Claude Code was that for me.

In this guide, I’ll walk you through the workflow that transformed my development process: setting up persistent context, mastering Plan Mode, and configuring specialized subagents.

This isn’t an exhaustive exploration of everything Claude Code can do. It’s a practical guide focused on what actually works well for me day to day.

Let’s dive in. 🤿

What is Claude Code, really?

Here’s the crucial mindset shift: visualize Claude Code as a developer tool, not a magic box that does everything for you.

It can be incredibly effective when used well. It can also mess up codebases when used poorly. The difference lies entirely in your approach.

Core principles for success

Three elements make the difference between frustration and flow:

1. The claude.md file for persistent project context

2. Plan Mode for thinking before building

3. Specialized subagents for delegating to the right expert

Get these right, and Claude Code becomes a genuinely powerful part of your toolkit. Let’s break them down.

1. A good claude.md file

First thing: set up a claude.md file in your project root. Think of this as a persistent guide that Claude references on almost every prompt.

What belongs in there?

The more context here, the less you repeat yourself. Update it as your project evolves.

2. Plan Mode: think before you build

With your claude.md in place, you’re ready for the next piece of the puzzle: how you actually build features.

This is the cornerstone of using Claude Code properly.

It’s tempting to ask Claude to “implement feature X” directly. Don’t.

For complex features, this rarely works well. The code might function, but it lacks coherence with your existing architecture.

Why? When you jump straight to implementation, Claude makes assumptions about your architecture, naming conventions, and patterns. These assumptions compound. You end up with code that technically works but feels foreign to your codebase.

The fix: Plan Mode.

Toggle it by pressing Shift + Tab twice. Describe the feature you want in detail. Claude will analyze your codebase and draft a structured plan.

Here’s the key: read that plan carefully. Iterate on it. Ask Claude to break it down into ordered implementation tasks. This step is where you save hours of refactoring later.

3. Specialized subagents

Once you have a solid plan, here’s where things get really powerful: specialized subagents.

These handle different parts of your codebase. Each subagent operates in its own context window, keeping your main conversation clean and focused.

Think of them as specialized team members. You wouldn’t ask your backend developer to handle your design system. Same logic here.

Common configurations:

How to set up subagents Setting up subagents is straightforward. Run /agents in Claude Code to open the management interface. From there you can create new agents at project level (stored in .claude/agents/) or user level (stored in ~/.claude/agents/).

Each subagent is a Markdown file with YAML frontmatter:

---
name: frontend dev
description: Frontend specialist. Use for React components, styling, and state management.
tools: Read, Edit, Bash, Grep, Glob
model: sonnet
---

You are a frontend expert specializing in React and TypeScript.

When invoked:
1. Review the component requirements
2. Check existing patterns in the codebase
3. Implement following established conventions
4. Ensure proper typing and error handling

Focus on clean, maintainable component architecture.

Pro tip: Let Claude generate the initial subagent for you, then customize it. Run /agents, select “Create New Agent,” and describe what you need. Claude will draft the configuration. You refine from there.

The description field matters. Make it specific and action oriented. Include phrases like “Use proactively” if you want Claude to invoke it automatically when relevant.

The full development workflow

Now that you understand the three core elements, let’s see how they work together. This is the workflow I follow for every feature I build:

┌─────────────────────────────────────────────────────────────────┐
│                     CLAUDE CODE WORKFLOW                        │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│  1. SETUP                                                       │
│     claude.md + subagents + MCP (Linear/Jira)                   │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│  2. PLAN MODE (Shift+Tab x2)                                    │
│     Describe feature → Claude analyzes codebase → Draft plan    │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
                    ┌─────────────────┐
                    │  Plan looks     │
                    │  good?          │◄──────────────┐
                    └─────────────────┘               │
                      │           │                   │
                     Yes          No                  │
                      │           │                   │
                      │           ▼                   │
                      │   ┌───────────────┐           │
                      │   │ Iterate &     │───────────┘
                      │   │ refine plan   │
                      │   └───────────────┘
                      ▼
┌─────────────────────────────────────────────────────────────────┐
│  3. IMPLEMENTATION                                              │
│     Dispatch to specialized subagents                           │
│     (frontend / backend / testing / docs)                       │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│  4. REVIEW                                                      │
│     Ask Claude to check for unnecessary complexity              │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│  5. PR                                                          │
│     Claude opens PR with clear description                      │
└─────────────────────────────────────────────────────────────────┘

That’s the bird’s eye view. Let’s zoom in on how to actually implement this, starting from scratch.

Setting up a new project: the checklist

Starting from scratch? Here’s how to get everything wired up from day one.

Complete these steps:

1. Set up your claude.md with project context and coding standards

2. Configure specialized agents for your stack (frontend, backend, GitHub, documentation, architecture)

3. Connect your ticketing platform via MCP (Linear, Jira, or markdown todos)

The MCP integration is worth the setup. With Linear, Claude can read ticket descriptions, update statuses, and create subtasks. Planning and execution in one loop. It will then open the PR and link it to your Linear issue. Pretty convenient. (I’ll get into more details about that in a coming post)

The feature development pattern

With your project configured, here’s the step by step pattern I follow for every new feature:

Taking the time to plan and brainstorm the perfect plan for your feature is what makes the code output good. Don’t skip this part !

Common mistakes to avoid

Before you run off to implement all of this, let me save you some pain. These are the traps I fell into early on:

Personal perspective

Having used Claude Code extensively over the past months, I’ve watched my own productivity transform. So did my workflow. I write less code now, and spend more time reviewing PRs and talking to an AI in my console.

The impact is real. I ship faster and spend less time debugging.

Claude Code became truly useful when I stopped asking it to “build feature X” and started treating it like a junior developer on my team. One that needs clear context, a solid plan, and specific responsibilities. That framing changed everything.

At this point, it would be difficult for me to go back to my regular coding experience. I would feel much less effective without this tool in my toolkit.

Overall, I’m a big fan of Claude Code and I really enjoy this new approach to coding. It allows me to focus more on features and architecture, while only diving into the code when the topic is genuinely interesting.

Coming up next

This guide covers the fundamentals, but there’s more to explore. In upcoming posts we will get into

• Linear workflow integration for automated project development

• Deep dive into the most useful MCP tools and subagents

• Claude code for marketing

See you in the next one,

Robin

What’s your experience with AI assisted coding? Drop your thoughts below. 👇

Useful resources

The Claude Code documentation is awesome
Wshobson set of claude code agents & plugins

Model Context Protocol (MCP) was supposed to fix this, it’s like USB-C for AI. But here’s what nobody’s saying, you don’t need to write a single line of Python to use it. n8n turns MCP development from a multi-day coding marathon into a drag-and-drop afternoon.

Why n8n works so well for MCP development

I’ll be honest, if you’re hand-coding MCP servers, you’re either unaware of better options or you enjoy pain.

Visual tool management

MCP server development requires defining tools, handling authentication, and managing server lifecycle, all through code. n8n flips this on its head by providing a visual interface where each workflow step becomes a potential MCP tool. You’re essentially building with building blocks instead of writing boilerplate.

Bidirectional MCP integration

What makes n8n unique in the MCP ecosystem is its bidirectional approach. You can turn n8n workflows into MCP servers that AI agents can call, and simultaneously use n8n as an MCP client to consume external tools. This dual capability means you can create sophisticated automation pipelines that bridge multiple MCP services without custom integration code.

Enterprise-ready infrastructure

n8n handles the operational concerns that often trip up custom MCP implementations: authentication, error handling, logging, and scalability. When you deploy an n8n MCP server, you’re getting production-ready infrastructure that can handle real workloads, not just proof-of-concept demos.

Building a developer assistant in 20 minutes

Let me show you something practical. We’re building a developer assistant that combines GitHub with custom code analysis tools. Two MCP servers. Zero Python files.

Architecture overview

Our developer assistant uses 2 MCP servers:

GitHub MCP server (external service integration)

• get/comment on issues

• list repository issues

• read file contents

• full GitHub API access

Custom dev tools MCP server (internal tools)

• code quality analyzer

• documentation generator

• StackOverflow search

• PR change summarizer

The AI agent discovers and orchestrates these tools automatically. No manual coordination required.

Prerequisites setup

You’ll need:

• n8n instance (self-hosted or n8n Cloud)

• community packages enabled: N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE=true

• MCP community nodes installed: n8n-nodes-mcp

• GitHub personal access token

• OpenAI API key

Implementing the GitHub MCP server

Step 1: create the MCP server trigger

Start by creating a new workflow and adding the MCP server trigger node. This transforms your workflow into an MCP server endpoint.

Node: MCP Server Trigger
Path: github-tools

The trigger generates a unique URL like /mcp/github-tools/sse that MCP clients can connect to.

Step 2: add GitHub tool nodes

Connect GitHub nodes to your MCP trigger. Each becomes a discoverable tool:

Get issue node:

Resource: Issue
Operation: Get
Parameters: $fromAI(’issue_number’, ‘GitHub issue number’, ‘number’)

Comment on issue node:

Resource: Issue  
Operation: Create Comment
Issue Number: $fromAI(’issue_number’, ...)
Body: $fromAI(’comment_body’, ‘Comment text’, ‘string’)

List issues node:

Resource: Repository
Operation: Get Issues
Limit: 10

Get file node:

Resource: File
Operation: Get
File Path: $fromAI(’file_path’, ‘File path in repository’, ‘string’)

Step 3: configure authentication

Add your GitHub personal access token to each GitHub node. The MCP server will handle this securely when tools are invoked.

Building the custom dev tools MCP server

This is where MCP’s value really shines: creating specialized internal tools.

1. MCP Server Trigger (path: dev-tools)

2. Execute Workflow Trigger (receives function calls)

3. Switch Node (routes to appropriate tool)

4. Tool Workflow Nodes (expose tools to MCP)

Tool 1: Code quality analyzer

What developers on Reddit actually want: something that catches console.logs, old var declarations, and nested if-hell before code review.

How it works in n8n:

• Add a Code node

• Check for common issues (debug statements, old syntax, missing comments)

• Return a JSON score and suggestions

Skip the fancy static analysis. The 80/20 rule applies, catching obvious issues catches 80% of problems. Your custom tool can focus on your team’s specific code smells.

Tool 2: StackOverflow search

Use an HTTP request node hitting StackOverflow’s API. Format the results. Done.

Always use {dynamicTyping: true, skipEmptyLines: true} when parsing external API responses. Trust me on this one.

Tool 3: PR summariser

Takes GitHub PR data and returns a human readable summary. Perfect for daily standups.

Keep summaries short. A good summary is 1-2 sentences max. The AI can always fetch more details if needed.

Connecting your AI agent

Now comes the fun part: letting your AI agent discover and use these tools automatically.

1. Add MCP Client nodes pointing to your server endpoints

2. Configure your AI agent (OpenAI GPT-4, Claude, whatever)

3. Add a Chat Trigger for the web interface

System prompt that actually works:

You are a developer assistant. You help with code reviews, 
documentation, and development workflows. You have access 
to GitHub and custom dev tools. Use them proactively.

Don’t over-engineer your system prompts. Be clear, be direct, be brief.

2 real examples

1. Analyze this code quality

function test() {
  var x = 1;
  console.log(x);
  if (x) {
    if (x > 0) {
      if (x < 10) {
        return x;
      }
    }
  }
}

Agent response:

"Score: 70/100. Issues: debug statements, old var declarations, deep nesting. Suggestions: Remove console.log, use const/let, reduce nesting depth."

The AI automatically chose the right tool, executed it, and formatted the response.

2. “Search StackOverflow for async/await best practices, then generate documentation for my async function”

Agent response:

“Found 5 relevant posts. Based on those, here’s your documentation...”

This required ZERO configuration beyond defining the tools. The AI agent figured out it needed two tools and orchestrated them automatically.

Share

My tips

After digging through Reddit threads, n8n forums, and GitHub issues, here’s what experienced users actually do:

Start small, then scale

Maybe automate something simple, like notifying your team when a new client signs up. As you get comfortable, you can build more complex workflows.

Why this matters: Complex workflows are just simple workflows connected together. Master the basics first.

Use Sub-workflows for complex agents

From n8n forums: for complex AI agents with many tools, use the Call Workflow node. Each tool becomes a separate workflow.

Benefits:

• Easier to debug (test tools individually)

• Better organization (not one giant workflow)

• No performance penalty on n8n Cloud

Simple agents with 2-3 tools? Just use built-in nodes. Don’t over-engineer.

Naming conventions save lives

The biggest complaint on Reddit is messy workflows that nobody can understand 3 months later.

What works:

• Name every node descriptively

• Use consistent patterns (Get-[Thing], Check-[Condition], Send-[Action])

• Add notes for complex logic

• Document weird workarounds immediately

Error handling

Production workflows WILL fail. APIs timeout. Services go down. Users send garbage data.

Essential practices:

• Add Error Trigger nodes to catch failures

• Set up retry logic (3 attempts with exponential backoff)

• Send alerts to Slack/email when things break

• Log everything—you’ll need it for debugging

n8n’s error handling saved us hundreds of hours monthly. We get alerted immediately when something breaks, with full context.

Security

Do these things:

• Store API keys in n8n’s credential manager (NEVER in code)

• Use bearer token authentication for production MCP endpoints

• Run behind a reverse proxy (nginx/Caddy)

• Enable rate limiting

• Set up environment variables properly

Most security breaches happen because someone hardcoded credentials “just for testing.” Don’t be that person.

Subscribe now

Common issues

MCP client can’t connect

Check these:

1. Is the workflow activated?

2. Does the MCP path match your client config exactly?

3. Are SSE connections allowed through your firewall?

4. Is your SSL certificate valid?

When in doubt, check the execution logs. They’re there for a reason.

Tools aren’t appearing in my AI agent

Fix these:

1. Clear, descriptive tool descriptions (the AI uses these!)

2. Proper $fromAI() parameter definitions

3. Restart your AI agent after adding tools

4. Check that tool nodes are actually connected to the MCP trigger

90% of missing tools issues are unclear descriptions. The AI needs to understand when to use each tool.

Everything is slow

Optimize:

• Use caching for frequently accessed data

• Set reasonable HTTP timeouts (don’t wait forever)

• Monitor your n8n instance resources

• Consider using async operations

If a tool takes >5 seconds, users will complain. If it takes >10 seconds, they’ll assume it’s broken.

Conclusion

You can keep hand-coding MCP servers if you want. Some problems need custom code. But for 80% of use cases? Visual development is faster, more maintainable, and easier to hand off. We now use a similar workflow at Moqa Studio.

Like and drop a comment below if you want the complete workflow JSON to get started. Way easier than building from scratch.
Also, if you found this useful, share it with a developer who’s still writing custom integrations by hand.

Picture this: You describe a feature.

AI agents explore your codebase, implement the solution, write tests, create PRs, and handle Git workflows.

You focus on architecture and strategy.
This isn’t future tech, this is Claude Code right now.

The dev role is evolving from code writer to code conductor.

And honestly? It’s the biggest shift since we moved from assembly to high-level languages.

Why this evolution matters

Traditional developer workflow is dead:

• ❌ Old: Write code → Debug → Test → Commit → PR

• ✅ New: Plan features → Review AI implementations → Guide architecture

⠀Future belongs to devs who can orchestrate AI agents, not just write syntax.

The game changing features 🎯

1. Multi-agent dream teams 🤖

Specialized subagents that collaborate like senior developers:

• Code Reviewer Agent: Security patterns, performance optimization

• Debugger Agent: Root cause analysis, systematic problem-solving

• Data Science Agent: ML implementations, analytics architecture

• DevOps Agent: Deployment, infrastructure, CI/CD

⠀

Real workflow:

“Implement user analytics with privacy compliance”

→ Data Science Agent designs architecture
→ Code Reviewer validates privacy patterns
→ Main Agent implements solution
→ DevOps Agent handles monitoring
→ All collaborate on testing

This is intelligent collaboration, not just parallel processing.

2. Autonomous git mastery 📊

Git becomes conversational and smart:

• Contextual commits based on business impact

• Intelligent branch management with proper naming

• Smart conflict resolution understanding code context

• PR creation with impact analysis and testing notes

Example:

“Refactor payment processing edge cases”

 → Creates branch: fix/payment-edge-cases-handling
 → Implements comprehensive solution
 → Generates: “feat(payments): Add retry logic and timeout handling
    - Implements exponential backoff for failed transactions
    - Adds comprehensive error logging
    - Includes unit tests for timeout scenarios”
 → Creates PR with security analysis

3. Universal tool integration (MCP) 🔗

Claude Code becomes your development orchestrator:

• JIRA: “Implement JIRA 1234” → Complete implementation + ticket updates

• Database: Direct queries with context awareness

• Monitoring: Analyze Sentry errors → Implement fixes

• Design: Figma → Pixel perfect implementations

Each integration multiplies capabilities exponentially.

4. Human like codebase exploration 🕵️

Explores codebases like a senior dev, not through embeddings:

• Uses glob, grep, find organically

• Traces execution flow across services

• Maps dependencies and business logic

• Understands architectural patterns

Instead of explaining your codebase, Claude investigates and adapts.

5. Production ready safety hooks 🎣

Intelligent guardrails for enterprise use:

• Pre-modification: Security scans, permission checks

• Post-change: Auto-format, tests, documentation updates

• Custom workflows: Slack notifications, deployment triggers

# Critical file protection
if [[ “$file” == *”production-config”* ]]; then
    exit 1  # ❌ Protected
fi
# Auto-validation pipeline
prettier → tests → staging → team notification

What this really means

The New Developer Skillset:

• Architectural thinking over syntax memorization

• AI orchestration across multiple specialized agents

• Strategic code review for business logic validation

• Problem decomposition into AI-actionable tasks

⠀Industry Reality Check:

• Development velocity increases 10x, not 2x

• Code quality becomes consistent across teams

• Complex software barriers drop dramatically

• Senior devs become solution architects + AI conductors

Jump in the boat now

Claude Code isn’t another tool, it’s the foundation of post-traditional development. The devs who win won’t write the most code. They’ll orchestrate AI agents to build better software faster.

The developer job isn’t disappearing. It’s evolving into something more strategic, creative, and infinitely more powerful.

Ready to conduct the orchestra? Check out Claude Code at

https://docs.claude.com

Want me to deep dive into any specific feature? Multi-agent workflows? Git automation? MCP integrations? Hit me up. I’m obsessed with how this tech is reshaping development.

My problem on this one was super simple: I wanted to be able to work on some projects or quick things quickly while on the go.

I use Claude code a lot, and really wanted to be able to use it while on the go, from my phone.

This is what this setup is all about, and more.

Context

In this article, we will explore a workflow that setup in order to be able to:

• Ask Claude Code to edit stuff on my projects & validate changes by opening PRs

• Have a Telegram bot notify me when a PR is opened

• Review & merge that PR on github mobile

Here is a quick demo video of the full flow

What We're Building

• Claude Code project manipulation from mobile devices

• Automated PR creation for each AI-generated change

• Telegram notification system for instant PR awareness

• Mobile-optimized code review and merge workflows

Let’s set this up

Step 1 : Spin up a VPS

Create a small VPS (Virtual Private Server) with the provider of your choice.

I used Hetzner because their prices were extremely good (4.99$ /month), but you can use whatever VPS provider you like the most (DigitalOcean, …)

I also went for ubuntu as my operating system on my vps.

Step 2 : Setup your VPS

ssh into your VPS and install some must have

ssh root@your-vps-ip

# Essential updates

apt update && apt upgrade -y

apt install git curl nodejs npm tmux nginx -y

# Verify Node 18+

node -v

Step 3 : Git auth

Generate SSH key on VPS:

ssh-keygen -t ed25519 -C "your_email@example.com"

eval "$(ssh-agent -s)"

ssh-add ~/.ssh/id_ed25519

# Copy this to GitHub SSH keys

cat ~/.ssh/id_ed25519.pub

From there you can clone the repo of your choice to start to work on it

git clone git@github.com:username/repo.git

cd repo

Step 4 : Install Claude Code

# Global install (no sudo)

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

# Authenticate

claude login

# Follow OAuth flow

# Test installation

claude doctor

From here, you can already ssh from your phone and have Claude Code work on your projects, which is awesome.

(Optional) Step 5 : Create Claude Code subagents

I like working with Claude Code subagents

I highly recommend creating a small PR creator subagent to create and write PRs on your project.

Here is an example:

# PR Expert Agent

You are a PR expert. Your job is to:

- Create detailed pull requests with clear descriptions

- Follow conventional commit standards

- Include testing instructions

- Add relevant labels and reviewers

When creating PRs:

1. Write descriptive titles

2. Include "What changed" and "Why"

3. Add testing steps

4. Tag breaking changes

Step 6 : n8n + Telegram bot

I created a short n8n flow in order to have a Telegram bot notify me whenever I have a new PR on one of my projects.

Here is what it looks like

There is:

• A github trigger node on PR creation (you have to setup one for each of your projects)

• A switch that is going to look at the action (PR opened / closed)

• Two Telegram message nodes that will send a message depending the context

  • PR opened with the link and some details

  • PR merged

In order to set the Telegram nodes, you will need to create a Telegram bot using father-bot (super simple)

Step 7 : Enjoy your flow

From there, cliking on the PR link will open Github mobile on your phone.

You can review the code and merge the PR accordingly !

Conclusion

I’m a big fan of this flow and use it daily at the moment.

Will probably keep upgrading it in the coming weeks !

With MCP rapidly gaining traction in the AI community, I wanted to understand what makes this new protocol suddenly so important.

Let's explore why Model Context Protocol is becoming the standard way for AI to connect to external tools and data.

MCP explained: What exactly is it?

When you build AI applications, you typically need to connect to:

🔹 Databases for retrieving information 🔹 APIs for external services 🔹 File systems for document access 🔹 Other tools your users need

Before MCP, each of these connections required:

• Custom integration code

• Different authentication methods

• Separate maintenance for each service

• Significant development overhead

Model Context Protocol creates a standardized way for AI to interact with ALL of these systems through one consistent interface.

Think of it like the USB standard for AI - one protocol to connect everything.

Why MCP matters: The integration problem it solves

Most people don't realize how much time AI developers spend on integrations rather than actual AI capabilities.

The current reality without MCP:

1. An AI agent that needs to check your calendar, then email a colleague, then update a database requires THREE separate custom integrations

2. Each integration has its own:

   • Authentication system

   • Data formatting requirements

   • Error handling approach

   • Maintenance burden

3. Adding a new tool means writing entirely new code

This is why most AI applications stay limited to a handful of services - integration complexity creates a barrier.

MCP breaks through this barrier with one standard protocol for everything.

Technical breakdown: How MCP actually works

MCP uses a client-server architecture with JSON-RPC messages:

• MCP Clients: AI models or applications that want to use external tools

• MCP Servers: Services that provide capabilities to the AI

The protocol exposes three key components:

1. Tools: Functions the AI can call (like "sendEmail" or "searchDatabase")

2. Resources: Data the AI can access (like files or database records)

3. Prompts: Templates the AI can use for specific tasks

The magic happens through dynamic discovery - AI models can automatically detect what capabilities are available without being explicitly programmed for each one.

MCP advantages: Why developers are adopting it

The benefits of MCP extend beyond just standardization:

✅ Universal compatibility: Works with any AI model (Claude, GPT, open-source LLMs)

✅ Bidirectional communication: Both retrieving data AND taking actions

✅ Reduced development time: Connect new services in minutes, not days

✅ Future-proof: Add new tools without changing your core application

✅ Context sharing: Maintain conversation state across different tools

As one developer put it: "MCP took our integration time from weeks to hours."

Current limitations: What to be aware of

MCP isn't perfect yet. Current challenges include:

⚠️ Deployment complexity: Primarily local servers for now, though cloud options are coming

⚠️ Security considerations: Authentication and permissions systems are still maturing

⚠️ Performance overhead: Multiple connections can introduce latency

⚠️ Tool quality variance: Effectiveness depends on how well tool interfaces are described

For simple projects with minimal integration needs, MCP might be overkill. But for complex AI applications connecting to multiple systems, the benefits far outweigh these limitations.

Available MCP servers: What you can use today

The ecosystem is growing rapidly. As of March 2025, over 1,000 MCP servers are available for services including:

• Slack and Discord

• Google Workspace (Gmail, Drive, Calendar)

• Database connectors (PostgreSQL, MongoDB)

• Notion, Figma, and other productivity tools

• CRM systems like Salesforce

• Search engines and knowledge bases

• Custom enterprise tools

This collection of pre-built servers means you can often find what you need without building from scratch.

The roadmap: What's coming next for MCP

According to the official MCP roadmap, several key improvements are in development:

1. Remote servers with OAuth: Simplifying cloud deployments

2. Registry system: Central discovery for available MCP servers

3. Stateless connections: Improved scalability

4. Performance optimizations: Reducing latency overhead

5. Enhanced security: Better authentication and permissions

These improvements address most of the current limitations, positioning MCP to become even more widely adopted.

Real-world example: MCP in action

To illustrate MCP's power, consider this financial advisor AI application:

Without MCP: The developer would need to write custom integrations for banking APIs, investment platforms, spreadsheet access, and email services - each with different authentication, data formats, and maintenance requirements.

With MCP: The developer connects pre-built MCP servers for each service, and the AI can:

• Check account balances

• Analyze investment performance

• Update budget spreadsheets

• Send summary reports via email

All through a single, consistent interface - dramatically reducing development time and complexity.

Comparison with alternatives: Where MCP fits

How does MCP compare to other approaches?

Custom API integrations:

• Much more development work

• Less flexibility and scalability

• Higher maintenance burden

OpenAI plugins:

• Limited to OpenAI's ecosystem

• Less standardized

• Primarily one-way information retrieval

LangChain tools:

• Developer-focused rather than AI-focused

• Requires more code for each integration

• Less dynamic discovery

MCP provides a more standardized, flexible, and AI-native approach to tool integration.

Conclusion: The future of AI connectivity

MCP solves a real pain point for AI developers - the integration mess. While it's still early days, MCP has the potential to become the standard way AI systems connect to external tools and data.

Just as USB standardized physical device connections and HTTP standardized web communications, MCP is standardizing how AI interfaces with the digital world.

As the protocol matures and adoption continues to accelerate, we'll likely see MCP become the foundation for more sophisticated AI applications that seamlessly interact with our digital tools and information.

The question isn't whether to use MCP, but when and how to integrate it into your AI development strategy.

What now?

• Explore the collection of available MCP servers

• Check the official MCP roadmap for upcoming features

• Consider which of your AI projects would benefit from standardized tool access

• Join the growing MCP community to share experiences and best practices

With Telegram's CEO arrested in France, I got curious: How secure is Telegram, really?

Let's unpack the tech behind those "private" chats.

Telegram's chat types: What you need to know

When you start a new chat on Telegram:

🟠 By default, you get:

• Regular private messages

• Group chats

• Channels

These are NOT end-to-end encrypted

🟢 You have to manually choose:

• "Secret Chats" for one-on-one convos

This is the ONLY option with end-to-end encryption

Most users never switch to Secret Chats. Let's see why this matters.

Telegram's two encryption methods :

1️⃣ Default encryption (what most people use):

• Uses MTProto, Telegram's custom protocol

• Messages are encrypted... but Telegram has the keys

• Telegram can read your messages if they want to

2️⃣ Secret Chats encryption:

• Uses improved MTProto 2.0

• True end-to-end encryption

• Only you and the recipient have the keys

• Telegram can't read these messages

The takeaway? Unless you're actively using Secret Chats, your Telegram messages aren't really private. So what's wrong with server encryption, it still is encryption right?

The problem with Telegram's default encryption:

• Messages are encrypted between you and Telegram's servers

• BUT Telegram holds the encryption keys

• This means:

  • Telegram can decrypt and read your messages anytime

  • Your privacy relies on trusting Telegram won't abuse this access

Compare this to true end-to-end encryption:

• Even the service provider can't read your messages

• Your chats are private, period.

Bottom line: With Telegram's default, you're trusting them with your privacy. With true E2E, you don't have to trust anyone.

Why Telegram's encryption approach matters:

1. Government requests:

   • Telegram could be forced to hand over your messages

   • With true E2E, this wouldn't be possible

2. Data breaches:

   • If hackers breach Telegram's servers, your chats could be exposed

   • E2E encryption would protect you even if servers were compromised

3. Trust issues:

   • You're betting Telegram won't misuse your data

   • But why take that risk when other apps offer real privacy?

The big question: Do you trust Telegram with your private conversations? Let's have a look at other messaging apps.

Comparison with other messaging apps:

Signal:

• Open-source protocol developed by cryptography expert Moxie Marlinspike

• Used by WhatsApp, Facebook Messenger (secret convos), and Google (encrypted RCS)

• E2E encryption by default for all chats

• Minimizes metadata collection

• Non-profit organization, focused on privacy

WhatsApp:

• Uses Signal Protocol for E2E encryption

• E2E encryption by default since 2016

• Owned by Meta, raising some trust concerns

iMessage:

• Apple's proprietary E2E encryption

• E2E encrypted by default since 2011

• Limited to Apple devices

Key point: These apps use E2E by default, unlike Telegram. But remember: even with E2E, apps may still collect metadata (who you talk to, when, etc.). This is also a privacy concern.

Conclusion: Telegram's security reality

Telegram's security isn't as straightforward as it seems:

• Default chats aren't truly private

• Only "Secret Chats" offer real E2E encryption

• Other major apps (Signal, WhatsApp, iMessage) use E2E by default

The arrest of Telegram's CEO highlights the complex balance between privacy and accountability.

About the CEO's arrest

Pavel Durov faces charges in France for:

• Failure to moderate illegal content

• Alleged hosting of:

  • Drug trafficking

  • Child sexual abuse material

  • Fraud on the platform

This case highlights the complex balance between user privacy and platform accountability. It also raises questions: How much access should governments have to our communications? Can strong encryption coexist with effective moderation?

What now?

• Check your Telegram settings. Are you using Secret Chats when needed?

• Consider alternatives like Signal for sensitive conversations

• Stay informed about the privacy policies of your messaging apps

What do you think? Is Telegram secure enough for you? Share this article to spread awareness! 🔁 Drop a comment with your thoughts 💭

Interesting sources:

• Detailed technical breakdown of Telegram's encryption by a cryptography expert

  • Is Telegram really an encrypted messaging app?

• In-depth look at Durov's arrest and Telegram's content moderation challenges

  • Telegram's CEO has taken a hands-off approach for years — now his luck might have run out

• Explores the legal implications of holding tech CEOs accountable for platform content

  • Can Tech Executives Be Held Responsible for What Happens on Their Platforms?