Salvatore Mosaico · 2026
The collaboration between artificial intelligence and the designer: from correct results to system quality.
An application works: pages open, data is saved, calculations return the expected results. Can we say the job is finished?
Not necessarily. Working correctly is essential, but it is not enough to describe software quality. We must also ask how understandable, adaptable and reusable it is. Above all: where have responsibilities been placed?
Developing with artificial intelligence makes this question particularly important. AI can quickly implement requested features, but a succession of correct solutions does not, on its own, guarantee a coherent architecture.
Contents
- 1. One feature at a time, a design also emerges
- 2. The comparison that revealed the problem
- 3. Simplifying use, not denying complexity
- 4. Counting objects does not explain a system
- 5. When specifications come from the system
- 6. With AI, documenting afterwards also means checking
- 7. A web page that documents the database
- 8. Collaboration that produces quality
- Conclusion
1. One feature at a time, a design also emerges
Working with AI often proceeds through successive requests:
“Add a game.”
“Now make it multilingual.”
“Introduce rooms for remote play.”
“Add administration tools.”
“Prepare the statistics.”
Each request seems to concern a function. In reality, it may involve decisions about data structures, dependencies and the distribution of logic.
AI is therefore doing more than writing code: it is participating in design, even when nobody has explicitly asked it to design the entire system.
The risk is that each new need is treated as a local problem, adding another solution without sufficiently reconsidering earlier ones.
This does not mean that AI inevitably produces bad software. It means that quality also depends on the guidance it receives, the available context and the review of accumulated decisions.
2. The comparison that revealed the problem
The discussion began by comparing two databases.
In the website developed with AI, 36 tables had been identified, with no views, procedures or triggers. In the earlier SPIAGGE project there were 10 tables, 59 views and 2 triggers; these called three procedures, recovered separately because they were not included in the dump examined.
These are not numbers for awarding a score. The projects address different needs, and a view does not necessarily replace a table.
However, the comparison revealed an architectural difference: in the first system, much of the logic resided in application code; in the second, a substantial part was organised in the database.
The designer’s decisive observation was:
I do not write joins in my PHP. I query views using SELECT, WHERE and ORDER BY.
This was not an abandonment of relationships between data. It was the result of having already defined them in the underlying layer.
3. Simplifying use, not denying complexity
A page may need a complete quotation with resources, periods, prices and discounts.
If these elements are reconstructed in PHP, the page developer must understand the tables, links and formulas. If a view already presents them in the required form, application code can simply request the result.
Complexity does not disappear: it is handled at the appropriate layer and made reusable.
The person maintaining that layer must understand the database well. The person building a page does not necessarily need to know every internal step of the calculation.
This also enables a division of labour: the designer defines services and rules; the application developer uses them through a simpler interface.
This does not mean every operation belongs in the database. It means that its location should be a conscious choice, not an incidental consequence of the latest request.
4. Counting objects does not explain a system
The designer recounts an earlier experience: a system that had been running for years, with around 120 tables and 1,200 views. Two software companies, brought in successively to replace him, tried to rebuild the system starting with the database, without managing to complete the replacement.
This account does not, by itself, establish why those attempts failed. But it suggests an essential question:
Before replacing the structure, had they understood the services it provided and the rules it embodied?
A large number of views may represent unnecessary layers, but it may also embody a decomposition of the problem developed over many years. To distinguish the two, one must study definitions, dependencies and uses.
At the same time, a quality architecture must be transferable to other people. If its rationale remains only in its author’s head, an important part of the project remains fragile.
This is where documentation comes in.
5. When specifications come from the system
Around thirty years ago, the designer had already seen automatic documentation in action: connecting to Oracle with the appropriate credentials, a tool read the database structure and, through macros and a Word template, produced a document of around 250 pages, organised into chapters and sections. In his recollection, generation was error-free.
The change was not just about speed.
In the traditional process he describes, the designer delivered a document containing the data structures, and the database programmer implemented them. The document and the implementation were two representations that had to be kept aligned.
In the new process, the designer implemented the structure directly, and the documentation was derived from it.
The specifications, as he puts it, “came back from the implementation”: they described the system as built, rather than being only instructions for building it.
This does not eliminate the need to define objectives, requirements and constraints beforehand. It does avoid manually transcribing structural information the database already knows.
6. With AI, documenting afterwards also means checking
In our work, the project grew through successive features. Documentation of the structure actually built must therefore follow implementation.
Afterwards does not necessarily mean at the end. It can mean after every significant change.
Documentation thus becomes a tool for observing what AI has helped build:
- Which structures have been added?
- Which responsibilities have been duplicated?
- Where do the rules reside?
- Which components depend on the same data?
- Are services already available that the new code does not use?
This is what happened in this discussion: database documentation made an architectural difference visible that merely seeing the pages work would not have highlighted.
7. A web page that documents the database
The natural next step is an administrative page that reads database metadata and produces a document according to a predefined template.
A chapter for tables, a section for each table, and a table listing fields and types. Then relationships, views, triggers and procedures, with a contents page and Word or PDF export.
The source can be a dump or a server-side connection, protected and granted only the necessary permissions.
Two activities must be distinguished:
Extracting the structure is a deterministic task. Names, types and constraints must not be invented by AI.
Explaining its meaning can benefit from AI. A complex query can be described, a procedure summarised, a dependency highlighted. Interpretations must, however, remain distinguishable from extracted facts.
Moreover, if the logic resides in PHP, documenting the database is not enough to document the application: the code must also be analysed.
8. Collaboration that produces quality
The connection with the MOSAICO method is direct.
In moving from RandomNumero to RandomRange, the problem was not just obtaining a number in the correct interval. It was recognising an existing capability and using it without reproducing its mechanism.
The same principle applies to a view, a procedure or an application service.
The experienced user does not merely tell AI what is missing. They also identify existing responsibilities, interfaces that must be respected and duplication to avoid.
AI, in turn, can help make alternatives explicit, reconstruct dependencies and check the consistency of new changes.
Collaboration therefore becomes a cycle: clarify the need, identify the responsibility, implement, verify the result and update the documentation. Then review the whole system.
Conclusion
AI can enormously accelerate code production. But producing more code, faster, does not automatically mean building a better system.
The value of experience also lies in recognising what should not be rewritten, keeping interfaces simple and making decisions understandable.
If AI builds the project one feature at a time, documentation generated from the system allows the designer to see and govern the whole again.
It is through this closer collaboration that we move from a merely working product to a quality product: not just asking AI to add something, but reasoning together about where it belongs and how it should integrate with what already exists.