> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/es/2025/w50-what-should-the-team-do-next-year-in-ai-coding.md).

# W50-Qué debería hacer el equipo el próximo año en programación con IA

Esta semana leí [*Estado de la IA*](https://openrouter.ai/state-of-ai), de a16z y OpenRouter. Es un estudio empírico basado en un volumen del orden de 100 billones de tokens reales de la plataforma OpenRouter. Apenas empecé a leerlo, tuve la sensación de haber perdido la noción del tiempo. La versión oficial de o1 se publicó el 2024-12-05, hace justo un año. La proporción de tokens procesados por modelos de razonamiento ha aumentado a lo largo de 2025 y últimamente ya supera la mitad.

Si suponemos que las capacidades de los modelos seguirán mejorando durante los próximos años —con más extensión de las capacidades multimodales, de memoria y de agentes—, el objetivo central del equipo en programación con IA no debería limitarse a introducir algunas herramientas y reunir unas cuantas plantillas de prompts. Debería ser construir una base de ingeniería AI-Ready, para que cuanto más potentes sean los modelos, más capacidad de entrega podamos liberar.

Para mantener nuestro trabajo en esa dirección a largo plazo, los cinco frentes siguientes permiten acumular mejoras.

**1) Arquitectura**

La IA tampoco puede hacer mucho con un proyecto que nadie sabe explicar con claridad. No solo consume enormes cantidades de tokens, sino que puede provocar regresiones con facilidad al pasar por alto dependencias implícitas. Los principales problemas de la arquitectura de frontend son la mezcla de vistas y lógica de negocio, el entrelazamiento de lógica y efectos secundarios y la imposibilidad de separar lo que cambia con frecuencia de lo que permanece estable. Adoptar MVVM o MVC no basta para resolverlos.

El proyecto debería poder responder claramente qué constituye su código central. Ese código contiene toda la lógica de negocio y la evolución del estado. Idealmente, está formado por funciones puras, es independiente del framework, no depende del entorno, admite pruebas unitarias y tiene entradas y salidas deterministas. El resto se ocupa de las operaciones de entrada y salida de red, los efectos secundarios y el renderizado de la interfaz. Así, la IA dispone de una base estable sobre la que trabajar y los cambios resultan más controlables.

**2) Hacer explícito el contexto**

Sin el contexto histórico, la IA tampoco puede entender por qué el código contiene ciertos trucos extraños. La importancia de la documentación y los comentarios ya no se limita a conservar conocimiento: afecta directamente a la calidad del código generado.

Más concretamente, hay que hacer explícita la información del dominio del negocio, las restricciones arquitectónicas, las preferencias tecnológicas y las normas de ingeniería del equipo. Lo ideal es registrarlas en formatos fáciles de consumir por la IA, como registros de decisiones de arquitectura, listas de restricciones o secciones del README con las reglas que no pueden vulnerarse. Una cadena de herramientas adecuada debe hacer llegar ese contexto al modelo.

**3) Adelantar las restricciones**

Estoy muy de acuerdo con detectar los problemas antes mediante el compilador y el análisis estático. Rust es un ejemplo de compilación estricta, pero en la mayoría de los casos de frontend no es imprescindible usar Rust para evitar incidentes. El verdadero problema es que no aprovechamos plenamente las ventajas de TypeScript. La principal razón es histórica: para extender TS más rápidamente se permitió usarlo de forma muy permisiva. En la práctica, muchos proyectos no han activado todas las restricciones de tipos y compilación.

El modo strict de TS es una base no negociable. Hay que prohibir de forma decidida tipos sin sentido como any. También hacen falta reglas de lint personalizadas y comunes. Podemos escribir reglas de ESLint para imponer los límites arquitectónicos y unificar el estilo del lenguaje, por ejemplo, exigiendo Composition API o prohibiendo las dependencias entre capas.

**4) Verificación programática**

Generar código será cada vez más barato. Lo realmente costoso es verificar si es correcto, así que hagamos primero las verificaciones de bajo costo. Esto encaja con el enfoque de TDD y también resuelve la dificultad histórica de su alto costo de implantación.

Una buena arquitectura permite identificar bien el código central. Cubrirlo con pruebas unitarias pasa a ser una inversión muy rentable. Frontend y backend colaboran mediante contratos, por lo que conviene incorporar Zod para validar los esquemas en tiempo de ejecución. Frontend y QA colaboran mediante casos de prueba. Escribir los criterios de aceptación o los casos de prueba en lenguaje natural antes de implementar puede parecer aburrido, pero también puede ser muy eficaz.

**5) Observabilidad y diagnóstico**

A medida que crecen la organización y la especialización, la respuesta a reclamaciones de clientes y el diagnóstico de problemas en producción se vuelven menos eficientes. La información de los registros está dispersa entre servicios, y recopilar hechos mediante intercambios en grupos de chat puede consumir horas.

Hay que conectar los registros y la observabilidad para que la IA pueda ver los datos completos de los servicios anteriores y posteriores. Como mínimo, necesitamos registros estructurados, trazas unificadas y la posibilidad de reproducir los recorridos críticos. Automatizar primero la recopilación de hechos permitirá a los ingenieros responder con más agilidad. También es un requisito previo para el diagnóstico automático con IA.