AI in software development: faster doesn't mean automatic

In practice, writing code is only part of the work. A useful system needs to understand the organisation's real process, structure data, respect business rules, integrate existing tools, protect information, handle exceptions, be tested and keep working after it goes live. AI speeds up several of these tasks. It doesn't eliminate the analysis, the experience, or the accountability for the outcome.

AI doesn't understand the business on its own

Before writing any code, you need to understand how the work is actually done: who's involved, what information comes in, what decisions get made, where time and data get lost. A client's initial requirements rarely describe everything — there are rules so routine to the team that no one thinks to explain them, spreadsheets that became informal databases, procedures that differ between departments.

AI can organise documentation, summarise meetings, suggest questions and help turn requirements into use cases. But it still takes someone able to spot contradictions, tell symptoms from causes, and work out whether the solution being asked for is actually the solution that's needed.

The same AI doesn't produce the same result in everyone's hands

The value of AI tools depends on who's directing and validating them. An experienced developer knows how to break a problem down, provide the relevant context, set boundaries, and recognise an answer that looks correct but doesn't respect the existing architecture, data or rules. They know how to tell a working demo apart from an application built to run for years, with different roles, permissions, integrations and real data.

Experience helps you ask AI better questions — but above all it helps you evaluate the answers: what information to provide, which parts of the system can't change, what risks a proposed solution carries, when a fix only solves the example shown, and when it's better not to use AI at all.

AI app-building platforms are useful, but have limits

App-generation platforms (like Lovable) are very useful for prototypes, pages and standardised flows. They cut the time to a first version significantly. The challenge grows when the system needs to integrate legacy software, preserve rules accumulated over years, migrate inconsistent data, apply different conditions per customer, or fix errors that only surface with specific combinations of information — complex permissions, ERP and accounting integration, importing old data, high-volume processing, auditing, backups, evolving without stopping the operation. In these contexts, generating the first interface is only the beginning.

Velocitas Code's RALPI project illustrates that complexity well: a platform with over 30,000 automotive rubber-parts references, integrating products, photographs, equivalences, vehicle fitment, customer-specific pricing and PDF catalogue generation running to hundreds of pages. The difficulty isn't producing a file — it's keeping all of these elements coherent and usable year after year.

Choosing and validating the right model is part of the engineering

There's no single ideal model for everything. A project can combine document interpretation, coding, search, classification, content generation and data validation — and the right model depends on complexity, volume, confidentiality, cost and the impact of getting it wrong.

External models offer strong reasoning for complex problems: exploring architectures, helping write code, producing documentation, working over anonymised information. Before using them, you need to know what data will be sent, where it's processed and for how long — credentials, personal data and sensitive code shouldn't be sent to external services without assessing their data-handling terms, retention, location, use for training, and contractual guarantees.

Local models, running on infrastructure controlled by Velocitas Code or by the client, can make more sense when data is confidential or volume is high — financial information, contracts, internal documentation, business archives. They allow greater control over where data is processed and stored, provided the infrastructure, access controls, logs and backups are also properly protected. They don't need to beat the largest models at everything — just be good enough, and validated, for the specific job they do.

Not every task needs the most powerful model. A small model can classify documents; a specialised model can interpret images; a more capable model is reserved for exceptions and complex analysis. And some tasks shouldn't go to a language model at all — calculations, rates, permissions and identifiers remain the job of deterministic code.

A responsible solution typically combines conventional code for exact rules, small models for repetitive tasks, specialised models for documents or images, advanced models for complex analysis, and human validation at the highest-risk points. The goal isn't to use AI everywhere — it's to use it where it creates real advantage.

Example: 1000faturas

1000faturas processes invoices by reading QR codes, running OCR, and using an LLM to extract fields such as amounts, tax IDs and dates. Each method has a different error profile: the structured data from a QR code tends to be more reliable than visual reading, when present and correctly decoded — but not every invoice has one; OCR fails on poor-quality scans; an LLM can plausibly interpret a value that is, in fact, wrong.

That's why extracted data is presented for confirmation before being treated as final, especially where there are discrepancies, low confidence, or fields with accounting impact. This isn't a lack of trust in the AI — it's recognising that an error in an invoice amount has a real cost, and that automatic extraction speeds up the work without replacing verification. AI eliminates repetitive manual data entry; it doesn't eliminate validation.

AI changes the scale of what a small team can build

1000faturas also shows how AI can substantially expand development capacity. In a few months it became possible to build a platform whose size and functional scope could represent several years of individual work, or require a multidisciplinary team to deliver in a similar timeframe.

The application includes over 350,000 lines of internally developed source code across Python, SQL, JavaScript, web components and system scripts — of which more than 230,000 are Python. Counting configuration, technical documentation, comments and the rest of the project's content, it approaches 1.2 million lines, not including external libraries and frameworks.

Lines of code don't, on their own, measure an application's quality; they're used here only as an indicator of scale. The system combines QR code and ATCUD reading, OCR, LLM-assisted interpretation, duplicate detection, multi-company and multi-currency management, cost centres and projects, importing statements from different banks, bank reconciliation, and handling a range of business contexts.

AI accelerated the creation of structures, interfaces, integrations, documentation and tests, as well as helping identify and fix problems. It also made it feasible to explore more alternatives and build features that might otherwise not have justified the time or investment required.

But the system wasn't created automatically. AI didn't decide the architecture, didn't understand the accounting rules on its own, didn't validate the results against real documents, and didn't take responsibility for errors. Every component had to be directed, the different parts integrated, the generated code reviewed, real scenarios tested, and problems that only emerge at this scale had to be fixed.

The main gain wasn't building exactly the same product in less time. It was letting a small team deliver, in months, a solution whose scale and functional diversity would previously have been associated with several years of development or a much larger team.

And this work doesn't end with the first version. An enterprise platform keeps evolving with new documents, banks, rules, integrations, customer needs and legal or accounting changes — just as with RALPI or the bespoke systems we generally build.

Testing AI means understanding how it fails

In a traditional system, the same function tends to give the same result with the same data. An AI model can respond differently, misread a new case, or produce a plausible-sounding answer without sufficient grounding. Testing needs to combine several layers: automated tests for conventional code, validated example sets, comparison against expected results, validation through deterministic rules, testing with incomplete or poor-quality data, human review by sampling, routing of uncertain cases, and monitoring after going live.

It isn't enough to show that AI works on a few chosen examples — you need to know its failure modes and make sure they're caught before they have consequences.

Using AI professionally also requires investment

Using AI isn't free, and it isn't just a matter of opening an app. External models are usually paid through subscriptions or by token volume processed. Analysing long documents, images, codebases and lengthy histories can represent significant consumption, especially when operations need to be repeated, responses compared, or more advanced models used.

For tasks involving confidential information or large volumes of data, Velocitas Code has invested in dedicated AI infrastructure. This allows different models to run locally, workloads to be distributed across multiple machines, and sensitive information to remain in a controlled environment. It represents an ongoing investment in computing capacity, storage, electricity, maintenance and technological upgrades.

This option reduces dependence on external services and per-token costs, but it doesn't eliminate costs. It requires processing time: a local model can be economically advantageous for high-volume work, but slower than a high-capacity external service.

Infrastructure alone does not guarantee good results. An important part of the expertise lies in evaluating different AI engines and models against real tasks: measuring output quality, processing time, memory requirements, context capacity and cost. The most recent, largest or most expensive model is not necessarily the right one for every process.

This evaluation needs to be done with real examples. It means comparing results, measuring times, identifying recurring errors and determining the minimum acceptable quality level. For some processes, a slower, cheaper local model is the right call; for others, response time or complexity justifies a more advanced external service. It can also make sense to use a smaller model for most documents and route only the difficult cases to a more powerful one.

Knowing how to choose this combination is an important part of the work. The goal isn't always to use the newest, biggest or most expensive model, but to find the best balance of quality, speed, confidentiality and cost for each process.

The real value lies not only in having access to AI, but in knowing which engine to use, what level of quality is required, how long each operation will take, what it will cost, and how its results should be validated.

If AI speeds up development, why don't prices fall proportionally?

AI has its own costs, but it also increases productivity. The issue is that this gain isn't spread evenly across every phase of a project. It accelerates initial code scaffolding, repetitive tasks, documentation and part of error analysis. But writing code is only a portion of the work needed to deliver an enterprise system. Specialist work is still required: understanding the process, architecture and data structuring, clarifying contradictory requirements, systems integration, data migration, diagnosing hard-to-reproduce errors, security, validation with users, and going live.

Quickly generated code sometimes needs more review — it can work on an example and ignore a rule, introduce a vulnerability, or fail on real data. A project's price doesn't correspond to the number of lines written; it includes analysis, architecture, integration, testing, documentation and technical accountability — plus accumulated knowledge, available infrastructure, and choosing the right tools for each task.

When scope is exactly the same and risk is low, productivity gains can show up as a shorter timeline. But in most projects, the gain is converted into more quality within a similar investment: more validation, more exceptions handled, a better user experience, more test coverage, more security, more complete documentation. The client gets greater robustness and lower risk, even when the price stays the same — and the bar for what's expected of a system has also risen: where recording information used to be enough, today intelligent search, automation and dashboards are expected.

Part of the productivity gain AI provides offsets the investment in infrastructure, external services, experimentation and continuous learning. Another part turns into a larger-scale solution: more features, integrations, exceptions handled, testing, documentation and capacity to evolve. The client doesn't just get what they would have received anyway, faster — they may get a solution that, with the same investment and the previous methods, would have been far more limited.

How easy it is to build features also creates risk

With AI, it's tempting to add just one more button, report or automation. But every feature needs to be understood, integrated, secured, tested, documented and maintained. A feature that takes minutes to generate can create hours of validation and new dependencies for years to come. A good solution isn't the one with the most features — it's the one that solves the priority problems with the least complexity necessary.

That makes managing expectations even more important. If a feature appears ready in a prototype within minutes, it can look production-ready — but that demo rarely includes exceptions, security, data migration, integrations or future maintenance. It's always necessary to distinguish between an idea, a prototype, a feature in development and a production-ready system — and to weigh every new request by its real benefit, and by its impact on timeline, investment and maintenance.

AI amplifies experience; it doesn't remove accountability

Using AI professionally takes more than writing prompts: it takes understanding processes, choosing models, protecting data, combining AI with deterministic rules, testing results and controlling functional growth. At Velocitas Code, AI is an acceleration tool — it helps analyse, code, document and test faster. The architecture, the validation and the accountability for the outcome remain in the hands of whoever understands the process and works with the client.

AI can generate a first version in minutes. Experience determines whether that version will still work with thousands of records, hundreds of pages and years of evolution. It enables a small team to build in months what would previously have required several years of individual work or a much larger development team — execution that's still directed, reviewed and validated by experienced professionals. The benefit for the client isn't just getting software faster, but getting a more complete, better-validated solution, ready to evolve without turning every new requirement into a problem.