9 min read

Can you build an app with AI? What the tool does on its own, and when to bring in a professional

Sébastien Nobour

Founder of DEVEDANOS

Solutions

Yes. You describe an app in a few sentences, and an AI tool produces a first version of it: screens, forms, a database, a link to open it. When it comes to testing an idea, that is a big change.

The useful question comes right after. Can this app take payments? Keep your customers’ data? Serve your users every day, for years? This is where the answer depends less on the tool than on what is done around it.

Which AI can build an app?

Three kinds of tools answer that question.

AI app builders. You describe what you want in a chat. The tool generates the app, hosts it and puts it online, without you writing a single line of code. They are the ones filling the first page of Google for this search.

Chat assistants. Can ChatGPT build an app? It writes the code, piece by piece, and explains it. Assembling it, installing it on a server and putting it online is up to you.

Coding assistants, built into the developer’s working environment. They write, change and test code when the developer asks. They are aimed at developers, and developers use them: nearly 90% of the technology professionals surveyed for the 2025 DORA report use AI in their work. The report comes from DORA, Google Cloud’s research programme on how software is built and released to production.

Vibe coding: building an app without reading the code

Building an app by describing what you want, without reading the code the AI writes, has a name: vibe coding. The term comes from Andrej Karpathy, an AI researcher, in a post published in February 2025. He describes a way of programming where you accept every suggested change without reading it, and paste the error messages into the chat until it works. He says himself that this suits throwaway side projects, the kind you hack on over a weekend.

Developer Simon Willison drew the distinction that matters here. Vibe coding is building with AI without reviewing the code it produces. When a developer reviews the code, tests it, and can explain every line to someone else, that is software development. AI-assisted, but software development.

What the tool does well on its own

Testing an idea. Showing a screen to a business partner, a customer or a future user before committing a budget. Building a small internal tool, used by a handful of people, that handles neither money nor personal data.

Allen Holub puts it plainly: vibe coding has its place for throwaway prototypes. The word that matters is “throwaway”. A prototype is there to learn something. Then you throw it away.

Where the tool stops

An app that works during a demo has proven one thing: it works during a demo. Holub lists what “it works” does not guarantee: security, data protection compliance, scalability and service availability when many users log in, backups, how easily it can be changed. For a business, five points matter most.

Security

Security vendor Veracode had more than 100 AI models write code for 80 tasks where a secure or an insecure solution could be chosen. In about 45% of cases, the code contained a security flaw. Newer models do no better than older ones on this point.

On the public showcase of one AI app builder, an engineer analysed 1,645 published apps. In 170 of them, about one in ten, anyone could view their users’ data: names, email addresses, financial information.

Personal data

As soon as an app stores names, addresses or information about your customers or employees, the GDPR applies. The company that collects this data must protect it with technical measures appropriate to the risk (Article 32). If there is a breach, it must report it to the supervisory authority (the CNIL in France), where feasible within 72 hours (Article 33). Fines can reach 20 million euros or 4% of worldwide annual turnover, whichever is higher (Article 83).

This obligation falls on the company that collects the data. It is the same whichever tool wrote the code.

Payments

To take a payment, an app goes through a payment provider. The tricky part comes next: the provider tells the app that a payment has been received, and the app has to check that the message really comes from the provider. Without that check, anyone can send a fake message and get an order shipped. The provider can also send the same message twice, and the app must record it only once. Payment providers say so in their own documentation, Stripe and Adyen alike.

In a demo, nobody makes a real payment. So these problems do not show up.

Maintenance

An app lives in production. It has to keep up with security updates, with changes in your business, with requests from your users. Maintenance means continuously adjusting the app as those needs change. You have to understand what needs to change, then fit it into the existing app without breaking what works.

Allen Holub says what an AI would have to do to take on this work: fit users’ needs “into your existing system with the minimal number of changes, no degradation of the UX or architecture, and no bugs.” In his view, AI is not there yet. A human is still needed to understand what has to change and to adapt the app to the people who use it.

Karpathy notes it in his post: the code grows beyond what he can follow. For a weekend side project, that does not matter. For an application your users depend on, every change becomes a gamble once nobody knows what the code does any more.

And maintenance costs more than the development itself, as we explain in our article on software projects that go over budget.

Scaling

A demo is done with a single user. Holub counts scalability among the properties that “it works” does not guarantee. What runs smoothly for one person can slow down, or go down, when many users log in at the same time.

When should you bring in a professional?

The criterion is not the size of the app. It is what happens if it breaks down, produces wrong results, or leaks its data.

Bring in a professional when your app:

  • takes money;
  • stores personal data about your customers or employees;
  • serves your users every day;
  • has to evolve with your business, for years.

As long as none of this is at stake, the tool on its own is often enough.

What a professional does with AI

Bringing in a professional does not mean giving up on AI. Development teams use it too. The difference is in everything around the code: automated tests that check every change before it reaches your users, a review of what the tool wrote, releases to production that do not break what worked the day before.

The 2025 DORA report describes AI as an amplifier. It strengthens teams that already have good practices, and worsens the difficulties of the others. The report draws on responses from nearly 5,000 technology professionals. It measures two things: how many changes a team puts into production, and how many of them cause problems once live. The more a team uses AI, the more changes it ships. But, as in the previous year, those changes also go wrong more often. For example, a change breaks something, and it has to be either rolled back or fixed in a hurry. Or an incident hits users, and the team has to release a fix nobody had planned.

Allen Holub writes in “No Agentic SDLC, only Agentic coding” that AI does the coding, which is only a small part of software development. In his view, until an AI can hold a conversation with users to draw out what they need, that work stays human.

With AI, writing code costs little, and verification becomes the bottleneck, says Dave Farley in his interview for the Aviator podcast (“Engineering Discipline in the AI Era”, February 2026).

Alexandre Poitevin says he has been writing Python for ten years. In a LinkedIn post, he recounts that he had offered to help Bryan Finster, who was working on a Python codebase without being used to that stack. Bryan Finster has been a developer since 1996. He joined Walmart in 2001, wrote supply-chain software there, then helped the company spread continuous delivery across its teams. Today he maintains MinimumCD.org, a site that describes the minimum practices of continuous delivery. In the end, Bryan Finster did not need Alexandre’s help. He knew how to steer an AI agent. For Alexandre Poitevin, what counted were the principles Bryan Finster had mastered (testing strategy, dependency management), more than knowing the language.

It was not AI that let Bryan Finster work without knowing Python. It was his command of the fundamentals of software engineering. Those fundamentals apply whatever the language. In a comment, Bryan Finster adds that on the day he decided to move part of a system from .NET Framework to .NET Core, he had never seen .NET code.

At DEVEDANOS, this is how we work. AI is one of our tools, within an approach where every change is checked by automated tests. For custom software development, we work on a fixed budget, invoiced at the end of each month for the work done. Your application is usable within a month, with a few essential features: your users start working with it straight away, and how they use it determines which features come next. Once a feature has been signed off and released, it is judged on how your users respond, and we decide the next ones with you right away, for as long as you wish. A living application is never finished: once you stop evolving it, all it gets are security patches and updates to the components it runs on, and it is an application that is slowly dying.

And to make sure that what worked last month still works this month, we apply a zero-regression guarantee: every regression is fixed and covered by an automated test so that it does not come back, at no extra cost.

Further reading

Our guide covers these sources in detail. You will also find the questions to ask before signing a quote for developing your custom tool.

Do you have an app built with AI that has to hold up in production, or a tool that no longer keeps up with your business? Shall we talk?

Sources

Read next