Building with AI: architecture, infrastructure and maintenance
A working screen is only the beginning. Architecture, security, infrastructure and continued development need decisions beyond a few prompts.
Building an application with AI can begin with a surprisingly good result. A few instructions, a working form, an attractive dashboard and the first records. It is easy to decide that the hardest part is behind us. In my view, this is precisely where we should slow down. A working screen does not yet tell us whether we have a product ready for real users.
Letting AI build it or building with AI’s help
This is more than a choice of words. In the first approach, we expect the model to solve the problem for us and judge mainly the visible result. In the second, we remain responsible for decisions, understand the limitations and control the changes. The same assistant can take part in both processes. The difference comes from the way we work, not the tool’s logo.
AI can significantly shorten the path from an idea to a demonstration. It can propose a data model, prepare a form and help test an assumption. That is a real benefit, especially for an experiment with limited consequences. We do not have to dismiss it to recognise the work that follows. A prototype is valuable when we know which question it is meant to answer.
Architecture starts before the first screen
Consider a system serving several companies. We need to define data boundaries, user roles, billing rules and account recovery. Imports, account deletion and change history add further requirements. A model can generate every feature separately and still produce an inconsistent system. A locally correct fragment does not guarantee that all the pieces work together correctly.
Before coding, I would write down a few architectural decisions. What is the source of truth for the data? Which operations must be atomic? How do we recognise a retried request, and who may see its result? The document need not run to a hundred pages. It should, however, let us explain the application’s behaviour without asking the model what it intended.
Choose technologies in the same way. A stack with a future is not necessarily a collection of the newest libraries. Security support, available people, documentation and migration costs matter more. Assess hosting and deployment too. A tool that is convenient for a demonstration may require infrastructure the team cannot maintain later.
Review more than the happy path
OWASP highlights the risks of misplaced trust in AI-generated code. It recommends reviewing that code and applying normal secure development practices. A fragment does not get a special exemption because it came from a text instruction. The organisation remains responsible for running it. [1]
Check more than whether a form saves successfully. Can a user from one company read another company’s document? What happens when someone clicks the payment button twice? How does an import behave if it stops halfway through? These cases reveal whether we understand our product. A model can help prepare the tests, but we must be able to justify their acceptance criteria.
The review also covers dependencies, information given to the assistant and the permissions of its integrations. OWASP recommends controlling secrets and verifying generated changes. An automated tool with deployment access can cause more damage than a bad suggestion in an editor. Give it permissions appropriate to the task rather than the convenience of administrator access to the whole environment. [2]
Infrastructure does not appear when we click Publish
Building an application with AI does not remove the need to prepare its production environment. Production needs domains, certificates, mail configuration, backups and monitoring. Test environments must be separated from real data. We need rules for deployment, rollback and secret storage. Scheduled jobs, queues and disk capacity also need attention. Each element may work separately and fail in an unexpected combination.
A verified backup includes a restore trial. Monitoring should detect an unavailable service, not merely a running process. Someone must respond to an alert, with instructions for what to do. The cost of this work does not disappear when code becomes cheaper to generate. Only the proportion of time spent on different tasks changes.
NIST describes secure development as a set of practices covering organisational preparation, software protection and responses to vulnerabilities. That is a broader process than a one-off code check. It helps organise responsibility regardless of the assistant being used. Treat the documentation as a reference point, not an automatic certificate of project quality. [3]
Continued development is the real test
The first version shows whether we can build a feature. Later versions show whether we can change the system without damaging existing data and behaviour. Migrations, integration compatibility and security fixes follow. Every promise made to a user begins to cost time. This is where the earlier savings can easily disappear.
Building with AI makes sense when it accelerates informed work. A sensible plan includes a small scope, explicit decisions, change review and verifiable deployment criteria. It then needs a maintenance budget, not just a launch budget. I am optimistic about tools that reduce repetitive work. I remain sceptical of the promise that a responsible product can be created with a few prompts.
Sources and verification date
2026-10-19 · English edition of the Polish article.
