Skip to content
Veltical
All articles
Insights9 min read

The Reality of Building Software with AI in 2026: Faster, Yes. On Its Own and for Free, No

What AI concretely changes in a software project and what it does not change at all: where it brings real speed, why the cost reduction is 10–20% and not 90%, why testing and review remain human work, what happens to projects "built with AI" without an experienced team, and what to ask an agency that says it works with AI.

By VelticalPublished

Realitatea dezvoltării software cu AI în 2026: mai rapid, da; singur și gratuit, nu
Photo by Daniil Komov

The Reality of Building Software with AI in 2026: Faster, Yes. On Its Own and for Free, No

We work with AI every day. It writes code, proposes architectures, generates tests, explains a legacy system in ten minutes. And every day we talk to clients who have heard that if a project is built with AI, it builds itself, it is ready immediately and it costs a fraction. It is not so, and whoever promises that has either never shipped anything to production or will ship something that has to be rebuilt.

This article explains what AI concretely changes in a software project, what it does not change at all, where the real cost and time reduction comes from, why an experienced team remains the condition for quality, and what happens to projects "built with AI" without one. It is written for companies that want to understand what they are buying when an agency says it works with AI.

What AI does very well

It writes code faster than any human. A screen, an endpoint, a database migration, a set of unit tests: minutes instead of hours. Repetitive code, the kind that used to consume a third of a project's time, has almost disappeared as manual effort.

It explains existing systems. An inherited, undocumented codebase can be understood in hours instead of weeks. For takeover and modernisation projects, this is the biggest change of recent years.

It generates alternatives. Three approaches for an architecture, five phrasings for an onboarding flow, ten test cases nobody thought of. Exploration has become cheap.

It shortens the path from idea to first result. A working prototype in days, not weeks. The client conversation starts from something that opens, not from a document.

On a typical project, delivery time can shrink significantly. That is the reality and we use it on every project.

What AI does not do on its own

It does not know what should be built. The model receives a description and produces what it understood from it. If the description is vague, incomplete or contradictory, the product will be vague, incomplete and contradictory, but it will look finished. Discovering what the client actually wants, the exception cases and what is missing from the requirement remains human work, and it is the hardest part of any project.

It does not make architecture decisions for your future. The model optimises for the current request. It does not know that in month nine you will need a second user role, a second country or an enterprise customer demanding data isolation. The decisions that cost the most when wrong remain with a person who has been through them before.

It does not see what it was not told. Generated code is plausible, compiles and works on the happy path. Tenant isolation in a multi-tenant system, rate limiting, validation of an uploaded file, handling of a failed payment: if you did not ask explicitly, they are not there, and their absence is invisible at the demo.

It does not test in the real world. It generates tests, but it does not know that the partner's API responds differently from its documentation, that the cheap device freezes on the third photo, or that users tap the button twice. Testing on real cases, real devices and real data remains exactly as necessary and takes exactly as long.

It is not accountable for the outcome. When the system goes down at two in the morning or one customer sees another's data, someone has to understand why and fix it. The model has no context on your production system and no responsibility. A person has both.

Where the real cost reduction comes from

On a project delivered properly, with AI used by an experienced team, the cost reduction compared with the same project built without AI is usually between 10 and 20 percent. Not 70. Not 90.

The reason is the structure of the effort. Writing code was one part of the project, not the whole project. Discovery, architecture, product decisions, integrations with systems that do not behave as documented, testing, security, launch, and reviewing everything the model generated consume the time that is left. And review is a new line: generated code has to be read, understood and corrected by someone who knows what it should have looked like. A senior developer reviewing AI code produces far more than before; a junior accepting everything proposed produces something that does not work, faster.

Delivery time falls more than cost, because steps compress and run in parallel. The same team ships faster and ships more. But the work of judgement, the involvement and the responsibility stay the same, and those are what you pay for.

What happens to projects "built with AI" without a team

We see them more and more often in audits. They were delivered fast, at a low price, they look good and they passed the demo. Then:

  • Security. Secrets in code, authorisation that only checks whether you are logged in and not whether you may see the resource, no rate limiting, dependencies with known vulnerabilities, AI components with no protection against manipulation.
  • Hidden bugs. The happy path works. The failed payment, the 50 MB file, the user with accented characters in their name, two simultaneous requests on the same object: never handled, because nobody asked.
  • Disposable architecture. Everything in one file, no separation, no versioned migrations, no environments. The next feature costs as much as the first ten.
  • Code nobody understands. Not the client, not the person who generated it. The first serious intervention starts with two weeks of reading.
  • Uncontrolled running costs. Model calls with no caching, no limits, no metering. The invoice arrives as a surprise.

The outcome is the same every time: the project needs an experienced team, just later, under pressure, with real users in the system and data to migrate. The final investment usually far exceeds what a project done properly from the start would have cost. The low price was not a saving; it was a deferral with interest.

What a team that works well with AI looks like

It orchestrates, it does not delegate. The person decomposes the problem, decides the architecture, writes precise requirements and checks every result. The model executes well-defined steps. This order is never reversed.

It reviews everything that reaches production. Every generated line passes through someone who knows what it should look like. The quality standard belongs to the team, not the model.

It tests exactly as before. Automated and manual, on real cases, on real devices. AI helps write the tests and find the cases; it does not replace running them.

It has experience without AI. Only someone who has built systems without these tools can judge whether what they propose is right. A model proposes a good solution and one that will collapse at the first real customer with the same confidence.

It measures. Delivery time, defects found after launch, running cost. If AI helps, it shows in numbers, not in presentations.

That is how we work: the same senior team, the same standards for architecture, security and testing, with AI used at every stage where it brings real speed. The result is a project delivered faster and usually 10 to 20 percent cheaper, not a project built by a machine.

What to ask an agency that says it works with AI

  1. Who reviews the generated code and what is their experience without AI?
  2. What has concretely changed in your testing process?
  3. What has changed in your security process?
  4. By how much has delivery time fallen on recent projects, in numbers?
  5. By how much has cost fallen, and where does the difference come from?
  6. How do you control the running cost of AI components in the product?
  7. What happens when the model proposes something wrong, and how do you catch it?

If the answer to the first question is vague, the rest no longer matter.

What to do next

If you have received a quote "with AI" at a fraction of the others, ask for the hours, the deliverables, the testing process and who reviews the code. If you already have a project delivered fast and cheap and it feels fragile, a one-to-two-week technical audit tells you what can be kept and what has to be redone before you have real users in the system.

At Veltical the fixed price is issued within 24 hours of a scoping conversation, with hours and deliverables shown, the client owns the code from day one, the 90-day warranty covers defects in what we shipped, and every Friday you receive a version you can use. See how we work.

Frequently asked questions

By how much does AI reduce the cost of a project?

On a project delivered properly, by an experienced team, usually by 10 to 20 percent compared with the same project without AI. Delivery time falls more, because steps compress. The much larger reductions promised in some quotes come from removing discovery, testing, security or review, not from efficiency, and they are paid for later.

Can I build my app myself with AI?

You can build a prototype, and it is an excellent way to validate an idea. A product with real users, payments, personal data and a need for maintenance needs someone who understands what the model generated and why. The difference between the two is invisible at the demo; it shows at the first incident.

Why is a senior team needed if AI writes the code?

Because AI writes what it is asked, with the same confidence whether it is right or not. Someone has to know what to ask, recognise what is missing and be accountable for what reaches production. Experience has not become less necessary; it has become more productive.

Is a project built with AI less secure?

Not if it is built by a team applying the same security standards as before. It is less secure when generated code reaches production without review, because the model does not add access control, rate limiting or input validation on its own if they were not requested. Most of the issues we find in audits of "AI-built" projects are exactly these.

Related articles

  • How to Choose a Software Development Agency in 2026
    Insights9 min read

    How to Choose a Software Development Agency in 2026

    A guide to choosing a software development agency: the real signals of a team that ships, the ones that mislead (portfolio, headcount, low price), fixed price vs. time and materials, how to compare quotes properly, what the contract must contain and 15 questions to ask before you sign.

    Read article
  • Server and Application Security: How to Protect a Platform Properly in 2026
    Security9 min read

    Server and Application Security: How to Protect a Platform Properly in 2026

    A practical guide to server and web application security: how attackers actually get in, what to configure at server level (access, firewall, secrets, backups), what to verify in the application (authentication, authorisation, injection, dependencies, AI components), logging and incident response, GDPR and NIS2 requirements, and what a serious security audit must contain.

    Read article
  • The letters AI and a question mark written in black marker on a whiteboard
    AI automation10 min read

    AI Automation for Businesses: What to Automate and How to Build It Properly in 2026

    A practical guide to AI automation for businesses: how it differs from classic automation, the processes with the best return (customer support, invoices and documents, sales, reporting), the architecture of a system that survives production, human in the loop, GDPR, how to run a pilot with real numbers and what a serious quote must contain.

    Read article