Salvatore Mosaico · 2026
Author’s note
This essay grows out of direct professional experience. MOSAICO is the author’s name for organising software through systematic reuse and layers. The project scenes are simulations illustrating its implications in the AI age. Employment outlooks are the author’s reflections, not certain predictions.
Contents
- 1. The question: if AI programs, who will be a programmer?
- 2. The MOSAICO method: reuse, layers and composition
- 3. From code reuse to reusing technical intelligence
- 4. What AI can do and what it still lacks
- 5. The programmer moves up a level
- 6. The decisive new skills
- 7. Simulation 1: building an application with AI
- 8. Simulation 2: when the code works but the product is wrong
- 9. Simulation 3: review, security and failures
- 10. Educating new programmers
- 11. Changing professions and new roles
- 12. MOSAICO in the age of AI
- 13. Conclusion: less typing, more engineering
1. The question: if AI programs, who will be a programmer?
I was a very capable programmer. For years, my advantage lay not only in writing an individual procedure well, but in not having to rewrite it every time. I built base libraries for the database, user interface and recurring services; above them I placed level-1 APIs, and above those the application-specific APIs I called level 2. The final application used level 2. When a new project arrived, a very substantial part of the work—often around sixty per cent—was already available.
Today I describe what I want to an artificial intelligence and watch it quickly produce a good interface, many features and code in almost any language. I myself have stopped developing in the traditional way. But I have not stopped building applications: I use the skills accumulated over the years to guide the tool, recognise what is missing and turn a quick result into a good product.
This experience raises a question: what is the future of programmers? If producing code becomes increasingly inexpensive, does the profession lose value, or does its focus change?
The argument of this essay is that programmers do not disappear: they move up a level. Value shifts from typing instructions to understanding problems, from local implementation to architecture, from syntax to control of the system’s overall behaviour. Machines can multiply code; someone must still decide which system is worth building, how it should be composed, and when it is reliable enough to deliver.
The future belongs not to those who write the most lines, but to those who best turn an intention into a verifiable system.
2. The MOSAICO method: reuse, layers and composition
The name MOSAICO expresses the idea: an application is not carved from a single block each time, but assembled from pieces already designed, tested and compatible. Reuse does not eliminate creativity; it shifts creativity from making every element to choosing and arranging the elements.
THE MOSAICO ARCHITECTURE
Base libraries: stable components for databases, user interfaces, data access, communication and shared services.
Level 1: general functional APIs that hide library details and offer consistent operations across projects.
Level 2: APIs for the specific application; they describe the domain and use level 1 exclusively.
Application: the final interface and workflows, built through the capabilities exposed by level 2.
The rule that level 2 uses only level 1 is decisive. It prevents the application from depending directly on dozens of technical details. If the database or graphics library changes, the lower levels should absorb the impact. If a domain rule changes, the main intervention belongs in level 2.
This is not merely a time-saving technique. It is a way of governing complexity. Every level has a vocabulary, a task and a boundary. Lower layers must be general; higher layers become progressively closer to the real problem.
Having sixty per cent ready does not mean that all projects are alike. It means many difficulties are not new: authentication, persistence, validation, presentation, notifications and error handling. Separating them from the specific core prevents confusion between infrastructure and product value.
3. From code reuse to reusing technical intelligence
AI radically extends the principle of reuse. A traditional library reuses existing code. A generative model reuses patterns learned from enormous numbers of examples and can adapt them to a new request. It does not merely retrieve an identical function: it synthesises a possible implementation.
But MOSAICO and AI are not the same. MOSAICO establishes explicit dependencies, deliberate boundaries and components whose identity the designer controls. AI can generate a solution quickly, but tends to optimise for the immediate request. Without architectural constraints, it may duplicate logic, cross layers, choose inconsistent libraries and produce a system that looks elegant but is expensive to maintain.
New reuse therefore needs old discipline. AI accelerates production; architecture keeps acceleration from becoming accumulation. The more code we can generate, the more important the rules limiting where it belongs and what it can depend on become.
Experienced programmers retain an enormous advantage here. Having watched systems grow, break and become unmanageable, they recognise future costs hidden inside today’s shortcut. The machine sees the requested fragment well; the architect must see the lifecycle.
4. What AI can do and what it still lacks
Current AI is highly effective at generating project structures, graphical components, queries, tests, documentation, language conversions and implementations of common features. It is also an excellent partner for exploring alternatives or explaining unfamiliar code.
But a program compiling and a screen looking attractive do not prove the product is right. AI does not spontaneously possess the organisation’s history, compromises agreed with the client, undocumented exceptions, the economic meaning of an error or responsibility for the consequences. It can be given this context, but someone must select it, maintain its consistency and notice what has not been said.
FOUR ESSENTIAL DISTINCTIONS
Valid code / correct requirement: software can execute the wrong thing perfectly.
Demo / product: a successful demonstration does not establish security, resilience, accessibility or maintainability.
Test passed / risk governed: tests cover selected scenarios; they do not automatically certify forgotten ones.
Plausible answer / responsible decision: a convincing solution still needs ownership, controls and acceptance criteria.
Saying that AI “cannot do MOSAICO” therefore means something specific: it can implement the pieces and even follow its rules if we provide them, but it is not an autonomous guarantor of architectural continuity. Without organised memory, automated checks and supervision, each new request risks reinventing the system.
5. The programmer moves up a level
For a long time, programming meant translating an algorithm into rigorous instructions. Now part of that translation can be delegated. Programmers increasingly design the intermediate language through which people and machines collaborate: specifications, API contracts, examples, tests, data schemas, constraints and quality criteria.
Knowing how to ask in natural language is not enough. Prompting is merely the entry point. Real competence means maintaining coherence across dozens of requests, understanding the resulting code, anticipating interactions and building a process that exposes errors early.
The transition is from author of every line to owner of the system; from solver of isolated tasks to designer of boundaries; from syntax seeker to judge of alternatives; from implementer to technical director of software agents.
This does not remove the need to know programming. Without understanding variables, data structures, concurrency, transactions, protocols and complexity, one cannot control what AI generates. Code may be handwritten less often, but must be read with greater care.
6. The decisive new skills
Domain understanding. Turning vague needs into explicit rules; distinguishing what the client asks for from what the process genuinely needs.
Architecture and modularity. Establishing responsibilities, dependencies, contracts and call direction. This is the heart of MOSAICO and becomes more important when code is produced quickly.
Specification. Writing acceptance criteria, edge cases, examples and invariants. A precise request is worth more than many late corrections.
Code reading and review. Understanding the behaviour, side effects and assumptions of code one did not personally write. Future programmers may read more than they type.
Strategic testing. Not merely generating tests, but choosing what must be tested: properties, boundaries, errors, integrations, regressions and hostile scenarios.
Security and privacy. Managing identities, authorisations, secrets, personal data, dependencies and attack surfaces. AI also accelerates the production of plausible vulnerabilities.
Observability and diagnosis. Logs, metrics, traces and alerts must explain the system’s behaviour in production. A rapidly generated application remains opaque if it cannot tell us what happens to it.
Tool evaluation. Choosing models, libraries and platforms without tying the product to a fashion. Understanding costs, licences, quality, portability and vendor dependence.
Communication and responsibility. Explaining technical decisions to clients and colleagues; declaring AI use; knowing who approves a change and who answers for the result.
7. Simulation 1: building an application with AI
Imagine building a booking system for a small medical centre. A hasty request might be “create a modern appointment-management app”. AI would probably produce an attractive screen, a database and some operations. But the project is not yet defined.
PROJECT MEETING — FROM IDEA TO CONTRACT
Client: I want a patient to book quickly.
Designer: Can they book any service? Is a referral required? Who can see the reason for the visit?
Client: Some services require approval; reception sees administrative data, not clinical notes.
Designer: Then let us define roles, booking states, authorisation rules and data retention before generating the screens.
AI: Receives API contracts, a data schema, examples and acceptance criteria, and implements a first version.
In MOSAICO, level 1 offers general capabilities: authenticating a user, saving an entity, sending a notification and recording an event. Level 2 exposes domain operations: requesting, approving or cancelling a booking and checking availability. The interface calls only these operations.
The programmer’s value is not in typing the calendar module. It lies in discovering hidden rules, preventing the interface from bypassing authorisation and turning the requirement into checkable contracts.
AI compresses the interval between specification and prototype. This makes it possible to show the product early and correct our understanding. But speed must not make us confuse a prototype with completion.
8. Simulation 2: when the code works but the product is wrong
A commercial platform automatically applies a ten per cent discount to orders above one hundred euros. AI implements the rule and every proposed test passes. After delivery, it emerges that the threshold must exclude VAT, some products are excluded and two promotions cannot be combined.
REVIEW — THE FIRST ERROR IS NOT IN THE CODE
Junior developer: The function is correct: if total > 100, apply ten per cent.
Product owner: It is correct against an incomplete specification.
Architect: Promotional logic has ended up in the interface. It belongs in level 2, independent of the UI, and must receive a precisely defined total.
Reviewer: Add contrasting examples: 99 euros before VAT; 110 euros of excluded products; two simultaneous promotions.
The lesson is fundamental: debugging is not only about code. Requirements, architecture and mental models also need debugging. AI can repair a function quickly, but cannot reliably guess a commercial policy that was never formulated.
Future programmers must therefore ask questions that produce observable differences. A good test case does not just confirm expected behaviour; it separates competing interpretations of a requirement.
9. Simulation 3: review, security and failures
Consider an AI-generated function to delete a user. It deletes the main row and returns “operation successful”. It seems complete. Professional review must ask: what happens to orders, tax documents, consents and logs? Is deletion permitted, or is anonymisation needed? Can an administrator delete themselves? Is the operation reversible?
PRE-RELEASE CHECKPOINT
Correctness: are invariants, transactions and behaviour after partial completion defined?
Security: is identity verified and authorisation checked on the server, not just in the UI?
Data: are retention, minimisation, audit and entity relationships respected?
Resilience: what happens if the database, network or external service fails to respond?
Observability: will an operator understand what happened without exposing sensitive data?
These questions show why professional software is not identical to source text. It includes data, infrastructure, operating procedures, people, responsibilities and consequences. AI can assist each check; it does not remove the need to decide which checks are mandatory.
Productivity cannot be measured only in generated features. A team is productive when it delivers value without accumulating invisible risks. Today’s code becomes tomorrow’s maintenance.
10. Educating new programmers
If students can generate an entire program, assessing them only on writing it from scratch leads either to hidden AI use or artificially supervised exercises. Education must include the tool and shift attention to computational thinking.
The foundations remain essential: algorithms, data structures, logic, operating systems, networks, databases and language principles. Not because every detail must be memorised, but because this knowledge makes it possible to formulate hypotheses and diagnose errors.
A POSSIBLE PROGRAMMING ASSESSMENT
Part A — Reading: explain generated code’s behaviour and identify dependencies and side effects.
Part B — Design: define APIs, data, invariants and edge cases before implementation.
Part C — AI use: generate a solution, declaring requests, tools and changes made.
Part D — Verification: write tests capable of disproving the solution and analyse a deliberately introduced error.
Part E — Oral defence: justify choices and change the project when a requirement changes.
A particularly useful exercise provides a working but poorly designed application. Students must separate it into layers, reduce dependencies and explain what becomes reusable. This closely resembles MOSAICO and real work.
Learning programming in the AI age also means learning not to delegate too early. Form a plan before asking for help; predict behaviour before running the program; define a correctness criterion before accepting the answer.
11. Changing professions and new roles
Serious employment forecasts invite caution: AI exposure concerns tasks, not automatically entire professions. For junior developers, the most concrete risk is the shrinking of simple activities through which people previously learned on the job. This makes apprenticeships that still provide experience of diagnosis, review and growing responsibility urgent.
In the outlook proposed here, the relative value of some activities will decline: repetitive code, elementary syntax searches, mechanical format conversion, standard CRUD and first-draft interfaces. Greater value will lie in integrating systems, governing data, verifying security, designing user experiences, evaluating AI output and accepting responsibility for results.
Hybrid roles may emerge: product engineers moving between problem and implementation; platform architects building company “level 1” layers; quality owners for generated systems; security specialists for assisted development pipelines; context curators keeping specifications, documentation and rules accessible to agents.
But job titles matter less than the combination of skills. Strong programmers combine technical depth, domain knowledge, communication and disciplined control. The European references cited below describe shortages of advanced ICT specialists, particularly in AI and security: demand does not simply disappear, but becomes more selective.
The greatest danger is not AI replacing every programmer. It is an organisation confusing the ease of producing a demo with the ability to govern a real system.
12. MOSAICO in the age of AI
MOSAICO can evolve from a library collection into a platform intelligible to AI. Its levels must become not only code but contracts: concise documentation, usage examples, schemas, automated tests and explicit prohibitions.
Level 1 should offer safe preferred paths for data access, authentication, logging, errors and configuration. Level 2 should speak the application’s language and prevent the UI from knowing the infrastructure. AI receives these rules as context and generates only within the established boundaries.
MOSAICO + AI — OPERATING PROCESS
1. Intent: describe the objective, users, constraints and what must not happen.
2. Architecture: assign each responsibility to the correct layer and define contracts.
3. Generation: ask AI for a small, traceable change consistent with existing components.
4. Verification: run tests, analysis, human review and edge-case checks.
5. Consolidation: when a capability is genuinely general, promote it into the appropriate reusable layer.
In this form, AI does not supersede the method: the method becomes the structure that allows AI to be productive without disordering the system. Generative intelligence supplies local speed; MOSAICO supplies architectural memory.
There is a further opportunity. Previously, the cost of generalising a component could exceed the immediate benefit. AI now reduces the cost of documenting, testing and adapting it. Reuse can grow, provided it does not become premature abstraction: promote a piece only after recognising its genuine generality.
13. Conclusion: less typing, more engineering
Programming was never merely writing code. Code was the necessary medium through which intention became behaviour. A machine can now produce part of that medium. Responsibility for the behaviour does not disappear.
Future programmers must define problems, draw boundaries, compose services, read code, design tests, control risks and understand the people who will use the system. They must know AI well enough to exploit it and computing well enough not to be deceived by it.
My personal experience leads to an apparent paradox: I have stopped developing in the old sense, but still build applications. AI performs a greater share of the material work; years of accumulated skill let me choose, direct, correct and recognise a good product.
MOSAICO anticipated this transformation. Even then, the advantage was not rewriting everything, but organising what had been learned and rapidly composing a new solution. Today the pieces can also be generated; the mosaic’s design remains essential.
AI does not make programmers useless. It makes simple line production less valuable and the ability to give each line a place, purpose, test and responsibility more valuable.
The programmer’s future is not to compete with machines in typing speed. It is to become the person who can tell the machine what to build, understand what it actually built, and answer for the consequences.
Essential references
- International Labour Organization, Generative AI and Jobs: A Refined Global Index of Occupational Exposure (2025) — Exposure concerns task transformation, not automatic elimination of professions.
- International Labour Organization, The future of work: How will junior programmers be affected? (2025) — Entry pathways and learning activities for junior programmers.
- European Commission, State of the Digital Decade 2025 — AI, cloud and big-data adoption alongside advanced ICT skills shortages.
- ACM / IEEE-CS / AAAI, Computer Science Curricula 2023 (2024) — Competencies, professional responsibility and AI in computing education.
- David Parnas, On the Criteria To Be Used in Decomposing Systems into Modules (1972) — Modularity hides decisions likely to change.
- Fred Brooks, No Silver Bullet (1986; Computer, 1987) — Accidental versus essential software complexity.
Written for online publication. Short excerpts may be quoted with attribution to the author and title.
Read also
Mathematics in the age of artificial intelligence