Claude Can Build the Website. It Can't Build the Understanding. Not Yet.

AI has made software dramatically cheaper to generate. It has not made architecture, verification, or business understanding optional.

Claude and Cursor are genuinely excellent products.

I use these tools myself, and I think they are a real preview of where software development is heading. A landing page, a prototype, a small internal tool, even a surprisingly capable first version of a product, can now be produced in an afternoon.

That part isn't hype.

What has changed is the cost of getting from an idea to something that works. What hasn't changed is what happens after that.

A working demo and a working business are different things.

The gap between them is where most AI-built projects eventually become interesting.

WHERE PERETZ FITS

A Note on Where Peretz Actually Fits

This isn't a description of what we do at Peretz. Generating a landing page or a template corporate site through AI in an afternoon isn't our profile, and it's not what we compete on.

What we actually build is custom e-commerce platforms, landing pages, corporate websites, and the kind of business architecture covered elsewhere on this site, the parts of a business genuinely too complex, too specific, or too strategically important to hand off to a single prompt.

This article isn't a pitch for what we sell. It's an honest look at where the broader market actually stands, as of September 2026. AI tooling in this space moves fast enough that some of this could read differently by November. That's not a hedge. It's just accurate.

COST OF GETTING STARTED

AI Changed the Cost of Getting Started

For a simple website, AI can remove an extraordinary amount of friction. You can describe a layout, generate the components, refine the copy, connect an API, change the styling, add another page, and iterate again before a traditional development process would have finished its first planning cycle.

For prototypes, this is even more powerful. Something that previously required a developer, a designer, and several rounds of communication can now be explored by one person in an afternoon.

That matters. It changes the economics of experimentation. It means more people can test ideas that previously would have remained ideas.

But it also creates a new problem. When the cost of producing the first version falls dramatically, the first version starts looking deceptively close to the finished product.

It isn't.

PROMPT NOT SPECIFICATION

A Prompt Is Not a Specification

There is a specific pattern I keep seeing. Someone copies a prompt from an "expert," pastes it into Claude or Cursor, gets something that looks impressive, and stops. The interface exists. The buttons work in the demonstration. The page looks finished. So the project feels finished.

But a prompt is a starting instruction, not a specification. A specification describes what the system actually has to do. Those are very different things.

A prompt might say: build a booking system for a consulting business.

A specification has to answer questions like: who can create a booking, what happens when two people select the same time, where availability is stored, what happens when a payment fails, whether an administrator can modify a booking, what happens when a customer cancels, which system is the source of truth, who receives notifications, what happens when an external service is unavailable, and what should happen six months from now when the business changes the workflow.

The prompt can generate the beginning. It cannot decide what the business actually means by "booking system." That understanding has to come from somewhere.

CODE WORKS SYSTEM DOESNT

When Code Works but the System Doesn't

This is where AI-generated software can become deceptive. Individual pieces can work perfectly. A form can submit. An API can respond. A component can render. A database can contain records. An authentication flow can work.

And yet the system can still be poorly designed.

Without architectural thinking behind the build, AI-generated code can tend toward the same problem that appears in hurried human development: pieces that technically work, stitched together without a coherent model underneath. One part follows one pattern. Another part follows another. A new feature introduces another data structure. An integration is added directly to the component that needs it.

Nothing is obviously broken. Until the business changes. Then the seams appear. The tenth page is harder than the first. The second integration is harder than the first. Changing one workflow unexpectedly breaks another. A new content type requires rewriting several unrelated pieces.

Every addition costs more than the last one because the system was never designed to absorb change.

Implementation makes individual pieces work. Architecture determines whether the pieces can continue working together as the business changes.

AI PATCHES SYSTEM

When AI Patches a System It Doesn't Understand

There's a specific variant of this worth naming on its own, because it doesn't involve building anything from scratch at all.

A site that was genuinely well built at some point goes quiet for a while, nobody touches it, content stops getting updated, features stop shipping. Then someone picks it back up, and starts filling gaps and adding features with Claude or another AI system. The work continues on the old codebase, which is still coherent, still maintained, still fine on its own terms.

What I keep noticing is a specific shape of technical debt that accumulates fastest exactly here: a patch written in Python, bolted onto a site actually built in PHP, because that's what the model reached for by default, and nobody caught the mismatch before it shipped. It isn't extending the original system. It's creating a second, unrelated one sitting next to the first, held together by whatever glue code gets patched in next to make them talk to each other.

One patch like that is survivable. A pattern of them, patch after patch, each in whatever the model defaulted to that day, each stitched on with its own workaround, is how a genuinely solid old site quietly turns into something nobody fully understands anymore, including the person who's been adding to it the whole time.

NOT ALWAYS CHEAP CLIENTS

It's Not Always the Cheap Clients

Worth naming clearly: it isn't only people looking for the cheapest possible route who end up here. Some of the projects I've seen this happen to weren't low-budget or unmotivated at all. They were people who genuinely wanted to learn, who had real money to spend, and who assumed one project would be enough to figure it out.

The result is a familiar shape. An HTML shell exists, but nobody knows what to do next. There's no admin panel. Forms look connected in the interface but don't actually send data anywhere, and the person who built it genuinely believed it was finished. Only once someone sits down to write a real specification based on what already exists does it become clear that the original idea was something else entirely, that the build had quietly drifted from the actual intent somewhere along the way, and nobody caught it because nobody had the vocabulary to notice while it was happening.

That's not a story about laziness. It's a story about underestimating how much a single project can actually teach a non-technical person about what they're building, and about how invisible that drift is from the inside when you don't yet know what questions to ask.

SOURCE OF TRUTH

The Source of Truth Problem

One of the questions AI-generated projects often avoid is deceptively simple: where does the truth live?

A customer might exist in a CRM. An order might exist in an ecommerce platform. A payment might exist in Stripe. An email subscription might exist somewhere else. Analytics may contain another version of the customer journey. The website may have yet another representation of the same information.

Those systems can all work individually. But a business still needs to know which system owns what.

That is architecture. And when the answer is unclear, adding another integration doesn't solve the problem. It usually makes it larger.

DEMO NOT ENVIRONMENT

The Demo Is Not the Environment

A demo has a happy path. A real product has users, and users do things the demo never showed. They submit empty fields. They double-click buttons. They lose their connection. They use Safari. They upload the wrong file. They return six months later. They use a phone nobody tested. They trigger two processes at the same time. They do something the original prompt never anticipated.

We caught exactly this kind of issue on our own site recently. A CSS rule written for portfolio galleries and hero images, elements that always sit inside containers with fixed heights, was unintentionally applying to ordinary images inside article content. Chrome and Firefox degraded gracefully. Safari rendered those images at their native pixel size instead, visibly cropping them. Nobody designed that bug. Nobody would have discovered it from the original implementation. Someone had to actually use the system in a different environment.

New hardware keeps adding fresh versions of the same problem. Foldables and unusual viewport configurations introduce behavior that older responsive assumptions were never designed around. A site built and checked on exactly one device has no way of knowing whether it holds up on any of this.

That's what verification is for.

VERIFICATION CORE SKILL

Verification Is the New Core Skill

The hard part of building with AI was never writing the prompt. Generation has become cheap. Verification has not.

Does the form actually send the data. Where does that data go. What happens when the request fails. Does the integration fail loudly or silently. What happens when the input isn't exactly what the demonstration assumed. What happens when the user does something the model wasn't asked to anticipate.

The chat window shows you the happy path. Everything else is what verification is actually for.

This changes the role of the person building with AI. You don't necessarily need to write every line of code yourself. But you do need enough understanding to interrogate what the model produced. You need to know what questions to ask, what looks suspicious, and what "working" actually means.

FIRST VERSION CHEAPER

AI May Make the First Version Cheaper

There is a common argument that building with AI is simply cheaper than hiring a developer. Sometimes it is. For a landing page, it probably is. For a prototype, it often is. For a small internal tool, it can be dramatically cheaper.

The calculation changes when the software becomes a business system. Because now you are not only paying for generation. You are paying with your own time to understand the problem, learn how the generated system works, verify it, debug it, maintain it, write and edit the content, understand analytics, learn the basics of search, manage deployment, and make decisions when the model gives you several technically plausible answers.

Add that time honestly and the economics can look very different.

But that doesn't make the experiment pointless. Quite the opposite. You may have learned something valuable that no course could have taught you. You now understand more about your own system. Your next project may be much better because of it.

And that is probably the most underrated benefit of building with AI: it can make learning by doing dramatically cheaper. The mistake is assuming that because generation became cheap, understanding became unnecessary.

WHO OWNS SYSTEM

Who Actually Owns the System?

There is another question that becomes more important as AI makes software easier to generate. Who owns the thing you just built?

Not just the source code. Who owns the repository, the domain, the hosting account, the database, the API credentials, the analytics, the deployment process, the data model, and the knowledge required to maintain it, exactly the ownership map covered in what you own vs what you're renting. And who can make a meaningful change six months from now.

The source code may exist. The application may run. But if only one person understands how everything fits together, the business may still have a dependency it cannot see.

AI doesn't eliminate that dependency. Sometimes it makes it easier to create.

QUESTIONS BEFORE BUILD

The Questions Worth Asking Before You Build

You don't need the perfect prompt. You need better questions. Before generating the first line of code, work through these.

Before You Ask AI to Build It

1. What exactly is this system supposed to do? Not what should the homepage look like. What business process is the system actually responsible for?

2. What does the owner need to change without touching code? Content, products, users, pricing, workflows?

3. Where does the data actually live? What is the source of truth?

4. What happens when an integration fails? A production system cannot assume that every API will always respond.

5. Who owns the infrastructure? Domain, hosting, repository, database, credentials, analytics.

6. How will the system be verified? Not just whether the demo works. Whether the system works when reality stops following the demo.

7. What happens when the business needs its tenth feature? This is where architecture becomes visible.

8. What happens when the person who built it is no longer available? That is where technical ownership becomes a business question.

AI Can Generate vs. What Someone Still Has to Design

AI VIDEO DEMO LOUDER

The AI Video Demo Is the Same Story, Just Louder

Social media is full of AI-built websites presented through polished AI-generated videos. The production quality can be genuinely impressive.

But a polished demonstration proves one thing: that something can be made to look real. It doesn't prove that the underlying system exists in a form that can operate, evolve, or be maintained.

The same distinction applies to generated websites. A beautiful screen is evidence of production. It is not evidence of architecture.

DIDNT REMOVE ENGINEERING

AI Didn't Remove Engineering. It Moved It.

This is probably the most important shift. For years, software development was constrained heavily by the cost of producing code. AI is attacking that constraint directly, and that is a very good thing.

But as code generation becomes cheaper, other parts of the process become relatively more important: requirements, architecture, data, verification, security, operations, content, measurement, maintenance.

The scarce resource is moving. The ability to generate software is becoming widely available. The ability to understand what software should exist, how it should fit together, and whether it actually works is still much harder.

REAL OPPORTUNITY

The Real Opportunity

This is why I don't think the interesting question is whether AI can build a website. It obviously can.

The more interesting questions are what kind of website should exist, what business system sits behind it, what the company actually needs to own, what happens when the business changes, and who understands the system when the demo is long gone.

AI has made the first version dramatically easier to produce. That is the opportunity. It means more businesses can experiment, more founders can test ideas, more teams can build internal tools, and more people can turn a concept into something tangible before spending heavily on development.

But the lower cost of generation makes the distinction between a generated artifact and a real system more important, not less.

A prompt can produce code. It cannot decide what the business should become. It can generate an interface. It cannot take responsibility for the system behind it. It can produce a convincing demo. It cannot tell you whether the business will still work when the demo ends.

None of this is a claim that AI can't eventually understand context and intent far better than it does today. That gap is real, and it will keep closing, probably faster than most predictions suggest.

But right now, at this stage, what AI actually does is amplify. Put it in the hands of someone who already thinks like an architect, or who genuinely wants to understand what they're building, and it becomes a real force multiplier, doing in an afternoon what used to take weeks. Put it in the hands of someone chasing the illusion of fast and cheap, hoping to skip understanding entirely, and it won't deliver what they actually wanted. At least not yet.

AI made building cheaper. It did not make understanding optional.

Can Claude or Cursor actually build a working website?

Yes, especially for landing pages, simple sites, prototypes, and small internal tools. The gap is what happens after the first version works: architecture, hosting, data, verification, maintenance, and search visibility.

What is the difference between an AI-generated prototype and a production-ready system?

A prototype demonstrates that an idea can work. A production system has to survive users, data, failures, maintenance, security, deployment, change, and time.

Is building a site with AI actually cheaper than hiring a developer?

Sometimes. For simple projects and prototypes, often substantially. The economics change when you include the time required to understand, verify, maintain, and operate a real business system.

Why does AI-generated software often feel stitched together as it grows?

Because without architectural thinking, each new addition can follow its own pattern. It may work at small scale while becoming increasingly expensive to extend.

What should someone ask before generating a site with AI?

Where it will be hosted and who maintains it, what the owner needs to change without touching code, where the data lives, which integrations matter, how failures are handled, how the system will be verified, and what happens as the business grows.

Are AI-generated video website demos actually a new technique?

The production quality has improved substantially, but a polished demonstration is not evidence of a production-ready system. It demonstrates what can be generated, not necessarily what can operate, evolve, or be maintained.