Forem: Increase Akinwole

The AI Productivity Paradox: Why Developers Are 19% Slower (And What This Means for 2026)

Increase Akinwole — Thu, 18 Dec 2025 15:55:39 +0000

We've all heard the narrative: AI coding tools are revolutionizing software development, making us faster, more productive, and more creative. GitHub reports that 41% of new code is now AI-generated. Tool vendors tout massive productivity gains. And if you ask most developers, they'll tell you AI makes them faster.

But here's the uncomfortable truth: They might all be wrong.

The Study That's Making Everyone Uncomfortable

In a rigorous randomized controlled trial conducted by METR (Model Evaluation & Threat Research) between February and June 2025, something shocking emerged. When 16 experienced open-source developers were given real tasks from their own repositories, projects they'd worked on for an average of five years, those using AI tools took 19% longer to complete their work.

Let that sink in. Not 19% faster. 19% slower.

But here's where it gets really interesting: Before the study, these developers predicted AI would make them 24% faster. Even after experiencing the slowdown, they still believed AI had sped them up by 20%.

This isn't just a measurement error. This is a 39-percentage-point perception gap between reality and belief.

The Trust Crisis No One's Talking About

The disconnect between perception and reality extends far beyond this single study. Google's 2024 DORA report, surveying over 39,000 professionals, revealed troubling patterns:

75% of developers feel more productive with AI
Yet every 25% increase in AI adoption showed a 1.5% dip in delivery speed
System stability dropped by 7.2% with increased AI adoption
Only 24% of developers report having "a great deal" or "a lot" of trust in AI-generated code

This creates a dangerous paradox: We're using tools we don't trust, believing they're helping us, while data suggests they're slowing us down.

Why Are We Actually Slower?

The METR study identified five key factors contributing to the productivity loss:

1. The Over-Optimism Trap

Developers consistently overestimated AI's benefits. This persistent optimism meant they kept reaching for AI assistance even when it was counterproductive. It's like having a hammer and seeing every problem as a nail, except the nail gun is actually slower than doing it by hand.

2. Deep Repository Knowledge Defeats AI

The study found that developers with high familiarity with their repositories were slowed down more. When you already know your codebase intimately, AI suggestions often miss crucial context. As one participant noted: "AI doesn't pick the right location to make the edits" and lacks understanding of "weird cases of backwards compatibility."

3. AI Struggles with Complexity

The repositories averaged over 1.1 million lines of code and were approximately 10 years old. Developers reported that AI "made some weird changes in other parts of the code that cost me time to find and remove." Current AI tools simply struggle with complex, mature codebases where everything is interconnected.

4. The Acceptance Rate Problem

Developers accepted less than 44% of AI-generated code suggestions. Even when accepted, 56% of developers reported needing to make major changes to clean up AI code. Think about that overhead: you're spending time reviewing, understanding, and fixing AI suggestions.

5. The Review Tax

Developers spent approximately 9% of their time just reviewing and cleaning AI-generated outputs. That's nearly 4 hours per week for a full-time developer, time that could have been spent writing code they understood from the start.

But Wait, Other Studies Show the Opposite?

You're right to be skeptical. Microsoft's 2023 study showed developers completing tasks 55.8% faster with GitHub Copilot. Other research found a 26% increase in completed tasks.

So what gives?

The key difference is context and experience level:

Earlier studies often used simpler, self-contained tasks
They measured less experienced developers working on unfamiliar codebases
The tasks were algorithmic and well-scoped

The METR study specifically tested experienced developers on their own mature projects, the real-world scenario most professional developers actually face. As the research notes, "less experienced developers showed higher adoption rates and greater productivity gains."

Translation: AI might be a great tutor for beginners, but a questionable assistant for experts.

The 2025-2026 Reality Check: What Changed?

Interestingly, Google's 2025 DORA report (released September 2025) shows a shift: AI adoption is now linked to higher software delivery throughput, a reversal from 2024's findings. But stability concerns remain.

What happened? A few things:

Tools got smarter. Claude 3.7 Sonnet, GPT-4, and specialized coding agents emerged with better context understanding.
Developers got wiser. There's a learning curve. Studies suggest it may take 11 weeks (or 50+ hours with a specific tool) to see meaningful productivity gains.
Best practices emerged. The developer community figured out when to use AI and when to skip it.

So When Does AI Actually Help?

Based on the research, AI coding tools excel at:

Boilerplate and repetitive code: Writing CRUD operations, API endpoints, or standard patterns? AI shines here.

Unfamiliar territories: Learning a new framework or language? AI can accelerate the learning curve.

Documentation and explanation: Generating README files, inline comments, or understanding existing code.

Test generation: Creating unit tests and test cases based on existing functions.

Simple, well-scoped tasks: Clear requirements with minimal context? AI can handle it.

When to Stay Human

Complex, interconnected systems: Your 5-year-old monolith with tribal knowledge? AI will struggle.

Security-critical code: AI-generated code has been found to introduce more privilege escalation paths (322% more) and design flaws (153% more).

When you know the answer: If you already have deep familiarity with the solution, AI will slow you down.

Quality over speed contexts: When code quality, maintainability, and long-term thinking matter most.

The 2026 Playbook: Using AI Responsibly

Here's how to actually benefit from AI coding tools in 2026:

1. Treat AI as a Junior Developer

Never accept the first suggestion. Review, understand, and refine. Would you merge a junior dev's code without review? Then don't do it with AI.

2. Context is King

Start by documenting your codebase thoroughly. Well-documented code helps AI generate better suggestions. As Google engineers found: document early to get better output later.

3. Break Tasks Into Stages

Don't ask for entire modules in one shot. Instead:

Ask AI to outline the approach
Request detailed pseudocode
Generate implementation in chunks
Review and integrate piece by piece

4. Use the Right Tool for the Job

Inline completion (Copilot, Cursor autocomplete): For simple functions
Chat/generation (Claude, GPT-4): For explaining concepts, planning
Agentic tools (Claude Code, Windsurf): For multi-file refactors
Don't use AI at all: When you know exactly what to do

5. Measure What Matters

Stop tracking "lines of code generated" or "suggestions accepted." Instead, measure:

Time to merge (cycle time)
Code review comments and issues
Post-merge bugs and reverts
Developer satisfaction and flow state

6. Establish Team Standards

AI amplifies your development culture. If your processes are messy, AI will make them messier. Invest in:

Clear coding standards
Documented architectural decisions
Consistent error handling patterns
Security guidelines

7. Practice Fundamentals

Don't let AI atrophy your skills. As one engineer noted after relying heavily on AI: "Things that used to be instinct became manual, sometimes even cumbersome." Continue practicing the grunt work regularly.

The Bigger Picture: What This Means for 2026

The AI productivity paradox teaches us an important lesson: We're in the middle of a fundamental shift in how software gets built, and we're still figuring out the rules.

Here's what to expect in 2026:

More Specialization: Tools will get better at specific tasks. We'll see AI that's great at testing, AI that's great at refactoring, and AI that's great at documentation, not one tool trying to do everything.

Better Context Management: The 200K+ token context windows we're seeing now will become standard. Tools will maintain better understanding of entire codebases.

Human-AI Collaboration Patterns: Clear playbooks will emerge for when to use AI and when to go manual. The "vibes-based coding" phase will mature into structured practices.

Skill Evolution: The most valuable developers won't be those who generate the most AI code, they'll be those who know when to trust it, when to question it, and how to integrate it responsibly.

The Bottom Line

AI coding tools aren't magic productivity multipliers, at least not yet, and not for everyone. They're powerful but immature technologies that work best in specific contexts.

The 19% slowdown isn't a death knell for AI coding tools. It's a reality check. It tells us:

Perception isn't reality. Just because you feel faster doesn't mean you are faster.
Experience matters. What works for beginners doesn't work the same way for experts.
Context is everything. AI needs more information than we initially thought to be truly helpful.
Quality takes time. The time you save generating code gets spent reviewing and fixing it.

As we move into 2026, the winners won't be the developers who blindly adopt every AI tool. They'll be the ones who thoughtfully integrate AI where it helps, skip it where it doesn't, and maintain the fundamental skills that make them effective engineers.

The productivity paradox isn't a problem to solve, it's a reality to navigate. And navigating it well might just be the most important skill you develop this year.

Vibe Coding vs Traditional Development: Finding Your Balance

Increase Akinwole — Tue, 09 Dec 2025 12:03:05 +0000

Last Tuesday at 2 AM, I shipped a feature in 3 hours that would've taken me two days using my "proper" development workflow. The code worked perfectly. The users loved it. But my dev brain kept screaming: "Where are your tests? What about the documentation? Did you even plan this?"

Welcome to the eternal struggle between vibe coding and traditional development.

If you've been in the dev community lately, you've probably heard about "vibe coding", that magical state where you just flow with the code, trusting intuition over rigid processes. But here's the thing: both approaches have their place, and knowing when to use each one might be the most valuable skill you can develop.

What Are We Really Comparing?

Before we dive in, let's define what we're actually talking about.

Traditional Development is the structured approach most of us learned in school or bootcamps. It emphasizes planning, documentation, testing, code reviews, and following established patterns. Think TDD, design documents, and those three-hour architecture meetings.

Vibe Coding is the intuitive, flow-state approach where you trust your instincts and just build. It's about momentum over methodology, shipping over perfection, and letting your subconscious developer brain take the wheel. Less planning, more doing.

Neither is inherently better. They're tools, and like any tool, they shine in different situations.

The Case for Traditional Development

Let's be honest: traditional development practices exist for good reasons. They're battle-tested solutions to real problems that have cost companies millions of dollars.

When Traditional Development Wins

Working on critical systems: When you're touching payment processing, medical records, or anything where bugs can harm people or cost serious money, you need that safety net. Write those tests. Do those code reviews. Plan meticulously.

Large team collaboration: When 20 developers are working on the same codebase, you need structure. Without conventions, clear documentation, and proper planning, you'll spend more time fixing conflicts than building features.

Long-term maintainability: That clever hack you vibe-coded at 2 AM? Future you (or worse, your teammate) will hate you for it. Traditional practices ensure code remains understandable and maintainable months or years later.

Complex architecture decisions: When you're designing a microservices architecture or choosing a database strategy, you can't just vibe it. These decisions have long-term consequences that require careful analysis.

The Hidden Costs of "Proper" Development

But traditional development isn't free. Every process has overhead:

Planning meetings that could've been async messages
Writing tests for code that might get thrown away tomorrow
Documentation that's outdated before it's even reviewed
Code review cycles that kill momentum and context
Analysis paralysis from trying to predict every edge case

I once spent three weeks on a "properly planned" feature with full test coverage and documentation. The stakeholder changed their mind two days after launch. All that careful work? Wasted.

The Case for Vibe Coding

Vibe coding gets a bad rap from the "serious developers," but it's how some of the best software gets built. It's not about being sloppy—it's about optimizing for different constraints.

When Vibe Coding Wins

Prototyping and MVPs: When you're validating an idea, speed trumps everything. Ship fast, learn fast, iterate fast. Nobody needs unit tests for a prototype that might be scrapped tomorrow.

Solo projects and side hustles: When you're the only developer and the stakes are low, why burden yourself with enterprise processes? Trust your judgment and move fast.

Creative exploration: Sometimes you don't know what you're building until you build it. Vibe coding lets you discover solutions through experimentation rather than upfront planning.

Small, isolated features: That new button on your dashboard? The email notification template? These don't need architecture review meetings. Just build it and ship it.

High-context, low-complexity work: When you deeply understand the domain and the change is straightforward, formal processes just slow you down.

What Vibe Coding Gets Right

Vibe coding recognizes some truths that traditional development often ignores:

Flow state is real and valuable: When you're in the zone, you can accomplish in 2 hours what would take 8 hours with constant interruptions for standup, code review, and planning.

Perfect is the enemy of shipped: Working software in users' hands beats perfect software in your head every time.

Context is expensive: Every meeting, every code review round, every context switch costs you precious mental bandwidth. Sometimes the fastest path forward is just heads-down building.

Your intuition is trained: After years of coding, your gut instincts are informed by countless experiences. Trust them.

The Reality: You Need Both

Here's what I've learned after bouncing between startups and enterprise roles: the best developers aren't purists. They're pragmatists who know when to vibe and when to be rigorous.

My Personal Framework

I use what I call the "consequence-complexity matrix" to decide my approach:

Low consequence + Low complexity = Pure vibe coding

UI tweaks
Internal tools
Quick fixes
Experimental features

High consequence + Low complexity = Vibe with safety nets

Add basic tests
Quick peer review
But keep the momentum

Low consequence + High complexity = Structured vibe

Rough plan or diagram
Code freely within that structure
Refactor as you learn

High consequence + High complexity = Full traditional

Proper design phase
Test-driven development
Thorough code review
Documentation

Real-World Examples

Vibe coding win: I built an internal dashboard for our support team in a single afternoon. No tests, minimal planning, just vibes. It's been running for two years with zero issues because the domain was simple and the stakes were low.

Traditional development win: When we rewrote our authentication system, we spent a week planning, another week implementing with TDD, and had three rounds of security review. Overkill? No. That code handles thousands of users' sensitive data.

Hybrid approach: For our new feature flagging system, I vibe-coded a prototype in a day to validate the approach. Then we threw it away and built the production version properly over two weeks with full test coverage.

Finding Your Balance

Here's how to develop your own sense of when to use each approach:

Start with self-awareness

Ask yourself honestly:

How well do I understand this problem?
What happens if this breaks?
Am I building to learn or building to ship?
Will anyone else need to maintain this?
Is this experimental or foundational?

Develop your gut check

Before starting any task, pause for 30 seconds and ask: "What's the appropriate level of rigor here?" Your instinct will get better with practice.

Create safety valves

Even when vibe coding, have some guardrails:

Use TypeScript or another typed language (catches obvious bugs)
Write integration tests for critical paths (even if you skip unit tests)
Do quick self-reviews before pushing (catch the obvious mistakes)
Keep a "tech debt" list (acknowledge what you're skipping)

Timebox your vibes

Give yourself permission to vibe code for a fixed period. "I'll build this feature in 2 hours with pure vibes. If it works, great. If not, I'll restart with proper planning." This prevents vibe coding from becoming reckless coding.

Learn to shift gears

The best developers can switch modes mid-project. Start with vibe coding to explore the solution space, then switch to traditional development once you know what you're building. Or vice versa: plan the architecture properly, then vibe code the implementation.

The Common Pitfalls

Vibe Coding Gone Wrong

The rewrite trap: You vibe code something quickly, it grows, and eventually you need to rewrite it properly. Sometimes that's fine (validate fast, rebuild right). Sometimes it's wasteful.

The maintenance nightmare: Future you trying to debug vibe-coded spaghetti at 3 AM is not a fun experience. Leave yourself breadcrumbs—at least some comments explaining the why.

The scope creep: Vibe coding feels so productive that you keep adding features without stopping to question if they're needed. Momentum is great until you build the wrong thing really fast.

Traditional Development Gone Wrong

Process theater: Following processes because "that's how we do things" rather than because they add value. If your standup is just people reading their Jira tickets, you're doing it wrong.

Premature optimization: Planning for scale you'll never reach, abstracting before you understand the problem, building frameworks when you need features.

Innovation paralysis: When everything requires an RFC, three meetings, and a committee decision, you'll never ship the weird experimental feature that becomes your killer feature.

Tools That Help Both Approaches

Interestingly, modern tools are making it easier to get the best of both worlds:

AI assistants (Claude, Copilot, Cursor) let you vibe code faster while still maintaining quality. They help you write tests quickly, suggest edge cases, and catch bugs—the safety nets without the overhead.

Type systems give you compile-time guarantees even when you're moving fast. TypeScript lets you vibe code with confidence.

Hot reload and fast feedback loops mean you can experiment freely and catch mistakes immediately.

Linting and formatting tools handle the boring stuff automatically, letting you focus on the interesting problems.

My Current Balance

These days, I spend about 60% of my time vibe coding and 40% in traditional mode. But it varies wildly by project:

Side projects? 90% vibe coding, 10% "let me at least write a README"
Startup features? 70% vibe, 30% structure
Enterprise work? 30% vibe, 70% traditional
Open source? 50/50, because others need to understand my code

The key insight: I'm consciously choosing my approach based on context, not just defaulting to one style.

The Meta Skill

Here's the real secret: the skill isn't mastering vibe coding or traditional development. It's developing the judgment to know which tool to use when.

Some developers are incredible at traditional development but get bogged down in process when they should just ship. Others are vibe coding wizards who create maintenance nightmares because they never slow down to do things properly.

The developers I most admire? They can switch effortlessly between modes. They vibe code their way through exploratory work, then lock in with rigorous practices when they find something worth building properly. They know when tests add value and when they're just ceremony.

Your Action Plan

If you're trying to find your balance, here's what I suggest:

Track your work for a week: Note which tasks you vibe coded and which got the full treatment. Did you choose appropriately?
Experiment deliberately: Pick a task you'd normally over-engineer and just vibe it. Pick another you'd normally vibe and do it properly. How did it feel? What did you learn?
Get feedback: Ask teammates or users which of your shipped features feel solid and which feel hacky. You might be surprised.
Build your rubric: Develop your own decision framework. Mine is consequence-complexity, but yours might be different based on your context.
Forgive yourself: You'll sometimes choose wrong. That's fine. The goal is to improve your batting average, not be perfect.

The Bottom Line

Vibe coding and traditional development aren't enemies. They're different tools in your toolkit, each optimized for different situations.

The worst developers are the ones who only know one approach and try to apply it everywhere. The best developers are pragmatists who choose their methodology based on context, not ideology.

So the next time you're starting a task, pause and ask: "What does this need?" Sometimes the answer is proper planning and rigorous testing. Sometimes it's throwing on some lo-fi beats and vibing your way to a solution in one flow state session.

Both are valid. Both are professional. Both are necessary.

The magic happens when you know which one to use.

Building Your First MCP Server: A Complete Beginner's Guide

Increase Akinwole — Tue, 02 Dec 2025 15:16:56 +0000

If you've been exploring AI development, you've probably heard about the Model Context Protocol (MCP). But what exactly is it, and how do you build your own MCP server? In this guide, we'll walk through creating your first MCP server from scratch, no prior experience required.

What is MCP?

The Model Context Protocol is an open standard that enables AI assistants like Claude to securely connect with external data sources and tools. Think of it as a universal adapter that lets AI models interact with your applications, databases, and services in a standardized way.

Before MCP, integrating AI with different tools meant building custom solutions for each integration. MCP provides a unified protocol that makes these connections simpler and more maintainable.

What We're Building

We'll create a simple weather MCP server that provides current weather information. This server will expose a tool that Claude can use to fetch weather data for any city. It's a perfect first project because it's practical, straightforward, and demonstrates all the core MCP concepts.

Prerequisites

Before we start, make sure you have:

Node.js installed (version 18 or higher)
Basic knowledge of JavaScript/TypeScript
A code editor (VS Code recommended)
An API key from OpenWeatherMap (free tier works fine)

Step 1: Set Up Your Project

First, create a new directory and initialize a Node.js project:

mkdir weather-mcp-server
cd weather-mcp-server
npm init -y

Install the required dependencies:

npm install @modelcontextprotocol/sdk
npm install --save-dev typescript @types/node

Create a tsconfig.json file:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "Node16",
    "moduleResolution": "Node16",
    "outDir": "./build",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src/**/*"]
}

Step 2: Understanding MCP Server Structure

An MCP server has three main components:

Resources: Read-only data that the AI can access (like files or database records)
Tools: Functions that the AI can execute (like searching, creating, or updating data)
Prompts: Pre-built prompt templates the AI can use

For our weather server, we'll focus on creating a tool since we want Claude to actively fetch weather data.

Step 3: Create the Server

Create a src directory and add an index.ts file:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";

const WEATHER_API_KEY = process.env.OPENWEATHER_API_KEY;

if (!WEATHER_API_KEY) {
  throw new Error("OPENWEATHER_API_KEY environment variable is required");
}

// Create the MCP server
const server = new Server(
  {
    name: "weather-server",
    version: "1.0.0",
  },
  {
    capabilities: {
      tools: {},
    },
  }
);

// List available tools
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: "get_weather",
        description: "Get current weather information for a city",
        inputSchema: {
          type: "object",
          properties: {
            city: {
              type: "string",
              description: "The city name (e.g., 'London', 'New York')",
            },
          },
          required: ["city"],
        },
      },
    ],
  };
});

// Handle tool execution
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "get_weather") {
    const city = request.params.arguments?.city as string;

    if (!city) {
      throw new Error("City parameter is required");
    }

    try {
      // Fetch weather data from OpenWeatherMap API
      const response = await fetch(
        `https://api.openweathermap.org/data/2.5/weather?q=${encodeURIComponent(
          city
        )}&appid=${WEATHER_API_KEY}&units=metric`
      );

      if (!response.ok) {
        throw new Error(`Weather API error: ${response.statusText}`);
      }

      const data = await response.json();

      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(
              {
                city: data.name,
                temperature: data.main.temp,
                feels_like: data.main.feels_like,
                humidity: data.main.humidity,
                description: data.weather[0].description,
                wind_speed: data.wind.speed,
              },
              null,
              2
            ),
          },
        ],
      };
    } catch (error) {
      throw new Error(
        `Failed to fetch weather data: ${
          error instanceof Error ? error.message : String(error)
        }`
      );
    }
  }

  throw new Error(`Unknown tool: ${request.params.name}`);
});

// Start the server
async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("Weather MCP Server running on stdio");
}

main().catch((error) => {
  console.error("Fatal error in main():", error);
  process.exit(1);
});

Step 4: Understanding the Code

Let's break down what's happening:

Server Initialization: We create a new MCP server with a name and version, specifying that it has tool capabilities.

ListToolsRequestSchema Handler: This tells Claude what tools are available. We define a get_weather tool with a clear description and input schema that specifies it needs a city name.

CallToolRequestSchema Handler: This is where the actual work happens. When Claude calls our tool, we fetch data from the OpenWeatherMap API and return formatted results.

Transport: We use StdioServerTransport which allows the server to communicate via standard input/output, making it easy to integrate with Claude.

Step 5: Build and Configure

Add build scripts to your package.json:

{
  "scripts": {
    "build": "tsc",
    "start": "node build/index.js"
  },
  "type": "module"
}

Build your server:

npm run build

Step 6: Get Your API Key

Go to OpenWeatherMap
Sign up for a free account
Navigate to your API keys section
Copy your API key

Step 7: Connect to Claude Desktop

To use your MCP server with Claude Desktop, you need to configure it. Create or edit the Claude Desktop configuration file:

On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

On Windows: %APPDATA%\Claude\claude_desktop_config.json

Add your server configuration:

{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": ["/absolute/path/to/your/weather-mcp-server/build/index.js"],
      "env": {
        "OPENWEATHER_API_KEY": "your_api_key_here"
      }
    }
  }
}

Replace /absolute/path/to/your/weather-mcp-server with the actual path to your project and your_api_key_here with your OpenWeatherMap API key.

Step 8: Test Your Server

Restart Claude Desktop. You should now be able to ask Claude questions like:

"What's the weather in Tokyo?"
"Can you check the current temperature in Paris?"
"Tell me about the weather conditions in Lagos"

Claude will automatically use your MCP server to fetch real-time weather data!

Understanding What Just Happened

When you ask Claude about the weather:

Claude recognizes it needs weather information
It discovers your get_weather tool through the MCP protocol
It calls the tool with the appropriate city parameter
Your server fetches data from OpenWeatherMap
The results are returned to Claude
Claude presents the information in a natural, conversational way

Common Issues and Solutions

Server not appearing in Claude: Make sure you've restarted Claude Desktop after editing the config file, and check that the path to your server is absolute, not relative.

API errors: Verify your OpenWeatherMap API key is correct and that you've activated it (it can take a few minutes after signing up).

TypeScript errors: Ensure you're using Node.js 18 or higher and that all dependencies are installed correctly.

Next Steps

Congratulations! You've built your first MCP server. Here are some ways to extend it:

Add more weather endpoints (forecast, air quality, historical data)
Implement caching to reduce API calls
Add error handling for invalid city names
Create additional tools for related functionality
Add resources to provide weather data access patterns

Where to Go From Here

The MCP ecosystem is growing rapidly. Here are some resources to continue your journey:

Building MCP servers opens up endless possibilities for enhancing AI capabilities. Whether you're connecting to databases, APIs or custom business logic, the pattern you've learned here applies universally.

JavaScript Build Tools: Past and Beyond

Increase Akinwole — Tue, 25 Nov 2025 15:37:38 +0000

Introduction

If you've been writing JavaScript for more than a few years, you've probably experienced the dizzying evolution of build tools. From manually concatenating files to modern zero-config bundlers, the JavaScript ecosystem has been on a relentless quest to make our development experience faster, simpler, and more powerful.

In this article, we'll journey through the history of JavaScript build tools, understand why each generation emerged, and explore what the future holds for frontend tooling.

The Early Days: Manual Concatenation and Task Runners

Before Build Tools (Pre-2010)

In the early days of web development, JavaScript files were simply linked in HTML with multiple script tags. As applications grew, this approach became problematic with issues like global namespace pollution, dependency management nightmares, and slow page loads from multiple HTTP requests.

Grunt (2012): The Task Runner Era

Grunt introduced configuration-based task automation to JavaScript. You could define tasks for minification, compilation, linting, and more through a Gruntfile.

module.exports = function(grunt) {
  grunt.initConfig({
    uglify: {
      build: {
        src: 'src/*.js',
        dest: 'build/app.min.js'
      }
    }
  });

  grunt.loadNpmTasks('grunt-contrib-uglify');
  grunt.registerTask('default', ['uglify']);
};

Why it emerged: Developers needed automation for repetitive tasks like minification and file watching.

Limitations: Configuration files became massive and complex. Tasks ran sequentially, making builds slow.

Gulp (2013): Streaming Build System

Gulp improved upon Grunt by using Node.js streams and code-over-configuration philosophy, making builds faster and more intuitive.

const gulp = require('gulp');
const uglify = require('gulp-uglify');
const concat = require('gulp-concat');

gulp.task('scripts', function() {
  return gulp.src('src/*.js')
    .pipe(concat('app.js'))
    .pipe(uglify())
    .pipe(gulp.dest('build'));
});

Innovation: Streaming architecture and cleaner API made it faster and more developer-friendly.

The Module Bundler Revolution

Browserify (2011): Bringing Node.js to the Browser

Browserify allowed developers to use Node.js-style require() statements in browser code, pioneering the concept of bundling.

// Now you could write browser code like Node.js
const utils = require('./utils');
const lodash = require('lodash');

Game changer: Module system in the browser before ES6 modules existed.

Webpack (2012): The Bundler King

Webpack transformed how we think about frontend assets. Everything became a module - JavaScript, CSS, images, fonts. It introduced concepts like code splitting, tree shaking, and hot module replacement.

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist')
  },
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      },
      {
        test: /\.(png|jpg|gif)$/,
        use: ['file-loader']
      }
    ]
  }
};

Why it dominated: Incredibly powerful and flexible, with a massive plugin ecosystem. It could handle any asset type and supported advanced features like lazy loading and HMR.

The catch: Configuration complexity became legendary. Webpack configs could easily grow to hundreds of lines.

Rollup (2015): Optimized for Libraries

Rollup focused on producing smaller, cleaner bundles using ES6 modules and advanced tree-shaking. It became the go-to choice for library authors.

export default {
  input: 'src/main.js',
  output: {
    file: 'bundle.js',
    format: 'esm'
  }
};

Sweet spot: Excellent for libraries and packages that needed minimal, clean output.

The Modern Era: Speed and Simplicity

Parcel (2017): Zero Configuration

Parcel promised "blazing fast, zero configuration web application bundler." It automatically detected dependencies and transformed files without requiring configuration.

# That's it. No config file needed.
parcel index.html

Philosophy: Convention over configuration. Just point it at your entry file and go.

Innovation: Multi-core compilation and filesystem caching made it incredibly fast.

Snowpack (2020): Unbundled Development

Snowpack took a radical approach by leveraging native ES modules in the browser, skipping bundling entirely during development.

Key insight: Modern browsers support ES modules natively. Why bundle during development at all?

Result: Near-instant startup and updates, regardless of project size.

Vite (2020): The New Standard

Created by Evan You (Vue.js creator), Vite combined the best ideas from previous tools with native ESM during development and Rollup for production builds.

// vite.config.js - minimal config
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()]
});

Why developers love it:

Lightning-fast cold starts and hot module replacement
Simple configuration with sensible defaults
Framework-agnostic but with great framework support
Production builds optimized with Rollup

Development experience:

npm create vite@latest my-app
cd my-app
npm install
npm run dev
# Server running in milliseconds, not seconds

esbuild (2020): Written in Go for Speed

esbuild rewrote the bundler in Go, achieving speeds 10-100x faster than JavaScript-based bundlers.

Benchmark reality check: What took Webpack 10 seconds might take esbuild 0.1 seconds.

Trade-off: Fewer features and plugins than mature bundlers, but many tools now use it internally for speed.

Turbopack (2022): Rust-Powered Successor

Vercel announced Turbopack as "the successor to Webpack," written in Rust for maximum performance. Currently integrated into Next.js.

Promise: 700x faster updates than Webpack, 10x faster than Vite for large applications.

Current State: What Should You Use Today?

For New Projects

Vite: Best all-around choice for most frontend projects. Fast, simple, excellent DX.
Next.js/Remix/SvelteKit: Framework-specific solutions that handle bundling for you.

For Libraries

Rollup or esbuild: Produce clean, optimized packages.
tsup: Modern, simple library builder powered by esbuild.

For Large Monorepos

Turborepo + Vite/esbuild: Orchestration with fast builds.
Nx: Complete monorepo solution with caching and task scheduling.

Legacy Projects

Webpack: Still perfectly fine if already set up. Webpack 5 is stable and performant.

Looking Beyond: The Future of Build Tools

Native Tooling Integration

Browsers continue improving native ES module support and import maps, potentially reducing bundling needs further.

WebAssembly Tooling

More tools will be written in compiled languages (Rust, Go) for native-level performance. SWC (Rust-based) is already replacing Babel in many projects.

Edge Computing Optimization

Build tools are evolving to optimize for edge deployments, with features like automatic code splitting for serverless functions.

Unified Toolchains

Projects like Biome aim to replace multiple tools (ESLint, Prettier, bundlers) with single, fast solutions.

AI-Assisted Optimization

Future tools might use AI to automatically optimize bundle splitting, lazy loading strategies, and performance based on real usage patterns.

Key Lessons from the Evolution

1. Developer Experience Matters: Tools that are easier to configure and faster to run win adoption.

2. Performance is Non-Negotiable: Each generation of tools gets dramatically faster. Users won't tolerate slow builds.

3. Defaults Over Configuration: Modern tools succeed by making the right choices by default while still allowing customization.

4. Native Platform Features: As browsers evolve, build tools adapt to leverage new capabilities.

5. The Best Tool is the One You Don't Notice: The ideal build tool works so seamlessly you forget it exists.

Practical Migration Advice

If you're on Webpack and considering a migration:

When to stay:

Your current setup works fine
Complex custom configurations that would be hard to replicate
Team familiarity and no pain points

When to migrate:

Starting a new project
Build times are causing productivity issues
Seeking simpler configuration
Want better developer experience

Migration path:

Try Vite on a small new feature or side project
Measure the difference in build times and DX
Plan incremental migration if beneficial
Keep Webpack knowledge - it's not going away soon

Conclusion

The evolution of JavaScript build tools reflects our industry's relentless focus on improving developer experience and performance. We've gone from manually concatenating files to sub-second rebuilds of massive applications.

Today, tools like Vite offer the best balance of speed, simplicity, and power for most projects. But the landscape continues evolving, with even faster tools emerging and new approaches being explored.

The key is choosing tools that match your project's needs and team's expertise rather than chasing the newest shiny object. Sometimes Webpack is still the right choice. Sometimes you need Vite's speed. And sometimes, for simple projects, you might not need a bundler at all.

What's your experience with JavaScript build tools? Have you made any migrations recently? Share your stories in the comments below!

A Beginner-Friendly Guide to TypeScript (What I Wish I Knew Earlier)

Increase Akinwole — Fri, 21 Nov 2025 14:34:35 +0000

When I first started learning TypeScript, I thought it was “just JavaScript with extra rules.”
But the deeper I went, the more I realised TypeScript isn’t just a tool, it’s a mindset.

If you’re new to it, this post will save you the confusion I went through and give you a smooth entry into TypeScript.

What Is TypeScript?

In simple terms:

TypeScript = JavaScript + types + better developer experience

It helps you catch bugs early, write clearer code, and avoid accidental mistakes.

Why TypeScript Matters

Here’s what I wish I understood from day one:
1. TypeScript makes your code predictable
No more guessing what a function returns or what type of data a variable holds.

2. Fewer runtime errors
TS catches issues before your code runs.
That alone saves hours of debugging.

3. Better autocomplete
Your editor becomes smarter.
Auto-suggestions, type hints and documentation right inside VS Code.

4. Makes teamwork easier
Other developers understand your code faster when types are clear.

TypeScript Basics (Explained Simply)

1. Type Annotations
You can tell TS the type of a variable:

let age: number = 24;
let username: string = "John";
let isLoggedIn: boolean = true;

2. Arrays

let scores: number[] = [10, 20, 30];
let names: string[] = ["John", "Jane"];

3. Objects

let user: { name: string; age: number } = {
  name: "John",
  age: 24
};

4. Functions

function greet(name: string): string {
  return `Hello, ${name}`;
}

5. Union Types

let id: number | string;
id = 12;
id = "12";

Interfaces (Your New Best Friend)
Interfaces let you create a structure that many objects can follow.

interface User {
  name: string;
  age: number;
  isAdmin?: boolean; // optional property
}

const admin: User = {
  name: "John",
  age: 24,
  isAdmin: true
};

This makes your code more organised and scalable.

TypeScript With React (A Quick Taste)

If you’re using React, TS helps you avoid a lot of confusion.

type ButtonProps = {
  label: string;
  onClick: () => void;
};

function Button({ label, onClick }: ButtonProps) {
  return <button onClick={onClick}>{label}</button>;
}

Now React knows exactly what the component expects, no more guessing.

The Biggest Lesson I Learned

You don’t need to master TypeScript before using it.
The real magic happens when you start building:

add types gradually
use your editor hints
let TypeScript guide you And with time, everything clicks.

Final Thoughts

TypeScript isn’t difficult. Once you get comfortable with its structure, your code becomes cleaner, safer and more enjoyable to write.

If you’re a beginner, here’s my advice:

Start small. Build often. Let TypeScript teach you as you go.

How I Transitioned Into Software Engineering (Coming From Architecture)

Increase Akinwole — Wed, 19 Nov 2025 17:55:14 +0000

When people hear that I studied Architecture for my BSc, they’re always surprised when I introduce myself today as a Software Engineer.
To many, the two fields feel worlds apart, one deals with buildings, the other with code.

But in reality, the transition wasn’t as strange as it sounds.

My Background: From Buildings to Code

I spent years learning architectural design, drawings, modelling, building science and how to bring concepts to life. Architecture teaches structure, logic, precision and the importance of breaking big ideas into small, buildable units.

Funny enough…
that’s exactly what software engineering requires too.

The Moment I Realized Architecture Wasn’t My Final Destination

At some point during my degree, I realized I enjoyed creating, but not just buildings. I wanted something more dynamic, something that allowed me to build faster, explore ideas quickly and bring solutions to life without waiting months or years.

I discovered programming accidentally.
The first time I saw a simple “Hello World,” it felt like magic — instant creation.

The Early Struggles

Transitioning wasn’t smooth:

I had to learn to think like a developer.
Debugging made me question all my life choices.
JavaScript humbled me more times than I can count.
I felt behind because others started earlier.

But one thing architecture taught me was discipline.
You don’t survive architecture school without resilience, and that helped me survive learning to code.

How Architecture Secretly Prepared Me for Software Engineering

Looking back, I realized Architecture gave me several advantages:

1. Design Thinking
In architecture, you learn to understand user flow, space usage and human behavior.
In software, it became intuitive for me to:

structure UI layouts,
think about user experience,
and design clean, logical systems.

2. Breaking Down Complex Projects
Architectural projects are huge.
You learn to break things into drawings, layers, components and stages.

This made it easier to understand:

components in React
modular code
large software systems
project management

3. Attention to Detail
Architecture forces you to think in precision, one small mistake affects the whole building.

That mindset helped me write cleaner, more readable code.

The Turning Point

The moment everything clicked was when I finally built my first functional project, something small but it worked.
And that feeling of bringing something to life through code was addictive.

From there:

I studied consistently
built projects
improved my portfolio
and slowly grew into the engineer I am today

What I Learned (That I Wish I Knew Sooner)

1. Consistency beats intensity
You don’t need 10 hours a day, just 3–4 focused hours done consistently.

2. You don’t need to know everything before building
Start building early. Projects teach more than tutorials.

3. Google, StackOverflow and documentation are your best friends
Real engineers search every day.

4. Impostor syndrome is normal
If you feel like you don’t know enough, congratulations — you’re a developer.

5. Your background is a strength, not a disadvantage
Architecture didn’t hold me back, it made me unique.

Conclusion

Switching careers isn’t easy, but it’s possible.
My journey from Architecture to Software Engineering taught me that your degree doesn’t define your future, your willingness to learn does.

If you’re transitioning from a completely different field too, remember:

You don’t start from zero. You start from experience.