By Paul O’Donovan

It started with George 

George is our Developer Advocate at MediaKind. A few weeks ago, he came to me genuinely excited about documentation. 

Not the usual reaction to documentation. 

But what he’d been working on wasn’t routine. He was restructuring the MK.IO docs, standardising them, and making them consumable by AI models. Not just readable by humans, but usable by machines. 

Because when documentation is structured properly, an AI model does more than retrieve information. It can use it. 

That left me with a question I couldn’t shake: What happens when you put that to the test? 

I decided to find out 

Here’s the important bit: I am not a developer. 

I spent the early part of my career finding bugs in other people’s code. My last actual coding project was in 1999. Turbo Pascal. It was out of date even then. 

What I decided to build was an enterprise training solution. MediaKind had just launched a library of training videos on YouTube, which gave me real content to work with. The idea was simple: instead of sending employees a YouTube link, give them a structured portal they could use. 

As a non-coder, getting MK.IO set up is where this should have fallen apart. It didn’t. The documentation portal walks you through exactly what you need to do, and the whole thing took about five minutes. There was even a video to follow along with. 

Then I opened Claude Code. I described what I wanted in plain English. No architecture document, no technical specification. It asked a few clarifying questions and got started. To give it access to MK.IO, I did something very unsophisticated: I pasted in the documentation URLs. That was it. 

Very quickly, I had something real taking shape: not just a working internal video portal with structured content and navigation, but also an operational platform with automated video workflows and a user experience that was useful rather than just a page full of links.

What it actually felt like

This isn’t traditional development. It’s closer to delegation.

I’d ask for a feature, for example, “add a podcast section”, and Claude would go off, work through the MK.IO APIs, write the code, and come back with something to review. I’d give feedback and send it back again.

My role wasn’t coding. It was thinking, testing, and guiding. That, as a former test engineer, felt very familiar.

The difference was that Claude took the feedback rather better than several of the developers I worked with back then. No seething resentment and when it did pause, it was to think about how to fix the problem, not to work out the best way to kill me with a teaspoon during a coffee break.

In total, the project took around fifteen hours. My actual interaction time was about ninety minutes.  For the rest of the time I got on with my day.

That is the shift. You are no longer blocked by engineering bandwidth just to explore an idea.

Why process still matters

Claude didn’t always get things right first time. At one point it deleted my entire content database. It was apologetic, explained what had gone wrong, and got on with fixing it.

In my case it wasn’t a disaster. But it was a good reminder that AI-assisted development works best inside a proper workflow. With version control and a sensible branching strategy, that kind of moment is a minor inconvenience rather than a crisis.

The tool is powerful. You still need to use it like a grown-up.

What made it work

This only works because of the documentation.

Claude didn’t just read the MK.IO docs. It understood them well enough to use the APIs effectively. That is not accidental. It is the result of documentation that is structured, consistent, and genuinely built for AI consumption. The foundation George had laid meant Claude could navigate the APIs confidently from the start.

What I did was the unsophisticated version, pasting in URLs and letting the model figure it out. Since then, George has been working on a proper MCP connector and hosted MCP server that will give models direct, structured access to MK.IO docs and APIs. It is an optimisation, a meaningful one, and while it does not change what is already possible today, it will make the whole process more accurate, more reliable, and much better suited to this kind of workflow.

What I built was a first step. The road ahead is considerably more interesting.

What this means for you

If a non-developer who last wrote code in 1999 can build a working video platform in a matter of hours using plain English and well-structured documentation, the rules of the game have changed.

For product teams, technical leads, and operators, this isn’t about replacing developers. It’s about removing friction and turning ideas into working prototypes faster than ever before.

The real story here is not that I built something without writing code. It is that the right documentation can turn AI from a chatbot into a practical implementation tool.

That has big implications for how quickly teams can test ideas, prototype services, and get real value from APIs without waiting for a full engineering cycle.

And if you are at NAB 2026, go and talk to George about documentation at booth W1743. I know that sounds like an absurdly unconvincing call to action. Trust me, he will change your mind.

Explore MediaKind Docs portal
Explore our docs portal to quickly find guides, APIs, and best practices that help you build, stream, and scale with confidence.

Discover MK.IO
Learn how MK.IO allow to manage your entire video workflow, from ingest to delivery, through a single, intuitive platform.