There has arguably never been a better time to have an idea for a software product.

Until recently, turning an idea into something people could actually use usually meant assembling a development team, finding a meaningful budget and accepting that months might pass before anyone outside the company touched the product. By the time you discovered whether customers wanted it, you could already have invested a considerable amount of money in finding out.

AI has changed that calculation.

Today, a founder can describe a product in ordinary language and watch an AI coding agent begin assembling it. A login page, customer dashboard, subscription flow, search feature, notification system or admin panel can appear remarkably quickly. The process is conversational: move this button, add another option, make this work on mobile, fix the error. The software changes almost as quickly as the idea does.

This style of development is often called vibe coding, and despite the slightly unserious name, its implications are significant. Small teams can now build and test ideas that would once have required a much larger investment. A product can move from a sketch in someone’s head to something customers can actually use in days or weeks rather than months.

For an early-stage business, that is enormously valuable. It also creates a new problem.

At some point the prototype begins to work. People create accounts. They return. Perhaps they invite colleagues. Eventually, some of them start paying. And almost without anyone noticing, the most important question about the product changes.

It is no longer simply: Can we build this?

It becomes: Can we depend on it?

That is the point at which production engineering starts to matter.

An MVP is supposed to prove the idea, not the infrastructure

There is nothing inherently wrong with software being built quickly with AI. In many cases, it may be one of the most rational ways to build an MVP.

The purpose of an MVP, after all, is not to prove that a company can create perfect software. It is to answer much more important commercial questions. Do people understand the idea? Will they use it? Will they come back? Will anyone pay for it?

AI makes it possible to answer those questions without first making an enormous investment in engineering. That changes the economics of experimentation. Instead of spending months preparing a product for a market that may not care, companies can put something in front of customers, learn from their behaviour and adapt quickly.

Problems arise only when the first version succeeds and everyone continues treating it as though nothing has changed.

A small café offers a useful analogy. On its first day, perhaps ten customers walk through the door. One person can take the orders, make the coffee, collect payments and remember who asked for oat milk. The system works perfectly.

Then the café becomes popular.

There are suddenly 300 customers a day, delivery drivers waiting at the door, online orders arriving on a tablet and three people trying to use the same till. The original process has not suddenly become foolish. It simply belongs to a different scale of business.

Software behaves in much the same way. The architecture that was perfectly adequate for validating an idea may become increasingly fragile once thousands of people begin depending on it.

And this is where the reassuring phrase “it works” can become misleading.

A product may look perfectly healthy from the outside. Customers can create accounts. They can upload information. They can make payments. The screens load and the buttons do what they are supposed to do.

Yet none of this tells you what happens when 1,000 people arrive at once. It does not tell you whether a payment provider sending the same confirmation twice will result in a customer being charged twice. It does not tell you whether one user can accidentally access another user’s data, whether your backups can actually be restored, or whether anybody will know when a critical background process stops running at three in the morning.

It certainly does not tell you whether a system that feels fast with 2,000 database records will still feel fast with two million.

These are not signs that the MVP was badly built. They are simply questions the MVP was never designed to answer. Its job was to prove value. Once customers begin relying on it, the definition of “working” becomes much broader.

AI can build faster than organisations can understand

There is another complication that is particularly relevant to agentic coding: software can now evolve faster than the people responsible for it can form a complete mental picture of how it works.

Imagine building a house through a series of instructions.

Add another bedroom. Put a balcony here. Move the kitchen downstairs. Add a bathroom beside the new bedroom. Extend the living room.

Suppose every instruction could be carried out within minutes. The experience would feel miraculous.

After the fiftieth change, however, somebody might reasonably ask where the pipes now run, whether a particular wall is load-bearing or why the house seems to have acquired three separate electrical panels.

Nobody deliberately designed a bad house. It simply evolved very quickly.

AI-built software can develop in the same way. Each individual request is perfectly logical. Add subscriptions. Add team accounts. Add an integration. Add permissions. Add reporting. Add another customer type.

The coding agent keeps extending the product, usually solving the immediate request in front of it. What it does not automatically provide is the kind of long-term architectural judgment that asks how those decisions interact across the entire system.

Eventually, someone has to stop thinking about the latest feature and start thinking about the product as a whole.

That, in large part, is what production engineering is for.

What production engineering actually means

The phrase can sound intimidating, particularly to non-technical founders. It suggests large infrastructure teams, complicated diagrams and engineers discussing things nobody else in the room understands.

The basic idea is much simpler: take software that already works and make sure it can be trusted.

That means looking beneath the interface and asking questions that were less urgent during the experimentation stage. Is customer information protected properly? Can the application recover when something fails? Are certain parts of the code becoming unnecessarily complicated? Can the system comfortably support ten times as many customers? Are important events being recorded so problems can later be investigated?

It also means creating safeguards around future development. A product that changes every week needs automated checks capable of detecting when a new feature unexpectedly breaks an old one. The deployment process should allow teams to release changes without turning every update into a small gamble. There should be monitoring capable of showing when the product is unhealthy and enough documentation for another engineer to understand what has already been built.

This is not an exercise in making the software academically perfect.

Perfect software is an expensive and frequently imaginary goal. Production engineering is instead about identifying the failures that would become costly if the company continued growing and addressing those risks before they become emergencies.

The distinction matters because success changes the consequences of failure.

A bug affecting five test users is inconvenient. The same bug affecting 5,000 paying customers can become a business incident.

Weak security around dummy data is relatively unimportant. Weak security around customer documents, payment information or confidential company data is something else entirely.

And while restarting an application during an investor demonstration may be embarrassing but survivable, asking a business customer to refresh the page while the system they rely on remains unavailable is a rather different experience.

The software itself may not have become worse. The stakes have simply become higher.

The sensible response is usually not to rebuild everything

For companies reaching this stage, one of the worst possible conclusions is that their AI-built MVP must now be discarded and rewritten from scratch.

Sometimes a rewrite is necessary. Often it is not.

The existing product contains something more valuable than elegant code: accumulated knowledge. It reflects months of discovering what customers want, which features they ignore, how the workflow should behave and where the original assumptions were wrong. In successful cases, it may also contain real customers and real revenue.

An engineering team that arrives and immediately proposes replacing everything has probably skipped an important step.

The first job is to understand what is actually there.

Perhaps the payment flow is fragile, but the rest of the application is perfectly serviceable. Perhaps access controls need to be strengthened. Perhaps the database is likely to become a bottleneck. Maybe there is almost no automated testing, or monitoring is so limited that failures can go unnoticed for hours.

Those issues can be prioritised.

Keep the parts that work. Strengthen the parts that matter. Replace components when there is a clear reason to do so.

The aim is not to transform an MVP into the world's most elegant piece of software. It is to make continued success less dangerous.

This approach is also economically more sensible. A startup that has just proved customer demand rarely needs to disappear into a six-month engineering project. It needs to keep serving those customers while gradually improving the foundations underneath them.

Production engineering, done well, should enable growth rather than interrupt it.

Moving beyond vibe coding does not mean abandoning AI

There is an odd assumption hidden in some discussions about AI-generated software: that eventually “real engineers” arrive and take the AI away.

That is unlikely to be how modern software development works.

AI remains useful throughout the process. Engineers can use it to write tests, inspect existing code, identify repetitive patterns, generate documentation, investigate bugs and accelerate routine development work. It can continue writing features too.

What changes is not the presence of AI. What changes is the environment around it.

During the MVP phase, an instruction might simply be: Add subscriptions.

Later, that same request needs context. Add subscriptions using the existing payments architecture. Follow the company’s security requirements. Handle duplicate notifications correctly. Test the main failure scenarios. Make sure failed transactions generate an alert.

AI is still doing useful work, but it is now operating within boundaries created by engineering judgment.

That distinction is important. Generating software and engineering a product are related activities, but they are not quite the same thing.

One optimises for producing a result quickly. The other also considers what happens to that result tomorrow, six months from now, under unexpected load, after a developer leaves, when a third-party service fails or when a new customer uses the system in a way nobody anticipated.

The more important the product becomes, the more those questions matter.

AI has changed where companies should spend their engineering effort

The traditional startup journey placed a great deal of expense at the beginning.

Companies needed meaningful engineering resources simply to discover whether an idea was worth pursuing. Much of that investment happened before there was any convincing evidence that customers wanted the product.

Agentic coding allows a different sequence.

A company can start with an idea, build an AI-assisted MVP, put it in front of real users and collect evidence that the product solves a meaningful problem. Only then, once that evidence exists, does it make sense to invest more heavily in reliability, security, scalability and maintainability.

In other words, the journey increasingly looks like this:

Idea → AI-built MVP → Real users → Proof of demand → Production engineering → Growth

This is not an argument for doing less engineering. It is an argument for applying engineering at the right time.

Before product-market evidence exists, speed and learning matter enormously. The ability to discard an unsuccessful idea cheaply is a feature, not a failure. Companies should experiment. They should use AI aggressively. They should build things that might not survive.

But when one of those experiments begins to work, the situation changes.

It is no longer simply an experiment.

It is becoming a business.

And businesses eventually need systems their customers can rely on.

The next generation of successful software may begin messily

There will undoubtedly be a great deal of poorly built software created with AI over the next few years.

There will also be companies that would never have existed without it.

The important distinction will probably not be between businesses that used AI and businesses that did not. AI-assisted development is likely to become too common for that distinction to remain particularly useful.

The more interesting question will be what companies did after AI helped them find something valuable.

The strongest teams will not spend months polishing products nobody has asked for. They will use AI to reduce the cost of finding out what customers actually want.

But neither will they assume that the first version which finds traction should carry the business indefinitely.

They will recognise the point at which speed needs to be joined by reliability; when experimentation begins to require security; when “it works on my laptop” needs to become monitoring, backups, testing and recovery; and when a rapidly assembled collection of useful features has to become a system that people can genuinely depend on.

That may be one of the most important consequences of AI-assisted software development.

AI has dramatically shortened the distance between “I have an idea” and “It works.”

Production engineering addresses the next distance: from “It works” to “We can depend on it.”

An AI-built MVP does not need to apologise for how it was created. Nor does it necessarily need to be thrown away, rebuilt from scratch or separated from the tools that helped create it.

If it has reached the point where customers rely on it, it has already done exactly what an MVP was supposed to do.

Now it simply needs the engineering that comes with success.