In this article I’ll talk about the evolution of my local agentic dev workflow, that changed quite a lot since last time we talked about it.

I’ve been using ghostty for several months now and for a few reasons, it clicked for me really quickly.

Ghostty

A few reasons I’m using ghostty:

• It’s blazing fast and smooth. It’s a native macos app with GPU acceleration baked in.

• It’s simple and pure on install. You can configure most of it (starting by what it looks like) but it comes with zero default config.

I’ve started using it as my main terminal (replacing iTerm2), and my workflow stayed quite simple:

• One project per tab

• Up to 4 panes per tab

I’m only using the simple keybinding to move between those panes. And voila. Simple, effective & enjoyable on a daily basis.

Where Herdr comes in

Quick context if you’ve never heard of it: Herdr is a terminal multiplexer, like tmux, but built for coding agents. It runs inside your existing terminal (Ghostty, Kitty, iTerm2, even inside tmux), ships as a single Rust binary, and gives you workspaces, tabs and tiled panes. The twist: it detects the agent running in each pane (Claude Code, Codex, OpenCode, and a growing list) and shows its state in a sidebar: working, idle, done, or blocked waiting on you. Sessions persist in a background server, so you can detach, reattach, or even SSH in from another machine and your agents are still running. It also exposes a local socket API and CLI, which means your agents can drive Herdr themselves. Keep that last bit in mind, it matters later.

I started experiencing with Herdr about two weeks ago and man, I fell in love with it. I’ve completely reworked my usual agentic coding workflow and it’s never been so enjoyable to manage several agents at once !

Why use Herdr in the first place you might ask ?

In my case, it answered to 4 main reasons (+ one extra that came later in):

1. Herdr improves my parallel agent coding flow

2. It survives ghostty crashes (happens sometimes for me when I switch between light & dark theme)

3. It’s controllable and customisable using ai agents

4. There is a plugin system (and it’s super easy to create yours)

(and a bonus point that landed more recently, it handle remote hosts too !)

What “parallel agent flow” actually looks like

Here’s a typical session for me now:

• One Herdr workspace per project, same rule as my Ghostty tabs before. Inside a workspace, one tab per task, and inside each tab: an agent pane, a pane for tests or a dev server.

• 5 to 6 workspaces running at once while I juggle through them

  

That said, I spent a couple of hours configuring herdr before starting to properly use it, and the following section explains why.

Setting up Herdr

In order to get started with Herdr, I asked an agent (using claude code in my case) to rebind a few keystrokes so that I could use it easily.

I first needed to be able to use both Ghostty and Herdr shortcuts together without having to use the ctrl+b mode of Herdr that I don’t like that much.

After this, I setup my herdr theme to match my ghostty themes dynamically, and from there I started to work with herdr.

Concretely, the Ghostty side looks like this:

# Herdr: forward ghostty-style shortcuts as Herdr prefix sequences
# (\x02 = Ctrl+B, Herdr's prefix key). These replace ghostty's native
# splits/tabs so Herdr owns the layout.
keybind = cmd+d=text:\x02v
keybind = cmd+shift+d=text:\x02-
keybind = cmd+t=text:\x02N
keybind = cmd+alt+t=text:\x02c
keybind = cmd+alt+left=text:\x02h
keybind = cmd+alt+right=text:\x02l
keybind = cmd+alt+up=text:\x02k
keybind = cmd+alt+down=text:\x02j

# Native ghostty escape hatches: same key plus shift
# (or ctrl where shift was already taken)
keybind = cmd+shift+t=new_tab
keybind = cmd+ctrl+d=new_split:right
keybind = cmd+ctrl+shift+d=new_split:down
keybind = cmd+shift+alt+left=goto_split:left
keybind = cmd+shift+alt+right=goto_split:right
keybind = cmd+shift+alt+up=goto_split:up
keybind = cmd+shift+alt+down=goto_split:down

# Jumping: cmd+N = Herdr workspace N, cmd+alt+N = Herdr tab N
# (esc+digit = alt+digit chord), alt+shift+N = ghostty tab N
# (cmd+shift+3/4/5 are macOS screenshot shortcuts, hence alt+shift)
keybind = cmd+digit_1=text:\x021
keybind = cmd+alt+digit_1=text:\x1b1
keybind = alt+shift+digit_1=goto_tab:1
# ...same three bindings repeat for digits 2–9

And on the Herdr side, almost nothing changes. The digits just get pointed at the right unit:

[keys]
# Workspaces are the per-project unit; give them the plain digits
switch_workspace = "prefix+1..9"
# Tabs move to direct alt+digit chords (esc+digit encoding)
switch_tab = "alt+1..9"

The trick: Herdr still thinks I’m a regular ctrl+b user, Ghostty just types the prefix for me. cmd+d sends ctrl+b v (split), cmd+t sends ctrl+b N (new workspace), cmd+1 sends ctrl+b 1 (workspace 1). No mode switching, and my memory from months of Ghostty stays the same.

The digit keys end up as a three-layer system, and it’s the part I use most:

• cmd+N → Herdr workspace N (one per project)

• cmd+alt+N → Herdr tab N (one per task)

• alt+shift+N → native Ghostty tab N

The last customisation step was setting up my Herdr theme to match my Ghostty theme dynamically, so switching light/dark in Ghostty switches Herdr too.

After a few days of usage, i stumbled myself wanting three things:

1. A menu bar integration to monitor my agents without having to be on my terminal

2. A remote connection to my mac from my phone / iPad to use herdr

3. A raycast/macos like command bar to do basic actions like renaming tabs and spaces

So I started digging to add those three things !

Spoiler: I solved #1 and #3. #2 is still a work in progress, more on that at the end.

Using swiftbar to add custom menu bar activities

SwiftBar allows you to create custom macos menu bar items, without having to compile anything. Install it once using homebrew and get started. In my case, I asked my coding agent to add two things:

1. A way to monitor all my Herdr agents

2. A way to turn on/off ssh connection to my mac + monitor who is connected, from where

The results is two dynamic menu bar items, indicating my agents status & ssh connection state.

I’ve committed the results in my public tips & tricks repo that I use on all the machines I use if you want to have a closer look https://github.com/Binb1/awesome-tips

Building a custom herdr plugin

First things first, you need to know that I’m a command palette pro user. I think that command palettes are great UX wise in most tools, and I felt like Herdr could definitely use one. So I decided to create my own small plugin !

What it does: hit a shortcut, get a searchable list of actions: rename the current tab, rename the workspace, jump to a workspace, split, close. The things I was previously doing with three different keybindings I could never remember.

You can install this plugin running > herdr plugin install Binb1/herdr-palette

The doc to create plugins is pretty stragithforward, publishing them is too. There are already a lot of cool plugins out there btw!

Wrap-up

This new dev workflow was both fun and fast to setup.

Just to be clear, is using Herdr a must ? Nope. Is it fun to use, and does it bring productivity boost ? Absolutely !

If you got a few spare hours to manggle with this, I can only recommend it !

I’m planning to explore the best options to leverage this setup remotely (from my phone mainly) in the coming weeks, still havn’t found the perfect setup for now.

If you’re interested in using my custom setup, I have a public repo where I store the useful things form my different projects right here https://github.com/Binb1/awesome-tips

Hoping that this can help you out, See you in the next one !

About me

I’m Robin, a builder with a software engineering background. I currently work as a Forward Deployed Engineer at @Moqa Studio, a studio I co-founded in 2023, where we ship practical AI agents and engines for tech companies.

On the side, I’ve been shipping iOS apps since 2014, and I write about tech on The Buildup.

Since January, 3,091 of the 3,567 commits on my current project are co-signed by Claude. That is 86%.

During summer 2025, I started to use Claude code, as a very good coding assistant,

→ A bug, Claude fixed it.
→ A component, Claude built it.
→ A refactor, Claude did it.

But the more I use it, the less I think that is the interesting part.

The interesting part is what happens when you stop asking Claude to write code and start asking it to do work.

→ Investigate this bug.
→ Understand this codebase.
→ Build this feature.
→ Run the tests.
→ Look at the screenshots.
→ Try another approach.
→ Review what you just did.
→ Open a PR.

That is a different mental model.

And with the latest Claude Code features, it is becoming obvious. Anthropic is pushing Claude Code toward longer, more autonomous work: subagents, agent teams, hooks, worktrees, persistent memory, goals.

So here are the things I care about when using Claude Code on a real product.

The ones that changed how I work, with the actual bugs and files they come from.

1. Give Claude a problem (better than a task)

The old way:

Fix the trip save function, some trips have no points.

The better way:

Some multi-day trips arrive in the database with a real distance and zero GPS points. Don’t change anything yet. Find every path where a recording can be saved without its track.

The first asks for code in a function I had already blamed. The second asks Claude to understand something.

It found three ways a save could lose its data. I would have fixed the first one and shipped.

The expensive thing is not Claude generating 500 lines of code. It is Claude generating 500 lines of the wrong code.

2. Let it explore before you tell it where the bug is

Long trips showed up cropped on the shared web page. I was sure it was the mobile recorder, again. Instead of “fix the recorder”:

Find out why traces longer than a few hours are cut on the share page.

Claude followed the chain from the page to the database and came back with: the recorder is fine, the API layer caps every response at 1,000 rows, including stored procedures. Then it checked something I would not have, that the usual paging header is ignored on those calls, so the fix had to be explicit paging. A second, unrelated page had the same bug.

Autocomplete helps me write what I already decided. Claude Code helps me decide what should be written.

3. Explore and plan before implementing

For anything that touches the boat, I do not skip the first two. For an anchor alarm (drop a virtual anchor, get woken up if the boat drifts):

Explore how background GPS tracking and notifications work in this app. Don’t modify anything.

Give me a plan for an anchor drag alarm on top of it. Phone locked, bad GPS, keep the existing architecture unless there’s a strong reason not to.

The plan is where the decisions surfaced: a default radius of four boat lengths, a breach that must persist twelve seconds, and a rule that a GPS gap can delay the alarm but never suppress it. I would have discovered that rule at three in the morning, from a false alarm.

Plan mode adds overhead. If you can describe the diff in one sentence, skip it.

4. Context

Claude Code sends the whole conversation on every turn, and quality drops as the window fills.

An hour on a database test, then a landing page to rewrite? /clear. New session.

Same for files. Point Claude at the two files that matter. The folder with 38 of them can stay closed.

Same for tools. Run /context once in a fresh session and look at what is loaded before you type. Every MCP server in there should have a job in this session.

When the problem is the same but the conversation got huge, /compact. What has to survive lives elsewhere: rules in CLAUDE.md, workflows in skills, learnings in memory.

Memory is the part that changed recently. Claude Code keeps a memory folder per project, and mine has about forty files. One says: if a database test passes locally and fails in CI, reset the local database first, because new migrations only get applied on a fresh start. Claude wrote that down after it cost us a round-trip to CI, and the lesson has held since.

After a long investigation, I ask for it explicitly:

Write down what we learned so the next session can continue without repeating this.

The conversation is temporary. The knowledge is permanent.

Share

5. CLAUDE.md

Mine answers one question: what would I explain to a new developer on their first day? The lines that earn their place are the ones Claude could only learn from me. “This is a B2C app, no team accounts” is there because the boilerplate is B2B and Claude kept building team features. “Regenerate the types after every migration” is there because it forgot.

If I have said it twice, it goes in. If it only matters for one workflow, it becomes a skill, because every line of the file rides along in every session, including the ones where it is dead weight.

The file gets better through corrections. Claude once proposed a new enum value to fix a calculation. I said no. Three days later it proposed a heuristic to detect the same case. This time I wrote the refusal down, with the reason, and the idea has stayed away since.

6. Skills

If I say the same thing three times, it should be a skill.

Most of mine live outside the code. One writes product descriptions. It is mostly rules: every adjective comes with a number, every section rests on a verified fact, and a list of words stays out. A validation script greps the output for all of it. A rule with a script behind it is a test. The rest is prayer.

Subagents are the same idea with their own context window. Mine are canned prompts with a name: database, tests, forms, code review. They earn their place because a schema review’s noise stays in their window and out of mine.

7. Hooks

A hook turns “please run the formatter” into “the formatter runs”.

I have zero. CLAUDE.md asks Claude to run typecheck, lint and format after every task. It is an instruction, so it is optional. A commit from July is titled “fix pre-existing errors surfaced by the unblocked Lint gate”. That is what optional looks like.

First hook to add: after every edit, run the formatter. Second: before every test run, rewrite the command so only failures come back. Start with one annoying manual step. The framework can wait.

8. Choose the model

My default is Fable, 1M context, xhigh effort. Expensive, and right for my codebase. When it fails, it is because it knew too little about an SDK’s internals, and a bigger model fixes that. Anthropic’s rule: too little knowledge, bigger model. Too little effort, higher effort.

I go cheaper wherever the thinking is already done. All my subagents run on Sonnet.

Set it once. Changing model or effort mid-session drops the prompt cache and re-reads the whole conversation at full price.

9. Git

Claude commits and writes the message. That is where the rationale lives now: the commit lists what failed and why, and a comment in the recorder says “this is exactly how multi-day trips lost their trace”. Written for the next agent as much as for me.

Reverting is free. A follow-up looked right in the session and did not work on the boat. Reverted, and the memory file says: dead end, here is the unsolved problem if you retry.

Checkpoints and /rewind are for the session. Git is for the product.

10. Parallelize only parallel work

Generating 32,000 descriptions was parallel work: waves of 200, ten subagents at a time, one merge agent per wave.

A bug in one recorder is the opposite. Five agents would each have needed to understand the same three modules before deciding anything.

When the work is parallel, worktrees: a refactor in one, a content loop in another, main free for a hotfix. Each agent gets its own filesystem.

11. /usage

A long loop hits the plan’s five-hour limit, waits, resumes. That works because the loop knows where the limit is. /usage shows it, and now attributes usage to each skill, subagent and MCP server.

One consequence: content generation runs inside Claude Code sessions rather than through the API. Same models, one bill.

Bonus: spend your weekly allowance early

The weekly cap expires, and Anthropic resets it early for everyone more often than you would expect. Each reset replaces whatever was left with a full allowance. Spent early, your week counts twice. Saved, it gets overwritten.

So run the heavy jobs in the first three days after a reset: migrations, content loops, large refactors. Keep the tail of the week for reviews and small fixes. /usage shows the reset time, and a session stopped by a limit now waits and resumes on its own.

The skill is now delegating

What to give it, what to keep, when to let it run, when to hit Escape.

Delegation works when the repository is ready for it. For me that meant a short CLAUDE.md, a few subagents, skills with validators, a memory folder, tests named like specs, commits that explain why. All of it is engineering, and all of it compounds: every mistake makes the next run better.

The goal is Claude doing more of the work while I keep control of the result.

Thanks for reading The Buildup. Robin and I share what we are building: the code, the failures, the numbers, and what is worth following in tech that week.

We are the two people co-founder at Moqa Studio, an AI agency in Paris. We build AI agents and systems for businesses, and we help engineering teams work the way this article describes. If your team wants to get there faster, say hello.

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?