Fresh

April 14, 2026wwcpro

AI can put a decent-looking landing page on screen in about the time it takes to refill your coffee. That part is real. The part nobody puts in the demo video is what happens in the two hours after that first draft appears, which is where the actual job now lives.

A lot of agencies are cagey about how much AI is in their process. That is a shame, because the honest version is more useful (and frankly more interesting) than either the hype or the hand-wringing. The tools are in the room. What matters is how they get used, what they get wrong, and who is on the hook when they do.

Where AI is genuinely pulling weight

The real wins are less flashy than the demos and bigger than most people expect.

Exploration is the big one. Early in a project, the expensive part is not building. It is deciding. When a designer can put six credible directions on the table in an afternoon instead of two over a week, the conversation with a client changes shape. You stop debating an idea in the abstract and start reacting to something you can see. Weak directions die faster. Strong ones get pushed further, because there is budget left to push them.

Production work is the second one. Once a direction is locked, a huge share of the remaining effort is repetitive and unglamorous. Component variants. Responsive states. Loading and empty states that used to get skipped because the deadline ate them. Alt text first drafts. Data migrations. Test coverage. None of that is where craft shows up, and all of it takes hours. Handing the first pass to a machine and spending the saved time on the parts a person actually notices is a straight upgrade for your project.

Third, AI is a fast way through unfamiliar territory. Reading a client's legacy codebase, working out an API with thin documentation, translating a design file into working components. It shortens the runway.

The failures are quiet, not loud

Here is the part that gets glossed over. AI does not fail like a broken tool. It fails like a confident intern, which is much harder to catch.

Hallucinated code. Generated code will reference functions that do not exist, options that were never in the library, or a package that nobody ever published. It reads perfectly. Sometimes it even runs, and then falls over on an edge case in production. Anything that is not exercised by a test or a human clicking through it is a live grenade.

Brand drift. Models trend toward the average of everything they have seen, so left unattended they drift toward generic. The same rounded cards, the same gradient, the same three-column section. If your business paid to look like nobody else, a fast draft that looks like everybody else is a step backward, not a shortcut.

Accessibility that looks fine and is not. This one comes up constantly. Generated markup often renders beautifully and fails in practice. A div styled to look like a button that a keyboard cannot reach. Text contrast that misses the standard by a hair. Form fields with no label attached. Modals that open and send focus somewhere unhelpful. It passes a glance and fails a real user.

Security shortcuts. Generated code tends to take the shortest path to working, which is not the safest path. API keys sitting in the browser bundle. Missing input validation on a form. Database rules that are permissive because permissive is easier. Every line touching data, payments, logins, or user input needs a human security pass. No exceptions.

Rights on generated assets. This is the one that keeps lawyers busy. Ownership rules for AI-generated images are still settling, and they vary by jurisdiction and by the terms of the specific tool. A generated texture behind a headline is low risk. A generated hero image containing something that resembles a real person, a real product, or a trademarked logo is a different conversation. Trademark and likeness law does not care how the file was made.

Maintainability debt. Code can work today and still be a problem in eight months. Six near-identical components where one flexible component belonged. Clever patterns nobody on the team can explain. If your site is a long-term asset, and it is, the code has to be something a human can pick up and change.

Over-trusting the first draft. All of the above compounds because the output sounds so sure of itself. A junior developer hedges. A model does not. That confidence is the single biggest risk in the whole workflow.

Guardrails that actually make this work

None of that argues for avoiding the tools. It argues for a process. The practices below are what separate a fast, solid build from a fast mess.

  • Start from the design system, never a blank prompt. Feed the model your real tokens, type scale, spacing, and existing components. Constraint is what keeps output on brand.
  • Treat every generated file as a pull request from a talented, sleepy junior. A human who could have written it reviews it line by line. If nobody on the team understands it, it does not ship.
  • Test accessibility by hand. Automated checks catch some of it and miss plenty. Someone needs to tab through the page, use it without a mouse, and check contrast against the real backgrounds.
  • Security review anything touching data. Forms, authentication, payments, database rules, third-party keys. Every time, no matter how small the change looks.
  • Set an asset policy before the project starts. Decide what may be generated (backgrounds, textures, concept exploration) and what must be photographed, illustrated, or licensed. Write it into the deliverables.
  • Ask for less per request. Narrow, specific asks produce reviewable output. "Build the whole page" produces something that has to be untangled.
  • Keep a record. Note where generated assets and code were used. Future you will want that list.

What to ask the people building your site

You do not need to audit anyone's tooling. A few plain questions tell you plenty. Where does AI sit in the process, and where does it deliberately not? Who reviews the output before it reaches your site? What is the policy on generated imagery and rights? Does any of this change the estimate or the timeline?

A team with a real process answers specifically and without flinching. A team that either denies using AI or credits it for everything is telling you the same thing, which is that nobody has thought it through. The WWC team is happy to walk through exactly where that line sits on a given project, because the conversation tends to build trust rather than spend it.

The practical takeaway

AI moved the bottleneck. It did not remove it. When producing a first draft costs almost nothing, the value shifts entirely to judgment, review, and accountability. The question worth asking is no longer whether your agency uses these tools. It is whether they have built the review habits that make the speed safe.

So look for evidence of the boring stuff. Accessibility checked by a person. Security reviewed on every data path. Brand rules enforced instead of hoped for. Clear ownership of every asset on the page. Get that foundation right and AI becomes what it should be, which is more exploration, faster revisions, and more of your budget spent on the work your customers actually notice.