AI-assisted development is a normal part of the work today, not an exception. So the interesting question isn't whether AI is used, but when such an approach is appropriate for your project, and how you check that the result actually works.
What AI-assisted development means
It means that a tool generates the part of the work that can be described, and a person edits, completes and verifies it. It's not hands-off app manufacturing, and it's not a new kind of programming either — it's a different split of time within the same work.
The term vibecoding is also used for this way of working. On its own it doesn't explain anything, which is why it matters more how the process is set up and who checks the output.
Where AI can help
Mostly where the assignment is clear and the work is repetitive:
interface basics: forms, lists, filters, tables;
standard code that repeats throughout a project;
draft tests for existing scenarios;
a first version of documentation and descriptions;
quick solution variants that can be compared before choosing one.
One distinction matters here: generating a draft is not the same as verifying it's correct. Code that looks right and runs can still have wrong logic, missing input validation, or incorrectly configured permissions. That's found through testing, not by reading it.
When this approach can make sense
Clearly bounded assignments are a good fit: a first version with an agreed scope, an internal tool for a known group of users, adding a missing step to an existing process.
Complexity, however, isn't determined by the number of screens. What matters is also:
data — its volume, quality, and whether it needs to be migrated from an older solution;
integrations — whether the connected systems have a usable interface and whether you have access to them;
required operations — how many people will use it, and what happens if it's down for an hour.
An app with five screens and two integrations can be more demanding than twenty screens with no connections at all.
What stays the vendor's responsibility
No tool takes over any of the following:
understanding what problem is actually being solved, and for whom;
designing the solution, including the data model and roles;
weighing trade-offs — what we simplify now, and what that will cost later;
reviewing the outputs and catching errors that aren't obvious at first glance;
testing the agreed scenarios, including error states;
handing over the solution so that it can actually be worked with.
This is the whole point of the service. Generating code is just one of the activities inside it.
When a deeper assessment is needed
Some projects require more preparation and more verification than a simple internal tool needs:
sensitive personal, health, or financial data;
complex permissions, where each role sees a different slice of the data;
significant integrations that a company's operations depend on;
critical operations, where downtime means direct losses;
a regulated environment with its own requirements.
This doesn't mean AI tools can't be used on such projects. It means they require an appropriately careful design, expertise in the relevant domain, and more thorough verification — and the scope and timeline need to reflect that.
If you're considering a project like this, say so at the very start. We'll go through what needs to be checked before work begins.
What to clarify before placing an order
Regardless of the vendor and the tools used, it's worth having answers in advance to:
Scope — what's in the first version and what isn't, written down so it can be checked.
Progress demos — at which points you'll see the work in progress.
Acceptance criteria — which scenarios must work for the deliverable to be considered done.
Handover — exactly what you'll receive, and in what form.
Operating costs — which services will be running, and who pays for them.
Support — to what extent and for what period it's agreed.
These are questions we go through too — and their answers are part of the agreed scope, not an attachment delivered at the end.
Example scenario: where things usually break down
The following is an illustrative example, not a description of a specific client project.
A company needs a tool for approving purchase orders. The screens are simple: a list, a detail view, an approve button. Generating them is a matter of a short amount of time.
The real work lies elsewhere: who is allowed to approve up to what amount, what happens when the approver is out of office, what happens with an order changed after approval, and how you can later prove who approved what. No tool solves any of these questions — they get resolved by talking with the company, and then verified through testing.
That's why, with us, scope gets agreed before development, not during it.
Summary
AI tools speed up the repetitive part of the work; they don't replace design or review.
Suitability of the approach is determined by data, integrations and required operations, not the number of screens.
More demanding environments don't rule out AI, but they do require more thorough verification.
Before placing an order, clarify scope, demos, acceptance criteria, handover, operations and support.
We cover how this affects the budget in the article How much does the first version of an app cost, and where can you reasonably save. We explain the difference between a demo and an operational solution in A proof of concept is not production.
