> 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/2026/w38-everything-can-be-engineered.md). # W38-Todo puede abordarse con ingeniería Varias cosas que he hecho últimamente me hacen sentir cada vez con más fuerza que la IA está cambiando mi forma de abordar los problemas complejos. Antes, cuando un problema superaba cierto grado de complejidad, normalmente solo podía dedicarle más atención. Recordar configuraciones, mantener documentación, explicar una y otra vez el contexto y diagnosticar los errores después de que ocurrieran. Aunque supiera que podía resolverlo con un programa, no siempre compensaba construir y mantener un sistema para ello. Ahora estoy más dispuesto a convertirlo en un proyecto de ingeniería. Dejar por escrito los hechos y las reglas, delegar las operaciones repetitivas en programas, añadir comprobaciones a los cambios y conservar el historial y las vías de reversión. Cuando surja una nueva necesidad, podré ampliar esa base. Los métodos de ingeniería existen desde hace mucho. **La IA ha reducido el coste de aplicarlos y mantenerlos. Muchos proyectos que antes no compensaban ahora sí lo hacen.** ## De una configuración de proxy a un proyecto que se puede mantener El primer ejemplo es la configuración del proxy de mi Mac. Al principio, solo se trataba de conseguir que unas cuantas aplicaciones se conectaran bien a internet. A medida que crecieron las necesidades, empezaron a intervenir el enrutamiento de distintos sitios, la conexión directa a la red corporativa, las diferencias de entorno entre la línea de comandos y las aplicaciones de escritorio, las actualizaciones de configuración y las migraciones de equipo. Resolver cada cuestión por separado no era difícil. Pero, al acumularse las reglas, mantenerlas de memoria se volvió complicado. Hoy resolvía un problema y, pasado un tiempo, podía haber olvidado por qué lo había configurado así y qué afectaría el siguiente cambio. Terminé organizando esta solución en un repositorio privado. El repositorio contiene plantillas de configuración, reglas de enrutamiento, scripts de generación y validación, y manuales de recuperación, mantenimiento y diagnóstico. Puedo previsualizar los cambios antes de hacerlos, crear copias de seguridad antes de instalar y revertir si algo sale mal. También hay pasos claros y criterios de aceptación para migrar a otro Mac. Ya he realizado la migración a otro equipo y he comprobado la eficacia y la eficiencia de la solución. Lo que antes exigía revisar cada aspecto y configurarlo a mano ahora se puede completar siguiendo las reglas y los procesos del repositorio. La capacidad de reutilizar el proyecto ha quedado así probada en la práctica. Para mí, el cambio consiste en que por fin puedo tratar esta configuración como un sistema que mantengo a largo plazo. Cuando añado una aplicación o ajusto una regla, tengo un lugar donde hacerlo, un método para comprobarlo y un historial que consultar. **La complejidad sigue existiendo, pero ahora tiene un lugar definido donde alojarse y una forma de gestionarla.** ## El propio equipo de agentes también necesita ingeniería El segundo ejemplo es el equipo de agentes que llevo un tiempo utilizando. Si trabajo solo con uno o dos agentes, normalmente basta con conversar directamente y asignarles tareas. Pero, cuando necesito que varios agentes asuman distintos roles y se organicen para colaborar en la resolución de problemas complejos, hace falta un conjunto claro de reglas de funcionamiento. Hay que decidir de antemano quién descompone las tareas, quién implementa, quién revisa, cómo se entrega el trabajo y quién toma el relevo cuando surge un problema. Al incorporar tareas automatizadas al equipo o al proyecto, también hay que gestionar cómo se activan y ejecutan. Por ejemplo, detectar cambios en el código y revisar las PR automáticamente, o trasladar el contenido correspondiente a cada repositorio secundario después de integrar un cambio en el repositorio de integración. Estas necesidades fueron más allá de mantener unos cuantos prompts a mano. Por eso organicé las configuraciones de los roles, las reglas de colaboración y las tareas automatizadas de los agentes en un proyecto que puedo gestionar, operar y ampliar de forma continua. Las responsabilidades de cada rol, las reglas de colaboración y las políticas de funcionamiento se guardan en el repositorio. Este declara el estado que debería tener el equipo, mientras que la herramienta de sincronización comprueba las diferencias con su estado real. Los cambios se pueden previsualizar y, después de aplicarlos, se verifica que ambos estados coincidan. Así puedo ajustar el equipo de forma continua sin tener que volver a montarlo desde cero cada vez. **Una experiencia de colaboración que funciona puede convertirse en una regla compartida por todos los roles implicados.** Los problemas que revela un fallo también pueden incorporarse a la configuración y a los procesos de validación, y servir de base para el siguiente trabajo. He empezado a tratar al equipo de agentes como un sistema que necesita operaciones y mejoras continuas. Las capacidades del modelo son una parte. Los límites de cada rol, la entrega de tareas y los métodos de aceptación también requieren una mejora constante. ## Reunir el contexto de trabajo del equipo en una misma versión El tercer ejemplo es el MVP de declaración de impuestos que estamos desarrollando. Lo estamos construyendo en el repositorio de integración de BFO. La documentación de producto y arquitectura, los contratos de interfaces, las especificaciones de aceptación, el código de frontend y backend y las herramientas de los agentes entran en un mismo repositorio de integración y forman una base común versionada. **Quiero trabajar de una forma en la que la documentación sea código y el código sea producto.** Cuando cambian las reglas del producto, podemos modificar y revisar juntos la documentación, los contratos, la implementación y los criterios de aceptación relacionados. Podemos volver a una versión concreta y ver qué se exigía entonces, cómo lo implementaba el código y con qué criterios se juzgaba si era correcto. Antes, ese contexto solía estar disperso entre documentos, conversaciones y la memoria de distintas personas. La colaboración entre roles exigía trasladarlo y explicarlo una y otra vez. Producto lo explicaba, desarrollo lo interpretaba y pruebas lo reconstruía. Tras un cambio de requisitos, había que volver a comprobar que todos estuvieran trabajando con la misma versión. El repositorio de integración ofrece una referencia común para todo ese trabajo. No elimina las diferencias de interpretación entre personas, pero puede reducir el coste de buscar materiales, comprobar versiones y repetir explicaciones del contexto. Las conversaciones pueden centrarse en cambios concretos, y sus conclusiones tienen un lugar claro donde quedar registradas. La IA también puede leer esos materiales. Al recibir una tarea, puede buscar contexto siguiendo los requisitos, los contratos, la implementación y las pruebas, sin depender por completo de la información que se le facilite de forma puntual en la conversación actual. El MVP sigue en desarrollo y aún falta comprobar sus beneficios a largo plazo. Me interesa especialmente la iteración cotidiana posterior. Si estos recursos se mantienen junto con el producto, cada ronda de trabajo puede dejar una base más completa para la siguiente. **El trabajo que ya hemos hecho puede seguir reduciendo el coste del trabajo futuro.** ## Hechos y presentación en la gestión financiera El cuarto ejemplo aún no existe: es el proyecto de gestión de mis finanzas personales y mis inversiones que tengo previsto crear. Actualmente mantengo en Google Drive materiales de revisión semanal, mensual y trimestral sobre las finanzas familiares, y sigo observando los mercados. Pienso organizar poco a poco ese trabajo en un proyecto privado. Incluirá la situación básica de las finanzas familiares, los activos en los que invertir, los canales de inversión, las observaciones de mercado y los registros de las revisiones periódicas. **Lo que más me atrae es poder separar la fuente de los hechos de su forma de presentación.** Antes, al decidir si registrar la información en una hoja de cálculo, un documento o una presentación, ya solía estar pensando en su aspecto final. La herramienta de presentación acababa determinando fácilmente cómo se organizaban los datos. En adelante, quiero mantener primero un registro básico con fuentes, fechas y versiones, y generar después la presentación según la pregunta concreta. Si quiero ver la distribución de activos, genero un gráfico. Si quiero hacer la revisión mensual, genero un informe. Si quiero entender un cambio, indago en el historial. Todas las presentaciones proceden de los mismos datos básicos y pueden contrastarse con ellos. Así no tendré que reorganizar los hechos para cada forma de presentación. Los gráficos y los informes se pueden generar y ajustar en cualquier momento. El mantenimiento a largo plazo se centrará en que la información subyacente sea precisa, completa y esté actualizada. Esto también ha cambiado mi forma de entender la ingeniería. Un proyecto puede albergar hechos, reglas y registros de decisiones, y generar, según sea necesario, interfaces que las personas puedan leer y utilizar. ## La IA facilita recuperar la inversión en ingeniería Estos ejemplos tienen algo en común. Todos han acumulado cierta complejidad y todos necesitan mantenimiento continuo. Antes, quizá no hubiera querido crear proyectos de ingeniería para ellos. Escribir scripts, completar documentación, validar y mantener herramientas exige una inversión. Muchas necesidades personales son demasiado pequeñas para que sus beneficios cubran el coste, así que acabamos resolviéndolas a mano. La IA reduce esa inversión. Cuando resulta más barato organizar configuraciones, escribir scripts, añadir pruebas y mantener documentación, aumenta el número de problemas que estoy dispuesto a resolver con métodos de ingeniería. La configuración del proxy, la colaboración entre agentes, el contexto de trabajo del equipo e incluso las finanzas familiares empiezan a entrar en ese ámbito. **La fiabilidad sigue necesitando mecanismos concretos que la sostengan.** Hay que contrastar los hechos, validar los cambios, detectar los fallos y poder revertir cuando sea necesario. La IA puede ayudar a construir y mantener esos mecanismos, pero no puede sustituirlos. Solo con esa base tengo más confianza para seguir ampliando las capacidades. **El sistema puede resolver más problemas sin exigirme un aumento proporcional de memoria y atención.** Cada vez tengo más claro que todo puede abordarse con ingeniería. Más precisamente, **si un problema contiene partes que se pueden describir, calcular y verificar de forma clara, tengo la posibilidad de organizarlas en un proyecto que pueda mantenerse de forma continua.** El juicio y las decisiones siguen correspondiendo a las personas, pero la organización de la información, la ejecución y la retroalimentación que los rodean pueden mejorar constantemente. Antes, ante un problema complejo, lo primero que pensaba era cuánto esfuerzo tendría que dedicarle. Ahora me pregunto primero si puedo construir un sistema que siga creciendo en el futuro.