Rethinking the Engineering Process with MCP

More than forty years ago, Frederick Brooks made an observation that still feels uncomfortable because it remains true.

In The Mythical Man-Month, he argued that the hardest problem in software teams is not technical complexity, but communication. As teams grow, coordination costs explode—not because people are incapable, but because they no longer share the same context.

What Brooks was really pointing at, even if he didn’t use today’s language, was this:

Software systems fail when context is fragmented.

Despite decades of better languages, tools, and platforms, this problem hasn’t gone away. In fact, with distributed systems and AI-assisted development, it has intensified.

Today, code is no longer the bottleneck.
Context is.

That is why an MCP-based engineering process matters—not as a new tool, but as a correction to a problem we’ve known about for decades.

# Engineering Has Quietly Changed

Modern engineering work is not about writing instructions in isolation.

A developer today works inside a web of:

• long-lived codebases
• distributed services
• deployment pipelines
• observability signals
• historical decisions
• partially remembered incidents

The context required to make a safe change rarely lives in one place. It is scattered across dashboards, tickets, chat threads, and people’s memories.

We have normalized this fragmentation.
AI has made it impossible to ignore.

AI systems can generate code quickly, but they lack intuition:

• why a decision was made
• which trade-offs were accepted
• which failures already happened

Without shared context, speed becomes risk.

# What Is MCP, Really?

MCP is not an execution platform. It is an interface and context-sharing protocol. It provides a structured way for development tools and models to access code repositories, infrastructure metadata, and observability systems through a consistent interface.

It is about making context explicit.

An MCP-based engineering process treats context as first-class infrastructure—something that can be:

• discovered
• queried
• reasoned over
• acted upon

by humans and AI agents.

In practical terms:

MCP is the layer that allows engineers and agents to understand what is happening in a system, why it is happening, and what actions are safe to take next.

This is not documentation for compliance.
It is operational understanding, kept alive.

# The Shift: From Writing Code to Maintaining Shared Understanding

Traditional engineering assumed that humans carried context in their heads and tools merely executed instructions.

That assumption no longer holds.

Systems are too large, teams too distributed, and change too continuous. AI agents amplify this reality—they don’t remove the need for context; they expose its absence.

An MCP-based approach reframes engineering as:

The practice of maintaining shared understanding across humans and agents.

That shared understanding shows up in three concrete ways.

# 1. Context Discovery

Instead of reconstructing history manually, developers and agents can ask:

• What changed recently?
• Which decisions led here?
• What signals indicate stress or risk?
• What constraints must be respected?

Context is not guessed. It is discoverable.

This is the first break from the world Brooks described—communication no longer depends entirely on people being present at the same time with same understanding.

# 2. Contextual Action

MCP is not just about reading context.
It enables acting within it.

Actions like:

• creating commits
• triggering deployments
• rolling back changes
• updating configurations

are taken with awareness of:

• prior decisions
• system state
• operational impact

AI agents stop being “fast typists” and start behaving like supervised engineers.

# 3. Context Persistence

This is where most teams quietly lose compounding advantage.

With MCP, context survives:

• team churn
• role changes
• tool migrations
• time

Decisions don’t vanish when someone leaves.
Rationale doesn’t disappear after an incident is closed.

Engineering maturity accumulates instead of resetting.

# MCP as the Engineering Nervous System

I find it useful to think of MCP as the nervous system of engineering: it lets the system sense, coordinate, and respond coherently.

Without it, we get reflexes.
With it, we get intent.

# A Practical Example

This is not theoretical for me.

In my own workflow, I maintain a daily development log. After every bug fix or feature change, an agent summarizes what changed and appends it to the log.

For larger or structural changes, I maintain Architectural Decision Records (ADRs)—capturing not just what changed, but why. These ADRs are written after prompt-driven conversations within a context-aware agentic IDE.

Over time, something interesting happens:

• Dev logs capture the flow of work
• ADRs capture decision intent
• Both are queryable later
• Both inform future actions

This is not documentation for its own sake.
It is context persistence embedded into daily engineering.

# Decision Traces Become Visible

Recently, I came across Jaya Gupta’s writing on decision traces (Jaya Gupta). From a business perspective, the idea can feel abstract.

From an engineering perspective, it becomes very concrete.

When:

• decisions are recorded in ADRs
• changes are visible in code and deployments
• outcomes appear in observability signals

a trace forms naturally.

I can see which architectural decision led to which system behavior.

Today, this trace exists primarily at the technical level. If business SLAs were layered in, the same mechanism could support controlled experimentation across technical and business outcomes.

The important point is this:

Decision traces don’t require new bureaucracy. They emerge when context is captured where work actually happens.

# Why This Matters for AI Agents

AI agents without context are confident but fragile.

They can generate plausible code, but without understanding:

• historical failures
• operational constraints
• intent behind past decisions

they amplify risk.

An MCP-based process ensures that agents operate inside the same contextual boundaries as humans.

A simple rule holds:

AI agents are only as safe as the context they are allowed to see and act upon.

# Governance Without Heavy Process

One fear is that all this adds overhead.

In practice, it does the opposite.

MCP replaces:

• implicit rules
• undocumented assumptions
• fragile handoffs

with:

• explicit constraints
• traceable decisions
• auditable actions

Governance becomes embedded, not enforced.

# Closing Thought

Brooks warned us that software fails when communication breaks down.
AI has not solved that problem—it has made it more visible.

The teams that will scale safely in the AI era are not those with the best models, but those that treat context as infrastructure.

MCP is not the future of coding.
It is the future of engineering.

As I explained above, I have been experimenting with these ideas in my own work. Reading the Railway MCP documentation, particularly the get-logs method, and the Opalstack MCP examples helped crystallize the shift. This feels less like an experiment now and more like a direction.