They Built the Dinosaurs. They Forgot to Engineer the Park.

What Jurassic Park understood about AI-assisted software development three decades before vibe coding existed.

There is a scene in Jurassic Park that feels as though it was written for the current age of artificial intelligence.

Ian Malcolm is sitting around a table while John Hammond proudly explains what his scientists have achieved. Hammond sees discovery, progress and possibility. Malcolm sees something else: power acquired without the discipline traditionally required to attain it.

His objection is not that the scientists failed. It is that they succeeded before they understood the consequences of their success.

They stood on the shoulders of geniuses, accomplished something extraordinary as quickly as they could, packaged it—and began selling it.

That is vibe coding.

It is also the premise of the entire film.

Jurassic Park has already been built, but its existence is not enough. After a worker is killed, the people financing the park demand independent scrutiny. Hammond brings in domain experts because the project will not proceed on spectacle and his assurances alone. It needs to be inspected, understood and endorsed by people capable of recognising what he may have missed.

At first, the park looks almost impossible to reject. It is a scientific marvel presented with confidence, theatre and technology that appears to work perfectly. Hammond expects wonder to become approval.

Instead, Grant, Sattler and Malcolm remain sceptical. They ask questions the presentation does not answer. As they move deeper into the park, its polished claims progressively give way to unexamined assumptions, concentrated dependencies and systems that cannot survive contact with reality.

The arc of Jurassic Park is a due-diligence process conducted too late.

It did not require any discipline to attain it

AI has democratised the ability to create software. Someone with little conventional development experience can now describe an idea and, within hours, have something that looks remarkably close to a finished product.

It can have authentication, a dashboard, a database and a payment button. It can generate polished interfaces and enough functionality to survive a demonstration.

That is an extraordinary achievement.

It is also where the danger begins.

The barrier to generating software has collapsed. The complexity of operating software has not.

A system still has to survive malformed input, duplicate submissions, concurrent users, third-party failures and requirements nobody identified at the beginning. It must protect customer data, preserve financial history and behave predictably when the ideal path collapses.

AI can produce code without requiring its operator to learn why those problems matter. It can provide the output of engineering without automatically providing the judgement that makes the output dependable.

That distinction is becoming dangerously easy to ignore.

The gates opened. That did not make the park safe.

The modern software demonstration is seductive.

A customer chooses a product. They enter their details. They press a button. A success message appears.

It works.

But what does works mean?

Does the checkout prevent a duplicate order if the customer presses twice? What happens if payment succeeds but the order fails to persist? If two customers purchase the final unit simultaneously, which one owns it? If a courier becomes unavailable, does fulfilment fail visibly or disappear into a silent error?

None of these questions are especially impressive in a demo. They are the system.

The interface is only the visitor centre. The engineering is in the fences, the contingency plans and the knowledge of what happens when the power goes out.

This is particularly obvious in e-commerce because software is coordinating money, stock, customers and fulfilment. A small inconsistency can become an oversold product; a retry, a duplicate charge; a convenient plugin, a critical dependency nobody understands.

The customer sees a checkout button. The business inherits everything behind it.

The market is selling the lunchbox

This distinction became impossible for me to ignore while trying to market ORM Development.

Again and again, I encounter business owners asking for what they describe as a website or an app. Beneath those words are product variations, personalisation, payments, international shipping, inventory and fulfilment.

They are not really describing a website. They are describing a commerce operation.

Yet the typical response immediately reduces that operation back into visible features: choose a platform, install plugins, connect a gateway and strap automation onto the existing stack. Fixed price. Quick turnaround. Everything working.

Often, a price is offered before a single question has been asked about how the business works.

Nobody asks whether personalisation changes price or refund eligibility, when inventory should be reserved, or what happens when payment succeeds and order creation fails. International shipping is treated as a plugin rather than an operation involving currencies, tax, couriers and exceptions.

Each requirement is priced as an isolated checkbox because each has a purchasable component carrying the same name.

That is not necessarily dishonesty. Frequently, it is a failure to perceive the system hiding behind the interface.

The result is a market in which a configured storefront and an engineered commerce platform are compared as two price points of the same product. To a business owner without technical experience, both proposals appear to contain variations, payments and shipping. The engineering only becomes visible when something fails, the business changes or supposedly independent features interact.

By then, the inexpensive build may already be processing real money, storing personal data and shaping the daily operation.

This is the lunchbox problem. The visible capability has been packaged and made easy to sell before either party fully understands what has been created.

The provider sells the presence of features. The owner believes they have purchased the behaviour of a system.

Those are not the same thing.

The discrepancy becomes dangerous because a significant part of a developer's role is to hold the technical understanding that the business owner reasonably does not. The owner understands the operation; they should not need to understand transaction isolation, authentication boundaries or database invariants to commission dependable software.

The developer's responsibility is to translate one form of understanding into the other. They must turn operational intent into system behaviour, identify where the requested workflow contains risk and explain the consequences of technical decisions the owner is not equipped to evaluate alone.

That relationship works when each party contributes different expertise and discovery creates a shared model. It fails when the owner cannot evaluate the implementation and the developer cannot explain it. The owner knows what the platform should do. Generated code determines what it actually does. Nobody understands the discrepancy between them.

Communication, requirements work and domain modelling are therefore not administrative overhead. They make responsibility possible. A developer cannot protect rules they never discovered, and an owner cannot approve consequences nobody explained.

This is why discovery matters.

Discovery is not writing down a feature list and feeding it into a model. It is an informed investigation into the operation, led by somebody who recognises which questions need to be asked.

How can somebody discover concurrency requirements if they do not know concurrent state changes are dangerous? How can they investigate payment recovery if they do not understand that payment and order creation can succeed independently?

AI can generate a discovery questionnaire. It cannot guarantee that its operator understands the answers, notices a contradiction or recognises the significance of something the owner mentions in passing. It cannot compensate for somebody who lacks the mental model required to know when the conversation has exposed risk.

A prompt operator can reproduce the requirements a client already knows how to express. An engineer discovers the requirements neither party had articulated yet.

Much of development's value lives in the questions asked before code exists and the assumptions challenged before they become architecture.

If the full reach of someone's technical understanding is knowing how to prompt AI for an output, their discovery process can only be as deep as the prompt they know to write. The unknown unknowns remain unknown, and are then embedded into the product.

A responsible estimate begins with questions. The person who makes the project sound more complicated may be the only person who has recognised its actual complexity.

The uncomfortable questions are not obstacles to the sale. They are evidence that somebody is thinking about what happens after the gates open.

When the park goes offline

Jurassic Park is presented as a triumph of automation. From one control room, a remarkably small team can operate an entire island: security, transport, communications, tours and containment.

Dennis Nedry knows what that achievement cost. In one of his most revealing moments, he argues that the whole park can be run from that room with minimal staff. He points to millions of lines of code, limited computing resources and the difficulty of keeping every connected system alive at once.

He is defensive, bitter and ultimately destructive. However, he is not wrong about the complexity.

The park has confused automation with resilience.

Its efficiency depends on concentrated knowledge and access. When Nedry becomes unavailable - and then hostile - the organisation discovers that it has not removed its dependency on human expertise. It has compressed that dependency into one person.

In engineering, this is the bus-factor problem: how many people can disappear before a system can no longer be understood or safely operated? Jurassic Park's answer is one.

It is also a failure of defence in depth. One person can disable critical systems, with neither effective redundancy nor a team capable of restoring control. The park appears highly automated, but its automation has enlarged the blast radius of a single failure.

Modern businesses make the same mistake when they celebrate that one employee, one agency or one AI conversation can run everything. A lean system is valuable. A system nobody else understands is fragile.

Generated software can make that fragility worse. If the person deploying it cannot explain its architecture, then the organisation may have no genuine owner of the system at all. The knowledge exists somewhere between a model's output, an undocumented prompt history and code that everybody assumes somebody else understands.

At that point, AI becomes the bus factor.

That is more dangerous than depending on Nedry. Nedry may feel underappreciated and underpaid, and he is capable of bringing the park to its knees, but he at least understands what he built. He can diagnose it, reason about limited resources and explain what will happen when part of the system is taken offline.

An AI model is not a maintainer waiting on the telephone. It may not retain the context that produced the system, and it cannot own an incident or guarantee that tomorrow's answer will preserve yesterday's assumptions. If no human understands the code, the organisation's bus factor is not one. In any meaningful sense, it is zero.

Automation should reduce repetitive labour. It should not remove the people, documentation, access controls and recovery plans required when the automation fails.

The real test of an automated system is not how little attention it needs while everything is working. It is how safely the organisation can recover when the park goes offline.

The people who understand the raptors

Hammond understands what the dinosaurs represent commercially. Muldoon and Grant understand what they are capable of.

That difference matters.

To Hammond, the raptors are another extraordinary attraction to be contained and displayed. To the people who have studied predators, their behaviour is the central fact. They test boundaries. They learn. They coordinate. A fence is not proof of control merely because it held yesterday.

Software domains behave in a less cinematic but similarly unforgiving way. Consider inventory management.

From outside the domain, inventory appears to be a number beside a product. Add stock when it arrives. Subtract stock when something sells. Display the result.

To somebody who has engineered the domain, that number is the result of movements, reservations, concurrent checkouts, cancellations, returns and fulfilment. Each transition has consequences elsewhere.

Treating inventory as a database field because the interface makes it look simple is Hammond looking at the enclosure and assuming the animal has been understood.

The same applies to payments, tax, shipping and refunds. These are not features sitting politely beside one another. They are domains with behaviours, invariants and failure modes. The people closest to them often sound cautious because they can see the boundaries being tested long before leadership sees a breach.

Good engineering listens to the Muldoons and Grants. It does not dismiss domain expertise because the dashboard still looks calm.

You selected them because they looked good

Sattler identifies the same failure elsewhere in the park. Some of its plants are poisonous. They were selected because they looked right in the environment, while their actual behaviour within that environment was ignored.

That is a software decision made every day.

A library is selected because it produces the desired component quickly. A plugin is selected because its screenshots match the brief. An AI-generated interface is accepted because it looks polished and moves convincingly during the demonstration.

Nobody asks what else arrived with it.

What permissions does it require? How does it store data? What happens when it is updated, abandoned or forced to share a workflow with another component?

The component was chosen for what could be seen. Its operational behaviour remained unexamined.

This is how software becomes filled with dependencies that are individually attractive and collectively toxic: competing for state, damaging performance and quietly expanding the system's security boundary.

The interface may look like the park Hammond intended to present. The domain expert sees the poisonous plants surrounding the visitors.

Appearance is evidence of presentation. It is not evidence of suitability.

How do you control what you do not understand?

When Henry Wu explains that every dinosaur in Jurassic Park is female, he presents the decision as a security control. Their chromosomes were engineered. A hormone was withheld. Unauthorised breeding was therefore impossible.

Malcolm responds with the question that exposes the weakness in the entire park: How do you know?

Wu knows what the system was designed to do. He mistakes that design intent for proof of what the system is actually doing.

Software teams make the same mistake constantly.

The application was designed to reject unauthorised access. The payment integration was designed to process each request once. The code was generated to satisfy the prompt.

But did it?

Control is not a statement of intention. It requires understanding, observation and evidence. It requires knowing which assumptions the system depends upon, how those assumptions can fail and what signals would reveal that reality has diverged from the design.

If nobody understands the generated code, they cannot reliably challenge its assumptions. If they cannot observe its behaviour, they cannot know when it escapes its intended boundaries. If they cannot explain why a safeguard works, they cannot know which change will silently remove it.

A passing demonstration is not evidence of control. Neither is an AI response saying the implementation is secure.

Tests provide evidence; monitoring reveals behaviour; documentation preserves intent. Engineers connect those signals to a mental model and decide whether the system is still behaving safely.

Without that understanding, asking AI to maintain the product becomes an exercise in repeatedly modifying a black box. Each change may appear successful while weakening an invariant nobody knew existed.

You cannot govern what you cannot understand. You cannot verify what you cannot observe. You cannot recover what nobody owns.

Jurassic Park's animals did not respect the boundaries their creators had specified. Software will not respect ours simply because they appeared in the prompt.

They filled in the gaps

The dinosaurs could not be reconstructed from complete DNA, so Jurassic Park's scientists filled the missing sequences with frog DNA. The shortcut completed the immediate task: it produced viable animals.

It also changed the behaviour of the system.

The borrowed DNA carried capabilities the designers had not accounted for. Under the right conditions, the supposedly all-female population could reproduce. The material used to fill a gap quietly invalidated one of the park's central security assumptions.

AI fills gaps too.

Requirements are rarely complete, yet generated code must still choose an implementation. When the prompt does not define a rule, the model infers one from patterns, conventions and surrounding context.

The blank does not remain blank. It becomes an assumption embedded in the product.

That assumption may be perfectly plausible and still be wrong for the business. Worse, it can import behaviour that conflicts with rules elsewhere in the system while satisfying the visible request that prompted it.

This is why shortcuts cannot be judged only by whether they complete the immediate feature. Every substitute carries behaviour. Every inferred requirement becomes a business decision, whether anybody consciously made it or not.

The danger is not simply that AI may misunderstand an instruction. It is that the output can look complete precisely because the missing understanding has been concealed by a plausible answer.

The frog DNA filled the sequence. It also gave life a way around the park's controls.

Chaos does not ask permission

Malcolm's chaos argument completes the analogy.

Complex systems are sensitive to tiny differences in their starting conditions. A small change does not always remain small. It can travel through connected components, interact with other state and produce an outcome that could not be inferred by looking at the change in isolation.

Commerce systems are full of these interactions.

A delayed payment notification arrives after a retry. A reservation expires as fulfilment begins. A courier accepts a shipment while the local update times out. Each event may be valid; their ordering creates the failure.

This is why a collection of working features does not automatically become a dependable system. Product variations, personalisation, payments, tax, inventory and international shipping may each function correctly alone. Once connected, they create paths and states that no single screenshot can demonstrate.

Engineering cannot eliminate uncertainty, but it can design for it. Transactions preserve invariants within critical boundaries, idempotency makes retries safe, and audit trails make failures diagnosable and reconciliation possible.

The goal is not Hammond's fantasy of absolute control. It is a system that remains understandable and recoverable when reality behaves differently from the demonstration.

Standing on the shoulders of geniuses

All modern software stands on earlier work. Its languages, databases, operating systems and libraries let us build what no individual could create from first principles.

That is not a weakness. It is how engineering advances.

AI is the newest and most powerful layer of abstraction in that history. It can explain unfamiliar code, accelerate implementation and help one developer operate with extraordinary breadth.

I know because I use it.

I have spent more than 2,000 hours building a custom e-commerce platform, with AI beside me for much of the process. It has accelerated my work, challenged decisions, exposed blind spots and widened the range of problems I could tackle.

But it did not remove the work.

It did not decide where transactional boundaries belonged, protect inventory under concurrency or own the consequences of payment succeeding while checkout failed. It could propose implementations; it could not take responsibility for which one belonged in the system.

Most importantly, it could not be accountable.

AI helped me build the dinosaurs. The 2,000 hours went into engineering the park.

When nobody takes responsibility for the dinosaurs

The problem with vibe coding is not that AI writes code. Human-written code can be insecure, brittle and badly designed. Generated code can be thoughtful, elegant and correct.

The problem is the removal of visible friction.

Traditional development forces people through enough difficulty to discover that software is full of consequences. That experience does not guarantee competence, but it often teaches caution.

When a system can be generated before its creator has encountered those lessons, confidence develops faster than judgement.

Experimentation is healthy. The problem begins when the experiment is packaged as a product, connected to real money and customer data, and sold with promises its creator cannot evaluate.

When it fails, responsibility is displaced onto the model, framework, plugin or customer.

But tools cannot accept responsibility. The person who chooses to deploy the system must.

Power without accountability was Malcolm's warning. It remains the warning now.

The dinosaurs are digital. The consequences are real.

Imagine a surgeon who can perform an operation by following generated instructions but does not understand anatomy. Or an architect who can produce beautiful plans without understanding load paths, material behaviour or why the building remains standing.

Nobody would describe either person as innovative. We would describe them as dangerous.

Their tools and outputs may be extraordinary. But producing an incision or drawing is not evidence of the knowledge required to take responsibility for a patient or structure.

Software is too often judged through a different lens.

If an application launches and completes its happy path, its creator is treated as having successfully built it. Data modelling, security, failure recovery and operational ownership are dismissed as concerns for later.

They are not optional when a system handles personal data and money—still less when it controls high-risk operations in healthcare, transport or infrastructure.

Computer science may not always produce a physical object whose failure can be seen immediately, but software failures have physical, financial and human consequences. A leaked record cannot be made private again. A corrupted financial history cannot always be reconstructed. A failed control system does not care that its interface looked finished.

We would not accept "the model generated it" as a defence from a surgeon or an architect. We should not accept it from the person who deploys consequential software.

AI can extend professional capability. It cannot confer professional competence upon somebody who is unable to evaluate its work.

Build the dinosaurs. Engineer the park.

There is a reasonable place for vibe coding.

Use it to explore an idea, build a prototype or test a workflow where the consequences of failure are contained. Let AI remove boilerplate and accelerate implementation.

But the moment software becomes responsible for someone else's money, data, livelihood or operation, the standard changes.

At that point, somebody must understand the architecture and the invariants it can never violate. Somebody must test failure paths, observe production behaviour and explain why the system can be trusted.

That is engineering.

It is slower than generating a demonstration because reality is slower than a demonstration. It includes the work invisible in a screenshot: transactional boundaries, audit trails, monitoring, recovery and tests proving yesterday's feature still works after tomorrow's change.

I am not opposed to AI-assisted development. I am opposed to offloading understanding, accumulated expertise and professional responsibility.

Use AI to carry more of the workload. Do not ask it to carry the knowledge that makes the work safe.

AI should make that engineering more capable. It should not give us permission to pretend it is unnecessary.

I will not endorse your park

Hammond's park was visually extraordinary. The gates opened. The vehicles moved. The presentation convinced its visitors that the impossible had been made manageable.

At first glance, it looked too good to be true.

It was.

The experts do not reject the park because they lack imagination. Their expertise lets them see beyond the demonstration: Grant understands the animals, Sattler the ecosystem and Malcolm the refusal of complex systems to remain inside neat boundaries.

With every layer they peel back, confidence becomes less defensible. Population control, automation, security and the operational model fail. The scientific marvel degrades into assumptions that were never subjected to enough scrutiny.

By the end, Grant tells Hammond that he will not endorse the park. Hammond no longer argues. Exposure to the reality of his own system has given him the same answer.

This is the lifecycle of many vibe-coded products compressed into one film.

In the film, the cost of discovering the truth is measured in characters' lives. In business, failure is less cinematic but not harmless: lost revenue, corrupted records, operational disruption, legal exposure and personal data placed in systems incapable of protecting it.

That makes the failure financial, legal and ethical. Not merely technical.

And in healthcare, transport, infrastructure or other high-risk environments, even that distinction disappears. Software built without understanding can still carry a human cost.

The first demonstration can look revolutionary. The interface is polished, the core journey works and its speed of creation feels like proof that software's old cost and difficulty have been defeated. A business owner may reasonably see exactly what Hammond saw: an extraordinary capability ready to open.

Then somebody with genuine domain credibility begins asking questions.

They inspect authentication rather than noting that a login page exists. They follow payment and order state through failure rather than watching one successful checkout. They examine ownership and recovery rather than assuming AI can generate another patch.

The product does not become fragile because an expert inspected it. The inspection makes its existing fragility visible.

And once the business owner understands the discrepancy between what they believed they had purchased and what the system can actually guarantee, they are likely to reach Hammond's conclusion themselves.

The failure was not in creating the dinosaurs.

The failure was confusing creation with control—and presentation with proof.

That is the mistake the software industry now risks repeating at enormous scale. We can create faster than ever. We can package ideas before we understand them and sell systems before we have accepted responsibility for their behaviour.

The answer is not to reject AI. It is to recover the humility its power requires.

Use the model. Generate the code. Accelerate the work. Then apply the discipline: understand it, challenge it, test it and take responsibility for it.

The question is no longer whether AI can build the software.

It can.

The question is:

Has anybody engineered the park?