The work is the qualification

I’ve spent decades building things for the web. A considerable amount of that has been my own time: evenings spent trying an idea, weekends working through a problem, and experiments that never became a product but taught me something I still use.

That experience shapes how I look at the current rush to become qualified in AI.

I understand wanting a structured place to start. A good course can introduce useful ideas, challenge assumptions and help someone get moving. But when I’m deciding whether someone can build or operate something, the certificate tells me very little on its own.

Show me what you’ve done with it.

Show me something that works beyond the demonstration. Explain the decisions, the limitations and what happened when somebody used it in a way you hadn’t anticipated. Show me the second version, after the first met reality.

That is where I start paying attention.

Hours matter when they leave something behind

There is a kind of understanding that comes from spending a lot of time with the work.

You recognise a familiar failure hiding behind unfamiliar terminology. You know which questions to ask before changing a system. You can look at an impressive output and spot the missing permission check, the fragile dependency or the assumption that will cause trouble later.

Those instincts develop through repeated contact with consequences.

Hours alone aren’t a qualification either. You can spend years repeating the same mistakes. What matters is what the time produces: better judgement, stronger work, useful experiments and an ability to explain why something should be done a particular way.

My own unpaid learning has been a large part of that. Following a question because I wanted to understand it. Building a tool because the existing process annoyed me. Going back to something I thought I understood and discovering another layer.

That work rarely comes with a badge. It does leave evidence.

AI makes judgement more visible

An assistant can help produce code, explore an interface or turn a rough idea into a working prototype. That gives us more opportunities to try things and less reason to leave every idea sitting in a notebook.

It also makes the quality of the decisions around that output more important.

Does this belong in WordPress? Would a static site do the job? Does the form actually deliver the enquiry? Who can access the saved data? Can the next person maintain it? What happens when the release needs reversing?

These are the questions I bring to my work on AceHost. Connecting an assistant to hosting tools through MCP is useful because it lets the workflow include real site context and defined operations. The value comes from how those operations are built, scoped and checked.

That is the practical side of the MCP workflow I wrote about recently. The connection is one component. Someone still has to understand the system around it.

A badge can become an appeal for relevance

I’m less persuaded when the qualification becomes the main story.

There is a point where repeatedly announcing that you are ready for the future starts to sound like an attempt to establish relevance. I would rather see what you have already contributed to it.

There is a difference between learning to read a wave and being carried along in its wake. From a distance, both can look like forward movement. The difference becomes apparent when conditions change.

For those of us who have spent decades building, breaking, repairing and maintaining things, this is another period of learning. We still have to do the work. Experience doesn’t excuse us from testing a new tool or questioning an old habit.

It does give us something useful to bring to the experiment.

And a newcomer who can show thoughtful, working results deserves to be taken seriously too. I would apply the same standard regardless of age, job title or qualifications.

Make the evidence easy to inspect

If you want to demonstrate expertise, publish the useful parts of the work.

Explain a decision. Share a tool. Document a failure and the correction. Show what improved and how you checked it. Be clear about what is running, what is experimental and what still needs attention.

You don’t have to expose client information or publish every line of code to make your judgement visible.

The future of development should put more weight on that evidence. What can you build? What can you improve? What can you keep working? What have you learned well enough to pass on?

I’ll keep putting my time into answering those questions.