DEV Community: Ivelin (Ivo)

The Rise of the Fleet: Scaling My Engineering Workflow with Github Copilot Agents

Ivelin (Ivo) — Mon, 06 Apr 2026 20:59:58 +0000

In this post, I’ll walk you through how I use Copilot and my personal preferences for different approaches. For this demo, I’m using an Express server with two endpoints that find books by author or publisher. My goal is to build a simple UI for it.

I should start by saying I’m no expert; I’m learning new things every day and constantly adapting my workflow. By sharing this, I hope to kick off some discussions in the comments and at the office so I can learn how you’re using the tool, too.

I’m not going to dive into specific models here - just use whatever suits your needs. It’s worth trying different ones to see what you like best. Models change and improve faster than I can blink (at least it feels that way!).

The below is a screenshot of the chat with with all the options expanded. Let’s explore some of them:

Using ‘Local’ mode

I use ‘Local’ for tasks that need less compute and a faster response. When I’m planning, brainstorming, or exploring parts of the codebase and want to talk through ideas, I’ll stick with Local. Let’s start by mapping out the UI concept:

The Agent helpfully clarifies the process, catches edge cases, or flags anything it finds a bit ambiguous.

Once we’ve gone back and forth a few times and the plan feels solid, it’s time to implement the changes.

CoPilot CLI

Moving on to the Copilot CLI. I think of it as the ‘agent’ that takes the guesswork out of the equation. It’s perfect for those tougher tasks that require a bit more compute.

In the top right of the search bar, you can check your ‘sessions in progress’ or ‘unread sessions’ that are waiting for your input or permission to continue.

In the screenshot below, I accidentally kicked off the implementation twice. I’m going to archive one of them so I can focus on the session that actually needs my attention.

The Agent starts by checking out the plan and executing the steps in order. It’ll ask for permission before running certain commands, giving you a few ways to handle the workflow:

Manually approve each prompt as it comes.
Whitelist specific commands to always be allowed in the session, workspace, or globally.
Go rogue and allow all commands for the duration of this session.

While waiting for the plan to finish executing, I decided to kick off another session to update the documentation.

A few minutes later, the work is done. Before reviewing the code, I’ll QA the changes. The first thing I noticed is that the response isn’t rendering, so let’s get the agent to fix it.

I’m going to enable the ‘debugger’ custom agent to help me fix the error. (I’ll dive deeper into custom agents a bit later in the post.)

It’s often a good idea to spin up a separate session for debugging, so your agent starts from a fresh session, but you can definitely keep it within the same session if you prefer.

This agent has access to the Simple Browser in VSCode, so it can check the error directly, but I usually include the details in my request anyway just to be sure.

First, I’d totally forgotten to start the server in the background (a classic "face-palm" moment). Second, the returned price was occasionally undefined, so calling .toFixed() was breaking the app. Thankfully, the Debugger agent caught both.

Next, I’ll review the code to make sure it matches what I had in mind. Once I’m happy, I’ll ask it to create a PR - this automatically runs some checks and raises the request against my main branch.

In this example, I kept all my prompts in one session, but if you like to keep things tidy, you can easily do the PR part in a fresh session instead.

Copilot CLI options

If you type /, Copilot brings up a list of available commands with a brief description for each. Let’s break down the main ones and what they’re used for:

To keep this brief, I’ll give you a quick overview of what’s what and how I use each, but I’d love for you to share your favourite prompt or agent that’s been game-changing for your workflow.

I also recommend checking out the community-created collections of custom agents, skills, and workflows to supercharge your experience. One big tip: ALWAYS READ THE RAW FILES before you copy them. Make sure no prompt injection commands are hidden in the comments, which are easy to miss in preview mode.

Awesome-copilot collection:

https://github.com/github/awesome-copilot

And Anthropic’s collection:

https://github.com/anthropics/skills

I’d also recommend Matt Pocock’s collection:

https://github.com/mattpocock/skills

`/create-prompt`

If you find yourself repeating the same prompts, save some time by creating a workspace-specific prompt. You can also save them globally to use across all your repos.

`/create-instructions`

Instructions are the guidelines for how an Agent should behave in a repository. Think of them as the ‘onboarding docs’ for the AI.

`/create-skill`

I think of Skills as the ‘playbook’ you hand to your agents. They bundle together high-level instructions, strict context constraints, and technical tool definitions. This helps agents tackle complex workflows with much higher precision and consistency.

`/create-agent`

Think of Agents as personas with different skills. You can create one to help you brainstorm, another to turn those ideas into action, and a third to actually build them out - essentially a different persona for every stage of your development.

`/create-hook`

Think of these like Git hooks, but for AI agents—instructions that trigger during specific events like sessionStart, sessionEnd, userPromptSubmitted, preToolUse, postToolUse, or errorOccurred. I’d definitely suggest checking out the secrets-scanner hook as a solid example.

Using a Fleet (multiple agents)

Let’s tackle that same task again, but this time using a Skill to generate a Product Requirements Document (PRD) and then kicking off a fleet of agents to execute the work in parallel.

It then follows up with a bunch of questions about any criteria I might have missed.

The Skill I used splits tasks into GitHub issues, but you can easily set it up to create them locally instead.

Done! Let’s check and see if those issues were actually created.

And in Github:

Next, I’ll use the /fleet command to kick off multiple agents. Each one will grab an issue and execute the task independently.

Once it’s finished, it’ll let me know in the chat and provide the files for review. I’ll usually run a quick test to make sure everything works as expected before I dive into the code review.

The UI looks okay - I didn’t give it much detail on the styling, so I’m pretty happy with the result. If anything feels off, I’ll just keep iterating until it’s exactly where I want it.

In my experience, deploying a fleet can be a bit slower-this specific task took about 15 minutes. But as models improve, this is only going to get faster.

It’s more cost-effective since you end up using fewer tokens. Because each agent has its own context and focuses on its own task, you get much less context drift. You can even assign specific personalities to different tasks.

One thing to watch out for: agents share the same file system, which can lead to conflicts. It’s a "last write wins" scenario, so if multiple agents hit the same file, they might overwrite each other. Ideally, you want them working on separate areas.

The best part is that you can "set and forget" them. Once they’re finished, you just review all the changes in one go.

Conclusion

Orchestrating agents and agentic development is only going to get faster and more effective-and hopefully cheaper, too. We’re still in the early days, so experiment and see what fits your needs. Just be mindful of what you copy from the web and the permissions you grant your agents. If you have any tips, share them-we’re all in this together. Embrace the learning and enjoy the process. Happy coding (or maybe I should say Happy prompting)!

Getting Started with the Model Context Protocol (MCP): Build and Connect Your First MCP Server

Ivelin (Ivo) — Mon, 04 Aug 2025 10:57:51 +0000

What is MCP
Demo 1 - Using a pre-build MCP - sharing my local filesystem
Demo 2 - Creating MCP server from the ground up (using Typescript SDK)
MCP Server Inspector
Connecting MCP Client with our MCP Server
(Optional) Extend the custom MCP Server with dynamic data

What is MCP?

The Model Context Protocol acts as a bridge between AI models and external services in a standardised way. On their own, LLMs are limited in usefulness - while ChatGPT 3.5 was good at generating text and making jokes, it couldn’t access real-time data or connect to your email inbox by itself.

This is where “tool augmentation” became important - we were able to link LLMs to various services, but each service used a different API. Managing and scaling applications with this approach could quickly become very challenging.

MCP Server addresses this issue by providing a unified communication method with the LLM (MCP Client). This means users no longer need to worry about individual service APIs, making it much easier to implement and scale different services.

In fact, it's even more convenient - typically, service providers are responsible for creating and maintaining the MCP server. This means that any changes to their API are handled by them, so users don't need to worry about ongoing maintenance.

There are countless ways to use MCP servers. Common examples include connecting an LLM to your browser so the AI can browse for you, granting access to your email, linking to Github to allow the AI access to your repositories, or integrating with tools like Figma or Blender for 3D design tasks. Many many more.

To show how this works, we'll start by using an existing community built MCP server before creating our own. To connect to an MCP server, we need an MCP Client. Some available options are VSCode, Claude Desktop, Cursor and many others. Since I'll be coding in VSCode, that's the client we'll use.

(Part 1) Connecting to a pre-built MCP Server

After reviewing the available options on mcpservers.org, I’ve chosen to use the Filesystem MCP. This MCP includes built-in tools for managing a selected directory. Once access is granted, the AI will be able to perform the following tasks:

Read/write files
Create/list/delete directories
Move files/directories
Search files
Get file metadata

To add The Filesystem MCP in VSCode, we'll connect by using the following commands

🔸 Cmd/Ctrl + Shift + P and select MCP: Add Server

🔸 Enter the NPM Package name and allow access

🔸 I will add a directory containing various files that require sorting (uhh you should see my desktop). If you're following along, select an existing directory from your file system.

🔸 Enter system ID - you can leave that as filesystem.

A mcp.json file has now been created in .vscode directory, containing the following information:

{
  "servers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/{{username}}/Downloads/TheJunkDrawer"
      ],
      "type": "stdio"
    }
  },
  "inputs": []
}

We can also confirm that the Filesystem MCP has been added by checking the Extensions tab in the sidebar. (Yes my sidebar is on the right and it’s just awesome, don’t judge me!).

I noticed that although the server was installed, it didn't start automatically for me. If you encounter the same issue, you can start it by pressing Cmd/Ctrl + Shift + P, then select MCP List Servers > Select Filesystem > Start Server.

To check if it's functioning properly, let's ask the AI to organise the files into folders based on their file types. Here’s the current state of the folder:

The query I ran: (without saying “please.” The guilt is real)

This MCP server includes 12 tools, each functioning like a separate action. It can independently determine the next steps to take, but before carrying out any action, it will either request your approval or you can choose to let it operate automatically and go wild. Here’s the result after it finished:

(Aaaaaaa!!! This is crazy!! Honestly, my Desktop and Downloads need this more than anywhere else).

(Part 2) Creating MCP server from the ground up

Now that we've worked with a pre-built MCP, let's create a server from scratch to connect our app with AI models. To keep it straightforward, we'll build a weather tool using TypeScript. Let's begin by setting up a new project:

Setup a new project

🔸 Create a directory and cd into it. In your terminal, type:
mkdir mcp-weather-server && cd $_
🔸 Initiate a new project yarn init -y or use your preferred package manager (I knooow, I should really start using pnpm)
🔸 In the newly created files, open package.json and add "type": "module" below version to enable ES Modules (required for MCP SDK)
🔸 Create index file with touch index.ts
🔸 Install the SDK
yarn add @modelcontextprotocol/sdk

That's everything for now. Here is how the directory currently appears:

Building the server

Open index.ts and copy the code provided below. Be sure to follow the comments that explain each step.

// Import necessary modules from the MCP SDK
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

// Create a new MCP server instance with a name and version, required for the MCP protocol
const server = new McpServer({
  name: "MCP Weather Server",
  version: "1.0.0",
});

/* Register a tool with the server.
   Tools allow the AI to perform specific actions or retrieve information */
server.registerTool(
  // Unique identifier for the tool
  "get-weather",
  // Tool metadata
  {
    title: "\"Get Weather\","
    // Descrtion helps AI understand what the tool does
    description: "\"Tool to get the weather of my location\","
    // Input schema to define the expected input
    inputSchema: {
      location: z.string().describe("The location to get the weather for"),
    },
  },
  // Function to execute when the tool is called
  async ({ location }) => {
      /* For demonstration purposes we will return static data,
         but in a later step we will make this dynamic */
    return {
      content: [
        {
          type: "text",
          text: `The weather in ${location} is sunny with a temperature of 28°C.`,
        },
      ],
    };
  }
);

/* StdioServerTransport uses the terminal for input/output
   This is useful for local development and testing
   In production, you might use a different transport like HTTP or WebSocket */
const transport = new StdioServerTransport();
await server.connect(transport);

That's it! This was a straightforward example, but it gives you an idea of how it works. Now, let's test it out using the inspector.

MCP Server Inspector

The MCP Inspector is a handy GUI tool used for testing MCP Servers. Let's launch it and connect our server by running the following command:

npx -y @modelcontextprotocol/inspector npx -y tsx index.ts

You should see the following output in the console. Open the provided URL, which will already have the token filled in:

This is how Inspector version v0.15.0 appears on my system with the dark theme enabled, so your view might look slightly different. On the loaded screen, select the bottom left button ‘Connect’, then click on ‘List Tools’ and select the ID of the tool (get-weather).

Type the location and you should receive a result.

And that, ladies and gentlemen, is how you get endless 28°C sunny days in London. You’re welcome! For you rain lovers (I am secretly one too, but shhh), we will work on this later.

The MCP Inspector is useful for testing each tool you’ve created, but it’s probably not the main way you’d want to interact with your server. Let’s integrate this with the tools you use every day - specifically, back to VSCode.

Connecting MCP Client with our MCP Server

🔸 In VSCode, open the command palette by pressing Cmd/Ctrl + Shift + P.
🔸 Type MCP: Add Server
🔸 Choose Command (stdio)

🔸 Enter command npx -y tsx index.ts
🔸 Enter your server name (or leave default)
🔸 Choose where to install it - I have selected Workspace

This should open your mcp.json file with your configurations in place and the server running. If it hasn't started automatically, click Start to launch it.

🔸 Let's ask Copilot for the current weather in London (as if I can’t see out of the window that it isn’t sunny)

and the result, as expected - Sunny 28C (Before I move on, I will hit refresh on this a few more times to see if the clouds will get the hint and clear as I have plans for this weekend).

Congratulations! You’ve set up your first MCP Server. While this example is quite simple and the use case may seem limited for now, the main goal was to help you understand the concept. Feel free to experiment with your own ideas. If you have any questions, you can reach out to me on LinkedIn.

In the next step, we’ll make a request to fetch actual weather data and update the static response to return real-time information.

Connect the server to a weather API provider

We are going to use Open-Meteo, as it’s free and does not need API key.

🔸 In your index.ts, replace the body of the callback function with the following. Be sure to follow the comments that explain each step.

 /* We first need to fetch latitude and longitude coordinates for the given location using
    the Geocoding API Notice that I am using countryCode=GB to limit results to Great Britain,
    you can change this to any country code or remove it for global results.
  */
  try {
    const result = await fetch(
      `https://geocoding-api.open-meteo.com/v1/search?name=${location}&count=1&countryCode=GB`,
      {
        method: "GET",
        headers: {
          "Content-Type": "application/json",
        },
      }
    );

    // Parse the response as JSON
    const coordinatesJson = await result.json();

    // Extract latitude and longitude from the response
    const { latitude, longitude } = coordinatesJson.results[0];

    // Fetch weather data using the obtained coordinates
    const weatherResult = await fetch(
      `https://api.open-meteo.com/v1/forecast?latitude=${latitude}&longitude=${longitude}&hourly=temperature_2m,precipitation_probability,rain`,
      {
        method: "GET",
        headers: {
          "Content-Type": "application/json",
        },
      }
    );

    // Parse the weather data response as JSON
    const weatherJson = await weatherResult.json();

      // Return the weather data in a structured format
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify(weatherJson, null, 2),
        },
      ],
    };
  } catch (error) {
   // Handle any errors
    console.error("Error fetching weather data:", error);
    return {
      content: [
        {
          type: "text",
          text: "Failed to fetch weather data. Please try again later.",
        },
      ],
    };
  }

We can view the result in the inspector. Next, we'll run it in our MCP Client.

🔸 In VSCode, restart your MCP Server by opening the Command Palette Cmd/ctrl + Shift + P
🔸 Select MCP: List Servers and select the weather-server

🔸 Select Restart server . You will then notice in the Output that the MCP server has been stopped and restarted.
🔸 Try again with the same prompt:

How awesomeeee!!! The LLM takes the raw data and gives you a friendly message, with the accurate data, with no formatting needed!

Conclusion

Connecting an LLM to various services, data sources, and applications in a standardised way significantly enhances its usefulness. MCP, an open-source solution from Anthropic, has rapidly gained popularity. Like any emerging technology, developers may eventually encounter edge cases that require further development or even replacement of the solution, but for now, it shows great promise and is becoming the standard.

If you'd like to talk more about any of the topics above, I’d be happy to connect on LinkedIn. I’m happy hear your feedback or answer any questions. All the best and happy coding!

Useful Links:

First steps in initialising Webpack and Typescript

Ivelin (Ivo) — Tue, 15 Mar 2022 23:29:34 +0000

Part 1 - Very basic setup

Build your own config for Webpack from the ground up. This post will hold your hand for the first 4 steps and you will see how to take it from there. As of Webpack 4, a config file is not needed so let's see how we can create a build.

In your terminal, navigate to a folder you want to work in and type the following:

yarn init -y

yarn add webpack webpack-cli --dev

In the root level create a folder /dist with a file index.html inside and another folder /src in the root level and add a index.js file inside it. Your file structure should look like the following:

|- package.json
|- package-lock.json
|- /dist
    |- index.html
|- /src
    |- index.js```

In your package.json, replace "main": "index.js", with "private": true to prevent it from publishing your package.

Add basic HTML5 boiler plate to your dist/index.html file, it should look like this:



<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Webpack</title>
    <script src="main.js"></script>
  </head>
  <body></body>
</html>

As an example, add a console log to your ./src/index.js



const greetings = "Hello World";
console.log(greetings);

This is all that is needed for a very basic build. Now run yarn webpack and you can see a new, compiled file main.js to appear in ./dist. The content of the compiled file should look like the following:



console.log("Hello World");

Part 2 - Adding a custom config file

In the root level, add a file called webpack-config.js and then add the following configs:



import path from "path";

export default {
  entry: "./src/index.js",
  output: {
    path: path.resolve(__dirname, "dist"),
    filename: "main.js",
  },
};

Part 3 - Add script command

In your package.json, add the following command to the existing scripts (you should have test by default)



"build": "webpack --mode development"

Next time you need to run a build, you can use yarn run build instead of typing it all in the terminal.

Part 4 - Add TypeScript

Install dependancies



yarn add typescript ts-loader ts-node --dev

Add a new file tsconfig.json to the root level of the project and add the following configs:



{
    "compilerOptions": {
      "target": "ESNEXT",
      "module": "commonjs",
      "strict": true,
      "esModuleInterop": true,
      "skipLibCheck": true,
      "forceConsistentCasingInFileNames": true,
      "resolveJsonModule": true
    }
  }

Then open your webpack-config and add the following below output



module: {
  rules: [
    {
      test: /\.tsx?$/,
      use: "ts-loader",
      exclude: /node_modules/,
    },
  ],
},
resolve: {
  extensions: [".tsx", ".ts", ".js"],
},

Replace the entry file extension in your webpack-config to:



entry: path.resolve(__dirname, "src/index.ts")

Add a new file to ./src named index.ts. You can now start to use this instead.

This is all that is needed to create an initial configs for webpack and add support for typescript. If you have any questions, please leave a comment and I will get back to you. All the best at initialising webpack!