Arquitectura AI-First: Por Qué la Responsabilidad Única Importa Más Que Nunca

La IA está cambiando cómo escribimos código más rápido que cualquier cambio que hayamos visto. En solo un par de años, pasó de autocompletar a desarrolladores de código. Pero la verdad es que, aunque la IA está acelerando todo, los principios que mantienen el software unido no han cambiado. De hecho, importan más que nunca.

Y esto es solo el comienzo. ChatGPT comenzó como un bot de chat. Luego empezó a escribir funciones, leer tickets, revisar el PR. Está aprendiendo el lenguaje de la ingeniería, no solo la sintaxis, sino el proceso. En unos años, no solo nos asistirá.

Colaborará con nosotros. Entonces, ¿cuál es nuestro papel? Tenemos dos opciones. Podemos resistirnos fingir que este cambio no está sucediendo, o podemos aceptarlo. Pero hacerlo con estructura, con barandillas, con intención, porque sin ellas, la velocidad se convierte en caos.

Con ellas, podemos construir un sistema que se mantenga estable incluso cuando la IA esté involucrada. Estamos en fase de transición. La IA aún no es completamente un compañero de equipo, pero cada actualización se acerca más. Lee nuestra estructura. Aprende nuestro patrón, y se adapta a cómo construimos pronto. No solo seguirá nuestro comando. Nos ayudará a decidir cómo construir y cómo estamos construyendo software. La línea entre humano e IA se está desvaneciendo. La velocidad no es nueva.

Cada gran salto en la historia comenzó con caos. Cuando pasamos de caballos a coches, parecía incontrolable, demasiado rápido, demasiado arriesgado. Pero una vez que añadimos estructura, carreteras, carriles, reglas, lo que sea, esa velocidad se convierte en progreso. Hemos vivido con eso durante un siglo ahora, y la velocidad no rompió el mundo. Solo lo remodeló. La velocidad no es el enemigo. Lo mismo está sucediendo con la IA.

No está creando caos. Lo está amplificando. Y si le das una estructura, amplifica el progreso continuamente en lugar de ese caos. Por eso la arquitectura importa más que nunca. Se trata de lo que mantiene tus sistemas estables, incluso con la IA tomando el control para evolucionarlos.

Soy John Adib. He pasado la última década construyendo sistemas de todos los tamaños, desde pequeñas aplicaciones de start-up hasta plataformas distribuidas a gran escala, y he visto tanto el caos como el control de cerca. Mi enfoque siempre ha sido simple. Hazlo claro, consistente y construye para durar. Y últimamente, la IA se ha convertido en parte de esa historia.

Cuando comencé a usar IA en el trabajo de producción, fue como agregar un nuevo compañero de equipo. Rápido, creativo, pero de alguna manera impredecible. Y me di cuenta de algo. El mismo principio de arquitectura, cualquiera que tengamos, que ayuda a los humanos a colaborar más eficazmente entre sí, también está ayudando a la IA a integrarse. De eso trata esta charla. Cómo mantener el control, mientras todo a tu alrededor se acelera.

Hemos pasado por muchos cambios, desde la nube, desde el escritorio a la nube, de monolitos a microservicios. Pero este es diferente. Esto es nuevo. Esto está cambiando completamente la forma de trabajar que tenemos. La IA no es un nuevo framework o biblioteca. Es un nuevo participante en cómo construimos. Entonces, ¿qué significa eso para nuestra arquitectura?

Tradicionalmente, nuestros sistemas estaban diseñados solo para humanos. La IA, si existía, incluso, era el servicio externo, solo a través de algún tipo de API. La arquitectura realmente no se preocupaba por la IA como parte del equipo y el proceso. Pero eso está cambiando. Está cambiando rápido. La IA ahora puede leer nuestros tickets, generar los PRs, refactorizar nuestro código, o incluso revisar el código y enviarlo a producción. Ya no es una herramienta. Es parte de todo el proceso.

Puede participar en cada una de las pequeñas partes del proceso. Eso significa que nuestra arquitectura tiene que adaptarse. Para mí, la arquitectura AI-first significa construir un sistema que no colapse cuando la IA se une al ciclo. Sistemas con límites claros, capas predecibles y fuertes barandillas, para que la IA pueda moverse rápido sin romper tu estructura. Y tu código y tu sistema.

La IA no inventa una estructura para ti. Solo amplifica lo que ya tienes allí. Si tu base es clara, está amplificando la claridad de eso. Pero si es desordenada, solo está amplificando el caos y va a fallar muy rápido. Por eso la arquitectura, especialmente la responsabilidad única, importa más que nunca.

Ahora, los principios que mantienen todo estable, responsabilidad única. Hablemos de eso. Si tuviera que elegir solo un principio para mantener todo estable en la era de la IA, sería este, el principio de responsabilidad única. Dice simplemente un archivo, un propósito, una razón para cambiar. Suena muy simple. Es muy básico. Cada ingeniero lo sabe. Pero es la regla que separa el caos de la claridad, especialmente en la era de la IA.

Así que la responsabilidad única no se trata solo de la sintaxis. Se trata de la intención. Cada archivo, cada función y componente que tengas debería tener solo un trabajo y hacerlo realmente bien. Cuando los límites son claros, la IA los entiende también. Sabe dónde pertenecen las cosas y va a conectar los puntos juntos. Y luego va a crear lo que pidas, ya sea arreglar el error o agregar una nueva característica. Y no se va a romper. La IA aprende por reconocimiento de patrones.

Si tu arquitectura tiene una separación clara, se vuelve claro para la IA leer eso y entenderlo. Pero si todo está mezclado, lógica, IA, backend, base de datos, lo que sea que tengas, la IA aprende todos esos ruidos. Va a amplificar esos. Y va a crear un desorden cada vez más. Imaginemos esto por un segundo. Abres tu chat de cursor, Cloud Code, Gemini, Chattopaddy, lo que sea que tengas, cualquier IA que tengas, y le pides que agregue una nueva pequeña característica a la base de código. Va a comenzar rápidamente, saltar de inmediato, agregando más y más líneas a la base de código existente. No piensa en lo que tienes allí, tu arquitectura. Solo va a completar tu solicitud lo más rápido posible.

El código que funciona hoy pero puede romperse mañana. A la IA no le importa tu arquitectura. A la IA le importan tus solicitudes. A menos que diseñes un sistema que le enseñe el proceso a ella. Responsabilidad única y separación de preocupaciones. Estos dos son hermanos. Uno define la regla, el otro muestra cómo aplicarlas. La responsabilidad única dice un archivo, una razón para cambiar. Y por otro lado, la separación de preocupaciones dice asegúrate de que cada parte de tu sistema maneje su propia responsabilidad y nada más. Cuando estos dos límites son claros, los humanos entienden el sistema. Además, la IA puede seguirlos para seguir la estructura que tienes más precisamente en tu base de código. Ahora, imagina la misma característica de nuevo, pero esta vez, tu proyecto tiene una estructura clara.

La IA observa el patrón que tienes y comienza a seguirlo. No añade un código en cualquier lugar que pueda hacerlo. Está tratando de encontrar el mejor lugar para esa lógica. La velocidad sigue ahí, pero ahora se ha vuelto estable, predecible y también fácil de mantener, lo cual es realmente importante para nosotros.

No vamos a simplemente construir las cosas y publicarlas. Necesitamos mantener nuestro software y eso realmente importa. Porque cuando la arquitectura guía a la IA, la estructura convierte la velocidad en estabilidad. La diferencia entre estos dos es el tiempo que la arquitectura guió a la IA. Así que los principios, como hablamos, nos dan una dirección y las barandillas nos mantienen en el camino.

Las estructuras nos dan dirección, pero como dijimos, la barandilla nos da una dirección para estar seguros. La IA se mueve rápido, pero sin ningún límite, rápidamente se convertirá en un riesgo. Veamos las reglas simples que protegen la estabilidad cuando la IA se une a la construcción. Lint. No podemos confiar en que todos o cada IA recuerden nuestros límites. Las reglas de lint y una verificación estática harán que la estructura no sea negociable. Convierten la claridad en código.

El mejor sistema no solo depende de la memoria de las personas, depende de la imposición. Así que cuando hablamos de Lint, estamos diciendo, OK, cualquiera que sea la herramienta que estés usando, puede ser ESLint, puede ser BioMe o cualquier otra tipo de herramientas que estés usando basadas en tu lenguaje. Necesitamos definir una regla, la regla que no importa, IA escribiendo código o humano, para prevenir el problema, para proteger tu base de código, para crear un caos. Hay cientos de reglas por ahí basadas en el lenguaje. Puedes elegir las mejores herramientas para ti.

Pero lo que importa es proporcionarlas para proteger tu base de código, para definir la estructura y tener una regla que te ahorre una gran cantidad de tiempo en el futuro para mantener la base de código que tienes. El siguiente gran tema son las pruebas. No puedo hablar de esto durante horas. Ya no son solo para humanos.

Se trata de enseñar a la IA cómo se ven las cosas correctas cuando el modelo, cualquier modelo que genere tu código, la prueba va a ser el lenguaje de la confianza. Un contrato que prueba que una estructura aún funciona. He visto a muchos desarrolladores pidiendo a la IA que genere solo unas pocas pruebas para tener algo y solo para cosas básicas.

solo unas pocas pruebas para tener algo y solo para cosas básicas. Pero lo que importa en la era de la IA realmente depende de la prueba porque estás escribiendo algo y la IA va a cambiar eso en el futuro. Así que si tu prueba es realmente restrictiva y verifica toda la situación que tienes, va a ser realmente confiable en el futuro cuando alguien más o la IA cambie eso en el futuro. Así que necesitamos entender la importancia de la prueba y no deberíamos considerarla solo como algo agradable de tener.

Va a ser algo realmente crítico para nosotros. Y la parte en la que vamos a controlar nuestra IA sobre el cambio de código y la parte divertida que vi muchas veces, de hecho, uno de mis colegas recientemente me contó sobre la prueba fallida. Le pedí a la IA que las arreglara. La IA las eliminó todas y no quedó nada al final.

Lo que importa es que necesitas entender que la prueba es algo de un nivel completamente diferente y necesitas entender cuándo y por qué necesitas cambiarlas. Normalmente, cuando escribes una prueba para verificar un resultado especial de alguna función o alguna entidad que tienes, no necesitas. No deberías actualizar eso en el futuro. Y recuerda, la responsabilidad única, si necesitas otro acto, otro resultado de esa función, deberías crear una nueva función. No actualices esa, la antigua. Y la IA aprende de nuestros patrones. Se trata de consistencia, nombres consistentes, carpetas, funciones, todo lo que tenemos.

Si los humanos pueden adivinar dónde está el código para hacer algo, la IA también simplemente puede hacerlo. Pero la consistencia se trata de claridad. Nos está ayudando. Está ayudando a la nueva forma de codificación que tenemos.

Y la siguiente parte importante es sobre la documentación. No se trata del comentario en el código. No lo tomes a mal. La documentación se trata de dar un contexto, una historia de cómo tu sistema encaja en conjunto.

Cuando la arquitectura es clara, no deberías necesitar un comentario para explicarlo. Creo que no necesitamos un comentario. Si usamos nombres descriptivos y entendemos, damos un contexto con documentación, no necesitamos tener comentarios en línea para definir lo que hay allí. Lo que importa en la documentación son los límites. Se trata de toda la intención de lo que trata esa parte del código.

Eso va a ayudar tanto a los humanos como también definitivamente a la IA a entender cómo construir, extender o arreglar sin adivinar sobre ellos. Una buena documentación no describe el código. Describe el sistema. Y en la era de la IA, importa. Y la razón es que algunas de las IA están tratando primero de analizar tu código y luego generar documentación para sí mismas para referirse a las próximas cosas que quieren implementar.

Así que vemos algunas de las IA especialmente tratando de crear documentación para ahorrar tokens para la próxima solicitud que tengas, porque documentan lo que necesitaban. Y la próxima vez, solo están leyendo esa parte en lugar de leer toda la base de código para entenderlos. Así que algunas personas piensan que las reglas pueden ralentizar al equipo, pero las buenas reglas hacen exactamente lo contrario. Mantienen el impulso seguro. GuardDays permiten que todos se muevan rápido en la misma dirección. No nos está ralentizando en absoluto.

Y necesitas entender que todos los GuardDays, todas las cosas de las que hablamos y que podemos agregar a nuestra base de código, la IA va a aprender cómo usarlas. Y cada vez va a ser mejor y mejor. Está entendiendo tu patrón y cada vez tratando de actuar mejor y mejor. Así que eso necesitas entender. Invertir tiempo ahora para mejorar estos GuardDays para tu equipo y la IA está ahorrando tu tiempo en el futuro. Así que solo estoy sugiriendo hacer eso lo antes posible antes de que sea tarde.