Monday, 16th March 2026
Over the last three weeks, I've been studying how to get the most out of agentic coding tools -- not by throwing everything at them, but by being deliberate about how I use them.
The common assumption among many users seems to be that maximising value from something like Claude Max is straightforward: crank up the thinking effort, throw in a vague prompt, and let it burn through your weekly usage. More tokens consumed must mean more work done, right? I'd argue the opposite.
My approach has been focused on minimising waste at every step. Before an agent touches a task, I prepare comprehensive instruction sets and structured markdown files it can read immediately -- this dramatically reduces the time and context an agent needs to orient itself and get going. Rather than babysitting sessions interactively, I run everything through remote servers with tmux, which lets me monitor tasks continuously without being physically present. During the day, I define and queue up tasks with clear todos, so the agent keeps working through the night while I sleep. The work doesn't stop when I do.
The results have been tangible. In my first week, I used roughly 20% of my weekly allocation. Second week, around 30%. This week is trending toward 70%+ -- but that's not because I've become less efficient. It's because the pipeline is now mature enough to take on significantly more ambitious work. In these three weeks, this setup has produced over 2,000 unit and integration tests -- a volume that would have taken far longer and cost far more with a less structured approach.
The lesson I'd take from this: don't stress about hitting your usage ceiling every week. A half-used week with a well-structured pipeline and meaningful output beats a maxed-out week of chaotic, expensive prompting. Build the scaffolding first. The productivity will follow -- and it will compound.
Microsoft Copilot and the MCP Integration Experience — A Mess
When people talk about the best AI models right now, the conversation usually centres on Claude, ChatGPT, and Gemini -- with Grok increasingly earning a mention. But enterprise AI is a different landscape entirely. Inside large organisations with strict security and compliance requirements, the shortlist shrinks fast. Many firms effectively have one sanctioned option: Microsoft Copilot. It's deeply embedded in the Microsoft 365 ecosystem that most enterprises already run on, which makes it the path of least resistance for IT departments -- regardless of whether it's actually the best tool for the job.
Today I was working through the process of connecting our MCP server to Copilot. It did not go well.
The documentation is ambiguous to the point of being genuinely misleading. The UI is cluttered and poorly thought through. And the settings -- where do I even start. Here's a question that should have a simple answer: how many distinct Copilot platforms does Microsoft currently operate? The answer, as best as I can tell, is at least three. Microsoft 365 Copilot, Copilot Studio, and GitHub Copilot all exist as separate products with separate configurations, separate interfaces, and separate documentation -- and the lines between them are blurry enough that figuring out which one you're actually supposed to be working in is itself a non-trivial task. For a developer trying to do something as specific as MCP integration, this fragmentation is a genuine obstacle.
This is what Microsoft looks like right now from the inside -- a company sitting on an enormous pile of products that don't quite talk to each other, held together by inertia and enterprise lock-in rather than coherent design. The AI wrapper is new; the organisational chaos underneath it is not.
On a brighter note: I also got a new work machine today. A 64GB RAM workstation, first thing to do -- setting up a proper Linux environment for future development work. Some things, at least, are still built with the developer in mind.