Expertise and experience still matter, perhaps more than ever.
Artificial intelligence has changed the way people think about building for the web. Tools like Claude, Lovable, and others have made it easier than ever for anyone to generate a design, spin up a prototype, or produce a block of code in seconds. That’s genuinely exciting, and we use AI tools ourselves every day.
But there’s a growing gap between what AI can generate and what a website actually needs to succeed. At KMDG, we’re seeing that gap widen in real time, and it’s worth talking about honestly.
“We had Claude build it.” And then we got the call.
Barely a week goes by without a client sending us something they had AI generate: a new page layout, a feature widget, a redesigned section they’d like dropped into their existing site. And we love the enthusiasm. The problem is almost never the idea. It’s the execution.
Here’s what we see consistently: the person who built the AI design wasn’t in the marketing department. They were in operations, or ownership, or IT. They had a vision, they prompted their way to something that looked great on a screen, and they sent it over.
What they didn’t have in front of them was the brand guide. Or the accessibility checklist. Or the legal requirements the site is obligated to meet. So what arrives is a design that uses the wrong fonts, off-brand colors, and layouts that don’t scale to mobile, wrapped in a pile of HTML and JavaScript that’s nearly impossible to maintain.
We’ve had cases where something as simple as updating a button link required us to put the client’s own files back through Claude just to get the code cleaned up enough to edit. That’s not a knock on AI. It’s a sign that AI-generated code, without professional oversight, creates technical debt fast.
Branding, accessibility, and compliance aren’t optional extras
When a design gets generated outside the marketing team, a few things tend to get missed. They’re not small things.
Brand consistency is the first casualty. A site that’s been carefully built around a specific color palette, typography system, and visual language doesn’t benefit from a new section that ignores all of that. It creates a disjointed user experience that quietly erodes trust.
Accessibility is a legal and ethical requirement, not a nice-to-have. WCAG compliance governs contrast ratios, keyboard navigation, screen reader compatibility, and more. AI tools don’t automatically produce accessible code. A human with expertise has to review, test, and ensure the output meets the standard.
Legal requirements (including Consent Management Platform integration) are equally non-negotiable. A cookie consent mechanism that doesn’t function correctly, or that conflicts with a new widget’s scripts, can expose a business to real liability. AI doesn’t know your site’s compliance configuration.
To help bridge this gap, we’ve built an internal widget that allows us to take AI-generated designs and code and properly integrate them into a client’s existing website environment, accounting for their CMS, their CSS framework, their brand system, and their compliance setup. It’s not about rejecting AI output. It’s about making it actually work in the real world.
The gap between ability and expertise
Something important has shifted with AI, and it’s worth naming directly.
Previously, building something in code required at least a working understanding of how that code functioned. The act of writing it was inseparable from understanding it. AI has changed that completely. Code can now be generated by someone with no understanding of how it works, why it’s structured a certain way, or what could go wrong when it meets a real production environment.
For mockups and prototypes, that’s completely fine. Getting an idea on screen quickly has real value. But production code is a different matter entirely. Code that runs on a live website, handles user data, integrates with third-party services, or sits inside a complex CMS needs more than a working first draft. It needs someone who understands what it’s doing and can take responsibility for what happens next.
This is where engaging an expert can mean the difference between a tool that works and a liability waiting to surface.
The quality of AI output is also directly shaped by the expertise of the person guiding it. An experienced developer doesn’t just ask AI to write code. They give it existing code as a starting point. They provide structured data for reference. They direct it to conform to established coding standards and work within frameworks they’ve already built and tested. They review every line the AI produces and make changes where needed. The result is code that is solid, maintainable, and debuggable. Not just functional on the surface. Not just code that runs, but code that lasts.
Less experienced users often don’t know what to ask for, which means they don’t know what to look for in the output either. The prompt shapes the product, and expertise shapes the prompt.
When experience solves what AI cannot
AI is genuinely impressive at troubleshooting. It can work through problems methodically, try multiple approaches, and cover a lot of ground quickly. But there are categories of problems that can only be solved by someone who has encountered them before.
During development of one of our internal plugins, an issue surfaced that appeared to be caching related. Early in the process, we suspected that the actual cause was a highly specific interaction between Advanced Custom Fields and WordPress’s metadata cache. When an ACF value is changed during post saving, it can spontaneously revert later in the same request because the cache for that value never gets updated. The fix is to clear the meta cache after making the change. It’s an obscure issue, the kind that doesn’t appear in documentation and isn’t something you’d reason your way to. The only reason our team knew how to fix the issue was because they had seen it before.
Rather than intervene immediately, we decided to let the AI keep working. It was a genuinely difficult problem to debug, and we were curious whether it would find its way there on its own. It took on the troubleshooting with everything it had: logical steps, progressive testing, increasingly targeted attempts to isolate the cause. It did everything right. After nearly three hours, it had not found the answer.
Once we provided the solution, the AI immediately understood what to do with it and implemented it correctly. But without the experiential knowledge to identify the root cause, it was simply spinning through three hours of impressive, well-structured, yet ultimately unproductive troubleshooting.
This isn’t a failure of AI. It’s an illustration of what experience actually provides that AI currently cannot replicate: pattern recognition built from years of encountering specific, real-world problems in specific, real-world environments.
Just because you can build it doesn’t mean you should
This is the lesson we keep coming back to, and one recent client experience illustrates it better than anything.
A client came to us excited about a tool they’d built using AI. The concept was smart: a system that would allow their stakeholders to upload a list of customers, analyze the data, surface useful insights, and suggest social media content. They built it, it worked, and they were ready to roll it out across their network.
There was just one problem. Several, actually.
The tool worked by sending customer data through an API to a third-party AI service. That data was never encrypted or anonymized. The customer information being uploaded (names, contact details, behavioral data) was moving through an external service without any of the security controls that kind of data requires. The client hadn’t considered it because the tool worked. It did the thing it was supposed to do.
It also hallucinated. When stakeholder data was incomplete (and it often was, because there was no validation layer requiring complete records) the AI filled in the blanks. Not with educated estimates. With made-up information, presented as fact. A social media post built on fabricated customer data isn’t just ineffective. It’s a liability.
And then there was the nature of the data itself: some of the customer records involved minors. That layer of the situation brought with it an entirely different set of legal and ethical obligations that the tool, as built, was completely unequipped to handle.
The tool wasn’t bad. The idea wasn’t bad. But it was built without the security review, the data governance framework, and the compliance awareness that a system handling real customer data demands.
AI amplifies capability. It also amplifies risk.
The same quality that makes AI tools so powerful (their speed and accessibility) is what makes them risky without professional guidance. They lower the barrier to building things. But they don’t lower the barrier to building things well.
At KMDG, we’re not anti-AI. We use it to work faster, think through problems, and serve our clients better. But we also know where it ends and where expertise begins. Strategy, brand stewardship, security architecture, accessibility compliance, and legal awareness aren’t things a prompt can replace.
When you bring AI into your web projects, the question isn’t just “can we build this?” It’s “should we build this, and are we building it right?”
That’s what we’re here for.
Have questions about how to responsibly integrate AI tools into your web presence? Get in touch with KMDG.