Salvatore Mosaico · 2026
Nota del autor
Este ensayo nace de experiencia profesional directa. MOSAICO es el nombre que el autor da a una organización basada en reutilización sistemática y niveles. Las escenas son simulaciones. Las perspectivas laborales son reflexiones del autor, no predicciones ciertas.
Índice
- 1. La pregunta: si la IA programa, ¿quién programará?
- 2. El método MOSAICO: reutilización, niveles y composición
- 3. De reutilizar código a reutilizar inteligencia técnica
- 4. Lo que la IA sabe hacer y lo que todavía no posee
- 5. El programador sube de nivel
- 6. Las nuevas competencias decisivas
- 7. Simulación 1: construir una aplicación con IA
- 8. Simulación 2: el código funciona, pero el producto está equivocado
- 9. Simulación 3: revisión, seguridad y fallos
- 10. La formación de nuevos programadores
- 11. Profesiones que cambian y nuevos roles
- 12. MOSAICO en la época de la IA
- 13. Conclusión: menos tecleo, más ingeniería
1. La pregunta: si la IA programa, ¿quién programará?
Fui un programador muy competente. Durante años mi ventaja no consistió solo en escribir bien un procedimiento, sino en no tener que reescribirlo cada vez. Construí bibliotecas básicas para la base de datos, la interfaz y los servicios recurrentes; encima situé API de nivel 1 y, sobre ellas, las API específicas de la aplicación, que llamaba nivel 2. La aplicación final utilizaba el nivel 2. Ante un nuevo proyecto, buena parte del trabajo —a menudo alrededor del sesenta por ciento— ya estaba disponible.
Hoy describo a una inteligencia artificial lo que deseo y la veo producir rápidamente una buena interfaz, muchas funciones y código en casi cualquier lenguaje. Yo mismo he dejado de desarrollar de la manera tradicional. No he dejado de construir aplicaciones: uso la experiencia acumulada para orientar la herramienta, reconocer lo que falta y transformar un resultado rápido en un buen producto.
De ahí surge la pregunta: ¿cuál será el futuro de los programadores? Si producir código resulta cada vez más barato, ¿pierde valor la profesión o cambia su objeto?
La tesis de estas páginas es que el programador no desaparece: sube de nivel. El valor pasa de teclear instrucciones a comprender el problema, de la implementación local a la arquitectura, de la sintaxis al control del comportamiento global. La máquina multiplica el código; alguien debe decidir qué sistema merece existir, cómo componerlo y cuándo es suficientemente fiable para entregarlo.
El futuro no pertenece a quien escribe más líneas, sino a quien transforma mejor una intención en un sistema verificable.
2. El método MOSAICO: reutilización, niveles y composición
MOSAICO expresa bien la idea: una aplicación no se esculpe cada vez en un bloque único, sino que se compone con piezas diseñadas, probadas y compatibles. La reutilización no elimina la creatividad: la desplaza de fabricar cada elemento a elegirlos y disponerlos.
LA ARQUITECTURA MOSAICO
Bibliotecas básicas: componentes estables para bases de datos, interfaz, acceso a datos, comunicación y servicios comunes.
Nivel 1: API funcionales generales que ocultan detalles de las bibliotecas y ofrecen operaciones coherentes a los proyectos.
Nivel 2: API propias de la aplicación, que describen el dominio y utilizan exclusivamente el nivel 1.
Aplicación: interfaz y flujos finales construidos mediante las capacidades del nivel 2.
La regla de que el nivel 2 solo utiliza el nivel 1 es decisiva. Evita depender directamente de decenas de detalles técnicos. Si cambia la base de datos o la biblioteca gráfica, las capas inferiores deberían absorber el impacto. Si cambia una regla del dominio, se interviene principalmente en el nivel 2.
No es solo ahorro de tiempo: es gobierno de la complejidad. Cada nivel posee vocabulario, tarea y frontera. Las capas inferiores deben ser generales; las superiores se acercan progresivamente al problema real.
Tener un sesenta por ciento listo no significa que todos los proyectos sean iguales. Muchas dificultades no son nuevas: autenticación, persistencia, validación, presentación, notificaciones y errores. Separarlas del núcleo específico evita confundir infraestructura y valor del producto.
3. De reutilizar código a reutilizar inteligencia técnica
La IA amplía radicalmente la reutilización. Una biblioteca tradicional reutiliza código escrito. Un modelo generativo reutiliza patrones aprendidos de enormes cantidades de ejemplos y los adapta a una petición nueva. No recupera solo una función idéntica: sintetiza una implementación posible.
Pero MOSAICO y la IA no son lo mismo. MOSAICO crea dependencias explícitas, fronteras decididas y componentes cuya identidad controla el diseñador. La IA genera rápidamente soluciones, pero tiende a optimizar la petición inmediata. Sin restricciones arquitectónicas puede duplicar lógica, atravesar capas, elegir bibliotecas incoherentes y producir un sistema elegante por fuera y caro de mantener.
La nueva reutilización necesita el antiguo rigor. La IA acelera la producción; la arquitectura evita que la aceleración se convierta en acumulación. Cuanto más código se genera, más importan las reglas que delimitan dónde debe vivir y de qué puede depender.
El programador experimentado conserva una enorme ventaja. Quien ha visto sistemas crecer, fallar y volverse inmanejables reconoce costes futuros ocultos en un atajo presente. La máquina ve bien el fragmento pedido; el arquitecto debe ver el ciclo de vida.
4. Lo que la IA sabe hacer y lo que todavía no posee
La IA actual es eficaz generando estructuras de proyecto, componentes gráficos, consultas, pruebas, documentación, conversiones entre lenguajes y funciones comunes. También ayuda a explorar alternativas o explicar código desconocido.
Pero que un programa compile y una pantalla resulte agradable no demuestra que el producto sea correcto. La IA no posee espontáneamente la historia de la organización, los compromisos con el cliente, las excepciones no documentadas, el significado económico de un error ni la responsabilidad por sus consecuencias. Puede recibir ese contexto, pero alguien debe seleccionarlo, mantenerlo coherente y advertir lo que no se ha dicho.
CUATRO DISTINCIONES ESENCIALES
Código válido / requisito correcto: el software puede ejecutar perfectamente lo equivocado.
Demostración / producto: una demostración exitosa no prueba seguridad, resiliencia, accesibilidad ni mantenimiento.
Prueba superada / riesgo controlado: las pruebas cubren escenarios elegidos, no certifican automáticamente los olvidados.
Respuesta plausible / decisión responsable: una solución convincente sigue necesitando responsable, controles y criterios de aceptación.
Decir que la IA «no sabe hacer MOSAICO» significa algo preciso: puede implementar sus piezas y respetar sus reglas si se las damos, pero no garantiza autónomamente la continuidad arquitectónica. Sin memoria organizada, comprobaciones automáticas y supervisión, cada petición puede hacerle reinventar el sistema.
5. El programador sube de nivel
Programar significó durante mucho tiempo traducir un algoritmo a instrucciones rigurosas. Ahora parte de esa traducción se delega. El programador diseña cada vez más el lenguaje intermedio de colaboración entre persona y máquina: especificaciones, contratos de API, ejemplos, pruebas, esquemas de datos, restricciones y criterios de calidad.
No basta pedir bien en lenguaje natural. El prompting es solo la entrada. La competencia real consiste en mantener coherencia durante decenas de peticiones, entender el código generado, prever interacciones y construir un proceso que revele pronto los errores.
Se pasa de autor de cada línea a responsable del sistema; de resolver tareas aisladas a diseñar fronteras; de buscar sintaxis a juzgar alternativas; de ejecutor a director técnico de agentes de software.
No desaparece la necesidad de saber programar. Sin comprender variables, estructuras de datos, concurrencia, transacciones, protocolos y complejidad no se controla lo generado. Quizá se escriba menos código a mano, pero habrá que leerlo con más atención.
6. Las nuevas competencias decisivas
Comprensión del dominio. Convertir necesidades vagas en reglas explícitas y distinguir la petición del cliente de lo que realmente necesita el proceso.
Arquitectura y modularidad. Establecer responsabilidades, dependencias, contratos y dirección de llamadas: el corazón de MOSAICO, aún más importante con generación rápida.
Especificación. Escribir criterios de aceptación, casos límite, ejemplos e invariantes. Una petición precisa vale más que muchas correcciones tardías.
Lectura y revisión. Entender comportamiento, efectos secundarios e hipótesis de código ajeno. El programador quizá lea más de lo que teclee.
Pruebas estratégicas. Elegir qué demostrar, no solo generar pruebas: propiedades, límites, errores, integraciones, regresiones y escenarios hostiles.
Seguridad y privacidad. Gestionar identidades, autorizaciones, secretos, datos personales, dependencias y superficies de ataque. La IA también acelera vulnerabilidades plausibles.
Observabilidad y diagnóstico. Registros, métricas, trazas y alertas deben explicar el comportamiento en producción. Una aplicación generada deprisa sigue siendo opaca si no cuenta qué le sucede.
Evaluación de herramientas. Elegir modelos, bibliotecas y plataformas sin atar el producto a una moda. Conocer costes, licencias, calidad, portabilidad y dependencia del proveedor.
Comunicación y responsabilidad. Explicar decisiones a clientes y compañeros, declarar el uso de IA y saber quién aprueba el cambio y responde del resultado.
7. Simulación 1: construir una aplicación con IA
Imaginemos un sistema de reservas para un pequeño centro médico. Una petición apresurada sería «crea una aplicación moderna para gestionar citas». La IA probablemente produciría una pantalla atractiva, una base de datos y operaciones. Pero el proyecto aún no está definido.
REUNIÓN — DE LA IDEA AL CONTRATO
Cliente: Quiero que un paciente reserve rápidamente.
Diseñador: ¿Cualquier servicio? ¿Hace falta prescripción? ¿Quién ve el motivo de la visita?
Cliente: Algunos servicios requieren aprobación; recepción ve datos administrativos, no notas clínicas.
Diseñador: Definamos roles, estados de la reserva, autorización y conservación de datos antes de generar pantallas.
IA: Recibe contratos, esquema de datos, ejemplos y criterios de aceptación; implementa una primera versión.
En MOSAICO, el nivel 1 ofrece capacidades generales: autenticar, guardar una entidad, enviar una notificación, registrar un evento. El nivel 2 expone operaciones del dominio: solicitar, aprobar o cancelar una reserva, comprobar disponibilidad. La interfaz llama solo a estas operaciones.
El valor del programador no es teclear el calendario. Es descubrir reglas ocultas, impedir que la interfaz eluda autorizaciones y convertir requisitos en contratos comprobables.
La IA acorta el tiempo entre especificación y prototipo, permitiendo mostrar pronto el producto y corregir la comprensión. Pero rapidez no debe significar confundir prototipo y conclusión.
8. Simulación 2: el código funciona, pero el producto está equivocado
Una plataforma comercial aplica diez por ciento de descuento a pedidos superiores a cien euros. La IA implementa la regla y pasan las pruebas propuestas. Tras la entrega se descubre que el umbral excluye IVA, algunos productos están excluidos y dos promociones no se acumulan.
REVISIÓN — EL PRIMER ERROR NO ESTÁ EN EL CÓDIGO
Desarrollador junior: La función es correcta: si total > 100 aplica diez por ciento.
Responsable del producto: Correcta respecto a una especificación incompleta.
Arquitecto: La lógica promocional terminó en la interfaz. Debe estar en el nivel 2, independiente de la UI, recibiendo un total precisamente definido.
Revisor: Añadamos casos contrastantes: 99 euros sin IVA; 110 euros en productos excluidos; dos promociones simultáneas.
La depuración no afecta solo al código: también requisitos, arquitectura y modelo mental. La IA corrige funciones rápidamente, pero no adivina con fiabilidad políticas nunca formuladas.
El programador debe hacer preguntas que produzcan diferencias observables. Un buen caso de prueba no solo confirma el comportamiento esperado: separa interpretaciones alternativas del requisito.
9. Simulación 3: revisión, seguridad y fallos
Una función generada para eliminar un usuario borra la fila principal y devuelve «operación realizada». Parece completa. Pero ¿qué ocurre con pedidos, documentos fiscales, consentimientos y registros? ¿Se permite borrar o hay que anonimizar? ¿Puede un administrador eliminarse? ¿Es reversible?
CONTROL ANTES DEL LANZAMIENTO
Corrección: ¿se definen invariantes, transacciones y comportamiento ante una operación parcial?
Seguridad: ¿identidad y autorización se comprueban en el servidor, no solo en la UI?
Datos: ¿se respetan conservación, minimización, auditoría y relaciones entre entidades?
Resiliencia: ¿qué sucede si no responde la base de datos, red o servicio externo?
Observabilidad: ¿un operador comprenderá lo ocurrido sin exponer datos sensibles?
El software profesional no coincide con su texto fuente: incluye datos, infraestructuras, procedimientos, personas, responsabilidades y consecuencias. La IA ayuda en los controles, pero no decide cuáles deben ser obligatorios por nosotros.
La productividad no se mide solo en funcionalidades generadas. Un equipo productivo entrega valor sin acumular riesgos invisibles. El código de hoy será mantenimiento mañana.
10. La formación de nuevos programadores
Si el alumnado genera un programa entero, evaluarlo solo por escribirlo desde cero conduce al uso oculto de IA o a ejercicios artificialmente vigilados. La formación debe incluir la herramienta y centrarse en el pensamiento informático.
Las bases siguen siendo indispensables: algoritmos, estructuras de datos, lógica, sistemas operativos, redes, bases de datos y principios de los lenguajes. No para memorizar todo, sino para formular hipótesis y diagnosticar errores.
UNA POSIBLE PRUEBA
Parte A — Lectura: explicar código generado, dependencias y efectos secundarios.
Parte B — Diseño: definir API, datos, invariantes y casos límite antes de implementar.
Parte C — IA: generar declarando peticiones, herramientas y modificaciones.
Parte D — Verificación: escribir pruebas que puedan refutar la solución y analizar un error introducido deliberadamente.
Parte E — Defensa oral: justificar decisiones y modificar el proyecto cuando cambia un requisito.
Un ejercicio útil entrega una aplicación que funciona pero está mal diseñada. Hay que separarla en niveles, reducir dependencias y explicar qué resulta reutilizable. Se parece mucho a MOSAICO y al trabajo real.
Aprender también es no delegar demasiado pronto: primero planificar, luego pedir ayuda; primero predecir, después ejecutar; primero definir corrección, luego aceptar la respuesta.
11. Profesiones que cambian y nuevos roles
Las previsiones serias invitan a la cautela: la exposición a IA afecta sobre todo a tareas, no automáticamente a profesiones enteras. Para los junior, el riesgo concreto es reducir las actividades sencillas con las que antes se aprendía trabajando. Urgen aprendizajes con diagnóstico, revisión y responsabilidad creciente.
En la perspectiva propuesta aquí, perderán valor relativo el código repetitivo, la sintaxis elemental, conversiones mecánicas, CRUD estándar y primeros diseños de interfaz. Ganarán valor integración, gobierno de datos, seguridad, experiencia de uso, evaluación de resultados de IA y responsabilidad.
Podrían surgir roles híbridos: product engineers entre problema e implementación; arquitectos de plataformas que construyen «niveles 1» empresariales; responsables de calidad de sistemas generados; especialistas en seguridad de desarrollo asistido; curadores de contexto que mantienen especificaciones, documentación y reglas accesibles a agentes.
Importa menos el título que combinar profundidad técnica, conocimiento del dominio, comunicación y disciplina de control. Las referencias europeas citadas describen escasez de especialistas TIC avanzados, particularmente en IA y seguridad: la demanda no desaparece simplemente, se hace más selectiva.
El mayor peligro no es sustituir a todos los programadores, sino confundir la facilidad de producir una demo con la capacidad de gobernar un sistema real.
12. MOSAICO en la época de la IA
MOSAICO puede evolucionar de colección de bibliotecas a plataforma inteligible para la IA. Los niveles deben convertirse también en contratos: documentación concisa, ejemplos, esquemas, pruebas automáticas y prohibiciones explícitas.
El nivel 1 ofrece caminos seguros para datos, autenticación, registros, errores y configuración. El nivel 2 habla el lenguaje de la aplicación y evita que la UI conozca la infraestructura. La IA recibe esas reglas y genera dentro de sus límites.
MOSAICO + IA — PROCESO
1. Intención: describir objetivo, usuarios, restricciones y lo que no debe ocurrir.
2. Arquitectura: asignar responsabilidades al nivel correcto y definir contratos.
3. Generación: producir un cambio pequeño, trazable y coherente con los componentes existentes.
4. Verificación: pruebas, análisis, revisión humana y casos límite.
5. Consolidación: promover una capacidad realmente general al nivel reutilizable adecuado.
La IA no supera el método: este permite que sea productiva sin desordenar el sistema. La inteligencia generativa aporta velocidad local; MOSAICO, memoria arquitectónica.
Antes, generalizar un componente podía costar más que su beneficio inmediato. La IA reduce documentación, pruebas y adaptación. Puede crecer la reutilización, sin abstracción prematura: promover una pieza solo después de reconocer su auténtica generalidad.
13. Conclusión: menos tecleo, más ingeniería
Programar nunca fue solo escribir código. Era el medio obligado para convertir intención en comportamiento. Ahora la máquina produce parte de ese medio, pero la responsabilidad del comportamiento no desaparece.
El programador deberá definir problemas, dibujar fronteras, componer servicios, leer código, diseñar pruebas, controlar riesgos y comprender a los usuarios. Saber suficiente IA para aprovecharla y suficiente informática para no ser engañado.
Mi experiencia lleva a una paradoja aparente: dejé de desarrollar en el sentido antiguo, pero sigo construyendo aplicaciones. La IA hace más trabajo material; la experiencia me permite elegir, dirigir, corregir y reconocer un buen producto.
MOSAICO anticipaba la transformación: organizar lo aprendido y componer rápidamente nuevas soluciones, no reescribir todo. Hoy también pueden generarse las piezas; sigue siendo esencial el diseño del mosaico.
La IA no vuelve inútil al programador. Hace menos valiosa la mera producción de líneas y más valiosa la capacidad de dar a cada una lugar, propósito, prueba y responsabilidad.
El futuro no es competir en velocidad de escritura, sino saber decir a la máquina qué construir, comprender qué ha construido realmente y responder de las consecuencias.
Referencias esenciales
- International Labour Organization, Generative AI and Jobs: A Refined Global Index of Occupational Exposure (2025) — Transformación de tareas, no eliminación automática de profesiones.
- International Labour Organization, The future of work: How will junior programmers be affected? (2025) — Acceso profesional y actividades formativas de juniors.
- European Commission, State of the Digital Decade 2025 — IA, nube y big data, junto a carencia de competencias TIC avanzadas.
- ACM / IEEE-CS / AAAI, Computer Science Curricula 2023 (2024) — Competencias, responsabilidad e IA en formación informática.
- David Parnas, On the Criteria To Be Used in Decomposing Systems into Modules (1972) — La modularidad oculta decisiones susceptibles de cambiar.
- Fred Brooks, No Silver Bullet (1986; Computer, 1987) — Complejidad accidental y esencial del software.
Texto concebido para publicación en línea. Se permiten citas breves indicando autor y título.
Lee también
Las matemáticas en la época de la inteligencia artificial