AI & Engineering — The Future of Work

How AI coding tools are reshaping the deep-work era of software engineering — and why that’s an opportunity worth seizing.

The flow state is being disrupted — and that’s okay

For over a decade, the gold standard of great engineering has been deep work. Long, unbroken stretches of concentration. A single ticket. A single codebase. The mythical state of flow that turns average engineers into 10x contributors. We optimised our entire culture around it — no-meeting Wednesdays, async-first communication, Pomodoro timers, noise-cancelling headphones.

Then AI coding tools arrived. And now a single engineer can run three parallel implementation threads before lunch.

The rise of tools like Claude, Cursor, GitHub Copilot, and the Model Context Protocol (MCP) is doing something subtle but seismic: it’s pulling engineers out of deep, single-threaded work and into a new mode of operation — one where your job is less “write the code” and more “direct the code.” Less carpenter, more architect on a busy site.

This is the birth of the Multi-Context Programmer.

What MCP actually means for your workflow

The Model Context Protocol, in its technical sense, is a standard that lets AI models connect to external tools, codebases, APIs, and data sources simultaneously. But zoom out, and it describes something happening to engineers themselves: we’re being asked to hold more context, more concurrently, than ever before.

In a traditional deep-work workflow, a senior engineer might spend a full day implementing one feature — reading the codebase, reasoning through edge cases, writing tests, refactoring. The cognitive load was high, but it was singular. You held one problem in your head.

With AI pair-programming at your side, that same engineer is now:

• Supervising an AI writing the authentication service
• Reviewing a PR the AI drafted on the data pipeline
• Prompting a third agent to debug the flaky integration test
• All before the morning standup

The throughput is extraordinary. But so is the cognitive shift required. This isn’t the same skill set as deep work. It’s something new.

What we’re gaining (and what we need to grieve)

Let’s be honest about the trade-off. Deep work built something important in engineers — intuition. Hours spent tracing through a memory leak, manually debugging a race condition, or reading source code you didn’t write builds a kind of mental model of systems that AI-assisted shortcuts can quietly erode.

The risk isn’t that AI writes bad code. It’s that engineers stop understanding the code being written on their behalf.

That said, the gains are real and worth embracing. Boilerplate that used to consume three hours of focus is gone in minutes. Junior engineers can punch above their weight class. Senior engineers can finally operate at the architectural level they’ve always wanted to, rather than getting bogged down in implementation details.

The engineers who thrive in this new era won’t be the fastest typists or the best at memorising API signatures. They’ll be the ones who can think in systems, communicate precisely with AI tools, and hold multiple workstreams in their head without losing the thread on any of them.

How to adapt: the multi-context programmer’s playbook

This is not a eulogy for deep work. It’s a call to evolve.

1. Protect deliberate deep work — don’t let it vanish Schedule time weekly where you write code without AI assistance. Debug manually. Read unfamiliar codebases. This isn’t nostalgia — it’s maintenance of the cognitive muscle that makes you a good director of AI. You can’t review what you don’t understand.

2. Treat prompting as a first-class engineering skill The quality of your AI output is directly proportional to the quality of your input. Vague prompts produce vague code. Learn to write precise, contextual prompts with constraints, examples, and expected outputs. This is a skill gap in most engineering teams right now — the first to close it win.

3. Build context-switching rituals Multi-context work is mentally expensive if done haphazardly. Create lightweight rituals for switching between workstreams — a quick note on where each thread is, what’s blocked, what needs a decision. Treat yourself like a small engineering team that needs a standup.

4. Review obsessively AI-generated code ships bugs with the same confidence it ships working features. The multi-context programmer’s most important habit is rigorous, skeptical code review — of AI output especially. Don’t merge what you don’t understand. The responsibility didn’t transfer to the model; it transferred to your review.

5. Invest in systems thinking As implementation gets automated, the irreplaceable human contribution moves up the stack: architecture, trade-off analysis, domain knowledge, team coordination, technical strategy. The engineers who double down on systems thinking now will lead the teams that everyone else wants to be on.

The MCP engineer is already here

The best engineers working today aren’t fighting this shift — they’re leaning into it. They’re treating AI tools like a team of fast but literal junior developers: capable, but requiring clear direction, supervision, and context. They’re operating at a level of output that would have seemed impossible three years ago.

The era of the deep-work solo craftsperson isn’t over — but it’s sharing the stage. The engineers who will define the next decade are the ones who can move fluidly between deep thinking and multi-context directing, knowing when to go wide and when to go deep.

That’s the multi-context programmer. And you can start becoming one today.