← Back to the blog
27 October 2026

Okay, But Actually… An AI Subscription Is Not a Development Process

Okay, But Actually… An AI Subscription Is Not a Development Process

Someone on one of Pedro's posts said people buy access to an AI tool and suddenly act as if they know how to develop software.

I use AI. Please remain calm. Do not run. Do not alert the authorities. We will get through this together.

There is a fair concern hiding inside the insult. People can generate code they do not understand and put it online. A working demo can now be made very quickly, including by someone who has no idea what will happen when real customers, payments and staff accounts arrive.

None of this proves that Pedro, I or anyone else is building that way. Seeing an AI subscription tells you about as much as seeing a laptop on the desk. The interesting part is what happens between the first prompt and the finished app.

The demo is the easy part

Say a business needs an app for paid workshops. An AI tool can help build a booking form, save the customer details and connect a payment service. The developer may have something impressive to show within days.

Now two customers try to book the final place at the same time. One payment succeeds, but the booking confirmation fails. Another customer presses the payment button twice. A staff member moves someone to a different date after the class is already full.

What should the app do in each case?

Developers often call situations outside the normal expected journey edge cases. The normal journey here is one customer choosing one workshop, paying once and receiving one booking. Real customers and internet connections are not always that cooperative.

The name can make these situations sound like tiny technical curiosities. A customer who has been charged without receiving a place will not consider herself an interesting event at the edge of the system.

AI can suggest answers and help write the code. It can help create tests too. Somebody still has to decide which behaviour is right for this business, check what the tool produced and make sure the app does not sell the same seat twice.

The client is not paying a developer to discover whether a prompt can produce a booking form. We know it can. The client is paying for the judgement around all the annoying situations that were not visible in the pretty demo.

I am not going to pretend AI is useless

The better AI coding tools have become, the stranger it sounds when people use “they probably have an AI account” as a complete review of someone's work.

I use AI to explore approaches, write repetitive parts, find mistakes, create tests and document what I built. It can catch things I missed. It can also produce an answer that looks completely reasonable and is wrong.

That is why the developer still needs to understand the app, inspect the changes, run it and test what happens outside the happy path. If I accept the work and put it into a client's app, it is my responsibility. “The AI wrote it” would be a particularly embarrassing support policy.

OWASP's guidance on coding with AI makes the same point: AI-assisted changes need a human owner who reviews and approves them. The tool does not take responsibility for the software it produces.

The client does not need to read the code

A business owner should not need to conduct a technical interview or inspect a repository to find out whether a developer knows what they are doing.

Pick one important part of the app and ask the developer to explain it in normal language. If customers pay through the app, ask what happens between pressing the payment button and receiving confirmation. What happens if part of that process fails? Can staff see the problem? Can they fix it without charging the customer again?

Ask to see those situations tested. The answer does not need to involve a forty-page security report and a ceremonial gong. The developer can demonstrate a failed payment, a duplicate click and an attempted booking when no places remain. A client can understand whether the result makes sense without understanding the code behind it.

The client can also check who owns the hosting, database and payment accounts, where changes are recorded, how important records are backed up and what support exists after launch. These answers say far more about the work than whether the developer used AI while producing it.

The US National Institute of Standards and Technology's secure development framework describes software development as a collection of practices across the life of the product. It covers preparing people and processes, protecting the software, producing it carefully and responding when problems are found. It does not define quality by counting how many characters a human typed without assistance.

The UK's National Cyber Security Centre also recommends testing throughout development. Code does not become trustworthy because somebody wrote every semicolon personally.

Buying established software does not answer this either

An established product has history, documentation and a company responsible for it. Those things can make it easier to assess. They do not prove that nobody used AI to build it, and nobody seriously checks a software supplier by asking whether its developers typed every line themselves.

The same applies when a consultant builds workflows inside a subscription platform. They may use templates, AI and automated tools to work faster. Fine. The client still needs to know whether the booking process works, what happens when it fails and who can repair the setup later.

Somehow, AI assistance becomes evidence of incompetence only when the software is custom. Put equally complicated logic inside a familiar platform and the method used to build it stops inspiring dramatic speeches about software engineering.

Ask how the work is done

I am happy to tell clients that I use AI. I am not going to hand them a pile of prompts and call it a development process.

Ask what the developer needed to understand before building. Ask how they tested the important parts, what happens when an outside service fails, who owns the accounts and who will help after launch. A good developer should be able to answer without burying the client in terminology.

If the only evidence is an impressive demo and “the AI says it works,” walk away. If the developer understands the business, can explain their decisions, tests the awkward cases and remains responsible for the result, the existence of an AI subscription is not the scandal somebody hoped it would be.

Want a site like this?

Take a look at the packages, or just say hello.

See the packages →