I saw a SharePoint MVP's post recently. Genuine excitement. Markdown support had landed in SharePoint. Not a joke — real, earned enthusiasm from someone who knows their domain inside out.
And I get it. In the SharePoint world, that's real progress. It matters for real users solving real problems. You don't become an MVP without expert knowledge and public recognition. He was right to celebrate.
What stopped me wasn't his post. It was the contrast with myself — with what I used to get excited about, and what I'm working on now.
The Post I Would Have Written
Eighteen months ago, I'd have written that exact post. Same enthusiasm. Same well-earned expertise. Same genuine belief that this was meaningful progress. And I'd have been right — in the world I was living in.
But I've spent the last year backing into a different way of working. Then, over a long weekend, I sat down and built the infrastructure for agents to work autonomously — agent loops, error recovery, quality gates, the unglamorous fabric that makes autonomous code trustworthy instead of terrifying. By Sunday night, those agents had scaffolded 111 SharePoint web parts and 5 backend services. Design, build, test. All local. No human hands on the code.
Three days of tooling produced months of human output. But the output wasn't the impressive part — the steep learning curve was.
The SharePoint MVP wasn't wrong. He was just in a different conversation. And that's the part that scared me.
What YouTube Doesn't Show You
Here's what no tutorial, TikTok, or conference talk prepares you for: the grind.
Over those three days, something broke roughly every few hours. Not metaphorically — literally. You fix the macOS permissions so the agent can read files. Now it needs a gateway restart. Restart it and the model config turns out to be broken — empty model name, nothing works for two hours while you trace why. Fix that, and suddenly the build fails because the SCSS configuration is extending the wrong toolchain — it was written for Gulp, not Heft. Rewrite that, and the Yeoman scaffold generator silently ignores your CLI flags because a .yo-rc.json exists from a previous run. Build a manual template script to bypass it. Now the directories are PascalCase and your pipeline expected kebab-case. Fix that. Now C++ native modules won't compile on Node 22. That's before you even get to the agents looping — repeating the same three broken commands until you harden the loop detection.
None of this is in a tutorial. You can't watch a video for it. You have to live through it — hands on, late at night, no shortcut.
The memory file got patched again and again. Model preferences changed. The sync method moved from a Pi server to Git-based recovery. Configs were rewritten wholesale — config.json, sass.json, tsconfig, ESLint rules, the entire pipeline script. Each fix revealed the next breakage. The pain point just moved — same problem, different file, new and creative way of failing.
This is the unglamorous truth about building agent infrastructure: you're not engineering features. You're engineering resilience. Before it can build web parts autonomously, it has to survive the environment. Before you can trust it, it has to break in every possible way. There is no "prompt engineering" your way out of this. It's systems engineering, and it's dirty.
Two Conversations, Same Industry
Here's what I keep coming back to: these two things — celebrating markdown support and watching agents build entire applications autonomously — are happening in the same industry, on the same platform, to people with the same job title.
That's not a criticism of anyone. It's a data point about how fast the ground is shifting.
The gap isn't between smart people and slow people. It's between two entirely different models of what software development is becoming. In one model, we're incrementally improving the tools we already know. In the other, the tools are learning to use themselves.
And you can be a genuine expert — someone with years of deep domain knowledge, public recognition, real achievements — and still be standing in the first room while the second one exists a few doors down.
I almost was.
How I Almost Missed It
I'm not telling this story because I saw it coming. I didn't. I backed into it.
I was a SharePoint developer. Not a machine learning engineer. Not an AI researcher. A developer who spent years learning the quirks of SPFx, the SharePoint Framework, because that's what the job demanded.
What changed wasn't my intelligence or foresight. It was a simple question: "What if I stopped prompting AI and started architecting workflows for it?"
That shift — from treating AI as a smart autocomplete to treating it as a team member with a defined role, quality gates, and an audit trail — was the door I walked through. Not because I was clever. Because I was curious, and slightly lazy, and the alternative was writing web part number 112 by hand.
The methodology that emerged — I now call it Works With Agents, but the name doesn't matter — isn't complicated. It's just… different. Different enough that it creates a perception gap. And perception gaps are where the real opportunity lives.
What This Means (For All of Us)
Here's the uncomfortable part. The gap isn't closing. It's widening.
The tools are getting better faster than the mental models are updating. By the time the average team lead internalises what Claude or Copilot can do today, the agents will have moved on to something else entirely. We're not in a technology adoption curve. We're in a fragmentation event.
Three things I think are true, as of May 2026:
1. Your technical moat is thinner than you think. If your competitive advantage is "we build features faster," a research loop — cron job, web search, LLM analysis, agent scaffold — can clone your feature set in a weekend. The moat is moving to compliance, trust, and domain relationships. Things that take months or years, not hours.
2. The bottleneck isn't code generation. It's verification. When an agent can produce a thousand lines of code in seconds, the hard problem isn't "did it compile?" It's "did it do what I actually needed, safely, and can I prove that to an auditor?" Regulated industries feel this most acutely, but it's coming for everyone.
3. The people who are "behind" aren't stupid. They're in a different room. And most of us are in rooms we don't know about yet. The question isn't "am I ahead?" It's "what room am I in right now that already looks like markdown support to someone else?"
The Real Question
I don't have a tidy conclusion. The SharePoint MVP was right to be excited. Markdown in SharePoint is progress. But somewhere between his post and my screen, I realised that the measure of progress had fundamentally changed. Not gradually. Suddenly. And not everyone noticed.
So the question I've been sitting with: what room am I in right now, feeling perfectly current, that already looks like markdown support from the outside?
If you've got an answer — or if this made you uncomfortable — I'd genuinely like to hear it.
