AI Can Build Websites Now. But It Still Needs Someone to Lead.

A few years ago, asking an AI to build a complete website was usually an efficient way to create a mess.

It could generate a respectable landing page. It knew enough HTML and CSS to produce something that looked convincing in a screenshot. It could explain JavaScript, write isolated components and suggest fixes for errors.

But the moment the work involved an existing project, current platform conventions, multiple files, real business requirements or decisions that had to remain consistent across an entire website, the cracks appeared.

The AI forgot earlier instructions. It invented functions that did not exist. It confidently used outdated structures from major platforms. It changed one component while breaking another. It solved the visible problem without understanding the system around it.

It was useful, but clumsy.

That has changed remarkably quickly.

Modern coding agents can inspect repositories, edit many files, execute commands, run tests, use external tools and continue working on tasks that would once have required a long sequence of manually coordinated prompts. OpenAI describes Codex as a software-engineering agent capable of building features, fixing bugs, answering questions about a codebase and proposing changes from within an isolated development environment.

That is a substantial change.

It does not mean that AI can be released into any project without supervision. It means that the limiting factor is shifting. The question is no longer simply whether AI can write code.

The more important question is whether someone has created an environment in which the AI can do useful work.

From generating snippets to working inside systems

The first generation of mainstream AI coding assistance mostly worked at the level of suggestions.

You described a button, function or page. The model generated code. You copied it into your project, discovered what was wrong and returned with another prompt.

It behaved like a very fast sidekick with an unreliable memory.

Tools such as GitHub Copilot already demonstrated that this assistance could improve speed. In a controlled GitHub study, developers using Copilot completed a programming task substantially faster than the control group. But that generation of tooling was still mostly assisting a person who remained responsible for every step of implementation.

Current agents operate differently.

They can receive a broader objective, inspect the project, locate relevant files, make coordinated changes and validate parts of their own work. The SWE-bench project was created to measure whether language models can resolve real software issues taken from actual GitHub repositories. Early systems solved only a small fraction of those tasks. More recent agents perform dramatically better, although benchmark results still need to be interpreted carefully.

The change is not that AI suddenly became infallible.

The change is that it gained a working loop:

Understand the request.
Inspect the environment.
choose an action.
use a tool.
observe the result.
correct the approach.
continue until the task is complete or blocked.

OpenAI calls this the agent loop: the system that coordinates the model, its instructions, its tools and the feedback it receives while working.

That loop is what turns a chatbot into something closer to a working agent.

The breakthrough was not just better code

A modern AI model can usually produce better code than its predecessors. But code generation alone does not explain the progress we have seen.

The real breakthrough is that AI can increasingly work with context.

That context may include:

the structure of a repository;
existing components and design patterns;
project documentation;
database models;
naming conventions;
coding standards;
previous decisions;
screenshots and visual references;
test results;
business rules;
instructions stored inside the project.

This changes the nature of collaboration.

Instead of asking:

“Create a website for my business.”

we can give an agent:

an existing repository;
a defined technical stack;
a component library;
a visual system;
content models;
acceptance criteria;
rules about what it may and may not change;
commands for testing its work.

The result is not guaranteed to be good. But it is operating inside a system rather than improvising the entire project from a vague sentence.

Anthropic describes a similar principle in its guidance for Claude Code: strong results depend on giving the agent ways to inspect the codebase, verify its work and understand the environment in which it operates. Its work on context engineering also emphasises that agents should retrieve the information they need at the moment it becomes relevant instead of trying to hold an entire organisation’s knowledge in one enormous prompt.

This is why “prompt engineering” is becoming too narrow a description.

The real work is increasingly context engineering and system design.

AI is fast enough to build the wrong thing at remarkable speed

The most dangerous misconception is that increasing autonomy removes the need for human direction.

It does the opposite.

Imagine hiring an extraordinarily fast construction team. The team can work day and night. It can acquire materials, operate machinery and complete many tasks in parallel.

But there is no architect, no agreed plan and no inspection process.

The speed of the team does not protect the project. It magnifies every unclear decision.

AI behaves similarly.

It can implement a poor architecture quickly. It can create dozens of inconsistent components instead of one reusable system. It can optimise for a feature that should never have existed. It can faithfully apply the wrong business rule across an entire project.

And because the output often looks professional, the error may not be immediately obvious.

A polished interface is not evidence of a sound product.

Working code is not evidence of a maintainable system.

Passing one test is not evidence that the business requirement was understood.

This is where human responsibility remains essential.

Someone still needs to decide:

what the website is supposed to achieve;
who it is for;
how content should be structured;
which technologies are appropriate;
what should remain simple;
what risks are acceptable;
what must be verified manually;
when the AI is solving the wrong problem.

AI can increasingly execute a plan.

It still should not be trusted to invent the entire plan without challenge.

How we use AI at Vayluna

At Vayluna, we do not use AI as a button that supposedly produces complete businesses.

We use it as an operating layer across projects.

That can include:

inspecting and rebuilding an existing website;
creating reusable page structures;
organising content collections;
translating and adapting content between markets;
analysing product data;
generating first drafts of visual and editorial assets;
checking technical consistency;
documenting workflows;
researching markets and competitors;
creating internal tools;
preparing content for articles and video.

Our work on InstantTraveling is one example. AI can assist with research, information architecture, content systems, technical implementation and repeatable production workflows. But it cannot decide on its own what makes a travel guide useful, which mainstream conventions should be rejected or what editorial voice the project should have.

Those are human decisions.

The same applies when rebuilding an ecommerce project such as VaySafe. AI may inspect a product catalogue, identify inconsistent data, create templates or implement a defined structure. It still needs an operator to determine which products belong, what customers need to understand and which commercial priorities matter.

The valuable part is not asking AI to “make a site.”

The valuable part is dividing the work intelligently:

Human responsibility

define the objective;
choose the architecture;
set priorities and limits;
provide business context;
recognise trade-offs;
approve consequential decisions;
perform final quality control.

AI responsibility

inspect;
implement;
compare;
transform;
test;
document;
repeat;
surface inconsistencies.

The clearer that division becomes, the more useful the agent becomes.

We stopped relying on one enormous prompt

A common way to use AI is to write an increasingly long prompt describing everything the model should know.

That works until it does not.

Instructions conflict. Important details become buried. Old context remains present after it is no longer valid. The model gives attention to the wrong part of the prompt. The user assumes the AI remembers a decision that was never stored anywhere reliably.

A stronger workflow places important knowledge inside the project itself.

That may include:

a clear README;
architecture documentation;
design tokens;
reusable components;
examples of accepted output;
project-specific instructions;
automated tests;
structured content schemas;
checklists for completion.

OpenAI’s own description of agent-first engineering makes the same broader point: teams increasingly need to design environments, specify intent and create feedback loops that allow agents to perform reliable work.

In other words, the quality of the result depends on more than the intelligence of the model.

It depends on the harness around it.

Autonomy begins after architecture

The phrase “autonomous AI” can create the impression that the human disappears.

In useful real-world work, autonomy usually begins only after someone has reduced ambiguity.

An agent can work for a considerable period without constant intervention when it knows:

what success looks like;
where the relevant files are;
which commands it may use;
which rules are non-negotiable;
how to test the result;
when it must stop and ask for a decision.

That is not unrestricted autonomy.

It is delegated autonomy inside a controlled framework.

This is similar to managing a capable employee. Micromanaging every keystroke wastes the employee’s ability. Giving them no objective or boundaries creates avoidable risk. The goal is neither total control nor total freedom.

The goal is a well-defined area of responsibility.

Where AI still fails

The progress is real, but so are the limitations.

AI coding agents can still:

rely on outdated documentation;
misunderstand the current structure of a platform;
invent APIs, settings or dependencies;
overlook edge cases;
introduce security problems;
modify files outside the intended scope;
solve a symptom rather than the underlying issue;
report completion while important work remains unfinished;
produce plausible but unsupported claims;
preserve a bad architectural assumption because it was present in the original request.

Benchmarks cannot fully remove this uncertainty. Research has also warned that formal software benchmarks may overestimate performance in everyday interactive development, where requests are less precisely written and environments are messier than a carefully prepared test.

That should not be read as evidence that agents are useless.

It is evidence that verification remains part of the job.

The correct response to AI fallibility is not to reject the tool. It is to build review, testing and evidence into the workflow.

Does this remove the need for developers?

No.

But it changes what valuable development work looks like.

Less time may be spent manually writing repetitive code. More time can move towards:

architecture;
product judgement;
systems thinking;
security;
user experience;
verification;
integration;
understanding the business behind the software.

For smaller businesses, the effect may be even more significant.

A founder or operator with limited technical ability can now participate much more directly in building software. They can explain the business problem, review visible results and guide priorities while an agent performs work that previously required far more manual implementation.

That does not instantly turn every founder into a senior engineer.

It does reduce the distance between an idea and a working first version.

The people who benefit most will not necessarily be those who know the cleverest prompt. They will be the people who understand their problem well enough to define a useful system around the AI.

The website is not the product of one prompt

A modern website can now be built with an extraordinary amount of AI assistance.

AI may help generate its code, content, visual assets, translations, tests and documentation. It may independently complete defined tasks across a repository. It may even discover and repair some of its own mistakes.

But a good website is still the result of choices.

What should be said?

What should be left out?

What does the visitor need first?

Which interaction creates confidence?

Which technology is appropriate?

What can fail?

What should never be automated?

Those questions cannot be delegated blindly.

AI has moved from being a clumsy sidekick to becoming a capable execution partner. That is real progress, and it has happened faster than most people expected.

But the strongest results do not come from letting it run loose.

They come from giving it something worth following.

The future of AI-assisted development is not a blank prompt followed by a finished company.

It is a human defining the architecture, building the feedback loops and setting the standard—then allowing AI to do more of the execution than was previously possible.

That is how we use it at Vayluna.

Not as a substitute for direction.

As a multiplier once direction exists.